一个完整的自动驾驶系统，需经历科学严谨的需求设计，加上全方位全流程的测试验证，才能进入落地量产阶段。

而自动驾驶系统的开发，包括软件、硬件、机械和系统4层开发流程。每一层也都遵循“需求-设计-实现-测试”4个小V模型。

路测只是系统层测试的最后一环节。要保障最终系统满足需求，按设计正确实现，首先要确保硬件、软件和机械层都符合要求，正确实现。

测试是一种有效验证的方式，为此，大疆车载在满足ASPICE、SPICE for ME/EE等行业流程标准的基础上，建立了4个层级9个测试过程域，测试覆盖率100%的测试体系。

* ASPICE：Automotive Software Process Improvement and Capacity determination汽车软件过程改进及能力评定

* ISO 26262《道路车辆功能安全》国际标准，是以安全相关电子电气系统特点所制定的功能安全标准，也是第一个适用于大批量量产产品的功能安全标准

1.

路测不仅具有随机性和偶发性，且测试重点在系统功能层，难以全面暴露底层缺陷。

即使全天候全时段24小时不间断路测，也不一定能测试出非系统层的小概率异常问题。

而往往是小概率问题，可能带来系统的功能故障或失效，进而导致人员伤害或更严重的事故后果。

秉着安全第一的首要原则，大疆车载的做法是尽可能从源头规避问题的产生。

在测试体系下，我们从一行代码和一个零部件，到最终的量产路测，做到全流程的测试覆盖和问题的层层拦截。

2.

硬件是自动驾驶系统实现的基石，地基是否牢稳，很大程度决定了上层建筑是否安全可靠。

硬件层测试即是为了确保硬件在各种条件下，都能稳定运行。

# 硬件层测试

2.1 硬件设计测试验证

主要针对硬件电路电气特性的测试，验证电气等指标是否满足电路正常工作的要求。

2.1.1 信号完整性测试

如在高低温环境下，对DDR（内存）进行数字眼图测试，确保在极端环境下，信号质量仍满足要求。

结合高速信号仿真和眼图实测，对标印证测试结果。

2.1.2 电源完整性测试

电源的供电稳定性和快速响应能力，直接影响系统的正常稳定运行。

除了常规的电源参数测试，如噪声、纹波、时序测试等，我们还会对主板上所有开关电源进行环路响应测试，验证电源是否满足系统运行需求。

2.2 硬件合格性测试

将整个硬件部件作为测试对象，测试其是否满足系统分解下来的硬件功能需求，确保硬件能长时间稳定可靠运行。

2.2.1 硬件功能测试

如故障失效模拟测试中，我们列举了可能导致硬件故障的100+项失效类型，如启动故障、过压失效、DDR失效等。

提前测试硬件在失效模式下，给出故障指示信号的响应时间和行为，确保系统能正确识别故障类型并及时反应。

2.2.2 硬件可靠性测

对硬件是否能长时间可靠运行进行测试，如使用温箱快速温变，通过极限温度变化，进行高加速寿命测试，加速硬件尽早暴露问题。

或进行电压-温度两个维度四角测试，覆盖各种极端使用场景，探索工作温度的边界。

3.

坚实可靠的机械部件，可以为系统提供一个稳定安全的实现环境。

通过对机械部件的多种性能进行测试，尽量确保其在各种条件下，都能支撑系统正确实现。

# 机械层测试

3.1 机械设计测试

主要针对零部件和产品的机械设计进行测试，包括各种参数、接口配合、集成装配等，保障机械零部件和产品与机械设计的一致性。

3.1.1 集成测试

在机械的集成过程中，对相关部件或组件的装配性能进行测试，确保集成装配工艺的稳定性和可行性。

3.1.2 零部件测试

如在光学镜头性能测试中，我们会针对镜头OTF（Optical transfer function，光学传递函数）、TTL（Total Track Length，镜头总长）、透光率、光圈、畸变等性能进行测试，确保最终产品性能符合设计需求。

3.2 机械合格性测试

针对集成组装完成的产品或总成（集合体，实现一个特定功能的零部件系统总称）进行测试，确保产品的散热性能、防水防尘、材料使用要求等方面符合机械需求。

3.2.1 实车安装测试

在组装完成后，我们会对机械的多种特性进行实车安装验证。

如实车热测试，在真实运行环境中，检测产品在极端温度环境下的实际散热能力。

3.2.2 产品噪音测试

机械噪音是产品的一个特殊测试需求。

我们会模拟产品在车上正常工作的状态，进行噪音测试，检测在振动频率等不同条件下，噪音等级的变化情况。

4.

软件在自动驾驶系统中的占比之重，意味着软件层测试更不容轻视。

从每一行代码的编码规范，到整个软件模块的集成验证，将层层确保软件实现与软件需求设计一致。

# 软件层测试

4.1 软件单元验证

除了常规的单元测试，我们还将单元验证细分为多个维度的测试。目前已在百万行代码上完成相关单元验证。

4.1.1 编码规范检测

基于MISRA C：2012，C++和AUTOSAR C++ 14等行业标准，完成并统一了编码规范要求，提高了代码的可读性和可维护性。

4.1.2 软件质量度量

在完成代码静态检查的基础上，我们定义了一些软件质量度量指标，如圈复杂度（v(G)）小于10、函数嵌套调用深度（LEVEL）小于4、函数定义的参数数量（PARAM）小于5等，来进一步评估软件代码的质量。

4.1.3 单元测试

从函数典型应用场景测试运行是否正确，异常（输入异常，运行环境异常等）是否被测试等维度进行测试。

目前已实现功能安全等级为A/B/C相关代码100%分支覆盖，功能安全等级为D的相关代码100%修正判定条件覆盖。

4.2 软件集成和集成测试

代码编写完成，进入软件集成阶段，需测试验证集成后的运行是否与架构设计一致。

4.2.1 时序测试

时序图是架构设计的一种常用工具，用来描述软件对象交互行为的时间顺序。

我们会对其进行设计验证和异常验证，包括测试模块间消息请求及响应时长是否符合需求、或基于异常做故障注入，来测试其对异常的处理是否符合预期等。

4.2.2 数据结构测试

测试各软件模块间传输的数据结构、数据类型、数据范围和正确性等内容，保障不同模块间的正确交互。

4.3 软件合格性测试

自动驾驶系统包含很多软件模块（如环境感知、决策规划、车辆控制等），我们会针对不同软件模块的特性，调整测试重点，对其正确性、安全性和可靠性，进行精准有效测试。

4.3.1 车位感知测试

大量的系统失效是由于感知的漏检/误检导致，此时测试重点比起是否100%覆盖需求，更重要地是探索因算法和传感器性能局限，带来的有效感知边界。

我们会针对影响感知检测效果的因素，在系统层测试前对感知进行测试评估。

4.3.2 规划控制测试

规划控制模块与系统的安全性和舒适性密不可分。

我们对规划控制的测试结果，进行了10+项量化指标提取，通过代码测试的自动回归数据，可以计算和监控该量化指标，及时对影响系统安全性和可靠性的问题，进行监控和拦截。

 

许多系统层测试才暴露的问题，追根溯源，可能只是某一个代码、一个零部件或机械异常导致。

而从源头开始进行层层追溯的多维度测试，可以有效规避自动驾驶系统可能出现的潜在问题。