在当今的汽车电子开发过程中，测试扮演着十分重要的角色。然而，在使用正确的策略、思想和工具以使将来实现更为高效和自动化执行测试方面，业界仍然有许多潜力可挖。
本文分析了测试技术的现状，阐明了在实践中所发生的交互作用疑难问题，并且证明了今天已经可以使用现成的工具以一种优雅而高效的方式解决与测试相关的具体项目任务。
1.引言
过去十年，汽车电子行业的状况发生了翻天覆地的变化。起初，在汽车上仅使用了几个ECU，但是现在某些豪华车安装的ECU数量已经超过[JW1]了60个。增加的电子系统提高了安全性、舒适性并节约了能源。今天，更多的创新依赖于电子技术，而很多功能的实现也日益依赖于软件。
复杂度的提高使得全面而高效的测试变得比以往任何时候都更加重要。大量电子元件的广泛使用导致潜在错误源的数量急剧增多。由于测试可以尽早发现并改正错误和降低成本，因此无论在ECU开发的哪个所有阶段它都是不可或缺的。此外，只有将部件集成起来并运行于真实环境和实时条件下时，一些系统缺陷才会暴露出来。这让测试成为了一门跨部门和跨厂商的学科。
早期发生的大量电子故障说明，在不考虑上述事实且忽视系统测试的情况下会发生什么问题。问题发现的越晚，对抬高成本产生的影响就越严重。而极端情况下由于修正错误而引起的产品召回更加清楚地说明了这一点。虽然汽车工业的成员吸取了这些教训，对测试极为重视，然而我们仍然可以通过现有的资源来进一步提高测试效率。此外，尽管测试成本占用了项目预算大部分资源，但它保证了ECU的正确功能。因此，使用明晰的概念(比如使用现代方法和工具代替不全面的自动测试步骤)来最大化的提高测试质量和测试深度是非常重要的。
2.分析、仿真和测试工具
ECU网络是汽车电子的中枢。而残余总线仿真方法为进行ECU测试建立了重要基础。如果没有对ECU环境的初步模拟，那么大多数ECU都不能有效地地运行。比如，很多ECU只有在提供网络管理功能的条件下才能正常运转。
来自Vector Informatik公司的CANoe是一款被广泛用于分析、仿真和测试分布式、嵌入式系统的工具(图1)。它被广泛应用于残余总线仿真并且支持所有重要的总线系统——特别是CAN、LIN、MOST和FlexRay——Vector Informatik公司也提供适用于这些总线系统的PC接口。现有的商业接口卡可用于从CANoe访问ECU的I/O线路。此外，Vector还宣布将发布一种带有特定测试功能(比如切换附加负载到ECU终端和将其直接短路)的I/O硬件产品。
图1：CANoe包含针对网络系统的分析、仿真和测试功能。
各种分析功能、仿真组件和测试序列依赖于以数据库形式集成在工具中的模型。它们可能是用于CAN的DBC格式的通信矩阵、用于FlexRay的FIBEX文件、用于MOST的XML功能目录或用于LIN的LDF文件。同样，CDD和ODX描述文件可以用来描述ECU的诊断功能。测试描述文件除了包含系统的基本信息外，还包含了信号、报文和诊断服务等的符号化名称。这简化了测试人员和测试开发者的工作，并且在测试和通信描述之间创建了一个抽象层。
任何能运行Windows操作系统的简单PC工作站都可运行CANoe。使用实时配置系统可以建立具备更高实时性能的、更为强大的测试站。实时配置系统由两部分组成(图2)：一台运行实时操作系统(Windows CE)的专用电脑，用于执行残余总线仿真和实际的测试；另一台独立的PC机，用作图形用户界面和进行评估。在该设置中，系统也可用作进行部件HIL测试的测试执行环境。
图2：双机运行的CANoe Real-Time提供了更高的实时性。
3.测试与开发的集成
如今的开发模型在各个开发阶段都要求进行测试(图3)。通常，个体测试是独立的、分离的活动，是由专门的人使用专门的工具、语言和方法在有适当配置的专用工作站上完成的。这里，创建测试通常是一项独立的工作，与其他开发活动是分开的。
图3：测试在所有开发阶段都是不可或缺的。
这种分段式的工作方法源于将开发过程中众多不同的任务分配给专门的工作组。但是，如果对任务分割的要求太严格，那么不同开发和测试任务间的众多关联点将很有可能不能被优化利用。例如只有很好地协调部件测试和系统测试才能避免开发过多内容相同的冗余测试用例。当使用兼容工具时，已经开发出来的测试用例可以作为其他不同领域的开发基础。避免冗余开发的做法释放了占用的资源，举例来说，可以将其投入到现有测试用例及其高级开发的确认工作中。全面的测试管理为协作提供了坚实的基础，共用相同的测试用例优化了测试的广度和深度。协调也有助于发现和填补测试缺口。
除了连接不同的测试阶段，开发和测试活动也必须相互联系且互相适应。应当将测试理解为开发的一个组成部分，它需要使用恰当的方法和工具来支持。在程序和结构上得到保证之外，必须保证这一点。在此，重要的是测试与开发一起进行，而不是只在要求的正式确认阶段进行。理想的情况是，可以直接在ECU开发者的工作地点利用现有的资源直接进行测试。
为此，CANoe提供了一个用来执行测试的运行时环境，并可以与残余总线仿真和分析功能并行使用。该流程非常容易建立，尤其是在开发者已经使用CANoe进行残余总线仿真和总线通信分析的情况下。
CANoe的测试组件可以手动、半自动和完全自动化的完成测试。开发者可以从简单测试入手，然后对它们进行扩展和完善。通常，复杂测试的创建过程是确认部门的任务，他们要在开发者的测试上建立他们的测试。
这种测试的一个重要基础是残余总线仿真。理想情况下这种仿真并非由手工建立，而是从系统的描述数据库中自动生成和参数化的。实际工作由所谓的建模DLL(比如交互层、网络管理等)完成，它们是随工具一起提供的或者是由Vector作为OEM专用建模包提供的。残余总线仿真为模拟节点提供的信号可以直接从测试脚本中获取，也可以手工方式激励或添加。
与测试阶段中系统化的计划、执行和归档活动相比，伴随开发的测试通常省略了正式的执行和归档。然而，这些测试对提高整体质量做出了实质性贡献，因为他们赋予了开发者为后续的测试阶段提供更稳定的产品的能力。
4.成熟度评估和误差分析
在开发过程中，为了评估ECU的成熟度，需要对所有执行过的测试进行全面的评价。除了要考虑单个测试结果在可靠性和相关性方面的质量，更重要的是采用适当的测试来全面覆盖所要求的特性。因此，非正式的测试结果对成熟度分析也是有帮助的。前提条件是(除记录测试过程外)使用兼容的配置管理。从完成面向质量的、结构化的开发过程的角度来说，这也是十分必要的。
无论在何时何地(测试实验室或工作台上)，无需用户或测试用例开发人员进行干涉，使用CANoe执行测试时都会生成一个测试记录。这样在进行伴有测试的开发时就不需要做额外的工作。用于测试记录的XML是一种开放格式，以使其它工具使用以对结果进行更深入的处理。例如在进行成熟度分析时可以使用一个测试管理系统来评价测试记录。
这项工作的本质是测试结果到测试用例、测试用例到需求的映射。使用唯一的标识符(比如一个需求ID)可以很容易地实现这一点，测试用例开发者在单个测试用例中会引用它。CANoe会自动将该标识符复制到测试记录中，这样所有测试用例、测试结果和需求就可以明确地关联起来(图4)。
图4: 测试用例和测试结果由ID明确地引用。
分析实际发生错误的原因至少与记录和评估测试结果同样重要。大多数测试工具都不会提供这样的功能或者仅提供一些并不完善的功能。一个重要原因就是错误分析经常被当作开发者的一项完全独立的任务。首先，他们面临理解测试中检测到的错误并跟踪其原因的问题。尤其是当测试实验室报告错误时，开发者甚至时常无法使用测试中用到的系统。
基于上述原因，测试台上的测试步骤以及每一个与DUT间的交互动作都将被强制记录，特别是总线通信。在分析阶段，CANoe允许重放和分析任何需要的记录（日志）。从而有可能在开发场所使用与测试台上相同的测试系统以从中受益，这
