系统集成测试定义为在集成的硬件和软件环境中执行的一种软件测试，验证整个系统的行为。它是在一个完整的、集成的系统上进行的测试，以评估系统是否符合其指定的要求。
系统集成测试(SIT)用于验证软件系统模块之间的交互。它涉及软件需求规范/数据和软件设计文档中规定的高级和低级软件需求的验证。
还验证软件系统与其他软件系统的共存，并测试软件应用程序的模块之间的接口。在这种类型的测试中，模块首先单独测试，然后组合成一个系统。
例如，逐步组合和测试软件和/或硬件组件，直到整个系统已经集成。
在本教程中，将了解-
- 什么是系统集成测试？
- 为什么要进行系统集成测试
- 如何进行系统集成测试
- 集成测试的进入和退出标准
- 硬件到软件集成测试
- 软件到软件集成测试
- 自上而下方法
- 自下而上方法
- 大爆炸方法
为什么要进行系统集成测试
在软件工程中，进行系统集成测试是因为，
- 有助于及早发现缺陷。
- 有关个别模块可接受性的早期反馈将可用
- 缺陷修复的调度是灵活的，并且可以与开发重叠
- 正确的数据流
- 正确的控制流
- 正确计时
- 正确的内存使用
- 更正软件要求
如何进行系统集成测试
这是一种系统化的技术，用于构建程序结构，同时进行测试以发现与接口相关的错误。
所有模块都预先集成，整个程序进行整体测试。但在这个过程中，很可能会遇到一组错误。
纠正这样的错误是困难的，因整个程序的巨大扩展而变得复杂。我们将在本教程后面的部分看到有关增量方法的更多详细信息。
有一些增量方法，比如在基于目标处理器的系统上进行集成测试。使用的方法是黑盒测试。既可以使用自下而上的集成，也可以使用自上而下的集成。
测试用例仅使用高级软件需求定义。
软件集成也可以很大程度上在主机环境中实现，特定于目标环境的单元继续在主机中模拟。再次需要在目标环境中重复测试以进行确认。
此级别的确认测试将识别特定于环境的问题，例如内存分配和释放错误。一些嵌入式系统的PRA与目标环境的耦合性会很强，使得在宿主环境中进行软件集成是不切实际的。
大型软件开发将软件集成划分为多个级别。较低级别的软件集成可以主要基于主机环境，较晚级别的软件集成变得更加依赖于目标环境。
注：如果仅测试软件，则称为软件集成测试[SSIT]，如果同时测试硬件和软件，则称为硬件软件集成测试[HSIT]。
集成测试的进入和退出标准
在执行集成测试时，通常使用ETVX(进入标准、任务、验证和退出标准)策略。
进入条件：
- 完成单元测试
输入：
- 软件需求数据
- 软件设计文档
- 软件验证计划
- 软件集成文档
内容：
- 根据高层次需求和低层次需求创建测试用例和过程
- 组合实现通用功能的低级模块构建
- 开发测试工具
- 测试构建
- 测试通过后，该版本将与其他版本组合并进行测试，直到系统作为一个整体进行集成。
- 在基于目标处理器的平台上重新执行所有测试，并获得结果
退出条件：
- 在目标硬件上成功完成软件模块的集成
- 根据规定的要求正确执行软件
产出
- 集成测试报告
- 软件测试用例和过程[SVCP]。
硬件和软件集成测试
硬件软件集成测试是在目标硬件环境上测试计算机软件组件(CSC)的高级功能的过程。硬件/软件集成测试的目标是测试集成在硬件组件上的已开发软件的行为。
基于需求的软硬件集成测试
基于需求的硬件/软件集成测试的目的是确保目标计算机上的软件满足高层次的要求。此测试方法显示的典型错误包括：
- 硬件/软件接口错误
- 违反软件分区。
- 无法通过内置测试检测故障
- 对硬件故障的响应不正确
- 由于排序、瞬时输入负载和输入功率瞬变引起的错误
- 反馈循环不正确的行为
- 内存管理硬件的控制不正确或不正确
- 数据总线争用问题
- 验证现场可加载软件兼容性和正确性的机构操作错误
硬件和软件集成处理高级需求的验证。 此级别的所有测试都在目标硬件上执行。
- 黑盒测试是此级别测试中使用的主要测试方法。
- 仅根据高级需求定义测试用例
- 测试必须在生产标准硬件上执行(在目标上)
设计硬件/软件集成测试用例时需要考虑的事项
- 软件对所有数据的正确采集
- 按照预期将数据从硬件扩展到软件和范围
- 正确地将数据从软件输出到硬件
- 规格范围内的数据(正常范围)
- 数据超出规范(异常范围)
- 边界数据
- 中断处理
- 计时
- 正确使用内存(寻址、重叠等)
- 状态转换
注意：对于中断测试，所有中断将独立于初始求进行验证，直到完全服务完成。将专门设计测试用例，以便充分测试中断。
软件集成测试
它是对在主机/目标计算机内运行的计算机软件组件的测试环境，同时模拟整个系统[其他CSC]，以及高级功能。
本课程重点介绍CSC在模拟主机/目标环境中的行为。用于软件集成的方法可以是增量方法(自上而下、自下而上或两者的组合)。
增量式方法
增量测试是集成测试的一种方式。在这种类型的测试方法中，首先单独测试软件的每个模块，然后通过向其添加其他模块，然后再添加另一个模块来继续测试，依此类推。
增量集成与大爆炸方法形成了鲜明对比。程序被构造和测试I接口更有可能被完全测试，并且可以应用系统测试方法。
有两种类型的增量测试
- 自上而下方法
- 自下而上方法
自上而下方法
在这种类型的方法中，个体从只测试用户界面开始，使用存根模拟底层功能，然后向下集成更低层，如下图所示。
- 从主控模块开始，通过在控件层次结构中向下移动来集成模块
- 主控模块的子模块以广度优先或深度优先的方式并入结构中。
- 深度优先集成集成结构的主控制路径上的所有模块，如下图所示：
模块集成过程通过以下方式完成：
- 以主控模块作为测试驱动器，用代替主控模块直接从属的所有模块。
- 根据所选方法(广度优先或深度优先)，用实际模块一次替换一个从属。
- 测试在每个模块集成时执行。
- 完成每组测试后，另一个存根将在完成每组测试时替换为实际模块
- 为了确保没有引入新的错误，可以执行回归测试。
该过程从步骤2继续，直到构建整个程序结构。自上而下的策略听起来相对简单，但实际上，新问题会出现。
当需要在层次结构中的低级别进行处理以充分测试较高级别时，会出现这些问题中最常见的问题。
自上而下测试开始时替换低级模块，因此在程序结构中没有重要的数据可以向上流动。
测试人员可能面临的挑战：
- 延迟许多测试，直到实际模块替换。
- 开发执行模拟实际模块的有限功能。
- 从层次结构的底部向上集成软件。
注意：第一种方法会导致我们失去对特定测试和特定模块合并之间的对应关系的某些控制。可能导致难以确定错误，往往会违反自顶向下方法的高度约束性质。
第二种方法是可行的，但随着存根变得越来越复杂，可能会导致显著的开销。
自下而上方法
自下而上的集成从程序结构中最低级别的模块开始构建和测试。在此过程中，模块自下而上集成。
在这种方法中，从属于给定级别的模块所需的处理始终可用。 此集成测试过程分四个步骤执行
- 低级模块被组合成执行特定软件子功能的集群。
- 编写驱动程序来协调测试用例的输入和输出。
- 测试群集或内部版本。
- 驱动程序被移除，并且群集被组合在程序结构中向上移动。
随着集成度的提高，需要单独的测试驱动程序测试。事实上，如果程序结构的前两级是自上而下集成的，那么随着集成的向上推进，驱动程序的数量可以减少，因此需要单独的测试驱动程序测试。
注：如果程序结构的前两级自顶向下集成，可以大幅减少驱动程序的数量，大大简化Build的集成。
大爆炸方法
在此方法中，直到且除非所有模块都准备就绪，否则不会集成所有模块。一旦准备好了，所有的模块都被集成，然后执行，以了解所有集成的模块是否都在工作。
在这种方法中，很难知道失败的根本原因，因为一次集成所有东西。 此外，生产环境中出现关键错误的可能性也很高。 只有在必须立即进行集成测试时，才会采用此方法。
总结：
- 执行集成以验证软件系统的模块之间的交互，有助于及早发现缺陷。
- 集成测试可以针对硬件-软件或硬件-硬件集成进行
-
集成测试通过两种方法进行
- 增量式方法
- 大爆炸方法
- 通常在执行集成测试时，使用ETVX(进入标准、任务、验证和退出标准)策略。
