从TPT看汽车测试术语（下）

上篇我们介绍了被测对象、动态测试和测试用例的概念，还提出了如何省时省力评估自动生成的测试用例的话题。事实上TPT能够实现测试用例和评估解耦，为每条用例/多条用例创建符合其场景的测试评估：可以通过GUI界面来进行信号对比、事件查询、信号边界检查、信号序列的正确性判断以及信号调理；也可以通过脚本语言实现复杂场景的评估。本文会介绍测试级别和测试环境，并带大家进一步了解模型动态测试工具——TPT。

什么是测试级别

ASPICE定义了以下五个测试级别：1. 软件单元测试(SWE.4)2. 软件集成与集成测试(SWE.5)3. 软件合格性测试(SWE.6)4. 系统集成与集成测试(SYS.4)5. 系统合格性测试(SYS.5)01软件单元测试
软件单元测试也被称为模块测试或功能测试。在单元测试中，测试对象是最小的软件组件，即单元。单元经常变化，因此单元测试必须经常调整、补充并再次执行。单元测试有两个主要目标：
1. 早期质量保证2. 快速检测模型/代码更改中的交叉影响因为软件或软件组件是永久地调整和更改的，并且后续的回归测试也总是充满了重复性，因此最简单的方法是在持续集成环境中自动化执行单元测试。TPT可以通过与Jenkins的集成实现自动化测试，提高测试效率。主要可实现的功能包括：基于TPT的Jenkins节点环境导入测试接口；自动生成TPT测试框架；自动执行TPT工程测试用例；自动生成测试报告。用Jenkins自动执行测试工程代替测试工程师手动执行，既能缩短测试周期，又能避免重复性劳动。

图1. Jenkins端TPT测试结果

02软件集成与集成测试
单元测试之后是软件集成测试。软件集成是单个软件组件的组装，这里的重点是测试软件组件之间的兼容性。集成测试通常分几个阶段进行，根据整个软件的结构，在几个中间阶段到几百个中间阶段之间提供集成测试。中间阶段的数量和选择最终取决于软件体系结构和软件设计。元素和级别越多，集成测试的中间阶段就越多。通常，集成测试是自下向上开发的，首先集成和测试几个单元(大约3-5个)。然后，所得到的单元组合与其他已经测试过的单元组合或其他单元集成在下一个中间阶段，并再次测试。这个迭代链一直持续到ECU的整个软件被构建和测试完毕。

图2. 集成测试迭代图
大量的集成测试一开始听起来工作量很大，但它有一个明显的优势，就是可以更快更好地发现错误。而在TPT中，单元的测试用例能够一定程度上复用到集成测试，为用户减少集成测试阶段的工作量。在《单元测试用例复用到集成测试？Testlet Library来助力！》一文中介绍了详细操作方法。集成测试的另一大优势在于，集成测试阶段发现的错误可以更容易地定位到其原因，从而大大简化了问题分析。经验表明，大多数软件错误都是在集成测试中发现的。

03软件合格性测试
集成测试完成后，软件合格性测试紧随其后。软件合格性测试通常在目标硬件上执行。软件合格性测试中的测试对象与集成测试中的最后一个测试对象相同:它是完全集成的软件。然而，它们各自的目的不同：

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

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

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

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

什么是测试环境

测试环境是指执行测试所需要的环境，包括硬件、仪器、模拟器、软件工具和其他支持要素。测试环境应该尽可能接近真实的生产环境，以便更准确地模拟实际环境中的操作和运行情况，从而确保软件在生产环境中的可靠性和稳定性。在这种情况下，我们经常会讨论在环测试，例如：模型在环（Model-in-the-loop ，MiL）软件在环（Software-in-the-loop ，SiL）处理器在环（Processor-in-the-loop ，PiL）硬件在环（Hardware-in-the-loop ，HiL）“在环”指的是测试对象与模拟生产环境的组件之间的一种特殊类型的交互。在“在环测试”中，环境对测试对象的状态和计算做出反应。TPT可以灵活适应于MiL/SiL/PiL/HiL/ViL整个在环测试阶段，并且支持各阶段的开发平台。

图3. TPT在环测试支持平台总览
现代新能源汽车软件的开发往往基于模型，而大多数模型是用MATLAB/Simulink/TargetLink或ASCET创建的。这些模型通常在开发环境中直接以单元和软件集成的形式作为模型在环(MiL)进行验证。这种类型的动态测试可以发现控制策略和逻辑中的错误。嵌入式系统的仿真是在同样仿真的环境模型中执行的。这种非常早期的测试的优点是可以快速检测到模型构建中已经存在的错误，并有可能对其进行修正。

模型在环-MiL

TPT在MiL环境能够自动从Simulink、TargetLink及ASCET模型获取接口信息并生成测试框架，通过测试框架将测试用例定义的输入信号激励给到被测模型，再回采被测模型的输出结果并对其进行评估，整个过程由TPT自动完成，无需用户自定义。

图4. 基于MATLAB/Simulink的TPT MiL测试过程

软件在环-SiL

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

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

手写代码：SiL可能是第一个测试级别。与MiL一样，目标是在早期阶段发现错误。

对于第1种模型生成的代码，为了验证生成的代码与原模型的等效性，应当进行背靠背测试。在TPT中，背靠背测试尤为便捷。以Simulink模型为例，用户只需要点击FUSION DLL就能调用Simulink生成代码，并且一键生成SiL测试平台，同时运行MiL和SiL平台，还能自动实现对两个平台测试数据的对比，完成等效性验证。

处理器在环-PiL

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

1. 通过调试器与目标芯片环境。

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

在这两种情况下，都提到了处理器在环(PiL)，实际上是指为目标处理器架构构建的软件测试。处理器在环测试的主要目标是检测编译器错误，或者在软件组件非常接近硬件的情况下，例如驱动程序或执行器的控制，在早期阶段检查硬件和软件组件的兼容性。在《PiL测试实战（上）| 单元级代码的PiL测试》一文中介绍了TPT做PiL测试的解决方案。简单来说，TPT将测试用例数据发送到UDE，并读取UDE从目标板读到的输出信号数据进行评估。这个过程中可以直接复用MiL/SiL环境的测试用例，单元级软件测试可实现同一测试工程覆盖MiL/SiL/PiL所有阶段。

图6. TPT+UDE PiL测试方案

硬件在环-HiL

下一个逻辑步骤是硬件测试，即在带有外围设备的物理ECU上完成软件测试，重点是输入和输出、通信总线和其他接口如何实时交互。这种测试的术语是硬件在环(Hardware-in-the-Loop ，HiL)。HiL测试从ECU开始，可以实现到系统网络级别。

图7. TPT与VECTOR CANoe集成TPT支持通过XiL-API接口与HiL设备进行集成，包括：VT System、dSPACE、NI Veristand、Concurrent iHawk、Speedgoat。可以发送测试用例到HiL设备执行，接受测试数据进行评估，支持实时测试、故障注入，也可以通过CANape/INCA对ECU进行标定和测量。

05总结
在汽车软件测试中，有许多术语和方法。在我们看来，掌握这些背景知识、合理运用测试工具和测试方法，是成功实现嵌入式系统测试的关键。本文带大家从工具的层面出发，介绍了TPT在不同测试级别和测试环境中的作用。