面向对象软件的测试用例的设计方法(2)

　　把语句if(x>=0)calculate_square_root( );

　　误写成if(x>0)calculate_square_root( );

　　为了推测出软件中可能有的错误，应该仔细研究分析模型和设计模型，而且在很大程度上要依靠测试人员的经验和直觉。如果推测得比较准确，则使用基于故障的测试方法能够用相当低的工作量发现大量错误;反之，如果推测不准，则这种方法的效果并不比随机测试技术的效果好。

　　12.4.2 集成测试方法

　　开始集成面向对象系统以后，测试用例的设计变得更加复杂。在这个测试阶段，必须对类间协作进行测试。为了举例说明设计类间测试用例的方法，我们扩充 12.4.1小节引入的银行系统的例子，使它包含图12.3所示的类和协作。图中箭头方向代表消息的传递方向，箭头线上的标注给出了作为由消息所蕴含的协作的结果而调用的操作。

　　和测试单个类相似，测试类协作可以使用随机测试方法和划分测试方法，以及基于情景的测试和行为测试来完成。

　　1. 多类测试

　　Kirani和Tsai建议使用下列步骤，以生成多个类的随机测试用例。

　　. 对每个客户类，使用类操作符列表来生成一系列随机测试序列。这些操作符向服务器类实例发送消息

　　. 对所生成的每个消息，确定协作类和在服务器对象中的对应操作符。

　　. 对服务器对象中的每个操作符(已经被来自客户对象的消息调用)，确定传递的消息。

　　. 对每个消息，确定下一层被调用的操作符，并把这些操作符结合进测试序列中。

　　. 为了说明怎样用上述步骤生成多个类的随机测试用例，考虑Bank类相对于ATM类(见图12.3)的操作序列：

verifyAcct·verifyPIN·［（verifyPolicy·withdrawReq）|depositReq|acctInfoREQ］n

　　对Bank类的随机测试用例可能是：

　　测试用例#r3:verifyAcct·verifyPIN·depositReq

　　为了考虑在上述这个测试中涉及的协作者，需要考虑与测试用例#r3中的每个操作相关联的消息。Bank必须和ValidationInfo协作以执行 verifyAcct和verifyPIN,Bank还必须和Account协作以执行depositReq。因此，测试上面提到的协作的新测试用例是：

　　测试用例#r4:verifyAcctBank·[validAcctValidationInfo]·verifyPINBank·[validPINvalidationInfo]·depositReq·[depositaccount]

　　多个类的划分测试方法类似于单个类的划分测试方法(见12.4.1节)。但是，对于多类测试来说，应该扩充测试序列以包括那些通过发送给协作类的消息而被调用的操作。另一种划分测试方法，根据与特定类的接口来划分类操作。如图12.3所示，Bank类接收来自ATM类和Cashier类的消息，因此，可以通过把Bank类中的方法划分成服务于ATM的和服务于Cashier的两类来测试它们。还可以用基于状态的划分(见12.4.1节)，进一步精化划分。

　　2. 从动态模型导出测试用例

　　在第9章中已经讲过，怎样用状态转换图作为表示类的动态行为的模型。类的状态图可以帮助我们导出测试该类(及与其协作的那些类)的动态行为的测试用例。图12.4给出了前面讨论过的account类的状态图，从图可见，初始转换经过了empty acct和setup acct这两个状态，而类实例的大多数行为发生在working acct状态中，最终的withdraw和close使得account类分别向nonworking acct状态和dead acct状态转换。

　　图12.4 account类的状态转换图

　　设计出的测试用例应该覆盖所有状态，也就是说，操作序列应该使得account类实例遍历所有允许的状态转换：

　　测试用例#s1:open·setupAccnt·deposit(initial)·withdraw(final)·close

　　应该注意，上面列出的序列与12.4.1节讨论的最小测试序列相同。向最小序列中加入附加的测试序列，可以得出其他测试用例：

　　测试用例#s2:open·setupAccnt·deposit(initial)·deposit·balance·credit·withdraw(final)·close

　　测试用例#s3:open·setupAccnt·deposit(initial)·deposit·withdraw·accntInfo·withdraw(final)·close

原文转自：http://www.uml.org.cn/Test/201501295.asp