《软件工程实践与项目管理》课件第10章

10.1软件测试的定义

10.2实例：图书借阅系统的功能函数10.3“软件测试计划说明书”的书写格式

10.4静态测试

10.5覆盖测试

10.6黑盒测试方法 10.7“缺陷报告单”的书写格式

10.8软件测试过程本章小结

习题

第10章软件测试10.1软件测试的定义

1983年，IEEE给出的软件测试的定义是：软件测试是使用人工或自动的手段来运行或测定某个软件系统的过程，其目的在于检验它是否满足规定的需求或弄清预期结果与实际结果之间的差别。这个定义明确指出：软件测试的目的是为了检验软件系统是否满足软件需求。这里强调了软件需求的重要性，因此软件需求是软件测试人员判断软件是否有缺陷的依据，就像法官判断案件嫌疑人是否犯法所依据的法律一样。10.2案例：图书借阅系统的功能函数

1.图书借阅系统功能分解通过分析，系统具有如下功能：①图书卡的注册、注销和信息查询；②图书借阅；③图书信息的查阅：按照作者姓名查阅、按照书名查阅；④图书返还。图书借阅系统的模块设计如图10-1所示。图10-1图书借阅系统的模块

2.函数关系从图10-1可以看出，本系统可以划分为如下函数：

Return_book()：还书函数；

findbook_bname()：按书名查找图书函数；

findbook_bauthor()：按作者名查找图书函数；

lend_book()：借书函数；

cardreg()：卡注册函数；

cardunreg()：卡注销函数；

cardreginfo()：卡的注册信息查询函数；

card_op()：卡的操作与管理函数。其中，card_op()函数调用三个函数：cardreg()、cardunreg()、cardreginfo()。函数调用关系如图10-2所示。10.3“软件测试计划说明书”的书写格式“软件测试计划说明书”的书写格式如下：

1引言

(1)测试背景这部分简要地阐述文档所说明的系统和软件的目的。这部分将大概描述系统背景、软件的本质；确定这个方案的发起人、受益人、使用者、开发者和维护机构；确定当前的状况并计划操作地点。

(2)测试目标

·确定现有项目的信息和应测试的软件配置；

·列出测试需求；

·推荐可采用的测试策略，并对这些策略加以说明，确定测试达到的标准；

·确定所需的测试资源，并对测试的工作量进行估计。

2测试范围列出软件需要进行的测试工作范围和不需要进行的测试工作范围；对于不实施某种测试，应该陈述具体的理由。例如，“将不实施安装测试，该项目将不提供安装版本”。

3测试的策略与方法测试人员采用的测试方法，如回归测试、功能测试、自动测试等。

4测试通过/不通过的标准测试是否通过的界定标准以及没有通过时的处理方法。

5停测标准给出每个测试阶段停止测试的标准。

6测试环境测试所需的硬件支持和软件环境等。

7测试人力资源分配列出测试所需人力资源以及软件测试人员的培训计划。

8测试进度安排制定每一个阶段的详细测试进度安排表。

9风险估计和危机处理估计测试过程中潜在的风险以及面临危机时的解决办法。

10制定应交付的测试工作产品指明应交付的文档、测试代码和测试工具，一般包括下列文档：测试计划、测试方案、测试用例、测试日志、测试总结报告、测试工具等。10.4静态测试软件测试方法分白盒测试和黑盒测试；从计算机运行状态分为动态测试和静态测试。动态测试通过运行被测程序，输入有效的测试用例，验证功能是否达到软件需求从而找出程序缺陷。静态测试时计算机并不真正运行被测试的程序，它只对被测程序的数据流和控制流等信息进行分析，找出系统的缺陷，做出测试报告，因此静态测试又称为“静态分析”。静态测试的目的是检查代码与设计的一致性、代码的可读性、代码和算法的正确性、代码结构的合理性等。例如：

(1)检查程序风格的一致性、规范性；

(2)检查算法的逻辑正确性，确定算法是否为最佳算法并实现了所要求的功能；

(3)检查模块接口的正确性，形参的个数、数据类型、顺序是否正确，确定返回值类型及返回值的正确性；

(4)检查程序输入参数的合法性；

(5)检查程序有无适当的异常处理模块；

(6)检查程序常量或全局变量、表达式、语句是否正确，是否含有二义性；

(7)检查程序代码是否可以优化。10.5覆盖测试白盒测试也称做结构测试或逻辑驱动测试，它的目的是了解和检测产品的内部工作过程，在测试手段上使用的是覆盖测试方法，可以分为如下六种覆盖测试方法：语句覆盖、判断覆盖、条件覆盖、判断/条件覆盖、条件组合覆盖和路径覆盖。这里给出了测试用例的格式，如表10-1所示。表10-1测试用例的格式在此，对表中一些项目做以说明：编号—根据项目进行编号，如：test1，test2，…，这里用的是T1，T2，…；执行结果—执行本测试用例所需的每一步操作。预期输出—描述被测项目或被测特性所希望或要求达到的输出或指标。这里还需要指出，测试用例的撰写人和执行测试的人不一定是同一个人。

1.利用语句覆盖方法设计测试用例语句覆盖是指设计若干个测试用例，使得被测试程序中的每条可执行语句至少被执行一次。在保证完成要求的情况下，测试用例的数目越少越好。

1)任务描述下面是一段简单的C语言程序，请使用语句覆盖方法完成测试用例的设计任务。inttesting(intx,inty){intpolo888=0;if(x>0&&y>0){polo888=x+y-10; //语句块1}else{polo888=x+y+10; //语句块2}

if(polo888<0){polo888=0;

//语句块3}returnpolo888;

//语句块4}

2)方法步骤做白盒测试时，一般不直接根据源代码设计测试用例和编写测试代码，通常是根据流程图来设计测试用例和编写测试代码，本任务的程序流程图如图10-3所示。图10-3程序流程图在图10-3中共有两个选择分支，要从“开始”到“结束”覆盖各语句必须覆盖“语句块1”、“语句块2”、“语句块3”、“语句块4”。所以表10-2给出了语句覆盖的测试用例。本任务的测试用例如表10-2所示。表10-2语句覆盖测试用例这样，通过两个测试用例即达到了语句覆盖的要求，当然，测试用例(测试用例组)并不是唯一的。用例T1：达到了覆盖“语句块1”和“语句块4”的目的；用例T2：达到了覆盖“语句块2”和“语句块3”的目的；因此本用例达到了语句覆盖的目的。

3)任务总结测试的充分性分析：假设第一个判断语句if(x>0&&y>0)中的“&&”被程序员错误地写成了“||”，即if(x>0||y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的语句覆盖，所以语句覆盖不能完全发现上述的逻辑错误。

2.利用判定(分支)覆盖方法设计测试用例

1)任务描述任务描述同1。任务：利用判定覆盖方法设计测试用例。

2)方法步骤判定覆盖测试是设计若干测试用例，使得程序中的每个判定结果至少都获得一次“真”值和“假”值。也就是说，程序中的每个取“真”、“假”的分支至少经历一次。该方法也叫“分支覆盖”测试方法。在本例中共有两个判断if(x>0&&y>0)(记为P1)和if(polo888<0)(记为P2)。测试用例如表10-3所示。表10-3判定覆盖测试用例

3)任务总结在上述的测试用例中，两个判断P1和P2取“真”、“假”值的每个分支都被执行了一遍，所以满足了判断覆盖的标准。假设第一个判断语句if(x>0&&y>0)中的“&&”被程序员错误地写成了“||”，即if(x>0||y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的判定覆盖，所以判定覆盖也不能完全发现上述的逻辑错误。由于可执行语句不在判定的真分支上就在假分支上，所以，满足了判定覆盖要求就一定满足语句覆盖要求，反之则不然。因此，判定覆盖比语句覆盖强。

3.利用条件覆盖方法设计测试用例

1)任务描述任务描述同1。任务：利用条件覆盖方法设计测试用例。

2)方法步骤条件覆盖方法是设计一组测试用例使程序中的每个条件都取真值和假值各取至少一次。在本例中分析的条件有三个：

x>0(记为C1)、y>0(记为C2)和polo888<0(记为C3)，但polo888<0是由x、y取值决定的，x，y取值全覆盖就把polo888的真、假值各取一遍了。3)测试用例条件覆盖测试用例如表10-4所示。表10-4条件覆盖测试用例

4)任务总结上面的测试用例同时也到达了100%判定覆盖的要求，但并不能保证达到100%条件覆盖要求的测试用例(组)都能到达100%的判定覆盖要求。既然条件覆盖不能100%达到判定覆盖的要求，也就不一定能够达到100%的语句覆盖要求了。4.利用判定与条件覆盖测试方法设计测试用例

1)任务描述任务描述同1。任务：利用判定与条件覆盖方法设计测试用例。

2)方法步骤判定与条件覆盖是指执行被测试程序时，程序中每个判断条件的真、假值分支至少被执行一遍，并且每个判断条件的内部判断式的真假值分支也要被执行一遍。即同时满足100%判定覆盖和100%条件覆盖的要求。本例中的判断为“x>0&&y>0”，内部判断式为：x>0和y>0。判定与条件覆盖测试用例如表10-5所示。表10-5判定与条件覆盖测试用例

3)任务总结达到100%判定与条件覆盖要求就一定能够达到100%条件覆盖、100%判定覆盖和100%语句覆盖的要求。

5.利用条件组合覆盖方法设计测试用例

1)任务描述任务描述同1。任务：利用条件组合覆盖方法设计测试用例。

2)方法步骤条件组合覆盖是指设计若干个测试用例，执行被测试程序时，程序中每个判断条件的内部判断式的各种真假组合都至少被执行一遍。可见，满足条件组合覆盖的测试用例组一定满足判定覆盖、条件覆盖、判定与条件覆盖。注意：

(1)条件组合只针对同一个判断语句内存在多个条件的情况，使得所有条件的各种可能的值至少出现一次。

(2)不同的判断语句内的条件取值之间无需组合。

(3)对于单条件的判断语句，只需要满足自己的所有取值即可。测试用例如表10-6所示。表10-6条件组合覆盖测试用例

3)任务总结

100%满足条件组合要求一定满足100%条件覆盖要求和100%判定覆盖要求。上面的测试用例中，经历了两条路径a—c—e—f和a—b—d—f，而被测试程序存在三条路径。所以这种测试方法不一定能覆盖程序的全部路径。

6.利用路径覆盖方法设计测试用例

1)任务描述任务描述同1。任务：利用路径覆盖方法设计测试用例。

2)方法步骤路径测试着眼于路径分析，完成路径测试的理想情况是做到了路径覆盖。路径覆盖也是白盒测试最为典型的测试方法。路径覆盖要求设计若干测试用例，执行被测试程序时，能够覆盖程序中所有可能的路径。本任务有四条路径：a—b—d—f，a—c—d—f，a—b—e—f，a—c—e—f。路径覆盖测试用例应该能够覆盖这四条路径。测试用例如表10-7所示。表10-7路径覆盖测试用例

3)任务总结由上表可见，100%满足路径覆盖，并不一定能100%满足条件覆盖(C2只取到了真)，但一定能100%满足判定覆盖(因为路径经历的就是某判断的分支)。上述六种逻辑覆盖从弱到强的排列顺序是：语句覆盖→判定覆盖→条件覆盖→判定与条件覆盖→条件组合覆盖→路径覆盖。它们之间的关系可用图10-4表示(路径覆盖很难在该图表示出来)。图10-4覆盖测试方法关系图我们应该清楚，没有一个测试方法能够找出软件的所有缺陷。即便对程序做到了路径覆盖测试，也不能保证源代码就不存在其他问题。因此我们要善于应用多种测试方法对程序进行测试。10.6黑盒测试方法黑盒测试方法是在已知软件产品功能设计的情况下，对其进行测试以确认其是否实现了的软件产品的功能要求。该方法把被测程序视作黑盒，不考虑程序内部的逻辑结构和内部特性，只依据软件的需求规格说明，输入相应的数据，检查程序的输出是否符合它的功能要求。使用黑盒测试主要是为了发现以下错误：

(1)是否有不正确的功能；

(2)是否有遗漏的功能；

(3)在接口上，是否能够正确地接收输入数据并产生正确的输出结果；

(4)是否有数据结构错误或外部信息访问错误；

(5)性能上是否能够满足要求；

(6)是否有程序初始化和终止方面的错误。黑盒测试有以下显著特点：

(1)黑盒测试不考虑软件的具体实现，当软件内部实现发生变化时，测试用例仍然可以使用。

(2)黑盒测试用例的设计可以和软件实现同时进行，这样能够压缩总的开发时间。

(3)对一些外购软件、参数化软件包以及某些自动生成的软件，由于无法得到源程序，只能选择黑盒测试对其进行测试。黑盒测试的优点如下：

(1)适用于各个测试阶段；

(2)从产品功能角度进行测试；

(3)容易生成测试数据。黑盒测试的缺点如下：

(1)某些代码得不到测试；

(2)无法发现软件需求说明书本身的错误；

(3)不易进行充分性测试。实现黑盒测试的内容常用的测试方法包括等价类划分法和边界值分析法。

1.利用等价类划分法设计测试用例

1)任务描述在C语言中有这样的规定：“变量标识符由字母、数字和下划线组成，并且首字符只能是字母和下划线，标识符的有效字符个数是8个，最大字符数是80个”。请利用等价类划分方法设计测试用例。

2)方法步骤等价类划分法是把全部的输入数据划分成若干的等价类，在每一个等价类中取一个数据来进行测试，这样就等价于把该等价类中全部数据取出进行了测试，就能以较少的具有代表性的数据进行测试，从而取得很好的测试效果。等价类又分为有效等价类和无效等价类两类。有效等价类指对于程序的需求说明而言合理的、有意义的输入数据所构成的子集合；利用它可以检验程序是否实现了预期的功能和性能。无效等价类指对于程序的需求说明而言不合理的、没有意义的输入数据所构成的集合；利用它可以检验程序是否实现了异常处理功能。使用等价类划分法设计测试用例，首先必须在分析需求规格说明的基础上划分等价类，然后列出等价类表，其格式如表10-8所示。对于本任务，等价类表如表10-9所示。表10-8等价类表格式表10-9标识符定义的等价类表

对于本任务，用等价类划分方法设计的测试用例见表10-10所示。表10-10标识符定义测试用例

3)任务总结一般情况下，划分等价类的方法如下：

(1)如果输入条件规定了数据的范围和取值个数，可以确定一个有效等价类和两个无效等价类。例如：100<X<999，有效等价类为(100，999)，无效等价类为“小于100”和“大于999”。

(2)如果输入条件规定了一个必须成立的情况(如输入数据必须是某个日期)，可以划分为一个有效等价类“输入某个日期格式字符串”和一个无效等价类“输入非日期格式字符串”。

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

4)课堂练习对下面程序描述用等价类划分方法设计测试用例。

(1)三角形组成问题。输入三个数，分别作为三角形的三条边(要求都是整数，取值范围在1～100之间)。判断是否能组成三角形，请给出测试用例。(提示：利用三角形组成的条件。)

(2)平方根函数。要求当输入值大于等于0时，返回输入数的平方根；当输入值小于0时，显示错误信息“平方根错误，输入值小于0”，并返回0。请设计测试此函数的设计用例。

2.利用边界值分析方法设计测试用例

1)任务描述下面是图书信息查询系统(前面给出过软件需求和函数结构)的图书卡注册信息浏览函数cardreginfo()结构。

{

FILE*fp;

inti,n=0;

fp=fopen("car.txt","r"); //打开卡信息文件

for(i=0;fread(&car[i],sizeof(structcard),1,fp)!=0;i++)

{

printf("第%d张卡<卡号：%d姓名：%s班级：

%d>\n",i+1,card[i].carnum,card[i].studentname,card[i].studentclass);

n=n+1;

}

fclose(fp);

printf("目前共有%d本书\n",n);

printf("按任意键\n");

getch();

}其中，card.txt文件存放有学生信息：卡号、姓名、班级。请利用边界值分析方法设计测试用例。

2)方法步骤边界值分析法是一种补充等价类划分法的测试用例设计技术，它不是选择等价类的任意元素，而是选择等价类边界的测试用例。常见的边界值有：

(1)对16bit的整型数而言，-32767和32768是边界；

(2)屏幕上光标的最左上角和最右下角位置；

(3)报表的第一行和最后一行；

(4)数组元素的第一个和最后一个元素；

(5)循环的第0次、第1次和倒数第2次、最后一次。对于本测试模块cardreginfo()中循环语句：

for(i=0;fread(&card[i],sizeof(structcard),1,fp)!=0;i++)可以设置边界如下：

(1) i=-1，0；

(2) i作为一个int整型变量，取边界值-32768，-32769，32767，32768。表10-11给出了本任务的边界值分析测试用例。表10-11边界值分析测试用例

3)任务总结根据长期的测试工作实践可知，大量的错误发生在输入或输出的边界上。因此针对各种边界情况设计测试用例，可以查出更多的错误。利用边界值分析法进行用例设计时应该注意：

(1)如果对输入条件范围进行了界定，则以边界内部以及恰巧超出范围边界的值作为测试用例。

(2)应当选取正好等于、刚刚大于或刚刚小于边界的值作为测试数据，而不是选取等价类中的典型值或任意值作为测试数据。

(3)在软件需求说明中，对于输出条件也可以用上面的两个原则进行测试用例的设计。

(4)如果在软件需求说明中描述的输入或者输出是一个有序集合(如：顺序文件、表格等)，那么就选择集合中的第一个和最后一个元素作为测试用例。

(5)如果程序使用了一个内部数据结构，应该选取这个内部数据结构的边界值作为测试用例。

(6)分析软件需求说明，找出其他可能的边界条件。10.7“缺陷报告单”的书写格式对测试过程中的每个缺陷都应该填写一份缺陷报告单，如表10-12所示。表10-12缺 陷 报 告 单表格中有关项目的说明：

(1)严重程度。致命性错误：数据丢失，数据计算错误、系统崩溃和死机；严重功能性错误：规定的功能没有实现或不完整、设计不合理造成性能低下，影响系统的运行；警告性错误：不影响系统运行的功能问题，例如，某变量定义之后在本程序中没有用到过。建议性错误：如代码规范等问题。

(2)重现几率分为四个等级：小于等于30%、大于30%小于60%、大于60%小于80%，大于80%小于等于100%(这个规定可以根据实际项目确定)；

(3)优先级别(指优先安排修正该缺陷的紧迫程度)分为三个级别：高、中、低；

(4)处理结果分为两种：已经解决、尚未解决；

(5)修改方式分为四种：修改相关代码、删除相关功能模块、改变设计、不做修改。10.8软件测试过程软件测试过程按测试阶段的先后顺序大致可分为单元测试、集成测试、系统测试三个阶段。在开发期间对模块进行单元测试，在相关联的模块都通过单元测试后，合并(成为一个大模块后)进行集成测试，在各个“大模块”测试完成后，进行整个系统的测试。

1.单元测试单元测试是对软件基本组成单元进行的测试。单元测试的对象是软件设计的最小单位—模块。例如“图书借阅系统”中有下面单元：

Return_book()：还书函数； findbook_bname()：按书名查找图书函数；

lend_book()：借书函数； findbook_bauthor()：按作者名查找图书函数；

cardreg()：卡注册函数； cardunreg()：卡注销函数；

cardreginfo()：卡的注册信息查询函数；

card_op()：卡的操作与管理函数。这里的每个函数是一个单元模块。单元测试的主要内容是模块接口测试。模块接口测试中的被测模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与被测模块相关联的模块。这些辅助模块可分为两种：

(1)驱动模块：相当于被测模块的主程序。它接收测试数据，把这些数据传送给被测模块，最后输出实测结果。例如，模块A要调用模块B，在测试模块B时，要编写一个驱动模块(模拟模块A对B的调用功能)来调用模块B，检查模块B是否存在缺陷。

(2)桩模块：用以代替被测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。例如，模块A要调用模块B，现在测试模块A时，要编写一个桩模块(代替模块B的功能)被模块A调用，(假设模块B是正确的)检查模块A是否存在缺陷。被测模块、与它相关的驱动模块以及桩模块共同构成了一个“测试环境”，如图10-5所示。在单元测试过程中对于每个单元测试完毕都要填写表10-12所示的《缺陷报告》。图10-5被测模块、驱动模块以及桩模块

2.集成测试集成测试的方式有以下两种。

1)非增值式集成测试非增值式集成测试的方法是：先分别测试每个模块，然后再把所有模块按设计要求放在一起结合成所需要实现的程序而进行测试。图10-6所示的是整个程序模块结构，共包含9个模块。图10-6整个程序模块结构具体测试计划如下：

(1)对模块<按照书名查询>进行单元测试。为<按照书名查询>设计驱动模块Driver1，来模拟<系统主函数>模块对<按照书名查询>的调用。如图10-7所示。图10-7对模块<按照书名查询>进行单元测试

(2)对模块<按照作者名字查询>进行单元测试。为<按照作者名字查询>设计驱动模块Driver2，来模拟<系统主函数>模块对<按照作者名字查询>的调用。如图10-8所示。图10-8对模块<按照作者名字查询>进行单元测试

(3)对模块<图书返还>进行单元测试。为<图书返还>设计驱动模块Driver3，来模拟<系统主函数>模块对<图书返还>的调用。如图10-9所示。图10-9对模块<图书返还>进行单元测试

(4)对模块<图书卡的操作与管理>进行单元测试。为<图书卡的操作与管理>设计驱动模块Driver4，来模拟<系统主函数>模块对<图书卡的操作与管理>的调用。为模块<图书卡的操作与管理>设计桩模块Stub1，来模拟模块<卡的注册信息查询>被<图书卡的操作与管理>的调用。如图10-10所示。图10-10对模块<图书卡的操作与管理函数>进行单元测试

(5)对模块<卡的借阅信息浏览>、<卡的注册信息查询>、<图书卡的注销>、<图书卡的注册>进行单元测试。为<卡的借阅信息浏览>、<卡的注册信息查询>、<图书卡的注销>、<图书卡的注册>分别设计驱动模块Driver5、Driver6、Driver7、Driver8来模拟<图书卡的操作与管理>模块对它们的分别调用。如图10-11所示。图10-11对模块<卡的借阅信息浏览>、<卡的注册信息查询>、<图书卡的注销>、<图书卡的注册>进行单元测试

(6)对模块<图书借阅>进行单元测试。为<图书借阅>设计驱动模块Driver9，来模拟<系统主函数>模块对<图书借阅>的调用。如图10-12所示。图10-12对模块<图书借阅>进行单元测试

(7)对主模块<系统主函数>进行单元测试。为主模块<系统主函数>设计五个桩模块Stub2、Stub3、Stub4、Stub5、Stub6分别模拟<按照书名查询>、<按照作者名字查询>、<图书返还>、<图书卡的操作与管理>、<图书借阅>模块被主模块的调用。如图10-13所示。

(8)把所有模块按设计要求放在一起结合成所需要实现的程序而进行系统测试图10-13对主模块<系统主函数>进行单元测试

2)增值式集成测试方式增值式集成测试方式有以下三种。

(1)自顶向下增值测试方式。自顶向下增值测试方式的方法是：主控模块作为驱动模块，所有与主控模块直接相连的模块(记为X)作为被测模块；根据集成的方式(深度或广度)，每次把从属于X的一个桩模块替换成真正的模块Y及Y的桩模块(如果Y有桩模块)，依此不断集成下去，直到全部模块被集成为止。在每个模块被集成时，都必须已经通过了单元测试；进行回归测试以确定集成新模块后没有引入错误。这种组装方式将模块按系统程序结构，沿着控制层次自顶向下进行组装。自顶向下的增值方式在测试过程中较早地验证了主要的控制和判断点。选用按深度方向组装的方式，可以首先实现和验证一个软件的完整功能。图10-14表示的是按照深度优先方式遍历的自顶向下增值的集成测试实例。图10-14自顶向下增值测试方式在树状结构图中，按照先左后右的顺序确定模块集成路线：①如图10-14(a)所示，先对顶层的主模块A进行单元测试。就是对模块A配以桩模块S1、S2和S3，用来模拟它所实际调用的模块B、C、D，然后进行测试；②如图10-14(b)所示，用实际模块B替换掉桩模块S1，与模块A连接，再对模块B配以桩模块S4，用来模拟模块B对E的调用，然后进行测试；③图10-14(c)是将模块E替换掉桩模块S4并与模块B相连，然后进行测试；④判断模块E没有叶子结点，也就是说以A为根结点的树状结构图中的最左侧分支深度遍历结束，转向下一个分支；⑤如图10-14(d)所示，模块C替换掉桩模块S2，连到模块A上，然后进行测试；判断模块C没有桩模块，转到树状结构图的最后一个分支；⑥如图10-14(e)所示，模块D替换掉桩模块S3，连到模块A上，同时给模块D配以桩模块S5，来模拟其对模块F的调用，然后进行测试；⑦如图10-14(f)所示，去掉桩模块S5，替换成实际模块F连接到模块D上，然后进行测试；⑧对树状结构图进行了完全测试，测试结束。

(2)自底向上增值测试方式。自底向上增值测试方式与自顶向下增值测试方式正好相反。图10-15表示的是按照自底向上增值方式集成测试的例子。图10-15自底向上增值测试方式①首先，对处于树状结构图中叶子结点位置的模块E、C、F进行单元测试，如图10-15(a)、图10-15(b)和图10-15(c)所示，分别配以驱动模块D1、D2和D3，用来模拟模块B、模块A和模块D对它们的调用。②然后，如图10-15(d)和图10-15(e)所示，去掉驱动模块D1和D3，替换成模块B和D分别与模块E和F相连，并且设立驱动模块D4和D5进行局部集成测试。最后，如图10-15(f)所示，对整个系统结构进行集成测试。

(3)混合增值测试方式。自顶向下增值方式和自底向上增值方式各有优缺点。通常是把以上两种方式结合起来进行测试，即混合增值测试方式。

3.系统测试系统测试是将已经集成好的软件系统与计算机硬件、外设、某些支撑软件、数据和人员等结合在一起，在实际运行环境下，对计算机系统进行一系列的确认测试。

1)常见的系统测试方法常见的系统测试方法有：恢复测试、安全测试、强度测试、性能测试、可靠性测试、兼容性测试。恢复测试是通过各种手段，强制性地让