中文翻译《ASPICE in practice》之“ENG.6 软件构建”

2.8 ENG.6 软件构建

2.8.1 目的

软件构建过程的目的是生成经过验证的软件单元，以正确反映软件设计。

基于在 ENG.5 中创建的软件设计，现在正在开发软件。实际上，编码过程在几个连续的编码、缺陷检测和缺陷纠正周期中迭代进行，并与其他开发活动（如软件设计或单元测试）紧密相关。

2.8.2 汽车行业特有的特征

在汽车行业，编码过程中会非常重视所用硬件的要求。特别是在操作系统或设备驱动程序等硬件相关层中，生成的代码通常只能用于一个微控制器，或者最多只能用于一个控制器系列。这同样适用于并非普遍适用的代码生成工具（例如编译器）。对于非硬件相关层，常见的编程语言是 C、汇编语言或 C++。如果软件建模、仿真和设计描述由工具支持，则通常会在后续工作步骤中触发自动代码生成。但是，自动生成的代码通常只能部分满足项目的要求。执行时间通常不是最理想的，自动代码内存容量要求经常超过可用内存容量。在大多数情况下，内存成本相当高。因此，在实践中，我们经常看到进一步的优化工作以减少内存需求。各个企业在代码生成的方式和方法上存在很大差异。一方面，它们可能包括完整的工具链，包括从需求定义到软件测试和支持活动（例如配置管理）的整个软件开发过程。另一方面，它们可能包括完全异构的结构，工具链中存在相当大的差距，并且一些工具是内部开发的。

评估员须知

原则上，工具在 1 级和 2 级评估中与评级无关（例如，它们有多好），因为 Automotive SPICE 在这方面没有任何要求（3 级有关于充分基础设施的明确要求）。但是，它们的应用是否会对基本实践的绩效产生不利影响这一问题对于评级目的确实非常重要。为此，可以检查工具是否得到适当部署和管理（例如，CM 工具的访问权限），是否定义了项目中工具应用的进入和退出条件，即从“手动活动”到工具应用的过渡，反之亦然，以及是否遵循了相关规范。

2.8.3 基本实践

BP1：定义单元验证策略。制定验证和重新验证软件单元的策略。该策略应定义如何使用可用的技术实现所需的质量。

注意：可能的技术包括静态/动态分析、代码检查/审查、白盒/黑盒测试、代码覆盖率等。

这里讨论的验证策略是 ENG.6 至 ENG.10 流程的总体验证策略的一部分，其中每个流程都需要类似的策略。该总体验证策略（另请参阅 SUP.2 BP1 和工作产品 19-10 »验证策略«）旨在实现不同开发阶段（编码、集成、软件测试等）中不同方法（审查、测试……）和验证活动的协调与配合。需要进行协调的原因是不同的验证方法同时重叠并相互补充。例如，在单元测试中可以发现在代码审查中未发现的缺陷，反之亦然。除此之外，这两种方法之间还有重叠部分。不同测试级别的协调也存在类似情况。例如，单元测试、集成测试和软件测试之间的传统区别基于以下概念：单元测试旨在确保各个单元的功能（以软件设计为衡量标准）；集成测试旨在测试接口和交互（以软件架构为衡量标准）；软件测试验证整体功能（以软件要求为衡量标准）。在汽车行业，这种传统的工作分工在较小的系统中通常不那么严格，因为较小的系统通常会将测试组合起来进行联合测试，因为这样可以节省精力并且更可行。从 Automotive SPICE 的角度来看，只要满足相关流程的目的，这种分工就完全合理。

评估员须知

无需单独 1:1 地实施每个 Automotive SPICE 流程。组织需要以适合其自身特定情况的方式设计其流程。评估团队的任务是建立组织流程与 Automotive SPICE 设定的要求之间的对应关系，并评估后者的履行情况。因此，在组合测试级别时，仍必须考虑与不同测试级别相关的特定特性。如果组织未能做到这一点，无论其规模如何，都会被降级。

重新验证是另一个需要完善概念的问题。术语“重新验证”表示在修改软件单元后重新进行验证。在 ENG.7 至 ENG.10 流程中，明确要求采用“回归测试策略”（另请参阅我们在 ENG.7 BP8 中所示的审议）。然而，在 ENG.6 中，我们发现除了回归测试之外还有其他可能的重新验证方法，因此需要就以下问题达成一致：哪种验证方法用于哪种类型的更改？

验证始终根据通常来自上一个开发阶段的规范进行。在流程目的中，Automotive SPICE 需要根据设计进行验证。对于代码，适用其他标准实践，特别是关于文档和编码指南（例如 MISRA 规则）。进一步的规范来自 BP1 中提到的策略。

此外，BP1 讨论了“期望质量”。这里要做的可能是就交付给客户的不同类型产品的不同质量水平达成一致。例如，一些 OEM 要求在很短的时间间隔内交付软件版本（在极端情况下以每周为增量）。显然，这些增量不可能与接近生产的后续版本具有相同的质量。其他可能的质量要求（不一定在单个软件单元的级别）包括：

1. 按照 [IEEE 1012] 的软件完整性级别，可以规范系统某个部分对于整个系统的关键性；这些级别可以为验证活动的工作量优化做出重要贡献，因为关键的系统组件比不太重要的系统组件得到更深入的验证。
2. 符合[IEC 61508]的安全完整性等级，这也影响验证方法和验证强度

BP1 规定了以下可能的验证方法：

1. 静态分析（另见词汇表）：在静态代码分析过程中，借助工具检查代码的一致性和是否符合规则和惯例。在评估中，OEM 通常会查看测试记录，以查看是否遵守了之前提到的 MISRA 规则。
2. 动态分析（另见词汇表）：这些包括执行代码的所有验证方法，特别是不同类型的测试。单元测试通常以白盒测试的形式执行。除了验证功能之外，这些测试还应该尽可能地考虑时间行为、通信和非功能性要求的满足（另见 ENG.8 中的“测试方法”一文）。
3. 代码检查和代码审查（另见词汇表）：这些验证技术有多种不同的变体。在这里，通常由一位或几位领域专家预先分析代码，然后在审查会议上讨论结果。要检查的典型问题是程序逻辑和对编码指南的遵守情况。通常会使用包含关键问题的清单，这些清单源自早期项目中发现的主要问题。
4. 白盒测试和黑盒测试（另见词汇表）：请参阅 ENG.8 中的“测试方法”附记。
5. 代码覆盖率分析（见词汇表）

BP2：制定单元验证标准。制定并记录验证策略中每个软件单元是否满足其设计、功能和非功能要求的标准。

注意：验证标准应包括单元测试用例、单元测试数据、编码标准和覆盖率目标。

注意：编码标准应包括 MISRA 规则的使用和定义的编码指南。

验证标准指定软件单元需要满足哪些条件才能被视为已成功验证。软件单元的验证标准比 BP5-7 中引用的验证标准更全面，因为后者每个仅与一个要求相关（有关更多详细信息，请参阅第 2.24 节，附录“验证标准”）。BP2 在其注释中指定了一些典型的验证标准：

1. 要成功执行的单元测试用例；关于这一点，请参阅本节末尾附录“测试文档”中“测试用例”的定义。
2. 单元测试数据：这些是指测试对象的输入值和预期结果及其相互关系（例如时间），以及执行相应测试用例后的目标值，包括容差、响应时间等。这些数据是测试用例描述的一部分（见上文）。
3. 编码规则和指南：MISRA 规则已在 BP1 中得到解决。编码指南通常定义有关文件命名约定、文件组织、注释、布局、命名约定、声明的规则。

BP3：开发软件单元。开发并记录每个软件单元的可执行表示。

注意：在开发软件单元时，可以使用代码生成工具来减少手动编码工作量。

对软件单元进行编码，检测并删除缺陷，直到开发人员认为代码满足所需的性能特征为止。如果功能范围在几个迭代步骤中扩展，则编码、缺陷检测和缺陷删除的循环也会执行多次。

在编程过程中遵守编码指南或其他非功能性要求等规定非常重要。以后的可读性和可理解性，以及代码的可重用性，都取决于对这些规定的遵守。稳定性、可测试性、可更改性和可维护性也是如此。

至少，文档是在代码本身中完成的（注释、解释、更改历史记录），如果需要，也可以在其他文档中完成（例如，“发行说明”）。更一般地说，设计文档和用户文档（安装、操作和维护文档）也可以被视为属于这一组。

评估员须知

代码质量的关键在于前几个开发阶段的工作成果（即需求和设计文档）的质量和可理解性。如果开发人员已经参与了需求和设计阶段，那么这将大有裨益。否则，必须以不同的方式确保信息流或技术诀窍的转移。应检查这一点。此外，还应检查开发组织是否已为可行且高效的代码生成创建了适当的技术前提条件（基础设施、工具使用等）。

BP4：验证软件单元。根据验证策略，根据详细设计验证软件单元。

根据验证策略检查创建的代码，并删除检测到的缺陷。验证的目标是通过合理的努力证明软件符合其规范，并且与软件单元正确功能相关的风险保持在合理范围内。

评估员注意

如果单元测试的目的可以通过组合测试级别实现，则单元测试的单独测试级别不是强制性的；另请参阅 BP1。

BP5：记录单元验证的结果。记录单元验证的结果并传达给所有相关方。

作为文档，我们至少需要一份测试日志以及测试事件报告（请参阅本节末尾的附录“测试文档”）。结果通常在团队内部传达，例如，传达给负责消除缺陷的个人、负责集成的人员和（子）项目经理。

BP6：确保软件详细设计与软件单元的一致性和双边可追溯性。确保包括验证准则在内的软件详细设计与包括验证准则在内的软件单元的一致性。通过建立和维护包括验证准则在内的软件详细设计与包括验证准则在内的软件单元之间的双边可追溯性来支持一致性。

必须确保每个开发的软件单元与软件设计的一致性。一致性检查必须确保：

1. 没有未在软件设计中描述的软件单元；反之亦然，每个设计元素都存在一个相关的软件单元。
2. 每个软件单元都反映了设计规范。
3. 软件设计的验证标准准确反映在单元测试用例中。

代码审查和单元测试用例审查是一致性检查的合适方法。建立垂直、双向可追溯性使一致性检查成为可能，因为对特定软件单元有效的设计规范是完全已知的。当然，在开发过程中也必须相应地维护可追溯性（有关可追溯性，另请参阅第 2.24 节）。

BP7：确保软件需求与软件单元的一致性和双边可追溯性。确保软件需求（包括验证标准）与软件单元（包括验证标准）的一致性。通过建立和维护软件需求（包括验证标准）与软件单元（包括验证标准）之间的双边可追溯性来支持一致性。

注：仅当软件详细设计中无法解决的需求（例如非功能性需求、属性等）时，才需要在软件需求和软件单元之间建立一致性和双边可追溯性。

仅当 BP6 尚未涵盖一致性和可追溯性要求，或软件详细设计中未反映需求（参见注释）时，BP7 才有意义。在这种情况下，必须确定每个完成的软件单元与软件需求的一致性。一致性检查必须确保以下内容：

1. 单元测试测试用例已考虑了与特定软件单元相关的所有相关要求，并且
2. 对于每项要求，在测试用例设计期间已考虑了相关的验证标准（参见 ENG.4 BP2）。

一致性检查的适当方法是审查单元测试用例。建立双向可追溯性有助于一致性检查，因为与特定软件单元相关的需求是完全已知的。可追溯性（在这种情况下是垂直可追溯性）的存在具有其他优势：

1. 在编码期间，可以查阅需求和相关验证标准以获取背景信息，或者不会遗漏任何需求。
2. 在创建单元测试用例期间，可以使用验证标准。
3. 检查单元测试是否涵盖所有需求变得更加容易。
4. 在需求发生变化时，更容易识别受影响的软件单元。

当然，必须在所有开发阶段保持可追溯性（有关可追溯性的更多详细信息，另请参阅第 2.24 节）。

BP8：确保软件单元与软件单元测试规范之间的一致性和双边可追溯性。确保软件单元（包括验证标准）与软件单元测试规范（包括软件单元测试用例）之间的一致性。通过建立和维护软件单元（包括验证标准）与软件单元测试规范（包括软件单元测试用例）之间的双边可追溯性来支持一致性。

通常，软件单元会进行一系列测试。这一基本实践旨在确保软件单元的验证标准与其测试规范一致。术语“测试规范”（参见工作产品 08-50）表示一系列内容，简而言之，包括如何测试软件单元、如何执行测试用例以及包括回归测试用例在内的单个测试用例的概念。

建立水平、双向可追溯性使一致性检查成为可能，因为与特定软件单元相关的相关测试和测试用例是完全已知的。如果软件单元包含多个功能，则可追溯性将变成两层（软件单元-功能-测试用例）。当然，在整个开发阶段都必须相应地保持可追溯性（有关可追溯性，请参阅第 2.24 节）。

一致性检查的另一个重要手段是代码覆盖率分析（参见词汇表），它检查是否已达到测试覆盖率目标。

2.8.4 指定工作产品

08-50 测试规范

参见 ENG.8

08-52 测试计划

参见 ENG.8

11-05 软件单元

软件单元是一段代码，其中包含用于执行或多或少独立任务的操作和数据。软件单元取决于软件设计、编程语言和应用程序。与外界的通信只能通过定义和明确指定的接口进行。在 Automotive SPICE 中，软件单元是最小的软件构建块。

13-22 可追溯性记录

参见 ENG.2

13-50 测试结果

参见 ENG.8

2.8.5  2 级特性

关于绩效管理

单个软件单元是根据软件设计开发的。这种开发通常由许多小的、迭代的工作步骤组成，因此详细的流程规划意义不大。这就是为什么通常只为每个单个软件单元规划开始和完成的原因。如果开发人员必须创建几个较小的软件单元（例如，每个单元只需几天时间），那么更精简的规划就足够了。绩效管理的另一部分是规划和跟踪所使用的资源和时间表。

关于工作产品管理

过程属性 PA 2.2 的要求特别适用于过程的主要工作产品：代码。其验证已通过基本实践进行。定义的开发过程和文档模板可以涵盖对进一步工作产品（例如验证程序、测试用例和测试结果）的要求。它们可以在评审中进行检查。工作产品（特别是代码和相关文档）受到配置控制。对于每个基线，所有相关工作产品均已指定。

附记：根据 IEEE 标准 829-1998 编写的测试文档（软件测试文档）

IEEE 标准 829 已成为行业标准，其中使用的术语在行业中很常用。Automotive SPICE 也对一些工作产品使用了 IEEE 定义。以下列表简要概述了 IEEE 829 标准中使用的术语；括号中的引用是 WP-ID。

1. 测试计划（测试计划，WP-ID 08-52）：所有测试活动的规划。除其他事项外，测试计划还确定了要测试的组件和功能、不需要测试的功能、方法、通过或失败标准、产品、测试活动、测试环境、职责、人员和时间表。
2. 测试设计规范（测试设计规范，WP-ID 08-50）：关于如何测试组件的概念。测试规范包括要测试的功能、特定测试技术、通过或失败标准以及相关测试用例列表等。
3. 测试程序规范（测试程序规范，WP ID-08-50）：执行测试所需步骤的规范。除其他外，测试程序规范包括目的和所有相关测试用例的列表、先决条件和准备步骤，以及执行程序和记录结果的指南。
4. 测试用例规范（测试用例规范，WP-ID 08-50）：如何测试特定测试对象（例如，功能）的描述。除其他外，测试用例包括测试项目、输入规范、输出规范和环境需求。
5. 测试项目交付报告：交付软件的描述（例如，交付给测试团队或客户）。它包括交付的确切内容，包括各个项目的版本、相关文档、每个项目的负责人、软件的交付方法、与上次交付相比的更改、已知缺陷和批准。
6. 测试日志（测试日志，WP-ID 13-50 的一部分）：包括测试项目和版本列表、测试环境、测试用例列表（测试人员、日期、结果、可能的意外事件）。
7. 测试事件报告（测试事件报告，WP-ID 13-50 的一部分）：测试期间检测到的问题的描述；测试事件报告包含与测试日志相同的数据，但更详细，以支持根本原因分析。它会进一步处理，应用问题解决管理流程（SUP.9）。
8. 测试摘要报告（测试摘要报告，WP-ID 13-50 的一部分）：为项目人员和管理层提供测试结果的概述；包括但不限于测试项目的识别及其测试方式、结果摘要及其评估（通过/未通过、失败风险等）。