测试基础｜汽车软件测试术语解释

编译整理｜TesterHome社区

作者｜Robert Fey

以下为作者观点：

目录

• 什么是测试对象或被测系统？

• 什么是测试用例？

• 什么是动态测试？

• 测试级别有哪些？

• 什么是测试环境？

• 总结

汽车世界在不断发展，“软件定义汽车”等新术语证明了软件对于当今汽车的重要性。

无论是 MiL、SiL、PiL、HiL、单元测试、软件测试还是集成测试：汽车软件测试领域有很多技术术语，因此两个人对同一术语的理解可能会有所不同。误解可能会发生，并使有效合作变得困难——我们也知道类似的情况。

在开发过程中，以前纯粹的机械领域逐渐扩展到软件和数字功能。车辆的功能和行为现在几乎完全通过软件实现。与此同时，当人们谈论软件时，也会立即提到测试。但为什么要提到软件和测试呢？软件也只在车辆的硬件上运行，它们共同构成 ECU（电子控制单元）。有些车辆配备多达 150 个 ECU，大约有 1 亿行代码（LOC）。ECU 相互通信和交互，以实现车辆的特定功能并使其对客户切实可行。

有这么多的编程代码，怎么可能出错呢？！让我们来看一个客户可以直接体验的车辆功能示例：在仪表盘上显示交通标志。它的工作原理如下： 

1.相机拍摄照片并对其进行评估。 

2.检测到的交通标志被传送到显示控制单元并在那里可视化。 

3.该信息同时传达给其他控制单元的其他功能并在那里进行处理。  

所有传感器、执行器和控制单元的连接被称为网络架构，一辆车至少需要三年的开发时间才能投入量产。所有传感器、执行器和控制单元的正确交互自然会影响车辆的功能和质量。为了测试正确的交互，必须分多个阶段反复迭代测试车辆。

最大的挑战是，汽车零部件的开发往往更多地是作为一个产品而不是一个项目，因此来自多个公司和部门的许多人都参与了汽车的制造。

综上所述，这意味着汽车的开发比人们最初想象的要复杂得多。一方面是由于组织框架条件，另一方面是由于包含软件内容的系统组件数量众多。由于可以通过多个系统组件的交互来体验功能，因此复杂性进一步增加。

为了弥补所有这些缺陷，车辆需要进行许多测试。测试的内容、具体测试级别以及测试方式将在下一节中讨论。

什么是测试对象或被测系统？

测试对象、被测系统和测试元素这些概念经常被同时使用。根据 ISTQB，测试对象被非常笼统地定义为“要测试的工作产品”。因此，测试对象可以是：

1. 一个单位

2. 多个软件部分的汇编

3. 完整的软件程序

4. 控制单元

5. 由多个控制单元组成的网络

6. 整辆车

7. 是任何其他要测试的对象

下面我们将使用术语“测试对象”和“被测系统”来表示所有需要测试的事物。  

什么是测试用例？

测试用例始终至少包含以下两条信息： 

1. 定义应如何刺激测试对象的测试数据。

2. 测试对象的预期值，定义测试对象在刺激期间应进行哪些计算/状态。 

可选地，测试用例可以添加更多相关信息。测试对象“ECU”的典型先决条件是：ECU 处于唤醒状态并准备好接收消息。 

测试数据和预期值是所有测试级别和测试执行的测试用例所必需的。预期值由各种信息源（也称为测试预言）提供。测试预言可以是现有系统（作为基准）、规范或个人的专业知识。在任何情况下，被测代码都不应作为信息源。 

什么是动态测试？

动态测试是测试对象的执行。大多数人将“测试”一词与动态测试联系在一起。 

在动态测试中，会创建并执行一个测试用例，用测试数据来刺激测试对象。刺激会导致测试对象执行计算或改变其状态。动态测试会记录测试对象的反应，并将其与期望值进行比较。如果反应等于期望值，则认为测试用例已通过。如果不相等，则认为测试用例失败。 

动态测试的对立面是静态测试。在静态测试中，测试对象不会被模拟，而是被静态分析。静态测试的一个例子是源代码文件的审查。

测试级别有哪些？

Automotive SPICE 间接地将测试级别分配给其流程模型，并了解以下五个流程： 

1. 软件单元验证（SWE.4） 

2. 软件集成与集成测试（SWE.5） 

3. 软件资格测试（SWE.6） 

4. 系统集成与集成测试（SYS.4） 

5. 系统资格测试（SYS.5）

根据 Automotive SPICE 进行分配时，应该注意，流程需要的活动不仅仅是动态测试。 

但测试用例实际上在哪个测试级别执行，目的是什么？我们从最小的级别开始：编码。这些是可以最早测试的测试对象。  

软件编程之后是与开发相关的单元测试。它们也称为模块测试、功能测试或单元测试。在单元测试中，测试的是最小的软件组件，即单元。  

单元经常更改，因此单元测试必须经常进行调整、补充和重新执行。单元测试有两个主要目标：

1. 早期质量保证2. 快速检测代码变更的交叉影响

单元测试通常是软件开发中第一个实现自动化的。

由于软件或软件组件会不断调整和更改，因此在持续集成方法框架内进行协调非常有用，并且已经建立。无论测试级别如何，重复测试始终称为回归测试，并且在 Automotive SPICE 中用于软件单元验证等是必需的。实施回归测试的最简单方法是自动化测试并在持续集成环境中执行它们。

单元测试之后是软件集成测试。集成是各个软件组件的组装及其测试。这里的重点是软件组件之间的兼容性。集成测试通常分几个阶段进行。根据整个软件的范围，集成测试提供几个中间阶段到几百个中间阶段。中间阶段的数量和选择最终取决于软件架构和软件设计。元素和级别越多，集成测试中可以预期的中间阶段就越多。  

通常，集成测试是自下而上开发的，首先将几个单元（大约 3-5 个）相互集成并进行测试。然后将生成的复合材料与其他已测试的复合材料或其他单元集成，然后进行下一个中间阶段的测试。这种迭代链一直持续到 ECU 的整个软件都已构建并测试完毕。 

大量集成测试乍一听似乎需要付出很多努力，但其明显优势在于可以更快、更好地发现错误。根据我们的经验，在集成测试中设置额外中间阶段所需的努力可以通过减少在最初设置测试阶段时创建测试用例所需的努力来补偿。  

还有什么可以证明集成测试是可行的？可以更轻松地缩小发现的错误的范围，找出其原因，从而大大简化分析。 

最重要的是：经验表明，大多数软件错误都是在集成测试中发现的。  

对于那些尚不相信的人来说，任何持续集成方法都恰好提供了这些测试阶段。  

集成测试完成后，接下来是软件测试，通常在目标硬件上执行。软件测试中的测试对象与集成测试中的最后一个测试对象相同：它是完全集成的软件。但是，它们各自的目的将这两个测试级别彼此区分开来。 

• 集成测试的目标：检查软件组件之间的兼容性。 

• 软件测试的目的：检查是否符合软件要求，例如与传感器和执行器的兼容性

• 信号处理

• 软件行为改变参数及其他方面

软件测试之后是进一步的集成测试。不过，这次不是在软件层面，而是在系统组件层面。程序与软件集成测试相同。ECU 与一个或多个传感器或执行器一起进行测试，并一点一点地添加其他组件，直到系统到位。  

最终测试在系统测试中进行。在此过程中，所有系统组件都集成到一个系统中并进行测试。系统测试的重点是确定是否符合系统要求以及系统的可交付性。  

在汽车开发中，现在还有一些额外的组织挑战，例如：什么是系统？对于汽车 OEM 来说，系统就是车辆。但是，提供子系统（例如动力系统或软件组件）的供应商如何回答这个问题？在这种情况下，必须更严格地指定测试阶段的测试对象。  

从合同的角度来看，还有一个进一步的测试阶段：验收测试，由客户执行。从合同的角度来看，验收是声明开发（软件、硬件、系统等）符合合同标准。验收后，剩余款项到期，保修开始。  

什么是测试环境？

测试环境就像是测试对象及其参与者的训练场。它应该尽可能贴近真实的生产环境，以便测试与其他参与者、状态和信号的交互的重要性尽可能高。

在这种情况下，人们经常谈论在环测试，例如：

1. 模型在环 (MiL) 
2. 软件在环 (SiL) 
3. 处理器在环 (PiL) 4. 硬件在环 (HiL)

“在环”之前的术语代表测试对象的类型。“在环”是指测试对象与模拟生产环境组件之间的一种特殊交互类型。在“在环测试”中，环境会对测试对象的状态和计算做出反应。因此，这些测试与开环测试相反，开环测试不会模拟任何环境反应。

与开环测试相比，“在环”测试的优势在于更接近真实生产环境。然而，在环环境的设置更为复杂。

在汽车环境中，开发通常基于模型。大多数模型都是用 MATLAB/Simulink 或 Targetlink 创建的。这些模型通常以单元和软件集成测试的形式直接在开发环境中验证为模型在环 (MiL)。  

这种动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的模拟是在环境的同样模拟模型中执行的。这种非常早期的测试的优点是可以快速检测并纠正模型构建过程中的错误。 

在软件在环 (SiL) 测试中，代码在 PC 上进行测试。代码可以是手写的，也可以是从模型生成的。这两种代码的范围不同。 

1.生成代码测试：检查代码生成器是否正常工作。生成的代码的功能应尽可能接近模型。  

2.对于手工代码，SiL 是第一个可能的测试级别。与 MiL 一样，其目的是在早期阶段发现错误。

SiL 用于测试阶段的单元测试、集成测试，在某些情况下也用于软件测试。此阶段尚不适用于硬件。 

SiL 中测试的代码无法在嵌入式 ECU 上执行。要执行，必须针对目标处理器编译代码。在此过程中生成的代码可以通过两种方式进行测试：  

1.通过带有未来目标环境的处理器的评估板。 

2.在模拟处理器的虚拟环境中的 PC 上。

这两种情况都称为处理器在环 (PiL)，实际上指的是针对目标处理器架构构建的软件测试。因此，严格来说，测试阶段也可以称为目标软件在环。  

处理器在环测试的主要目标是检测编译器错误，或者对于非常接近硬件的软件组件（例如驱动程序或执行器的控制器），在早期阶段检查硬件和软件组件的兼容性。  

下一个合乎逻辑的步骤是测试硬件：即物理 ECU 上带有外围设备的完成软件。现在的重点是输入和输出、通信总线和其他接口如何实时交互。术语为硬件在环 (HiL)。HiL 测试从 ECU 开始，可以实施到系统网络级别。有 HiL 测试台可以测试整个车辆，但设置和操作成本相应较高。尽管如此，它们还是很成熟的，因为从组织的角度来看，进行手动车辆测试也很昂贵，而且要耗费更多时间。  

在车辆测试中，ECU、执行器和传感器等组件在最终目标环境中进行测试。大多数情况下，车辆在冷地、暖地和热地等不同环境条件下进行测试。即使在今天，这些测试也主要是手动进行的。在某些情况下，会自动记录测量值，然后借助工具进行评估。每个 OEM 都会进行此测试阶段。要进行车辆测试，必须准备好车辆及其所有组件。然而，测试的可扩展性较差，因为手动测试需要经过培训的驾驶员和车辆。 

概括总结

术语和信息的密度清楚地表明了一点：了解背景、流程和项目之间的沟通是有效和高效地开发、测试和成功实施嵌入式系统的关键。 

在汽车软件测试中，有许多方法和方法论，我们认为，没有对错之分，只有有利和不利的因素。当然，这取决于各种参数、相关组织，最终取决于合作的人员。 

我们热衷于早期测试，我们建议直接从单元测试级别开始。进一步进行集成测试，可以测试不同的功能以获得开发的直接反馈。所有这些都可以实现快速、协作的产品开发。 （原文链接：https://www.synopsys.com/blogs/chip-design/automotive-testing-terms.html）