第二章：测试用例设计方法论

大家好，我是老张。在自动驾驶测试这行摸爬滚打了快十年，今天跟大伙聊聊测试用例设计的方法论。说实话，刚入行那会儿我也觉得设计用例就是拍脑袋，后来踩了不少坑才明白——好的方法论，能让你少走一半弯路。

2.1 等价类划分法在场景测试中的应用

等价类划分，说白了就是把输入数据分成几个「类」。同一类里的数据，测一个就够了。为什么？因为它们的行为表现是等价的。

我举个例子。假设我们要测试一个自动紧急制动（AEB）系统。它的触发条件是前车距离小于某个阈值。你想想看，距离这个参数，理论上可以取无穷多个值。但实际测试中，我们只需要测几个关键点。

具体怎么分？我一般这么干：

• 有效等价类：系统能正常处理的输入。比如AEB的有效触发距离是5米到50米。
• 无效等价类：系统不能处理的输入。比如距离小于0米，或者大于传感器最大量程。

我在项目中遇到过一件事。有一次测试一个泊车辅助系统，输入是超声波雷达的探测距离。我们只测了0.3米到2.5米这个范围，结果忽略了大于2.5米的情况。上线后，用户在空旷停车场倒车，系统突然报「障碍物过近」——其实就是因为大于2.5米时，雷达返回的是无效值，代码没处理好。

等价类划分的步骤，我总结为三步：

1. 识别输入参数（比如速度、距离、光照强度）
2. 划分有效类和无效类
3. 从每个类中选取代表值

嗯，这里要注意。有些参数不是简单的数值，比如天气状态。晴天、雨天、雪天，每个都是一个等价类。你不能只测一个晴天就认为所有天气都OK。

2.2 边界值分析法在场景测试中的应用

边界值分析，是等价类划分的好搭档。为什么？因为很多bug都出在边界上。我自己的经验是，80%的严重缺陷都跟边界条件有关。

举个例子。车道保持系统的激活条件是车速大于60km/h。那么60km/h这个点就是边界。你想想看，如果代码里写的是if (speed > 60)，那60km/h本身就不会激活。但如果需求写的是「大于等于60」，那代码应该是if (speed >= 60)。差一个等号，结果天差地别。

边界值分析的具体做法：

• 确定每个参数的边界点
• 测试边界点本身
• 测试边界点两侧的邻近值

比如一个参数范围是[0, 100]，那我们要测的值是：-1, 0, 1, 99, 100, 101。一共6个点。别嫌多，这6个点能帮你挡住大部分低级错误。

我记得有一次测试一个变道辅助系统。它的盲区监测范围是3米到8米。我们测了3米、8米、2.9米、8.1米。结果发现，在2.9米时系统误报，在8.1米时系统漏报。原因就是边界处理逻辑写反了。

2.3 场景流分析法

场景流分析，这个是我个人比较喜欢的方法。它跟前面两种不一样，不是盯着单个参数看，而是看整个场景的「流动」过程。

什么叫场景流？就是自动驾驶系统从感知到决策再到控制的完整链条。你想想看，一个典型的场景流可能是这样的：

感知阶段：检测到前方有车辆
预测阶段：预测前车将减速
决策阶段：决定本车也减速
控制阶段：执行减速操作

每个阶段都可能出问题。我建议你画一个流程图，把每个环节的输入输出都标清楚。然后针对每个环节设计测试用例。

具体怎么做？我一般分四步：

1. 拆解场景流：把场景分解成若干阶段
2. 识别关键节点：每个阶段的输入输出条件
3. 设计测试点：针对每个节点设计正向和反向用例
4. 组合测试：把多个节点的异常情况组合起来

我在项目中遇到过这样一个案例。测试一个十字路口左转场景。场景流是：感知到绿灯→检测到对向直行车辆→判断是否可左转→执行左转。我们单独测每个环节都没问题，但组合起来就出事了——感知到绿灯后，系统没有及时更新对向车辆的位置信息，导致左转时跟直行车差点撞上。

场景流分析还有一个好处——它能帮你发现「隐式依赖」。比如某个决策依赖于上一个感知结果，但代码里可能没做同步。这种bug，用等价类划分和边界值分析都很难发现。

嗯，最后说一句。这三种方法不是互斥的。我自己的习惯是：先用等价类划分确定参数范围，再用边界值分析找出关键点，最后用场景流分析串联整个流程。三管齐下，测试覆盖率才能上去。

好了，这一章就聊到这儿。下一章我们讲讲具体怎么把这些方法用到实际场景里。到时候我会拿几个真实案例出来，咱们一起练练手。