什么是SIT？系统集成测试示例
托马斯·汉密尔顿
什么是系统集成测试？
系统 整合测试 被定义为在集成的硬件和软件环境中进行的一种软件测试，用于验证整个系统的行为。它是对完整的集成系统进行的测试，以评估系统是否符合其指定要求。
系统集成测试（SIT）用于验证软件系统各模块之间的交互。它主要验证软件需求规范/数据和软件设计文档中规定的高级和低级软件需求。
系统集成测试 (SIT) 还验证软件系统与其他系统的共存性，并测试软件应用程序各模块之间的接口。在这种测试中，模块首先单独进行测试，然后组合起来构成一个系统。例如，软件和/或硬件组件会逐步组合和测试，直到整个系统集成完成。
上图显示了 SIT 的定义过程：分别验证的模块逐步合并，直到一个单一的集成系统处于测试状态。
为什么进行系统集成测试？
在软件工程中，进行系统集成测试是因为，
- 它有助于检测 缺陷 早
- 将提供有关单个模块可接受性的早期反馈
- 缺陷修复的时间安排灵活，可以与开发重叠
- 正确的数据流
- 正确的控制流
- 正确的时机
- 正确的内存使用
- 符合软件要求
系统集成测试、系统测试和用户验收测试
由于这三个级别是连续的，所以经常会被混淆。 系统测试 SIT 会检查一个已完成的构建版本是否符合要求，而 SIT 则会检查不同构建版本之间的衔接问题。 用户验收测试 从客户的角度考察企业的适应性。下表对两者进行了区分。
| 参数 | 系统集成测试 | 系统测试 | 用户验收测试 |
|---|---|---|---|
| 主要重点 | 集成模块之间的接口和数据流 | 组装完成后的整体行为 | 适用于实际用途的业务 |
| 测试级别 | 二级 | 三级 | 上线前的最终阶段 |
| 技术 | 黑盒子 | 黑盒子、白盒子或灰盒子 | 黑盒子 |
| 执行者 | 集成测试人员和开发人员 | 独立测试团队 | 客户或最终用户 |
| 典型缺陷 | 接口、时序、内存和数据映射ping 错误 | 功能性和非功能性系统错误 | 可用性和需求不匹配 |
| 运行 | 后 单元测试 | SIT之后 | 系统测试后 |
顺序很重要。模块通过单元测试，系统集成测试 (SIT) 验证接口，系统测试验证组装后的产品，用户验收测试 (UAT) 确认产品符合业务预期。跳过ping SIT 会将接口缺陷推入 UAT 阶段，而 UAT 阶段的每次修复成本都要高得多。
如何进行系统集成测试
它是一种系统化的程序结构构建技术，同时进行测试以发现与接口相关的错误。
所有的模块都是预先集成好的，整个程序都是经过整体测试的，但在这个过程中，很可能会遇到一系列的错误。
纠正此类错误很困难，因为整个程序的庞大扩展使得隔离变得复杂。一旦纠正并纠正了这些错误，就会出现新的错误，并且该过程会无缝地无限循环. 为了避免这种情况，我们采用了另一种方法：增量集成。下一节将详细解释增量集成方法。
有一些增量方法，例如在基于目标处理器的系统上进行集成测试。使用的方法是 黑色 Box 测试与验证. 可以采用自下而上或自上而下的集成方式。
测试用例仅使用高级软件需求来定义。
软件集成也可能主要在主机环境中实现，目标环境特有的单元继续在主机中模拟。需要在目标环境中重复测试以进行确认。
此级别的确认测试将识别特定于环境的问题，例如内存分配和释放错误。在宿主机环境中进行软件集成的可行性取决于目标机特定功能的多少。对于某些嵌入式系统，其与目标机环境的耦合性非常强，因此在宿主机环境中进行软件集成是不切实际的。
大型软件开发会将软件集成划分为多个级别。较低级别的软件集成可能主要基于主机环境，而较高级别的软件集成则更加依赖于目标环境。
注意： 如果只测试软件，则称为软件软件集成测试 [SSIT]；如果同时测试硬件和软件，则称为硬件软件集成测试 [HSIT]。
增量法
由于一次性集成所有内容会使缺陷难以隔离，因此大多数团队都遵循这里描述的增量式方法。
增量测试是集成测试的一种方式。在这种测试方法中，您首先单独测试软件的每个模块，然后通过向其添加其他模块继续测试，然后再添加另一个模块，依此类推。
增量集成与大爆炸方法形成对比。程序以小段的形式构建和测试，其中错误更容易隔离和纠正。接口更有可能得到完整测试，并且可以应用系统测试方法。
增量测试有两种类型
- 自上而下的方法
- 自下而上的方法
自上而下的方法
在这种方法中，单独开始仅测试用户界面，使用存根模拟底层功能，然后向下移动集成较低层和较低层，如下图所示。
- 从主控制模块开始，通过控制层次向下集成模块
- 主控制模块的子模块以广度优先或深度优先的方式纳入结构中。
- 深度优先集成将结构上一条主要控制路径上的所有模块集成在一起，如下图所示：
模块集成过程按以下方式完成：
- 以主控模块作为测试驱动程序，用存根替代主控模块下属的所有模块。
- 根据所选方法（广度优先或深度优先），下属存根将逐个被实际模块替换。
- 每个模块集成时都会执行测试。
- 每组测试完成后，另一个存根将被替换为真实模块
- 确保没有引入新的错误 迭代测试 可以执行。
这个过程从步骤2开始一直持续到整个程序结构建立完成。自上而下的策略听起来相对简单，但在实践中，会出现逻辑问题。
最常见的问题是，当需要在层次结构的较低级别进行处理以充分测试较高级别时。
在自上而下的测试开始时，存根会替换低级模块，因此没有任何重要数据可以在程序结构中向上流动。
测试人员可能面临的挑战：
- 推迟许多测试直到存根被实际模块替换。
- 开发执行有限功能以模拟实际模块的存根。
- 从层次结构的底部向上集成软件。
注意： 第一种方法使我们失去了对特定测试与特定模块合并之间对应关系的控制。这可能导致难以确定错误的原因，而这往往会违反自上而下方法的高度约束性质。
第二种方法是可行的，但会导致很大的开销，因为存根变得越来越复杂。
自下而上的方法
自下而上的集成是从程序结构最底层的模块开始构建和测试，按照从下到上的顺序进行模块集成。
在这种方法中，对于给定级别的下属模块所需的处理始终可用，并且无需存根。
此集成测试过程分为四个步骤
- 低级模块组合成执行特定软件子功能的集群。
- 编写驱动程序来协调测试用例的输入和输出。
- 对集群或构建进行测试。
- 驱动程序被移除，并且集群在程序结构中向上移动进行组合。
随着集成层级的向上推进，对单独测试驾驶员培训的需求也随之降低。事实上，如果将项目结构的最上两层自上而下地集成，驾驶员的数量可以大幅减少，集群集成也将大大简化。集成遵循下图所示的模式。
注意： 如果将程序结构的最上两层以自上而下的方式进行集成，则可以大幅减少驱动程序的数量，并且大大简化构建的集成。
大爆炸方法
在这种方法中，除非所有模块都已准备就绪，否则不会集成所有模块。一旦模块已准备就绪，则集成所有模块，然后执行该操作以了解所有集成模块是否正常工作。
在这种方法中，由于一次性整合了所有内容，因此很难知道失败的根本原因。
此外，生产环境中出现严重错误的可能性很高。
仅当必须立即进行集成测试时才采用这种方法。
硬件软件集成测试
硬件软件集成测试 是在目标硬件环境中测试计算机软件组件 (CSC) 的高级功能的过程。硬件/软件集成测试的目标是测试集成在硬件组件上的开发软件的行为。
基于需求的硬件-软件集成测试
基于需求的硬件/软件集成测试的目的是确保目标计算机中的软件满足高级要求。此测试方法发现的典型错误包括：
- 硬件/软件接口错误
- 违反软件分区。
- 无法通过内置测试检测故障
- 对硬件故障的错误响应
- 由于排序、瞬态输入负载和输入功率瞬变导致的错误
- 反馈循环不正确的行为
- 内存管理硬件控制不正确或不当
- 数据总线争用问题
- 机制的错误操作，以验证现场可加载软件的兼容性和正确性
硬件软件集成处理高级需求的验证。此级别的所有测试均在目标硬件上进行。
- 黑盒测试是此级别测试使用的主要测试方法。
- 确定 测试用例 仅从高层要求来看
- 必须在生产标准硬件上（目标上）执行测试
设计软硬件集成测试用例时需要考虑的事项
- 软件正确获取所有数据
- 从硬件到软件，数据的扩展和范围符合预期
- 软件到硬件的数据正确输出
- 数据符合规格（正常范围）
- 数据超出规格（异常范围）
- 边界数据
- 中断处理
- 定时
- 正确的内存使用（寻址、重叠等）
- 状态转换
注意： 对于中断测试，所有中断都将从初始请求到全面服务直至完成进行独立验证。测试用例将经过专门设计，以便充分测试中断。
软件到软件集成测试
它是在主机/目标计算机环境中测试计算机软件组件，同时模拟整个系统（其他 CSC），并测试其高级功能。
它着重研究CSC在模拟主机/目标环境中的行为。软件集成方法可以是增量式方法（自顶向下、自底向上或两者结合，也称为三明治式或混合式方法）。
集成测试的进入和退出标准
一旦确定了方法和两种集成方案，剩下的问题就是团队何时可以开始，何时可以结束。通常在执行集成测试时，会采用 ETVX（准入标准、任务、验证和退出标准）策略。
入学标准：
- 的完成 单元测试
输入：
- 软件需求数据
- 软件设计文档
- 软件验证计划
- 软件集成文档
活动：
- 根据高级和低级需求创建测试用例和程序
- 结合实现通用功能的低级模块构建
- 开发测试工具
- 测试构建
- 一旦测试通过，该构建就会与其他构建结合起来并进行测试，直到系统集成为一个整体。
- 在目标处理器平台上重新执行所有测试，并获取结果
退出标准：
- 成功完成软件模块在目标硬件上的集成
- 根据指定的要求正确执行软件
输出
- 集成测试报告
- 软件测试用例和程序 [SVCP]。
系统集成测试中的常见挑战
即使采用合理的方案和明确的退出标准，集成环境也会产生一些在单元测试中从未显现的问题。及早发现这些问题可以确保项目进度安排合理。
- 环境不匹配： 综合的 测试环境 很少能反映生产情况，因此时序和配置缺陷往往要到很晚才会被发现。
- 依赖关系准备情况： 第三方和遗留接口通常未完成，迫使测试人员依赖桩和模拟器的时间远远超过计划。
- 数据不一致： 两个模块可能以不同的方式表示同一记录，从而产生无声的不匹配而不是可见的错误。
- 缺陷所有权： 当故障涉及两个团队时，需要进行根本原因分析和 缺陷管理 明显减速。
- 回归成本： 每个新界面都会扩大 回归测试 由于程序集规模庞大，手动重新执行很快就会变得不可持续。
这些风险大多属于进度风险，而非技术难题。在集成第一个版本之前，就接口就绪日期、模拟器范围和缺陷分类负责人达成一致，可以消除大部分风险。对于供应商拥有的接口，还应记录约定的消息格式和升级联系人，因为缺少负责人会导致修复时间过长，超出缺陷本身应有的修复时间。
系统集成测试最佳实践
可重复的系统集成测试 (SIT) 周期与其说依赖于工具，不如说依赖于对接口、数据和证据的严格把控。以下五项实践同样适用于小型嵌入式系统和大型多厂商环境，并且每一项都能减少后续测试阶段的返工。
- 首先绘制每个接口的映射图。 在编写任何测试用例之前，请列出每次数据交换、其方向、协议和所有者。
- 按风险优先级排序。 在检查外观装饰性接口之前，先检查承载资金、身份或受监管数据的接口。
- 设计符合实际情况的测试数据。 涵盖正常范围、边界范围和异常范围，以便及早发现缩放和舍入误差。
- 实现稳定路径的自动化。 线接口检查到 持续整合 流水线作业，确保每次构建都重新验证它们。
- 保留证据 trac能够。 将每个结果与一个要求联系起来 trac能力矩阵 因此，退出标准可以被证明，而不是被断言。
⚠提示： 在集成开始前冻结接口规范。消息格式的任何后期更改都会导致接口两端的测试用例失效，这也是系统集成测试 (SIT) 返工的最常见原因。
