自动驾驶的测试是一个非常复杂的系统，我们用一篇文章，由小到大的逐个展开来和大家一起梳理下。
在梳理之前我们先抛出一个问题：自动驾驶的测试需要达到什么量级？
根据国际一般标准统计，人类司机驾驶一小时的死亡概率约为1/10^6，全世界每年因道路交通事故死亡人数约有125万。自动驾驶汽车如果要发展，其死亡概率必然要远低于这个标准。根据调查，目前社会可以接受的自动驾驶一小时的死亡率须不高于1/10^9。因此，如果要将死亡率降到1/10^9，每更新一次软件，司机必须驾驶10^9小时，才能保证功能的可靠性。显然，这种实车测试的方法并不可取。
真实的测试体系往往利用了分层思想，结合多种不同成本和覆盖角度的测试手段，让我们可以用可控的时间和成本，近似达成类似实车测试的效果。不同测试方法的成本是不同的，合理迭代次数也是有区别的。一个拥有合理测试体系的项目，模块逻辑测试必须规避60%以上的潜在问题，仿真功能性能测试则要解决30%的剩余潜在问题，而留给实车鲁棒性测试最多10%。在各自手段内尽可能的发现潜在问题，控制后道测试手段的问题量，如果搭配合理，则在保证极高覆盖度的同时，成本也会进入可控范围。比如如果仿真测试体系完备，则规划开发几乎无须上车验证，就可以减少大量的外围支持资源。
不同测试方法的对比
多层次的测试手段搭配也并非没有代价，构建一个专项测试系统往往存在搭建周期长，初期成本高的问题。无论是零部件测试中的CAE,DV,PV测试，还是软件里的静态，集成，仿真测试，常有为了追赶进度而绕过一些测试工序的情况发生。
其实这是一笔经济账，当我们省略了某一前道测试工序时，如果后道高成本的测试工序解决前道工序遗留问题时所耗费的资源，要高于设立前道流程的花费，整个测试体系就会变得得不偿失，反之亦然。
合理的测试层次也是一个平衡过程。
但一般而言，在一个延续性和成熟度较强的研发体系内，更多梯次且相互正交的测试体系配合高效的流转往往会达成更高的效率。
真正有效的测试，往往是使用特定的测试工具和特定的测试用例，审核被测对象特定维度的问题。任何一种测试系统，只要其针对某一类潜在问题，成本低于其他手段，覆盖问题范围又高于其他手段，则就是一个好的测试系统，并无所谓其属于哪种类型的测试系统，那都是后期被人为强行划分出来的概念。在测试的设计中，务实非常重要。
工程实践过程中的测试过程
另外，测试Pipeline往往也是训练Pipeline的一部分。过去测试体系的工作主要是杜绝+由于人的失误所导致的潜在产品隐患。
最为我们所熟知的就是测试驱动开发（Test-DrivenDevelopment，TDD），其要求在编写某个功能的代码之前先编写测试代码，然后只编写使测试通过的功能代码，通过测试来推动开发进行。
而现在自动驾驶正在走向自监督过程，我们看到更多机器与机器之间的互动。其中也包括机器与机器之间的测试反馈和开发调整，也就是我们非常熟悉的深度学习。对人而言，测试是为了保证产品和目标一致。对机器而言，训练也是为了达成类似的目的。
以上就是测试的一些基本思想，紧接着我们详细看下，目前智能驾驶有哪些典型的测试过程。如下图所示，个人认为可以从不同合作模式、不同领域专向以及不同技术断面三个方面进行系统性的梳理。
自动驾驶的常用测试手段
从不同合作模式来看，可以分为黑盒、白盒以及灰盒测试。
白盒测试会检查内部结构每一条通路是否按照设计正常工作，一般用于产品提供方内部的管理；黑盒测试一般不考虑内部结构，仅检查产品功能是否按照合同提出的技术要求实现了，一般用于被提供方的内部管理；灰盒测试介于上述两种测试程度之间，在测试外部功能的基础上，会对关键链路进行确认，一般用于提供方的发布测试或者被提供方的验收测试，具体程度视具体合作而定。
从不同领域专项来看，不同的领域有各自特有的问题及其对应的测试维度。
从软件代码出发会有静态测试、动态测试等：静态测试会分析程序的语句结构、编程规范等是否有错误和不妥,常用工具包括QAC/Converity等，占整个测试体系的比重较小，一般是软件测试的第一道，与之类似的是codereview其会组织相关专家对代码的静态设计做出评估；而动态测试则会比对运行程序后的结果与预期，分析运行效率和健壮性，目前自动驾驶绝大部分软件测试科目都属于动态测试范畴，比如性能测试及各类在环测试。
从不同技术断面出发，是所有划分模式中最复杂也是最重要的。
首先解释下设置断面的意义。当我们面临一个复杂多因素混合作用的系统问题时，通过设置断面，可以隔离影响变量，将复杂性简化到一个可被测试的程度，同时可以将原本串行的问题排查任务转化成并行任务，缩短项目进度。
如下图所示，最底层的是单元测试、模块测试和模块集成测试。在研发平台上（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测试不考虑目标硬件，可以在服务器上大量部署，成本较低，核心用于验证智驾功能的闭环运行正确性。可以划分为使用语义级仿真系统进行的局部闭环测试，以及使用环境渲染级别仿真系统进行的软件全功能闭环测试。
SIL是目前最有潜力的测试手段之一，因此我们做一个简单展开。单元测试、模块测试等方法虽然自动化率高，但不能直接发现智驾系统的功能性问题。而硬件在环测试、实车测试等虽然问题发现更为直观，但成本较高。而SIL在这些方法之间取得了不错的平衡，是一种性价比很高的手段。SIL系统从内部看核心要确保可重复性。如果测试无法复现其过去的实验结果，对后续评估会构成很大影响。如果由于多线程等原因确实无法完全保持可重复性，也需要多次实验后确认其方差与稳定性。从整个测试体系看，越靠近内部（比如单元测试），则越容易控制可重复性，而越靠近外部（比如实车测试），就越难控制。从SIL系统的外部看核心是自动化率和大规模并行部署的能力，作为整个测试体系当中综合分析来说规模最大的测试手段。减少人工和提高并发部署能力可以有效降低测试成本，并提高测试效率。SIL系统在智能驾驶的闭环体系下，除了测试，也开始为规划的迭代训练服务。我们在仿真测试中进行的安全评估、功能评估、法规要求评估、舒适性评估等所使用的指标和用例，其实也都是规控训练过程中的一种“损失函数”。
HIL测试区别于SIL需要考虑目标硬件，一般不会大量部署，因为成本较高，其结果相比SIL更接近真实状态，可以额外评估软件在目标硬件上的整体性能（运行调度，内存调用，算力调用）是否符合预期。HIL测试通常将一个被测控制器和一系列模拟设备做硬线（PWM、UART、CAN、GPIO等）连接，将记录或模拟的原始数据反向构建成真实信号输入，来完成对目标硬件的测试工作。在实践过程中，个人认为，切勿执着于全功能长周期工作的HIL台架，20台轻量级HIL台架（PIL台架）的价格可能还不及1台全功能HIL台架。效果上两者对比差距却并不大。一部分物理IO，一部分功能模拟往往更为科学，HIL台架一般仅用于短周期的闭环测试，长周期测试往往会有较大误差。
SIL和HIL测试方法
完成了单控制器的测试后，智能驾驶测试会继续进入整车级别，如下图所示，首先我们要介绍的是车辆在环测试VIL（Vehicle-in-Loop）或者说实车虚拟注入测试，即通过在软件内部配置断面测试接口，在封闭测试场内的实车测试环境下，屏蔽部分真实感知输入，从而在测试场内的空旷区域模拟任何形式的道路环境。比如在路上添加并不存在的车辆，或是模拟一个交叉口的信号灯切换。由于其他测试要素均为真实内容，因此测试可信度高，且可以充分利用封闭测试场的环境资源。
VIL测试方法
另一种VIL的全新形态是实车交通环境在环测试（VTEHIL），在室内场地构建模拟的周边环境变化以及车辆移动，来进行智能驾驶车的测试。由于环境完全受控，不受到气候变化影响，可实现24小时连续测试，并且可以高效且完整模拟极端工况。
VTEHIL测试方法
进一步往下，是道路在环测试RIL（Road-in-Loop）或者说封闭场地测试。除了环境参与者和司机之外，其他全部都是真实要素。
在常规汽车测试体系中，此种测试手段也是常规操作，但不同于过去人工遥控和摆放的实施手段，目前已经出现了自动化测试方案，由于最新的假人假车装备同样配置了必要的传感器，执行器与通信设备，可以接入云端集中指挥调度。因此云端的测试用例可以同步到封闭测试场内被智能假人和假车“表演”出来。大大提升完成一次测试的效率。
RIL测试方法
相比控制器级别的测试，整车级测试更关系体验下指标，比如接管率、鲁棒性等指标。除了VIL和RIL之外，整车级别测试还有LabCar测试以及大规模实车测试，这部分内容更多和整车其他传统测试流程一起进行。
LABCAR测试台架
单个智驾控制器测试完成后，需要给到整车部门，在整个电子电气架构中进行测试，这个测试就被称为LABCAR测试，LABCAR测试也可以理解为几个控制器组成的硬件在环（HIL）测试。通过模拟外围传感器与执行器信息来检测整个电子电气系统是否工作正常，同时LABCAR还可以人为注入故障（短路，断路等）来检测非正常情况下反应是否符合预期。
整车测试相对于系统测试往往关注的并非单个功能，而是可能导致综合影响的共性维度。比如整车异响性能测试。在很多相关问题上，涉事零部件往往在单体台架试验、系统级台架试验上，均无法复现，仅仅只有在整车状态下的某些特殊工况下才会出现。
整车测试的一般做法就是开放道路测试。首先是汽车的六大基本性能，包括动力性、经济性、制动性、操稳性、通过性，都有标准客观试验做定量解析，平顺性可能涉及工程师校调，随风格会有些许差异。另外会在各种极端环境下做综合测试（高原，高寒，高温），常说的“冬天去黑河，夏天去海南”，就是这么来的。一般来说所有测试的试验条件会比正常用车条件苛刻的多，从而可以有效提升测试效率。当然还包括刚才说到的NVH性能，耐久性能等只有在整车环境下才可以进行的测试。总的来说，整车测试的核心逻辑和零部件测试类似。由于测试需要配备牌照，保险，司机以及大量其他人力和保障资源，时间和经济成本都很高。因此整车测试往往较为精炼且被严格计划。实验工况数量和测试次数会被精密计算，一般根据理论外加经验估计得到。整车测试的另一个目的就是获得政府认可公告。中国有针对乘用车的强制检验标准，大概40余项，对于可以在市场售卖的车辆而言，这些试验是必须通过的。
大规模实车测试
大规模开放道路测试对于智能驾驶系统来说也是必须的，原因和传统路测略有不同。由于真实交通中更加千变万化，而驾驶模拟器或者受控场地测试只能复现很小一部分，评价的结果可能与真实情况有偏差。因此需要大规模路试来对智能驾驶汽车在整个交通环境中的运行进行验证。在开放道路测试中，功能数据、行为数据、环境数据都要同步采集。功能数据往往来源于智驾系统本身。行为数据核心是监控司机反应，来源于额外安装的内部摄像头、眼球追踪仪、生理检测设备。而环境数据会同时来源于车辆自身的环境传感器以及一些额外安装的性能更高的传感设备，比如激光、ins或者高清相机。当然目前这种方法已经更多的被数据闭环的方式所代替
以上就是和智能驾驶系统相关的所有测试手段的介绍，个人往往很难接触到所有这些任务，但是理解完全局，对于个人理解自己的测试任务在研发中的意义是有指导性的。
