4. 测试场景设计
Robotaxi 的道路测试与运营验证，本质上不是“跑够多少公里”的问题，而是“跑过多少种有意义的情形”。测试场景设计就是把无限的真实世界，压缩成有限、可复现、可度量、可追溯的场景集合，让每一公里测试都指向明确的验证目标。本节围绕场景分类、场景库构建、关键场景提取、边缘案例生成与覆盖度评估五个环节展开。
一、核心原理：从真实世界到可执行场景
场景设计的基本逻辑是“抽象—参数化—实例化”。真实交通事件先被抽象为场景要素，再被参数化为可调变量，最后实例化为可执行的测试用例。业界常用三层描述：
- 功能场景：用自然语言描述，如“无保护左转时对向有直行车辆”。
- 逻辑场景：给出参数范围，如自车速度 20~40 km/h、对向车距 30~80 m、路面附着系数 0.4~0.9。
- 具体场景：参数取定值，可直接注入仿真或实车测试，如自车 30 km/h、对向车距 45 m、附着系数 0.6。
场景分类通常按三个维度切分：道路维度（路口、匝道、隧道、无标线区域）、交通参与者维度（机动车、行人、骑行者、动物、施工人员）、环境与动态维度（天气、光照、遮挡、通信质量、交通流密度）。分类的价值在于保证场景库不出现“同类扎堆、异类缺失”。
二、方法流程：场景库构建与关键场景提取
场景库构建遵循“来源—清洗—标注—入库—版本管理”的链路。数据来源包括自然驾驶数据、事故数据、路测回放、仿真生成和专家经验。清洗阶段要去除重复、无效和不可复现片段；标注阶段为每个场景打上道路类型、参与者、冲突类型、风险等级等标签；入库后必须做版本管理，因为场景库一旦被用于回归测试，任何修改都会影响历史结论的可比性。
关键场景提取的核心是“风险—频次”二维筛选。高频低风险场景用于验证基本能力，低频高风险场景用于验证安全边界。常用指标包括碰撞时间 TTC、后侵入时间 PET、减速度需求、冲突点数量等。工程上通常先按 TTC 阈值粗筛，再用聚类去冗余，最后人工复核。
# 关键场景筛选伪代码
for scene in scene_library:
ttc_min = min_ttc(scene)
pet_min = min_pet(scene)
risk = risk_score(ttc_min, pet_min, scene.weather, scene.occlusion)
if risk >= RISK_TH and scene.frequency >= FREQ_TH:
key_scenes.append(scene)
key_scenes = cluster_dedup(key_scenes, eps=0.15)
三、边缘案例生成：从参数扰动到对抗构造
边缘案例不是“罕见案例”的同义词，而是“使系统接近能力边界”的案例。生成方法主要有三类：
- 参数扰动：在逻辑场景参数空间内做拉丁超立方或贝叶斯优化采样，寻找失败率高的参数组合。
- 对抗生成：用可微分仿真或强化学习，让其他交通参与者主动制造冲突，例如“鬼探头”行人从遮挡后突然出现。
- 故障注入：注入传感器遮挡、GPS 漂移、通信延迟、制动响应下降等，验证系统降级策略。
四、场景覆盖度评估与复盘
覆盖度评估回答两个问题：场景库是否覆盖了设计运行域 ODD 的关键维度？测试执行是否覆盖了场景库？常用做法是建立覆盖矩阵，行是场景类别，列是 ODD 要素，单元格填入用例数量与执行状态。覆盖度不足的单元格就是下一轮测试的重点。
| 评估维度 | 指标示例 | 达标参考 |
|---|---|---|
| 道路覆盖 | 路口/匝道/隧道/无标线占比 | 与 ODD 声明一致 |
| 参与者覆盖 | 行人、骑行者、大型车、施工人员 | 每类至少 1 组关键场景 |
| 风险覆盖 | TTC < 1.5 s 场景数量 | 关键场景占比 ≥ 20% |
| 环境覆盖 | 雨、雾、逆光、夜间、遮挡 | 恶劣条件单独统计 |
| 执行覆盖 | 已执行用例 / 场景库总数 | 回归集 100% 执行 |
五、常见误区与复盘要点
第一个误区是“场景库越大越好”。未去冗余的场景库会导致回归测试时间失控，且大量相似用例掩盖真实缺陷。第二个误区是“只关注失败场景”。通过场景同样重要，它们构成能力基线，缺少基线就无法判断新版本是否退化。第三个误区是“覆盖度用里程代替”。里程是执行量，不是覆盖度；一万公里直路巡航无法替代一次无保护左转。
复盘时应重点检查：关键场景是否被真正执行而非仅入库；边缘案例是否触发了预期降级；覆盖矩阵中空白单元格是否被记录并排期；场景库版本变更是否同步到回归集。只有把场景设计、执行、评估闭环起来，Robotaxi 的测试才具备工程可信度。