欧洲商用车领域中软件测试（一）

作者：Muzammil Shahbaz(泽众软件原创翻译) 发布时间：[ 2014/3/13 14:46:20 ] 推荐标签：软件测试组件测试系统测试

　　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的测试场景可以用来验证先前观察到的系统行为。