正确的集成测试描述包括（43)。<br />①集成测试也叫做组装测试，通常是在单元测试的基..

2009年上半年上午试卷综合知识

第 43 题


知识点	单元测试集成测试测试的目的数据结构详细设计组装测试
关键词	单元测试集成测试接口模块设计约束数据结构算法详细设计自顶向下测试数据
章/节	软件测试类型

正确的集成测试描述包括（43)。
①集成测试也叫做组装测试，通常是在单元测试的基础上，将模块按照设计说明书要求进行组装和测试的过程
②自顶向下的增殖方式是集成测试的一种组装方式，它能较早地验证主要的控制和判断点，对于输入输出模块、复杂算法模块中存在的错误能够较早地发现
③集成测试的目的在于检查被测模块能否正确实现详细设计说明中的模块功能、性能、接口和设计约束等要求
④集成测试需要重点关注各个模块之间的相互影响，发现并排除全局数据结构问题

A. ①②

B. ②③

C. ①④

D. ②④

相关试题开发阶段

第52题

2020年下半年

以下不属于单元测试中局部数据结构测试内容的是（52）。

第52题

2014年下半年

以下测试内容中，属于系统测试的是 (52) 。
①单元测试 ②集成测试 ③安全性测试
④可靠性测试 ⑤兼容性测试 ⑥可用性测试

第51题

2015年下半年

以下不属于系统测试的是（51）。
①单元测试
②集成测试
③安全性测试
④可靠性测试
⑤确认测试
⑥验证测试

知识点讲解

· 单元测试

· 集成测试

· 测试的目的

· 数据结构

· 详细设计

· 组装测试

单元测试

单元测试又称模块测试，是针对软件设计的最小单位——程序模块，进行正确性检验的测试工作。其目的在于发现各模块内部可能存在的各种差错。单元测试需要从程序的内部结构出发设计测试用例。多个模块可以平行地独立进行单元测试。

. 单元测试的内容。

在进行单元测试时，测试者需要依据详细设计说明书和源程序清单，了解该模块的I/O条件和模块的逻辑结构，主要采用白盒测试的测试用例，辅之以黑盒测试的测试用例，使之对任何合理的输入和不合理的输入，都能鉴别和响应。这要求对所有的局部的和全局的数据结构、外部接口和程序代码的关键部分，都要进行桌面检查和严格的代码审查。

在单元测试中进行的测试工作如下图所示，需要在五个方面对所测模块进行检查。

单元测试的工作

①模块接口测试。

在单元测试的开始，应对通过所测模块的数据流进行测试。如果数据不能正确地输入和输出，就谈不上进行其他测试。为此，对模块接口可能需要如下的测试项目：调用所测模块时的输入参数与模块的形式参数在个数、属性、顺序上是否匹配；所测模块调用子模块时，它输入给子模块的参数与子模块中的形式参数在个数、属性、顺序上是否匹配；是否修改了只作输入用的形式参数；输出给标准函数的参数在个数、属性、顺序上是否正确；全局量的定义在各模块中是否一致；限制是否通过形式参数来传送。

当模块通过外部设备进行输入/输出操作时，必须附加如下的测试项目：文件属性是否正确；OPEN语句与CLOSE语句是否正确；规定的I/O格式说明与I/O语句是否匹配；缓冲区容量与记录长度是否匹配；在进行读写操作之前是否打开了文件；在结束文件处理时是否关闭了文件；正文书写/输入错误，以及I/O错误是否检查并做了处理。

②局部数据结构测试。

模块的局部数据结构是最常见的错误来源，应设计测试用例以检查以下各种错误：不正确或不一致的数据类型说明；使用尚未赋值或尚未初始化的变量；错误的初始值或错误的缺省值；变量名拼写错或书写错；不一致的数据类型。可能的话，除局部数据之外的全局数据对模块的影响也需要查清。

③路径测试。

由于通常不可能做到穷举测试，所以在单元测试期间要选择适当的测试用例，对模块中重要的执行路径进行测试。应当设计测试用例查找由于错误的计算、不正确的比较或不正常的控制流而导致的错误。对基本执行路径和循环进行测试，可以发现大量的路径错误。

常见的不正确计算有：运算的优先次序不正确或误解了运算的优先次序；运算的方式错，即运算的对象彼此在类型上不相容；算法错；初始化不正确；运算精度不够；表达式的符号表示不正确。

常见的比较和控制流错误有：不同数据类型的相互比较；不正确的逻辑运算符或优先次序；因浮点数运算精度问题而造成的两值比较不等；关系表达式中不正确的变量和比较符；“差1”错，即不正确地多循环一次或少循环一次；错误的或不可能的循环中止条件；当遇到发散的迭代时不能中止的循环；不适当地修改了循环变量等。

④错误处理测试。

比较完善的模块设计要求能预见出错的条件，并设置适当的出错处理，以便在一旦程序出错时，能对出错程序重做安排，保证其逻辑上的正确性。这种出错处理也应当是模块功能的一部分。若出现下列情况之一，则表明模块的错误处理功能包含有错误或缺陷：出错的描述难以理解；出错的描述不足以对错误定位，不足以确定出错的原因；显示的错误与实际的错误不符；对错误条件的处理不正确；在对错误进行处理之前，错误条件已经引起系统的干预等。

⑤边界测试。

在边界上出现错误是常见的。例如，在一段程序内有一个n次循环，当到达第n次重复时就可能会出错。另外，在取最大值或最小值时也容易出错。因此，要特别注意数据流、控制流中刚好等于、大于或小于确定的比较值时出错的可能性。对这些地方要仔细地选择测试用例，认真加以测试。

此外，如果对模块运行时间有要求的话，还要专门进行关键路径测试，以确定最坏情况下和平均意义下影响模块运行时间的因素。这类信息对进行性能评价是十分有用的。

虽然模块测试通常是由编写程序的人自己完成的，但是项目负责人应当关心测试的结果。所有测试用例和测试结果都是模块开发的重要资料，必须妥善保存。

总之，模块测试针对的程序规模较小，易于查错；发现错误后容易确定错误的位置，易于排错，同时多个模块可以并行测试。做好模块测试可为后续的测试打下良好的基础。

. 单元测试的步骤。

通常单元测试是在编码阶段进行的。在源程序代码编制完成，经过评审和验证，确认没有语法错误之后，就开始进行单元测试的测试用例设计。利用设计文档，设计可以验证程序功能、找出程序错误的多个测试用例。对于每一组输入，应有预期的正确结果。

模块并不是一个独立的程序，在考虑测试模块时，同时要考虑它和外界的联系，用一些辅助模块去模拟与所测模块相联系的其他模块。这些辅助模块分为两种：

驱动模块（driver）——相当于所测模块的主程序。它接收测试数据，把这些数据传送给所测模块，最后再输出实测结果。

桩模块（stub）——也叫做存根模块。用以代替所测模块调用的子模块。桩模块可以做少量的数据操作，不需要把子模块所有功能都带进来，但不允许什么事情也不做。

所测模块、与它相关的驱动模块及桩模块共同构成了一个“测试环境”，如下图所示。驱动模块和桩模块的编写会给测试带来额外的开销。因为它们在软件交付时不作为产品的一部分一同交付，而且它们的编写需要一定的工作量。特别是桩模块，不能只简单地给出“曾经进入”的信息。为了能够正确地测试软件，桩模块可能需要模拟实际子模块的功能，这样，桩模块的建立就不是很轻松了。

单元测试的测试环境

模块的内聚程度高，可以简化单元测试过程。如果每一个模块只完成一种功能，则需要的测试用例数目将明显减少，模块中的错误也容易被预测和发现。

当然，如果一个模块要完成多种功能，且以程序包（package）的形式出现的也不少见，这时可以将这个模块看成由几个小程序组成。必须对其中的每个小程序先进行单元测试要做的工作，对关键模块还要做性能测试。对支持某些标准规程的程序，更要着手进行互联测试。有人把这种情况特别称为模块测试，以区别单元测试。

集成测试

集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

. 组装时需要考虑的问题。

①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

②一个模块的功能是否会对另一个模块的功能产生不利的影响；

③各个子功能组合起来，能否达到预期要求的父功能；

④全局数据结构是否有问题；

⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。

选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。

. 模块组装成为系统的方式。

模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。

①一次性组装方式（big bang）。

它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。

一次性组装方式

在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。

②增殖式组装方式。

这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

. 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。

自顶向下的增殖方式

自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。

. 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。

以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。

一次性组装方式

自底向上的增殖方式

. 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。

自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。

自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。

在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：

. 满足某些软件需求；

. 在程序的模块结构中位于较高的层次（高层控制模块）；

. 较复杂、较易发生错误；

. 有明确定义的性能要求。

在做回归测试时，也应该集中测试关键模块的功能。

. 集成测试的组织和实施。

集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：

①采用何种系统组装方法来进行集成测试。

②集成测试过程中连接各个模块的顺序。

③模块代码编制和测试进度是否与集成测试的顺序一致。

④测试过程中是否需要专门的硬件设备。

解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。

在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。

. 集成测试完成的标志。

集成测试完成的标志主要有以下几项。

①成功地执行了测试计划中规定的所有集成测试。

②修正了所发现的错误。

③测试结果通过了专门小组的评审。

集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。

集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。

测试的目的

软件测试是软件质量保证的主要手段之一，也是在将软件交付给客户之前所必须完成的步骤。目前，软件的正确性证明尚未得到根本的解决，软件测试仍是发现软件错误和缺陷的主要手段。软件测试的目的就是在软件投入生产性运行之前，尽可能多地发现软件产品（主要是指程序）中的错误和缺陷。

1983年，Bill Hetzel在《Complete Guide of Software Testing》一书中指出：“测试是以评价一个程序或系统属性为目标的任何一种活动。测试是对软件质量的度量”。Grenford J. Myers在《The Art of Software Testing》一书中指出：

（1）软件测试是为了发现错误而执行程序的过程。

（2）测试是为了证明程序有错，而不是证明程序无错误。

（3）一个好的测试用例在于它能发现至今未发现的错误。

（4）一个成功的测试是发现了至今未发现的错误的测试。

这种观点可以提醒人们测试要以查找错误为中心，而不是为了演示软件的正确功能。但是仅凭字面意思理解这一观点可能会产生误导，认为发现错误是软件测试的唯一目的，查找不出错误的测试就是没有价值的，事实并非如此。

首先，测试并不仅仅是为了要找出错误。通过分析错误产生的原因和错误的分布特征，可以帮助项目管理者发现当前所采用的软件过程的缺陷，以便改进。同时，这种分析也能帮助我们设计出有针对性的检测方法，改善测试的有效性。

其次，没有发现错误的测试也是有价值的，完整的测试是评定软件质量的一种方法。

因此，软件测试可以验证软件是否满足软件需求规格说明和软件设计所规定的功能、性能及软件质量特性的要求，为软件质量的评价提供依据。

软件测试只是软件质量保证的手段之一，不能单凭测试来保证软件质量。

数据结构

根据数据元素之间关系的不同特性，通常有下列4类基本的逻辑结构，即集合结构、线性结构、树形结构、图形结构。

1）线性结构

线性表是最常用且最简单的一种数据结构。线性表中除第一个元素外，每个元素均只有一个直接前驱；除最后一个元素外，每个元素都只有一个直接后继。

栈是限定仅在表尾进行插入或删除操作的线性表，是只能通过访问它的一端来实现数据存储和检索的一种线性数据结构。

队列是一种先进先出（FIFO）的线性表，它只允许在表的一端进行插入，而在另一端删除元素。

2）树

树是n（n≥0）个互不相交的有限集，当n=0时称为空树。在一棵非空树中，有且仅有一个节点称为根节点；当n>1时，其余的节点可分为若干个不相交的集合，其中每一个集合本身又是一棵树，这些集合称为根节点的子树。

3）图

图是由两个集合V和E组成的二元组，记为G=（V, E），其中V是顶点的非空有限集合，E是图中边的有限集合。

详细设计

总体设计只是为整个信息系统提供了一个设计思路和框架，框架内的血肉需要系统的设计人员在详细设计这个阶段充实。总体设计完成后，设计人员要向用户和有关部门提交一份详细的报告，说明设计方案的可行程度和更改情况，得到批准后转入系统详细设计。详细设计阶段主要是在总体设计的基础上，将设计方案进一步详细化、条理化和规范化，为各个具体任务选择适当的技术手段和处理方法。系统的详细设计一般包括如下。

（1）代码设计。

代码设计就是信息分类和编码的工作，是将系统中有某些共同属性或特征的信息归并在一起，并利用便于计算机和人识别和处理的符号来表示这些信息的设计工作。

（2）数据库设计。

数据库设计就是构建既能客观、准确地反映外部世界，又便于人类大脑认识的概念模型，并在此基础上对数据进行建模，转化为数据库管理系统所支持的数据模型；选择合适的存储结构和存储方法，最终完成数据库的设计工作。

（3）输入／输出设计。

输入／输出设计主要是对以记录为单位的各种输入输出报表格式的描述。另外，对人机对话格式的设计和输入输出装置的选择也在这一步完成。

（4）用户界面设计。

用户界面设计是指在用户与系统之间架起一座桥梁。主要内容包括：定义界面形式；定义基本的交互控制形式；定义图形和符号；定义通用的功能键和组合键的含义及其操作内容；定义帮助策略，等等。

（5）处理过程设计。

总体设计将系统分解为许多模块，并基本决定了每个模块的功能和界面。处理过程设计则定义每个模块的内部执行过程，包括数据的组织、控制流、每一步的具体加工要求和实施细节。通过处理过程设计，为编写程序制定一个周密的计划。一般来说，每一个功能模块都应设计一个处理流程。

组装测试

组装测试也被称为集成测试。即使所有模块都通过了测试，但在组装之后，仍可能会出现问题：通过模块的数据被丢失；一个模块的功能对其他模块造成有害的影响；各个模块被组合起来后没有达到预期功能；全局数据结构出现问题；另外单个模块的误差可以接受，但模块组合后，可能会出现误差累积，最后达到不能接受的程度，所以需要组装测试。

通常，组装测试有两种方法：一种是分别测试各个模块，再把这些模块组合起来进行整体测试，这种方法被称为非增量式集成。另一种是把下一个要测试的模块组合到已测试好的模块中，测试完后再将下一个需测试的模块组合进来进行测试，逐步把所有模块组合在一起，并完成测试。该方法被称为增量式集成。非增量式集成可以对模块进行并行测试，能充分利用人力，以加快工程进度。但这种方法容易混乱，出现的错误不容易被查找和定位。增量式测试的范围是一步步扩大的，所以错误容易被定位，而且已测试的模块可在新的条件下进行测试，程序测试得更彻底。

增量式测试技术有自顶向下的增量方式和自底向上的增量方式两种测试方法。

（1）自顶向下的增量方式。

自顶向下的增量方式是模块按程序的控制结构，从上到下的组合方式。再增加测试模块时有先深度后宽度和先宽度后深度两种次序。如下图所示的自顶向下组合示例中，先深度后宽度的方法是把程序结构中的一条主路径上的模块相组合，测试顺序可以是M₁→M₂→M_5→M₆→M₃→M₇→M₄。先宽度后深度的方法是把模块按层进行组合，测试顺序是M₁→M₂→M₃→M₄→M₅→M₆→M₇。组装过程可分成以下步骤：

自顶向下的组合示例

.用主模块作为驱动模块，与之直接相连的模块用桩模块代替。

.根据所选的测试次序，用下一个模块替换所用的桩模块；而新引入模块的直接下属模块用桩模块代替，构成新的测试对象。

.结合一个模块测试一个模块。为了避免引入新模块产生新问题，需要进行回归测试，即重复部分或全部已经进行过的测试。

.所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。

自顶向下的增量方式可以较早地验证控制和判断点，如果出现问题可及时进行纠正。在测试时不需要编写驱动模块，但需要桩模块。另外，如果高层模块对下层模块依赖性很大，需要返回大量信息，在用桩模块代替时，桩模块的编写就相对复杂，必然会增加开销。这时可以用下面介绍的自底向上的增量方式。

（2）自底向上的增量方式。

自底向上的增量方式是从最底层的功能模块开始，边组合边测试，从下向上地完成整个程序结构的测试。其步骤可以概括为：

.将最底层的模块组合成能完成某种特定功能的模块簇，为每个模块簇设计驱动程序，用驱动程序来控制并进行测试。

.按从下向上的方向，用实际模块替换相对应的驱动程序，组成新的模块簇，再为该模块簇设计驱动程序，用新的驱动程序进行控制和测试。

.所有模块是否已经被组合到系统中，并完成测试。如果没有完成测试，则返回到第二步，重复进行；如果完成测试，则停止测试。

自底向上的增量方式可以较早地发现底层关键性模块出现的错误。在测试时不需要缩写桩模块，但需要驱动模块。另外，这种方式对程序中的主要控制错误的发现相对较晚。

组装测试的方法选择取决于软件的特点和进度安排。在工程中，通常将这两种方法结合起来使用，即对位于软件结构中较上层的使用自顶向下的方法，而对于较底层的使用自底向上的方法。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5