利用范畴-划分思想，用相应场景路径的路径条件和加在消息上的约束、以及系统本身的属性约束来限定这些选择，排除无意义和有冲突的值，然后通过这些不同的范畴的不同选择的可能组合作为一个场景路径的测试用例，这样每个场景路径生成一个集成测试用例。具体算法描述如下：
Testcasegenerator(){
//输入：spath[n]
//输出：tcsuite[n]{ envirnmentpara,input(inputpara,paravaliue),expectoutput,postcondition}
i:integer;
for i:=1 to n do {
tcsuite[i].postcondition:=spath[i].pathcondition;
tcsuite[i].environmentpara:={满足路径条件的环境条件}
tcsuite[i].input.inputpara=spath[i].userinputsparamenters;
选择对本场景路径条件有影响的参数确定其可能的取值；
tcsuite[i].input.paravalue={符合路径条件的输入参数可能的取值}；
取出spath[i]的方法激活序列，分析每一个方法的定义，确定其可能的行为，选择符合场景路径条件的行为，并将方法序列的执行过程的输出序列存到tcsuite[i].expectoutput中；
i:=i+1;
}endfor;
}endtestcasegenerator;
为说明问题，我们选一条最长路径spath[5]（消息序列为：1.1，1.2，2.1，2.2，2.3，4.1，4.2，4.3，5）来演示使用上述方法生成覆盖该路径的测试用例的过程。，从该路径获取相关范畴如下：
Tcsuite[5]
Pathcongdition:!notATMCard, !isStolen, !accountClosed, validPIN&&n=1,!declineFee
Environmentcondition:
ATM卡，非成员卡，卡没有被盗，帐户没有关闭
parameter category：
inputPIN     //影响validPIN 
123456 [property validPIN][if !notAtmCard]
564821
123258
……..
deClineFee     //影响deClineFee
T   [property declineFee][if !isMemberCard]]
F
interaction behavior category：
session.beginSession()，    
插卡事件创建session对象
cardSlot.isATMCard()，
判断是ATM卡，读取卡号，定义cardNum，notATMCard=F[if !notATMCard]
判断不是ATM卡，notATMCard=T   
screen.prompt()，
屏幕提示“please input PIN”，n=1[if !notATMCard][property n]
屏幕提示“please input PIN”，n=2[if !notATMCard] [property n]
屏幕提示“please input PIN”，n=3[if !notATMCard] [property n]
numkeyPad.getEntry()，
输入正确的PIN inputPIN=’123456’[if n=1]
输入错误的PIN inputPIN<>’123456’[if n=1]
输入正确的PIN inputPIN=’123456’[if n=2] and [if !validPIN&&n=1]
输入错误的PIN inputPIN<>’123456’[if n=2] and  [if !validPIN&&n=1]
输入正确的PIN inputPIN=’123456’[if n=3] and [if !validPIN&&n=2]
         输入错误的PIN inputPIN<>’123456’[if n=3] and [if !validPIN&&n=2]
bank.checkCard()，
为被盗ATM卡验证PIN ，isStolen=T[if !notATMCard]
为帐户关闭的ATM卡验证PIN，accountClosed=T [if !notATMCard]
为合法ATM卡错误输入PIN验证身份，accountClosed=F,
isStolen=F ,validPIN=F[if !notATMCard&n<4]
为合法ATM卡正确输入PIN验证身份，accountClosed=F,
isStolen=F ,validPIN=T[if !notATMCard&n<4]
bank.getFeeAmount()，
获取非成员卡用户交易服务费金额,定义feeAmount [if !notATMCard&&ValidPIN&&n<4 and !isMemberCard]
screen.prompt()
屏幕提示“Fee Payed:XXX” 
numkeyPad.getEntry(),
输入同意付费，declineFee=T
输入拒绝付费，declineFee=F   
screen.prompt()
屏幕提示“please select transaction”[if !notATMCard&ValidPIN&&n<4] and [if isMemberCard or !isMembercard&!declineFee]
这样我们符合spath[5]路径条件的相应的一个测试用例tcsuite[5]的最后结果为：
Test case 5：
外部事件：插卡
environmentcondtion： ATM卡，非成员卡，卡没有被盗，帐户没有关闭
input category：
inputPIN=’123456’ //输入有效PIN
declineFee=F  //输入同意付费
interaction behavior category：
session.beginSession()，    
为ATM卡合法持卡人建立会话
cardSlot.isATMCard()，
判断是ATM卡，读取卡号cardNum, notATMCard=F
screen.prompt()，
屏幕提示“please input PIN”，定义n=1
numkeyPad.getEntry()，
输入正确的PIN，inputPIN=’123456’
bank.checkCard()，
为合法ATM卡正确输入PIN验证身份，定义accountClosed=F,
isStolen=F ,validPIN=T，ismemberCard=F;
bank.getFeeAmount()，
获取非成员卡用户交易服务费金额,定义feeAmount=xxx
screen.prompt()
屏幕提示“fee Payed XXX”
numkeyPad.getEntry(),
输入同意付费  定义declineFee=F
screen.prompt()
屏幕提示“Please select transaction”
预期的方法调用序列：session.beginSession()，cardSlot.isATMCard() ，screen.prompt() ，numKeypad.getEntry() ，bank.checkCard()  ，bank.getFeeAmount()，screen. prompt ()，numKeypad.getEntry()，screen. prompt ()
后条件：
inputPIN=’123456’,!notATMCard, !isStolen, !accountClosed, validPIN&&n=1,
!declineFee
预期输出：
屏幕提示“please input PIN”
屏幕提示“fee Payed XXX”
屏幕提示“Please select transaction”
    我们可以用同样方法为属于同一个用例的其他协作图构造了测试用例，则该用例的集成测试集构造完成。然后，可以用增量方式为组件、子系统、系统构造完整的集成测试用例集，而且可以用自动的方式进行。可以用中的插装方法按照每一场景路径上的方法调用顺序，对待测试实现进行插装，这样在执行时可以观察到软件用相应测试用例运行的结果，并将观察到的实际执行结果与测试用例中的预期结果进行比较，如果一致，说明相应场景的实现与设计是一致的，否则，存在错误，并且错误在协作图的相应场景路径上，可以通过实际结果与预期结果发生不一致的地方定位错误，然后调试修改。
    3.3算法实现工具框架 
    为了支撑上述测试用例生成方法的自动化，我们设计一个基于UML设计模型图的集成测试用例的自动生成工具UMLTGF，我们仍然使用UML为UMLTGF建模，本文给出UMLTGF的类图，如图3。相应的功能描述如下：
    1、ＵＭＬ模型分析器。能够直接读取UML协作图规约的文本文件（如MDL文件），进行解析，并获取对象角色、对象的属性和方法，链、约束，消息流和消息标签，存入相应的中间表，以便测试用例生成器使用；
    2、协作集成测试用例生成器。根据消息的顺序号和条件，跟踪消息流，生成每条消息的直接后继，然后通过遍历消息及其直接后继的方法生成协作图上每个用例场景对应的协作的场景路径，同时可以获取场景执行的控制流和数据流，并用范畴－划分方法生成相应场景路径对应的集成测试用例。输入为从协作图中提取的信息中间表，输出为生成的测试用例集合；
    3、测试用例管理。为使得生成的测试用例集可复用、可维护、无冗余，对每个测试用例设计了增加、修改、删除操作，用来在测试用例生成过程中管理这些测试用例集。

图3 UMLTGF类图