智能驾驶的测试是一个非常复杂的系统，我们用一篇文章，由小到大的逐个展开来和大家一起梳理下。在梳理之前我们先抛出一个问题，自动驾驶的测试量需要达到什么量级？根据国际一般标准统计，人类司机驾驶一小时的死亡概率约为10^6 分之一，全世界每年因道路交通事故死亡人数约有125万。自动驾驶汽车如果要发展，其死亡概率必然要远低于这个标准。根据调查，目前社会可以接受的自动驾驶一小时的死亡率须不高于10^9分之一。因此，如果要将死亡率降到10^9分之一，每更新一次软件，司机必须驾驶10^9小时，才能保证数据的效度。而驾驶10^9小时，里程将近250亿公里，需要300万辆车每天不间断的行驶一年时间，采集成本高达千亿。

显然，这种全部进行实车测试的方法并不可取。真实的测试体系往往利用了分层思想，结合多种不同成本和覆盖的测试手段，让我们可以用可控的时间和成本，近似达成类似实车测试的效果。如下图所示，不同测试方法的成本与效率都是不同的，允许迭代的次数也是有区别的。如果一个项目，软件在环的测试数量在千万级别，则硬件在环测试约在万余级别，而实车路测只有百余级别。在各自手段内可以提前发掘的潜在问题规模逐级降低，而成本却会逐级提升。如果搭配合理，则在保证极高覆盖度的同时，成本也会进入可控范围。比如如果仿真测试体系完备，则规划开发几乎无须上车验证，就可以减少大量的外围支持资源。

不同测试方法的成本与效率

多层次的测试手段搭配也并非没有代价，构建一个专项测试系统往往搭建周期长，初期成本高。无论是零部件测试中的CAE,DV,PV测试，还是软件里的静态，集成，仿真测试，常有为了追赶进度而绕过一些测试工序的情况发生。其实这是一笔经济账，当我们出于一些原因跳过了某一低成本的前道测试工序时，如果后道高成本的测试工序解决遗留问题耗费的资源高于设立前道流程的花费，就会变得得不偿失，反之亦然。合理的测试层次也是一个平衡过程。但一般而言，在一个延续性和成熟度较强的研发体系内，更多梯次且相互正交的测试体系配合高效的流转往往会达成更高的效率。

另一个测试常见的问题是执行“过于完美”的设计。如下图所示, 教科书式的把测试看成全用例，全手段的大工程其实不是非常可取，理论不错，实际的成本和收益并不高。真正有效的测试，往往是特定的工具，特定的测试用例审核被测对象特定维度的问题。任何一种测试系统，只要其针对某一类潜在问题，成本低于其他手段，覆盖问题范围又高于其他手段，则就是一个好的测试系统，并无所谓其属于哪种类型的测试系统，那都是后期被人为强行划分出来的概念。测试的设计往往没有那么多章法，务实非常重要。

工程实践过程中的测试过程

另外，测试Pipeline往往也是训练Pipeline的一部分。过去测试体系的工作主要是杜绝由于人的失误所导致的潜在产品隐患。最为我们所熟知的就是测试驱动开发（Test-Driven Development，TDD）要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动开发进行。而现在自动驾驶正在走向自监督过程，我们看到更多机器与机器之间的互动。其中也包括机器与机器之间的测试反馈和开发调整，也就是我们非常熟悉的深度学习。测试是对人的真值，也可以是对机器的真值。

最后，需要特别注意测试的自动化率和可重复性。测试以及训练Pipeline的调用一般是所有Pipeline中最高频的，因此对应Pipeline的自动化率和无人值守比例的要求也是所有数据管道中最高的，其很大程度上影响着研发成本。构建测试系统内核时，还需要特别注意对Repeatable（可重复）的要求，越靠近内部要求越高。如果测试无法复现其过去的实验结果，对后续评估会构成很大影响。如果由于多线程等原因确实无法完全保持可重复性，也需要多次实验后确认其方差与稳定性。

以上就是测试的一些基本思想，紧接着我们详细看下，目前智能驾驶有哪些典型的测试过程。如下图所示，个人认为可以从不同合作模式、不同领域专向以及不同技术断面三个方面进行系统性的梳理。

自动驾驶的常用测试手段

从不同合作模式来看，可以分为黑盒、白盒以及灰盒测试。白盒测试会检查内部结构每一条通路是否按照设计正常工作。一般用于产品提供方内部的管理。而黑盒测试一般不考虑内部结构，仅检查产品功能是否按照合同提出的技术要求实现了，一般用于被提供方的内部管理。灰盒测试介于上述两种测试程度之间，在测试外部功能的基础上，会对关键链路进行确认，一般用于提供方的发布测试或者被提供方的验收测试，具体程度视具体合作而定。

从不同领域专项来看，不同的领域有各自特有的问题及其对应的测试维度。从软件代码出发会有静态测试、动态测试等。静态测试会分析程序的语句结构、编程规范等是否有错误和不妥,常用工具包括QAC/Converity等，占整个测试体系的比重较小，一般是软件测试的第一道。与之类似的是code review其会组织相关专家对代码的静态设计做出评估。而动态测试则会比对运行程序后的结果与预期，分析运行效率和健壮性，目前自动驾驶绝大部分软件测试科目都属于动态测试范畴，比如性能测试以及各类在环测试。

从不同技术断面出发，是所有划分模式中最复杂也是最重要的。首先解释下设置断面的意义。当我们面临一个复杂多因素混合作用的系统问题时，通过设置断面，可以隔离影响变量，将复杂性简化到一个可被测试的程度，同时可以将原本串行的问题排查任务转化成并行任务，缩短项目进度。

如下图所示，最底层的是单元测试、模块测试和模块集成测试。在研发平台上（X86），将软件函数、单个或多个模块的输入输出作为断面，核心在于验证代码逻辑的正确性。通过VectorCast、GTest等工具将大量的错误输入和少量的正确输入注入被测对象，确认反馈符合预期，这个过程一般是开环的。模块级别的测试一般也被称为模型在环测试Model-in-the-Loop (MIL) 除了考虑部分正确性外，还会有一些模型性能指标比如感知模块的识别精度等。

软件逻辑层面的测试方法

一个在X86上稳定运行的软件，在嵌入式环境下可能出现堆栈溢出，调度混乱，时间戳不稳定，系统调用支持不到位，内存读取异常，运行阻塞等一系列问题。为了排查这种差异。如下图所示，在软件逻辑层面之上可以继续引入目标硬件这个维度，也就是处理器在环测试Processor-in-the-Loop (PIL)，其是将部分代码放置于目标处理器上，验证代码功能正确性的同时，确认其性能是否达到要求。比如，软件最长耗时，系统调用可靠性等。软件在环测试一般评估正确性，而硬件在环测试一般评估稳定性。

PIL测试方法

如下图所示，以上所有的测试一般都是开环的，并不会验证与环境对象的交互。当我们在软硬件的维度上增加环境闭环这个概念之后，就产生了软件在环测试SIL (Software-in-the-Loop)和硬件在环测试HIL (Hardware-in-the-Loop)的概念。引入环境要素后，还会同时引入场景库作为测试用例。测试过程除了验证基本逻辑外，还会评估一部分智能驾驶的运行服务指标。

SIL测试不考虑目标硬件，可以在服务器上大量部署，成本较低，核心用于验证智驾功能的闭环运行正确性。可以划分为使用语义级仿真系统进行的局部闭环测试，以及使用环境渲染级别仿真系统进行的软件全功能闭环测试。

HIL测试区别于SIL需要考虑目标硬件，一般不会大量部署，因为成本较高，其结果相比SIL更接近真实状态，可以额外评估软件在目标硬件上的整体性能（运行调度，内存调用，算力调用）是否符合预期。HIL测试通常将一个被测控制器和一系列模拟设备做硬线（PWM、UART、CAN、GPIO等）连接，将记录或模拟的原始数据反向构建成真实信号输入，来完成对目标硬件的测试工作。在实践过程中，个人认为，切勿执着于全功能长周期工作的HIL台架，20台轻量级HIL台架（PIL台架）的价格可能还不及1台全功能HIL台架。效果上两者对比差距却并不大。一部分物理IO，一部分功能模拟往往更为科学，HIL台架一般仅用于短周期的闭环测试，长周期测试往往会有较大误差。

SIL和HIL测试方法

完成了单控制器的测试后，智能驾驶测试会继续进入整车级别，如下图所示，首先我们要介绍的是整车在环测试VIL（Vehicle-in-Loop）或者说实车虚拟注入测试，即通过在软件内部配置断面测试接口，在封闭测试场内的实车测试环境下，屏蔽部分真实感知输入，从而在测试场内的空旷区域模拟任何形式的道路环境。比如在路上添加并不存在的车辆，或是模拟一个交叉口的信号灯切换。由于其他测试要素均为真实内容，因此测试可信度高，且可以充分利用封闭测试场的环境资源。

VIL测试方法

进一步往下，是道路在环测试RIL（Road-in-Loop）或者说假人假车参与测试。除了环境参与者和司机之外，其他全部都是真实要素。在常规汽车测试体系中，此种测试手段也是常规操作，但不同于过去人工遥控和摆放的实施手段，目前已经出现了自动化测试方案，由于最新的假人假车装备同样配置了必要的传感器，执行器与通信设备，可以接入云端集中指挥调度。因此云端的测试用例可以同步到封闭测试场内被智能假人和假车“表演”出来。大大提升完成一次测试的效率。

RIL测试方法

相比控制器级别的测试，整车级测试更关系体验下指标，比如接管率，系统稳定性，系统鲁棒性等指标。除了VIL和RIL之外，整车级别测试还有LabCar测试以及大规模实车测试，这部分内容更多和传统整车其他传统测试流程一起进行。

LABCAR测试台架

单个智驾控制器测试完成后，需要给到整车部门，在整个电子电气架构中进行测试，这个测试就被称为LABCAR测试，LABCAR测试也可以理解为几个控制器组成的硬件在环（HIL）测试。通过模拟外围传感器与执行器信息来检测整个电子电气系统是否工作正常，同时LABCAR还可以人为注入故障（短路，断路等）来检测非正常情况下反应是否符合预期。

整车测试相对于系统测试往往关注的并非单个功能，而是可能导致综合影响的共性维度。比如整车异响性能测试。在很多相关问题上，涉事零部件往往在单体台架试验、系统级台架试验上，均无法复现，仅仅只有在整车状态下的某些特殊工况下才会出现。

整车测试的一般做法就是真实路试。首先是汽车的六大基本性能，包括动力性、经济性、制动性、操稳性、通过性，都有标准客观试验做定量解析，平顺性可能涉及工程师校调，随风格会有些许差异。另外会在各种极端环境下做综合测试（高原，高寒，高温），常说的“冬天去黑河，夏天去海南”，就是这么来的。一般来说所有测试的试验条件会比正常用车条件苛刻的多，从而可以有效提升测试效率。当然还包括刚才说到的NVH性能，耐久性能等只有在整车环境下才可以进行的测试。总的来说，整车测试的核心逻辑和零部件测试类似。由于测试需要配备牌照，保险，司机以及大量其他人力和保障资源，时间和经济成本都很高。因此整车测试往往较为精炼且被严格计划。实验工况数量和测试次数会被精密计算，一般根据理论外加经验估计得到。

大规模实车测试

整车测试的另一个目的就是获得政府认可公告。中国有针对乘用车的强制检验标准，大概40余项，对于可以在市场售卖的车辆而言，这些试验是必须通过的。随着智能驾驶技术的逐步落地，智能驾驶往往也会加入整车级测试科目当中。核心原因不同于传统路侧。由于真实交通中存在中千变万化的情况，而在驾驶模拟器或者受控场地测试中只能复现很小的一部分，因此评价的结果存在着与真实情况有偏差可能性。因此，需要采用大规模路试（Field Operational Tests, FOT）来对整个交通环境进行长期影响分析。在FOT中，车辆除了配备需要评价的ADAS系统外，还需要装备摄像头、眼球追踪仪等设备对驾驶员的行为等数据进行采集，并且这些设备需要进行适当的隐藏，避免让驾驶员感觉被监视，尽量让驾驶员按照日常行驶状态行驶。当然目前这种方法已经更多的被数据闭环和众包的方式所代替。

以上就是和智能驾驶系统相关的所有测试手段的介绍，个人往往很难接触到所有这些任务，但是理解完全局，对于个人理解自己的测试任务在研发中的意义是有指导性的。