软件测试课件

第10章 软件测试第10章软件测试2/130第10章 软件测试10.1软件测试基础10.2白盒测试10.3黑盒测试10.4测试策略10.5面向对象测试10.6测试完成的标准10.7调试2/130第10章软件测试10.1软件测试基础10.23/130教学目的与要求掌握软件测试的目的、基本原则、测试方法；熟练掌握白盒测试、黑盒测试及测试用例的设计;掌握单元测试、集成测试、确认测试、系统测试等测试策略；4.了解面向对象测试的基本内容；理解测试完成标准；掌握调试的概念及调试方法。3/130教学目的与要求掌握软件测试的目的、基本原则、测试4/130教学重点教学重点软件测试的目的、基本原则；白盒测试、黑盒测试及测试用例的设计;测试策略。教学难点教学难点白盒测试、黑盒测试及测试用例的设计;面向对象测试的基本内容。教学学时教学学时 5学时4/130教学重点软件测试的目的、基本原则；白盒测试5/130教学方法教学方法采用多媒体课件+讲授法+启发式相结合教学教学参考文献教学参考文献软件工程导论(第五版),张海藩，清华大学出版社软件工程(第二版),齐治昌，高等教育出版社软件测试教程,宫云战，机械工业出版社软件测试技术概论,古乐，清华大学出版社软件性能测试与LoadRunner实战，于涌，人民邮电出版社5/130教学方法采用多媒体课件+讲授法+启发式相结合教学6/13010.1软件测试基础一、软件测试的目的测试是一个为了发现错误而执行程序的过程一个好的测试用例是指很可能找到迄今为至尚未发现的错误的测试用例一个成功的测试是指揭示了迄今为至尚未发现的错误的测试 根据这个测试目的，应该排除对测试的错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。6/13010.1软件测试基础一、软件测试的目的测试是一7/130有关软件测试的错误观点 “软件测试是为了证明程序是正确的，即测试能发现程序中所有的错误”。事实上这是不可能的。要通过测试发现程序中的所有错误，就要穷举所有可能的输入数据。例：程序P有两个整型输入量 X、Y，输出量为Z，在32位机上运行。所有的测试数据组（Xi，Yi）的数目为：232232=264，1毫秒执行1次，共需5亿年。PXYZ7/130有关软件测试的错误观点“软件测试是为了证明8/130“程序测试是证明程序正确地执行了预期的功能”。实际上，一个程序不仅要完成它所需完成的功能，而且不应完成它不该做的事。如不能把边长为0、0、0的三条边判断为等边三角形。8/130“程序测试是证明程序正确地执行了预期9/130二、软件测试的原则Davis提出了一组指导软件测试的基本原则：1.所有的测试都应可追溯到客户需求2.应在测试工作开始前的较长时间就进行测试计划3.Pareto原则：测试中发现的80%的错误可能来自于20%的程序代码4.测试应从“小规模”开始，逐步转向“大规模”5.穷举测试是不可能的6.为达到最有效的测试，应由独立的第三方来承担测试9/130二、软件测试的原则Davis提出了一组指导软件测试10/130其他的测试原则：1.在设计测试用例时，应包括合理的输入条件和不合理的输入条件2.严格执行测试计划，排除测试的随意性3.应当对每一个测试结果做全面检查4.妥善保存测试计划、测试用例、出错统计和最终分析报告，为维护提供方便5.检查程序是否做了应做的事仅是成功的一半，另一半是检查程序是否做了不该做的事6.在规划测试时不要设想程序中不会查出错误10/130其他的测试原则：11/130三、软件测试方法软件测试方法1.静态分析方法指以人工的、非形式化的方法对程序进行分析和测试。主要形式：审查、评审和走查。静态分析动态测试11/130三、软件测试方法软件测试方法1.静态分析方法静态12/130评审（Review）评审是由若干开发人员、项目经理、测试人员、用户或领域专家等组成一个会审小组，通过阅读、讨论和争议，对工作制品进行静态分析的过程。类型：需求评审、设计评审和代码评审。评审过程小组负责人先把需求规格说明、设计说明或程序代码及有关要求、规范等分发给小组成员，作评审依据；在充分阅读有关材料后召开评审会议，主要开发人员进行讲解，其他成员提出问题并展开讨论，审查是否存在错误；评审小组形成产品评审的书面报告。12/130评审（Review）评审是由若干开13/130走查（Walkthrough）走查是由设计人员或编程人员组成一个走查小组，通过阅读一段文档或代码，并进行提问和讨论，从而发现可能存在的缺陷、遗漏和矛盾的地方。类型：设计走查、代码走查。走查过程与评审过程类似，即先把材料先发给走查小组每个成员，让他们认真研究程序，然后再开会；与评审的区别：评审通常是简单地读程序或对照错误检查表进行检查；走查则是按照所提交的测试用例，人工模仿计算机运行一遍，并记录跟踪情况。13/130走查（Walkthrough）走查14/130 无论Y为何值，都不能够调用子程序。READYY0NX:=YX1)and(B=0)then X:=X/A;if(A=2)or (X1)then X:=X+1 end;该子程序接受A、B、X的值，并将计算结果x的值返回给调用程序。与该子程序对应的流程图如下：22/130例：对下列子程序进行测试23/130入口s(A1)and(B=0)a(A=2)or(x1)c返回ebx=x/Aftdx=x+1ft23/130入口s(A1)and(B=0)a(A=2)24/130语句覆盖语句覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个可执行语句都至少执行一次。欲使每个语句都执行一次，只需执行路径L1（sabcde）即可。测试用例如下：测试数据预期结果x=4,A=2,B=0 x=3seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)24/130语句覆盖语句覆盖是指选择足够的测试用例25/130判定覆盖判定覆盖（也称分支覆盖）是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次（即判定的每个分支至少经过一次）判定覆盖将每个判定的所有可能结果都至少执行一次，所以，程序中的所有语句也必定都至少执行一次。因此，满足判定覆盖标准的测试用例也一定满足语句覆盖标准。25/130判定覆盖判定覆盖（也称分支覆盖）是26/130欲使每个分支都执行一次，只需执行路径L3（sacde）和L4（sabce）即可。或者，执行路径L1（sabcde）和L2（sace）.seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)测试数据预期结果路径acx=1,A=2,B=1x=2sacdeftx=3,A=3,B=0 x=1sabcetf26/130欲使每个分支都执行一次，只需执行27/130条件覆盖条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中的每个条件的所有可能结果都至少出现一次。27/130条件覆盖条件覆盖是指选择足够的测试28/130判定a中各种条件的所有可能结果：A1，A1，B=0，B0。判定c中各种条件的所有可能结果：A=2，A2，x1，x1。seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)测试数据预期结果路径覆盖的条件x=1,A=2,B=0 x=1.5sabcdeA1，B=0，A=2,x=1x=2,A=1,B=1x=3sacdeA A 1 1，BB 0 0，B B 2 2，x1x128/130判定a中各种条件的所有可能结果：A1，A29/130条件覆盖通常比判定覆盖强，但有时虽然每个条件的所有可能结果都出现过，但判定表达式的某些可能结果并未出现。上面的二个测试用例满足了条件覆盖标准，但判定c为“假”的结果并未出现。29/130条件覆盖通常比判定覆盖强，但有时虽30/130判定/条件覆盖判定/条件覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定的所有可能结果都至少执行一次，并且，每个判定中的每个条件的所有可能结果都至少出现一次。显然，满足判定/条件覆盖标准的测试用例一定也满足判定覆盖、条件覆盖、语句覆盖标准。30/130判定/条件覆盖判定/条件覆盖是指选31/130seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)测试数据预期结果路径ac覆盖的条件x=4,A=2,B=0 x=3sabcdettA1，B=0，A=2，x=4x=1,A=1,B=1x=1saceffA A 1 1，BB 0 0，AA 2 2，x1131/130seacbdtffta:(A1)测试数据预期32/130条件组合覆盖条件组合覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每个判定中条件结果的所有可能组合都至少出现一次显然，满足条件组合覆盖标准的测试用例一定也满足判定覆盖、条件覆盖、判定/条件覆盖、语句覆盖标准。32/130条件组合覆盖条件组合覆盖是指选择足33/130判定a中条件结果的所有可能组合：A1，B=0;A1，B0;A1，B=0;A1，B0判定c中条件结果的所有可能组合：A=2，x1;A=2，x1;A2，x1;A2，x1seacbdtffta:(y1)and(z=0)c:(y=2)or(x1)33/130判定a中条件结果的所有可能组合：seacbdtf34/130测试数据测试数据预期预期结果结果路径路径ac覆盖的条件覆盖的条件x=4,A=2,B=0 x=3sabcdettA1，B=0 A=2，x=4x=1,A=2,B=1x=2sacdeftA1，B 0A=2，x 1x=2,A=1,B=0 x=3sacdeftA1，B=0 A2，x1x=1,A=1,B=1x=1saceffA1，B0A 2，x1seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)34/130测试数据预期结果路径ac覆盖的条件x=4,A=235/130条件组合覆盖是上述五种覆盖标准中最强的一种，然而，条件组合覆盖仍不能保证程序中所有可能的路径都被覆盖。本例中，满足条件组合覆盖标准的测试用例就没有经过sabce路径。35/130条件组合覆盖是上述五种覆盖36/130路径覆盖路径覆盖是指选择足够的测试用例，使得运行这些测试用例时，被测程序的每条可能执行到的路径都至少经过一次（如果程序中包含环路，则要求每条环路至少经过一次）。36/130路径覆盖路径覆盖是指选择足够的测试37/130本例中所有可能执行的路径有：L1(sabcde，a为“t”且c为“t”)L2(sace，a为“f”且c为“f”)L3(sacde，a为“f”且c为“t”)L4(sabce，a为“t”且c为“f”)seacbdtffta:(A1)and(B=0)c:(A=2)or(x1)测试数据测试数据预期结果预期结果路径路径acx=4,A=2,B=0 x=3sabcdettx=3,A=3,B=0 x=1sabcetfx=2,A=1,B=0 x=3sacdeftx=1,A=1,B=1x=1saceff37/130本例中所有可能执行的路径有：seacbdtfft38/130路径覆盖实际上考虑了程序中各种判定结果的所有可能组合，但它未必能覆盖判定中条件结果的各种可能情况。因此，它是一种比较强的覆盖标准，但不能替代条件覆盖和条件组合覆盖标准。38/130路径覆盖实际上考虑了程序中各种判定39/130基本路径测试在实际问题中，一个不太复杂的程序，特别是包含循环的程序，其路径数可能非常大。因此测试常常难以做到覆盖程序中的所有路径，为此，希望把测试的程序路径数压缩到一定的范围内。基本路径测试是TomMcCabe提出的一种白盒测试技术，这种方法首先根据程序或设计图画出控制流图，并计算其区域数，然后确定一组独立的程序执行路径（称为基本路径），最后为每一条基本路径设计一个测试用例。39/130基本路径测试在实际问题中，一个不太复杂的程序，特40/130程序的控制流图（也称程序图）流图由结点和边组成，分别用圆和箭头表示。设计图中一个连续的处理框（对应于程序中的顺序语句）序列和一个判定框（对应于程序中的条件控制语句）映射成流图中的一个结点，设计图中的箭头（对应于程序中的控制转向）映射成流图中的一条边。对于设计图中多个箭头的交汇点可以映射成流图中的一个结点（空结点）。40/130程序的控制流图（也称程序图）流图由结点和边组成，41/130上述映射的前提是设计图的判定中不包含复合条件。如果设计图的判定中包含了复合条件，那么必须先将其转换成等价的简单条件设计图。123456c）对应的流图a）含复合条件的设计图aborcdx=1x=2tfy=0b）只含简单条件的设计图ttffx=1x=1abcdx=2123456y=041/130上述映射的前提是设计图的判定中不包含复合条件。如42/130把流图中由结点和边组成的闭合部分称为一个区域（region），在计算区域数时，图的外部部分也作为一个区域。例如，右图所示的流图的区域数为3。独立路径是指程序中至少引进一个新的处理语句序列或一个新条件的任一路径，在流图中，独立路径至少包含一条在定义该路径之前未曾用到过的边。在基本路径测试时，独立路径的数目就是流图的区域数。12345642/130把流图中由结点和边组成的闭合部分称为一个区域（r43/130 例如，对一个PDL程序进行基本路径测试，该程序的功能是：最多输入N个值（以-999为输入结束标志），计算位于给定范围内的那些值（称为有效输入值）的平均值，以及输入值的个数和有效值的个数。43/130例如，对一个PDL程序进行基本路径测试，该程44/130valueiminimumvaluei=maximumtotal.valid加1sum=sum+valueivaluei-999total.inputntotal.valid0average=-999i加1total.valid加1赋初值average=sum/total.valid10111213987123456tffttttfff44/130valueiminimumval45/130其区域数为6，选取独立路径如下：路径1：1-2-10-11-13路径2：1-2-10-12-13路径3：1-2-3-10-11-13路径4：1-2-3-4-5-8-9-2-10-12-13路径5：1-2-3-4-5-6-8-9-2-10-12-13路径6：1-2-3-4-5-6-7-8-9-2-10-11-13为每一条独立路径设计测试用例。假设：n=5；minimum=0；maximum=100。45/130其区域数为6，选取独立路径如下：46/130路径1：1-2-10-11-13测试数据：value=90，-999，0，0，0预期结果：Average=90，total.input=1，total.valid=1路径2：1-2-10-12-13测试数据：value=-999，0，0，0，0预期结果：Average=-999，total.input=0，total.valid=0路径3：1-2-3-10-11-13测试数据：value=-1，90，70，-1，80预期结果：Average=80，total.input=5，total.valid=346/130路径1：1-2-10-11-1347/130路径4：1-2-3-4-5-8-9-2-10-12-13测试数据：value=-1，-2，-3，-4，-999预期结果：Average=-999，total.input=4，total.valid=0路径5：1-2-3-4-5-6-8-9-2-10-12-13测试数据：value=120，110，101，-999，0预期结果：Average=-999，total.input=3，total.valid=0路径6：1-2-3-4-5-6-7-8-9-2-10-11-13测试数据：value=95，90，70，65，-999预期结果：Average=80，total.input=4，total.valid=447/130路径4：1-2-3-4-5-8-9-2-10-48/130值得注意的是，某些独立路径（如例中的路径1和路径3）不能以独立的方式进行测试，此时，这些路径必须在其他的独立路径测试中被覆盖。48/130值得注意的是，某些独立路径（如例中的路径1和49/130循环测试循环分为4种不同类型：简单循环、嵌套循环、串接循环和非结构循环。(1)简单循环按照下列规则设计测试用例：零次循环：从循环入口到出口一次循环：检查循环初始值二次循环：检查多次循环m次循环：检查多次循环最大次数循环比最大次数多一次的循环比最大次数少一次的循环49/130循环测试循环分为4种不同类型：简单循环、嵌套循环50/13050/13051/130按照下列规则设计测试用例：先测试最内层循环：所有外层的循环变量置为最小值，最内层按简单循环测试；由里向外，测试上一层循环：测试时此层以外的所有外层循环的循环变量取最小值，此层以内的所有嵌套内层循环的循环变量取“典型”值，该层按简单循环测试；重复上一条规则，直到所有各层循环测试完毕；对全部各层循环同时取最小循环次数，或者同时取最大循环次数(2)嵌套循环51/130按照下列规则设计测试用例：(2)嵌套循环52/130(3)串接循环如果串接的各个循环互相独立，则可以分别用简单循环的方法进行测试；但如果第一个循环的循环变量与第二个循环控制相关，则两个循环不独立，此时，把第一个循环看作外循环，第二个循环看作内循环，然后用测试嵌套循环的办法来处理。(4)非结构循环这类循环应先将其结构化，然后再测试。52/130(3)串接循环如果串接的各个53/13010.3黑盒测试黑盒测试是依据软件的需求规约，而不考虑程序的内部结构与特性，检查程序的功能是否符合需求规约的要求。主要的黑盒测试方法有：等价类划分等价类划分边界值分析边界值分析比较测试比较测试错误猜测错误猜测因果图因果图53/13010.3黑盒测试黑盒测试是依据软件的需求规约54/130等价类划分等价类划分方法将所有可能的输入数据划分成若干个等价类，然后在每个等价类中选取一个代表性的数据作为测试用例。等价类是指输入域的某个子集，该子集中的等价类是指输入域的某个子集，该子集中的每个输入数据对揭露软件中的错误都是等效每个输入数据对揭露软件中的错误都是等效的，测试等价类的某个代表值就等价于对这的，测试等价类的某个代表值就等价于对这一类其他值的测试。一类其他值的测试。等价类划分方法把输入数据分为有效输入数等价类划分方法把输入数据分为有效输入数据和无效输入数据据和无效输入数据54/130等价类划分等价类划分方法将所有可能的输入数据划分55/130等价类划分设计测试用例的步骤确定等价类根据软件的规格说明，对每一个输入条件（通常是规格说明中的一句话或一个短语）确定若干个有效等价类和若干个无效等价类。可使用如下表格输入条件有效等价类 无效等价类55/130等价类划分设计测试用例的步骤确定等价类56/130确定等价类的规则：(1)如果输入条件规定了取值范围，则可以确定一个有效等价类（输入值在此范围内）和两个无效等价类（输入值小于最小值及大于最大值）例如，规定输入的考试成绩在0.100之间，则有效等价类是“0成绩100”，无效等价类是“成绩0”和“成绩100”。56/130确定等价类的规则：(1)如果输57/130(2)如果输入条件规定了值的个数，则可以确定一个有效等价类（输入值的个数等于规定的个数）和两个无效等价类（输入值的个数小于规定的个数和大于规定的个数）例如，规定输入构成三角形的3条边，则有效等价类是“输入边数=3”，无效等价类是“输入边数3”和“输入边数3”。57/130(2)如果输入条件规定了值的个数，则可以确定58/130(3)如果输入条件规定了输入值的集合（即离散值），而且程序对不同的输入值做不同的处理，那么每个允许的值都确定为一个有效等价类，另外还有一个无效等价类（任意一个不允许的值）。例如，规定输入的考试成绩为优、良、中、及格、不及格，则可确定5个有效等价类和一个无效等价类。58/130(3)如果输入条件规定了输入值的集合（即离59/130(4)如果输入条件规定了输入值必须遵循的规则，那么可确定一个有效等价类（符合此规则）和若干个无效等价类（从各个不同的角度违反此规则）。例如，在Pascal语言中对变量标识符规定为“以字母开头的串”。那么有效等价类是“以字母开头的串”，而无效等价类有“以数字开头的串”、“以标点符号开头的串”等。59/130(4)如果输入条件规定了输入值必须遵循的规60/130(5)如果输入条件规定输入数据是整型，那么可以确定三个有效等价类（正整数、零、负整数）和一个无效等价类（非整数）。(6)如果输入条件规定处理的对象是表格，那么可以确定一个有效等价类（表有一项或多项）和一个无效等价类（空表）。以上只是列举了一些规则，实际情况往往是千变万化的，在遇到具体问题时，可参照上述规则的思想来划分等价类。60/130(5)如果输入条件规定输入数据是整型，那么61/130设计测试用例在确定了等价类之后，建立等价类表，列出所有划分出的等价类。并为每个有效等价类和无效等价类编号。输入条件输入条件有效等价类有效等价类 无效等价类无效等价类61/130设计测试用例在确定了等价类之后，建立62/130边界值分析边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，其揭露程序中错误的可能性就更大。62/130边界值分析边界值分析也是一种黑盒测试方法，是对等63/130边界是指，相对于输入等价类和输出等价类而言，直接在其边界上、或稍高于其边界值、或稍低于其边界值的一些特定情况。使用等价类分析方法设计测试用例时，原则上，等价类中的任一输入数据都可作为该等价类的代表用作测试用例。而边值分析则是专门挑选那些位于边界附近的值（即正好等于、或刚刚大于、或刚刚小于边界的值）作为测试用例。63/130边界是指，相对于输入等价类和输出等价类而言，直接64/130边界值分析方法选择测试用例的规则如下：1如果输入条件规定了值的范围，则选择刚刚达到这个范围的边界的值以及刚刚超出这个范围的边界的值作为测试输入数据。例如，规定输入的考试成绩在0100之间，则取0，100，1，101作为测试输入数据。2如果输入条件规定了值的个数，则分别选择最大个数、最小个数、比最大个数多1、比最小个数少1的数据作为测试输入数据。例如，规定一运动员的参赛项目至少1项，最多3项，则可选择参赛项目分别是1项、3项、0项、4项的测试输入数据。64/130边界值分析方法选择测试用例的规则如下：65/1303对每个输出条件使用第1条。例如，输出的金额值大于等于0且小于104，则选择使得输出金额分别为0、9999、1、10000的输入数据作为测试数据。4对每个输出条件使用第2条。例如，规定输出的一张发票上，至少有1行内容，至多有5行内容，则选择使得输出发票分别有1行、5行、0行、6行内容的输入数据作为测试数据。5如果程序的输入或输出是个有序集合，例如，顺序文件、表格，则应把注意力集中在有序集的第1个元素和最后一个元素上。65/1303对每个输出条件使用第1条。66/1306.如果程序中定义的内部数据结构有预定义的边界，例如，数组的上界和下界，则应选择使得正好达到该数据结构边界以及刚好超出该数据结构边界的输入数据作为测试数据。例如，程序中数组A的下界是10，上界是20，则可选择使得A的下标为10、20、9、21的输入数据作为测试数据。7.发挥你的智慧，找出其他可能的边界条件。由于边值分析方法所设计的测试用例更有可能发现程序中的错误，因此经常把边值分析方法与其它设计测试用例方法结合起来使用。66/1306.如果程序中定义的内部数据结构有预定义的边界67/130比较测试（backtoback）有些软件有很高的可靠性要求，特别是那些可能危及人的生命安全的软件系统，需要冗余的硬件和软件来减少错误发生的可能性。通常，可由二支软件开发队伍，根据相同的需求规格说明分别开发二个软件版本，然后，用相同的测试用例对二个版本的软件分别进行测试，比较二个版本软件的测试结果，如果测试结果相同，则可认为二个版本的软件都是正确的，如果测试结果不同，则要分析各个版本，以发现错误的所在。此测试称为比较测试。67/130比较测试（backtoback）有些软件有很68/130值得注意的是，比较测试并不能保证软件没有错误，如果规格说明本身有错，那么所有的版本都可能反映这种错误。另外，如果各个版本产生相同的但都不正确的结果，那么比较测试也无法发现这种错误。68/130值得注意的是，比较测试并不能保证软件没有错误，如69/130错误推测法错误猜测是一种凭直觉和经验推测某些可能存在的错误，从而针对这些可能存在的错误设计测试用例的方法。这种方法没有机械的执行步骤，主要依靠直觉和经验。错误猜测法的基本思想是：列举出程序中所有可能的错误和容易发生错误的特殊情况，然后根据这些猜测设计测试用例。69/130错误推测法错误猜测是一种凭直觉和经验推测某些可能70/130因果图在等价类划分方法和边界值方法中未考虑输入条件的各种组合，当输入条件比较多时，输入条件组合的数目会相当大因果图方法是一种帮助人们系统地选择一组高效测试用例的方法，它既考虑了输入条件的组合关系，又考虑了输出条件对输入条件的依赖关系，即因果关系，其测试用例发现错误的效率比较高。70/130因果图在等价类划分方法和边界值方法中未考虑输入条71/130因果图方法的特点是：考虑输入条件的组合关系；考虑输入条件的组合关系；考虑输出条件对输入条件的依赖关系，即考虑输出条件对输入条件的依赖关系，即因果关系；因果关系；测试用例发现错误的效率高；测试用例发现错误的效率高；能检查出功能说明中的某些不一致或遗漏。能检查出功能说明中的某些不一致或遗漏。71/130因果图方法的特点是：72/130用因果图设计测试用例的步骤：(1)分割功能说明书将输入条件分成若干组，然后分别对每个组使用因果图，这样可减少输入条件组合的数目。(2)识别“原因”和“结果”，并加以编号原因是指输入条件或输入条件的等价类；结果是指输出条件或系统变换。每个原因和结果都对应于因果图中的一个结点，当原因或结果成立（或出现）时，相应的结点的值为1，否则为0。72/130用因果图设计测试用例的步骤：(1)73/130(3)根据功能说明中规定的原因与结果之间的关系画出因果图因果图的基本符号如下：ba恒等ba非abcdabcd图中左边的结点表示原因，右边的结点表示结果。或与73/130(3)根据功能说明中规定的原因与结果之间的关74/130原因和结果之间的关系有：恒等：若恒等：若a=1，则，则b=1；若；若a=0，则，则b=0非：若非：若a=1，则，则b=0；若；若a=0，则，则b=1或：若或：若a=1或或b=1 或或c=1，则，则d=1；否则；否则d=0与：若与：若a=b=c=1，则，则d=1；否则；否则d=0画因果图时原因在左，结果在右，由上向下排列，并根据功能说明中规定的原因和结果之间的关系，用上述符号连接起来。必要时还可以引入一些中间结点。74/130原因和结果之间的关系有：75/130(4)根据功能说明在因果图中加上约束条件 因果图的约束条件如下图所示：要求RbabaM屏蔽互斥abcE包含abcI唯一abcO75/130(4)根据功能说明在因果图中加上约束条件要求76/130图中互斥、包含、唯一、要求是对原因的约束，屏蔽是对结果的约束互斥：表示互斥：表示a、b、c中至多只有一个为中至多只有一个为1，即不，即不同时为同时为1包含：表示包含：表示a、b、c中至少有一个为中至少有一个为1，即不同，即不同时为时为0唯一：表示唯一：表示a、b、c中有且仅有一个中有且仅有一个1要求：表示若要求：表示若a=1，则要求，则要求b必须为必须为1，即不可，即不可出现出现a=1 且且b=0屏蔽：表示若屏蔽：表示若a=1，则，则b必须为必须为0，即不可出现，即不可出现a=1 且且b=176/130图中互斥、包含、唯一、要求是对原因的约束，屏蔽是77/130(5)根据因果图画出判定表列出满足约束条件的所有原因组合，写出每种原因组合下的结果（如有的话）原因允许的原因组合中间结点各种原因组合下中间结点的值结果各种原因组合下的结果值(6)为判定表的每一列设计一个测试用例77/130(5)根据因果图画出判定表原中间结(678/130 例如，有一个处理单价为5角钱的饮料自动售货机软件，其规格说明如下：饮料自动售货机允许投入5角或1元的硬币，用户可通过“橙汁”和“啤酒”按钮选择饮料，售货机还装有一个表示“零钱找完”的指示灯，当售货机中有零钱找时指示灯暗，当售货机中无零钱找时指示灯亮。当用户投入5角硬币并押下“橙汁”或“啤酒”按钮后，售货机送出“橙汁”或“啤酒”。当用户投入1元硬币并押下“橙汁”或“啤酒”按钮后，如果售货机有零钱找，则送出相应的饮料，并退还5角硬币；如果售货机没有零钱找，则饮料不送出，并且退还1元硬币。78/130例如，有一个处理单价为5角钱的饮料79/130(1)分析规格说明，列出原因和结果规格说明中的红色部分是输入条件（原因），蓝色部分是输出条件（结果）。由于“售货机有零钱找”是在投入1元硬币时判断是否能找零钱的依据，也可把它看作是一个输入条件，即原因。与之对应的结果是售货机指示灯亮（或暗）。原因结果售货机有零钱找(21)售货机“零钱找完”灯亮投入1元硬币(22)退还1元硬币投入5角硬币(23)退还5角硬币押下“橙汁”按钮(24)送出“橙汁”饮料押下“啤酒”按钮(25)送出“啤酒”饮料79/130分析规格说明，列出原因和结果规格说明80/130(2)画出因果图。所有原因结点列在左边，所有结果结点列在右边。其中中间结点的含义如下：（11）投入1元硬币且押下饮料按钮（12）押下“橙汁”或“啤酒”按钮（13）应找5角硬币且售货机有零钱找（14）钱已付清80/130(2)画出因果图。所有原因结点81/130(3)由于原因2与3，4与5不能同时发生，分别加上约束条件E。(4)根据因果图画出判定表(5)根据判定表设计测试用例81/130(3)由于原因2与3，4与5不能82/13082/13083/13010.4测试策略一种测试策略就是将测试分为单元测试、集成测试、确认测试和系统测试。单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。对于基于计算机系统中的软件，还需将它集成到基于计算机系统中，并进行系统测试，以揭露不符合系统工程中对软件要求的错误。83/13010.4测试策略一种测试策略就是将测试分为84/130V模型：描述软件开发各阶段与测试策略之间的对应关系。系统工程需求分析设计编码系统测试确认测试集成测试单元测试84/130V模型：描述软件开发各阶段与测试策略之间的对应关85/130单元测试(UnitTesting)单元测试又称模块测试，它着重对软件设计的最小单元（软件构件或模块）进行验证单元测试根据设计描述，对重要的控制路径进行测试，以发现构件或模块内部的错误单元测试通常采用白盒测试，并且多个构件或模块可以并行进行测试这里将构件或模块统一称为模块85/130单元测试(UnitTesting)单元测试又86/1301.单元测试的内容模块接口：确保模块的输入/输出参数信息是正确的。包括参数的个数、次序、类型等。局部数据结构：确保临时存储的数据在算法执行的过程中都能维持其完整性。如不合适的类型说明、不同数据类型的比较或赋值、文件打开和关闭的遗漏、超越数据结构的边界等。边界条件：确保程序单元在极限或严格的情况下仍能正确地执行。86/1301.单元测试的内容模块接口：确保模块的输入/输87/1302.单元测试过程单元测试通常与编码工作结合起来进行。模块本身不是一个独立的程序，在测试模块时，必须为每个被测模块开发一个驱动(driver)程序和若干个桩(stub)模块。驱动程序被测模块桩模块桩模块87/1302.单元测试过程单元测试通常与编码工作结合起来88/130驱动模块接收测试数据，调用被测模块，把测试数据传送给被测模块，被测模块执行后，驱动模块接收被测模块的返回数据，并打印相关结果。驱动程序的程序结构如下：数据说明；初始化；输入测试数据；调用被测模块；输出测试结果；停止88/130驱动模块接收测试数据，调用被测模块，把测试数据传89/130桩模块的功能是替代被被测模块调用的模块，它接受被测模块的调用，验证入口信息，把控制连同模拟结果返回给被测模块。桩模块的程序结构如下：数据说明；初始化；输出提示信息（表示进入了哪个桩模块）；验证调用参数；打印验证结果；将模拟结果送回被测程序；返回89/130桩模块的功能是替代被被测模块调用的模块，它接受被90/130集成测试（IntegratedTesting）集成测试也称组装测试、联合测试经单元测试后，每个模块都能独立工作，但把它们放在一起往往不能正常工作。90/130集成测试（IntegratedTesting）91/130主要问题在于：数据可能在通过接口时丢失；数据可能在通过接口时丢失；一个模块可能对另一个模块产生产生非故意的、一个模块可能对另一个模块产生产生非故意的、有害的影响（即副作用）；有害的影响（即副作用）；当子功能被组合起来时，可能不能达到期望的当子功能被组合起来时，可能不能达到期望的主功能；主功能；单个模块可以接受的不精确性（如误差），连单个模块可以接受的不精确性（如误差），连接起来后可能会扩大到无法接受的程度；接起来后可能会扩大到无法接受的程度；全局数据结构可能会存在问题。全局数据结构可能会存在问题。91/130主要问题在于：92/130集成的方式有两种：非增量式集成：先将所有经过单元测试的模块非增量式集成：先将所有经过单元测试的模块组合在一起，然后对整个程序（作为一个整体）组合在一起，然后对整个程序（作为一个整体）进行测试。这种测试在发现错误时，很难为错进行测试。这种测试在发现错误时，很难为错误定位。误定位。增量式集成：根据程序结构图，按某种次序挑增量式集成：根据程序结构图，按某种次序挑选一个（或一组）尚未测试过的模块，把它集选一个（或一组）尚未测试过的模块，把它集成到已测试好的模块中一起进行测试，每次增成到已测试好的模块中一起进行测试，每次增加一个（或一组）模块，直至所有模块全部集加一个（或一组）模块，直至所有模块全部集成到程序中。在增量集成测试过程中发现的错成到程序中。在增量集成测试过程中发现的错误，往往与新加入的模块有关。误，往往与新加入的模块有关。92/130集成的方式有两种：93/130增量式集成又可分为自顶向下集成和自底向上集成。自顶向下集成：从主控模块（主程序）开始，自顶向下集成：从主控模块（主程序）开始，然后按照程序结构图的控制层次，将直接或间然后按照程序结构图的控制层次，将直接或间接从属于主控模块的模块按深度优先或广度优接从属于主控模块的模块按深度优先或广度优先的方式逐个集成到整个结构中，并对其进行先的方式逐个集成到整个结构中，并对其进行测试。测试。93/130增量式集成又可分为自顶向下集成和自底向上集成。94/130深度优先测试次序：M1、M2、M5、M8、M6、M3、M7、M4广度优先测试次序：M1、M2、M3、M4、M5、M6、M7、M8M2M3M4M7M1M6M5M894/130深度优先测试次序：M2M3M4M7M1M6M5M95/130自顶向下集成的步骤：主控模块（主程序）被直接用作驱动程序，所有直接从属于主控模块的模块用桩模块替换，然后对主控模块进行测试；根据集成的实现方式，下层的桩模块一次一个地替换成真正的模块，从属于该模块的模块用桩模块替换，然后对其进行测试；用回归测试来保证没有引入新的错误；重复第(2)和第(3)步，直至所有模块都被集成。95/130自顶向下集成的步骤：96/130自顶向下集成的优点：不需要驱动模块；能尽早对程序的主要控制和决策机制进行检验，能较早发现整体性的错误；深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。自顶向下集成的缺点：测试时低层模块用桩模块替代，不能反映真实情况；重要数据不能及时回送到上层模块。96/130自顶向下集成的优点：97/130自底向上集成：从程序结构的最底层模块自底向上集成：从程序结构的最底层模块（即原子模块）开始，然后按照程序结构图（即原子模块）开始，然后按照程序结构图的控制层次将上层模块集成到整个结构中，的控制层次将上层模块集成到整个结构中，并对其进行测试。并对其进行测试。自底向上集成在测试一个模块时，它的下层自底向上集成在测试一个模块时，它的下层模块（已测试过）可用作它的桩模块。模块（已测试过）可用作它的桩模块。97/130自底向上集成：从程序结构的最底层模块（即原子模98/130自底向上集成的步骤：将低层模块组合成能实现软件特定功能的簇；为每个簇编写驱动程序，并对簇进行测试；移走驱动程序，用簇的直接上层模块替换驱动程序，然后沿着程序结构的层次向上组合新的簇；凡对新的簇测试后，都要进行回归测试，以保证没有引入新的错误；重复第步至第步，直至所有的模块都被集成。98/130自底向上集成的步骤：99/130McMaMb簇1簇2簇3D1D3D2驱动模块簇4簇599/130McMaMb簇1簇2簇3D1D3D2驱动模块簇4100/130自底向上集成的优点：不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一层次的簇可并行进行测试，可提高效率。自底向上集成的缺点：整体性的错误发现得较晚。100/130自底向上集成的优点：101/130策略的选择自顶向下集成测试与自底向上集成测试各有优缺点，自顶向下集成测试与自底向上集成测试各有优缺点，将这两种策略组合起来可能是一种最好的折衷，其将这两种策略组合起来可能是一种最好的折衷，其策略是：在程序结构的高层使用自顶下向策略，而策略是：在程序结构的高层使用自顶下向策略，而在低层则使用自底向上策略。在低层则使用自底向上策略。集成测试时应特别关注关键模块的测试。关键模块集成测试时应特别关注关键模块的测试。关键模块是指具有下列一个或多个特征的模块：是指具有下列一个或多个特征的模块：与多个软与多个软件需求有关；件需求有关；含有高层控制（位于程序结构的高含有高层控制（位于程序结构的高层）；层）；本身是复杂的或是容易出错的；本身是复杂的或是容易出错的；含有确含有确定的性能需求。关键模块应尽早测试，回归测试时定的性能需求。关键模块应尽早测试，回归测试时也应集中在关键模块的功能上。也应集中在关键模块的功能上。101/130策略的选择102/130回归测试（RegressionTesting）在集成测试过程中，每当增加一个新模块时，原先已集成的软件就发生了改变。新的数据流路径被建立，新的I/O操作可能出现，还可能激活新的控制逻辑，这些改变可能使原本正常的功能产生错误。当测试时发现错误后，需修改程序；或者在软件维护时也需修改程序。这些对程序的修改也可能使原本正常的功能产生错误。回归测试是对已进行过的测试的子集的重新执行，以确保对程序的改变和修改，没有传播非故意的副作用。102/130回归测试（RegressionTesting103/130确认测试（ValidationTesting）确认测试标准 确认测试以软件需求规约为依据，以发现软件与需求不一致的错误。主要检查软件是否实现了规约规定的全部功能要求，文档资料是否完整、正确、合理，其他的需求，如可移植性、可维护性、兼容性、错误恢复能力等是否满足。103/130确认测试（ValidationTesting104/130确认测试的结果可分为两类：满足需求规约要求的功能或性能特性，用满足需求规约要求的功能或性能特性，用户可以接受。户可以接受。发现与需求规约有偏差，此时需列出问题发现与需求规约有偏差，此时需列出问题清单。清单。104/130确认测试的结果可分为两类：105/130软件配置评审软件配置评审也称软件审计，其目的是保证软件配置的所有成分都齐全，各方面的质量都符合要求，具有维护阶段必需的细节，而且已经编排好分类目录。软件配置主要包括计算机程序（源代码和可执行程序），针对开发者和用户的各类文档，包含在程序内部或程序外部的数据。105/130软件配置评审106/130测试是由一个用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经测试后的软件称为版软件。测试是由软件的最终用户在一个或多个用户场所进行的，开发者通常不在测试现场。测试是软件在一个开发者不能控制的环境中的“活的”应用，用户记录所有在测试中遇到的问题，并定期把这些问题报告给开发者，在接到测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。测试和测试106/130测试是由一个用户在开发者的场所进行的，软件在107/130系统测试（SystemTesting）系统测试是对整个基于计算机的系统进行的一系列测试。系统测试的种类很多，每种测试都有不同的目的，它们从不同的角度测试计算机系统是否被正常地集成，并完成相应的功能。常用的系统测试包括：恢复测试恢复测试（recovery testing）安全测试安全测试（security testing）压力测试压力测试（stress testing）性能测试性能测试（performance testing）107/130系统测试（SystemTesting）系统测108/130恢复测试（recoverytesting）恢复测试是通过各种手段，强制软件发生故障，然后来验证系统能否在指定的时间间隔内恢复正常，包括修正错误并重新启动系统。如果恢复是由系统自身来完成的，那么，需验证重新初始化、检查点机制、数据恢复和重启动等的正确性。如果恢复需要人工干预，那么要估算平均修复时间MTTR（meantimetorepair）是否在用户可以接受的范围内。108/130恢复测试（recoverytesting）恢109/130安全测试（securitytesting）安全测试用来验证集成在系统中的保护机制能否实际保护系统不受非法侵入。在安全测试过程中，测试者扮演一个试图攻击系统的角色，采用各种方式攻击系统。例如，截取或码译密码；借助特殊软件攻击系统；故意导致系统失效，企图在系统恢复之机侵入系统等等。一般来说，只要有足够的时间和资源，好的完全测试一定能最终侵入系统。系统设计者的任务是把系统设计成：攻破系统所付出的代价大于攻破系统后得到信息的价值。109/130安全测试（securitytesting）安110/130压力测试（stresstesting）压力测试也称强度测试，它是在一种需要非正常数量、频率或容量的方式下执行系统，其目的是检查系统对非正常情况的承受程度。如：当系统的中断频率是每秒当系统的中断频率是每秒1或或2个时，执行每秒个时，执行每秒10个中断的测试用例个中断的测试用例将输入数据的数量提高一个数量级来测试输入将输入数据的数量提高一个数量级来测试输入功能如何响应功能如何响应执行需要最大内存或其它资源的测试用例执行需要最大内存或其它资源的测试用例执行可能导致大量磁盘驻留数据的测试用例执行可能导致大量磁盘驻留数据的测试用例110/130压力测试（stresstesting）压力测111/130性能测试（performancetesting）性能测试用来测试软件在集成的系统中的运行性能。它对实时系统和嵌入式系统尤为重要。性能测试可以发生在测试过程的所有步骤中单元测试时，主要测试一个独立模块的性能，如算单元测试时，主要测试一个独立模块的性能，如算法的执行速度。法的执行速度。软件集成后，进行软件整体的性能测试。软件集成后，进行软件整体的性能测试。计算机系统集成后，进行整个计算机系统的性能测计算机系统集成后，进行整个计算机系统的性能测试。试。性能测试常常需要与压力测试结合起来进行，而且常常需要一些硬件和软件测试设备，以监测系统的运行情况。111/130性能测试（performancetestin112/13010.5面向对象测试面向对象软件的测试目标仍然是用最少时间和工作量来发现尽可能多的错误但面向对象软件的性质改变了测试的策略和测试战术。面向对象软件的测试也给软件工程师带来新的挑战。112/13010.5面向对象测试面向对象软件的测试目标113/130面向对象语境对测试的影响继承、封装、多态性、基于消息的通信等概念都是面向对象软件的重要特征，它们对面向对象测试有很大的影响。单元 适用于面向对象测试的两种单元定义单元是可以编译和执行的最小软件部件单元是可以编译和执行的最小软件部件单元是决不会指派给多个设计人员开发的软单元是决不会指派给多个设计人员开发的软件部件件部件类是面向对象软件中的单元类是面向对象软件中的单元113/130面向对象语境对测试的影响继承、封装、多态性、基114/130封装：因属性和操作被封装在类中，故测试时很难获得对象的某些具体信息，而给测试带来困难。继承：测试了父类的操作后，并不表示其子类就不必对继承的操作进行测试。多态性 在测试时，应覆盖反映多态的所有实现方法。基于消息的通信：面向对象软件是通过消息通信来实现类之间的协作，它们没有明显的层次控制结构，因此，传统的自顶向下和自底向上集成策略不适用于面向对象软件测试。114/130封装：因属性和操作被封装在类中，故测试时很难获115/130面向对象的测试策略把类作为面向对象软件的单元，传统的单元测试等价于面向对象中的类测试，也称类内测试。它包括类内的方法测试和类的行为测试。面向对象中的类间测试相当于面向对象的集成测试。它有两种集成策略：基于线程的测试：集成一组互相协作的类来响基于线程的测试：集成一组互相协作的类来响应系统的一个输入或事件，每个线程逐一被集应系统的一个输入或事件，每个线程逐一被集成和测试，并通过回归测试保证其没有产生副成和测试，并通过回归测试保证其没有产生副作用。作用。115/130面向对象的测试策略把类作为面向对象软件的单元，116/130面向对象的确认测试和系统测试策略与传统的确认测试和系统测试策略相同，在面向对象确认测试时，应该利用用况模型，通过用况提供的场景来发现与用户需求不一致的错误。基于使用的测试：按使用层次来集成系统。把那些几乎不使用其他类提供的服务的类称为独立类，把使用类的类称为依赖类。集成从测试独立类开始，然后集成直接依赖于独立类的那些类，并对其测试。按照依赖的层次关系，逐层集成并测试，直至所有的类被集成。116/130面向对象的确认测试和系统测试策略与传统的确认测117/130面向对象测试用例设计传统的测试用例设计方法及其思想在面向对象测试中仍是可用的。类内测试测试类中的每个操作（相当于中的每个操作（相当于传统软件中的函数或子件中的函数或子程序），通常采用白盒程序），通常采用白盒测试方法，如方法，如逻辑覆盖、基本覆盖、基本路径覆盖、数据流路径覆盖、数据流测试、循、循环测试等。等。测试类的行的行为（通常用状（通常用状态机机图来描述），利用状来描述），利用状态机机图进行行类测试时，可考，可考虑覆盖所有状覆盖所有状态、所有状、所有状态迁移等覆盖迁移等覆盖标准，也可考准，也可考虑从初始状从初始状态到到终止状止状态的的所有迁移路径的覆盖。所有迁移路径的覆盖。117/130面向对象测试用例设计传统的测试用例设计方法及其118/130划分测试，与等价类划分方法相似，它将输入和划分测试，与等价类划分方法相似，它将输入和输出分类，并设计测试用例来处理每个类别。划分输出分类，并设计测试用例来处理每个类别。划分的方式有多种：的方式有多种：v基于状态的划分是根据操作改变类状态的能力对操作分类。v基于属性的划分是根据使用的属性对操作分类，如使用属性a的操作、