约 5 分钟4 张卡

判定表

判定表把条件组合与对应动作放在同一张表中，用来检查“满足这些条件时，系统到底应该做什么”。它适合优惠、权限、运费等多条件共同决定结果的规则，也能暴露需求中没有说明的组合。

例如，“会员免运费”和“无法配送时拒绝订单”同时成立时，应该先拒绝还是直接创建免运费订单？写成判定表后，这个优先关系就必须得到明确答案。

1. 面试核心

先记住这几条，再读正文

判定表中的每一列是一条条件组合与动作规则。先列条件，再列动作，不用当前代码的分支顺序替代需求规则。卡 · 条件与动作
完整布尔组合数量随条件数增长，可行组合的动作应明确且不冲突。缺少结果也是需要澄清的问题。卡 · 规则缺漏与精简
条件可以标为无关的前提是该条件所有可行取值都不改变当前规则的结果。无关不是未知，也不是不想测。卡 · 规则缺漏与精简
不可行组合需要约束证据，不能把当前界面无法操作误当成服务端永远收不到。输入非法时的拒绝行为仍可能需要单独测试。卡 · 不可行组合

2. 条件与动作

卡 · 多个条件共同决定优惠或权限时，怎样建立判定表？

先看一组已经确认的示例规则：目的地不可配送时拒绝订单；可配送时，会员或者商品金额满 100 元免运费；其余订单收取 10 元运费。金额本身已通过合法性校验，会员身份由服务端确认。

这里有三个布尔条件：可配送 D、会员 M、满 100 元 A。三者均可独立取真或假，所以完整组合有 2³ = 8 个。

条件／动作	R1	R2	R3	R4	R5	R6	R7	R8
可配送 D	否	否	否	否	是	是	是	是
会员 M	否	否	是	是	否	否	是	是
满 100 元 A	否	是	否	是	否	是	否	是
拒绝订单	是	是	是	是	否	否	否	否
运费	不计算	不计算	不计算	不计算	10 元	0 元	0 元	0 元

R3 说明不可配送的会员仍应被拒绝。若代码先判断会员直接返回免运费，且调用方误把报价成功当成可以创建订单，这列就能暴露规则优先级错误。

“不计算”也是有含义的动作约定：不能偷偷创建订单后再报错。涉及持久化时，测试需要确认拒绝后没有生成订单或扣减资源。

3. 规则缺漏与精简

卡 · 判定表中的一列没有明确结果，应怎样处理？卡 · 判定表里的“—”代表什么，什么时候可以合并列？

判定表首先用来检查规则是否完整，然后才考虑减少重复。若某列无法填写，应该记录待确认问题；若两条需求要求同一组合执行相反动作，就要明确优先级或修改规则。

在本例中，D=否 时，会员和金额都不改变拒绝结果。可将 R1—R4 合成一列，并把无关条件写成 —：

条件／动作	S1	S2	S3	S4
可配送 D	否	是	是	是
会员 M	—	是	否	否
满 100 元 A	—	—	是	否
结果	拒绝	运费 0 元	运费 0 元	运费 10 元

S1 包含四个原始组合，S2 包含两个，S3、S4 各包含一个，合计仍为八个，而且互不重叠。这里的精简保持了原规则的含义。

精简后的每列选一个代表，能够覆盖四类规则，但没有实际执行八个原始组合。若担心程序错误地让会员绕过配送检查，仍应保留 R3 或 R4；“表可以合并”和“这些输入永远没有必要测试”是两个不同判断。

4. 从表到测试

卡 · 多个条件共同决定优惠或权限时，怎样建立判定表？

每条可行规则都要能转成输入和断言。对“满 100 元”这一条件，还要先用边界值分析确定 99.99、100.00 等具体金额及精度约束。判定表处理条件组合，不能替代每个条件自身是否算对的检查。

下面的可运行小例子核对八个布尔组合，金额转换、会员查询和实际下单不在函数范围内：

from itertools import product

def shipping_result(deliverable, member, enough):
    if not deliverable:
        return "REJECT"
    return 0 if member or enough else 10

# 顺序对应 D、M、A 各自按 False、True 枚举。
expected = ["REJECT", "REJECT", "REJECT", "REJECT", 10, 0, 0, 0]
for conditions, result in zip(product([False, True], repeat=3), expected):
    assert shipping_result(*conditions) == result, conditions

print("8 rules checked")