2. 自动驾驶测试基础
自动驾驶测试不是“把车开上路跑一跑”这么简单。它需要先明确被测对象处于什么自动化等级、由哪些系统模块构成、要验证哪些类型的需求，再把这些验证活动嵌入到工程研发流程中。理解这四件事——分级、架构、测试类型、测试流程——是后续学习场景覆盖与回归测试工程的前提。
一、自动驾驶分级：决定测试边界与责任主体
SAE J3016 将驾驶自动化分为 L0 到 L5 六个等级，核心区分维度是“动态驾驶任务（DDT）由谁执行、谁负责监控、谁作为兜底”。L0–L2 属于辅助驾驶，驾驶员始终是责任主体；L3 是有条件自动驾驶，系统在限定运行域内执行 DDT，但驾驶员需在请求时接管；L4 在限定运行域内系统可完成 DDT 与兜底；L5 则无运行域限制。
分级直接决定测试策略。L2 的测试重点是“人机共驾边界”，例如脱手检测、接管提示；L3 必须重点验证接管请求的提前量、最小风险状态（MRM）能否达成；L4 则要验证运行域（ODD）边界的识别与退出策略。若把 L2 的测试方法直接套用到 L4，会遗漏大量系统失效与降级场景。
二、系统架构：测试对象的层次划分
典型自动驾驶系统可划分为感知、定位、预测、规划、控制、执行与整车平台等层次。感知层输出目标与车道线，定位层提供位姿，预测层估计他车意图，规划层生成轨迹，控制层输出油门、制动、转向指令，执行层由线控底盘完成动作。测试必须按层次展开：
- 传感器层：摄像头、毫米波雷达、激光雷达的原始数据质量、标定与同步。
- 感知融合层：目标检测、跟踪、分类的精度与漏检、误检。
- 决策规划层：轨迹合理性、舒适性、交规符合性、博弈交互。
- 控制执行层：跟踪误差、响应时延、线控冗余。
- 整车与系统层：功能安全、预期功能安全、网络安全与整车集成。
三、测试类型：从模型到实车的连续谱
自动驾驶测试通常按“被测对象真实度”和“环境真实度”两个维度组织，形成从纯软件到实车的连续谱。常见类型包括：
| 测试类型 | 被测对象 | 典型工具/环境 | 主要目的 |
|---|---|---|---|
| 模型在环 MIL | 控制/规划算法模型 | Simulink、Python | 算法逻辑正确性 |
| 软件在环 SIL | 编译后的软件 | 仿真机、CI 流水线 | 代码级功能验证 |
| 硬件在环 HIL | ECU/域控制器 | dSPACE、NI、CarSim | 实时性与接口验证 |
| 车辆在环 VIL | 整车或底盘 | 转鼓、台架 | 执行器与整车集成 |
| 封闭场地测试 | 实车 | 试验场、假人假车 | 典型场景功能确认 |
| 开放道路测试 | 实车+安全员 | 公共道路 | 真实交通长尾暴露 |
这些类型不是替代关系，而是逐级筛选关系。越靠左成本越低、可重复性越高，适合早期快速迭代；越靠右真实度越高、成本越高，适合最终确认。工程上常用“左移”策略，把尽可能多的问题在 MIL/SIL 阶段拦截。
四、测试流程与 V 模型：场景测试的位置
V 模型左侧是设计分解，右侧是集成验证。需求从整车级分解到系统、软件、组件；右侧则从组件测试逐级集成到系统、整车。场景测试并非只出现在某一层，而是贯穿整个 V 模型：
- 左侧需求阶段：从 ODD、法规、事故数据中提取场景需求，形成场景库与覆盖目标。
- 组件/软件层：用 SIL 回放场景片段，验证感知、规划模块。
- 系统层：用 HIL 注入传感器数据与故障，验证系统响应。
- 整车层：在场地与道路执行场景用例，确认整车行为。
- 右侧确认阶段：用场景覆盖率、通过率、回归结果反向确认需求是否被满足。
下面这张图展示了场景测试在 V 模型中的分布与数据流关系：
从图中可以看到，场景库位于 V 模型底部，同时向左右两侧供给：左侧需求驱动场景生成，右侧测试结果反向反馈回归。这正是“场景覆盖与回归测试”在工程流程中的核心位置。
五、常见误区与复盘
误区一：把分级当标签，不区分 ODD。同样是 L4，园区低速与高速干线对感知距离、接管策略的要求完全不同，测试用例不能通用。
误区二：只做 HIL 不做 SIL。HIL 资源紧张、排队周期长，大量边界用例应在 SIL 阶段先跑通，否则会拖慢迭代。
误区三：场景测试只在整车阶段做。场景应作为需求资产在 V 模型左侧就定义，并逐层复用，否则右侧只能“凭经验试”。
误区四：用通过率代替覆盖率。通过率高不代表覆盖了关键长尾，必须同时看场景覆盖维度与参数边界。
复盘时建议回答三个问题：当前测试处于 V 模型哪一层？该层对应的场景来源是什么？失败用例是否已回流到场景库并触发回归？把这三个问题固化到测试流程中，场景测试才能真正成为可管理、可追溯、可回归的工程活动。