在汽车嵌入式系统中^[SZ05]质量保证的一个核心就是“车载测试”或者“道路测试”。道路测试，实际上应该被用于校准控制参数，并验证整车，但是却常被误用作寻找软件相关的规定、设计与实施错误^[Sim97]。道路测试占用了大量的时间和精力。针对一个单一的控制单元进行数百万公里的行驶测试并不是不普遍。此外，道路测试通常发生在控制研发的关键阶段（就时间而言），因为它们通常在系统研发的最后阶段进行。在那个时候，误差修正的平均成本已经非常高了。由于相当大的时间和成本压力，因此通常要在早期市场引进和取得的测试深度之间进行协调。其结果造成嵌入式系统开发与实施过程中的错误被发现得太晚，甚至到了消费者才被发现^[Sim97]。

与道路测试相比较，在软件研发过程中针对“软件系统测试”的方法和步骤的应用，能够更早、更有效地检测与软件相关的差错。然而，这需要以实用为导向的、把一般的测试技术与方法改成适应具体应用域的测试技术和方法。为了确保高效率，测试应该在研发过程中进行，而不是仅仅在研发结束的时候进行。

然而，我们经常可以观察到的是如今的汽车检测控制软件的测试遵循“直觉的方法”，这导致了测试差距和测试冗余。

因为在实践中不可能做到详尽的测试，所以动态测试始终是一个抽样步骤。尽可能小且尽可能多地揭示测试对象差错的测试方案子集，需要从所有可能的测试方案的无限集合中选择。如图11.1所示，充足的样本元素（测试方案）的选择决定了整体测试的内容与质量。

图11.1 输入域、差错和测试方案(www.daowen.com)

在图11.1中，测试对象的输入域用一个矩形黑框表示，灰色区域（如①和②）表示差错子域。由测试方案覆盖的那部分输入域用圆圈表示。如果测试方案落在灰色区域内（如④），那么这意味着它是一个揭示差错的测试方案，否则它是一个不揭示差错的测试方案（如③）。

由于选择过程具有特殊的意义，所以当设计足够多的测试方案时，存在需要支持测试者的“系统测试设计”技术。应用这些测试技术系统化了测试方案的选择，并使其易于理解与可重复^[Sim97]。

当测试汽车控制软件时，“特定选择测试方案”是典型的，也就是说测试方案是在没有（明确）定义步骤的情况下确定的。实际测试方案的选择取决于测试者的经验和专业技能，且复制困难——就算真的能复制。选择特定的方案一方面导致测试方案或多或少有多余（图11.1中右上方），另一方面也导致了测试差距（图11.1中左下方）。此外，“每次一个单因素试验”是典型的，也就是说只有单因素变量改变引起实验结果变动（在图11.1中，测试方案的布置就像一条线上的珠子）。作为一项规则，这样不可能对特定测试方案做出有关质量和完整性的说明。就测试方案的数量而言，它们的差错检测等级水平往往不足。

那些有条不紊、有理有据且在一般软件工程中存在的软件测试设计技术，往往定制适应行政管理或科学的软件。它们不能充分适应汽车嵌入式控制系统的细节，因此，它们像上面那样进行（技术）转移。特别是测试方案的时间因素不能合理考虑进来。