7.集成测试

一、集成测试介绍

• 测试
  单元测试 → 集成测试 → 系统测试
• 软件开发
  需求 → 高层设计 → 底层设计 → 代码
• 灰盒测试

定义

• 集成测试（集成测试、综合测试、联合测试、整体测试测试、实验测试）
• 集成测试是软件测试的阶段，在该阶段中，各个软件模块被组合在一起并作为一个组进行测试。
• 集成测试在单元测试之后并在系统测试之前。

集成测试 VS 单元测试

• 在集成测试之前，单元测试已经完成。
• 单元测试和集成测试关注的范围不同。

集成测试 VS 系统测试

• 系统测试和集成测试站在不同的角度。
• 集成测试的目的是验证对高级设计项目的功能、性能和可靠性要求。

集成测试的主要优点

• 缺陷被及早发现。
• 更容易修复早期检测到的缺陷。
• 我们会更早地获得有关各个模块和整个系统的健康状况和可接受性的反馈。
• 缺陷修复的计划是灵活的，并且可以与开发重叠。

主要测试重点

• 模块（或组件）之间的接口
• 集成功能特性
• 交互协议和消息
• 系统架构

集成测试步骤

第 1 步：创建测试计划
第 2 步：设计测试用例并准备测试数据
第 3 步：如果适用，创建脚本以运行测试用例
第 4 步：一旦集成了组件，执行测试用例
第 5 步：修复错误（如果有）并重新测试代码
第 6 步：重复测试循环，直到组件成功集成

集成测试周期数和总集成时间由以下参数决定

• 系统模块数

• 模块的相对复杂度（圈复杂度）

• 模块间接口的相对复杂度

• 每个测试周期中需要聚集在一起的模块数量

• 待集成模块之前是否经过充分测试

• 每个测试-调试-修复周期的周转时间

• 集成测试作为一系列测试周期以增量方式进行。

• 在每个测试周期中，更多的模块与现有的和经过测试的构建集成，以生成更大的构建。

• 一个完整的系统被一个周期一个周期地构建，直到整个系统可以运行以进行系统级测试。

什么时候完成集成测试

• 该系统完全集成在一起。
• 所有的测试用例都已经执行完毕。
• 发现的所有严重和中等缺陷都已修复。

集成测试功能

• 单元测试不完全，会无能为力检查内容是否正确，相互称为模块关系。
• 与系统测试相比，集成测试用例从程序结构入手，目的和目标更强，测试可以更有效地发现和定位问题。
• 它可以更轻松地模拟特殊困难的异常流，然后系统可以测试测试用例。
• 快速定位问题。

集成测试与开发的关系

• 集成测试与大纲设计相对应，系统结构中的大纲设计是集成测试的基础。
• Booch Grady 认为集成是面向对象开发的关键活动。
• 在结构设计开发中，集成测试同样重要。
• 集成测试和架构设计之间的依赖。

什么时候进行集成测试

• 构成组件的单元或模块
• 组成系统的组件
• 形成产品的系统
• 集成测试有时被定义为单元和系统之间的测试级别。

集成测试级别

• 模块间集成
• 子系统内集成
• 子系统集成
• 成对测试

二、集成测试策略

• 描述模块集成（组装）方法。
• 如何组合系统的模块？ 全部同时组装还是逐步组装？
• 集成测试基本策略较多，分类比较复杂，但可以分为以下两类：
  • 非增量整合策略——一口气
  • 增量整合战略——逐步实现

集成测试可以分为两类

• 增量集成测试：增量测试逐步扩展集成模块集。
• 非增量集成测试：通过非增量测试，软件模块被随机组合和测试。

Big bang（大爆炸） integration

它是一种非增量集成方法，它一次将所有系统组件集成在一起，不考虑组件的依赖性和可能的风险。

• 优势
  集成测试可以快速完成，只需要很少的存根和驱动程序。
  多位测试人员可并行工作，人力物力利用率更高。
• 坏处
  发现错误时更难定位和更改。
  许多接口错误直到系统测试才发现。
• 范围
  现有系统只需少量修改
  具有足够单元测试的小型系统
  系统由经过认证的高质量可重复使用组件制成
• 即时与增量集成测试
  • 即时集成测试有时被称为大爆炸方法。 在爆炸之后定位细微的错误可能非常困难。
  • 增量集成测试会导致一些额外的开销，但可以显着减少错误定位和纠正时间。 最佳增量方法本质上取决于单个项目和各种替代方案的利弊。

Top-down （自顶向下）integration

步骤：

（1）首先关注顶层组件，然后逐步测试底层组件。
（2）可以使用深度优先和呼吸优先策略。
（3）进行回归测试，排除集成可能导致的错误。
（4） 所有模块都集成到系统中完成测试，否则转（2）。

• 当存根不能传达正确有用的信息时，可以使用其他一些方法
  • 许多测试可以推迟到用真实模块替换的存根
  • 进一步的开发模块可以模拟存根的实际功能
  • 自下而上的集成
• 优势
  早期显示控制和判断要点。
  使用深度优先组装，可以先实现并验证完整的软件功能。
  最多只需要一个驱动模块。
  支持故障隔离。
• 缺点
  存根的开发和维护成本都较高。
  底层组件需求无法预测可能会导致对顶层组件进行多次修正。
• 范围
  产品控制结构比较清晰稳定。
  高级产品界面变化比较小。
  产品底层接口未定义或可能经常更改。
  产品控制模块技术风险大，需要尽快验证。

Bottom-up （自底向上）integration

定义

从底层最少的依赖组件开始，按照依赖结构，层层向上集成，检测整个系统的稳定性

步骤

(1) 对于给定级别的模块，其子模块（包括子模块下级模块）都有组装和测试，所以不需要存根。
(2) 从底层模块开始，也可以添加两个或多个叶子模块合并一起测试。
(3) 开发驱动模块对step2中的模块进行测试，然后用实际模块代替驱动模块，将被测模块合并为一个大模块进行测试。
(4) 重复该过程直到顶层模块测试。

优势
允许对底层模块进行早期认证，任何准备好进行集成测试的叶节点都可以进行测试。
减少存根开发的工作量
支持故障隔离
缺点
驱动模块开发工作量比较大。
高级验证被推迟到最后，无法及时发现设计错误。
底部异常硬盖。

范围
底层接口比较稳定，高层接口变化比较频繁的产品。
较早完成底部模块的产品。

Sandwich（三明治） integration

结合自上而下策略和自下而上策略的优势。

优势
结合自上而下策略和自下而上策略的优势。
缺点
集成测试前中层测试不够。
范围
大多数软件开发项目都使用它。

Layers（分层） integration

通过增量集成方法验证特定级别架构应用系统的稳定性和互操作性。

策略
系统的层分区。
确定集成策略内部级别。
确定级别之间的集成策略。
范围
通讯软件。
层次分明的产品体系。

High-frequency （高频）integration

频繁的新代码被添加到稳定的基线中，以检测集成故障并控制可能的基线偏差。

• 高频积分所需条件
  得到一个稳定的增量，一个完整的子系统已经被证明没有问题。
  最有意义的递增函数可以固定在一个频繁的间隔，例如每日构建。
  测试套件与代码并行开发，并始终保持最新版本。
  使用自动化。
  使用配置管理工具，否则递增版本将失控。

• 策略
  开发者提供完整的增量代码，测试者同时完成相关测试包的开发。
  测试人员修改或添加组件以形成新的集成体，并在其上运行集成测试套件。
  评价结果

• 优势
  错误预防有效。
  可以更早地发现严重的错误、遗漏和不正确的假设。
  错误定位比较容易。
  减少存根代码和驱动程序代码的开发。
  开发和集成可以同步进行。

• 缺点
  在最初的几个周期中可能很难顺利整合。
  高频积分频率需要把握好。

• 范围
  迭代过程模型开发的产品

• 创建每日构建在许多组织中非常流行（特别是在迭代的系统中）

  它有助于更快地交付系统

  它强调小的增量测试

  它稳定地增加了测试用例的数量

  系统使用自动化的、可重用的测试用例进行测试

  努力修复在24小时内发现的缺陷

  构建的前一个版本保留为引用和回滚

  一个典型的实践是保留过去的7-10构建

Event-based（基于事件） integration

从消息的认证路径正确性出发，逐步集成系统，验证系统稳定性。

• 策略
  从外部系统，分析可能的系统输入集。
  选择一条消息分析通过的模块。
  集成这些模块并测试消息接口。
  重复上述步骤，直到所有消息都被测试。
• 优势
  验证一条消息可能需要几个模块，进度会更快。
  减少驱动模块开发。
• 缺点
  对于复杂的系统，消息之间的相互关系可能复杂且难以分析。
  对于接口测试来说，它是不够的。
• 范围
  面向对象的系统。
  基于有限状态机的嵌入式系统。
• 为每个新构建（模块集）创建一个测试策略，并在规划测试策略时解决以下问题
  需要从 SIT 测试计划中选择哪些测试用例？
  哪些以前失败的测试用例现在应该重新执行以测试新版本中的修复？
  如何确定部分回归测试的范围？
  测试此构建的估计时间、资源需求和成本是多少？

三、集成测试分析

集成测试关注的内容

1.架构分析

• 从需求跟踪入手，划分系统实现的结构层次。
  目的
  – 综合水平考试略有帮助。
• 找出组件之间的依赖关系。
  目的
  – 确定集成测试的粒度，即基础模块大小。

2.模块分析

• 清除测试模块。
• 识别模块之间的关系，然后首先集成最相关的模块。
• 依次集成低耦合模块。

3.接口分析

• 接口划分
  • 确定系统、子系统的边界和模块。
  • 确定模块内部接口、子系统内部接口和系统内部接口。
  • 确定模块或子系统之间的接口。
  • 确定系统与操作系统、硬件和软件接口以及第三方之间的接口。
• 接口分类
  • 功能界面
  • 消息接口
  • 类接口
• 接口数据分析
  • 跨接口分析数据。
  • 函数接口侧重于参数编号、顺序、属性等。
  • 消息接口侧重于消息类型、消息域等。
  • 类接口侧重于属性和行为。

4.可测试性分析

主要将可测试性下降集中在不断增加的集成上。 所以要充分注意不能测试的接口，尽快找到解决办法。

5.集成测试策略分析

• 良好的集成测试策略主要关注
  • 测试对象可以充分测试，尤其是关键模块。
  • 模块和接口清晰。
  • 投入资源得到充分利用。

6.常见的集成测试故障

• 配置/版本控制错误
• 功能的遗漏、重叠或冲突
• 文档或数据库使用不正确或不一致
• 错误的对象和信息绑定。 错误的参数或不正确的参数值
• 组件之间的冲突
• 资源竞争

四、集成测试用例设计

使用的设计思路和方法

1.为运行系统设计测试用例。

• 在集成测试中需要关注的是接口可以使用，并且不会阻塞集成测试的后续执行。 所以测试人员可以根据这个原则设计一些基本的功能测试用例来进行最小功能限制验证。
• 技术与方法
  • 等价划分法
  • 规范导出方法（规范导出法）
    • 根据相应的标准描述设计测试用例。
    • 每个测试用例用于测试一个或多个标准声明。
    • 基本上是按照语句的顺序使用，从规范的语句设计相关的测试用例。
    • 这种方法实现了测试用例和标准化语句之间非常好的对应。 加强标准化的可读性和可维护性。
    • 是一种正向测试技术，需要反向测试技术来补充测试用例。
    • 当某些用例的标准需要不同的处理时，每个语句可能需要更多的测试用例。

2.设计正面测试的测试用例。

• 界面设计和模块功能设计要求清晰、正确。
• 测试侧重于接口需求的验证和集成模块功能的正确满足。
• 根据大纲设计文档导出相关测试用例。
• 技术与方法
  • 标准出口方式
  • 输入测试
  • 输出覆盖测试
  • 等价划分
  • 状态转换测试

3.设计测试用例进行反向测试。

• 逆向测试包括分析接口是否实现了规范不需要的功能，可能的接口遗漏或接口定义错误的规范，分析接口可能的异常，包括接口数据错误，接口数据序列错误。
• 技术与方法
  错误猜测法
  基于测试的风险
  基于故障测试
  边值分析
  特殊值测试
  状态转移方法

4.针对特殊需求设计测试用例。

• 安全测试、性能测试、可靠性测试都应该在系统测试阶段进行，但是有些产品在模块设计文档中已经明确了这些指标，对于有特殊要求的接口应该尽早测试。
• 技术与方法
  标准化出口方式

5.设计满足覆盖的测试用例。

Function cover
Interface cover
Technology and method

6.测试用例补充。

新增功能、特性修改、缺陷修改

注意

• 成本、进度和质量
• 高亮测试键，必须覆盖键接口
• 充分考虑回归和执行自动化

五、集成测试流程

1. 策划阶段
2. 设计阶段
3. 实施阶段
4. 表演舞台

六、集成测试环境

• 对于一个简单的系统（单进程软件），集成测试环境和单元测试环境是相似的。
• 对于复杂的系统，往往分布在不同的硬件和软件平台上。 集成测试环境非常复杂，需要依赖一些商业测试工具或测试仪，有时还需要开发一些界面模拟工具。
• 在考虑集成测试环境时，请遵循以下几个方面：
  硬件环境
  操作环境
  数据库环境
  网络环境

七、集成测试原则

• 关键模块必须经过充分测试
• 必须测试所有接口
• 集成测试应该按照一定的级别进行
• 当接口发生变化时，所有相关接口都应使用回归测试进行测试
• 集成测试按计划进行，防止随机测试
• 集成测试策略应该整合质量、成本和进度之间的关系