4、判定表法：判定表结构、条件桩与动作桩、实战案例（优惠券发放逻辑）
大家好，我是老赵。今天咱们聊聊判定表法。
说实话，我刚入行那会儿，最怕的就是那种「条件多、逻辑绕」的需求。比如优惠券发放，什么满减、新用户、限时、品类限制……各种条件搅在一起，写测试用例写到怀疑人生。后来我学会了判定表法，嗯，这玩意儿真能救命。
4.1 判定表长什么样？
判定表，说白了就是一个「条件-动作」的对照表。它把所有的条件组合都列出来，然后告诉你每种组合下该做什么。
我个人习惯把判定表分成四个部分：
- 条件桩：列出所有可能的条件。比如「是否新用户」、「是否满减」。
- 动作桩：列出所有可能的动作。比如「发放优惠券」、「不发放」。
- 条件项：针对每个条件，列出它的取值（真/假、是/否）。
- 动作项：针对每个条件组合，列出对应的动作。
举个例子，一个最简单的判定表：
| 条件桩 | 规则1 | 规则2 | 规则3 | 规则4 |
|---|---|---|---|---|
| 是否新用户？ | 是 | 是 | 否 | 否 |
| 是否满100元？ | 是 | 否 | 是 | 否 |
| 动作桩 | 规则1 | 规则2 | 规则3 | 规则4 |
| 发放10元券 | ✓ | |||
| 发放5元券 | ✓ | |||
| 不发放 | ✓ | ✓ |
4.2 条件桩与动作桩：怎么拆？
很多同学问我：「老赵，条件桩和动作桩怎么分？感觉分不清啊。」
其实很简单。你想想看，条件桩是「输入」，动作桩是「输出」。条件桩是那些你无法控制、只能判断的东西，比如用户属性、订单金额。动作桩是系统要执行的操作，比如发券、弹窗、记录日志。
我在项目中遇到过一个问题：产品经理把「是否发放优惠券」既当条件又当动作。这其实不对。条件应该是「是否满足发放条件」，动作才是「发放优惠券」。记住这个原则，就不会搞混。
4.2.1 条件桩的提取原则
- 互斥性：条件之间不能有隐含的依赖关系。比如「是否新用户」和「是否老用户」就是互斥的，不能同时出现。
- 完整性：所有影响结果的条件都要列出来。漏掉一个，测试就不全。
- 原子性：每个条件应该是不可再分的最小单元。比如「是否满100元且是新用户」应该拆成两个条件。
4.2.2 动作桩的提取原则
- 可观测性：每个动作都应该是系统能执行、测试能验证的。比如「发送短信」可以验证，「提升用户体验」就没法测。
- 唯一性：同一个条件组合下，动作应该是确定的。不能既发券又不发券。
4.3 实战案例：优惠券发放逻辑
好了，理论说完了，咱们来点实际的。这是我从真实项目中提炼出来的案例。
4.3.1 需求描述
假设我们要测试一个优惠券发放系统。规则如下：
- 用户必须是新用户或者老用户且累计消费满500元，才能获得优惠券。
- 如果用户是新用户，发放10元无门槛券。
- 如果用户是老用户且满500元，发放8折券（最高减50元）。
- 如果用户是老用户但未满500元，不发放。
- 所有用户如果在活动期间内，额外发放5元券。
嗯，这个需求有点绕。咱们用判定表来拆解。
4.3.2 提取条件桩和动作桩
先看条件：
- 条件1：是否新用户？（是/否）
- 条件2：是否老用户且满500元？（是/否）——注意，这个条件只在「非新用户」时有效。
- 条件3：是否在活动期间？（是/否）
再看动作：
- 动作1：发放10元无门槛券
- 动作2：发放8折券（最高减50元）
- 动作3：发放5元券
- 动作4：不发放
4.3.3 构建判定表
3个条件，理论上2³=8种组合。但有些组合是无效的，比如「新用户」且「老用户且满500元」——这不可能同时成立。所以实际有效的组合只有5种。
| 条件桩 | 规则1 | 规则2 | 规则3 | 规则4 | 规则5 |
|---|---|---|---|---|---|
| 是否新用户？ | 是 | 是 | 否 | 否 | 否 |
| 是否老用户且满500元？ | — | — | 是 | 是 | 否 |
| 是否在活动期间？ | 是 | 否 | 是 | 否 | — |
| 动作桩 | 规则1 | 规则2 | 规则3 | 规则4 | 规则5 |
| 发放10元无门槛券 | ✓ | ✓ | |||
| 发放8折券 | ✓ | ✓ | |||
| 发放5元券 | ✓ | ✓ | |||
| 不发放 | ✓ |
注意看，规则5中「是否在活动期间」我填了「—」，表示这个条件不影响结果。因为老用户且未满500元，不管是不是活动期间，都不发放。这就是判定表的优势——一眼就能看出哪些条件组合是冗余的。
4.3.4 从判定表到测试用例
判定表画完了，测试用例也就出来了。每个规则就是一条测试用例。比如：
- 用例1：新用户，活动期间 → 发放10元无门槛券 + 5元券
- 用例2：新用户，非活动期间 → 发放10元无门槛券
- 用例3：老用户且满500元，活动期间 → 发放8折券 + 5元券
- 用例4：老用户且满500元，非活动期间 → 发放8折券
- 用例5：老用户且未满500元 → 不发放
4.4 判定表法的优缺点
说了这么多，咱们客观评价一下判定表法。
4.4.1 优点
- 全覆盖：所有条件组合都列出来了，不会漏测。
- 可视化：一张表就能看清所有逻辑，沟通成本低。
- 易维护：需求变了，改表就行，不用重新想用例。
4.4.2 缺点
- 组合爆炸：条件超过5个，表就变得很大。我见过一个项目有8个条件，256种组合，画完表人都傻了。
- 不擅长处理顺序：判定表只关心「条件组合」，不关心「条件出现的顺序」。如果逻辑有先后依赖，判定表就不好使了。
4.5 小结
判定表法，说白了就是「穷举条件，匹配动作」。它特别适合那种「条件多、逻辑复杂」的场景。你想想看，如果没有判定表，你可能会漏掉某个条件组合，导致线上出bug。有了判定表，一张表就能搞定所有测试用例。
嗯，今天就聊到这儿。下一章咱们讲正交实验法，那个更适合「条件多但组合可以精简」的场景。到时候见。