4、用例设计进阶：正交实验法、场景法、错误推测法

说实话，很多同学写用例写到一定阶段，就会遇到瓶颈。

什么瓶颈呢？就是「能想到的我都写了，但总觉得漏了什么」。我当年带项目时也这样，一个登录功能写了80条用例，结果上线还是出了个组合bug——用户名带特殊字符+密码超长+网络超时，三个条件凑一起就崩了。

为什么会这样？因为单点覆盖再全，也架不住组合爆炸。今天我们就聊聊怎么用三种进阶方法，把用例的「密度」和「杀伤力」提上去。

4.1 正交实验法：用数学打败组合爆炸

先问个问题：一个搜索功能，有3个输入框（关键词、分类、排序方式），每个有4个选项。全组合要写多少条用例？

4×4×4 = 64条。如果再加一个筛选条件，直接翻倍。你想想看，这谁受得了？

正交实验法的思路很简单：用最少的组合，覆盖最多的两两配对。它不测所有组合，但保证任意两个参数的所有取值都至少被覆盖一次。

举个例子，一个搜索页有3个因素：

• 关键词：有值、空值、特殊字符
• 分类：全部、图书、电子
• 排序：默认、销量、价格

全组合是27条。用L9(3^3)正交表，9条就够了：

用例编号	关键词	分类	排序
1	有值	全部	默认
2	有值	图书	销量
3	有值	电子	价格
4	空值	全部	销量
5	空值	图书	价格
6	空值	电子	默认
7	特殊字符	全部	价格
8	特殊字符	图书	默认
9	特殊字符	电子	销量

你看，任意两个参数的所有取值组合，都至少出现了一次。比如「关键词=空值」和「排序=价格」同时出现，在第5条里。

4.2 场景法：从用户视角出发

正交实验法解决的是「参数组合」问题，但用户不是按参数来操作的。用户是按「场景」来的。

我记得有一次测试一个电商下单流程，用例写了200条，覆盖了各种输入组合。结果上线第一天就出问题了——用户从「购物车」点「去结算」，页面白屏了。为什么？因为我们测的都是从商品详情页直接下单，没测从购物车跳转的场景。

场景法的核心就是：画出用户的操作路径，每条路径就是一条用例。

基本步骤：

1. 确定角色：谁在用？普通用户？VIP？管理员？
2. 列出基本流：最顺利的操作路径。比如登录→搜索→加购→下单→支付→完成。
3. 列出备选流：每个节点可能出错的地方。比如搜索无结果、加购失败、支付超时。
4. 组合成场景：基本流 + 备选流，形成完整用例。

你想想看，如果只测基本流，那备选流里的bug就全漏了。我建议每个功能至少画一张场景图，把分支都标出来。

4.3 错误推测法：经验就是生产力

这个方法说白了就是「猜哪里会出问题」。听起来不严谨，但恰恰是资深测试和初级测试的分水岭。

我曾经测过一个文件上传功能。需求文档写得很清楚：支持jpg、png，大小不超过5M。我按正交法写了用例，覆盖了各种格式和大小组合。结果上线后，用户上传了一个「文件名带中文+空格+超长路径」的图片，直接报错。

为什么我没测到？因为需求文档没写这些。但经验告诉我：文件名、路径、特殊字符，永远是高危区。

错误推测法的常见套路：

• 边界值附近：比如输入框最大长度，试试多一个字符会怎样
• 特殊字符：空格、引号、斜杠、Unicode字符
• 并发操作：同时点两个按钮、快速双击
• 异常中断：网络断开、服务器重启、数据库锁表
• 数据依赖：删除父数据后子数据怎么办？

4.4 三种方法怎么搭着用？

这三种方法不是互斥的，而是互补的。我个人习惯的流程是这样的：

1. 先用场景法：画出用户操作路径，保证核心流程不漏
2. 再用正交实验法：对每个步骤的参数做组合覆盖，减少冗余
3. 最后用错误推测法：补一些「正常人想不到但用户一定会干」的骚操作

举个例子，测试一个注册页面：

• 场景法：正常注册→邮箱验证→登录；注册失败→提示错误→重新填写
• 正交法：用户名（3种）、密码（3种）、邮箱（3种），9条用例覆盖两两组合
• 错误推测法：用户名含emoji、密码粘贴、邮箱带加号、快速点击提交两次

这样下来，用例数量不多，但覆盖质量很高。我试过很多次，这种组合方式发现的bug数量，比单纯用等价类边界值多30%以上。

好了，这三种方法你可以在下一个项目中试试。不用一次全用上，先从场景法开始，慢慢加入正交和错误推测。你会发现，用例的质量会明显提升。

可可精品资料库