中文翻译《ASPICE in practice》之“ENG.7 软件集成测试”

2.9 ENG.7 软件集成测试

2.9.1 目的

软件集成测试过程的目的是将软件单元集成到更大的组件中，生成与软件设计一致的集成软件，并测试软件项之间的交互。

软件集成应分步进行，并伴有测试。 测试补充了前面的单元测试。 逐步集成有助于尽早识别和消除缺陷，特别是在复杂的系统中。 这样，“软件集成的进展”就得到了保证，并且在集成过程中功能的增长仍然是可控的。 关于文档，Automotive SPICE 遵循 IEEE 术语（另请参阅 ENG.6 中的附录“测试文档”。）

2.9.2 汽车行业特有的特征

在 Automotive SPICE 中，ENG.7 和 ENG.9（系统集成）中描述了集成的各个方面。 如果项目中开发了由硬件和软件项目组成的集成系统，则纯软件集成在ENG.7中描述，软件/硬件集成在ENG.9中描述。 在某些情况下，如果硬件已经作为成品（例如，作为 ECU）提供，则集成仅进行一次，并且不同的软件单元直接集成到目标硬件上。

评估员注意事项

如果 ENG.7 和 ENG.9 合并，则集成活动可以在 ENG.7 或 ENG.9 中评级。 评估两者（相同）没有任何意义。 大多数情况下，评级将以 ENG.9 进行，而 ENG.7 将被宣布不适用。 不过，应该牢记各个集成级别的不同方面。 例如，系统集成时主要考虑硬件和软件之间的接口。 在软件集成过程中分析软件项之间的接口。

许多组织都以较高的软件重用率开展工作，将项目基于现有的软件平台，然后对其进行修改或增强以满足项目要求。 与纯粹针对特定项目的开发相比，在进一步开发平台软件时，在质量保证问题方面适用了更多的注意义务。 该义务适用于 ENG.7 流程以及所有其他工程流程。 如果建模工具用于基于模型的软件设计，则可以直接在建模工具本身中执行软件集成。 在建模工具中执行的集成测试通常称为软件在环测试（SIL 测试）。

2.9.3 基本实践

BP1：制定软件集成策略。 制定与发布策略一致的软件项目集成策略以及集成顺序。

该策略指定了将软件单元集成到越来越大的集成软件项目中的逐步顺序，同时考虑到发布策略（参见 SPL.2）。 从某个聚合级别开始，集成的软件项对应于软件架构的元素。 因此，集成策略必须与软件设计和软件架构兼容或源自软件设计和软件架构。 根据产品的不同，可以采用不同的集成策略，所有策略都应考虑不同的方法来集成新的或更改的软件项目：

1. 自下而上，从硬件相关软件开始（另见图 2-9）
2. 自上而下，从用户界面开始
3. 从基本软件开始，然后集成关键模块/单元
4. 以任何顺序集成，例如根据可用性
5. 一步集成所有部件

最后一种方法也被称为（有点贬义）“大爆炸”方法。 它仅在扁平架构中才有意义，在扁平架构中，只有少数共存且功能独立的模块与软件库集成。 这种策略在大型、复杂的系统和/或不同开发团队的分布式开发中是有问题的。

相比之下，如果需要遵循“洋葱层原理”从内到外进行，则特定的集成顺序确实有意义，因为只有当下面各层的功能已经可靠运行时，才能合理地测试层中的功能。

评估员注意事项

如果使用“大爆炸”策略在项目中实施软件集成，则该项目必须毫无疑问地证明该方法的适当性。 仅凭成本或时间压力等原因并不足以证明这一点。 如果评估小组得出的结论是“大爆炸”不是适当的方法或者可能对产品质量产生负面影响，则应降低相应实践的等级，并记录该决定的原因。