汽车电子软件测试术语-简介

目录

 

软件与车辆：高度复杂

测试对象，测试用例和动态测试

测试级别

测试环境

 

无论是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处于唤醒状态并准备接收消息。

 

测试数据和期望值是所有测试级别的测试用例和以这种形式执行的测试用例所需要的。期望值是由各种各样的信息来源给出的——也称为测试预言。测试预言可以是现有的系统(作为基准)、规范或个人的专业知识。在任何情况下，被测试的代码都不应该作为信息的来源。

 

什么是动态测试?

 

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

 

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

 

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

 

什么是测试级别？

 

ASPICE间接地将测试级别分配给它的过程模型，并包含以下五个过程:

 

1. 软件单元验证(SWE.4)

2. 软件集成与集成测试(SWE.5)

3. 软件资质测试(SWE.6)

4. 系统集成与集成测试(SYS.4)

5. 系统资质测试(SYS.5)

 

 

当根据ASPICE进行分配时，应该注意：流程期望更多的活动而不仅仅是动态测试。

 

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

 

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

 

单元经常变化，因此单元测试必须经常调整、补充并再次执行。单元测试有两个主要目标:

 

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

 

单元测试通常是软件开发中首先自动化的。

 

因为软件或软件组件是永久地调整和更改的，所以在持续集成方法框架内的一致性是非常有用的，并且已经建立起来了。无论测试级别如何，测试的重复总是被称为回归测试，并且在ASPICE中，软件单元验证是必需的。实现回归测试的最简单方法是自动化测试并在持续集成环境中执行它们。

 

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

 

通常，集成测试是自底向上开发的，首先相互集成和测试几个单元(大约3-5个)。然后，所得到的复合体与其他已经测试过的复合体或其他单元集成在下一个中间阶段，并再次测试。这个迭代链一直持续到ECU的整个软件被构建和测试完毕。

 

大量的集成测试一开始听起来工作量很大，但它有一个明显的优势，就是可以更快更好地发现错误。在我们的经验中，在集成测试中建立一个额外的中间阶段所需要的工作，可在最初建立测试阶段时，通过减少创建测试用例所需的工作来得到补偿。

 

还有什么是支持集成测试的? 发现的错误可以更容易地缩小到其原因，从而大大简化了分析。

 

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

 

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

 

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

 

1. 集成测试的目的:检查软件组件之间的兼容性。

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

3. 信号处理

4. 软件行为改变参数等方面

 

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

 

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

 

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

 

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

 

什么是测试环境？

 

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

 

在这种情况下，经常会讨论在环测试，例如

 

1. 模型在环（Model-in-the-loop ，MiL）
2. 软件在环（Software-in-the-loop ，SiL）
3. 处理器在环（Processor-in-the-loop ，PiL）
4. 硬件在环（Hardware-in-the-loop ，HiL）

 

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

 

与开环测试相比，“在环测试”的优点是更接近真实的生产环境。但是，在环环境的设置更加复杂。

 

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

 

这种类型的动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的仿真是在同样仿真的环境模型中执行的。这种非常早期的测试的优点是可以快速检测到模型构建中已经存在的错误，并有可能对其进行修正。

 

在软件在环测试（SiL）中，测试代码是在PC上测试的。这要么是手写的，要么是从模型生成的。这两种代码的作用域是不同的。

 

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

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

 

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

 

在SiL中测试的代码不能在嵌入式ECU上执行。为了执行，必须为目标处理器编译代码。在这个过程中生成的代码可以通过两种方式进行测试:

 

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

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

 

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

 

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

 

下一个逻辑步骤是测试硬件: 也就是说，在带有外围设备的物理ECU上完成软件。现在的重点是输入和输出、通信总线和其他接口如何实时交互。这种测试的术语是硬件在环(Hardware-in-the-Loop ，HiL)。HiL测试从ECU开始，可以实现到系统网络级别。HiL试验台架可以对整车进行测试，但设置和操作成本相应较高。尽管如此，他们还是很成熟的，因为进行手动车辆测试也很昂贵，而且更费时。

 

在车辆测试中，ecu、执行器和传感器组件在最终目标环境中进行测试。车辆大多在寒冷、温暖和炎热地区的不同环境条件下进行测试。即使在今天，这些测试也主要是手动执行的。在某些情况下，测量结果会被自动记录，然后在工具的帮助下进行评估。这个测试阶段发生在每个OEM。要进行车辆测试，车辆及其所有部件必须可用。然而，由于手动测试需要训练有素的司机和车辆，测试的可扩展性较差。

 

总结

 

术语和信息的密集使得一件事很清楚: 背景知识、过程和项目之间的沟通是有效和高效地开发、测试和成功实现嵌入式系统的关键。

 

在汽车软件测试中，有许多方法和方法，在我们看来，没有对与错，而是有利与不利。当然，这取决于各种参数，涉及的组织，最终取决于一起工作的人。

 

我们是早期测试的支持者，我们建议直接从单元测试级别开始。进一步说到集成测试，可以测试不同的功能以获得开发的直接反馈。所有这些都导致了快速、合作的产品开发。