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

2.10 ENG.8 软件测试

2.10.1 目的

软件测试过程的目的是确认集成软件满足定义的软件要求。

测试确保集成软件符合 ENG.4 中确定的软件要求。这指的是集成（ENG.7）完成后的集成软件产品。很可能有多个并行软件产品在不同的处理器上运行，并且在后期系统集成（ENG.9）期间，这些软件产品与其他系统组件（即包括硬件、机械）集成在一起。

2.10.2 汽车行业特有的特征

汽车行业通常开发由硬件、软件和机械组件组成的集成系统。在评估中，会出现一个问题，即如何将项目中执行的不同测试与相应的流程（ENG.7、ENG.8、ENG.9、ENG.10）联系起来。如果有明确的软件需求和明确关联的测试，这很容易做到。事实上，情况往往有所不同：需求描述通过硬件和软件交互实现的功能，然后在集成后进行测试。

评估员注意事项

评估实践中，常见的测试分配如下：

1. ENG.7：软件集成期间的测试
2. ENG.8：在与硬件集成之前对成品软件产品进行的测试，其中目标硬件由软件和/或硬件实验室设置模拟。实验室设置也可能包括成品 ECU。
3. ENG.9：软件和硬件组件系统集成期间的测试
4. ENG.10：在目标硬件上对集成系统进行的测试

我们经常遇到以下情况：目标硬件已经可用，所有测试都直接在目标硬件上执行。在这种情况下，ENG.7/ENG.8 和 ENG.9/ENG.10 大多是多余的。评估通常会放弃双重评估，只评估 ENG.9/ENG.10 中的集成和测试，声明 ENG.7/ENG.8“不适用”。应注意各个集成级别的不同方面：基于 ENG.4/ENG.5 的测试用例必须在 ENG.9/ENG.10 中执行，即现在必须在系统级别证明符合软件要求和软件架构。如果不这样做，在评估 ENG.9/ENG.10 时将产生负面影响。

如果交付的原型（例如早期样品）不包含完整功能，则软件测试必须确保交付的（部分）功能能够按照要求运行。汽车软件开发的一个特殊特征是，硬件相关性和实时行为（另请参阅 ENG.5，第 2.7.2 节“汽车行业特有的特征”）对测试类型和测试环境（通常是目标硬件和目标环境）有很大影响。

2.10.3 基础实践

BP1：制定软件测试策略。制定与发布策略一致的软件测试策略。

在测试整个软件之前，必须先在测试计划中记录适用于软件测试的目标和一般参数（参见 ENG.6 中的附录“测试文档”）。发布策略定义了哪些功能将在何时可用，因此，在何时可以且必须执行哪些测试。

BP2：制定软件测试的测试规范。制定软件测试的测试规范，包括将在集成软件上执行的测试用例。测试用例应证明符合软件要求。

注意：软件测试过程应在软件开发生命周期的早期开始。在开发测试用例和可测试需求方面，与软件需求分析 ENG.4、软件设计 ENG.5 和需求引出 ENG.1 密切相关。

必须指定要执行的测试。这与测试设计规范、测试程序规范和测试用例规范（测试规范的元素，WP-ID 08-50）文档的信息内容相对应。在规范期间，可以补充 BP1 中的部分测试计划。总的来说，需要以下内容：

1. 如何进行测试？（方法、测试组、测试执行指南、测试顺序、测试结束标准等）
2. 测试使用哪些环境/条件、操作和输入数据？
3. 不同的测试验证了哪些要求？
4. 集成软件产品需要哪些行为（例如，以输出数据的形式）才能宣布测试成功？

总而言之，测试作为一个整体必须适合证明所有软件要求都已实现。从方法论的角度来看，这里可以使用白盒测试和黑盒测试。在实践中，大多数情况下都执行功能测试，即黑盒测试。软件测试流程和测试策略的准备应在开发过程开始时就已开始，并随着需求分析的深入而进一步完善。这样，可以在开发的早期阶段为软件测试定义适当的验证标准。

BP3：验证集成软件。根据软件测试的测试用例和软件测试策略验证集成软件。

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

注意：考虑到效率，测试应尽可能自动化。

执行计划的测试并创建测试日志。另请参阅我们针对 ENG.7 BP5 给出的与测试结果文档相关的详细说明，以及 ENG.6 中的附录“测试文档”。

BP4：记录软件测试结果。记录软件测试结果并传达给所有相关方。

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

软件测试结果记录在测试日志和测试事件报告中，然后纳入测试总结报告中（符合 ENG.7 BP6）。根据测试总结报告，可以决定软件质量是否足以继续进行系统集成（ENG.9）流程步骤。在修复错误期间，可能会发现底层软件测试规范（BP2）以及需求规范也需要修订。

BP5：确保软件需求与软件测试规范的一致性和双向可追溯性。确保软件需求与软件测试规范（包括测试用例）的一致性。通过在软件需求和软件测试规范（包括测试用例）之间建立和维护双向可追溯性来支持一致性。

注意：一致性可以通过审查记录来证明。

通过“水平”可追溯性（另见第 2.24 节）来确保软件需求与软件测试规范之间的一致性，这意味着必须为每个软件需求指定一个涵盖该特定需求的相应软件测试。同样，对于每个软件测试用例规范，必须明确要测试哪些需求。可以通过审查和相应的审查记录来证明这种覆盖范围。在这里，同样，必须在整个项目生命周期中保留可追溯性——尤其是在进行了更改的情况下。

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

此实践要求根据对软件项目所做的更改对完整的集成软件进行回归测试。有关回归测试的主要主题，请参阅 ENG.7 BP8。

附记：测试方法的简要概述

1. 静态分析：借助开发工具套件或其他专用工具对代码进行分析，例如，检测“死”代码段、无限循环、未初始化变量、违反编码约定等。这种分析称为“静态”，因为在分析期间不会执行代码。
2. 动态方法：在动态测试中，代码在测试环境中执行。

测试类型有以下区别：

1. 白盒测试（也称为“基于结构的测试”）基于程序代码、设计、接口描述等，源自对软件内部结构的知识。在大多数情况下，它们由软件开发人员自己执行，因为他们非常了解软件组件的内部结构。一个风险是软件开发人员的“组织盲目性”。
2. 黑盒测试（也称为“功能测试”）将外部软件接口的外部可观察行为（不了解结构）与所需行为进行比较。黑盒测试也可以由单独的测试团队或外部测试人员执行。一个优点是可以观察到“四眼原则”。
3. 灰盒测试（黑盒/白盒测试的组合）通常由软件开发人员提供。与黑盒测试一样，它们针对软件的外部可观察行为。了解软件单元的内部结构有助于设计这些测试。

附记：测试用例的一些推导方法

1. 基于处理逻辑：处理逻辑是指操作和决策（所谓的路径）的后果，从而根据条件做出决策。可以区分不同的测试覆盖等级：

1. 语句覆盖（C0 度量）：每个操作（= 语句）至少执行一次。
2. 分支覆盖（C1 度量）：每个操作至少执行一次，每个可能的决策至少引发一次。
3. 条件覆盖：每个操作至少执行一次，每个条件的可能结果至少引发一次。

1. 等价类：将输入值区分为各个类，其中每个值检测缺陷的可能性相同。
2. 边界值分析：从经验上讲，错误更有可能发生在边界处。例如，可以通过直接在极限之上、之上或之下的值进行测试。

2.10.4 指定工作产品

测试相关工作产品摘要

为清楚起见，我们在此总结与测试相关的工作产品。Automotive SPICE 中的测试流程有三个核心工作产品：测试规范、测试计划和测试结果。这些工作成果大部分可归因于 IEEE 定义的术语（请参阅 ENG.6 中的附录“测试文档”）：

08-50 测试规范

Automotive SPICE 测试规范包括以下内容：

1. IEEE 测试设计规范
2. IEEE 测试程序规范
3. IEEE 测试用例规范
4. 根据 IEEE 标记回归测试用例

此外,对于集成测试：

1. 识别要集成的系统元素
2. 集成顺序

08-52 测试计划

Automotive SPICE 测试计划包含以下组件：

1. IEEE 测试计划
2. 测试策略，例如黑盒/白盒测试、等价类测试、回归测试策略

13-50 测试结果

Automotive SPICE 测试结果包含以下内容：

1. IEEE 测试日志
2. IEEE 测试事件报告
3. IEEE 测试摘要报告

2.10.5 级别 2 的特征

关于绩效管理

BP1 涵盖了测试规划的概念部分（即测试什么以及如何测试）；级别 2 的通用实践和项目管理流程要求安排和跟踪单个测试活动。在小型项目中，测试规划通常是项目管理的一部分。由于大多数大型项目都有自己的测试子项目，因此子项目管理通常负责详细规划和跟踪，而项目管理仅负责粗略规划。

关于工作产品管理

过程属性 PA 2.2 的要求特别适用于测试计划、测试规范和测试结果。定义了有关工作产品（即测试计划）和质量标准（例如，用于评审）的要求，相关文档（如测试用例）处于配置控制之下，评审已进行并可验证。工作产品的修改以可验证的方式进行管理，例如，包括对测试计划和测试用例进行受控更改/认可，以保护对软件所做的更改。