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

说实话，很多同学学完等价类和边界值之后，会觉得测试用例设计也就那么回事。但等你真正进了项目，你会发现——光靠那两招，根本不够用。

我刚开始带项目的时候，就吃过这个亏。一个参数组合的bug，愣是漏到了线上。从那以后，我老老实实把正交实验法、场景法和错误推测法学了个透。今天咱们就把这三板斧掰开揉碎讲清楚。

3.1 正交实验法：用最少的用例覆盖最多的组合

你想想看，一个功能如果有4个参数，每个参数有3个取值。全排列组合是多少？3的4次方，81种。真要全测，项目周期得翻三倍。

正交实验法就是干这个的——用最少的用例，覆盖两两组合。为什么是两两？因为据统计，70%以上的bug都是由两个参数交互触发的。三个以上参数同时出问题的概率极低。

3.1.1 正交表长什么样？

我直接给你看一个最常用的正交表：L9(3^4)。意思是9条用例，覆盖4个参数，每个参数3个取值。

用例编号	参数A	参数B	参数C	参数D
1	A1	B1	C1	D1
2	A1	B2	C2	D2
3	A1	B3	C3	D3
4	A2	B1	C2	D3
5	A2	B2	C3	D1
6	A2	B3	C1	D2
7	A3	B1	C3	D2
8	A3	B2	C1	D3
9	A3	B3	C2	D1

你看，81种组合被压缩到9条用例。而且任意两列之间，所有组合都出现了且只出现一次。这就是正交表的精髓——均匀分散，整齐可比。

3.1.2 实际项目怎么用？

我在测试一个搜索功能时，遇到过这么个场景：搜索条件有「关键词」「分类」「排序方式」「每页条数」四个维度。每个维度3-4个取值。

我当时没急着写用例，先列了个因子-状态表：

因子（参数）	状态1	状态2	状态3
关键词	中文	英文	数字
分类	全部	电子产品	图书
排序方式	默认	价格升序	销量降序
每页条数	10	20	50

然后套用L9(3^4)正交表，直接生成9条用例。跑完之后，发现「英文关键词+价格升序」这个组合下，搜索结果排序错乱了。这个bug如果全量测试，可能要跑到第40条用例才能发现。

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

正交实验法虽然高效，但它有个致命弱点——它只关心参数组合，不关心业务流程。你想想看，用户使用软件是一个连续的过程，不是一个个孤立的参数输入。

场景法就是来解决这个问题的。它的核心思想是：模拟用户真实的使用路径。

3.2.1 基本流和备选流

场景法把业务流程分成两种：

• 基本流：用户最常用的、最顺利的路径。比如登录→搜索商品→加入购物车→支付→完成。
• 备选流：各种异常、分支、中断的情况。比如支付失败、库存不足、网络超时。

我举个例子你就明白了。拿「用户下单」这个功能来说：

基本流：
  1. 用户登录
  2. 选择商品
  3. 填写收货地址
  4. 选择支付方式
  5. 支付成功
  6. 订单生成

备选流：
  2a. 商品库存不足 → 提示缺货
  3a. 地址不完整 → 提示补充
  4a. 支付超时 → 取消订单
  5a. 支付失败 → 重新支付
  6a. 订单生成失败 → 回滚库存

每个备选流和基本流组合，就是一个场景。比如「基本流+备选流2a」就是一个场景：用户选了一个缺货的商品，系统应该怎么处理。

3.2.2 场景法实战案例

我记得有一次测试一个「在线考试系统」。如果用正交法，我只能测各种参数组合。但场景法让我发现了几个致命问题：

• 场景1：考生答题中途断网，重新连接后答案丢失
• 场景2：考试时间到，但考生还在答题，系统强制交卷
• 场景3：考生提交后，发现还有未答的题目，想重新进入

这些场景，正交法根本覆盖不到。但恰恰是这些场景，最容易出线上事故。

3.3 错误推测法：靠经验吃饭

这个方法听起来有点玄学，说白了就是——猜哪里会出bug。

你可能会问：这也能叫方法？嗯，它确实不是科学方法，但它非常实用。尤其是当你对某个系统足够熟悉的时候，你闭着眼睛都能猜到哪些地方会出问题。

3.3.1 常见的错误类型

我总结了一下，常见的容易出bug的地方就那么几类：

• 边界值附近：比如输入框最大长度、分页的最后一页
• 空值/零值：比如金额为0、数量为空、列表为空
• 并发操作：比如两个人同时编辑同一条数据
• 数据依赖：比如删除父级数据时，子级数据没处理
• 状态转换：比如订单从「已支付」直接跳到「已完成」，跳过了「已发货」

3.3.2 我的避坑指南

我曾经在一个支付系统上栽过跟头。用户支付成功后，系统回调处理超时，导致订单状态卡在「支付中」。用户付了钱，但订单显示未支付。

从那以后，我养成了一个习惯：每次测试前，先列一个「错误推测清单」。比如：

错误推测清单（支付模块）：
  □ 支付成功回调超时
  □ 支付成功回调重复调用
  □ 支付金额精度丢失（0.1+0.2 != 0.3）
  □ 退款金额超过原支付金额
  □ 同时发起多笔支付
  □ 支付过程中关闭页面

这个清单不是一次性的。每次发现新bug，我都会加进去。久而久之，你的错误推测能力会越来越强。

3.4 三种方法的对比与选择

说了这么多，你可能有点晕。到底什么时候用哪个？我直接给你一张对比表：

方法	适用场景	优点	缺点
正交实验法	多参数组合、配置测试	用例少、覆盖全	不关心业务流程
场景法	业务流程、用户操作路径	贴近真实使用	用例数量不易控制
错误推测法	高风险区域、历史bug高发区	针对性强、效率高	依赖个人经验

我个人习惯是：先场景法，再正交法，最后错误推测法。这个顺序能保证你既覆盖了业务流程，又覆盖了参数组合，还能补上经验性的漏洞。

3.5 本章知识体系

下面这张图，帮你把三种方法的核心逻辑串起来：

好了，这一章的内容就到这。三种方法各有侧重，但都是实战中必不可少的武器。你可以在自己的项目里试着用起来，慢慢就会找到感觉。