4. 测试工程基础
商用车智能驾驶的道路测试不是“把车开出去跑一圈”那么简单。它是一套以风险为驱动、以证据为核心的系统工程活动。要让测试结果可复现、可追溯、可验收，团队必须先统一语言：什么是测试用例、什么是测试场景、什么是通过判据；再明确测试类型与测试级别；最后用合适的开发测试模型把需求、设计、实现与验证串起来。本节围绕这五个关键词展开，为后续的场景设计、数据采集、评价指标与安全评估打下共同基础。
一、核心术语：把“测什么、怎么判”说清楚
在智能驾驶测试中，最容易产生歧义的往往不是技术，而是术语。以下六个术语建议在项目启动阶段就写入测试计划并统一使用。
- 测试项（Test Item）：被测试的对象，可以是一个功能（如AEB自动紧急制动）、一个子系统（如感知融合）或整车。
- 测试用例（Test Case）：一次可执行的最小验证单元，包含初始条件、输入激励、执行步骤和预期结果。
- 测试场景（Scenario）：对测试环境的描述，包括道路、交通参与者、天气、光照、交通流等要素。场景是智能驾驶测试的“输入空间”。
- 通过判据（Pass Criteria）：判定测试是否成功的量化条件，例如“制动减速度不小于4 m/s²且未发生碰撞”。
- 覆盖度（Coverage）：已测场景占目标场景空间的比例，可分为功能覆盖、场景覆盖、代码覆盖等。
- 可追溯性（Traceability）：需求、设计、测试用例、测试结果之间的双向链接，是安全论证的关键证据链。
二、测试类型：从“怎么测”到“测什么”
测试类型回答的是“用何种手段获取证据”。商用车智能驾驶常见测试类型可按执行环境与验证目标两个维度划分。
| 测试类型 | 执行环境 | 典型目标 | 商用车示例 |
|---|---|---|---|
| 模型在环（MiL） | 纯软件仿真 | 算法逻辑正确性 | 纵向控制算法在Simulink中验证 |
| 软件在环（SiL） | 编译后代码+仿真 | 代码级功能与接口 | 感知融合模块输出目标列表 |
| 硬件在环（HiL） | 真实ECU+仿真环境 | 控制器时序与故障注入 | 制动ECU响应AEB请求的延迟 |
| 车辆在环（ViL） | 真实车辆+虚拟场景 | 底盘执行与整车集成 | 转向执行器跟踪规划轨迹 |
| 封闭场地测试 | 试验场 | 功能边界与重复性 | 40 km/h对静止目标AEB触发 |
| 开放道路测试 | 公共道路 | 真实交通流与长尾场景 | 高速匝道汇入、施工区绕行 |
这些类型不是替代关系，而是逐级递进的证据链。MiL/SiL用于早期快速迭代，HiL/ViL用于集成验证，场地与道路测试用于最终确认。跳过前序环节直接上路，会把本可在仿真中暴露的问题带到高风险环境。
三、测试级别：从部件到整车的验证层级
测试级别回答的是“在哪个层级验证”。ISO 26262与ASPICE体系下，通常分为四级：
- 部件级（Component）：验证单个传感器、执行器或算法模块，如毫米波雷达测距精度。
- 系统级（System）：验证子系统集成后的功能，如AEB从感知到制动的完整链路。
- 整车级（Vehicle）：验证车辆在真实动力学下的表现，如满载工况制动距离。
- 场景级（Scenario/Operational）：验证车辆在特定交通场景中的行为，如路口右转避让行人。
级别越高，环境越真实，但可控性与可重复性越低。工程上常用“左移”策略：把尽可能多的验证前移到低级别，用仿真和台架覆盖高频与危险场景，把宝贵的道路里程留给真正需要真实环境的验证。
四、V模型与敏捷测试理念：两种节奏的协同
V模型强调“需求—设计—实现—验证”的对应关系：左侧逐层分解，右侧逐层验证，每个开发层级都有对应的测试级别。它的价值在于可追溯性和安全完整性，适合功能安全相关的高风险项。
敏捷测试强调迭代、快速反馈和持续集成。它不否定V模型，而是把长周期的V拆成多个短周期的小V，在每个迭代内完成“需求—实现—测试”的闭环。对于智能驾驶，推荐的做法是：安全相关功能保留V模型的严格追溯，感知与规控算法采用敏捷迭代，通过自动化回归和仿真流水线实现每日构建、每日验证。
五、案例与误区：从一次AEB测试复盘说起
某商用车项目在场地测试中AEB功能表现良好，但开放道路测试时出现一次对横穿电动两轮车的漏触发。复盘发现：场地测试用例只覆盖了标准成人假人，未覆盖两轮车目标；感知模块在MiL阶段未引入两轮车数据集；需求文档中“弱势道路使用者”定义模糊，导致测试用例设计时遗漏。问题根因不在算法，而在测试术语与覆盖度管理。
改进措施包括：在需求阶段明确目标物分类；在MiL/SiL阶段引入两轮车、行人、动物等长尾目标；在用例模板中增加“目标类型”字段并统计覆盖度；在V模型右侧增加场景级验收测试，确保需求—用例—结果可追溯。
六、方法流程：从需求到证据的闭环
1. 需求分解：功能需求 → 安全需求 → 测试需求
2. 场景设计：功能场景 → 逻辑场景 → 具体场景
3. 用例生成：初始条件 + 输入激励 + 预期结果 + 通过判据
4. 级别分配：部件级 / 系统级 / 整车级 / 场景级
5. 类型选择：MiL → SiL → HiL → ViL → 场地 → 道路
6. 执行与记录：原始数据 + 日志 + 视频 + 判定结果
7. 追溯与复盘：需求ID ↔ 用例ID ↔ 结果ID，更新覆盖度
这套流程的核心是“证据链”。每一个测试结果都能回溯到具体需求，每一个需求都有对应的测试用例，每一个用例都有明确的通过判据。对于商用车而言，还要额外关注载荷状态、挂车组合、制动热衰退等特有因素，这些必须在测试级别和场景设计中显式建模。