1. 课程导入

1.1 到底什么是「仿真测试场景」？

先把这个概念说清楚。很多人一上来就谈场景库，结果连场景的定义都没对齐。

我个人习惯这样定义：仿真测试场景，是对车辆在特定时间、特定环境、特定操作下的一段连续行为的抽象描述。 说白了，就是把你开车时遇到的各种情况，拆成计算机能理解、能回放的一段脚本。

举个例子。你在高速上开着自适应巡航，前面突然有辆车加塞进来——这就是一个场景。它包含：

• 道路环境：高速、直道、三车道
• 自车状态：时速 110 km/h，ACC 开启
• 目标物行为：邻车道车辆以相对速度 15 km/h 切入本车道
• 时间窗口：从加塞开始到自车完成减速跟车

我在项目中遇到过不少团队，把场景和用例混为一谈。场景是「发生了什么」，用例是「我们要测什么」。这两个东西分不清，后面构建场景库一定会乱。

1.2 场景库到底值不值得建？

说实话，五年前我也觉得场景库是个「锦上添花」的东西。直到有一次，我们为一个 L3 项目做回归测试，手动写了 200 多个测试用例，结果漏掉了一个很常见的「雨夜对向远光灯」场景——实车路试时直接触发了误制动。

从那以后，我彻底改变了看法。场景库的价值，我总结为三点：

价值维度	具体说明	我的体会
可复用性	一次构建，多次使用。不同项目、不同版本都能跑	我们团队复用率从 20% 提升到 70%，节省了 40% 的测试准备时间
可追溯性	每个场景都能追溯到需求、法规或事故数据	遇到法规更新时，能快速定位哪些场景需要修改
可量化性	用场景覆盖率代替「感觉测够了」	管理层终于能看到「我们测了 85% 的场景」而不是「我们测了很多」

1.3 构建场景库，难在哪？

你想想看，场景库听起来不就是「把场景存起来」吗？为什么那么多团队做不好？

我踩过的坑，总结下来主要是这三个：

1. 场景来源杂，格式不统一
   • 有的来自法规（如 Euro NCAP），有的来自路采数据，有的来自工程师经验
   • 每个来源的描述方式都不一样，整合起来像在拼图
2. 场景粒度难把握
   • 太粗：一个场景包含太多变体，跑完不知道具体测了啥
   • 太细：一个场景拆成几百个参数组合，管理成本爆炸
3. 维护成本高
   • 场景库不是建完就完事的。传感器升级了、算法改了、法规更新了，场景都得跟着变
   • 我曾经接手过一个场景库，里面 30% 的场景已经无法在最新平台上运行

1.4 构建原则：我这些年总结的「铁律」

原则这东西，说起来简单，做起来难。但有些底线不能破。

我这些年带团队建场景库，一直守着四条原则：

原则	解释	反面案例
结构化	场景必须有统一的元数据模型，不能各写各的	有人用 JSON，有人用 XML，有人用 Word——最后谁也读不懂谁的
可扩展	新场景能无缝加入，不影响已有场景	加一个新场景要改整个数据库结构，这种设计趁早重来
可追溯	每个场景都能找到「为什么建它」	场景库里一堆场景，问来源没人知道，最后全废弃
可执行	场景描述必须能直接驱动仿真工具	场景写得天花乱坠，但仿真工具跑不了——等于零

嗯，这里要注意。第四条「可执行」是最容易被忽视的。很多团队花大量精力做场景描述，结果到了仿真工程师手里，还得手动翻译一遍。这就不对了。

1.5 场景库的整体框架长什么样？

说了这么多，咱们用一张图把场景库的构成理清楚。

这张图我建议你多看两眼。它反映了一个核心思想：场景库不是静态仓库，而是从来源到分类到执行的闭环系统。

最上面是场景来源，中间是核心存储和分类，最下面是输出执行。每一层之间都有明确的接口和规范。这样建出来的场景库，才经得起时间和项目迭代的考验。

1.6 小结：建库之前，先想清楚这三件事

这一章的内容比较多，但核心就三件事：

• 定义对齐：团队里每个人对「场景」的理解必须一致
• 价值明确：场景库是为了可复用、可追溯、可量化，不是为了「有」
• 原则守住：结构化、可扩展、可追溯、可执行——少一条都不行

我个人经验是，建场景库最怕的不是技术难，而是方向偏。方向对了，后面 29 章的内容才有意义。方向错了，工具再好也是白搭。