测试用例设计方法 主要内容主要内容¡功能性测试设计功能性测试设计¡结构性测试设计结构性测试设计¡状态转换测试设计状态转换测试设计¡OO单元测试设计单元测试设计¡参考书参考书1.《《软件测试（原书第二版）（软件测试（原书第二版）（Software Testing A craftsman‘s Approach Second Edition) 美美 Paul C.Jorgensen 著著 韩柯韩柯 杜旭涛翻译，机械工业出版社杜旭涛翻译，机械工业出版社2.《《软件工程－实践者的研究方法软件工程－实践者的研究方法》》（（Software Engineering A practitioner‘s Approach Fifth Edition) Roger S. Pressman,黄伯素，梅宏黄伯素，梅宏 翻译，机械工业出版社翻译，机械工业出版社3.《《嵌入式软件测试嵌入式软件测试》》（（Testing Embeded Software））[美美] Bart Borekman,Edwin Notenboom著，张君施，张思宇，周承平译，电子工业出版社著，张君施，张思宇，周承平译，电子工业出版社 测试用例设计方法概述¡测试用例设计方法主要分两大类：黑盒测试（功能性测试）和白盒测试（结构性测试），它们使用的测试用例在表现形式上一模一样，都是：¡（输入1，输入2，…….输入n，预期输出）¡这输入1，输入2，……..输入n就是程序的输入（可以理解为程序的输入参数，全局变量，触发事件），预期输出可以是程序的输出（可理解为程序的输出参数，返回值，全局变量，输出事件）如右图 程序的规格说明（预期行为）和内部结构（决定实际行为）¡ 黑盒测试与白盒测试的区别在于，黑盒测试方法通过程序的规格说明来识别测试用例。
白盒测试根据程序的内部代码结构（分支，循环，条件）来识别测试用例 .见右图图8 程序的规格说明（预期行为）和内部结构（决定实际行为） 黑盒测试与白盒测试的结合¡基于黑盒的测试（也就是基于规格说明测试）可能有些程序的内部路径（大多数是些异常处理路径）覆盖不到，往往是这里的代码会使程序表现出大家所不期望的行为（程序异常死机，或隐藏了恶意的代码，如特洛伊木马程序，还有内存泄漏，程序走飞，死循环等等）¡所以有必要在黑盒测试结束后，检查一下程序内部的测试覆盖率，对没有覆盖到的路径或代码，根据代码结构信息，再设计一些测试用例覆盖这些没有覆盖到路径或代码，看看程序是否会出现异常的行为这是我们所倡导的基本的软件单元测试策略 两个示例程序¡三角形问题¡NextDate问题 三角形问题陈述¡三角形问题接受三个整数a，b和c作为输入，用做三角形的的边程序的输出是由这三条边确定的三角形类型：等 边三角形，等腰三角形，不等边三角形或非三角形 NextDate问题¡NextDate是一个有三个变量（月份，日期和年）的函数函数返回输入日期后面的那个日期变量月份，日期和年都具有整数值，且满足下列条件：¡C1:1<=月份<=12¡C2:1<=日期<=31¡C3:1812<=年<=2012¡如果任意一个条件失败，则NextDate会出示一个消息，指示相应的变量超出范围 功能性测试设计¡边界值测试¡等价类测试¡决策表测试 边界值测试 任何程序都可以看做是一个函数，程序的输入构成函数的定义域，程序的输出构成函数的值域，输入定义域测试是最著名的功能性测试手段，它的重点是在输入定义域¡边界值分析¡健壮性测试¡最坏情况测试¡特殊值测试 边界值分析¡大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。
针对各种边界情况设计测试用例，可以查出更多的错误 ¡边界值分析的基本思想是使用在最小值，略高于最小值，正常值，略低于最大值和最大值处取输入变量值¡边界值分析基于单缺陷假设：失效极少是由两个（或多个）参数同时取某一特定值引起的,基本是由单变量取某一特定值引起的.¡边界值测试用例的获得：通过所有变量取正常值，只有一个变量取边界值¡,,……共 9个测试用例¡变量是离散有界值都可以用边界值分析，但逻辑布尔量不适用（如号码）X2abdc两变量函数边界值分析测试用例X1 边界值分析举例在描述问题时,关于三角形的边,除了说明是整数外,没有给出其他条件.显然,低端边界都是1.我们任意取200做为高端边界,下表给出使用这些定义域产生的边界测试用例. 健壮性测试¡健壮性测试是边界值分析的一种简单扩展：除了变量的五个边界值分析取值，还要通过采用一个略超过最大值（max＋）的取值，和一个略小于最小值（min－）的取值¡如果程序执行显式的范围检查并适用例外处理机制解决“健壮值”问题，必须选择健壮性测试X2abdc两变量函数健壮性测试用例X1 最坏情况测试最坏情况测试¡最坏情况测试拒绝单缺陷假设,采用多缺陷假设:某些失效(Failure)是由两个或多个参数同时取某些特定值引起的.¡对每个变量首先进行包含最小值，略高于最小值，正常值，略低于最大值，最大值五元素测试¡然后对这集合进行笛卡尔儿积计算，生成测试用例X1abcb两变量函数最坏情况测试用例 笛卡尔积¡两个集合A和B的笛卡尔积，是集合¡A×B＝{;xЄA^YєB}¡例1：集合A={1,2,3}¡集合B={w,x,y,z}¡A和B的笛卡尔积是集合¡A×B＝{<1,w>,<1,x>,<1,y>,<1,z>,<2,w>,<2,x>,<2,y>,<2,z>,<3,w>,<3,x>,<3,y>,<3,z>}¡例2：一个更直观的例子：x轴上的点与y轴上的点的笛卡尔积是整个平面上所有点的集合。
最坏情况测试举例¡我们仍然以三角形程序举例来说明最坏情况测试 特殊值测试¡当测试人员适用其领域知识，适用类似程序的经验以及关于“软点”信息开发测试用例时，就会出现特殊值测试，就是不使用测试方针，只使用“最佳工程判断”¡特殊值测试是高度主观性的，但是所产生的测试用例集合，常常比我们已经研究过的其他方法生成的测试集合，更能有效地发现缺陷 边界值测试总结¡除了特殊值测试，基于函数（程序）输入定义域的测试方法除了特殊值测试，基于函数（程序）输入定义域的测试方法是所有测试方法中最基本的，这些测试方法都有一种假设：是所有测试方法中最基本的，这些测试方法都有一种假设：即输入变量是真正独立的，如果不能保证这种假设，就不能即输入变量是真正独立的，如果不能保证这种假设，就不能产生令人非常满意的测试用例（如产生令人非常满意的测试用例（如NextDate中生成中生成1912年年2月月31日）日）¡这些方法还有两方面的区别：正常值和健壮值，单缺陷和多这些方法还有两方面的区别：正常值和健壮值，单缺陷和多缺陷假设缺陷假设 等价类测试¡使用等价类作为功能性测试的基础有两个动机：1.我们希望进行完备的测试2.同时又希望避免冗余¡等价类测试重复边界值测试的两个决定因素：健壮性和单/多缺陷假设¡等价类的重要问题是它们构成集合的划分，其中划分是指互不相交的一组子集，子集的元素都有一些共同的特点¡等价类测试的思想就是通过每个等价类中的一个元素代表整个等价类元素集合，来标识测试用例。
¡等价类测试的关键就是选择类的等价关系 示例函数¡我们讨论一个具有两个变量x1,x2的函数F¡其中：1.a<=x1<=d, 区间为[a，b），[b,c），[c,d]2.e<=x2<=g ,区间为[e,f），[f,g]¡X1和x2的无效值是：x1d,和X2g 弱一般等价类测试¡弱一般等价类测试：¡测试用例中每个参数等价类（区间）的都被遍历到¡注意单缺陷假设的作用，弱一般等价类测试的测试用例的个数等于max(参数1等价类个数，参数2等价类个数……参数n的等价类个数）X2abfe弱一般等价类测试用例CdgX1 强一般等价类¡强一般等价类测试基于多缺陷假设，因此测试用例的个数等于各个参数等价类个数的乘积X2abfe弱一般等价类测试用例CdgX1 弱健壮等价类测试¡这种测试的名称显然与直这种测试的名称显然与直觉矛盾，而且自相矛盾，觉矛盾，而且自相矛盾，怎么既弱而且又健壮？怎么既弱而且又健壮？¡健壮是考虑了无效值健壮是考虑了无效值¡弱是有单缺陷假设弱是有单缺陷假设1.对于有效输入，使用等价对于有效输入，使用等价类的一个值类的一个值2.对于无效输入，测试用例对于无效输入，测试用例将拥有一个无效值将拥有一个无效值X2abfe弱健壮等价类测试用例CdgX1 强健壮等价类测试¡这种测试名称既不与直觉矛盾，也不自相矛盾，只是觉得有些冗余¡健壮是指要考虑无效指¡强是指多缺陷假设¡我们从所有等价类的笛卡尔积中获得测试用例X2abfe强健壮等价类测试用例CdgX1 三角形问题的等价类测试用例¡在描述问题时，我们曾经提到过有四种可能出现的输出：非三角形，不等边三角形，等腰三角形和等边三角形。
可以使用这些输出标识如下所示的输出（值域）有效等价类（无效等价类没有列出）：¡R1={:有三条边a,b和c的等边三角形}¡R2 ={:有三条边a,b和c的等腰三角形}¡R3 ={:有三条边a,b和c的不等边三角形}¡R4={:三条边a,b和c不构成三角形} 一般等价类，弱健壮，强健壮等价类举例 NextDate问题的等价类测试¡NextDate是一个三变量函数，即月份，日期和年，这些变量的有效值区间定义如下：¡M1={月份：1≤月份≤12}¡D1={日期： 1≤日期≤31}¡Y1={年：1812 ≤年≤2012}¡无效等价类¡M2={月份：月份〈1}¡M3={月份：月份〉12}¡D2={日期：日期〈1}¡D3={日期：日期〉31}¡Y2={年：年〈1812}¡Y3={年：年〉2012} NextDate问题的等价类测试用例 NextDate问题的等价类测试(第二次)¡以上只是在有效/无效的层次上处理等价类，通过对平年和闰年的分析，日期是月末最后一天的分析，可以对有效值进行进一步区分等价类：¡M1={月份：每月有30天}¡M2={月份：每月有31天}¡M3={月份：此月是2月}¡D1={日期：1≤日期≤28}¡D2={日期：日期=29}¡D3={日期：日期=30}¡D4={日期：日期=31}¡Y1={年：年=2000}¡Y2={年：年是闰年}¡Y3={年：年是平年} NextDate问题的等价类测试用例和以前一样，机械地从对应的等价类中间选择输入，机械选择输入值不考虑领域知识，会出现不可能的输入日期，“自动”的测试用例生成永远都会有这种问题，因为领域知识不是通过等价类选择获得的。
等价类测试的总结1.等价类测试的弱形式不如强形式的测试全面2.如果输入数据以离散值区间和集合定义，则等价类测试是合适的当然也适用于如果边界值越界系统就会出现故障的系统 3.通过结合边界值测试，等价类测试可得到加强4.在发现“合适”的等价关系之前，可能需要进行多次尝试如果程序函数很复杂，则等价类是被暗示的，如NextDate函数 基于决策表的测试¡在所有功能性测试方法中，基于决策表的测试方法是最严格的，因为决策表具有逻辑严格性¡20世纪60年代初以来,决策表一直被用来表示和分析复杂逻辑关系.决策表很适合描述不同条件集合下采取行动的若干组合的情况. 使用决策表来设计测试用例¡为了使用决策表标识测试用例,我们把条件解释为输入,把行动解释为输出.(第一种方法)¡有时候条件最终引用输入的等价类,行动引用被测软件的主要功能处理部分.这时每条规则就被解释成测试用例的输入.(第二种方法)¡由于决策表可以机械地强制为完备的,因此可以生成用测试用例的完整集合 决策表的构成¡决策表有四部分：条件桩，条件条目，行动桩和行动条目¡所有条件都是二叉条件的决策表叫做有限决策表¡如果条件可以有多个值，则对应的决策表叫做扩展条目表条件桩规则1规则2规则3规则4C1C2:C3:TTTTTFTFTTFFA1xxA2xA3:xx 三角形问题决策表 ---第一种方法三角形问题决策表中，给出了不关心条目－和不可能规则不关心条目－和不可能规则使用的例子，不关心条目实际表明条件是不相关的，它代表了多条规则（如果是有限条目决策表，则规则中每出现一个不关心条目，该规则数乘一次2）不可能规则不关心条目条件桩代表测试用例的输入行动桩代表测试用例的输出每条规则标识了一个测试用例 NextDate的决策表测试用例¡前面在讲ＮextDate的等价类测试中，发现从等价类中随意地选取输入值会产生很奇怪的测试用例，如1812年6月31日的下一天。
问题的根源在于假设变量都是很独立的如果变量确实是独立的，则是用等价类的笛卡尔积是有意义的¡如果变量之间在输入定义域中存在逻辑依赖关系，则这些依赖关系在笛卡尔积中就会丢失（说抑制可能更确切）决策表格通过使用“不可能行动”概念来表示条件的不可能组合，使我们能够强调这种依赖关系¡选择NextDate函数，是因为它可以说明输入定义域中的依赖性问题，这使得这个例子成为基于决策表测试的一个完美的例子 NextDate的第一次尝试¡先考虑前面为NextDate函数划分的等价类集合¡M1={月份：每月有30天}¡M2={月份：每月有31天}¡M3={月份：此月是2月}¡D1={日期：1≤日期≤28}¡D2={日期：日期=29}¡D3={日期：日期=30}¡D4={日期：日期=31}¡Y1={年：年是闰年}¡Y2={年：年不是闰年}¡如果我如果我们希望突出不可能的希望突出不可能的组合，合，则可以建立具有以可以建立具有以下条件和行下条件和行动的的优先条目决策表先条目决策表 有256规则的第一次尝试这个决策表会有这个决策表会有256条规则，其中有很多是不可能的条规则，其中有很多是不可能的 NextDate的第二次尝试¡为了说明另一种决策表表示方法，这一次采用扩展条目决策表开为了说明另一种决策表表示方法，这一次采用扩展条目决策表开发，并更仔细地研究行动桩。
在构建扩展条目决策表时，必须保发，并更仔细地研究行动桩在构建扩展条目决策表时，必须保证等价类构成输入定义域的真划分（划分是一组不相交的子集，证等价类构成输入定义域的真划分（划分是一组不相交的子集，子集的并是全集子集的并是全集).如果规则条目之间存在如果规则条目之间存在“重叠重叠”，则会存在冗，则会存在冗余情况，使得多个规则都能够满足余情况，使得多个规则都能够满足¡为了产生给定日期的为了产生给定日期的NextDate,能够使用的操作只有五种：日期能够使用的操作只有五种：日期和月份的增和月份的增1和复位，年的增和复位，年的增1，我们不允许复位年来回退时间，我们不允许复位年来回退时间¡利用前面的年月日的等价类划分，我们可以得到利用前面的年月日的等价类划分，我们可以得到36规则的决策表规则的决策表与等价类测试时含与等价类测试时含36个测试用例的笛卡尔积对应但我们利用不个测试用例的笛卡尔积对应但我们利用不关心条目得到下表关心条目得到下表17条规则的决策表仍然有逻辑不可能的规条规则的决策表仍然有逻辑不可能的规则）则） 第二次尝试的等价类划分¡M1={月份：每月有30天}¡M2={月份：每月有31天}¡M3={月份：此月是2月}¡D1={日期：1≤日期≤28}¡D2={日期：日期=29}¡D3={日期：日期=30}¡D4={日期：日期=31}¡Y1={年：年=2000}¡Y2={年：年是闰年}¡Y3={年：年时平年} 17条规则的扩展决策表如果填满这个决策表的行动条目，如果填满这个决策表的行动条目，就会发现就会发现12月份由一些麻烦的问题。
月份由一些麻烦的问题如果是12月31日,该怎么办?每列规则识别一个测试用例规则代表测试用例的输入行动代表程序的主要处理测试用例的输出怎么办?根据规格说明和测试用例的输入计算出来 第三次尝试的等价类划分¡通过引入月份等价类的第三个集合，可以澄清年末问题¡M1={月份：每月有30天}¡M2={月份：每月有31天，12月除外}¡M3={月份：此月是12月}¡M4=={月份：此月是2月}¡D1={日期：1≤日期≤27}¡D2={日期：日期=28}¡D3={日期：日期=29}¡D4={日期：日期=30}¡D5={日期：日期=31}¡Y1={年：年是闰年}¡Y2={年：年不是闰年}¡这些等价类的笛卡尔积包含40个元素由于组合规则中包含不关心条目，最后我们得到一个22规则的决策表 22条规则的决策表上图所示决策表应该是上图所示决策表应该是NextDate函数源代码的基础，这个例子从另一函数源代码的基础，这个例子从另一方面说明测试如何能够很好地改进程序设计所有决策表分析都应该方面说明测试如何能够很好地改进程序设计所有决策表分析都应该在在NextDate函数的详细设计期间完成函数的详细设计期间完成12月31日8月31日这四条可以合并 NextDate的精简决策表 决策表测试的指导方针¡决策表技术适用于具有以下特征的应用程序：1.If then else逻辑很突出2.涉及输入变量子集的计算3.输入和输出存在复杂因果关系4.很高的圈（McCabe）复杂度(后面解释)¡决策表不能很好地伸缩（有n个条件的有限决策表有2N个规则¡与其他技术一样，多次尝试的迭代会有所帮助。
结构性测试设计¡结构性测试（又称为白盒测试）用例设计方常见的主要有以下几种[1]：¡条件测试¡基本路径测试¡循环测试¡状态机测试设计以实现测试用例对程序的逻辑覆盖，和路径覆盖：¡[1] 参见《软件工程－实践者的研究方法》第17章，323页－335页 测试覆盖种类测试覆盖种类1.语句覆盖语句覆盖：语句覆盖就是设计若干个测试用例，运行被测试程序，使得每一条可执行语句至少执行一次；2.判定覆盖（也称为分支覆盖）：判定覆盖（也称为分支覆盖）：设计若干个测试用例，运行所测程序，使程序中每个判断的取真分支和取假分支至少执行一次；3.条件覆盖条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的每个可能取值至少执行一次；4.判定判定-条件覆盖条件覆盖：设计足够多的测试用例，运行所测程序，使程序中每个判断的每个条件的所有可能取值至少执行一次，并且每个可能的判断结果也至少执行一次5.条件组合测试：条件组合测试：设计足够多的测试用例，运行所测程序，使程序中每个判断的所有可能的条件取值组合至少执行一次；6.路径测试路径测试：设计足够多的测试用例，运行所测程序，要覆盖程序中所有可能的路径。
下面以例子进行分析讲解 void DoWork(int x,int y,int z){ int k=0,j=0; if((x>3)&&(z<10)) { k=x*y-1; //语句块1 j=sqrt(k); } if((x= =4)||(y>5)) { j=x*y+10; //语句块2 } j=j%3; //语句块3} 画出前面函数的流程图如右：判断条件 语句覆盖：语句覆盖：为了说明简略，分别对各个判断的取真、取假分支编号为b、c、d、e为了测试语句覆盖率只要设计一个测试用例就可以把三个执行语句块中的语句覆盖了测试用例输入为：{ x=4、y=5、z=5}程序执行的路径是：abd该测试用例虽然覆盖了可执行语句，但并不能检查判断逻辑是否有问题，例如在第一个判断中把&&错误的写成了||，则上面的测试用例仍可以覆盖所有的执行语句可以说语句覆盖率是最弱的逻辑覆盖准则 分支覆盖分支覆盖 对于上面的程序，如果设计两个测试用例则可以满足判定覆盖的要求 测试用例的输入为：{ x=4、y=5、z=5} 程序执行路径是:abd{ x=2、y=5、z=5} 程序执行路径是:ace 上面的两个测试用例虽然能够满足分支覆盖的要求，但是也不能对判断条件进行检查，例如把第二个条件y>5错误的写成y<5,、上面的测试用例同样满足了分支覆盖。
条件覆盖条件覆盖条件覆盖就是设计若干个测试用例，运行被测试对象，使得程序中每个判断的每个条件的可能取值至少执行一次对例子中的所有条件取值加以标记例如：对于第一个判断：条件x>3 取真值为T1，取假值为-T1条件z<10 取真值为T2，取假值为-T2对于第二个判断：条件x=4 取真值为T3，取假值为-T3 条件y>5 取真值为T4，取假值为-T4 则可以设计测试用例如下 测试用例测试用例 通过路径通过路径 条件取条件取值覆盖分支覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=5 ace-T1、T2、-T3、-T4 cex=4、y=5、z=15 acdT1、-T2、T3、-T4 cd 上面的测试用例不但覆盖了所有分支的真假两个分支，而且覆盖了判断中的所有条件的可能值 但是如果设计了下面的测试用例，则虽然满足了条件覆盖，但只覆盖了第一个条件的取假分支和第二个条件的取真分支，不满足分支覆盖的要求 测试用例测试用例 通过路径通过路径 条件取条件取值覆盖分支覆盖分支x=2、y=6、z=5 acd-T1、T2、-T3、T4 cdx=4、y=5、z=5 acdT1、-T2、T3、-T4 cd 分支条件覆盖：分支条件覆盖： 分支条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行，即要求各个判断的所有可能的条件分支取值组合至少执行一次。
根据定义只需设计以下两个测试用例便可以覆盖8个条件值以及4个判断分支 测试用例测试用例 通过路通过路径径 条件取条件取值覆盖分支覆盖分支x=4、y=6、z=5 abdT1、T2、T3、T4 bdx=2、y=5、z=11ace-T1、-T2、-T3、-T4 ce 分支条件覆盖从表面来看，它测试了所有条件的取值，但是实际上某些条件掩盖了另一些条件例如对于条件表达式(x>3)&&(z<10)来说，必须两个条件都满足才能确定表达式为真如果（x>3）为假则一般的编译器不在判断是否z<10了对于第二个表达式（x= =4）||（y>5）来说，若x==4测试结果为真，就认为表达式的结果为真，这时不再检查（y>5）条件了因此，采用分支条件覆盖，逻辑表达式中的错误不一定能够查出来了 条件组合覆盖：条件组合覆盖： 条件组合覆盖就是设计足够的测试用例，运行被测试对象，使得每一个判断的所有可能的条件取值组合至少执行一次 现在对例子中的各个判断的条件取值组合加以标记如下：1.x>3,z<10 记做T1 T2， 第一个判断的取真分支2.x>3,z>=10 记做T1 -T2， 第一个判断的取假分支3.x<=3,z<0 记做-T1 T2， 第一个判断的取假分支4.x<=3,z>=10 记做-T1 -T2，第一个判断的取假分支5.x=4,y>5 记做T3 T4， 第二个判断的取真分支6.x=4,y<=5 记做T3 -T4， 第二个判断的取真分支7.x!=4,y>5 记做-T3 T4， 第二个判断的取真分支8.x!=4,y<=5 记做-T3 -T4，第二个判断的取假分支 根据定义取4个测试用例，就可以覆盖上面8种条件取值的组合。
测试用例如下表：测试用例测试用例 通过路径通过路径 条件取条件取值覆盖覆盖组合号合号x=4、、y=6、、z=5 abdT1、、T2、、T3、、T4 1和和5 x=4、、y=5、、z=15 acdT1、、-T2、、T3、、-T4 2和和6 x=2、、y=6、、z=5 acd-T1、、T2、、-T3、、T4 3和和7 x=2、、y=5、、z=15ace-T1、、-T2、、-T3、、-T4 4和和8 上面的测试用例覆盖了所有条件的可能取值的组合，覆盖了所有判断的可取分支，但是却丢失了一条路径abe 路径测试覆盖路径测试覆盖 路径测试覆盖就是设计足够多的测试用例，覆盖被测试对象中的所有可能路径 在上面的测试用例中再添加一个测试用例则可对程序进行了全部的路径覆盖 测试用例测试用例 通过路径通过路径 覆盖条件覆盖条件 X=5、、y=6、、z=5 abe T1、、T2、、-T3、、T4 基本路径测试基本路径测试上面的例子是一个很简单的程序函数，只有四条路径但在实践中，一个不太复杂的程序，其路径都是一个庞大的数字，要在测试中覆盖所有的路径是不现实的为了解决这一难题，只得把覆盖的路径数压缩到一定限度内，例如，程序中的循环体只执行一次。
下面介绍的基本路径测试就是这样一种测试方法，它在程序控制图的基础上，通过分析控制构造的圈复杂度，导出基本独立路径集合，从而设计测试用例的方法设计出的测试用例要保证在测试中程序的每一个基本独立路径至少执行一次 在程序控制流图的基础上，通过分析控制构造的环路复杂性，导出基本可执行路径集合，从而设计测试用例包括以下4个步骤和一个工具方法：1.画出程序的控制流图：描述程序控制流的一种图示方法2.计算程序圈复杂度：McCabe复杂性度量从程序的环路复杂性可导出程序基本路径集合中的独立路径最大条数，这是确定程序中每个可执行语句至少执行一次所必须的测试用例数目的上界上界3.导出基本独立路径：根据圈复杂度和程序结构设计用例数据输入和预期结果4.准备测试用例：确保基本路径集中的每一条路径的执行 先讲一下控制流图的符号先讲一下控制流图的符号 在介绍基本路径方法之前，必须先介绍一种简单的控制流表示方法，即流图流图使用下面的符号描述逻辑控制流，每一种结构化构成元素有一个相应的流图符号 例子如下面的C函数：int Sort(int iRecordNum,int iType)1 { 2 int x=0;3 int y=0;4 while (iRecordNum-- > 0)5 {6 if(0= =iType){7 x=y+2; break } else8 if(1= =iType)9 x=y+10; else12 x=y+20;13 }14 Reutrn x;} 第一步：画出控制流图第一步：画出控制流图流图中的每一个圆称为流图的结点，代表一条或多条语句。
流图中的箭头称为边或连接，代表控制流为了说明流图的用法，我们采用过程设计表示法，此处，流程图用来描述程序控制结构可将流程图映射到一个相应的流图(假设流程图的菱形决定框中不包含复合条件)在流图中，每一个圆，称为流图的结点，代表一个或多个语句一个处理方框序列和一个菱形决测框可被映射为一个结点，流图中的箭头，称为边或连接，代表控制流，类似于流程图中的箭头一条边必须终止于一个结点，即使该结点并不代表任何语句(例如：参见if-else-then结构的符号)由边和结点限定的范围称为区域计算区域时应包括图外部的范围任何过程设计都要被翻译成控制流图 画出其程序流程图和对应的控制流图如下：图2(a)流程图图2(b) 流图 第二步：计算圈复杂度第二步：计算圈复杂度 圈复杂度是一种为程序逻辑复杂性提供定量测度的软件度量，将该度量用于计算程序的基本的独立路径数目，为确保所有语句至少执行一次的测试数量的上界独立路径必须包含一条在定义之前不曾用到的边 有以下三种方法计算圈复杂度：1.流图中区域的数量对应于环型的复杂性；2.给定流图G的圈复杂度－V(G)，定义为V(G)=E-N+2，E是流图中边的数量，N是流图中结点的数量；3.给定流图G的圈复杂度－V(G)，定义为V(G)=P+1，P是流图G中判定结点的数量。
对应上面图中的圈复杂度，计算如下：ü流图中有四个区域；üV(G)=10条边-8结点+2=4;üV(G)=3个判定结点+1=4 第三步：导出基本独立路径第三步：导出基本独立路径 根据上面的计算方法，可得出四个独立的路径：ü路径1：4-14ü路径2：4-6-7-14ü路径3：4-6-8-10-13-4-14ü路径4：4-6-8-11-13-4-14根据上面的独立路径，去设计输入数据，使程序分别执行到上面四条路径 第四步：准备测试用例第四步：准备测试用例为了确保基本路径集中的每一条路径的执行，根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到，满足上面例子基本路径集的测试用例是：路径1：4-14输入数据：iRecordNum＝0，或者取iRecordNum<0的某一个值预期结果：x＝0路径2：4-6-7-14输入数据：iRecordNum＝1,iType＝0预期结果：x＝2路径3：4-6-8-10-13-4-14输入数据：iRecordNum＝1,iType＝1预期结果：x＝10路径4：4-6-8-11-13-4-14输入数据：iRecordNum＝1,iType＝2预期结果：x＝20这里的预期输出有问题,应该是从程序的规格说明导出,不应该从程序的结构中导出 循环测试循环测试 循环测试是一种白盒测试技术，注重于循环构造的有效性。
有四种循环：简单循环，串接循环，嵌套循环和不规则循环简单循环嵌套循环串接循环不规则循环 简单循环： 下列测试集用于简单循环，其中n是允许通过循环的最大次数Ø整个跳过循环；Ø只有一次通过循环；Ø两次通过循环；Øm次通过循环，其中m
测试时要把时间事件作为信号事件激励到状态机对象上 状态机的基本概念--转换Ø转换到自身Ø防护将同一状态上同一事件触发的多个转换隔开 状态机的基本概念--动作和活动动作：在状态机的某个特殊点，执行不可中断地行为，该行为被认为不需要花费什么时间(take a non-significant amount of time )一个动作也可以是作为一个整体不能被中断的一串动作活动：活动需要花费一些时间，因而可以被中断因此只能在状态中定义活动开始到带”是一个动作；“到带”是一个活动 状态机的基本概念--动作和活动许多协议和应用模块需要建立TCP链接，维护PEER状态机PEER状态机一般以noinfo状态作为初始状态，tcp链接链接后到达TCP-CONNECTED状态那么“建立TCP链接”是一个“动作”，还是一个“活动”呢？如果工作于“阻塞”模式，TCP建立完成前模块不响应其他事件，则“建立TCP链接”是一个动作；否则“建立TCP链接”就应该是一个活动，二者状态机不同 状态机的基本概念---嵌套状态汽车收音机的状态图，其中超状态开启由两个正交区域组成 事件触发动作的执行顺序B状态和D状态是A状态的子状态；C状态是B状态的子状态。
t1事件：w、(x,y)、zt2事件：p、n、mt3事件：p、n、g、st4事件：q、s动作是按照一定的顺序来执行的首先执行的是接受状态的出口标记中定义的动作，接下来是指向转换的动作，最后是结果状态的入口标记中定义的动作 许多嵌入式系统或GUI程序全部或部分表现出基于状态的行为当设计这些系统时，可以使用基于状态的建模从基于状态的模型中可以导出测试用例基于状态的测试设计技术目标是验证事件、动作、验证事件、动作、行为与状态转换之间的关系行为与状态转换之间的关系通过使用这种技术，人们就可以判断系统基于状态的行为是否满足系统的规范集合状态转换测试目的 状态机设计、编码中可能出现缺陷原因分类基于状态的行为出现错误可能有三种原因第一：状态图无法表示系统功能规范的正确转换基于状态的测试设计技术不能够揭示这些故障类型，因为状态图本身被用作测试的基础第二：状态图的语法不正确或不一致可以通过静态分析和评审来发现这些故障（例如通过使用审查清单或工具），如果解决了发现的故障，那么就可以使用基于状态的测试设计技术，使这个状态图成为动态测试的基础第三：从状态图到代码的转换现在已经出现了自动转换的工具，如果这个转换过程是自动实现的，生成的代码将是状态图的准确的表示，那么就没有必要再采用基于状态的测试设计技术。
基于状态的测试设计技术适用于手工编码实现状态机的场合 状态图和软件中可能发生的故障：状态1.1 没有进入转换的状态规范和/或实现故障）1.2 遗漏初始状态必须定义状态图中的所有路径当转换到一个没有给出最终子状态的超状态时，超状态必须包含一个初始状态如果没有给出初始状态，那么就无法预测转换是在何处终止规范和/或实现故障）1.3 额外状态系统生成比状态图中多的状态实现故障）1.4 遗漏状态系统中没有出现状态图中给出的状态实现故障）1.5 破坏性状态转换到无效态而导致系统崩溃实现故障） 状态图和软件中可能发生的故障：防护2.1 防护必须指向转换而不是状态规范故障）2.2 完成事件转换上的防护，如果防护被评估为false，那么系统会陷入死锁规范和/或实现故障）2.3 初始转换上的防护初始转换上不能有防护规范和/或实现故障）2.4 重叠防护在这种情况下，无法确定系统将转换到哪种状态规范和/或实现故障）2.5 防护为false但仍然有转换发生，系统将达到一个预期之外的最终状态实现故障）2.6 错误的防护实现有些条件下，这将导致预期之外的系统行为实现故障） 状态图和软件中可能发生的故障：转换3.1 转换必须有一个接收状态与一个最终状态。
规范和/或实现故障）3.2 相互矛盾的转换一个事件触发系统从一个子状态改变为另一个子状态，而同时又触发超状态之外的一个转换，这实际上将导致不再能够转换到某个子状态（规范和/或实现故障）3.3 遗漏或错误转换最终的状态既不正确，也没有被破坏（规范和/或实现故障）3.4 遗漏或错误动作执行转换时执行了错误的动作规范和/或实现故障） 状态图和软件中可能发生的故障：事件4.1 遗漏事件事件被忽略规范和/或实现故障）4.2 隐含路径系统对一个定义的事件作出响应，但状态图中没有定义这个响应（也被称为“潜路径”）（实现故障）4.3 对一个没有定义的事件作出响应（也被称为“后门”）实现故障） 状态机错误类型的检查单 状态转换测试技术状态转换测试技术(STT)由以下步骤组成ü编写状态-事件表ü编写转换树ü编写合法路径测试用例的测试脚本ü编写非法事件测试用例的测试脚本ü编写防护测试脚本 录音机的状态图 录音机的状态-事件表 编写录音机的状态转换树第一层：初始状态第二层：初始状态经过一次转换可以到达的状态第n层：从第n-1层经过一次转换可以到达的状态叶子：如果某一层的节点（状态）在以前的某层出现过，则这个节点不必再分解下去，成为叶子 编写合法路径测试用例借助于转换树与状态-事件表，可以创建一个只覆盖合法测试路径的测试用例集。
转换树上的每一个路径都是一个测试用例，这个测试用例覆盖整个路径，直到叶子，并从叶子返回初始状态（如果可能的话），以便下一个测试用例的执行也就是说，要想测试用例能够连续执行，每一个状态都必须有一个回到初始状态的路径 编写合法路径测试用例(续) 编写合法路径测试用例(续)输入输出ID事件防护动作状态L1.1 evRewindbuttonTape exists, tape not at the beginningStartRewind RewindL1.2 evPlaybuttonStopRewindStartPlayPlayL1.3 evStopbuttonStopPlayStandby到达叶子回到初始状态注意：这个测试用例的三个输入在不同时间点按顺序输入，输出也是 编写非法事件测试用例可以从状态-事件表中得到非法的状态-事件组合非法的状态-事件组合是指当在特定状态时，系统没有指定要对该事件做出响应因而，所有非法事件测试用例的预期结果，应当是系统对此不作出响应注意：不应当将非法事件测试用例与系统中明确指出不对某个事件作出实质响应，而只是输出一个错误消息的测试用例相混淆 编写非法事件测试脚本(续) 编写防护测试脚本l如果防护由一个带有边界值得条件组成，那么需要对该防护进行边界值分析。
对每一个防护，要从边界值左边和右边两个方向来应用边界条件和测试用例l如果防护由一个复杂的条件组成，那么就要使用决策表（见功能性测试设计部分）的方法来覆盖测试针对防护条件而设计的补充测试用例如下图所示 编写防护测试脚本(续) Petri网定义¡Petri网是一种双向有向图(P,T,In,Out),其中,P和T是不相交的节点集合¡P我们通常称为地点（places)集合¡T我们通常称为转移（Transition)集合¡In和Out是边的集合.üP={ p1,p2,p3,p4,p5}üT={t1,t2,t3}üIn={,,,,üOut={,,} Petri网例子 有标记的Petri网¡定义¡有标记的Petri网是一种5元组（P，T，In，Out，M)，其中（P，T，In，Out）是个Petri网，M是地点到正整数的映射集合¡M中的元素是个n元组，其中n是集合P中的地点个数对于右图所示的Petri网，集合M包含形式为,其中ni是与相应地点P有关的整数，整数的值表明在这个地点中的令牌（token）的个数¡右图所示的有标记的Petri网的标记元组M是<1,1,0,2,0> Petri网的转移¡定义2¡转移可以在Petri网中发生，如果在其所有输入地点中至少有一个记号¡定义3¡当触发Petri网一个转移时，要从其每个输入地点删除一个令牌（Token),并在每个转移进的地点增加一个令牌（Token)¡右上图显示了t2转移发生后，Petri网中令牌的变化转移前转移后 事件驱动的Petri网¡定义¡EDPN是一种多向图（P，D，S，In，Out），包括三个节点集合P，D和S，以及两个映射集合In和Out。
其中：ØP是事件地点的集合ØD是数据地点的集合ØS是转移的集合ØIn是（PUD）×S的有序对偶集合ØOut是S×（P∪D）的有序对偶集合¡定义¡EDPN（P，D，S，In，Out）的一个标记M，是p元组的一个序列,其中p=k+n，k和n是集合P和D中的元素个数，p元组中的个体项mi 表示事件或数据地点中的记号个数¡每个标记M对应Petri网络的一个执行 EDPN的例子事件地点数据地点 将状态机转换成EPDN¡将状态机中的状态当做“数据地点”¡将状态机中的转换当做“转移”¡将状态机中的转换上的输入事件作为“输入事件地点”，用正三角形表示，将转换上的动作作为“输出事件地点”，用倒三角形表示¡Petri网中边的方向规定如下：1.边从表示“接受状态”的“数据地点”和“输入事件”的“事件地点”出发，结束于“转移”2.边从表示“转移”出发，结束于表示“结果状态”的数据地点和“输出事件”的事件地点 EDPN的执行过程EDPN中的一个标记元组(p3,p4,d5,d6,d7)描述m1(0,0,1,0,0)没有允许发生的转移m2(1,0,1,0,0)S7允许发生，s7被触发m3(0,0,0,1,0)没有允许发生的转移m4(1,0,0,1,0)S8允许发生，s8被触发m5(0,0,0,0,1)没有允许发生的转移m6(0,1,0,0,1)S9允许发生，s9被触发m7(0,0,0,1,0)没有允许发生的转移EDPN中的一个标记元组(p3,p4,d5,d6,d7)描述m1(0,0,1,0,0)(初始条件,处于状态d5)m2(1,0,1,0,0)p3发生m3(0,0,0,1,0)处于状态d6m4(1,0,0,1,0)p3发生m5(0,0,0,0,1)处于状态d7m6(0,1,0,0,1)p4发生m7(0,0,0,1,0)处于状态d6 例子：土星牌挡风玻璃雨刷¡ 某些土星牌汽车的挡风玻璃雨刷是由带刻度的控制杆控制的。
这种控制杆有四个位置：停止，间歇，低速和高速；刻度盘位置有三个位置，分别是数字1，2和3刻度盘指示三种间歇速度，刻度盘的位置只有当控制杆在间歇位置上时才有意义¡下图的决策表给出了挡风雨刷对应控制杆和刻度盘的工作速度c1:c1:控制杆控制杆停止停止间歇间歇间歇间歇间歇间歇低速低速高速高速c2:c2:刻度盘刻度盘——1 12 23 3————a1:a1:雨刷雨刷0 04 46 6121230306060 土星牌挡风玻璃雨刷的输入和输出事件输出事件描述p5雨刷提供每分钟0次摆动p6雨刷提供每分钟6次摆动p7雨刷提供每分钟12次摆动p8雨刷每分钟20次摆动p9雨刷提供每分钟30次摆动p10雨刷每分钟60次摆动输入事件描述p1控制杆上移一个位置p2控制杆下移一个位置p3刻度盘上移一个位置p4刻度盘下移一个位置 土星牌挡风玻璃雨刷的状态和转移状态描述d1控制杆位于“关"d2控制杆位于“间歇”d3控制杆位于“低速”d4控制杆位于“高速”d5刻度盘位于1d6刻度盘位于2d7 刻度盘位于3转移描述s1“关”到“间歇”的转移s2“间歇”到“低速”的转移s3“低速”到“高速”的转移s4“高速”到“低速”的转移s5“低速”到“间歇”的转移s61到2的转移s72到3的转移s83到2的转移s92到1的转移 控制杆的状态机和EDPN 刻度盘的状态机和EDPN 档风玻璃雨刷系统的EDPN 档风玻璃雨刷系统的EDPN的样本1场景md1d2d3d4d5d6d7p1p2p3p4p5p6p7p8p9p10描述01 1 关,111 1 1 控制杆上移,s1开放2 1 1 s1触发,s11开放3 1 1 1 s11触发,s11开放4 1 1 1 1 控制杆上移,s2和s11开放5 1 1 1 s2触发6 1 1 刻度盘上移,s7开放7 1 1 s7触发8 1 1 1 控制杆下移,s5开放9 1 1 s5触发,s12开放10 1 1 1 s12触发11 1 1 1 控制杆下移,s6开放121 1 1 s6触发 样本2场景中的并行行为 时间0123456789101112控制杆数据地点d1d1 d2d2 d3d3d3d3 d2 转移 s1 s2 输入事件 p1 p1 p2 输出事件 p9p9p9p9p9p9 刻度盘数据地点d5d5d5d5d5d5d5d5 d6d6d6d6 转移 s7 输入事件 p3 输出事件 雨刷数据地点 转移 输入事件 输出事件 p6p6p6 p7 如何使用EPDN来进行测试设计¡EPDN是一张有向图,就如同状态机和程序流图一样，所以EPDN对测试设计的意义就在于对图的覆盖上（节点或边）。
¡可以将EPDN转换成状态机,采用状态转换测试设计的方法,遍历所有可能的状态转换¡可以采用类似基路径测试的方法，遍历Petri网中所有的节点 面向对象的单元测试设计面向对象的单元测试设计对OO软件的类测试相当于传统软件的单元测试和传统软件的单元测试不同，他往往关注模块的算法细节和模块接口间流动的数据，OO软件的类测试是由封装在类中的操作和类的状态行为所驱动的OO软件测试的特点：l因为属性和操作是被封装的，对类之外操作的测试通常是徒劳的封装使对对象的状态快照难于获得l继承也给测试带来了难度，即使是彻底复用的，对每个新的使用语境也需要重新测试l多重继承更增加了需要测试的语境的数量，使测试进一步复杂化如果从超类导出的测试用例被用于相同的问题域，有可能对超类导出的测试用例集可以用于子类的测试，然而，如果子类被用于完全不同的语境，则超类的测试用例将没有多大用途，必须设计新的测试用例集 类测试一般有两种主要的方式： 功能性测试和结构性测试，即对应于传统结构化软件的黑盒测试和白盒测试功能性测试以类的规格说明为基础，它主要检查类是否符合其规格说明的要求例如，对于Stack类，即检查它的操作是否满足LIFO规则；结构性测试则从程序出发，它需要考虑其中的代码是否正确，同样是Stack类，就要检查其中代码是否动作正确且至少执行过一次。
面向对象的单元测试设计面向对象的单元测试设计 面向对象的单元白盒测试面向对象的单元白盒测试策略策略 结构性测试对类中的方法进行测试，它把类作为一个单元来进行测试测试分为两层：第一层考虑类中各独立方法的代码，即方法的单独测试第二层考虑方法之间的相互作用，即方法之间的综合测试每个方法的测试要求能针对其所有的输入情况，但这样还不够，只有对这些方法之间的接口也做同样测试，才能认为测试是完整的对于一个类的测试要保证类在其状态的代表集上能够正确工作，构造函数的参数选择以及消息序列的选择都要满足这一准则因此，在这两个不同的测试层次上应分别做到： l方法的单独测试：结构性测试的第一层是考虑各独立的方法，这可以与过程的测试采用同样的方法，两者之间最大的差别在于方法改变了它所在实例的状态，这就要取得隐藏的状态信息来估算测试的结果，传给其它对象的消息被忽略，而以桩来代替，并根据所传的消息返回相应的值，测试数据要求能完全覆盖类中代码，可以用传统的测试技术来获取l方法的综合测试：第二层要考虑一个方法调用本对象类中的其它方法和从一个类向其它类发送信息的情况单独测试一个方法时，只考虑其本身执行的情况。
而没有考虑动作的顺序问题，测试用例中加入了激发这些调用的信息，以检查它们是否正确运行了对于同一类中方法之间的调用，一般只需要极少甚至不用附加数据，因为方法都是对类进行存取，故这一类测试的准则是要求遍历类的所有主要状态面向对象的单元白盒测试策略面向对象的单元白盒测试策略 类方法的综合测试用例设计-随机测试 ¡为了提供随机测试方法的简略性举例，考虑一个银行应用，其中account类有下列操作：open，setup，deposit，withdraw balance，summarize，creditLimit和close[1] P460-461，这些操作的每一个均可应用于account，但是，问题的性质隐含了一些限制（例如，帐号必须在其他操作可应用前被打开，在所有操作完成后被关闭）即使有了这些限制，还是存在操作的很多排列一个account实例的最小的行为生命历史包括下面操作：¡open•Setup•deposit•withdraw•close¡这表示了account的最小测试序列，然而，大量的其他行为可能在下面序列中发生：¡open•setup•deposit•[deposit|withdraw|balance|summarize|creditiLimit]n•withdraw•close¡一系列不同的操作序列可以随机产生，例如：¡测试用例r1：open•setup•deposit•deposit•balance•summarize•withdraw•close¡测试用例r2：open•setup•deposit•withdraw•deposit•balance•creditLimit•withdraw•close¡这些和其他的随机顺序测试被进行以测试不同的类实例生命历史。
¡随机测试的可能排列的数量可能增长非常大可以使用类划分测试来改善测试效果 类方法的综合测试用例设计-划分测试¡测试划分测试划分（paritition testing）可以减少测试类所需的测试用例的数量，采用的是基本于传统软件的等价划分[1]P318类似的方式：输入和输出被分类，并且测试用例被设计以处理每个类别类的等价划分测试有如下几种：¡基于状态的划分基于状态的划分基于类的操作改变类状态的能力来对类操作分类，再次考虑account类，状态操作包括deposit和withdraw，而非状态操作包括balance、summarize和creditLimit测试被以这样一种分别独立测试改变状态的操作和那些不改变状态的操作的方式来设计，因此，¡测试用例p1：open•setup•deposit•deposit•withdraw•withdraw•close¡测试用例p2：open•setup•deposit•summarize•creditLimit•withdraw•close¡测试用例p1改变状态，而测试用例p2测试不改变状态的操作（除了那些在最小测试序列中的操作）¡基于属性的划分基于属性的划分基于它们使用的属性来对类操作分类，对accout类，属性balance和creditLimit可被用于定义划分，操作被分为三个类别：（1）使用creditLimit的操作，（2）修改creditLimit的操作，（3）不使用和修改creditLimitde操作。
然后对每个划分设计测试序列¡基于类别的划分基于类别的划分基于各自完成的类属函数来对类操作分类，例如，在accout类中的操作可被分类为初始化操作（open、setup）、计算操作（deposit、withdraw）、查询操作（balance、summarize、creditLimit）和终止操作（close） 类方法综合测试用例设计-类状态测试¡状态－转换图（STD）是作为表示类的动态行为的模型[1]P408类的STD可被用于帮助导出测试类（和那些与其协作的类）的动态行为的测试序列右图给出了前面讨论的account类的STD¡根据该图，初始变迁经过了empty acct和setup acct状态，类的实例的大多数行为发生在working acct状态，最终的withdrawal和close使得account类分别向nonworking acct和dead acct状态发生变迁¡设计的测试用例集应该使类的所有可能状态达到完全的覆盖[1]P462，即应用于测试的操作序列应该导致accout类的变迁穿越所有允许的状态¡测试用例s1：open•setupAccnt•deposit(initial)•withdraw(final)•close应该注意，该序列等同于8.1.1小节讨论的最小测试序列，加入其他测试序列得到最小序列中：¡测试用例s2：open•setupAccnt•deposit(initial)•deposot•balance•credit•withdraw(final)•close¡测试用例s3：open•setupAccnt•deposit(initial)• deposit •withdraw• accntInfo• withdraw(final) •close¡更多的测试用例可以被识别以保证类的所有行为已经被适当地测试，在类行为导致与一个或多个类协作的情况下，可能多个STD被用于跟踪系统的行为流。
¡状态转换图可以按“宽度优先的方式”遍历[1]P463，在语境内，宽度优先隐含了某测试用例测试单个变迁，并且当新的变迁将被测试时，仅以前测试过的变迁被使用 类集成测试用例设计-多个类随机测试 ¡Kirani和Tsai[KIR94][1]P462 建议了下面的步骤序列以生成一组多个类随机测试用例：¡1. 对每个客户类，使用类操作列表来生成一系列随机测试序列，操作将发送消息给其它服务器类¡2. 对生成的每个消息，确定在服务器对象中的协作者类和对应的操作¡3. 对服务器对象中的每个操作（已经被来自客户对象的消息调用），确定它发送的消息¡4. 对每个消息，确定下一层被调用的操作并结合这些操作到测试序列中¡为了说明[KIR94][1]P462，考虑bank类相对于ATM类的（下图）的操作序列：¡verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|accInfoReq]n¡Bank类的随机测试用例可能是：¡测试用例r3：verifyAcct•verifyPIN•depositReq¡为了考虑涉及该测试的协作者，和在测试用例r3中提到的每个操作关联的消息被考虑，bank必须和validationInfo协作以执行verifyAcct和verifyPIN，bank必须和account协作以执行depositReq，因此，测试上面提到的协作的新的测试用例是：¡测试用例r4：verifyAcctbank • [validAcctvalidationInfo] • verifyPINbank• [validPINvalidationInfo] • depositReqbank • [depositaccount] 基于消息路径（MM）的测试¡这里我们定义消息是一种程序设计语言机制，通过这种机制一个单元将CPU控制权转移给另一个单元。
面向对象软中的MM路径是由消息连接起来的方法路径我们再定义原子系统功能(ASF)是一种MM路径，它从一个系统（端口）输入事件开始一直到系统（端口）输出事件为止¡ASF概念描述了面向对象软件的事件驱动性质：开始系统是静止的，当一个ASF的系统级输入事件来到时，会触发系统的某个MM路径，即方法--消息序列，这个序列可能会触发其他的MM-路径，直到最终MM路径序列以某个端口事件结束，这时这个ASF也就结束了系统又恢复到静止的状态，等待另一个启动系统的ASF（端口）输入事件¡我们可以基于ASF/MM这两个基本概念，为由OO软件的若干个类构成的软件子系统识别类间集成测试用例UML的时序图为有效识别MM路径和ASF提供了很好的支持 。