介绍 测试是汽车开发过程中的一个重要部分。随着软件越来越多地被应用于现代汽车，对严格软件测试方法的需求也变得越来越多。一个一直被忽略的特殊方面是：具有很多独特特色的商用车领域的软件测试的实践。 本文是对商用车领域软件测试的第一个全面的研究。但是，许多特征和相关结果可以外推到汽车行业的其他部分，而且更广泛地，还可以外推到嵌入式系统领域。我们通过对用于汽车行业的26工具和欧洲市场的20个工具/服务提供商的调查研究了现行做法。最后，还预测了未来潜在机会的一些方向。 本文希望能给汽车行业从业人员提供现被用于汽车领域的软件测试工具和服务的深刻见解。 由于本文重点是商用车领域，工具/服务提供商可以熟悉这一领域的潜在机会。 最后，对学生和研究人员来说，了解汽车嵌入式软件测试是如何在实践中进行的，及塑造汽车行业的新概念有哪些或许也挺有意思的。商用车领域 2.1定义 欧盟根据其结构及设备类型的设计目的来定义”商用车”，能够运载：a）超过九人，包括司机在内；b）货物和标准油箱[ 1 ] 的任何机动道路车辆都属于”商用车”。 轻型商用车（ LCV ）是车总重≤3.5吨的商用车的欧盟正式术语，符合该类别的车辆有面包车，小巴和轻型卡车等；重型商用车（ HCV）是车总重>3.5吨的商用车的欧盟正式术语，符合该类别的车辆有货车，卡车，油罐车等。HCV的一个更广泛的定义里还包括农用车辆（拖拉机，收割机等），及施工车辆（岩石钻机，推土机，轮式装载机等）在内的重型设备和机械。 本文的研究范围涵盖了轻型和重型商用车。 2.2市场规模和潜力 商用车辆占有了汽车行业的一个具体且不可忽略的市场份额。按照ACEA （欧洲汽车制造商协会）数据显示，2012年全世界生产的超过20万台的商用车占据了欧盟市场11.3％的份额。较2011年，2012年欧盟产的LCV / HCV出口收入增加了22.9 ％[3] 。 同样， Frost＆Sullivan公司[ 2 ]指出，欧洲对轻型商用车的需求已经远远超过其他大洲。特别是混合商用车，在不久的将来将占据主要市场份额。一直会用到大约2016年的大多数混合LCVs将包括梅赛德斯－奔驰Sprinter和福特Transit Connect的电动版本。这两款车型有望占据欧洲混合轻型商用车市场的三分之一。 不看生产数据统计，伴随着全世界24%的年复合增长率[ 2 ]，所有主要地区均有望保持商用车远程信息技术的增长速度。 2.3质量保证的挑战概述 在现代汽车的发展趋势已从纯机械转向广泛地电子化。 一辆典型现代汽车里的电子控制单元（ECU）粗略估计大约有70个，包括100多万的目标代码指令和近1 GB的软件[ 4 ] 。 这一趋势也反映在商用车的发展中。对嵌入式控制器越来越多的使用已或多或少地充当了商用车远程信息的催化剂。 这类车的价值创造主要是由嵌入式软件决定的，这不仅增加了成本和复杂性的，还增加了嵌入式软件的潜在缺陷。机械缺陷逐渐减少的同时，电子系统造成的缺陷却正在迅速增加[ 5 ] 。传动、线控、导航、人机工程学和信息娱乐类技术的进步要求嵌入式系统方法中有严格的质量保证措施。全球汽车业也普遍如此。 但是，商用车行业尤其受到旨在提高环境保护，安全（ ISO 26262/IEC 61508 ）和质量保证措施（ IEEE 610 ） [ 9 ]的严格法规的影响， 。 为了满足当下目标，就要完全更新换代正在开发中的发动机，底盘和车身。所需解决的问题是：应该在商用车先进的嵌入式系统中使用什么样的，以及如何运用恰当的质量保证策略。 3．视觉测试领域特征 本节从测试的角度来描述：商用车领域的特征是相当重要的。 3.1安全性高要求 安全性是商用车的一个极其严格的要求。 欧洲道路评估计划的目的是：到2020年，要把欧洲交通事故的概率减少到零死亡。——该项目被称为Vision Zero。相关的标准，如ISO 26262 [ 9 ] ，也对汽车行业施加压力，使之为了让工程道路更安全去开发协议，工具和最佳实践准则。 还有一些其他专门针对商用车的安全措施。例如，重型卡车对由于开车时不经意地超出侧翻阈值而直接造成的翻车事件要多加注意。因此，制造商已经投入了相当多的时间和资源建立安全措施（例如：翻滚稳定控制系统）以应付重型商用车的这种情况。 3.2可靠性高需求 可靠性关注的是系统中故障率的量化。软件可靠性是一定执行时间内软件不会失败的概率。 迄今为止在汽车领域，相较于其他嵌入式系统领域如航空电子设备[4]，可靠性并未受到正式管理。 此外，商用车应该在艰苦的，安全性很苛刻的环境下也能正常工作，如重型卡车装载数吨燃料，岩石钻机钻探不规则表面。因此，低可靠性会导致运行过程中出现危险情况。 他们的预期寿命要比正常客车长。所有这些情况都对车辆的可靠性和耐用性附加了要求。 3.3实时电子控制单元（ECU）功能 商用车嵌入式系统的复杂性很大程度上是因为大多数汽车系统的其它类并不正视实时性和界面限制。 对汽车软件工程实践的研究[ 4 ]表明，大部分车辆功能是由硬质和软质实时任务实现的。 极端情况下，多达95 ％的功能由硬实时任务模拟，最有可能是商用车，因为对于商用车，像具有离散事件软实时功能的多媒体功能和人体舒适感功能并不太重要。 此外，要求不软不硬但有时又介于两者之间的功能，往往模拟为硬质[ 4 ]的 。典型的要求包括任务间的优先关系和抖动。 时间限制，例如截止时限在单个应用程序中可以变化多达三个数量级，通常从毫秒到几秒。 这方面的测试是极具挑战性的，因为一个系统的正确性不仅取决于其逻辑正确性，还取决于结果生成的确切时间。 往往很难追踪和再现错误，因为这需要对决定何时模拟系统及何时期望反应有很高的精确度。 3.4交错配置及变体
商用车的产品体积通常比客车小。而且，用户往往对诸如发动机扭转力，有效载荷等[5]技术规范要求更多。因此，汽车制造商经常用产品变体满足更大的客户群，从而增加市场份额及产品生产量。所以，商用车辆的嵌入式系统包括来自多个供应商的组件，且存在于大量的配置和变体里。
这就导致了为了覆盖庞大的产品变体而进行的测试活动方面的巨大的工作量。
3.5分布式开发
由于商用车部件变体的不一致性，汽车制造商不可能开发其所有的内部产品。相反，他们更愿意依赖第三方供应商成熟的专业知识。
由于这个原因，部分还因为严格的成本要求，商用车的发展在很大程度上被分散和外包[ 6 ]了 。这就形成了许多供应链关系使得规范最新及各级一致很困难。
事实上，制造商最终也没能在一个“黑盒”元件的内部设计出什么细节[4]。这就增加了定位单元和集成层次的组件测试误差的复杂性。
4 .汽车软件测试实践
本节概述了汽车软件测试里的实践情况。
本研究着眼于商用车领域，但本节的研究结果适用于整个汽车行业。
请注意，本节中的经验仅限于汽车行业主要名人们使用的主流做法。还有其他一些包括研究和技术创新的做法，被排除在本研究之外。
这里，我们的目的是提供一些明确的汽车行业的主要做法。
4.1基于模型的开发和测试
根据作者与主要汽车制造商、供应商合作的经验，现代汽车开发过程中模型驱动工程有着强劲的发展势头。这包括开发过程的各个阶段，即从需求到验证。
模型是表示系统行为一部分的一个抽象视图。
工程师很早期就使用特定领域建模技术为系统行为建模，使他们能够通过模型自动生成代码并在实施前测试系统，快速开发系统。
基于模型的测试的基本思想是：应用选定的算法由模型[13]自动生成测试，而不是手动创建测试用例。
除了自动化程度高，基于模型的测试还有助于由抽象层面来维持系统模型间的可追踪性并由系统执行层面来测试输出间的可追踪性。这就使得错误的来源容易追踪，也降低了整体测试活动的精力和成本。
4.2循环X测试水平
基于模型的开发和测试的不同阶段是用汽车SPICE开发标准所推荐的V模型（见图1）手动描述的。
V模型通常被设计来进行符合开发流程的不同水平的测试工作。
这些水平的测试被称为循环模型，循环软件，循环处理器（HIL）和循环硬件（又名循环X [ 7 ] ）测试，说明如下。
MIL （循环模型） ：
MIL提供可用系统（或子系统）模型的测试，且该模型及其环境没有任何物理硬件就可以进行仿真模拟。该系统的输入、输出界面被定义为关于不同的测试场景。
输入信号值进行了模拟，且相应的输出信号值与在该场景中定义的预期值进行了比较。
很早期甚至早在实施之前，MIL测试就可以进行系统的功能验证。
由于在同一台机器上的模型和环境类似，所以就不需要实时硬件了。
SiL（循环软件） ：
SIL进行可执行代码段（或实施段）的测试。
在同一个机器上的操作情况相似。因此，此水平不需要实时硬件。
所有关于存储容量，数据结构等的细节都是由被模拟的环境控制的。这确保了任何“运行时错误”（缓冲区溢出，除以零，非法类型转换错误等）在实施时的检测。
此外，它还使系统行为可以通过运行MIL里同样的测试场景对模型进行验证。
PIL （循环处理器） ：
PIL确保在目标处理器或目标处理器模拟器上运行时，可以测试实施过程。
执行环境通常仍是通过一个专用的实时仿真器模拟的。
这个阶段的故障可以与目标编译器（联动，优化选项，等等）或目标处理器架构联系起来。
MIL和SIL的测试场景在这可以用来与原结果进行比较，确保代码功能正确，即使是在它已被编译并在目标处理器上运行后。
HiL（循环硬件） ：
HiL使现被嵌入实际硬件（ECU）中的实施得以被测试。这是通过把ECU和一个专用的实时仿真器连接起来完成的，此仿真器阐明了ECU对分析结果的测试环境的实际输入/输出。
ECU用来交流的嵌入式系统的其他部分仍然可以被模拟。
然而，它们与真实的电子信号进行交互。
HiL里的测试可以在实时环境中分析代码和硬件集成。
此水平的故障，也与输入/输出界面间的低水平通信，与嵌入式系统的其他部分的实时通信有关。
MIL和SIL的测试场景可以用来验证先前观察到的系统行为。
图1. V模型阐明循环X测试阶段