3. 测试用例设计方法:等价类划分、边界值分析、正交实验法、场景法、错误推测法
测试用例怎么设计,才能既覆盖全面又不冗余?这个问题,我几乎每次带新人时都会被问到。说实话,量产导入阶段的测试用例设计,跟研发阶段的单元测试不太一样。你想想看,产线上每天跑几千片板子,测试用例要是设计得不好,要么漏测,要么浪费时间。
我个人习惯把这五种方法组合着用。它们各有各的适用场景,就像工具箱里的不同工具。下面我一个个拆开来讲。
3.1 等价类划分
等价类划分,说白了就是把输入数据分成几个「等价」的组。同一组里的数据,程序处理方式应该是一样的。我们只需要从每组里挑一个代表来测就行。
核心原则:
- 有效等价类:符合需求、有意义的输入
- 无效等价类:不符合需求、无意义的输入
举个例子。假设一个电源模块的输入电压范围是 5V ± 10%。那等价类就是:
| 类型 | 范围 | 代表值 |
|---|---|---|
| 有效等价类 | 4.5V ~ 5.5V | 5.0V |
| 无效等价类(低压) | < 4.5V | 3.3V |
| 无效等价类(高压) | > 5.5V | 6.0V |
我在项目中遇到过有人把每个电压值都测一遍,测了整整一天。其实完全没必要。等价类划分就是帮你做减法的。
我的习惯:先列有效等价类,再列无效等价类。无效等价类往往比有效等价类更容易发现隐藏的 bug。
3.2 边界值分析
边界值分析,是等价类划分的好搭档。经验告诉我,很多 bug 都出在边界上。为什么会这样?因为开发写代码时,最容易搞错的就是「<」和「<=」这种边界条件。
还是上面那个电源模块的例子。边界值就是:
- 最小值:4.5V
- 最大值:5.5V
- 略低于最小值:4.49V
- 略高于最大值:5.51V
- 正常值:5.0V(作为参考)
我曾经踩过的坑:有一次只测了边界值本身,没测边界值附近的值。结果产品在 4.49V 时直接重启了。从那以后,我每次都会把「边界 + 边界 ± 最小步进」都测一遍。
边界值分析通常取 3 个点(最小值、最大值、正常值)或 5 个点(最小值、略低于最小值、最大值、略高于最大值、正常值)。我个人更推荐 5 点法,覆盖更全面。
3.3 正交实验法
当测试参数很多时,全组合测试根本跑不完。比如有 4 个参数,每个参数有 3 个取值,全组合就是 3⁴ = 81 种。产线上哪有这个时间?
正交实验法就是用来解决这个问题的。它用最少的测试用例,覆盖参数之间的两两组合。
正交表的基本概念:
- 因子:测试参数
- 水平:参数的取值
- 正交表:用 Ln(mk) 表示,n 是测试用例数,m 是水平数,k 是因子数
举个例子。假设我们要测一个通信模块,有 3 个因子,每个因子有 2 个水平:
| 因子 | 水平 1 | 水平 2 |
|---|---|---|
| 波特率 | 9600 | 115200 |
| 数据位 | 8 | 7 |
| 校验位 | 无 | 偶校验 |
全组合需要 2³ = 8 个用例。用正交表 L₄(2³) 只需要 4 个:
| 用例 | 波特率 | 数据位 | 校验位 |
|---|---|---|---|
| 1 | 9600 | 8 | 无 |
| 2 | 9600 | 7 | 偶校验 |
| 3 | 115200 | 8 | 偶校验 |
| 4 | 115200 | 7 | 无 |
你看,每个因子的每个水平都出现了相同次数,而且任意两个因子的所有组合都出现了。这就是正交性。
我的建议:网上有现成的正交表工具,直接查表就行。别自己手算,容易算错。
3.4 场景法
场景法,就是模拟用户真实的使用流程。你想想看,用户不会按着你的测试用例来操作。他们可能会乱按、会跳步骤、会在中间断电。
场景法通常分两种:
- 基本流:用户按正常流程操作,一路顺畅
- 备选流:用户操作出错、中断、异常等情况
举个例子。一个刷卡开锁的场景:
| 场景类型 | 操作步骤 | 预期结果 |
|---|---|---|
| 基本流 | 刷卡 → 验证通过 → 开锁 | 门锁打开 |
| 备选流 1 | 刷卡 → 验证失败 → 提示错误 | 门锁不开,显示错误码 |
| 备选流 2 | 刷卡 → 验证通过 → 开锁中突然断电 | 门锁保持关闭,恢复供电后重新验证 |
| 备选流 3 | 连续刷卡 5 次失败 → 锁定 | 门锁锁定 30 秒 |
我在项目中遇到过有人只测了基本流,结果备选流里全是 bug。场景法就是逼着你去想那些「用户会怎么搞砸」的情况。
3.5 错误推测法
错误推测法,说白了就是靠经验猜哪里容易出问题。这个方法没有固定的公式,全靠积累。
常见的错误推测方向:
- 空值:输入为空时程序会不会崩溃?
- 超长值:输入超过限制长度时会不会溢出?
- 特殊字符:输入 <script> 会不会触发 XSS?
- 并发操作:同时按两个按钮会不会死锁?
- 重复操作:连续提交两次会不会生成重复数据?
我曾经犯过的错:有一次没测「同时按两个按键」的场景。结果量产时发现,用户同时按「音量+」和「电源键」会导致系统死机。这个 bug 在产线上被批量复现,最后紧急修了一版固件。
错误推测法不能单独用,它是对其他方法的补充。我一般会在写完等价类和边界值后,再花 10 分钟想想「还有什么地方可能会出问题」。
3.6 五种方法的组合使用
这五种方法不是孤立的。我个人的使用流程是:
- 先用场景法:画出用户的基本流和备选流
- 再用等价类划分:对每个输入参数分组
- 接着用边界值分析:补充边界附近的测试点
- 然后用正交实验法:减少多参数组合的用例数
- 最后用错误推测法:凭经验补充遗漏的异常场景
下面这张图展示了它们之间的关系:
总结一下:
- 等价类划分帮你做减法,减少重复测试
- 边界值分析帮你抓住最容易出 bug 的地方
- 正交实验法帮你用最少的用例覆盖多参数组合
- 场景法帮你模拟真实用户操作
- 错误推测法帮你补漏,靠经验发现隐藏问题
这五种方法,你用得越多,就越有感觉。刚开始可能觉得麻烦,但等你踩过几次坑之后,就会明白它们有多重要了。