第4章测试用例设计方法（下）

4、测试用例设计方法（下）：判定表驱动法、正交实验法、场景法、错误推测法

好，咱们接着聊。上一节我们把等价类和边界值讲透了，这两个方法虽然基础，但说实话，覆盖不了所有场景。你想想看，有时候输入条件之间是互相影响的，一个条件成立与否，直接决定了另一个条件要不要测。这时候，就得请出我们今天的主角们了。

判定表这玩意儿，说白了就是用来处理「多个条件组合」的。我刚开始带项目时，有个同事写了个登录模块，测试时发现密码错误和账号锁定两个状态同时出现时，系统直接崩溃了。为什么？因为开发只考虑了单一条件，没做组合测试。

判定表的核心结构很简单：

举个例子，一个简单的登录校验：

你看，4种组合，一目了然。我曾经在一个支付系统里用过判定表，条件有「余额充足」「风控通过」「商户状态正常」三个，组合出来8种情况。结果发现有一种组合（余额不足+风控通过+商户异常）开发根本没处理，直接抛了500错误。这就是判定表的威力——把逻辑漏洞照得清清楚楚。

我的小技巧：条件超过4个时，判定表会膨胀得很快（2^n）。这时候我一般先做条件合并，把互斥的条件先干掉，再画表。

判定表虽好，但条件一多就扛不住了。比如你有6个条件，每个条件2个取值，那就是2^6=64种组合。真要全测，时间成本扛不住。这时候正交实验法就派上用场了。

正交实验法的核心思想是：用最少的用例，覆盖最广的组合。它基于一个数学原理——任意两个条件的组合，至少出现一次。

我习惯用L9(3^4)这种符号来表示：

举个例子，一个搜索功能有3个条件：

全组合是2×3×2=12种。用正交表，我选L4(2^3)就够了：

你看，4个用例就覆盖了所有两两组合。排序方式「相关度」没出现？嗯，这里要注意，正交表不是100%覆盖所有组合，它只保证两两组合。如果你的业务要求必须覆盖某个特定组合，那就得额外加用例。

避坑指南：我曾经在一个电商项目里，用正交表测了商品筛选功能，结果漏掉了一个「价格区间+品牌」的组合，导致线上用户筛选时出现了空结果。后来我学乖了——正交表做完后，一定要补上业务上最关键的几个组合。

前面几种方法，都是从「输入条件」出发。但有时候，用户的操作流程才是关键。场景法就是干这个的——模拟用户真实的使用路径。

场景法分两种：

拿网购下单来说：

我一般画场景法时，会先画一个流程图。把基本流画成一条直线，备选流像树枝一样分出去。然后每个分支写一个测试用例。这样做的好处是——你永远不会漏掉用户的操作路径。

我记得有一次测一个银行转账功能，基本流很顺畅。但备选流里有个「转账途中账户被冻结」的场景，开发没处理，结果用户转账到一半，钱扣了但对方没收到。这就是场景法的价值——它逼着你去想「如果用户不按套路出牌怎么办」。

    核心要点：场景法不是用来替代其他方法的，而是用来补充的。我一般先用等价类和边界值搞定输入，再用场景法搞定流程。

这个方法，说白了就是「猜」。但猜得有依据，不是瞎猜。错误推测法依赖的是测试人员的经验积累——你知道哪些地方容易出问题，就重点测哪里。

常见的错误推测方向：

我曾经测过一个文件上传功能，大家都测了正常上传、大文件上传、格式错误上传。但我凭经验推测——如果上传过程中网络断了会怎样？一试，果然，文件只上传了一半，系统显示上传成功，但实际文件损坏了。这就是错误推测法的价值——它不靠公式，靠的是你对系统的理解。

我个人的习惯是，每次测试一个新系统，先花半小时做错误推测。把最容易出问题的点列出来，优先测。等这些点都过了，再去做系统性的测试。这样效率最高。

我的经验清单：每次项目结束后，我会把这次发现的bug分类整理，加到自己的「错误推测清单」里。下次遇到类似系统，直接拿出来用。积累个三五年，你也能成为「猜bug」的高手。

好了，这四种方法讲完了。你可能会问，实际项目中到底用哪个？我的建议是：判定表用于逻辑组合，正交表用于参数组合，场景法用于流程测试，错误推测法用于查漏补缺。没有哪个方法能包打天下，组合使用才是王道。