自动驾驶测试，不止路测
一个完整的自动驾驶系统，需经历科学严谨的需求设计，加上全方位全流程的测试验证，才能进入落地量产阶段。
而自动驾驶系统的开发，包括软件、硬件、机械和系统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+项量化指标提取，通过代码测试的自动回归数据，可以计算和监控该量化指标，及时对影响系统安全性和可靠性的问题，进行监控和拦截。
许多系统层测试才暴露的问题，追根溯源，可能只是某一个代码、一个零部件或机械异常导致。
而从源头开始进行层层追溯的多维度测试，可以有效规避自动驾驶系统可能出现的潜在问题。
标签：集成,验证,系统,驾驶,硬件,自动,测试,软件 From： https://www.cnblogs.com/panlifeng/p/16806309.html