什么是在环测试

嵌入式系统软件是一个竞争优势。软件可以使得已经舒适的乘坐更具吸引力，比竞争性交通工具更好。它还可减少驾驶室噪音，或降低燃油消耗。可轻松地配置嵌入式软件，以符合用户的喜好 – 只需按一下开关便可将舒适的公路汽车变为更具运动特色的交通工具。

当然也可在硬件中实现那些可以通过软件获得的功能，但是这样做会相应地增加制造成本和产品价格。嵌入式软件还可实现重复利用，并且可更加频繁地更新，以满足不断增长的需求。

图1，在环测试示意图

所有这些以及其他更多原因造成了嵌入式软件应用的复杂性。很难测试和验证复杂嵌入式软件的功能。验证和确认费用、解决缺陷的成本以及没有及时发现的缺陷问题会抹杀掉软件功能具有的所有优势。

嵌入式软件开发行业意识到这一点，并基于图形化模型进行软件开发，以应对不断增长的复杂性。图形化的产品功能还具有仿真能力，可提高验证和确认方法。本文简要概述通过基于模型的设计的关键软件测试方法。

1 通过模型开发和测试嵌入式软件

建模是设计和开发中的一个重要步骤，它发生在收集高层需求之后以及进行任何实现之前。模型还允许在开发的同时，进行持续地进行测试和验证。

图2，建模是设计和开发中的一个重要步骤

在早期的设计阶段，开发者可开发纯粹的行为模型，以阐明并定义软件的详细要求。

虽然此类模型已经具备了基本解决方案的轮廓，但是它们依然独立于目标平台。这些目标独立的行为模型将用于设计验证和早期的需求确认。

用于捕获关键需求、在仿真中展示正确行为以及展示对高层需求可追溯性的模型通常被称为“可执行规范”。

对可执行规范的进一步开发和具体实现可产生代表最终实现的模型的定义。这就是用于产品代码生成的模型。通常，这些模型会对代码生成做优化;它将从数据类型、目标架构以及要求的代码风格。所有这些变更需要一个验证过程，确保产品代码生成模型中引入的变更不会改变软件的行为。确认生产代码生成模型以及生成代码的正确行为的测试为代码验证。

把验证分布在设计验证和代码验证阶段允许我们更早地开始验证工作，更多的关注在测试上和更短的时间去修复在测试中检测到的错误。在本文的其余部分，我将介绍两个设计验证方法：

·模型在环测试

·软件在环测试

以及用于代码验证的两个方法：

·处理器在环测试

·硬件在环测试

2 设计验证

设计验证的主要目的是确认所有关键要求和设计概念是否已正确体现在设计模型中。

·模型在环测试

与“静态”的书面设计不同，可在仿真过程中评估可执行规范。通常，通过改变一组模型参数或输入信号，或通过查看输出结果或模型的响应，来完成这一操作。依据模型执行的仿真顺序也称为模型在环测试。

模型在环测试的测试数据可来自测试矢量数据库，或来自实际系统的模型，在后一种情况下，我们讨论闭环控制系统。

可执行规范通常不仅仅包含功能设计模型和软件逻辑，还包括设备和环境模型、高层需求的链接以及其他文件。它通常还包括用于自动化仿真结果评估的验证数据。

模型在环测试的结果可用于验证软件行为是否正确，并确认开发流程的初始需求。通过仿真收集的信息会成为代码验证的基准。

·软件在环 (SIL)

在许多情况下，在目标环境中部署软件之前，确保所设计的系统的软件组件能够按预期运行，这一点非常重要。

图3，软件在环(软件算法测试)

软件算法的测试(在主机上的联合仿真中评估生成的函数或手写的代码)称为“软件在环”。与模型在环测试类似，输入测试矢量可来自于测试数据库或来自设备模型，并且可与 MIL 测试共享。

当软件组件包含需要在目标平台上执行的生成代码(例如，更新控制器逻辑以满足新要求)和手写代码(例如，现有驱动程序和数据适配器)的组合时，此类验证尤其有用。

通常利用软件在环测试来验证图形化模型中现有算法的重新实现。可能很难或需要花费较多成本来维护一些旧的但是正确的代码，这对于在建模环境中重新实现及验证而言意义重大。在这种情

况下，仿真成为比较新模型实现和旧代码中已有算法的输出的环境。

3 代码验证

验证设计质量及其对现有的需求的兼容性之后，我们可专注于代码验证。代码验证的关键目标是确保软件行为匹配在仿真中捕获的模型行为。

·处理器在环 (PIL)

从概念上来说，处理器在环 (PIL) 测试类似于软件在环测试。关键的差别在于 PIL 代码在嵌入式处理器硬件或指令集仿真器上执行，以便该验证可考虑在目标处理器上执行的算法的特定具体条件。在模型与部署的目标