判定表法：从条件到动作的精准映射

说实话，我刚入行那会儿，最怕的就是那种「条件多、结果乱」的测试场景。比如登录权限，光角色就有五六种，再加上各种操作权限，组合起来简直让人头大。后来我学会了判定表法，才算是找到了门道。

判定表法，说白了就是一张「如果…那么…」的对照表。它能把复杂的业务逻辑拆得清清楚楚。你想想看，当你有多个条件组合时，每个组合对应什么结果，用判定表一列，一目了然。

判定表的结构

判定表由四个部分组成，我习惯叫它们「四桩两件」：

• 条件桩：列出所有可能的输入条件。比如「是否登录」「是否VIP」。
• 动作桩：列出所有可能的输出动作。比如「允许访问」「弹出提示」。
• 条件项：每个条件的具体取值。比如「是/否」「真/假」。
• 动作项：每个条件组合下，应该执行的动作。

举个例子，我做过一个优惠券发放系统。条件桩是「用户是否新注册」「订单金额是否满100」「是否使用过优惠券」。动作桩是「发放10元券」「发放5元券」「不发券」。你看，这样一拆，逻辑就清晰了。

建立判定表的步骤

我总结了一套五步法，用了好多年，屡试不爽：

1. 列出所有条件桩——把业务规则中的输入条件全写出来，一个别漏。
2. 列出所有动作桩——每个条件组合对应的输出结果。
3. 填写条件项——每个条件取Y/N，组合数就是2的n次方（n是条件个数）。
4. 填写动作项——根据业务规则，每个组合填上对应的动作。
5. 化简合并——去掉冗余组合，合并相同结果的列。

嗯，这里要注意。第3步的组合数可能会很大。如果条件超过4个，组合数就超过16了。我建议先做等价类划分，把条件减少到4个以内，再用判定表。

实战案例一：登录权限

我记得有一次，一个后台系统的权限逻辑特别绕。管理员、编辑、访客三种角色，有的页面只能看，有的能编辑，有的完全不让进。我用判定表一列，问题全暴露了。

假设条件桩有三个：

• C1：是否已登录（Y/N）
• C2：角色是否为管理员（Y/N）
• C3：目标页面是否公开（Y/N）

动作桩有两个：

• A1：允许访问
• A2：跳转到登录页

判定表如下：

条件/动作	规则1	规则2	规则3	规则4	规则5	规则6	规则7	规则8
C1: 已登录	Y	Y	Y	Y	N	N	N	N
C2: 管理员	Y	Y	N	N	Y	Y	N	N
C3: 公开页面	Y	N	Y	N	Y	N	Y	N
A1: 允许访问	✓	✓	✓		✓		✓
A2: 跳转登录						✓		✓

你看，规则4和规则8都要求跳转登录。规则4是「已登录、非管理员、非公开页面」——说白了就是权限不够。规则8是「未登录、非管理员、非公开页面」——根本没登录。这两种情况虽然条件不同，但动作一样，可以合并。

实战案例二：优惠券发放

另一个经典场景是优惠券发放。业务规则是这样的：

• 新用户注册后，发放10元券
• 老用户订单满100元，发放5元券
• 如果用户已经领过同类券，不再发放
• 大促期间，所有用户额外发放8折券

条件桩：

• C1：是否新用户（Y/N）
• C2：订单金额≥100（Y/N）
• C3：是否已领同类券（Y/N）
• C4：是否大促期间（Y/N）

动作桩：

• A1：发放10元券
• A2：发放5元券
• A3：发放8折券
• A4：不发券

这里组合数有16种。我挑几个典型的说说：

规则	C1	C2	C3	C4	A1	A2	A3	A4
1	Y	-	N	N	✓
2	N	Y	N	N		✓
3	-	-	Y	-				✓
4	-	-	-	Y			✓

注意看，规则1中C2是「-」，表示「任意值」。因为新用户不管订单金额多少，都发10元券。这就是判定表的化简技巧——用「-」代替Y/N，减少冗余列。

判定表法的核心逻辑

为了让你更直观地理解，我画了一张流程图。它展示了从条件到动作的完整映射过程：

这张图你看懂了吗？条件桩和条件项是输入，经过判定表的规则匹配，输出对应的动作项。说白了，判定表就是一张「查表」——你给我条件组合，我告诉你该做什么。

总结一下

判定表法特别适合那些「条件多、逻辑复杂」的场景。我个人习惯在以下情况优先使用：

• 业务规则有3-6个条件
• 每个条件只有两个取值（Y/N）
• 动作结果与条件组合强相关

如果条件超过6个，我建议先做等价类划分，或者拆成多个子判定表。否则组合数太多，判定表本身就成了负担。

嗯，最后说一句。判定表法不是万能的，但它是我见过的最直观的逻辑梳理工具。你试试看，用一次就会爱上它。

可可精品资料库