3. 场景库工程化基础
在ADAS功能开发中，我们经常听到“场景”“场景库”“测试用例”“回归测试”这几个词，但它们并不是同义词，而是从“描述世界”到“验证系统”逐层收敛的四个工程对象。理解它们之间的映射关系，是搭建可复用、可追溯、可回归的场景库体系的前提。本节先厘清概念边界，再给出Bosch场景库体系结构的组织方式。
一、四个核心概念的定义与边界
场景（Scenario）是对一段交通情境的抽象描述，回答“在什么道路、什么环境、哪些交通参与者、以什么行为发生交互”。它通常由静态要素（道路几何、车道数、限速、标志标线）和动态要素（自车、目标车、行人、非机动车的初始状态与行为意图）构成。场景本身是“世界模型”，不绑定具体被测系统。
场景库（Scenario Library）是场景的集合，但工程化的场景库不是简单堆叠，而是带有分类维度、参数空间、标签体系和版本管理的结构化资产。它回答“我们覆盖了哪些情境、还缺哪些情境”。
测试用例（Test Case）是把场景实例化到具体被测对象上的可执行单元。它包含：场景参数的具体取值、被测系统配置（软件版本、传感器配置、标定参数）、执行条件（初始速度、触发时刻）、通过/失败判据。同一个场景可以派生出多个测试用例，例如同一“前车急刹”场景，在30 km/h、50 km/h、80 km/h下各生成一个用例。
回归测试（Regression Test）是在软件或参数变更后，重新执行既有测试用例集合，确认没有引入功能退化。回归测试的关键不是“再跑一遍”，而是“用稳定的判据、可复现的环境、可对比的结果”来回答“这次改动是否破坏了原有能力”。
二、从场景到用例的实例化过程
以一个典型AEB（自动紧急制动）场景为例：自车以恒定速度跟随前车，前车在某一时刻以固定减速度制动，自车需在碰撞前减速或刹停。这是场景描述。要变成测试用例，需要补齐以下参数：
- 自车初始速度：50 km/h（示例值）
- 前车初始速度：50 km/h，跟车时距1.2 s
- 前车制动减速度：-6 m/s²，制动起始时刻T=2.0 s
- 路面附着系数：0.8（干燥沥青）
- 被测系统：AEB软件版本V2.3.1，毫米波雷达+前视摄像头
- 通过判据：TTC（碰撞时间）最小值≥0.6 s，且未发生碰撞
这些参数一旦确定，场景就变成了一个可执行、可复现、可判定的测试用例。参数空间的不同组合，就形成了用例族。工程上通常用“场景模板+参数表”的方式批量生成用例，而不是手工逐个编写。
三、Bosch场景库体系结构
Bosch在ADAS场景库工程中，通常采用分层结构来组织资产，从抽象到具体依次为：功能场景层 → 逻辑场景层 → 具体场景层 → 测试用例层。功能场景用自然语言描述“要测什么能力”；逻辑场景用参数范围描述“在什么参数空间内测”；具体场景用固定参数描述“这一次具体怎么测”；测试用例则绑定被测系统与判据，直接进入执行。
这个分层结构的价值在于：功能场景层保证“覆盖意图”不遗漏；逻辑场景层定义“参数空间”便于组合覆盖；具体场景层提供“可复现的确定输入”；测试用例层绑定“被测系统与判据”直接进入执行。回归测试则是在测试用例层之上，按版本或变更范围选择用例子集，重新执行并对比结果。
四、场景库工程化的关键实践
在实际项目中，场景库不是一次性建成的，而是随功能迭代持续生长。以下实践值得注意：
- 标签体系：每个场景至少打上功能域（AEB/LKA/ACC）、道路类型（高速/城市/乡村）、环境条件（昼/夜/雨/雾）、参与者类型（车/人/两轮车）、危险等级等标签，便于按需筛选回归子集。
- 参数表驱动：逻辑场景的参数范围用表格或配置文件管理，用例生成脚本读取参数表批量实例化，避免手工复制粘贴导致的不一致。
- 版本绑定：测试用例必须记录被测软件版本、标定版本、场景库版本，否则回归结果无法追溯。
- 判据可量化：通过/失败判据尽量用数值阈值表达，如最小TTC、最大减速度、横向偏差峰值，避免“感觉可以”这类主观判断。
五、回归测试的触发与结果判读
回归测试通常在以下时机触发：软件版本更新、标定参数变更、场景库新增或修改、硬件配置变更。执行时，从测试用例库中按标签筛选出受影响的功能域用例集，在统一的仿真或台架环境中批量运行。
结果判读不能只看“通过率”。需要关注三类信号：新增失败（本次变更导致的退化，必须定位）、新增通过（可能是修复生效，也可能是判据过松，需复核）、结果波动（同一用例多次执行结果不一致，说明场景或判据稳定性不足）。对于新增失败，应回到具体场景层，检查是参数边界问题、被测系统逻辑问题，还是判据设置不合理。
只有把场景、场景库、测试用例、回归测试四者的关系理清，并在工程上落实分层结构、标签体系、参数驱动和版本绑定，场景库才能真正成为ADAS功能迭代的可靠基础设施，而不是一堆无法复用的场景文件。