判定表法：条件桩与动作桩、判定表结构、化简规则、实战案例

判定表法，说白了就是一张“如果…那么…”的逻辑表格。你想想看，我们做测试时最怕什么？最怕漏掉某个条件组合。判定表就是专门解决这个问题的。

我个人习惯，拿到一个功能点，先别急着写用例。先画判定表。把条件列清楚，动作理明白，再化简。这样写出来的用例，覆盖率有保障，冗余也少。

条件桩与动作桩

判定表由四个部分组成。我一个个说。

• 条件桩：列出所有可能的输入条件。比如登录功能，“用户名是否正确”、“密码是否正确”、“验证码是否正确”。
• 动作桩：列出所有可能的输出结果。比如“登录成功”、“提示用户名错误”、“提示密码错误”。
• 条件项：针对每个条件桩，列出其取值。通常是“真”或“假”，用Y/N或1/0表示。
• 动作项：针对每个条件组合，列出对应的动作。

我在项目中遇到过，有同事把“用户名正确”和“密码正确”写成了“登录信息正确”。这就麻烦了。因为“登录信息正确”包含了两个子条件，一旦拆分，判定表就乱了。记住，条件桩必须是原子性的。

判定表结构

标准的判定表长这样：

条件桩 / 动作桩	规则1	规则2	规则3	规则4
用户名正确	Y	Y	N	N
密码正确	Y	N	Y	N
登录成功	✓
提示用户名错误			✓	✓
提示密码错误		✓

你看，4条规则覆盖了所有组合。这就是判定表的力量——穷举所有可能性。

但这里有个坑。如果条件有3个，规则数就是2³=8条。4个条件就是16条。条件越多，表格越膨胀。怎么办？化简。

化简规则

化简的核心思想：合并那些“无论某个条件如何，结果都一样”的规则。

举个例子。假设登录功能里，只要“用户名错误”，不管密码对不对，都提示“用户名错误”。那这两条规则就可以合并。合并后的条件项用“-”表示，代表“任意值”。

化简后的判定表：

条件桩 / 动作桩	规则1	规则2	规则3
用户名正确	Y	Y	N
密码正确	Y	N	-
登录成功	✓
提示用户名错误			✓
提示密码错误		✓

从4条变成了3条。别小看这一条。在大型系统中，化简能减少30%-50%的用例量。

实战案例：登录功能

我们拿一个真实的登录功能来练手。假设需求如下：

• 用户名和密码都正确 → 登录成功
• 用户名错误 → 提示“用户名不存在”
• 用户名正确但密码错误 → 提示“密码错误”
• 用户名或密码为空 → 提示“请输入用户名/密码”

这里有个新条件：是否为空。所以条件桩有3个：

1. 用户名是否为空
2. 用户名是否正确
3. 密码是否正确

注意顺序。先判断是否为空，再判断是否正确。这是业务逻辑决定的。

完整的判定表（化简前）有8条规则。化简后，我得到5条：

条件/动作	规则1	规则2	规则3	规则4	规则5
用户名为空	Y	N	N	N	N
用户名正确	-	Y	Y	N	N
密码正确	-	Y	N	Y	N
提示输入用户名	✓
登录成功		✓
提示密码错误			✓
提示用户名不存在				✓	✓

你看，规则4和规则5，用户名错误时，不管密码对不对，都提示“用户名不存在”。合并了。

实战案例：购物车优惠

再来看一个复杂点的。购物车优惠计算。需求：

• 用户是VIP会员，且购物车金额满200元 → 打8折
• 用户是VIP会员，但金额不满200元 → 打9折
• 用户不是VIP会员，但金额满200元 → 打9.5折
• 用户不是VIP会员，且金额不满200元 → 不打折
• 如果使用了优惠券，则以上折扣均不生效，直接使用优惠券面额

条件桩：

1. 是否VIP会员
2. 金额是否满200元
3. 是否使用优惠券

动作桩：

1. 打8折
2. 打9折
3. 打9.5折
4. 不打折
5. 使用优惠券

化简前8条规则。化简后：

条件/动作	规则1	规则2	规则3	规则4	规则5
使用优惠券	Y	N	N	N	N
VIP会员	-	Y	Y	N	N
金额满200	-	Y	N	Y	N
使用优惠券	✓
打8折		✓
打9折			✓
打9.5折				✓
不打折					✓

规则1中，只要用了优惠券，其他条件无所谓。直接合并了3条规则。

判定表法知识体系

下面这张图，是我总结的判定表法核心知识结构。你可以把它当作一个速查地图。

判定表法，说白了就是结构化思维。把模糊的需求变成清晰的表格。我每次做测试设计，都会先问自己：这个功能有多少个独立条件？每个条件有多少种取值？然后画判定表。嗯，这步做完，心里就有底了。

最后说一句。判定表不是万能的。条件太多（超过5个）时，表格会变得庞大。这时候可以考虑用正交法或因果图法。但大多数场景下，判定表是最直观、最不容易出错的方法。