《软件工程与开发技术》课件第6章

第6章软件测试技术6.1软件测试基础

6.2白盒测试技术

6.3黑盒测试技术6.4软件测试计划和测试分析报告

6.5软件测试策略

6.6小结6.1软件测试基础6.1.1软件测试的概念、目的和原则

1.软件测试的概念软件测试是在软件投入运行前对软件需求分析、软件设计规格说明和软件编码进行查错和纠错(包括代码执行活动与人工活动)。找错的活动称测试，纠错的活动称调试。可以说，软件测试是为了发现错误而执行程序的过程。或者说，软件测试是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例(即输入数据及其预期的输出结果)，并利用这些测试用例去运行程序，以发现程序错误的过程。

2.软件测试的目的

GlenMyers在他的软件测试著作中就软件测试的目的提出下列观点：

(1)测试是一个为了寻找错误而运行程序的过程。

(2)一个好的测试用例是指很可能找到迄今为止尚未发现的错误的用例。

(3)一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。

正确认识测试的目的是十分重要的，只有这样，才能设计出最能暴露错误的测试方案。测试的目的应从用户角度出发，通过软件测试暴露软件中潜在的错误和缺陷，而不是从软件开发者的角度出发，希望测试成为表明软件产品不存在错误，验证软件已正确实现用户的要求的过程。否则，开发者测试时会选择不易测试出错误和缺陷的用例，这与上述测试目的相违背。一个成功的测试是指揭示了迄今为止尚未发现的错误的测试。测试的目标是能够以耗费最少时间与最小工作量找出软件系统中潜在的各种错误与缺陷。另外，我们应该认识到：测试只能证明程序中错误的存在，但不能证明程序中没有错误。因为即使实施了最严格的测试，仍然可能还有尚未被发现的错误或缺陷存在于程序当中，因而测试不能证明程序没有错误，但可能查出程序中的错误。

3.软件测试的基本原则人们为了提高测试的效率，在长期测试实验中积累了不少经验，下面列出了人们在实践中总结的主要基本原则：

(1)尽早地并不断地进行软件测试。实际问题的复杂性、软件本身的复杂性与抽象性以及开发期各层人员工作的配合关系等各种错综复杂的因素使得软件开发的各个阶段都可能存在错误及潜在的缺陷。所以，软件开发的各阶段都应当进行测试。错误发现得越早，后阶段耗费的人力、财力就越少，软件质量相对就高一些。(2)程序员或程序设计机构应避免测试自己设计的程序。测试是为了找错，而程序员大多对自己所编的程序存有偏见，总认为自己编的程序问题不大或无错误存在，因此很难查出错误。此外，设计机构在测试自己程序时，由于开发周期和经费等问题的限制，要采用客观的态度是十分困难的。从工作效率来讲，最好由与原程序无关的程序员和程序设计机构进行测试。(3)测试用例中不仅要有输入数据，还要有与之对应的预期结果。测试前应当设定合理的测试用例。测试用例不仅要有输入数据，而且还要有与之对应的预期结果。如果在程序执行前无法确定预期的测试结果，由于人们的心理作用，可能把实际上是错误的结果当成是正确的。(4)测试用例的设计不仅要有合法的输入数据，还要有非法的输入数据。在设计测试用例时，不仅要有合法的输入测试用例，还要有非法的输入测试用例。在测试程序时，人们常忽视不合法的和预想不到的输入条件，倾向于考虑合法的和预期的输入条件。而在软件的实际使用过程中，由于各种因素的存在，用户可能会使用一些非法的输入，比如常会按错键或使用不合法的命令。对于一个功能较完善的软件来说，不仅当输入是合法的时候能正确运行，而且当有非法输入时，也应当能对非法的输入拒绝接受，同时给出对应的提示信息，使得软件便于使用。(5)在对程序修改之后要进行回归测试。在修改程序的同时时常又会引进新的错误，因而在对程序修改完之后，还应用以前的测试用例进行回归测试，有助于发现因修改程序而引进的新的错误。(6)程序中尚未发现的错误的数量通常与该程序中已发现的错误的数量成正比。经验表明：一段程序中若发现错误的数目越多，则此段程序中残存的错误数目也较多。例如：在美国的IBM/370的一个操作系统中，47%的错误(由用户发现的错误)仅与该系统的4%的程序模块有关。据此规律，在实际测验时，为了提高测试效率，要花较多的时间和代价来测试那些容易出错即出错多的程序段。而不要以为找到了几个错误，就认为问题已解决，不再需要继续测试了。(7)妥善保留测试计划、全部测试用例、出错统计和最终分析报告，并把它们作为软件的组成部分之一，为维护提供方便。设计测试用例要耗费相当大的工作量，若测试完随意丢弃，以后一旦程序改错后需重新测试时，将重复设计测试用例，这会造成很大的浪费，因而妥善保留与测试有关的资料，能为后期的维护工作带来方便。

(8)应当对每一个测试结果做全面检查。这条重要的原则时常被人们忽视。不仔细、全面地检查测试结果，就会使得有错误征兆的输出结果被漏掉。(9)严格执行测试计划，排除测试的随意性。测试计划内容应包括：所测软件的功能、输入和输出、测试内容、各项测试的进度安排、资源要求、测试资料、测试工具、测试用例的选择、测试的控制方式和过程、系统组装方式、跟踪规程、调试规程、回归测试的规定以及评价标准等。6.1.2软件测试的过程图6.1测试的过程

测试过程有三类输入：软件配置、测试配置和测试工具。软件配置包括软件需求说明书、设计说明书、源程序清单等文档。测试配置包括测试方案、测试计划、测试用例、测试驱动程序等文档。测试工具包括支持测试的软件。输出信息有修正软件的文件和预测可靠性或得出纠错后可交付使用的正确软件。测试的信息流是不断递归的过程，也是相对有限的测试过程，而不是无限的过程。

(1)软件配置：指被测试软件的文件，如软件需求规格说明书、软件设计说明书和源程序清单等文档。(2)测试配置：指测试方案、测试计划、测试用例、测试驱动程序等文档。实际上，在整个软件工程过程中，测试配置只是软件配置的一个子集。

(3)测试工具：是为了提高测试效率而设计的支持软件测试的软件。例如，测试数据自动生成程序、静态分析程序、动态分析程序、测试结果分析程序以及驱动测试的测试数据库等。

(4)测试评价：由测试出的错误迹象，分析、找出错误的原因和位置，以便纠正和积累软件设计的经验。(5)纠错(调试)：是指找到出错的原因与位置并纠错，包括修正文件直到软件正确为止。纠错过程是测试过程中最无法预料的部分。为了诊断和纠正一个错误，可能需要一小时、一天、甚至几个月的时间。正是因为纠错本身所具有的不确定性，常常难以准确地安排测试日程表。(6)可靠性模型：通过对测试出的软件出错率的分析，建立模型，得出可靠的数据，指导软件的设计与维护。对测试结果进行收集和评价后，软件可靠性能够达到的质量指标也就清楚了。若出现一些有规律的、严重的、要求修改设计的错误，软件的质量和可靠性值得怀疑，应作进一步测试。另外，若软件功能看来完成得很好且遇到错误也容易纠正，从而可以得到两种不同的结论：一种是软件质量和可靠性是可以接受的；另一种是所进行的测试尚不足以发现严重的错误。若没有发现任何错误，可能是由于测试配置不够周到，依然有潜在的错误存在。若将错误放过，在维护阶段被用户发现时再纠正的话，所需费用将可能是开发阶段的40～60倍。6.1.3软件测试的方法软件测试的目的是以最少的测试用例集合测试出更多的程序中潜在错误。如何测试的彻底，怎样设计测试用例是测试的关键技术。依据测试过程是否在实际应用环境中来分，软件测试技术分为静态分析技术与动态测试技术两种。测试方法有分析方法(包括静态分析法与白盒法)与非分析方法(称黑盒法)之分。有关白盒法与黑盒法的内容将在后两节中介绍，在此节中仅介绍静态分析技术与动态测试技术。

1.静态分析技术静态分析技术不执行被测试软件，可对需求分析说明书、软件设计说明书、源程序做结构检查、流图分析、符号执行等来找出软件错误。可以人工进行分析，也可以用测试工具静态分析程序来进行，被测试程序的正文作为输入，经静态分析程序分析得出分析结果。

(1)结构检查是手工分析技术，由一组人员对程序设计、需求分析、编码测试工作进行评议，虚拟执行程序，并在评议中作错误检验。此方法能找出典型程序30%～70%有关逻辑设计与编码的错误。(2)流图分析是通过分析程序流程图的代码结构，来检查程序的语法错误信息、语句中标识符引用状况、子程序和函数调用状况及无法执行到的代码段。此方法便于分析编码实现与测试结果分析。

(3)符号执行是一种符号化定义数据，并为程序每条路径给出符号表达式，对特定路径输入符号，经处理输出符号，从而判断程序行为是否错误，达到分析错误目的的方法。这种方法比数值计算复杂得多，易出错，又不适于非数值计算，故使用较少。

2.动态测试技术动态分析是执行被测程序，由执行结果分析程序可能出现的错误。可以人工设计程序测试用例，也可以由测试工具动态分析程序来做检查与分析。动态测试包括功能测试和结构测试。它把程序看作为一个函数，输入的全体称为函数的定义域，输出的全体称为函数的值域，函数则描述了输入的定义域与输出值域的关系。这样动态测试的算法可归纳为(1)选取定义域中的有效值，或定义域外无效值。(2)对已选取值决定预期的结果。(3)用选取值执行程序。(4)观察程序行为，记录执行结果。(5)将(4)的结果与(2)的结果相比较，不吻合则程序有错。动态测试既可以采用白盒法对模块进行逻辑结构的测试，又可以用黑盒法做功能结构的测试。接口的测试，都是以执行程序并分析执行结果来查错的。6.2白盒测试技术6.2.1白盒测试概念如果已知产品的内部活动方式，就可以测试它的内部活动是否都符合设计要求。这种方法称白盒测试(White-boxTesting)，它是对软件的过程性细节做细致的检查。白盒测试又称为结构测试或逻辑驱动测试，此方法是将测试对象比作一个打开的盒子，它允许测试人员利用程序内部的逻辑结构和相关信息来设计或选择测试用例，对穿过软件的逻辑路径进行测试，可以在不同点检查程序的状态，以确定实际状态与预期状态是否一致。

软件人员使用白盒方法测试程序模块的检查点主要包括：对程序模块的所有独立的执行路径应至少测试一次；对所有的逻辑判定，取“真”与取“假”两种情况都能至少测试一次；在循环的边界和运行界限内执行循环体；测试内部数据结构的有效性等。表面看来，白盒测试是可以进行完全的测试的，从理论上讲也应该如此。只要能确定测试模块的所有逻辑路径，并为每一条逻辑路径设计测试用例，并评价所得到的结果，就可得到100%正确的程序。但实际测试中，这种穷举法是无法实现的，因为即使是很小的程序，也可能会出现数目惊人的逻辑路径。如图6.2所示是一个小程序的流程图。

图中，一个圆圈代表一行源程序代码(或一个语句块)。其中有五条通路，左边曲线箭头表示执行次数不超过20次循环。这样的执行路径就有520个，近似为1014个可能的路径。如果1ms完成一个测试，由此测试程序需3170年。由此看出，即使精确地实现了白盒测试，也不能断言测试过的程序全正确，因为实行穷举测试，由于工作量过大，需用时间过长，实施起来是不现实的。这就是程序测试的经济学问题。既然在测试阶段穷举法测试是不可行的，那么为了节省时间和资源，提高测试效率，就必须精心设计测试用例。需从大量的可用测试用例中精选出少量的测试数据，使得采用这些测试数据能够达到最佳的测试效果，即能高效地、尽可能多地发现隐藏的错误。测试只能发现错误，并不能保证程序没有错误。图6.2白盒测试中的穷举测试6.2.2白盒测试的测试用例设计测试用例设计的基本目的是确定一组最有可能发现某个错误或某类错误的测试数据。无论是黑盒测试(下节内容介绍)，还是白盒测试都不可能进行穷举测试，所以测试用例的设计只能在周期和经费允许的条件下，使用最少数目的测试用例，发现最大数目可能的错误。实际工作中，采用黑盒与白盒相结合的技术是较为合理的做法，可以选取并测试数量有限的重要逻辑路径，对一些重要数据结构的正确性进行完全的检查。这样不仅能证实软件接口的正确性，同时在某种程度上能保证软件内部工作也是正确的。

现在已经提出了许多测试用例的设计技术。下面只对白盒测试的重要测试方法进行介绍，黑盒测试的方法将在下节内容中介绍。逻辑覆盖是以程序内部逻辑为基础的测试技术，属白盒测试。这一测试考虑测试用例对程序内部逻辑覆盖的程度。当然，最彻底的覆盖是覆盖程序中的每一条路径，但是由于程序中可能会含有循环，路径的数目将极大，要执行每一条路径是不可能的，所以只希望覆盖的程度尽可能高些。目前常用的一些覆盖技术有以下八种。

1.语句覆盖语句覆盖的含义是选择足够多的测试用例，使得被测程序中的每条语句至少执行一次。图6.3是测试的一段程序的流程图对应的C源程序(用C语言书写)。floatA,B,X;

if(A＞1&&B==0)X=X/A;if(A==2||X>1)X=X+1;……

为了使每条语句都执行一次，程序应该按sacbed路径执行，为实现此路径而选取下面的一组输入数据(实际上X可以是任意实数):A=2,B=0,X=2

通过上例可以看出，这组数据只测试了条件为真的情况，若实际输入的条件为假时有错误显然测试不出来。事实上，语句覆盖对程序的逻辑覆盖很少，语句覆盖只关心判定表达式的值，而没有分别测试判定表达式中每个条件取不同值的情况。在上例中，为了执行sacbed路径以测试每个语句，只需两个判定表达(A＞1)AND(B=0)和(A=2)OR(X＞1)都取真值，上例中测试数据足够满足要求。但是，若程序中第一个判断表达式中的逻辑运算符“AND”错写成“OR”，或把第二个判定表达式中的条件“X＞1”误写成“X＜1”，上组测试数据则不符要求，不能查出这些错误。与后面所介绍的其他覆盖相比，语句覆盖是最弱的逻辑覆盖准则。

2.判定覆盖判定覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的取真分支和取假分支至少经历一次。判定覆盖又称为分支覆盖。判定覆盖的每个语句至少经历一次。例如对于图6.3来说，能够分别覆盖路径sacbed和sabd的一组测试数据，或者覆盖路径sacbd和sabed的两组测试数据均可满足判定覆盖标准。例如，以两组测试数据就可做到判定覆盖：

(1)A=4，B=0，X=1(覆盖sacbd)；

(2)A=2，B=1，X=3(覆盖sabed)。判定覆盖的缺点仍然是覆盖的不全，只覆盖了路径的一半，如将X＞1误写成X＜1，上组(1)数据仍覆盖sacbd，可见判定覆盖仍然很弱，但比语句覆盖强。图6.3语句覆盖

3.条件覆盖条件覆盖就是设计若干个测试用例，运行所测程序，使得程序中每个判断的每个条件的可能取值至少执行一次。条件覆盖使得每个语句至少执行一次。例如对于图6.3来说，共有两个判定表达式，每个表达式中有两个条件。为满足条件覆盖，在a点有以下几种情况出现：A＞1，A≤1，B＝0，B≠0；在b点有以下几种情况出现：A=2，A≠2，X＞1，X≤1。因而，只需要使用下面两组测试数据就可达到上述覆盖标准。(1)A=2，B=0，X=3(满足A＞1，B＝0，A=2和X＞1的条件，执行路径sacbed)；

(2)A=0，B=1，X=0(满足A≤1，B≠0，A≠2和X≤1的条件执行路径sabd)。

条件覆盖一般比判定覆盖强，因为条件覆盖使判定表达式中每个条件都取到了两个不同的结果，判定覆盖却只关心整个判定表达式的值。上例两组测试数据也同时满足判定覆盖标准。但是，也可能有相反情况：虽然每个条件都取到了两个不同的结果，判定表达式却始终只取一个值。例如，若使用以下两组测试数据，则只满足条件覆盖标准并不满足判定覆盖标准。

(1)A=2，B=0，X=1(满足A＞1，B＝0，A=2和X≤1的条件，执行路径sacbed)；

(2)A=1，B=1，X=2(满足A≤1，B≠0，A≠2和X＞1的条件，执行路径sabed)。上述例子的第二个判定表达式的值总为真，不满足判定覆盖的要求，为解决这一矛盾，需要对条件和分支兼顾。

4.判定/条件覆盖判定/条件覆盖就是设计足够的测试用例，使得判断中每个条件的所有可能取值至少执行一次，同时每个判断的所有可能判断结果至少执行一次。即要求各个判断的所有可能的条件取值组合至少执行一次。对于图6.3的例子而言，下述两组测试数据满足判定/条件覆盖标准。(1)A=2，B=0，X=4；(2)A=1，B=1，X=1。

判定/条件覆盖也有缺陷。从表面来看，它测试了所有条件的取值。但实际并不是这样。因为一些条件往往掩盖了另一些条件。对于条件表达式(A＞1)AND(B=0)来说，只要(A＞1)的测试为真，才需测试(B=0)的值来确定此表达式的值，但是若(A＞1)的测试值为假时，不需再测(B=0)的值就可确定此表达式的值为假，因而B=0没有被检查。同理，对于(A=2)OR(X＞1)这个表达式来说，只要(A=2)测试结果为真，不必测试(X＞1)的结果就可确定表达式的值为真。所以对于判定/条件覆盖来说，逻辑表达式中的错误不一定能够查得出来。

5.条件组合覆盖条件组合覆盖就是设计足够的测试用例，运行所测程序，使得每个判断的所有可能的条件取值组合至少执行一次。对于图6.3的例子来说，共有以下八种可能的条件组合：(1)A＞1，B=0属第一个判断的取真分支；(2)A＞1，B≠0属第一个判断的取假分支；(3)A≤1，B=0属第一个判断的取假分支；(4)A≤1，B≠0属第一个判断的取假分支；(5)A＝2，X＞1属第二个判断的取真分支；(6)A＝2，X≤1属第二个判断的取真分支；(7)A≠2，X＞1属第二个判断的取真分支；(8)A≠2，X≤1属第二个判断的取假分支。

对于每个判断，要求所有可能的条件的取值组合都必须取到。在图6.3中，每个判断各有两个条件，所以各有四个条件取值的组合。下面的四组测试数据可以使上面列出的八种组合每种至少出现一次：

(1)A=2，B=0，X=4(针对(1)，(5)两种组合，执行路径sacbed)；

(2)A=2，B=1，X=1(针对(2)，(6)两种组合，执行路径sabed)；

(3)A=1，B=0，X=2(针对(3)，(7)两种组合，执行路径sabed)；

(4)A=1，B=1，X=1(针对(4)，(8)两种组合，执行路径sabd)。

必须明确：在此例中条件组合覆盖并未要求第一个判定的四个组合与第二个判定的四个组合再进行组合，要那样的话，就需42=16个测试用例了。显然，满足条件组合覆盖标准的测试数据，也一定满足判定覆盖、条件覆盖和判定/条件覆盖标准。因此，条件组合覆盖是前述几种覆盖标准中最强的。但是，满足条件覆盖标准的测试数据并不一定能使程序中的每条路径都执行到，如上述四组测试数据都没有测试到路径sacbd。以上简单介绍了几种逻辑覆盖标准。在上述过程中，实现了多次涉及到测试数据执行的路径测试。显然，测试数据可检测的程序路径的多少也反映了对程序测试的详尽程度。从对程序路径的覆盖程度分析，下面提出一些主要的逻辑覆盖标准。

6.点覆盖点覆盖是设计足够的测试数据，使程序执行时至少经过程序图中每个节点一次。图论中，点覆盖的概念定义如下：如果连通图G的子图G"是连通的，且包含G的所有节点，则称G"是G的点覆盖。在正常情况下，程序图是连通的有向图，图中每个节点相当于程序流程图中的一框(一个或多个语句)，所以点覆盖相当于语句覆盖。

7.边覆盖边覆盖是设计足够的测试数据，使得程序执行路径至少经过程序图中每一个边一次，相应的图论中的定义是：如果连通图G和子图G"是连通的，而且G"包含G的所有边，则称G"是G的边覆盖。图6.4是由图6.3得出的程序图。为了使程序执行路径经过程序图的边覆盖(1，2，3，4，5，6，7)，至少需要两组测试数据(分别执行路径1-2-3和1-4-5-6-7，或分别执行路径1-4-5-3和1-2-6-7)。

一般情况下，边覆盖和判定覆盖是一致的。例如，上述中满足判定覆盖标准的测试数据同时满足边覆盖的标准。(1)A=4，B=0，X=1(执行路径1-4-5-3，即覆盖sacbd)；(2)A=2，B=1，X=3(执行路径1-2-6-7，即覆盖sacbd)。图6.4和图6.3对应的程序图

8.路径覆盖路径覆盖是选取足够多测试数据，使程序的每条可能路径都至少执行一次(若程序图中存在环，则要求每个环至少经过一次)。对于图6.4而言，共有四条可执行的路径：1-2-3；1-2-6-7；1-4-5-3和1-4-5-6-7。对应于这四条路径，下面四组测试数据可以满足路径覆盖标准：(1)A=1，B=1，X=1(执行路径1-2-3)；(2)A=1，B=1，X=2(执行路径1-2-6-7)；(3)A=3，B=0，X=1(执行路径1-4-5-3)；(4)A=2，B=0，X=4(执行路径1-4-5-6-7)。

路径覆盖相对来说是相当强的逻辑覆盖标准。测试数据暴露程序错误的能力比较强，有一定的代表性，它能够保证程序中每条可能的路径都至少执行一次。但是路径覆盖并没有检验表达式中条件的各种组合情况，而只考虑每个判定表达式的取值。若把路径覆盖和条件覆盖组合起来，可以设计出检错能力更强的测试数据。6.3黑盒测试技术6.3.1黑盒测试概念黑盒测试方法是在已知产品应该具有的功能的情况下，通过测试来检验是否每个功能都能正常使用的测试方法。对于软件测试而言，黑盒测试法把程序看成一个黑盒子，完全不考虑程序的内部结构和处理过程。黑盒测试是在程序接口进行的测试，它只检查程序功能是否能按照规格说明书的规定正常使用，程序是否能适当地接收输入数据产生正确的输出信息，并且保持外部信息(如数据库或文件)的完整性。黑盒测试又称功能测试。使用黑盒测试法，为了做到穷尽测试，至少必须对所有输入数据的各种可能值的排列组合都进行测试。与白盒法相似，由此得到的应测试的情况数往往大到实际上根本无法测试的程度，即黑盒测试使用所有有效和无效的输入数据来测试程序是不现实的。所以，黑盒测试同样不能做到穷尽测试，只能选取少量最有代表性的输入数据，以期用较少的代价暴露出较多的程序错误。6.3.2黑盒测试的测试用例设计

1.等价类划分

1)划分等价类等价类划分是黑盒法设计测试方案的一种典型的、实用的重要测试方法。等价类划分是根据数据测试的等效性原理来进行划分的。数据测试的等效性是指将分类的数据取其子集中一个数据做测试与子集中其他数据测试的效果是等效的，即子集中的一个数据能测出软件错误，那么子集中的其余数据也能测出错误；相反，子集中的一个数据测试不出程序错误，子集中的其余数据也测不出错误。

等价类划分是把程序的输入数据集合按输入条件划分为若干个等价类，每一个等价类相对于输入条件表示为一组有效或无效的输入，然后为每一等价类设计一个测试用例。如果某个等价类中的一个输入条件作为测试数据查出了错误，那么使用这一等价类中的其他输入条件，也会查出同样的错误；反之，若使用某个等价类中的一个输入条件作为数据进行测试没有查出错误，则使用这个等价类中的其他输入条件也同样查不出错误。简单地讲，有效等价类是指程序的合理输入数据，利用它可检验程序是否能实现预期的功能和性能。无效等价类是指其他不合理、无意义的数据，利用它可检查程序中功能和性能的实现是否不符合规格说明要求。在确定输入等价类时还需要分析输出数据的等价类，以便根据输出数据的等价类导出对应的输入等价类。等价类的划分在很大程度上是一个探索性的过程，主要依靠的是测试人员的经验，下面几点仅供参考。(1)如果某个输入条件规定了输入值的范围(其数值为1～999)，则可划分为一个合理等价类(大于等于1而小于等于999的数)和两个不合理的等价类(小于1和大于999的数)。

(2)如果某个输入条件规定了输入数据的个数(如每名学生一学期内只能选修1～3门课程)，则可划分为一个高效等价类(选修1～3门课程)和两个无效等价类(不选修和选修超过3门)。

(3)如果某个输入条件规定了一组可能的值，而且程序可以对每个输入值分别进行处理(如出差时交通工具的类型必须是火车、汽车或轮船)，那么可以为每一组确定一个有效等价类(如火车、汽车和轮船三种)，同时对一组值确定一个无效等价类(如飞机)。(4)如果某个输入条件规定了必须成立的条件(比如标识符的第一个字符必须是字母)，则可划分为一个有效等价类(第一个字符是字母)和一个无效等价类(第一个字符不是字母)。

(5)如果认为程序将按不同的方式来处理某个等价类中的各种测试用例，则应将这个等价类再分成几个更小的等价类。如上面第③点就将一个有效的等价类又分成火车、汽车和轮船三个等价类。

(6)如果输入条件是一个布尔量，则可以确定一个有效等价类和一个无效等价类。

(7)如果规定了输入数据为整数，则可以划分为正整数、零和负整数三个有效等价类为测试数据。2)确定测试用例根据等价类来设计测试用例，其过程如下：

(1)为每个等价类规定一个惟一的编号。

(2)设计一个新的测试用例，使其尽可能多地覆盖未被覆盖的有效等价类，此项工作重复进行，直到所有的有效等价类都被覆盖为止。

(3)设计一个新的测试用例，使其覆盖一个(而且仅仅一个)尚未被覆盖的无效等价类，此项工作重复进行，直到所有的无效等价类都被覆盖为止。

之所以要这样做，是因为某些程序中对某一输入错误的检查往往会屏蔽对其他输入错误的检查，因此，必须针对每一个无效等价类，分别设计测试用例。例如，某程序的功能说明规定：输入书的类型分别为精装本、平装本或线装本，书的数量为1～999册。若测试用例的输入数据类型为“活页”，且书目的数量为“0”，此情况覆盖了两个不合理的条件(类型和数量都是错误的)。当程序检查到书的类型错误时，就可能不再去检查数量是否也是错误的。3)用等价类划分法设计测试用例的案例某Pascal语言将数字串转换为整数的函数说明如下：

Functionstroint(dstr:shorstr):integer;typeshorstr=array[1··]ofchar其中，参数为shorstr，被处理的数字串是右对齐的，也就是说，当数字串比六个字符短，则在它的左边补空格；如果数字串是负的，则负号和最高位数字紧相邻，负号在最高位数字左边一列。…

由于Pascal编译程序有检测字符串超界的功能，所以数字串不等于六的数组可不设计测试用例，又由于Pascal编译能检测数组类型，所以也不需要为非字符数组类型做测试数据。由于所用计算机字长16位，所以用二进制数表示的范围为－32768～32767。依据输入/输出的有效与无效等价类划分如下。有效输入等价类有：①1～6个数字组成的数字串(最高位数字不是零)②最高位数字是零的数字串③最高位数字左邻是负号的数字串有效输出的等价类：①在计算机能表示的最小负整数和零之间的负整数②零③在零和计算机能表示的最大正整数之间的正整数无效输入等价类：①空字符串(全是空格)②左部填充的字符，既不是零也不是空格③最高位数后面，由数字和空格混合组成④负号与取高位数之间的空格⑤最高位数字右面，由数字和其他字符混合组成

无效输出的等价类：①比计算机能表示的最小负数还小的负整数②比计算机能表示的最大正整数还大的正整数依据上面划分出的等价类，可以设计下述测试方案(每个测试方案由三部分内容组成)：

(1)输入是1～6个数字组成的数字串，输出是合法的正整数。例如：输入：‘1’

预期的输出：1(2)输入是最高位数字为零的数字串，输出是合法的正整数。例如：输入：‘000001’

预期的输出：1(3)输入是负号与最高位数字紧相邻的数字串，输出是合法的负整数。例如：输入：‘－00001’

预期的输出：－1(4)输入是计算机能表示的最小负整数与零之间的负整数，输出为合法的负整数。例如：输入‘－02768’

预期的输出：－2768(5)输入是零字符串，输出为零。例如：输入：‘000000’

预期的输出：0(6)输入是在零和计算机能表示的最大正整数之间的正整数，输出为合法的正整数。例如：输入：‘032754’

预期的输出：32754(7)输入为空字符串。例如：输入：‘

’预期的输出：“错误——无效输入”

(8)输入的左部非零非空格。例如：输入：‘?????1’

预期的输出：“错误——填充错”

(9)输入的最高位数字右面由数字与空格混合。例如：输入：‘12’预期的输出：“错误——无效输入”(10)输入的负号与最高位有空格。例如：输入：‘－13’

预期的输出：“错误——负号位错”(11)输入的最高位数字右面由数字与其他字符混合。例如：输入：‘12?x3’

预期的输出：“错误——无效输入”(12)输入为比最小负整数小的负整数。例如：输入：‘－56889’

预期的输出：“错误--无效输入”(13)输入为比最大正整数还大的正整数。例如：输入：‘133867’

预期的输出：“错误——无效输入”

2.边界值分析

1)边界值分析从长期的实践中得知，处理边界情况时，程序最容易发生错误。所以，在设计测试用例时，应该选择一些边界值，这就是边界值分析的测试技术。边界值分析也是一种黑盒测试方法，是对等价类划分方法的补充。

使用边界值分析方法设计测试用例时，首先要确定边界情况，这需要经验和创造性。通常，输入等价类和输出等价类的边界就是应该着重测试的程序边界情况。选取的测试数据应该刚好等于、刚好小于和刚好大于边界值，而不是先取每个等价类内的典型值或任意值作为测试数据。例如，对于上述将数串转换为整数的例子来说，从边界值角度考虑应再补加下述测试方案。(1)使输出刚好等于最小的负整数。例如：输入：‘－32768’

预期的输出：－32768(2)使输出刚好等于最大的正整数。例如：输入：‘32767’

预期的输出：32767(3)使输出刚好小于最小的负整数。例如：输入：‘－32769’

预期的输出：“错误——无效输入”(4)使输出刚好大于最大的正整数。例如：输入：‘32768’

预期的输出：“错误——无效输入”

另外，依据边界值分析法的要求，应该分别使用长度为0，1和6的数字串作为测试数据。通常，设计测试方案时总是把等价类划分和边界值分析两种技术联合起来使用，使得测试用例有所减少。2)确定测试用例

(1)边界值分析不是从等价类中随便选一个数据作为代表，而是选一个或几个特定值，使这个等价类的每个边界都作为测试的目标。

(2)边界值分析不仅要考虑输入条件，而且要考虑输出情况(即输出等价类)。边界值分析法选择测试用例的原则如下：●如果某个输入条件规定了数据的大小，可以选择正好等于边界值的数据作为合理的测试用例，同时还要选择正好越过边界值的数据作为不合理的测试用例。例如，若输入值的范围是“－1.0～1.0”，则可选取“－1.0”，“1.0”，“－1.001”，“1.001”作为测试输入数据。●如果某个输入条件规定了数据的个数，则可分别设计边界值和超过边界值的测试用例。如某输入文件有1～255个记录，则可选择0个，1个，255个和256个记录作为测试的输入数据。●根据规格说明的每个输出条件，使用前面的原则(1)。例如，设计每月工资的折扣数程序，最低额为0元，最高额为500元，这时可选择0元、500元、负值和大于500元的测试用例。●根据规格说明的每个输出条件，使用前面的原则(2)。例如，某一情报检索系统，根据某一输入的请求，要求显示几项最新报道，但不能多于5条，这时可选择使程序分别显示0、1和5项报道作为测试用例，另外还要设计使程序显示6项报导的错误测试用例。●如果程序的输入或输出是有序集合(如有序表、线性表)，则应把注意力放在集合内的第一个和最后一个元素上。●如果程序中使用了一个内部数据结构，则应当选择这个内部数据结构的边界上的值作为测试用例。例如，程序中定义了一个数组，其元素下标的上界和下界分别为200和0，则应选择0与200作为测试用例。●分析规格说明，找出其他可能的边界条件。

3.因果图法因果图是设计测试用例的一种工具，它主要检查各种输入条件的组合。等价类划分、边界值分析的测试用例设计方法还不能考虑到组合输入条件可能引起软件错误，而因果图法则弥补了这个不足之处。1)设计测试用例因果图的测试用例设计步骤如下：(1)分析规格说明中的输入作为因，输出作为果。(2)依据因果的处理语义画出因果图。(3)标出因果图的约束条件。(4)将因果图转换为因果图所对应的判定表。(5)根据判定表设计测试用例。图6.5因果图定义符号恒等；(b)非；(c)或；(d)与；(e)异约束；(f)或约束；(g)惟一约束；(h)要求约束；(i)强制约束

其中，(a)图表示恒等：表示原因与结果之间是一对一的对应关系。若原因出现，则结果出现。若原因不出现，则结果也不出现。(b)图表示非：表示原因与结果之间的一种否定关系。若原因出现，则结果不出现。若原因不出现，则结果出现。(c)图表示或(∨)：表示若几个原因中有一个出现，则结果出现，只有当这几个原因都不出现时，结果才不出现。(d)图表示与(∧)：表示若几个原因都出现，结果才出现。若几个原因中有一个不出现，结果就不出现。(e)图表示异约束：表示a，b两个原因不会同时成立，两个中最多有一个可能成立。(f)图表示或约束：表示a，b，c三个原因中至少有一个必须成立。(g)图表示惟一约束：表示a和b原因当中必须有一个，且仅有一个成立。(h)图表示要求约束：表示当a出现时，b必须也出现，不可能a出现，b不出现。(i)图表示强制约束：它表示当a是1时，b必须是0，而当a为0时，b的值不定。2)利用因果图设计测试用例的实例某规格说明：“第一列字符必须是A或者B，第二列字符必须是一个数字，第一、二两列都满足时修改文件，第一列不正确时给出信息L，第二列不正确时给出信息M。”

(1)分析规格说明并编号。因：第一列字符是A①

第一列字符是B②约束①②只有一个为1，不能同时为1第二列字符是数字③果：一列正确E①②1111=①∨②∨修改文件=∧③即(①∨②)∧③给出L信息=即①∨②给出M信息=③2111112223图6.6因果图例(2)画出的因果图6.6所示。(3)将因果图转换为判定表(如表6.1所示)：遇到E约束记为X；条件和输出结果编号成立时记为1，否则记为0；表中每一列视为测试规则。表6.1判定表 ③组合条件12345678 ①条件原因②

111X110X101110010111010100100000XXXXXX010001010001100X0X③11动作结果222123(4)根据判定表的3～8列编写测试用例如下：根据3列输入：A3，A8输出：修改文件根据5列输入：B4，B5输出：修改文件根据4列输入：AM，A？给出信息M根据6列输入：BB，BC给出信息M根据7列输入：M1，X6给出信息L根据8列输入：XY，MN给出信息M与L

4.错误推测法测试工作是一项十分艰巨和复杂的工作，它具有创造性。通过对程序出错的共性分析，黑盒法中的等价类划分、边界值分析、因果图法已经可以达到用较少用例测试较多软件错误的目的。但是，各种程序由于其自身特点(如开发环境的不同及应用环境的不同等)，通常又有各自特定的容易出错的地方。例如，财务管理系统和工厂的机床控制系统由于其各自的开发工具、应用环境的不同，因而程序中容易出错的地方也不相同。因而，在设计测试用例时，需考虑程序自身的特点，设计出相应的测试用例。当然，这主要依靠测试人员的经验和直觉。人们在长期的软件测试中积累了许多丰富的测试经验，已掌握了那些最容易测出软件的错误的数据，用这样的数据测试效率会更快。这种根据经验来设计程序测试用例的方法称错误推测法。常用的方法如下：(1)零作为测试数据往往容易使程序发生错误。

(2)分析规格说明书中的漏洞，编写测试数据。

(3)根据尚未发现的软件错误与已发现软件错误成正比的统计规律，进一步测试时重点测试已发现错误的程序段。

(4)等价类划分与边界值分析容易忽略组合的测试数据，因而，可采用判定表或判定树列出测试数据。

(5)与人工代码审查相结合，两个模块中共享的变量已被做修改的，可用来做测试用例。因为对一个模块测试出错，同样会引起另一模块的错误。6.4软件测试计划和测试分析报告

软件测试是软件生命周期中一个非常重要的阶段，是保证程序质量的必不可少的操作步骤。为了提高软件的测试效率，必须使软件测试有计划的、有条不紊地进行，因而须编制相应的测试文档。测试文档主要由测试计划和测试分析报告组成。根据GB8567-88《计算机软件产品开发文件编制指南书》中的《测试计划》、《测试分析报告》以及GB9386-88《计算机软件测试文件编制规范》，测试计划可细化为测试计划、测试设计说明、测试用例说明和测试规格说明。测试分析报告可细化为测试项传递报告、测试日志、测试事件报告和测试总结报告。软件测试计划的内容如下：1.引言1.1编写目的1.2背景1.3定义1.4参考资料2.计划2.1软件说明2.2测试内容2.3测试1(标识符)2.3.1进度安排2.3.2条件a.设备b.软件c.人员2.3.3测试资料a.有关本项任务的文件b.被测试程序及其所在的媒体c.测试的输入和输出举例d.有关控制此项测试的方法、过程的图表2.3.4测试培训2.4测试2(标识符)3.测试设计说明3.1测试1(标识符)3.1.1控制3.1.2输入3.1.3输出3.2测试2(标识符)…4.评价准则4.1范围4.2数据整理4.3尺寸测试分析报告的内容如下：1.引言1.1编写目的

1.2背景

1.3定义

1.4参考资料2.测试概要3.测试结果及发现

3.1测试1(标识符)3.2测试2(标识符)4.对软件功能的结论

4.1功能1(标识符)4.1.1能力

4.1.2限制

4.2功能2(标识符)

5.分析摘要

5.1能力

5.2缺限和限制

5.3建议a.各项修改可采用的修改方法程度b.各项修改的紧迫程度c.各项修改预定的工作量d.各项修改的负责人

5.4评价6.测试资源消耗6.5软件测试策略

前面几节内容简述了设计测试方法的各种技术。实践表明，使用每种方法均可设计出一组有用的测试方案，但没有一种方法足以产生一组完善的测试方案。对每种方法而言，均有自身特长，因而用一种方法设计出的测试方案对某些类型的错误可能容易发现，但对另一些类型的错误不一定容易发现。所以，在实际工作中，总是把它们结合起来使用，形成综合的测试策略，以满足不同测试阶段和不同程序的需要。一般的做法是，用黑盒法设计基本的测试方案，再利用白盒法补充一些必要的测试方案。具体地说，可用以下策略结合各种方法：(1)在任何情况下都应该使用边界值分析的方法。

(2)必要时用等价划分法补充测试方案。

(3)必要时用错误推测法补充测试方案。

(4)如果在程序的功能说明中含有输入条件的组合，最好在一开始就用因果图法，然后再按以上(1)、(2)、(3)步聚进行。

(5)对照程序逻辑，检查已设计出的设计方案。可以根据对程序可靠性的要求采用不同的逻辑覆盖标准，如果现有测试方案的逻辑覆盖程度没达到要求的覆盖标准，则应再补充一些测试方案。

以上的综合策略在实际应用当中，相对来说较为有效，但它依然不能保证测试时发现一切程序错误，因为软件测试是一项十分艰巨复杂的工作。软件测试过程必须分步骤进行，每个步骤在逻辑上是前一个步骤的继续。大型软件系统通常由若干个子系统组成，每个子系统又由许多模块组成。大型软件系统的测试步骤基本由以下四个步骤组成：单元测试、集成测试(组装测试)、确认测试和系统测试，如图6.7所示。图6.7测试步骤6.5.1单元测试单元测试的目的在于发现各模块内部可能存在的各种差错。单元测试又称模块测试、逻辑测试或结构测试。测试的方法一般采用白盒法，以路径覆盖为最佳准则，且系统内多个模块可以并行地进行测试。单元测试在编码中就进行了，其测试策略包括：单元测试设计测试用例要测试哪几方面的问题，针对这几方面问题各自测试什么内容，测试的具体步骤及实用测试策略。1.单元测试的内容单元测试主要是对模块的五个基本特性进行评价。

1)模块接口在其他测试开始之前，首先要对通过模块接口的数据进行测试。若数据不能正确地输入和输出，则所有其他测试都是不切实际的。Myers提出了接口测试要点：

(1)实际参数与形式参数的个数是否相等。

(2)实际参数与形式参数的属性是否匹配。

(3)实际参数与形式参数的单位是否匹配。

(4)调用其他模块时所给实际参数的个数是否与被调模块的形参数个数相等。

(5)调用其他模块时所给实际参数的属性是否与被调模块的形参属性匹配。(6)调用其他模块时所给实际参数的单位是否与被调模块的形参单位匹配。

(7)调用内部函数所用参数的个数、属性和次序是否正确。

(8)是否存在与当前入口点无关的参数引用。

(9)输入是否仅改变了形式参数。

(10)全程变量在各模块中的定义是否一致。

(11)常数是否当作变量传送。若一个模块需要完成外部的输入或输出时，还应检查下述各点：(1)文件属性是否正确。(2)OPEN/CLOSE语句是否正确。(3)格式说明与I/O语句是否匹配。(4)缓冲器大小与记录长度是否匹配。(5)文件是否先打开后使用。(6)文件结束的条件是否处理过。(7)I/O的错误是否处理过。(8)输出信息中是否有正文的错误。2)局部数据结构检查局部数据结构是为了保证临时存储在模块内的数据在程序执行过程中完整、正确。局部数据结构往往是错误的根源。应仔细设计测试用例，力求发现下面几类错误：(1)不正确或不一致的说明。(2)错误的初始化或错误的缺省值。(3)拼写错或截短的变量名。(4)不一致的数据类型。(5)上溢、下溢和地址错误。除了局部数据结构外，如有可能，单元测试期间还应考虑全局数据(例如FORTRAN的公用区)对模块的影响。3)重要的执行路径在模块中应对每一条独立的执行路径进行测试，单元测试的基本任务是保证模块中每条语句至少执行一次。此时，设计测试用例是为了发现因错误计算、不正确的比较和不适当的控制流造成的错误。此时，基本路径测试和循环测试是最常用、最有效的测试技术。计算中常见的错误如下：(1)算术运算优先次序不正确或理解错误。(2)运算方式不正确。(3)初始化不正确。(4)精度不够。(5)表达式的符号表示错误。

比较判断与控制流常常紧密相关，因而，测试用例还应致力于发现下列错误：(1)不同的数据类型比较。(2)逻辑运算不正确或优先次序错误。(3)因为精度误差造成本应相等的量不相等。(4)比较不正确，或变量不正确。(5)循环不终止或循环终止不正确。(6)当遇到分支循环时，出口错误。(7)错误地修改循环变量。4)错误处理一个好的设计应能预见各种出错条件，并预设各种出错处理通路。出错处理通路同样需要认真测试，测试应着重检查下列问题：(1)错误描述难以理解。(2)错误提示与实际错误不相符。(3)在程序自定义的出错处理段运行之前，系统已介入。(4)对错误的处理不正确。(5)提供的错误信息不足，无法确定错误位置和查错。5)边界测试边界测试是单元测试步骤中的最后一步，也是最重要的一项任务。众所周知，软件通常容易在边界上失效，因而，采用边界值分析技术，针对边界值及其左、右值设计测试用例，很有可能发现新的错误。

2.单元测试步骤单元测试的步骤如下：

(1)按照图6.8配置测试环境，设计辅助测试模块。驱动模块相当于所测模块的主程序，主要用来接收测试数据，启动被测模块，打印测试结果。桩模块(也称存根模块)接收被测试模块的调用和输出数据，是被测模块的调用模块。驱动模块类似子程序模块，是单元测试中重要的成本开销。图6.8单元模块测试环境(2)编写测试数据。根据逻辑覆盖及上述关于单元测试要解决的测试问题的考虑原则，设计测试用例。

(3)进行多个单元的并行测试。经过编译之后，先做静态代码复审，由人工测试模块中的错误，由程序设计者、程序编写者和程序测试者参与，由软件设计能力很强的高级程序员任组长，在研究软件设计文档基础上召开审查会，分析程序逻辑与错误清单，测试预演，人工测试，代码复审后再进入计算机代码执行活动的动态测试，最后做单元测试报告。6.5.2集成测试集成测试也称组装测试，综合测试或联合测试。集成测试是按设计要求把通过单元测试的各个模块组装在一起之后进行测试，以便发现与接口有关的各种错误。在进行集成测试时，常需考虑的有关问题有：数据经过接口是否会丢失；一个模块对另一模块是否造成不应有的影响；几个子功能组合起来能否实现主功能；误差不断积累是否达到不可接受的程度；全局数据结构是否有问题。集成测试分为非渐增式测试和渐增式测试。

1.非渐增式测试非渐增式测试方法是先分别测试每个模块，再把所有模块按设计要求放在一起，结合成所要的程序再进行测试。

2.渐增式测试渐增式测试是把下一个要测试的模块同已经测试好的那些模块结合起来进行测试，测试完以后再把下下一个应该测试的模块结合进来测试，这种测试每次增加一个模块。这种方法实际上同时完成单元测试和集成测试。1)自顶向下结合自顶向下结合是一种递增的装配软件结构的方法。这种方法被日益广泛地采用，它需要连接程序，但不需要驱动程序。它是从主控制模块(“主程序”)开始，沿着软件的控制层次向下移动，从而逐渐把各个模块结合起来。把主控模块所属的那些模块都装配到结构中去时，有两种方法可供选择。

深度优先策略参看图6.9，深度优先策略先组装在软件结构的一条主控制通路上的所有模块。主控路径的选择决定于软件的应用特性。如，选取最左边的路径，先结合模块M1、M2和M5，接着是M8，如果M2的某个功能需要，可结合M6，然后再构造中央和右侧的控制通路。图6.9自顶向下结合

宽度优先策略宽度优先策略是沿软件结构水平地移动，把处于同一个控制层次上的所有模块组装起来。对于图6.9来说，先结合模块M2、M3和M4(代替存根程序S4)，接着是M5、M6和M7(代替存根程序S7)这一层，如此继续进行下去，直到所有模块都被结合进来为止。

自顶向下综合测试可归纳为以下五个步骤：

(1)用主控制模块做测试驱动程序，用连接程序代替所有直接附属于主控制模块的模块。

(2)依据所选的集成策略(深度优先或宽度优先)，每次只用一个实际模块替换一个桩模块。

(3)每集成一个模块立即测试一遍。

(4)只有每组测试完成后，才用实际模块替换下一个桩模块。

(5)为避免引入新错误，须不断进行回归测试(即全部或部分地重复已做过的测试)。

这一过程从第二步开始就不断进行，直到整个程序结构构造完毕。在图6.9中，实线表示已部分完成的结构，若采用深度优先策略，下一步就要用M7来替代桩模块S7。S7本身可能又带桩模块，随后将被对应的实际模块一一替代。自顶向下集成的优点在于能尽早地对程序的主要控制和决策机制进行检验，因而能较早发现错误。其缺点在于测试较高层模块时，低层处理采用桩模块替代，这并不能够反映实际情况，重要数据不能及时回送到上层模块，因而测试并不充分和完善。所以这种方法有它的局限性，若遇到此类问题，测试人员可选择以下几种方法解决之：(1)把某些测试推迟到用真实模块替代桩模块之后进行。这将使我们对一些特定的测试和特定模块的装配之间的对应关系失去某些控制，在确定错误原因时会比较困难。

(2)开发能模拟真实模块的桩模块。此法无疑要大大增加开销。

(3)从层次结构的底部向上装配软件。此种方法较切实可行，下面专门介绍。2)自底向上结合自底向上测试是从软件结构最低层的模块开始组装和测试，当测试到较高层模块时，所需的下层模块均已具备，因而不再需要桩模块。自底向上综合测试可归纳为以下四个步骤：

(1)把低层模块组合成实现一个特定软件子功能的族，见图6.10中模块族1、2、3。图6.10自底向上结合(2)为每个族设计一个驱动软件，作为测试的控制程序，以协调测试用例的输入和输出。图6.10中，虚线接的框D1、D2、D3是各个族的驱动程序。

(3)对模块族进行测试。

(4)按结构向上次序，用实际模块替换驱动程序，将模块族结合起来组装成新的模块族，再进行测试，直至全部完成。例如，在图6.10中，族1、族2上属于Ma，因而去掉D1和D2将这两个族直接与Ma接口；同样族3与Mb接口前将D3去掉；Ma与Mb最后与Mc接口。

采用自底向上方法，越向上层分别测试，所需驱动程序越少。而且，若软件结构的最上两层用自顶向下结合的方法进行装配，则将大大减少驱动程序的数目，同时族的组装也会大大简化。自顶向下方法不需驱动模块的设计，可在程序测试的早期实现并验证系统的主要功能，及早发现上层模块的接口错误。但自顶向下方法必须设计存根模块，使低层关键模块中错误发现较晚，并且不能在早期很快且充分地展开测试的人力。自底向上方法与自顶向下方法相比较，它的优缺点与自顶向下方法恰恰相反。一般在实际应用中，采用两种方法相结合的混合法，即对软件结构的较上层使用自顶向下的结合方法，对下层使用自底向上的结合方法，以充分发挥两种方法的优点，尽量避免其缺点。6.5.3确认测试确认测试又称有效性测试、合格测试或验收测试。模块组装后已成为完整的软件包，消除了接口的错误。确认测试主要由使用用户参加测试，检验软件规格说明的技术标准的符合程度，是保证软件质量的最后关键环节。

1.确认测试标准软件确认测试