高效的汽车电子测试

　　[图3：测试在所有开发阶段都是不可或缺的]

　　这种分段式的工作方法产生于将开发过程中众多不同的任务分配给专门的工作组。但是，如果对任务分割的要求太严格，那么存在于不同开发和测试任务间的众多关联点将很有可能不能被优化利用。比如，只有很好地协调部件测试和系统测试才能避免开发大量内容相同的冗余测试用例。当使用兼容工具时，已经开发出来的测试用例可以作为其它不同领域的开发基础。避免冗余开发释放了占用的资源，比如可以将其投入到现有测试用例及其高级开发的确认工作中。全面的测试管理为协作提供了坚实的基础，共用相同的测试用例优化了测试的广度和深度。协调也有助于发现和填补测试缺口。

　　除了连接不同的测试阶段，开发和测试活动也必须相互联系并互相适应。应当将测试理解为开发的组成部分，需要使用恰当的方法和工具对其进行广泛的支持。这必须从程序上和组织上得到保证。这里，重要的是测试与开发一起进行，而不是只在要求的正式确认阶段进行。理想的情况是，可以直接在ECU开发者的工作地点利用现有的资源直接进行测试。

　　为此，CANoe提供了一个用来执行测试的运行时环境，并可以与残余总线仿真和分析功能并行使用 。该流程非常容易建立，尤其是在开发者已经使用CANoe进行残余总线仿真和总线通信分析的情况下。

　　CANoe的测试组件可以手动、半自动和完全自动化的完成测试。开发者可以从简单测试入手，然后对它们进行扩展和完善。通常，复杂测试的创建过程是确认部门的任务，他们要在开发者的测试上建立他们的测试。

　　这种测试的重要基础是残余总线仿真。在理想情况下，这种仿真不是手工建立的，而是从系统的描述数据库中自动生成和参数化的。实际工作由所谓的建模DLL（比如交互层、网络管理等）完成，它们是随工具一起提供的或者是由Vector作为OEM专用建模包提供的。残余总线仿真为模拟节点提供的信号可以直接从测试脚本获取，或者以手工方式激励或添加。

　　与在测试阶段系统进行的计划、执行和归档活动相比，伴随开发的测试通常省略了正式的执行和归档。然而，这些测试对提高整体质量做出了实际贡献，因为他们让开发者能够为后续的测试阶段提供更稳定的产品。

　　4 成熟度评估和误差分析

　　在开发过程中，为了评估ECU的成熟度，需要对所有执行过的测试进行全面的评价。必须考虑个体测试结果在可靠性和相关性方面的质量，而更加重要

的是采用恰当的测试全面覆盖所要求的特性。因此，不怎么正式执行的测试，其结果对成熟度分析也是有帮助的。前提条件是（除了记录测试过程外）使用兼容的配置管理。从完成面向质量的、结构化的开发过程的角度来说，这也是十分必要的。

　　不论在何时何地（测试实验室或开发场所），使用CANoe执行测试时都会生成一个测试记录，该记录创建时不需要用户或测试用例开发者进行干涉。这样在进行伴随开发的测试时就不需要做额外的工作。用于测试记录的XML是一种开放格式，可供其它工具使用以对结果进行更深入的处理。例如，在进行成熟度分析时可以使用一个测试管理系统来评价测试记录。

　　该工作的本质是测试结果到测试用例、测试用例到需求的映射。使用唯一的标识符（比如一个需求ID）可以很容易地实现这一点，测试用例开发者在个体测试用例中会引用它。CANoe会自动将该标识符复制到测试记录中，这样所有测试用例、测试结果和需求就可以明确地关联起来（图4）。

　　[图4:测试用例和测试结果由ID明确地引用]

　　分析实际发生错误的原因至少与记录和评估测试结果同样重要。大多数测试工具都不会提供任何这样的功能或者仅仅提供不完善的功能。一个重要原因就是错误分析经常被当作开发者的一项完全独立的任务。首先，他们面临理解测试中检测到的错误并跟踪其原因的问题。尤其是，当测试实验室报告错误时，开发者常常甚至不能使用测试中用到的系统。

　　因此，会强制要求准确记录测试台上的测试步骤并记录每一个与DUT间的交互动作，尤其是总线通信。在分析阶段，CANoe允许重放和分析任何需要的记录（日志记录）。从而有可能在开发场所使用与测试台上相同的测试系统并从中受益，因此开发者可以独立地重新执行错误生成测试用例。在很多情况下，甚至是有必要进行简化时（比如为了避免选择不存在的测量硬件）都可以执行相关测试用例。

　　5 信号抽象和诊断

　　抽象是处理软件开发和系统设计中复杂度问题时普遍采用的重要方法。也可用它来处理测试。ECU中增长的功能不仅增加了系统的复杂度，而且需要更加广泛和复杂的测试。选择正确的抽象层组成测试不仅会影响创建测试用例所需要的工作量、进而影响成本，而且会影响测试用例的质量。就像所有其它软件组件一样，测试用例本身也可能会存在错误，应该在使用之前进行检查。另一方面是必要的维护任务，比如适应需求的改变和修订测试用例。

　　信号层抽象是测试ECU功能的常用方法，这也是为什么在ECU中实际的应用程序通常会基于信号抽象的原因（图5）。例如，在一个CAN系统中，ECU交互层提供了信号抽象。这正是CANoe使用交互层的方式；它从网络描述包含的信息中将自身参数化，而网络描述也用于创建ECU软件。这保证了ECU和测试环境使用相同的抽象层从而在相互间形成最佳的协调。

　　同时，信号抽象也表示了——至少在协议层——残余总线仿真。比如，它保证周期性信号实际是按周期发送的。在测试中，ECU是运行在有关总线通信的现实环境下的。此外，当修改了系统通信矩阵时，通常可以继续使用保持不变的测试用例。对相同的应用程序，抽象使得相似项目中的测试用例得到重用。

　　[图5：信号一方面提供了消息和I/O线路间的抽象，另一方面提供了测试定义和仿真模型间的抽象]

　　在ECU测试中，重要的并不仅仅是信号接口。只有在对ECU进行较深层访问时，对许多ECU功能的测试才会有意义。这样的访问是由诊断和标定接口提供的，它们通过ECU的现有总线接口接入。使用简单的消息序列对这些接口进行访问是没有意义的，因为在通信进程下面存在着规定的协议。使用合适的诊断和标定抽象 会更加便捷和可靠。