中文翻译《ASPICE in practice》之“ENG.9 系统集成测试”

2.11 ENG.9 系统集成测试

2.11.1 目的

系统集成测试过程的目的是集成系统元素以产生一个集成系统，该系统将满足系统架构设计和系统需求中表达的客户期望。

在开发的这一点上，系统元素，即软件、硬件和机械，被集成以提供系统所需的功能。 现在很明显这些组件是否匹配。 除了一些特殊的特征外，系统集成测试过程 ENG.9 在方法论上与软件集成测试过程 ENG.7（软件集成测试） 相同，但它涉及不同的对象。 以下讨论主要集中在与 ENG.7 的差异上。

2.11.2 汽车行业特有的特征

在最简单的情况下（一个软件、一个硬件、一个机械），硬件、软件和机械集成到一个系统中是通过机械集成和软件刷新，然后进行测试一步完成的。 对于复杂的产品（多处理器架构、多个硬件和机械组件、多个软件组件），这种集成通常分几个步骤完成。

术语“系统”的定义和概念划分相当困难（另请参见第 2.4.2 节），因为它在很大程度上取决于应用过程的领域。 在顶层 (OEM)，系统构成了车辆加上一些额外的外部系统（例如，远程信息处理）。 对于单个车辆组件，例如带有外围设备的 ECU，术语“系统”包括该组件的各个元素及其与其他车辆组件的接口。 就 ECU 的机械结构而言，其接口包括固定装置和安装空间。 关于硬件，接口包括电缆和连接器，而软件接口包括通信协议。 在实践中，有两个因素尤其成问题：

1. OEM/供应商或一级/二级供应商之间未准确定义或约定集成责任。
2. 由于同步开发，第三方组件的完成版本通常无法集成，因为它们也仍在开发中。 此外，在测试车辆中，我们发现在大多数情况下，相关方（OEM、供应商）的配置因硬件和软件版本的不同而有所不同。 结果是失败发生在甲方而不是乙方，反之亦然。

在迭代开发中，实现的功能数量随着每次交付而增加。 但是，交货日期之间可能会经过数周或数月。 项目必须支持这种实践模式，例如，通过适当的硬件、机械和软件发布计划。 这是为了确保根据协议交付功能性临时版本，并且客户可以进行自己的样品测试。 因此，该项目可以显着提高完全开发的整个系统的质量和可用性（另请参阅我们在 ENG.7 和 ENG.8 流程中第 2.9.2 和 2.10.2 节“汽车行业的特殊特性”中的审议）。

2.11.3 基本实践

BP1：制定系统集成战略。制定与发布策略一致的硬件项和集成软件的集成策略以及集成它们的顺序。

ENG.7 BP1 中显示的我们的审议同样适用于此基本实践。 现在要集成或测试的对象是软件和硬件元素及其不同的集成级别。 在最简单的情况下，软件和硬件同时开发并随后集成。 在复杂的情况下，完整的系统由多个机电和电子元件（后者带有软件项）的集合组成，因此会发生多个独立的硬件集成以及硬件和软件集成。 如果系统元素来自不同的开发伙伴，则必须对这些策略提出特殊要求。 ENG.7 和 ENG.9 中的相应要求当然可以在联合集成策略中实现。

BP2：制定系统集成测试策略。根据集成策略中定义的集成顺序确定测试步骤。

注意：集成测试将主要关注接口、数据流、系统元素的功能等。

注意：系统集成测试过程应该从系统开发过程开始。 系统需求分析 ENG.2、系统架构设计 ENG.3 或需求获取 ENG.1 在开发测试用例和可测试需求方面有密切联系。

注：系统集成策略包含根据更改（例如，更改的硬件项目、新的集成软件）集成系统元素的不同方法。 集成策略还包括最适合用于每种集成方法的测试方法。

注：确定的系统元素和集成顺序将对系统集成测试策略产生影响。

ENG.7 BP2 中显示的审议也适用于此基本实践。 现在被测元素是硬件单元和集成软件，而不仅仅是集成软件项。 同样，系统集成测试策略应该在系统需求分析/架构设计期间就已经开始。在这里，测试策略也被记录为测试计划的一部分——一个涵盖所有测试的整体策略是可取的。

BP3：制定系统集成的测试规范。开发要在每个集成系统元素上执行的测试规范系统集成，包括测试用例。 测试用例应证明符合系统架构设计。

我们对 ENG.7 BP3 中所示软件的考虑在这里也有效。 还应指定哪些其他系统元素必须在硬件和/或软件中可用才能测试特定系统元素。

BP4：集成系统元素。根据系统集成策略将系统元素集成为一个集成系统。

注：系统集成可以逐步将硬件元素集成为原型硬件、外围设备（传感器和执行器）和集成软件，以生成符合系统要求的优先级和分类的系统。

根据系统集成策略、项目计划和发布计划（参见 SPL.2），在系统级逐步执行集成。

BP5：验证集成系统。根据系统集成测试策略，针对系统集成测试用例验证每个集成系统元素。 证明存在并构建了一套完整的可用可交付系统元素。

注：集成系统的验证会生成测试日志。

注：集成系统的验证可以使用环境模拟方法（例如，硬件在环模拟、车辆网络模拟）来执行。

根据集成和回归测试策略执行测试，并记录结果（另请参见 ENG.7 BP5）。 汽车行业用于系统集成测试的标准做法是部署模拟，例如在一个或多个硬件在环测试台 (HIL) 上部分组装车辆组件，或软件模拟不可用组件的剩余总线模拟。 除此之外，还可以在测试车辆中进行系统集成测试，例如，侧重于接口。

BP6：记录系统集成测试的结果。记录系统集成测试的结果并与所有相关方沟通。

注意：测试事件报告和测试总结报告基于测试日志。

我们在 ENG.7 BP6 中的考虑也适用于此。

评估员须知

当然，必须向其传达结果的相关方不同于软件集成测试中涉及的相关方 (ENG.7)。 必须牢记这一点，尤其是当 ENG.7 和 ENG.9 结合使用时。

BP7：确保系统架构设计与系统集成测试规范的一致性和双向可追溯性。确保系统架构设计与系统集成测试规范（包括测试用例）的一致性。 通过在系统架构设计和系统集成测试规范系统（包括测试用例）之间建立和维护双边可追溯性来支持一致性。

系统集成测试与系统架构的一致性，如 ENG.7 BP7 中所示，主要通过系统架构元素和系统集成测试规范元素之间的“水平”可追溯性（另见第 2.24 节）得到保证。 这意味着需要关于哪些系统架构元素（包括验证标准）将使用系统集成测试的哪些测试用例元素进行测试的规范，反之亦然。 在这里，也必须在项目的整个生命周期中保持可追溯性——尤其是在进行更改之后。

BP8：制定回归测试策略并执行回归测试。如果更改了硬件项目或集成了集成软件，则制定重新测试系统元素的策略。 按照回归测试策略中的定义执行回归测试并记录结果。

在对系统元素进行更改后（例如，在删除缺陷或功能增强后），回归测试可确保已通过先前测试验证的属性仍然存在（有关详细信息，请参见 ENG.7 BP8）。

2.11.4 指定工作产品

08-50 测试规范；

参见 ENG.8 

11-06系统

这里术语系统被理解为定义完全配置和集成的产品元素集（见图 2-2 和相关注释），例如，所需的硬件、机械、软件和数据，包括文档。

13-22追溯记录

参见 ENG.2

13-50 测试结果

参见 ENG.8

2.11.5  2级特性

论绩效管理

系统集成是一项跨学科活动，通常由整个项目中不同的、相互作用的团队/子项目（例如，软件开发、电子产品开发、印刷电路板布局、机械构造）执行。 子项目通常遵循自己的子项目计划，这些计划在整个项目级别进行协调和商定。 根据我们的经验，这是有问题的，需要特别努力，尤其是当子项目分布在不同的开发站点时。 项目跟踪因此变得复杂。 在实践中，来自所有学科的代表或子项目经理合作并定期会面的项目管理团队已被证明是成功的（关于工作产品的管理，另请参见 ENG.7 中的相应讨论）。