3. 场景定义与分类
在自动驾驶开发中，“场景”一词被频繁使用，但团队内部往往对场景、情景、用例、测试用例的理解存在偏差，导致测试需求描述混乱、场景库建设重复、测试结果难以横向对比。本章从概念边界出发，建立统一的术语体系，并给出自然场景、危险场景、边缘场景的分类方法与应用策略，帮助学员在场景工程化建设中建立清晰的认知框架。
3.1 核心概念辨析：场景、情景、用例与测试用例
在自动驾驶测试领域，术语混用是常见问题。例如，有人将“车辆在雨天高速公路上变道”称为一个场景，也有人将其称为用例。实际上，这四者之间存在明确的层级关系与转化逻辑。场景是客观世界的片段描述，情景是场景在某一时刻的状态快照，用例是从功能需求出发的行为描述，测试用例则是可执行、可判定的具体测试规格。
3.1.1 概念定义与边界
| 术语 | 定义 | 时间维度 | 抽象层级 | 典型表达 |
|---|---|---|---|---|
| 场景 Scene | 一段连续时间内，道路、交通、环境、自车状态的完整描述 | 时间区间（如10s） | 高层抽象 | “高速跟车时前车急刹” |
| 情景 Situation | 某一时刻下所有相关要素的状态集合 | 时间点（如t=3s） | 中层快照 | “t=3s时，自车速度80km/h，前车距离25m，相对速度-15km/h” |
| 用例 Use Case | 从系统功能角度描述“谁在什么条件下做什么事” | 功能触发到结束 | 功能视角 | “AEB功能在自车接近前车时触发制动” |
| 测试用例 Test Case | 将用例参数化后，形成可执行、可判定的具体测试规格 | 执行周期 | 具体实例 | “自车50km/h，前车静止，距离30m，路面μ=0.8，预期AEB在碰撞前1.2s介入” |
从工程实践看，场景是“素材库”，情景是“切片”，用例是“需求”，测试用例是“执行脚本”。场景库建设时，先采集或构造场景，再从中提取关键情景，映射到功能用例，最终生成可批量执行的测试用例。这一链条在ISO 21448（SOTIF）和ASAM OpenX标准中均有体现。
3.1.2 概念转化流程
- 场景采集/构造：通过路采、仿真生成、事故重建等方式获得原始场景数据。
- 情景提取：从场景中按时间轴提取关键帧，标注自车状态、目标物状态、环境参数。
- 用例映射：将情景与自动驾驶功能（如AEB、LKA、ACC）进行关联，明确功能触发条件和预期行为。
- 测试用例生成：对用例中的参数进行具体化赋值，包括速度、距离、角度、光照、天气等，并定义通过/失败判据。
3.1.3 小型场景化说明
以“十字路口左转”为例：场景描述为“自车在双向四车道十字路口左转，对向有直行车辆”；情景为“t=2s时，自车位于停止线前5m，车速15km/h，对向车辆距离交叉口中心30m，车速40km/h”；用例为“左转辅助功能在检测到对向直行冲突时发出警告或减速”；测试用例为“自车15km/h左转，对向车辆40km/h直行，距离交叉口中心30m，路面干燥，预期系统在碰撞前2.5s发出警告”。
3.2 场景分类方法：自然、危险与边缘
场景分类的核心目的是服务于不同的测试目标。自然场景用于验证系统在常规工况下的表现，危险场景用于验证安全性底线，边缘场景用于探索系统能力的边界。三者并非完全独立，而是存在交叉与转化关系。
3.2.1 自然场景（Natural Scenarios）
自然场景来源于真实道路数据的统计分布，反映的是高频、常规的驾驶情况。其特点是出现频率高、参数分布集中、系统应能稳定处理。自然场景的主要用途包括：
- 回归测试：每次软件迭代后，用自然场景集验证基本功能未退化。
- 性能基准：统计系统在自然场景中的接管率、舒适度、通行效率等指标。
- 覆盖度评估：对比路采数据与场景库的分布差异，找出未覆盖的常规工况。
自然场景的构建通常基于大规模路采数据，通过场景挖掘工具（如场景关键词提取、聚类分析）自动生成。例如，某团队从1000小时路采数据中提取出“跟车行驶”“车道保持”“红灯停车”等高频场景，构成自然场景库的基础。
3.2.2 危险场景（Hazardous Scenarios）
危险场景是指可能导致碰撞、失控、功能失效或违反交规的场景。这类场景虽然发生频率低，但后果严重，是安全验证的核心。危险场景的来源包括：
- 事故数据：从国家事故数据库、保险数据、自然驾驶数据中提取碰撞前场景。
- 专家构造：基于功能安全（ISO 26262）和SOTIF（ISO 21448）分析，构造可能触发危害的场景。
- 对抗性生成：使用搜索算法（如遗传算法、贝叶斯优化）在参数空间中寻找导致系统失效的场景。
3.2.3 边缘场景（Corner/Edge Scenarios）
边缘场景是指参数处于边界值、极端条件或罕见组合的场景。这类场景用于检验系统的鲁棒性和泛化能力。边缘场景的典型特征包括：
- 参数边界：如车速接近系统设计上限、光照接近传感器极限、道路曲率接近最小转弯半径。
- 极端环境：暴雨、大雾、积雪覆盖车道线、逆光等。
- 罕见组合：多个低概率事件同时发生，如“夜间+雨天+行人突然横穿+对向远光灯”。
边缘场景的生成方法包括：参数边界扫描、组合测试（如成对组合、正交实验）、基于知识图谱的场景变异等。需要注意的是，边缘场景并非越多越好，应优先覆盖与安全强相关的边界条件。
3.2.4 分类对比与选择策略
| 维度 | 自然场景 | 危险场景 | 边缘场景 |
|---|---|---|---|
| 主要目标 | 验证常规性能 | 验证安全性 | 验证鲁棒性 |
| 来源 | 路采统计 | 事故+专家+搜索 | 边界分析+组合生成 |
| 出现频率 | 高 | 低 | 极低 |
| 测试优先级 | 每次迭代必测 | 安全发布前必测 | 能力评估时重点测 |
| 典型数量 | 数千~数万 | 数百~数千 | 数十~数百 |
| 判定标准 | 功能正常+舒适度 | 无碰撞+安全冗余 | 不失效+可降级 |
3.3 场景分类的工程实践案例
某自动驾驶初创公司需要建立L2+级辅助驾驶系统的场景库，用于验证其高速公路领航辅助（HWA）功能。团队面临三个约束：路采数据有限（仅200小时）、开发周期紧张（3个月后SOP）、安全标准要求高（满足C-NCAP 2025和ISO 21448）。
3.3.1 初始目标与数据情况
团队的目标是：在3个月内建立覆盖自然、危险、边缘三类场景的测试集，并完成至少两轮完整回归测试。初始数据包括：200小时高速公路路采数据、50个事故重建场景、30个专家构造场景。路采数据中，晴天占70%，雨天占15%，夜间占10%，其他占5%。
3.3.2 分析判断过程
团队首先对路采数据进行场景挖掘，使用基于规则的关键词提取（如“前车减速”“变道切入”“车道线模糊”）和基于聚类的场景分类，共获得自然场景120个。随后，团队对事故数据进行分析，发现“前车急刹”“相邻车道车辆切入”“施工区域改道”是高频危险场景。专家构造场景则聚焦于传感器失效（如摄像头被遮挡、雷达丢失目标）和极端天气（暴雨、大雾）。
在边缘场景生成方面，团队采用参数边界扫描法，对HWA功能的关键参数（自车速度、前车相对速度、切入角度、路面附着系数）进行边界值提取，并结合成对组合测试生成边缘场景。例如，将“自车速度120km/h”“前车相对速度-30km/h”“路面μ=0.3”组合为一个边缘场景。
3.3.3 实际操作步骤与结果
- 第一步：自然场景库构建。从200小时路采数据中提取120个自然场景，按“高速主路”“匝道汇入”“隧道”“施工区”等道路类型分类，每个场景包含10-30个情景。
- 第二步：危险场景库构建。将50个事故重建场景转化为可仿真执行的场景，补充30个专家构造场景，共80个危险场景。每个场景均标注了TTC、碰撞速度等安全指标。
- 第三步：边缘场景生成。通过参数边界扫描和组合测试，生成60个边缘场景。其中20个为单参数边界，40个为多参数组合。
- 第四步：测试用例转化。将三类场景共260个场景转化为可执行的测试用例，每个用例包含初始条件、动态参数、预期结果和判定标准。
执行两轮回归测试后，团队发现：自然场景测试通过率为98.5%，危险场景通过率为91.2%，边缘场景通过率仅为76.7%。进一步分析发现，边缘场景的失败主要集中在“路面μ=0.3+前车急刹”组合，系统在低附着路面上的制动策略过于激进，导致车辆侧滑。团队据此调整了AEB介入策略，在低附着路面上提前介入并降低制动梯度，最终将边缘场景通过率提升至88.3%。
3.4 常见误区与总结
在场景定义与分类的实际应用中，团队常陷入以下误区：
- 误区一：场景与测试用例混为一谈。场景是客观描述，测试用例是执行规格。直接使用场景作为测试用例，会导致参数不明确、判定标准缺失。
- 误区二：只关注危险场景，忽视自然场景。危险场景测试通过不代表系统在常规工况下表现良好。自然场景的舒适性和效率指标同样重要。
- 误区三：边缘场景越多越好。边缘场景的生成成本高、执行时间长，应优先覆盖与安全强相关的边界条件，而非盲目追求数量。
- 误区四：分类后不更新。场景库需要随着路采数据的增加、事故数据的更新、算法能力的提升而持续迭代。
总结而言，场景定义与分类是自动驾驶测试的基石。团队应建立统一的术语体系，明确场景、情景、用例、测试用例的层级关系；根据测试目标合理选择自然、危险、边缘场景的比例；并通过工程实践不断优化场景库的质量和覆盖度。下一阶段，我们将深入探讨场景参数化建模方法，将本章的概念框架转化为可计算、可搜索的形式化表达。