一种贯穿HIL仿真到诊断的汽车电子测试环境
图3：测试在所有开发阶段都是不可或缺的
除了连接不同的测试阶段，开发和测试活动也必须相互联系且互相适应。应当将测试理解为开发的一个组成部分，它需要使用恰当的方法和工具来支持。在程序和结构上得到保证之外，必须保证这一点。在此，重要的是测试与开发一起进行，而不是只在要求的正式确认阶段进行。理想的情况是，可以直接在ECU开发者的工作地点利用现有的资源直接进行测试。
为此，CANoe提供了一个用来执行测试的运行时环境，并可以与残余总线仿真和分析功能并行使用。该流程非常容易建立，尤其是在开发者已经使用CANoe进行残余总线仿真和总线通信分析的情况下。
CANoe的测试组件可以手动、半自动和完全自动化的完成测试。开发者可以从简单测试入手，然后对它们进行扩展和完善。通常，复杂测试的创建过程是确认部门的任务，他们要在开发者的测试上建立他们的测试。
这种测试的一个重要基础是残余总线仿真。理想情况下这种仿真并非由手工建立，而是从系统的描述数据库中自动生成和参数化的。实际工作由所谓的建模DLL(比如交互层、网络管理等)完成，它们是随工具一起提供的或者是由Vector作为OEM专用建模包提供的。残余总线仿真为模拟节点提供的信号可以直接从测试脚本中获取，也可以手工方式激励或添加。
与测试阶段中系统化的计划、执行和归档活动相比，伴随开发的测试通常省略了正式的执行和归档。然而，这些测试对提高整体质量做出了实质性贡献，因为他们赋予了开发者为后续的测试阶段提供更稳定的产品的能力。
成熟度评估和误差分析
在开发过程中，为了评估ECU的成熟度，需要对所有执行过的测试进行全面的评价。除了要考虑单个测试结果在可靠性和相关性方面的质量，更重要的是采用适当的测试来全面覆盖所要求的特性。因此非正式的测试结果对成熟度分析也是有帮助的。前提条件是(除记录测试过程外)使用兼容的配置管理。从完成面向质量的、结构化的开发过程的角度来说，这也是十分必要的。
无论在何时何地(测试实验室或工作台上)，无需用户或测试用例开发人员进行干涉，使用CANoe执行测试时都会生成一个测试记录。这样在进行伴有测试的开发时就不需要做额外的工作。用于测试记录的XML是一种开放格式，以使其它工具使用以对结果进行更深入的处理。例如在进行成熟度分析时可以使用一个测试管理系统来评价测试记录。
这项工作的本质是测试结果到测试用例、测试用例到需求的映射。使用唯一的标识符(比如一个需求ID)可以很容易地实现这一点，测试用例开发者在单个测试用例中会引用它。CANoe会自动将该标识符复制到测试记录中，这样所有测试用例、测试结果和需求就可以明确地关联起来(图4)。
图4：测试用例和测试结果由ID明确地引用
基于上述原因，测试台上的测试步骤以及每一个与DUT间的交互动作都将被强制记录，特别是总线通信。在分析阶段，CANoe允许重放和分析任何需要的记录(日志)。从而有可能在开发场所使用与测试台上相同的测试系统以从中受益，这样开发者就可以独立地再现生成错误的测试用例。在很多情况下，甚至是有必要进行简化时(比如为了避免选择不存在的测量硬件)都可以执行相关测试用例。
信号抽象和诊断
抽象是处理软件开发和系统设计中复杂度问题时普遍采用的重要方法。它也可用来处理测试。ECU中不断增多的功能不仅增加了系统的复杂度，还需要更广泛和复杂的测试。选择正确的抽象层组成测试不仅会影响创建测试用例所需要的工作量、进而影响成本，而且会影响测试用例的质量。就像所有其它软件组件一样，测试用例本身也可能会存在错误，应该在使用之前进行检查。此外，还需要必要的维护，比如适应需求的改变和修订测试用例。
信号层抽象是测试ECU功能的常用方法，这也是为什么在ECU中实际的应用程序通常会基于信号抽象的原因(图5)。例如，在一个CAN系统中，ECU交互层提供了信号抽象。这正是CANoe使用交互层的方式；利用网络描述中的信息，它将自身参数化。网络描述同样也可用于创建ECU软件。这保证了ECU和测试环境使用相同的抽象层从而在两者间形成最佳的协调。
评论