中文翻译《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. 一步集成所有部件

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

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

评估员注意事项

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

此外，还指定了软件项目的集成顺序。 因此，集成策略还必须与软件需求的优先级兼容，例如，与规定在哪些版本中实现哪些需求的发布策略兼容。 集成顺序可能必须根据项目过程中的功能增加和可能的结构变化进行调整。

图 2–9 遵循自下而上策略的集成顺序

集成策略可以通过不同的方式定义。 在某些情况下，不需要采用书面形式，例如，在应用“大爆炸”方法或只有几个级别的情况下，并且由于架构的原因，哪个模块属于哪个级别是毫无疑问的 ，并且团队是否非常熟悉集成顺序。

BP2：制定软件集成测试策略。 制定测试集成软件项目的策略。 根据集成策略中定义的集成顺序确定测试步骤。

注：软件集成测试将主要关注接口、数据流、项目功能等。

注意：软件集成测试过程应从软件开发过程开始时开始。 在开发测试用例和可测试需求方面，软件需求分析 ENG.4、软件设计 ENG.5 或需求获取 ENG.1 有着密切的联系。

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

注意：所识别的项目和集成顺序将对集成测试策略产生影响。

集成测试重点关注软件项目之间的接口、之间的数据流以及（如果 ENG.6 未涵盖）交叉功能。 集成测试主要是根据软件架构的规范来执行的。 各个软件单元的功能已在单元测试期间得到验证（ENG.6）； 集成软件的功能在软件测试期间得到验证（ENG.8）。

集成自然地在每个项目中进行； 然而，有时会缺少作为单独测试级别的集成测试。 这在简单的软件架构中肯定是有意义的，其中测试级别可能已组合（关于这一点，请参阅 ENG.6 BP1），并且如果集成测试明确包含在那里。

评估员注意事项

集成测试的单独测试级别的存在不是强制性的； 然而，集成测试的实际目的（见上文）必须得到满足。 这可以通过涵盖集成测试方面的适当设计的软件测试来完成（另请参阅 ENG.6 BP1 中显示的我们的审议）

在软件开发过程的开始阶段，在需求获取（ENG.1）、软件需求分析（ENG.4）和软件设计（ENG.5）期间，应该注意集成测试策略。 这样，可以在早期阶段为集成测试定义适当的验证标准。 对单个软件项目的修改的性质会影响集成测试的性质——对于新软件项目，必须进行详尽的集成测试。 如果发生变化，只需测试回归测试策略中指定的那些部分（参见 BP8）。 可用的软件项目和集成顺序也会影响集成测试策略，因为集成顺序很大程度上反映了测试顺序。 在某些情况下，独立的软件项目可以在集成之前进行预集成和测试。 然而，自然集成测试序列与集成序列相对应。

评估员注意事项

建议在总体测试策略中协调并共同记录 ENG.6、ENG.7、ENG.8、ENG.9 和 ENG.10 中描述的测试活动的测试策略。 没有必要针对每种情况提出单独的战略文件。 然而，如果存在总体测试策略，则必须考虑相关子过程的所有方面，包括回归。

Automotive SPICE 在测试计划的背景下描述了测试策略。 测试计划（请参阅 ENG.6 中的附注“测试文档”）应包括以下项目：

1. 需要通过什么方式来完成呢？ 这包括测试活动、测试策略、测试方法、测试序列、回归测试、要测试的组件和功能、不要测试的功能以及集成到软件开发过程中的规划。
2. 项目要达到或遵守哪个质量标准（例如，测试完成标准的定义）？
3. 需要或可用多少时间和人员？
4. 有哪些可用的测试手段？
5. 有哪些风险以及哪些缓解措施？

BP3：制定软件集成测试的测试规范。 开发软件集成测试的测试规范，包括要在每个集成软件项目上执行的测试用例。 测试用例应证明符合分配给每个软件项目的软件架构设计和软件详细设计。

对于每个集成软件单元，必须指定要执行的测试和方法。这包括以测试人员确切知道如何执行测试的方式编写的测试描述，以及环境设置、操作程序、 输入数据或要使用的数据，以及预期结果或行为的描述。 在这里，可以使用和制定更详细的初步工作，例如 ENG.5 流程中的验证标准。 集成测试侧重于测试软件单元/项目的交互。 测试主要针对跨模块的功能、接口、数据流等进行，以证明已经满足设计要求。 这些测试通常在实验室环境中进行。 由于它们需要对内部软件结构有很好的了解，因此通常使用所谓的白盒测试和灰盒测试。

在大多数情况下，测试是由各个软件单元/项目的开发人员在集成后执行的。 从一定的项目规模开始，特别是如果开发分布在不同地点，我们发现“集成商”或“集成代表”的角色是一个有益的补充。 在这种情况下，集成测试组将经常需要额外的测试人员。

代码验证标准的示例有：

1. 满足软件要求
2. 遵守编码指南
3. 与软件设计的一致性
4. 外部接口的一致性
5. 软件单元/项目之间的内部一致性
6. 满足有关测试覆盖程度的标准

BP4：集成软件单元和软件项目。 根据软件集成策略，将软件单元集成为软件项，将软件项集成为集成软件。

注：软件单元集成到软件组件49，软件组件集成到集成软件。

注：软件单元和软件组件的集成也集成了它们的数据。 数据可以是校准数据和变体编码数据。

整合是根据整合策略和项目计划进行的。 相关校准数据和变量编码数据的集成在汽车设置中发挥着重要作用，因为软件的功能高度依赖于这些数据。 校准数据是在特定项目的车辆测试过程中开发或成熟的； 在某些项目中，它完全或部分由 OEM 创建。

评估员注意事项

数据/软件的集成是集成过程中不可或缺的一部分。 因此必须对其进行检查并与评级相关。

BP5：验证集成软件。 根据软件集成测试策略，对照软件集成测试的测试用例验证每个集成的软件项。

注：集成软件的验证会生成测试日志。

根据集成测试策略执行测试，并将结果记录在测试日志中。 如果完成的结果和预期（计划）的结果相同，则获得积极的测试结果。 如果与预期结果有偏差或者结果完全不同，则相关的测试用例被认为是负面的或失败的。 关于生成的测试日志（WP-ID 13-50 的一部分），请参阅附录“测试文档”，ENG.6。 良好的测试日志中至少包含以下信息：

1. 谁测试了哪个软件版本、何时以及在哪个测试环境中？
2. 哪些测试用例按什么顺序执行以及结果是什么（例如，积极、消极或意外）？
3. 如果检测到缺陷，即测试失败：创建测试事件报告，说明缺陷 ID； 该报告用于问题管理跟踪目的（参见 BP6）。

BP6：记录软件集成测试的结果。 记录软件集成测试的结果并与所有相关方进行沟通。

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

根据 BP5 中引用的测试日志，为失败的测试用例创建测试事件报告（WP-ID 13-50 的一部分）。 为整体测试创建测试摘要报告（WP-ID 13-50 的一部分）。

测试事件报告不一定基于被测系统中的缺陷。 实际结果与预期结果之间的差异可能有多种不同的原因。 期望值可能是错误的，测试用例可能被错误执行，或者需求可能被误解，因为它们留下了太多的解释空间。 测试事件报告至少包含以下信息（另见 SUP.9）：

1. 所有可用的详细信息，即基础测试日志，包括预期值和实际值
2. 缺陷ID
3. 如果可能，分析问题对其他测试用例的影响
4. 有助于进行根本原因分析的附加信息

测试日志和测试事件报告之间不存在 1:1 的关系。 阴性测试可能有多种原因并导致多份测试事件报告。 另一方面，多次检测呈阴性可能是同一个原因造成的。 在这种情况下，根据受影响的功能创建单独的测试事件报告非常重要，因为在大多数项目中，各个功能由不同的人处理。 这是能够持续跟踪和消除相关缺陷的唯一方法。 有关软件集成测试的所有相关信息都汇总在测试总结报告中。 一份好的测试总结报告至少包含以下信息：

1. 软件集成测试的日期、持续时间、范围或工作量
2. 通过和失败的测试用例的数量，包括测试期间发现的问题用例的数量和优先级
3. 计划和执行的测试数量（例如迭代次数和必要的回归测试）
4. 评估软件集成测试的执行情况以及软件的质量
5. 结果的总结和评估以及整个测试是否被视为通过

根据测试总结报告，最终决定集成软件的质量是否足以继续进行下一个流程步骤 ENG.8（软件测试）。

客户通常还需要测试结果记录，因为在缺陷跟踪期间或在联合项目会议中需要考虑这些结果。 此外，测试记录是用于进度控制的性能记录，通常在安全相关系统的开发过程中需要作为证据。 更重要的是，它们构成了即将进行的维修工作和修订的基础。

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

软件集成测试和软件设计之间的一致性主要由软件架构和测试规范或软件集成测试的测试用例之间的“水平”可追溯性（另见第 2.24 节）来保证。 这需要指定使用软件集成测试的哪些测试用例来测试哪个架构元素，反之亦然。 必须在项目的整个生命周期中保持可追溯性，特别是在变更之后。

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

回归测试是必要的，以确保先前测试已保护的属性在代码更改后仍然可用（例如，作为缺陷删除或功能增强的结果）。

回归测试策略最简单的形式包括维护一组测试用例，这些测试用例在代码更改后默认执行，此外还包括新开发的专门针对覆盖修改的测试。 大多数情况下，这样的测试用例集合非常全面，如果测试不是自动化的，那么执行起来需要花费大量的精力。 在迭代开发模式中，变更，尤其是功能增强属于正常生活； 这就是为什么需要更智能的策略，例如：

1. 根据更改/增强的位置，仅测试测试用例集合的定义子集。
2. 根据交付类型，仅测试测试用例集合的定义子集。

评估员注意事项

在评估中，对于评级目的而言，重要的是回归测试是否按照要求的程度进行，而不是底层策略的智能程度或省力程度。

通常，回归测试策略应记录在测试计划中，即使是在简单的情况下，例如重复更新的 100% 测试。

由于不同的流程（ENG.7至ENG.10）需要回归测试策略，因此为所有工程流程建立通用的回归测试策略是有意义的。 回归测试的执行和结果当然会被全面记录，即使在 Automotive SPICE 中没有明确提及。

案例研究：XY Ltd. 的软件集成

为了更好地理解这个过程的相互关系，我们以案例研究的形式描述了软件集成、集成测试和回归测试的典型流程：

XY Ltd. 奉行两层集成战略：在每个开发站点（第 1 层）和开发总部（第 2 层），集成顺序均以书面形式指定和记录。 此外，对于要在相应集成级别执行的每个测试，都有以所谓的“测试规范”形式执行的测试的描述。 它包括相应的测试方法和测试用例的集合。 测试规范有一栏用于描述测试结果，需要在测试执行期间手动填写。 随后将其扫描并存储在配置管理系统中。 此外，还会起草一份“测试总结文件”，包括对结果的定量评估（测试数量、通过/未通过测试用例的数量、简短的口头总结）； 这也记录在 CM 系统中。 设计文档按名称引用所有代码文件，代码文件引用所有设计元素。 测试规范中的另一列用于回归测试，用于指定测试用例与短测试或长测试的从属关系。 回归测试策略（适用于所有地点的中心文档）规定了每周发布的简短测试以及每月发布和客户交付的长期测试。 测试规范不断更新，以涵盖增强的或新的功能。

每个地点和总部都有一名整合经理。 对于每个站点，整合期和员工工作量都有详细计划。 测试规范的所有测试用例都必须成功通过。 不同地点的集成级测试执行日期以及交付总部的截止日期在联合 MS-Project 计划中指定，并由本地或中央集成经理监控。 此外，每天都有电话会议。 负责的是整合经理和其他员工。 所有责任都记录在 MS-Project 计划中。 外部公司在总部由专门的员工（“分包经理”）控制，他们与各自的公司保持密切联系。 他们的分包交付仅在定义的里程碑时在版本中实施。 在所有其他方面，分包经理都被视为位置集成经理。

2.9.4 指定工作产品

01-03 软件项目

软件项目由集成软件单元、配置文件、数据和相关文档组成（见图 2-2 和相关注释）。

01-50 集成软件

集成软件被理解为软件项、特定 ECU 配置的可执行文件集以及可能的相关文档和数据的集合（见图 2-2 和相关注释）。

08-50 测试规范

参见 ENG.8

08-52 测试计划

参见 ENG.8

13-22 追溯记录

参见ENG.2

13-50 测试结果

参见 ENG.8

17-02 构建清单

构建列表的主要目的是识别软件聚合和所需的系统元素（参数设置、宏库、数据库、作业控制语言、识别的输入和输出源库等）。 它还记录了软件构建所需的操作或活动的顺序。

2.9.5  2级的特点

论绩效管理

软件集成规划和跟踪是使用项目中应用的项目管理方法来完成的。 在小型项目中，至少应该进行资源和进度规划。 大型项目的另一个要求是详细规划各个集成步骤。

工作产品管理

过程属性 PA 2.2 的要求特别适用于测试计划、测试规范和测试结果。 基线是根据计划绘制的。