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