1. 场景测试基础：自动驾驶场景定义、场景五要素、场景分类
大家好，我是老赵。在自动驾驶测试这行摸爬滚打了快十年，今天咱们来聊聊最基础、但也最容易被忽视的东西——场景。
很多人一上来就问我：「老赵，你们测试到底测什么？」
我通常会反问一句：「你觉得自动驾驶最怕什么？」
答案其实很简单——怕遇到没见过的场面。说白了，自动驾驶测试的核心，就是穷尽一切可能遇到的场面。而这些「场面」，就是我们说的场景。
1.1 什么是自动驾驶场景？
先给个定义。自动驾驶场景，是指自动驾驶系统在运行过程中，所面临的一段连续的、动态的交通环境描述。
嗯，这句话有点绕。我换个说法：
场景就是「车在什么路上、什么天气、周围有什么车、自己在干什么」的完整快照。它不是一张静态图片，而是一段有开始、有结束、有变化的动态过程。
核心理解：场景 = 环境 + 动态 + 时间
没有时间维度的，那不叫场景，叫状态。
我记得刚入行那会儿，有个同事拿着一张十字路口的照片跟我说：「这就是一个场景。」我当时就觉得不对劲。十字路口，车是直行还是左转？有没有行人闯红灯？天气是晴天还是雨天？这些都没说清楚，怎么能叫场景呢？
所以，场景必须包含时间轴上的变化。比如「自车以60km/h直行通过十字路口，此时右侧有车辆以40km/h速度切入本车道」——这才是一个完整的场景描述。
1.2 场景五要素：拆解场景的「原子」
做测试这么多年，我总结了一个经验：任何复杂的场景，都可以拆解成五个基本要素。就像化学里的元素周期表一样，掌握了这五个要素，你就能组合出无穷无尽的测试场景。
这五个要素分别是：
| 要素 | 说明 | 举例 |
|---|---|---|
| 道路 | 车辆行驶的物理基础设施 | 高速公路、城市道路、匝道、环岛 |
| 交通 | 交通规则、标志标线、信号灯 | 限速牌、停止线、红绿灯相位 |
| 环境 | 自然与人工环境条件 | 晴天、雨天、夜晚、隧道、施工区 |
| 自车 | 本车的状态与行为 | 车速、转向意图、传感器配置 |
| 他车 | 其他交通参与者的状态与行为 | 前车急刹、侧方车辆切入、行人横穿 |
你想想看，任何一个场景，是不是都能用这五个要素来描述？
举个例子：
- 道路：双向四车道城市主干道，中间有隔离带
- 交通：限速60km/h，有斑马线，无信号灯
- 环境：白天，晴朗，路面干燥
- 自车：以50km/h匀速直行，L2级辅助驾驶开启
- 他车：右侧车道有一辆轿车，距离自车约30米，车速55km/h
这就是一个完整的场景。缺了任何一个要素，测试结果都可能出现偏差。
我的习惯：每次设计测试用例前，我都会先列一个五要素清单。把每个要素的可能取值写出来，然后再组合。这样不容易遗漏边界情况。
1.3 场景分类：从抽象到具体的三层结构
场景有了，但怎么组织呢？总不能把几万个场景堆在一起吧？
这里就要引入场景分类的概念。我个人习惯把场景分为三个层次：功能场景、逻辑场景、具体场景。它们之间的关系，有点像「抽象类 → 参数化模板 → 实例化对象」。
1.3.1 功能场景
功能场景是最抽象的层次。它只描述「发生了什么」，不关心具体数值。
比如：
- 「前车减速，自车跟随减速」
- 「侧方车辆切入本车道」
- 「行人横穿马路」
这些描述里没有速度、距离、角度等具体参数。功能场景的作用是定义测试的「做什么」，而不是「怎么做」。
我在项目中遇到过一个问题：团队里不同人对同一个功能场景的理解不一样。有人说「前车减速」是减到30km/h，有人觉得是减到0。后来我们统一了规范——功能场景只写行为，不写数值。数值放到下一层去定义。
1.3.2 逻辑场景
逻辑场景在功能场景的基础上，给每个要素加上了参数范围。
还是刚才的例子：
- 「前车减速」→ 前车初始速度 [40, 80] km/h，减速度 [2, 6] m/s²
- 「自车跟随」→ 自车初始速度 [40, 80] km/h，跟车距离 [20, 50] m
逻辑场景定义的是参数的取值范围。它告诉我们：这个场景在什么条件下可能发生。
关键点：逻辑场景中的参数范围，应该覆盖所有可能的真实情况。范围太小会漏测，范围太大又会导致测试用例爆炸。
嗯，这里要注意：参数范围不是拍脑袋定的。我一般会参考三方面的数据：
- 自然驾驶数据（NDS）的统计结果
- 交通法规的限值要求
- 传感器性能的边界（比如毫米波雷达的最大探测距离）
1.3.3 具体场景
具体场景就是真正拿来执行测试的用例。它把逻辑场景中的参数范围，取成了具体的数值。
比如：
- 前车初始速度 60 km/h，减速度 4 m/s²
- 自车初始速度 60 km/h，跟车距离 30 m
- 天气：晴天，路面附着系数 0.8
一个逻辑场景，可以衍生出成百上千个具体场景。这就是测试用例设计的核心工作——从参数空间中采样出最有价值的点。
避坑指南：我曾经犯过一个错误——只采样了参数范围的中间值，觉得「典型工况」就够了。结果呢？系统在边界条件下出了大问题。后来我学乖了：边界值、极端值、组合边界值，这些才是测试的重点。
1.4 三个层次的关系
为了方便理解，我画了个简单的对应关系：
| 层次 | 抽象程度 | 参数 | 用途 |
|---|---|---|---|
| 功能场景 | 高 | 无具体数值 | 需求分析、测试规划 |
| 逻辑场景 | 中 | 有参数范围 | 测试设计、参数空间定义 |
| 具体场景 | 低 | 有具体数值 | 测试执行、仿真/路测 |
说白了，这三个层次就是从「想测什么」到「怎么测」再到「实际测」的逐步细化过程。
我建议刚入行的朋友，先从功能场景入手。别一上来就纠结具体数值。先把「要测什么行为」想清楚，再去细化参数。否则很容易陷入细节里出不来。
1.5 小结
这一章我们聊了三个核心概念：
- 场景定义：一段连续的、动态的交通环境描述，包含时间维度
- 场景五要素：道路、交通、环境、自车、他车——拆解场景的原子
- 场景分类：功能场景（抽象行为）→ 逻辑场景（参数范围）→ 具体场景（具体数值）
记住一句话：没有场景，就没有测试；没有好的场景分类，就没有高效的测试。
下一章，我们会深入聊聊如何从功能场景推导出逻辑场景的参数空间。到时候我会拿几个真实项目中的案例来拆解，保证干货满满。
课后思考：试着用五要素描述你每天上班路上遇到的一个典型场景。看看能不能把每个要素都写清楚？如果写不出来，说明你对场景的理解还不够深。