第12章 测试层次 第13章 集成测试

集成测试关注的问题
模块间的数据传递是否正确？ 一个模块的功能是否会对另一个模块的 功能产生错误影响？ 全局数据结构是否有问题，会不会被异 常修改？ 块组合起来的功能能否满足要求？ 集成后，各个模块的累积误差是否会扩 大，是否达到不可接受的程度？
集成测试的第一步
模块分析是集成测试的第一步，也是最 重要的工作之一。模块划分的好坏直接 影响集成测试工作量、进度和质量。 软件工程的2/8原则：测试中发现的80% 的错误可能源于20%的模块。 一般将模块划分为3个等级：高危模块、 一般模块和低危模块。高危模块应该优 先测试。
系统测试：通过与系统需求定义相比较，发 现软件与系统定义不符合或矛盾的地方。
集成测试与系统测试的区别
测试角度
集成测试：更多是站在开发人员的角度上， 以便发现更多的问题。
系统测试：更多是站在用户的角度来进行， 以证明系统的各个组成部分能够协调一致地 工作，以及验证软件在其运行的软件环境和 硬件环境下都可以正常工作。
集成测试与系统测试的区别ห้องสมุดไป่ตู้
测试对象
集成测试的对象是由通过了单元测试的各个 模块所集成起来的组件。
系统测试的测试对象除了软件之外，还包括 计算机硬件、相关外围设备以及数据传输机 构等。
测试时间
集成测试是介于单元测试和系统测试之间的 测试。
集成测试与系统测试的区别
测试方法
集成测试：通常采用白盒测试和黑盒测试相 结合的测试方法。
最终结果：功能分解
将集成测试与系统测试分开
线索：与执行时间行为有关的构造。 结构认识
集成测试所处的层次要比系统测试细得多。 对传统的瀑布模型，集成测试考虑的是概要
设计信息；系统测试是在需求规格说明层次 上。 找出系统线索、集成线索。
行为认识
以系统的系统级输入、输出位置上的端口边 界来考虑系统。系统端口事件为系统测试用 例的“原语”。
文件、数据库、队列、第三方中间件等：表现 的主要是数据的传递，其中的控制体现的不明 显。
共享资源：比如共享一段“存储区域”，其 中涉及的关键资源主要是“锁”了；这样的 两个模块在运行时往往分布到不同的进程或 者线程中，表现为对资源的竞争，以及数据 的共享。
同步：一个模块的运行需要另外一个模块的 触发，双方往往存在“信号”等通知机制， 也可以理解为一种特殊的控制方式。
W模型
W模型由Evolutif公司提出，相对于V模 型，W模型增加了软件各开发阶段中应 同步进行的验证和确认活动。 W模型由两个V字型模型组成，分别代表 测试与开发过程，图中明确表示出了测 试与开发的并行关系。
W模型
W模型
W模型强调：测试伴随着整个软件开发周期，而且测试的 对象不仅仅是程序，需求、设计等同样要测试，也就是说， 测试与开发是同步进行的。W模型有利于尽早地全面的发 现问题。例如，需求分析完成后，测试人员就应该参与到 对需求的验证和确认活动中，以尽早地找出缺陷所在。同 时，对需求的测试也有利于及时了解项目难度和测试风险， 及早制定应对措施，这将显著减少总体测试时间，加快项 目进度。 但W模型也存在局限性。在W模型中，需求、设计、编码 等活动被视为串行的，同时，测试和开发活动也保持着一 种线性的前后关系，上一阶段完全结束，才可正式开始下 一个阶段工作。这样就无法支持迭代的开发模型。对于当 前软件开发复杂多变的情况，W模型并不能解除测试管理 面临着困惑。
集成与系统测试
集成测试：集成测试是在软件系统集成 过程中所进行的测试，其主要目的是检 查软件单元之间的接口是否正确。它根 据集成测试计划，一边将模块或其他软 件单元组合成越来越大的系统，一边运 行该系统，以分析所组成的系统是否正 确，各组成部分是否合拍。集成测试的 策略主要有自顶向下和自底向上两种。
集成线索可看作单元级线索序列，但不考虑 单元线索的“内部问题”，只考虑单元线索 的交互。
第13章 集成测试
按设计要求把通过单元测试的各个模块 组装在一起之后，进行综合测试以便发 现与接口有关的各种错误。
集成测试过程通常是根据具体情况采取 不同的集成策略将多个模块组装成为子 系统或系统，以测试各个模块能否以正 确、稳定、一致的方式接口和交互，验 证其是否符合软件开发过程中的概要设 计说明书的要求。
传统瀑布模型的新模型
从功能分解转向强调合成，弥补传统瀑 布模型的不足。 以合成为核心，对集成和系统测试产生 重要影响。 瀑布模型三种主流派生：增量开发、进 化开发、螺旋模型。
回归测试：保证在前一个构建中工作正 常的功能，新增加了代码之后仍工作正 常。
累进测试：假设回归测试是成功的，且 新功能是可测试的。
自顶向下集成
构造程序结构的一种增量式方式。
从主程序开始，所有被主程序调用的下层单元 都作为“桩”出现。
自顶向下集成方法是一个日益为人们广泛采用 的测试和组装软件的途径。从主控制模块开始， 沿着程序的控制层次向下移动，逐渐把各个模 块结合起来。在把附属于（及最终附属于）主 控制模块的那些模块组装到程序结构中去，或 者使用深度优先的策略，或者使用宽度优先的 策略。
第四部分 集成与系统测试
软件在系统集成时会经常有这样的情况 发生，即每个模块都能单独工作，但这 些模块集成在一起之后却不能正常工作， 或是系统集成后虽可以正常运行，但系 统的容错性、安全性以及整体性却得不 到保障，系统不能长时间运行等等。这 就需要进行集成测试和系统测试，以找 出其中的软件缺陷，来提高整个软件的 质量和可靠性。
集成测试的层次
对于传统软件来说，按集成粒度不同，可 以把集成测试分为3个层次，即：
模块间集成测试 子系统内集成测试 子系统间集成测试
对于面向对象的应用系统来说，按集成粒 度不同，可以把集成测试分为2个层次：
类内集成测试 类间集成测试
集成测试的原则
所有公共接口必须被测试到； 关键模块必须进行充分测试； 集成测试应当按一定层次进行； 集成测试策略选择应当综合考虑质量、成本和 进度三者之间的关系； 集成测试应当尽早开始，并以概要设计为基础； 在模块和接口的划分上，测试人员应该和开发 人员进行充分沟通；
测试 G
非渐增式集成
渐增式集成
渐增式集成与“一步到位”的非渐增式集成相 反，它把程序划分成小段来构造和测试，在这 个过程中比较容易定位和改正错误；对接口可 以进行更彻底的测试；可以使用系统化的测试 方法。因此，目前在进行集成测试时普遍采用 渐增式集成方法。 当使用渐增方式把模块结合到程序中去时，有 自顶向下和自底向上两种集成策略。
集成测试策略
由模块组装成程序时有两种方法
先分别测试每个模块，再把所有模块按设计 要求放在一起结合成所要的程序，称为非渐 增式集成；
把下一个要测试的模块同已经测试好的模块 结合起来进行测试，测试完成后再把下一个 应该测试的模块结合起来进行测试，每次增 加一个模块，称为渐增式集成。
对两个以上模块进行集成时，用辅助模块来 模拟模块间的联系。
集成测试的原则
当测试计划中的结束标准满足时，集成 测试才能结束； 当接口发生修改时，涉及的相关接口都 必须进行回归测试； 集成测试应根据集成测试计划和方案进 行，不能随意测试； 项目管理者应保证审核测试用例； 测试执行结果应当如实地记录。
集成测试中用到的辅助模块
驱动模块：用以模拟待测模块的上级模 块。驱动模块在集成测试中接受测试数 据，把相关的数据传送给待测模块，启 动待测模块； 桩模块：用以模拟待测模块工作过程中 所调用的模块。桩模块由待测模块调用， 它们一般只进行很少的数据处理。
非渐增式集成
非渐增式集成方法首先对每个子模块进 行测试（即单元测试），然后将所有模 块全部集成起来一次性进行集成测试。
【例】 对如图所示的程序，采用非渐增 式集成方法进行集成测试。 A
B
C
D
E
F
G
程序结构图
非渐增式集成
测试 A
测试 B
测试 C
测试 D
测试 E
测试 F
测试 （A、B、C D、E、F、G）
自顶向下集成
从主控模块开始，按照软件的控制层次结 构，以深度优先或广度优先的策略，逐步 把各个模块集成在一起。
深度优先策略首先是把主控制路径上的模块集 成在一起，至于选择哪一条路径作为主控制路 径，带有随意性，一般情况下是根据问题的特 性确定。
自顶向下集成
以图1为例，若选择了最左一条路径，首先将模 块M1、M2、M5和M8集成在一起，再将M6集成起 来，然后考虑中间和右边的路径。
V模型
V模型
V模型最早是由Paul Rook在２０世纪８０年代后 期提出的，旨在改进软件开发的效率和效果，反 映出了测试活动与分析设计活动的关系。 V模型指出，单元和集成测试应检测程序的执行是 否满足软件设计的要求；系统测试应检测系统功 能、性能的质量特性是否达到系统要求的指标； 验收测试确定软件的实现是否满足用户需要或合 同的要求。 但V模型存在一定的局限性，它仅仅把测试作为在 编码之后的一个阶段，是针对程序进行的寻找错 误的活动，而忽视了测试活动对需求分析、系统 设计等活动的验证和确认的功能。
基于规格说明的生命周期模型
快速原型法：对集成测试没有特别要求， 对系统测试有特殊要求。 可执行规格说明：从可执行规格说明中 直接导出系统测试用例。
ASTM系统的分析
需求规格说明的结构化分析方法
以三种互补模型为基础：功能、数据和控制 功能模型使用数据流图 数据模型使用实体/关系模型 控制模型使用有限状态机
集成与系统测试
系统测试：系统测试是对已经集成好的软件系 统进行彻底的测试，以验证软件系统的正确性 和性能等满足其规约所指定的要求，检查软件 的行为和输出是否正确并非一项简单的任务， 它被称为测试的 “ 先知者问题 ” 。因此，系 统测试应该按照测试计划进行，其输入、输出 和其他动态运行行为应该与软件规约进行对比。 软件系统测试方法很多，主要有功能测试、性 能测试、随机测试等等。
软件测试过程
软件测试过程是一种抽象的模型，用于定义软 件测试的流程和方法。 软件测试过程和软件开发过程一样，都遵循软 件工程原理，遵循管理学原理。 随着测试过程管理的发展，软件测试专家通过 实践总结出了很多很好的测试过程模型。这些 模型将测试活动进行了抽象，并与开发活动有 机的进行了结合，是测试过程管理的重要参考 依据。
基于功能分解的集成
基于功能分解（以功能分解树为基础）， 四种方式：自顶向下、自底向上、三明 治、大爆炸。 所有集成顺序都假设单元已经通过单独 测试。 目标：测试通过单独测试的单元接口。
模块之间的接口类型：
通信协议：两个模块之间通信采用的是标准的 或者自定义的（网络）协议；
调用关系：模块A调用模块B，实际上是由模块 A向模块B发出了一条控制指令，这里数据传递 体现的不是很明显，往往体现为参数与返回值， 它们可以认为是控制的副本。
传统模型下的测试层次
测试层次的传统观念
传统软件开发V瀑布模型：强调测试的基本 层次，一个开发阶段产生的信息，构成该层 次测试用例标识的基础。
集成测试：根据功能分解树集成以前测试过 的单元。
自顶向下集成：测试桩 自底向上集成：测试驱动器 大爆炸集成
传统模型下的测试层次
系统测试：客户能够理解的活动，常与客户 验收测试结合一起进行。一般系统测试是功 能性测试。
系统测试：通常使用黑盒测试方法。
测试内容
集成测试：各个单元模块直接的接口，以及 各个模块集成后所实现的功能。
系统测试：整个系统的功能和性能。
集成测试与系统测试的区别
测试目的
集成测试：发现单元之间接口的错误，以及 发现集成后的软件同软件概要设计说明书不 一致的地方，确保各个单元模块组合在一起 后，能够达到软件概要设计说明的要求，协 调一致地工作。
集成测试与开发
集成测试与软件开发过程中的概要设计相关， 概要设计中关于整个系统的体系结构是集成测 试用例设计的基础。
概要设计作为软件设计的骨架，可以清晰地表 示出大型系统中的组件或子系统的层次构造， 软件产品的层次、组件分布、子系统分布等信 息为集成测试策略的选取提供了重要的参考依 据。
集成测试可以检验所设计的软件构架是否存在 错误和遗漏，以及是否存在二义性。