软件测试基础课件

第二章软件测试基础1第二章软件测试基础1[本章要点]

软件测试基础知识；白盒测试和黑盒测试的定义；常见的白盒和黑盒测试设计技术；白盒测试与黑盒测试的区别；测试计划和测试报告的编制；测试用例的定义和编制方法。2[本章要点]2[本章目标]理解并掌握白盒测试和黑盒测试，以及二者的优缺点和各自的应用范围；能够熟练使用几种常见测试用例设计技术；了解测试计划和测试文档的作用，以及应该包含的内容和制定方法；了解测试报告的基本内容，以及测试用例的基本内容和编制方法。3[本章目标]3经过改进的程序图定义：节点要么是整个语句，要么是语句的一部分，边表示控制流（从节点i到节点j有一条边，当且仅当对应节点j的语句或语句的一部分，可以立即在节点i对应的语句或语句的一部分之后执行）。程序的有向图公式化能够非常准确地描述程序的测试方面的问题。基本结构化程序设计的构造，例如：串行、选择和循环等可以用如图2-1所示的有向图表示。4经过改进的程序图定义：节点要么是整个语句，图2-1结构化程序设计构造的有向图5图2-1结构化程序设计构造的有向图52.2白盒测试白盒测试是一种可视的测试软件的方法，即它把测试对象看作一个透明的盒子，测试人员要了解程序结构和处理过程，按照程序内部逻辑测试程序，检查程序中的每条通路是否按照预定要求正确工作。白盒测试的过程如图2-7所示：图2-7白盒测试过程示意图62.2白盒测试图2-7白盒测试过程示意图6那么，在对被测软件进行白盒测试时，主要对程序进行哪些方面的检查呢？有如下几点：（１）保证一个模块中的所有独立执行路径至少测试一次；（２）对所有逻辑判定取值“true”和“false”的两种情况都至少测试一次；（３）在循环边界和运行界限内执行循环体；（４）测试内部数据结构的有效性。在软件测试领域，有六种基本的测试类型：单元测试，集成测试，功能测试/系统测试，可接受性测试，回归测试和Beta测试。白盒测试可以用在其中的三种测试类型中：1、单元测试7那么，在对被测软件进行白盒测试时，主要对程2、集成测试3、回归测试

2.2.1白盒测试与调试的异同

白盒测试和调试有哪些不同点呢？1、从承担的任务来看，白盒测试同其他类型测试一样，它的任务是发现所开发的项目中的缺陷；但是，调试不属于测试，其任务是纠正软件中的缺陷。2、从最终的结果来看，白盒测试有预知的结果，不可预知的只是程序是否通过测试，并且成功测试的结果是发现错误的症状，从而引起调试的进行；而调试的结果是消除项目中的错误。

82、集成测试83、从执行的过程来看，测试是一个发现错误、改正错误、重新测试的过程；而调试是一个推理过程。4、从准备工作来看，测试从已知的条件开始，使用预先定义的程序；调试一般是以不可知的内部条件开始，做统一性调试。5、从执行的计划性来看，测试是有计划的并要进行测试设计；而调试则不受时间约束。6、从执行的人员来看，测试经常是由独立的测试组在不了解软件设计的条件下完成的，而调试必须由程序员来完成。

93、从执行的过程来看，测试是一个发现错误、

7、从所使用的工具来看，大多数白盒测试的执行和设计可有工具支持，而调试程序员能利用的工具主要是调试器。2.2.2白盒测试的用例设计白盒测试用例设计技术就是研究如何用最少的测试用例最大限度地发现软件中的错误，目前主要有基本路径测试、等价类划分/边界值分析测试、覆盖测试、循环测试、数据流测试、程序插桩测试、变异测试等等方法。下面主要对几种常见的方法加以介绍：一、基本路径测试二、等价类划分/边界值分析（Equivalencepartitioning/boundaryvalueanalysis）107、从所使用的工具来看，大多数白盒测试的

三、控制流/覆盖测试（Control-flow/CoverageTesting）⑴方法覆盖方法覆盖可用于衡量测试用例所覆盖的方法的百分比。⑵语句覆盖（StatementCoverage）语句覆盖是一种衡量测试所覆盖的程序语句百分比的措施。通过测试应该达到100%程序语句覆盖的目标，可以标识圈数，然后执行最少的一组测试用例就可以达到语句覆盖的目标。⑶判断/分支覆盖判断/分支覆盖是为了衡量在测试过程中覆盖了多少个程序中的布尔表达式。11三、控制流/覆盖测试（Control-flo图2-11各种循环图四、循环测试是一种白盒测试技术，注重于循环构造的有效性。n循环结构测试用例的设计循环可以划分为以下几种模式，如图2-11：12图2-11各种循环图四、循环测试是一种白盒测可以使用如下方法设计循环测试用例：

一、简单循环：

二、嵌套循环：

三、串接循环：

四、无结构循环：五、数据流测试：六、程序插装：程序插装（ProgramInstrumentation）是指在程序中设置断点或打印语句，在执行过程中了解程序的一些动态特性。

13可以使用如下方法设计循环测试用例：13七、变异测试变异测试（MutationTesting）的提出始于70年代末期，是一种错误驱动测试，即针对某类特定程序错误而进行的测试，也是一种比较成熟的排错性测试方法（排错性测试方法的基本思想是通过检验测试数据集的排错能力来判断软件测试的充分性）。

14七、变异测试14逻辑覆盖语句覆盖判定覆盖条件覆盖判定－条件覆盖条件组合覆盖路径覆盖逻辑覆盖是以程序内部的逻辑结构为基础的设计测试用例的技术。它属白盒测试。15逻辑覆盖语句覆盖判定－条件覆盖逻辑覆盖是以程序内部的逻辑⑴语句覆盖(Statementcoverage):每个语句至少执行一次。例：问题：若AND错写为OR，或X>1错写为X<1,则错误无法由上例测出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FFTestcase:A=2,B=0,X=4.16⑴语句覆盖(Statementcoverage):每个语⑵判定覆盖(Branchcoverage)：在⑴的基础上，每个判定的每个分支至少执行一次。Testcases:①A=3,B=0,X=3②A=2,B=1,X=1问题：若X>1错写为X<1,仍然无法被测出。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF17⑵判定覆盖(Branchcoverage)：在⑴的基础上，⑶条件覆盖(Conditioncoverage)：在⑴的基础上，使每个判定表达式的每个条件都取到各种可能的结果。Testcases:①A=2,B=0,X=4（满足A>1,B=0;A=2,X>1)②A=1,B=1,X=1(满足A1,B0;A2,X1）问：条件覆盖？判定覆盖答:不一定。反例:①A=2,B=0,X=1②A=1,B=1,X=2

⑷判定/条件覆盖：即判定覆盖

条件覆盖入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF18⑶条件覆盖(Conditioncoverage)：在⑴的⑸条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出现一次。入口A>1ANDB=0TA=2ORX>1TX=X/AX=X+1返回FF全部可能的条件组合为：①A>1,B=0②A>1,B0③A1,B=0④A1,B0⑤A=2,X>1⑥A=2,X

1⑦A

2,X>1⑧A

2,X

1Testcases:①A=2,B=0,X=4(TT)②A=2.B=1,X=1(FT)③A=1,B=0,X=2(FT)④A=1,B=1,X=1(FF)问题：没有测试到（TF）的情形19⑸条件组合覆盖：每个判定表达式中条件的各种可能组合都至少出考察controlflowgraph的角度，还可考虑下述覆盖：⑹点覆盖⑺边覆盖=语句覆盖⑻路径覆盖(Pathcoverage):

每条可能的路径都至少执行一次，若图中有环，则每个环至少经过一次。=判定覆盖Testcases:①A=1,B=1,X=1②A=1,B=1,X=2③A=3,B=0,X=1④A=2,B=0,X=4⑼路径覆盖条件组合覆盖20考察controlflowgraph的角度，还可考虑下循环测试路径选择循环分为4种不同类型：简单循环、连锁循环、嵌套循环和非结构循环。

(1)简单循环①零次循环：从循环入口到出口

②一次循环：检查循环初始值

③二次循环：检查多次循环

④m次循环：检查在多次循环

⑤最大次数循环、比最大次数多一次、少一次的循环。

21循环测试路径选择循环分为4种不同类型：简单循环、连锁循环、嵌例：求最小值k=i;

for(j=i+1;j<=n;j++)

if(A[j]<A[k])thenk=j;

22例：求最小值k=i;22ace23ace23测试用例选择24测试用例选择24

(2)

嵌套循环

①对最内层循环做简单循环的全部测试。所有其它层的循环变量置为最小值；

②逐步外推，对其外面一层循环进行测试。测试时保持所有外层循环的循环变量取最小值，所有其它嵌套内层循环的循环变量取“典型”值。。

③反复进行，直到所有各层循环测试完毕。

25

(2)嵌套循环

①对最内层循环做简单循环的全部测试2626 ④对全部各层循环同时取最小循环次数，或者同时取最大循环次数(3)

连锁循环

如果各个循环互相独立，则可以用与简单循环相同的方法进行测试。但如果几个循环不是互相独立的，则需要使用测试嵌套循环的办法来处理。(4)非结构循环

这一类循环应该使用结构化程序设计方法重新设计测试用例。

27 ④对全部各层循环同时取最小循环次27基本路径测试基本路径测试方法把覆盖的路径数压缩到一定限度内，程序中的循环体最多只执行一次。它是在程序控制流图的基础上，分析控制构造的环路复杂性，导出基本可执行路径集合，设计测试用例的方法。设计出的测试用例要保证在测试中，程序的每一个可执行语句至少要执行一次。28基本路径测试基本路径测试方法把覆盖的路径数压缩到一定限度内，1.程序的控制流图符号○为控制流图的一个结点，表示一个或多个无分支的PDL语句或源程序语句。箭头为边，表示控制流的方向。291.程序的控制流图符号○为控制流图的一个结点，表示一个或多在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。边和结点圈定的区域叫做区域，当对区域计数时，图形外的区域也应记为一个区域。如果判断中的条件表达式是由一个或多个逻辑运算符(OR,AND,NAND,NOR)

连接的复合条件表达式，则需要改为一系列只有单个条件的嵌套的判断。30在选择或多分支结构中，分支的汇聚处应有一个汇聚结点。3031313232计算环路复杂性的方法：

-V(G)=简单判定节点数+1V(G)=E-N+2(E是边数，N是定点数）V(G)=封闭区域数+1V(G)=41234567833计算环路复杂性的方法：1234567833根据环路复杂性产生基本路径集Path1:1-2-3-8Path2:1-2-3-8-1-2-3Path3:1-2-4-5-7-8Path4:1-2-4-6-7-8准备测试用例覆盖所有基本路径34根据环路复杂性产生基本路径集34基本路径测试法步骤基本路径测试法适用于模块的详细设计及源程序，其主要步骤如下。①以详细设计或源代码作为基础，导出程序的控制流图。②计算得到的控制流图G的环路复杂性V（G）。③确定线性无关的路径的基本集。④生成测试用例，确保基本路径集中每条路径的执行。35基本路径测试法步骤35例如，在图示的控制流图中，一组独立的路径是

path1：1-11

path2：1-2-3-4-5-10-1-11

path3：1-2-3-6-8-9-10-1-11

path4：1-2-3-6-7-9-10-1-11路径path1，path2，path3，path4组成了控制流图的一个基本路径集。36例如，在图示的控制流图中，一组独立的路径是

path1：12.程序环路复杂性程序的环路复杂性给出了程序基本路径集中的独立路径条数，这是确保程序中每个可执行语句至少执行一次所必需的测试用例数目的上界。从控制流图来看，一条独立路径是至少包含有一条在其它独立路径中从未有过的边的路径。372.程序环路复杂性程序的环路复杂性给出了程序基本路径集中的3.导出测试用例导出测试用例，确保基本路径集中的每一条路径的执行。根据判断结点给出的条件，选择适当的数据以保证某一条路径可以被测试到—用逻辑覆盖方法。383.导出测试用例导出测试用例，确保基本路径集中的每一条路径每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都执行完毕，则可以确信程序中所有的可执行语句至少被执行了一次。必须注意，一些独立的路径(如例中的路径1)，往往不是完全孤立的，有时它是程序正常的控制流的一部分，这时，这些路径的测试可以是另一条路径测试的一部分。

39每个测试用例执行之后，与预期结果进行比较。如果所有测试用例都最后，归纳一下白盒测试中各种测试方法的应用策略。在白盒测试中，可以使用各种测试方法的综合策略如下。（1）在测试中，应尽量先使用工具进行静态结构分析。（2）测试中可采取先静态后动态的组合方式：先进行静态结构分析、代码检查，再进行覆盖率测试。40最后，归纳一下白盒测试中各种测试方法的应用策略。（3）利用静态分析的结果作为导引，通过代码检查和动态测试的方式对静态发现结果进行进一步的确认，使测试工作更为有效。（4）覆盖率测试是白盒测试的重点，一般可使用基本路径测试法达到语句覆盖标准；对于软件的重点模块，应使用多种覆盖率标准衡量代码的覆盖率。41（3）利用静态分析的结果作为导引，通过代码检查和动态（5）在不同的测试节点，测试的侧重点不同：在单元测试阶段，以代码检查、逻辑覆盖为主；在集成测试阶段，需要增加静态结构分析等；在系统测试阶段，应根据黑盒测试的结果，采取相应的白盒测试。42（5）在不同的测试节点，测试的侧重点不同：在单元测试阶段，白盒测试总结：

“白盒”法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。“白盒”法是穷举路径测试。在使用这一方案时，测试者必须检查程序的内部结构，从检查程序的逻辑着手，得出测试数据。贯穿程序的独立路径数是天文数字。但即使每条路径都测试了仍然可能有错误。第一、穷举路径测试决不能查出程序违反了设计规范，即程序本身是个错误的程序；第二、穷举路径测试不可能查出程序中因遗漏路径而出错。第三、穷举路径测试可能发现不了一些与数据相关的错误。43白盒测试总结： “白盒”法全面了解程序内部逻辑结构、对所有逻黑盒测试也称作功能测试和行为测试，主要是根据功能需求来测试程序是否按照预期工作。

黑盒测试的目的是尽量发现代码所表现的外部行为的错误，主要有以下几类：⑴功能不正确或不完整；⑵接口错误；⑶接口所使用的数据结构错误；⑷行为或性能错误；⑸初始化和终止错误。黑盒测试的示意图如图2-14所示。从图2-14中，我们可以看出黑盒测试只考虑程序的输入和输出，无须考虑程序的内部代码。2.3黑盒测试44黑盒测试也称作功能测试和行为测试，主要是根据

图2-14黑盒测试示意图45图2-14黑盒测试示意图452.3.1黑盒测试和白盒测试的异同本书归纳出以下几点：执行测试人员不同黑盒测试通常由用户以及非开发人员来进行；而白盒测试通常要有了解软件内部结构的开发人员来做。测试覆盖目标不同如果我们用一个盒子来代替整个软件系统，那么黑盒测试可以看成是一种系统测试。而对盒子内部的多个单元的测试就可以称作为白盒测试。另外一种区别就是，二者的覆盖目标不同。黑盒测试的目标是覆盖所有的用户需求；而白盒测试的目标是覆盖所有的代码。462.3.1黑盒测试和白盒测试的异同463、测试动机不同有效的安全测试有时也需要详细了解代码以及系统结构，此时把这些技术称作白盒测试。另外一种风险测试的目标可能就只是测试软件是否能够为用户提供预期输出。可用性测试就是如此，所以被称作黑盒测试。

4、测试方法不同一个最普通的区别就是行为测试设计是基于功能需求来定义测试，而结构测试则是基于代码本身来定义测试的。这就是两种设计测试的方法。因为行为测试是基于外部功能定义的，所以称作黑盒测试；结构测试则是基于代码内部结构来定义的，所以称作白盒测试。473、测试动机不同475、评估测试方法不同一些技术是使用代码工具来跟踪软件内部的工作过程，因此称为白盒测试技术。与之相比，黑盒测试技术只是简单的观察程序的正常输出。

2.3.2黑盒测试的用例设计常用的黑盒测试用例设计方法主要有以下几种：功能图分析方法，等价类划分方法，边界值分析方法，错误推测方法，因果图方法，判定表驱动分析方法，正交实验设计方法和功能图分析方法等。下面对上述方法分别作以简要介绍。485、评估测试方法不同48一、基于用户需求的测试黑盒测试用例就是基于用户需求的，也是从研究客户需求工作开始的。二、对等区间划分

对等区间划分是一种黑盒测试方法，该方法也称为等价类划分，是一种设计测试用例的非常形式化的方法。三、边界值分析法边界值分析方法是对等价类划分方法的补充。长期的测试工作经验告诉我们,大量的错误是发生在输入或输出范围的边界上,而不是发生在输入输出范围的内部。49一、基于用户需求的测试49四、状态转换测试状态转换测试适用于软件被设计成一个状态机或实现了一种被建模成一种状态机的情况。可以设计测试用例测试状态间转换，测试用例创建引起转换的事件。可以设计负面测试的测试用例用于测试状态与事件的非法组合。五、分支测试在分支测试中，测试用例用于测试单元的控制流分支或决策点。通常用于实现决策覆盖（DecisionCoverage）的测试目标。六、错误推测法错误推测法就是根据经验和直觉推测程序中所有可能存在的各种错误，借助边界值分析等方法有针对性的设计测试用例的方法。50四、状态转换测试50七、因果图方法因果图方法适合于检查程序输入条件的各种组合情况。使用该方法首先要理解软件所表示的对象及其关系，然后，定义一组保证“所有对象与其他对象都具有所期望的关系”的测试序列。

51七、因果图方法51等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时，完全不考虑程序的内部结构，只依据程序的规格说明来设计测试用例。等价类划分方法把所有可能的输入数据，即程序的输入域划分成若干部分，然后从每一部分中选取少数有代表性的数据做为测试用例。52等价类划分等价类划分是一种典型的黑盒测试方法，使用这一方法时使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选取测试用例两步。划分等价类

等价类是指某个输入域的子集合。在该子集合中，各个输入数据对于揭露程序中的错误都是等效的。测试某等价类的代表值就等价于对这一类其它值的测试。

53使用这一方法设计测试用例要经历划分等价类（列出等价类表）和选等价类的划分有两种不同的情况：

①有效等价类：是指对于程序的规格说明来说，是合理的，有意义的输入数据构成的集合。 ②无效等价类：是指对于程序的规格说明来说，是不合理的，无意义的输入数据构成的集合。在设计测试用例时，要同时考虑有效等价类和无效等价类的设计。54等价类的划分有两种不同的情况：

①有效等价类：是指对于程序划分等价类等价类的原则。

(1)如果输入条件规定了取值范围，或值的个数，则可以确立一个有效等价类和两个无效等价类。例如，在程序的规格说明中，对输入条件有一句话：

“……项数可以从1到999……”

则有效等价类是“1≤项数≤999”两个无效等价类是“项数＜1”或“项数＞999”。在数轴上表示成:55划分等价类等价类的原则。

(1)如果输入条件规定了取值范围 (2)如果输入条件规定了输入值的集合，或者是规定了“必须如何”的条件，这时可确立一个有效等价类和一个无效等价类。例如，在Pascal语言中对变量标识符规定为“以字母打头的……串”。那么所有以字母打头的构成有效等价类，而不在此集合内（不以字母打头）的归于无效等价类。(3)如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

56 (2)如果输入条件规定了输入值的集合，或者是规定了“必须(4)如果规定了输入数据的一组值，而且程序要对每个输入值分别进行处理。这时可为每一个输入值确立一个有效等价类，此外针对这组值确立一个无效等价类，它是所有不允许的输入值的集合。例如，在教师上岗方案中规定对教授、副教授、讲师和助教分别计算分数，做相应的处理。因此可以确定4个有效等价类为教授、副教授、讲师和助教，一个无效等价类，它是所有不符合以上身分的人员的输入值的集合。

(5)如果规定了输入数据必须遵守的规则，则可以确立一个有效等价类（符合规则）和若干个无效等价类（从不同角度违反规则）。57(4)如果规定了输入数据的一组值，而且程序要对每个输入值分边界值分析(BoundaryValueAnalysis)边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。人们从长期的测试工作经验得知，大量的错误是发生在输入或输出范围的边界上，而不是在输入范围的内部。因此针对各种边界情况设计测试用例，可以查出更多的错误。边界值分析是一种补充等价划分的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。注意：①程序最容易在边界发生错误； ②通常与等价划分结合进行。58边界值分析(BoundaryValueAnalysis)边界值设计原则应遵循以下几条原则：

1.如果输入条件规定了值的范围，则应取刚达到这个范围的边界的值，以及刚刚超越这个范围边界的值作为测试输入数据。

2.如果输入条件规定了值的个数，则用最大个数、最小个数、比最小个数少一、比最大个数多一的数作为测试数据。3.根据规格说明的每个输出条件，使用前面的原则1。59边界值设计原则应遵循以下几条原则：594.根据规格说明的每个输出条件，应用前面的原则2。5.如果程序的规格说明给出的输入域或输出域是有序集合，则应选取集合的第一个元素和最后一个元素作为测试用例。6.如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。7.分析规格说明，找出其他可能的边界条件。604.根据规格说明的每个输出条件，应用前面的原则2。60

(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使这个等价类的每个边界都要作为测试条件。

(2)边界值分析不仅考虑输入条件，还要考虑输出空间产生的测试情况被测试子域测试内点测试外点边界值分析法与等价类划分法区别61(1)边界值分析不是从某等价类中随便挑一个作为代表，而是使设计测试用例原则：

(1)如输入条件代表以a和b为边界的范围，测试用例应包含a、b、略大于a和略小于b的值。

(2)如输入条件代表一组值，测试用例应当执行其中的最大值和最小值，还应测试略大于最大值和略小于最小值的值。边界值分析法(续)62设计测试用例原则：边界值分析法(续)62错误推测法可以靠经验和直觉推测程序中可能存在的各种错误，从而有针对性地编写检查这些错误的例子。这就是错误推测法（如常见的错误）。错误推测法的基本想法是：列举出程序中所有可能有的错误和容易发生错误的特殊情况，根据它们选择测试用例。思路：①列出可能有的错误；②列出容易发生错误的特殊情况。以此为基础设计测试方案。根据：直觉、经验;工具：常见错误清单、判定表63错误推测法可以靠经验和直觉推测程序中可能存在的各种错误，从而错误推测法例1[例1]对一个排序程序，可以列出以下几种特别需要检查的情况：1)输入表为空。2)输入表中只有一行。3)输入表中所有的行都具有相同的值。4)输入表已经是排序的。64错误推测法例1[例1]对一个排序程序，可以列出以下几种因果图如果在测试时必须考虑输入条件的各种组合，可使用一种适合于描述对于多种条件的组合，相应产生多个动作的形式来设计测试用例，这就需要利用因果图。

因果图方法最终生成的就是判定表。它适合于检查程序输入条件的各种组合情况。65因果图如果在测试时必须考虑输入条件的各种组合，可使用一种用因果图生成测试用例的基本步骤

(1)分析软件规格说明描述中，哪些是原因(即输入条件或输入条件的等价类)，哪些是结果(即输出条件)，并给每个原因和结果赋予一个标识符。

(2)分析软件规格说明描述中的语义，找出原因与结果之间，原因与原因之间对应的是什么关系?根据这些关系，画出因果图。

66用因果图生成测试用例的基本步骤

(1)分析软件规格说明描述 (3)由于语法或环境限制，有些原因与原因之间，原因与结果之间的组合情况不可能出现。为表明这些特殊情况，在因果图上用一些记号标明约束或限制条件。

(4)把因果图转换成判定表。

(5)把判定表的每一列拿出来作为依据，设计测试用例。

67 (3)由于语法或环境限制，有些原因与原因之间，原因与结果在因果图中出现的基本符号

通常在因果图中用Ci表示原因，用Ei表示结果，各结点表示状态，可取值“0”或“1”。“0”表示某状态不出现，“1”表示某状态出现。主要的原因和结果之间的关系有:68在因果图中出现的基本符号

通常在因果图中用Ci表示原因，用E表示约束条件的符号

为了表示原因与原因之间，结果与结果之间可能存在的约束条件，在因果图中可以附加一些表示约束条件的符号。69表示约束条件的符号

为了表示原因与原因之间，结果与结果之间可一、分析中国象棋中走马的实际情况（下面未注明的均指的是对马的说明）

1、如果落点在棋盘外，则不移动棋子；2、如果落点与起点不构成日字型，则不移动棋子；3、如果落点处有自己方棋子，则不移动棋子；4、如果在落点方向的邻近交叉点有棋子（绊马腿），则不移动棋子；5、如果不属于1-4条，且落点处无棋子，则移动棋子；6、如果不属于1-4条，且落点处为对方棋子(非老将)，则移动棋子并除去对方棋子；7、如果不属于1-4条，且落点处为对方老将，则移动棋子，并提示战胜对方，游戏结束。70一、分析中国象棋中走马的实际情况（下面未注明的均指的是对马的二、根据分析明确原因和结果原因：落点在棋盘上；落点与起点构成日字；落点处为自己方棋子；落点方向的邻近交叉点无棋子；落点处无棋子；落点处为对方棋子（非老将）；落点处为对方老将。71二、根据分析明确原因和结果71结果：

21、不移动棋子；

22、移动棋子；

23、移动棋子，并除去对方棋子；

24、移动棋子，并提示战胜对方，结束游戏。添加中间节点11，目的是作为导出结果的进一步原因，简化因果图导出的判定表72结果：72考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7不能同时发生，所以对其施加异约束E.73考虑结果不能同时发生，所以对其施加唯一约束O。原因5、6、7三、根据因果图建立判定表：(分为两表)12345678910111213141516原因10101010101010101200110011001100113000011110000111140000000011111111结果110000000100000000211111111011111111用例74三、根据因果图建立判定表：(分为两表)23456789101123456789`0111213141516原因110101010101010101500110011001100116000011110000111170000000011111111结果220010000230000100240000001用例注：1、以上判定表中由于表格大小限制没有列出最后所选的测试用例；2、第2表中部分列被合并表示不可能发生的现象；3、通过中间节点将用例的判定表简化为两个小表。减少工作量。75123456789`0111213141516原因110102.4白盒测试和黑盒测试的比较1、白盒测试只关注软件产品的测试，不能够确保产品已经实现了规格说明中的所有功能。黑盒测试则只关注规格说明中的功能测试，不能够保证已经实现的各个部分都被测试到。2、与黑盒测试相比，白盒测试的成本要高一些。3、黑盒测试故意不考虑控制结构，而只注意信息域。白盒测试只考虑测试软件产品，它不保证完整的需求规格是否被满足。黑盒测试是一种确认技术，回答“我们在构造一个正确的系统吗？白盒测试是一种验证技术，回答“我们在正确地构造一个系统吗？”

总之，建议测试人员在进行测试的过程中，可以考虑先使用黑盒测试，然后统计相应的覆盖率，再设计适当的白盒测试用例作为补充以保证测试的完整性。762.4白盒测试和黑盒测试的比较76

2.4.1白盒测试的优缺点

1）优点可构成测试数据对特定程序部分测试，可以检测代码中的每条分支和路径；揭示隐藏在代码中的错误；对代码的测试比较彻底；有较多工具支持；有一定的充分性度量手段。

2）缺点工作量大,成本高。通常只用于单元测试，有应用局限；无法检测代码中遗漏的路径和数据敏感性错误；不能验证规格说明的正确性；无法对规格说明中未实现的部分进行测试；不易生成测试数据(通常)。772.4.1白盒测试的优缺点772.4.2黑盒测试的优缺点优点对于较大的代码单元来说，效率高；测试人员不需要了解实现的细节，包括具体的编程语言；测试员和程序员可以由不同的人员来担任；从用户的角度进行测试，容易被理解和接受；有助于暴露任何规格不一致或有歧义的问题；测试用例的设计可以在规格说明完成之后马上进行；容易入手生成测试数据；适用于各阶段测试。782.4.2黑盒测试的优缺点78缺点 实际上，只有一小部分可能的输入被测试到，某些代码得不到测试；如果没有清晰、简洁的规格说明，难以设计测试用例；如果测试人员不知道开发人员已经执行过该测试用例，会存在不必要的重复测试；会有很多程序路径没有被测试到；不能直接针对可能隐蔽了许多问题的特定程序段进行测试，；如果规格说明有误，则无法发现；不易进行充分性测试。79缺点 792.4.3灰盒测试灰盒测试介于白盒测试和黑盒测试之间，是现代测试的一种理念。就是指，在白盒测试中交叉使用黑盒测试的方法；在黑盒测试中交叉使用白盒测试的方法。2.5测试方法的选择一、单元测试测试方法：白盒测试参考规范：详细设计说明和代码结构二、集成测试测试方法：黑盒和白盒测试参考规范：详细设计说明和概要设计说明802.4.3灰盒测试80实用策略:

黑盒设计白盒补充①在任何情况下都应该使用边界值分析的方法；②必要时用等价划分法补充；③必要时再用错误推测法补充；④对照程序逻辑，检查测试方案。可根据对程序可靠性的要求采用不同的逻辑覆盖标准，必要时补充一些测试方案。注:即使用上述综合策略设计测试方案，仍不能保证发现一切错误。例如Lucent公司经过包括逐行检查源代码在内的多方面测试之后，其软件能达标运行的成功率为:

80%

81实用策略:黑盒设计白盒补充81为什么需要一个测试策略

测试策略应该使测试过程中的交流变得更为容易，而它会影响到整个项目组。通过制定测试策略来指导我们的工作，项目组所碰到的具体问题：·

缺乏可重复性测试—项目缺少回归测试。·

缺乏可见性测试—没有收集衡量结果的指标，唯一的标准就是发布代码的期限。·

反作用的构建过程—只对项目的紧急程度构建响应，没有预测其他构建人的需要。·

没有对测试环境或测试数据进行控制。·

代码发布后，没有进行单元或集成测试。·

没有简单的自动化过程，没有测试过程。82为什么需要一个测试策略测试策略应该使测试过程中的交流变软件测试策略软件测试策略描述软件测试活动的总体方法和目标。为了检验开发的软件能否符合规格说明书的要求，测试活动可以采用各种不同的策略。这些策略的区别在于它们表明了不同的出发点、不同的思路以及采用不同的手段和方法。具体地说，包括要使用的测试技术和工具；测试完成标准；影响资源分配的特殊考虑等。83软件测试策略软件测试策略描述软件测试活动的总体方通常，制定软件测试策略要考虑如下的内容。（1）要使用的测试方法。（2）确定质量风险。（3）测试完成和测试成功所采用的评价标准。（4）有关资源要求或涉及进度的特殊考虑。（5）测试类型、评估标准以及测试方法。（6）确定资源。84通常，制定软件测试策略要考虑如下的内容。84

在制定测试策略时，你需要和项目中的关键人物一起，将关注点放在你们所面对的问题上，制定一个长期的解决方案，可以在整个项目周期内实施。除了上面列出的那些问题之外，我们的项目解决方案还要满足测试策略的基本需求：在开发周期内，帮助项目组尽可能早的找到最严重的bugs。想尽早地发现最严重的缺陷，需要把项目的测试部分和开发部分联合在一起，包括不同的测试阶段、测试类型、项目环境，以及如何在环境、角色、职责之间升级代码，还有普遍使用的工具。85在制定测试策略时，你需要和项目中的关键人物一起，将关注点写字板上的计划

第1步：基本策略轮廓第2步：目前的安排第3步：突如其来的改进第4步：组织计划

第5步：确定要使用的工具

86写字板上的计划第1步：基本策略轮廓86写字板上的计划实现过程准备:

清晰地定义简化的概念是简单性的保证。把想法和内容写到写字板上，它可以帮助人们共享意见和观点。这时候，写字板往往是最好的媒介。人们使用写字板时，会画一些漂亮的图和流程图，而这些图形符号每个人都能理解。人员：项目经理、开发主管、架构师、DBA（数据库管理员），以及其他一些关键人物。测试策略应该覆盖整个项目的生命周期，让每个人都能按照它的方式工作。87写字板上的计划实现过程准备:87第1步：基本策略轮廓—轮廓

首先，把每个你想要捕获、制定的测试方面写到写字板上，分成列的形式。把测试阶段（包含了项目所执行的测试类型）、不同的代码环境、衡量指标各分成了一列，其中的衡量指标决定何时在不同的环境之间移动代码。列出项目组当前并存执行的每个测试阶段；在测试阶段的下面，列出要执行的测试类型。寻找测试类型的过程，会帮助你清晰地定义测试阶段。同时，可以把每个阶段所代表的含义和产生的内容分成一组。这里没有所谓的“正确”定义；唯一重要的就是大家都认可你所使用的定义。你也可能需要定义测试的类型，但更重要的是确保每个人都能够理解如何区分不同的测试类型。要使大家能够自由地讨论测试策略，一个清晰的框架需要清晰的定义。88第1步：基本策略轮廓—轮廓首先，把每个你想要捕获、制定的测第2步：目前的安排—测试的当前状态

列出不同的项目环境，以及当前所使用的衡量指标。后者决定了何时在环境之间移动构建。在实际情况中，项目组会执行系统测试和一些回归测试，以及为少量用户提供的专门的接受测试。而缺少单元测试和集成测试的一致性，以及通常在代码提交给用户之后所要进行的代码复查工作。系统测试中，利用一些功能测试和生命周期测试，将大部分的需求做了验证。而在前面的迭代中，项目组执行了一个或两个临时的潜在测试，所以已经包含了那些测试。所有的回归测试，在时间允许的情况下，从前面的一次发布开始，是手工地基于测试用例的测试。89第2步：目前的安排—测试的当前状态列出不同的项目环境，以具有5个项目环境。

1、开发人员自己的本地环境

2、全部集成到一个普遍的开发环境中。

3、项目要构建一个测试环境，以进行系统测试的工作。

4、基于需求验证和发布日期（关键的衡量指标），把代码移动到质量保证（QA）的环境中。

5、用户根据发布的版本对大多数的期望功能进行复查，然后在一系列的结束标志（另一个关键的衡量指标）出现后，代码即可移动到产品中。在衡量指标的那一列中，我们对每个环境中的需求验证级别进行了讨论，确定了那些能准确地反映当前过程的数字。90具有5个项目环境。90第3步：突如其来的改进

—添加的测试类型和衡量指标

所有的人都同意了写字板上有关衡量指标的内容，就可以制定项目测试希望达到的目标。讨论一些有关实践和工具的内容，后者可以帮助提高效率，并与当前的资源（人力和财力）水平相符合。同时，由于很可能不能再扩大测试组的规模了，这样会设法让开发人员为测试提供帮助，而谈论的关注点也随之开始围绕在此问题上。也可以把关注点放在我们所经历的那些关键问题上。（即前面所罗列的那些问题吗？）91第3步：突如其来的改进

—添加的测试进行自由讨论，商定问题，并得到了一些结论：利用单元测试和集成测试，可以尽早地发现更多的问题，并准备好自动化测试的初始级别，同时，它们提供了一些衡量指标，这些指标让我们可以更好的跟踪开发过程。这样，可以做出决定—-何时移动代码。系统测试中，以每次发布用户基线为结束，用户基线会增长，同时他们也会逐渐地要求一些更为精确的性能测试。不能再依赖于需求验证，不能再继续将其作为主要的测试类型了。因为不能忽略安全性测试、可用性测试、配置测试和数据完整性测试，以及上百种其他类型的测试。进行一些基于session-based的探索性测试，而最初是以成对的方式执行该测试的，直到我们更为适应这种类型测试的过程，同时，也发展了我们快速学习和解决问题的能力。一旦我们适应了探索性测试的工作，那么我们可以开始执行更多的sessions。需要建立一个正规的且自动化的烟雾测试，它适用于所有的环境，它和自动化回归测试的脚本集一起被用来测试那些高风险的功能，以及高容量的事务处理。92进行自由讨论，商定问题，并得到了一些结论：92用户的接受测试（UAT）远远达不到它应有的效果。因此，要制定更为详细的UAT测试计划，将其与测试脚本和培训材料一起提供给用户，以帮助他们快速地提高。然而，这并不意味着能够全权负责UAT的工作，提供更多的指南、资源和培训来帮助用户进行接受测试，目的只是希望UAT执行的更为顺利。商定代码何时可以在环境之间移动的衡量指标。无论是单元测试，还是集成测试，90%的测试通过率对代码而言已经足够了，甚至可以从中了解到一些还会出现的bug。决定要执行严格的代码复查，以保证在早期（更可取的是在写完或接近完成代码时）就发现问题，而不是在代码发布之后。在创建烟雾测试之后，代码必须100%的通过这些测试，这样才能前进入下一个级别。系统测试中，无论如何都不能让任何严重或高级别的缺陷遗留到下一个过程中，但是也存在这样的一些缺陷，是能容忍的，可以和用户进行交流，以此来确定他们的期望：问题现在就被修复，还是放在后面解决。我们使用了代码覆盖的测试工具，根据它添加了一些相关的衡量指标，同时根据工具的缺陷趋势分析，来帮助我们衡量系统测试工作的效果。93用户的接受测试（UAT）远远达不到它应有的效果。因此，要制定第4步：组织计划—职责、环境询问了会议中每一个人，一起检查所达成的（写在写字板上）共识。下一步，划分职责和活动的实际区域范围。在写字板上做了相应的标注。在写字板上做了相应的标注，如用蓝色方括号和箭头。反映出项目中所包含的工作小组。项目可能包含了更多的工作小组—多个开发或测试组，甚至有独立的行政或QA组。写字板上的蓝色箭头表示要执行的测试类型与环境的关联关系。虽然还不算完美，但这些内容为我们提供了一个测试提纲，使我们知道了大多数测试工作的分布情况。94第4步：组织计划—职责、环境询问了会议中每一个人，一起检第5步：确定要使用的工具

—最终所形成的测试策略

测试中实际所使用的工具，把这些工具添加到的测试策略里。确定了主要的测试工具，当然，补充其他一些有帮助的工具。比如单元测试，可选用JUnit，开发人员知道该如何使用它。静态分析，我们选用Jlint。其他的工具，选用Rational的产品：使用ClearCase进行资源和测试资产的控制；使用ClearQuest跟踪问题；Purify、Quantify和PureCoverage被用来进行运行期分析；需求管理（rm）工具使用RequisitePro；自动化测试使用Robot和TestManager。95第5步：确定要使用的工具

实施

把测试策略作为一个可接受的解决方案，可以制定一个实施计划。在计划中，回答下面的问题：包含了各新测试类型的迭代过程是什么？（划分测试类型对应的每个迭代过程。）我们如何对之前没有做过测试的小组进行测试培训？（事关测试资源的利用和分配。）我们何时开始安装、配置新的测试工具，并进行相关的培训？（测试工具的使用问题，会影响测试的实际进度。）由谁来负责每个测试阶段的管理工作？（指定一个测试负责人。）我们如何计划这份测试策略的修订和更新工作？（需要控制测试策略的版本变更。）我们如何衡量这份测试策略的有效性？（对该测试策略的效果进行评估，评估的标准是什么？）由谁来负责该测试策略的维护工作？（我们应该有自己的配置管理员来维护这些测试资产。）96实施把测试策略作为一个可接受的解决方进一步思考进一步思考，会遇到其他一些实施方面的问题，这些和项目背景有关。但只要能确保下面的一些情况就可以了：拥有所需的资源（人、硬件和软件）；有时间和能力给项目组内的人做相关的培训；你是个越干越起劲的人。项目的测试策略还没有具体地实施。我们发现了一些变更，比之前面的更具效力。我们已经完成了测试策略，但每次的迭代过程，依然要关注具体的新工具和新技术，或者关注与人员的培训，以使其具有更高的效率。这里讨论的测试策略很简单，它具有的格式也使我们可以容易地修改和更新，不仅灵活，而且很有帮助性。97进一步思考进一步思考，会遇到其他一些实施方面的问题，这些和项优秀测试策略与测试用例的重要意义观点：对于公司测试部最重要的人是设计优秀测试策略和设计优秀测试方案的测试工程师。自动化测试脚本开发工程师和测试工具开发者对于测试部很重要，但是其影响也是低于前者的。

自动化测试开发和测试工具开发都是可以外包出去的。而测试策略设计和测试方案设计才是测试部最重要的人才队伍。

98优秀测试策略与测试用例的重要意义观点：对于公司测试部最重要的2.6测试计划与测试文档最常见的测试文档包括测试计划，测试规范，测试用例和测试时发现缺陷后要写的‘缺陷报告’等。那么，测试计划和测试文档在测试过程中能够发挥什么样的作用呢？1、测试文档有助于测试任务的完成。2、使用测试文档可以更好的协调测试任务与测试过程。3、测试文档为测试项目的组织、规划与管理提供了一个架构。992.6测试计划与测试文档992.6.1测试计划的制定为了给读者一个宏观的认识，首先请看测试计划活动图，如图2-20所示。在制定测试计划过程中，核心活动就是：一、确定测试策略通常，可以采用以下几个方法来制定测试策略：1、确定测试的范围2、确定测试的方法3、确定测试标准和质量检查点4、确定自动化测试策略二、确定测试系统（硬件和软件）1、测试架构测试架构指的就是测试用例的组织结构。1002.6.1测试计划的制定为了给读者一个宏观的认识，首先请

图2-20

测试计划活动101图1012、测试工具3、测试环境测试环境的组成包括物理测试设施，产品运行的操作系统、产品运行的计算平台等。4、测试配置情况需要排列配置的优先级，然后决定哪些配置需要全面测试，哪些可以进行部分测试。三、预估测试工作量（资源和时间进度计划）对项目进行预估有5个准备步骤：1、确定要完成的任务。2、确定每项任务所需的工作量和整个测试生命周期的工作量。1022、测试工具102制定测试计划的原则制定测试计划是软件测试中最有挑战性的一个工作。以下原则将有助于制定测试计划工作。1．制定测试计划应尽早开始2．保持测试计划的灵活性3．保持测试计划简洁和易读4．尽量争取多渠道评审测试计划5．计算测试计划的投入103制定测试计划的原则103制定测试计划时面对的问题制定测试计划时，测试人员可能面对以下问题，必须认真对待，并妥善予以处理。

1．与开发者意见不一致

2．缺乏测试工具

3．培训不够104制定测试计划时面对的问题1044．管理部门缺乏对测试工作的理解和支持5．缺乏用户的参与6．测试时间不足7．过分依赖测试人员8．测试人员处于进退两难的状态9．不得不说“不”1054．管理部门缺乏对测试工作的理解和支持105制定测试计划制定测试计划时，由于各软件公司的背景不同，测试计划文档也略有差异。实践表明，制定测试计划时，使用正规化文档通常比较好。为了使用方便，在这里给出IEEE软件测试计划文档模板。106制定测试计划106107107根据IEEE829－1998软件测试文档编制标准的建议，测试计划包含了16个大纲要项，简要说明如下。1．测试计划标识符一个测试计划标识符是一个由公司生成的惟一值，它用于标识测试计划的版本、等级，以及与该测试计划相关的软件版本。108根据IEEE829－1998软件测试文档编制标准的2．介绍在测试计划的介绍部分主要是测试软件基本情况的介绍和测试范围的概括性描述。1092．介绍1093．测试项测试项部分主要是纲领性描述在测试范围内对哪些具体内容进行测试，确定一个包含所有测试项在内的一览表。具体要点如下。

功能的测试

设计的测试

整体测试1103．测试项110IEEE标准中指出，可以参考下面的文档来完成测试项：

需求规格说明

用户指南

操作指南

安装指南

与测试项相关的事件报告111IEEE标准中指出，可以参考下面的文档来完成测试项：1114．需要测试的功能测试计划中这一部分列出了待测的功能。5．方法（策略）这部分内容是测试计划的核心所在，所以有些软件公司更愿意将其标记为“策略”，而不是“方法”。1124．需要测试的功能112测试策略描述测试小组用于测试整体和每个阶段的方法。要描述如何公正、客观地开展测试，要考虑模块、功能、整体、系统、版本、压力、性能、配置和安装等各个因素的影响，要尽可能地考虑到细节，越详细越好，并制作测试记录文档的模板，为即将开始的测试做准备。测试记录具体说明如下。113测试策略描述测试小组用于测试整体和每个阶段的方法

公正性声明

测试用例

特殊考虑

经验判断

设想114公正性声明1146．不需要测试的功能测试计划中这一部分列出了不需要测试的功能。7．测试项通过/失败的标准测试计划中这一部分给出了“测试项”中描述的每一个测试项通过/失败的标准。正如每个测试用例都需要一个预期的结果一样，每个测试项同样都需要一个预期的结果。1156．不需要测试的功能115下面是通过/失败的标准的一些例子：

通过测试用例所占的百分比；

缺陷的数量、严重程度和分布情况；

测试用例覆盖；

用户测试的成功结论；

文档的完整性；

性能标准。116下面是通过/失败的标准的一些例子：1168．测试中断和恢复的规定测试计划中这一部分给出了测试中断和恢复的标准。常用的测试中断标准如下：

关键路径上的未完成任务

大量的缺陷

严重的缺陷

不完整的测试环境

资源短缺1178．测试中断和恢复的规定1179．测试完成所提交的材料测试完成所提交的材料包含了测试工作开发设计的所有文档、工具等。例如，测试计划、测试设计规格说明、测试用例、测试日志、测试数据、自定义工具、测试缺陷报告和测试总结报告等。1189．测试完成所提交的材料11810．测试任务测试计划中这一部分给出了测试工作所需完成的一系列任务。在这里还列举了所有任务之间的依赖关系和可能需要的特殊技能。11910．测试任务11911．环境需求环境需求是确定实现测试策略必备条件的过程。例如：

人员——人数、经验和专长。他们是全职、兼职、业余还是学生？

设备——计算机、测试硬件、打印机、测试工具等。12011．环境需求120

办公室和实验室空间——在哪里？空间有多大？怎样排列？

软件——字处理程序、数据库程序和自定义工具等。

其他资源——软盘、电话、参考书、培训资料等。121办公室和实验室空间——在哪里？空间有多大？怎样排列？112．测试人员的工作职责测试人员的工作职责是明确指出了测试任务和测试人员的工作责任。有时测试需要定义的任务类型不容易分清，不像程序员所编写的程序那样明确。复杂的任务可能有多个执行者，或者由多人共同负责。12212．测试人员的工作职责12213．人员安排与培训需求前面讨论的测试人员的工作职责是指哪类人员（管理、测试和程序员等）负责哪些任务。人员安排与培训需求是指明确测试人员具体负责软件测试的哪些部分、哪些可测试性能，以及他们需要掌握的技能等。实际责任表会更加详细，确保软件的每一部分都有人进行测试。每一个测试员都会清楚地知道自己应该负责什么，而且有足够的信息开始设计测试用例。12313．人员安排与培训需求123培训需求通常包括学习如何使用某个工具、测试方法、缺陷跟踪系统、配置管理，或者与被测试系统相关的业务基础知识。培训需求各个测试项目会各不相同，它取决于具体项目的情况。124培训需求通常包括学习如何使用某个工具、测试方法、14．进度表测试进度是围绕着包含在项目计划中的主要事件（如文档、模块的交付日期，接口的可用性等）来构造的。作为测试计划的一部分，完成测试进度计划安排，可以为项目管理员提供信息，以便更好地安排整个项目的进度。12514．进度表125表4给出了一个例子。126表4给出了一个例子。126进度安排会使测试过程容易管理。通常，项目管理员或者测试管理员最终负责进度安排，而测试人员参与安排自己的具体任务。127进度安排会使测试过程容易管理。通常，项目管理员或15．潜在的问题和风险软件测试人员要明确地指出计划过程中的风险，并与测试管理员和项目管理员交换意见。这些风险应该在测试计划中明确指出，在进度中予以考虑。有些风险是真正存在的，而有些最终证实是无所谓的，重要的是尽早明确指出，以免在项目晚期发现时感到惊慌。12815．潜在的问题和风险128一般而言，大多数测试小组都会发现自己的资源有限，不可能穷尽测试软件所有方面。如果能勾画出风险的轮廓，将有助于测试人员排定待测试项的优先顺序，并且有助于集中精力去关注那些极有可能发生失效的领域。下面是一些潜在的问题和风险的例子：129一般而言，大多数测试小组都会发现自己的资源有限，

不现实的交付日期

与其他系统的接口

处理巨额现金的特征

极其复杂的软件

有过缺陷历史的模块

发生过许多或者复杂变更的模块

安全性、性能和可靠性问题

难于变更或测试的特征