判定表与因果图

• 因果图的基本逻辑符号（AND/OR/NOT）
• 因果图到判定表的转换
• 从需求提取因果的设计能力

因果图中，原因是条件（输入），结果是动作（输出），用逻辑门连接。AND 表示多个原因同时成立结果才成立，OR 表示任一原因成立结果即成立，NOT 表示对原因取反。以"订单提交"为例：原因是"库存充足"、"金额>0"、"用户已登录"，结果是"订单创建成功"。若规则为"用户已登录 且 金额>0 且 (库存充足 或 允许缺货下单)"，则因果图为：登录与金额相与，再与（库存充足或允许缺货）相与，得到"订单创建成功"。绘制因果图时，先列出所有原因与结果，用逻辑门连接，再标注约束（互斥/包含/唯一），最后把因果图展开为判定表：每一列对应一个原因组合（条件项），结果列标出该组合下的动作。判定表可直接转化为测试用例，每一行条件组合即一个用例。

因果图的价值在于把需求中的"隐蔽逻辑关系"显式化，帮助发现遗漏条件与矛盾规则；判定表则把因果图落地为可执行的用例矩阵。逻辑门（AND/OR/NOT）是最基本的组合工具，理解其语义是掌握因果图的前提。转换时要注意"因果图节点多、判定表列数=2^n"的爆炸，需借助约束与合并控制规模。

• 完全展开与折叠的含义
• 展开的完备性与折叠的简洁性
• 工程决策因素

完全展开指把所有条件组合（2^n 列）全部列出，每一列对应一个明确的条件项与动作，牺牲简洁性换取完整性——好处是覆盖所有组合、无遗漏、便于追溯，坏处是组合多时规则数爆炸、维护困难。collapse（折叠）指在保证逻辑等价的前提下，把"动作相同且其余条件相同、仅一列条件项不同"的相邻列合并为一行，用"—"（任意/不关心）表示，以大幅减少规则数——好处是简洁、易读、成本低，坏处是可能掩盖"不同条件组合"的差异，需谨慎确认合并不改变逻辑。工程取舍原则：安全关键/需要逐条可追溯的场景倾向完全展开；常规业务规则多、需控制评审与维护成本的场景倾向折叠，并用加权/决策树推导来保证折叠正确。

完全展开与折叠是"完备性"与"简洁性"的权衡。完全展开保证无遗漏但代价高，折叠提升效率但需验证逻辑等价。工程上通常"先展开再折叠"：先完整列出所有组合确保覆盖，再合并动作相同的列得到精简判定表，既保证设计时无遗漏，又保证评审与维护时足够简洁。折叠后的等价性校验可用真值表或逻辑推导确认。

• limited-entry：条件项为真/假/任意
• extended-entry：条件项为具体值/范围
• 两者的适用场景

limited-entry（受限条目）判定表中，条件项只取"真（T）/假（F）/任意（—）"三种布尔值，动作项也只取"执行/不执行"，适合条件是布尔判断的业务规则。extended-entry（扩展条目）判定表中，条件项可以取具体值或范围（如"金额>100""状态=已支付"），动作项也可以标记具体动作，表达能力更强，适合条件是多种取值或几种类型共存的规则。工程差异在于：limited-entry 结构规整、易读易维护、适合二进制条件；extended-entry 表达力强、能直接容纳多值条件，但表格更复杂、更易出现条件项书写不一致。选择依据是条件的本质：若是"是否"型则用 limited-entry，若是"取值/范围"多变则用 extended-entry。

limited-entry 与 extended-entry 的差异本质是"条件项的表达粒度"。limited-entry 把一切条件抽象为布尔，结构统一但表达受限；extended-entry 允许条件携带具体取值，更贴近真实业务但更复杂。工程上常混用：用 limited-entry 表达布尔条件，用 extended-entry 表达多值条件，二者结合能平衡表达力与可读性。

• 因果图基本运算符语义
• 因果图与决策表的转化
• 工程协同流程

因果图的基本符号包括：identity（恒等，原因成立结果即成立）、not（非，原因成立结果不成立）、and（与，多因同时成立结果成立）、or（或，任一因成立结果成立）、xor（异或，恰有一个因成立结果成立）、nand（与非，多因同时成立时结果不成立）。这些符号用于表达需求中原因与结果之间的逻辑关系。与决策表的协同是：先分析需求，用因果图把原因、结果及逻辑关系画出来，标出约束（互斥/包含/唯一/要求），再按"每个原因组合对应一列"展开为判定表，最后把判定表转化为测试用例。因果图负责"逻辑建模与缺陷发现"，决策表负责"结构化落地与用例生成"，前者发现逻辑矛盾，后者保证覆盖完整。

因果图是"图"，擅长表达逻辑关系与发现条件矛盾；决策表是"表"，擅长穷举条件组合以保证覆盖。两者的协同是测试设计中的经典范式：因果图帮助理解并核对业务逻辑，决策表把逻辑转化为可执行用例。掌握各符号语义（尤其 xor/nand 的细微差别）是正确建模的前提。

• 判定表四要素
• 化简规则（合并相同动作列）
• 化简的等价性保证

判定表由四部分组成：条件桩（列出所有条件，如"金额>100"）、动作桩（列出所有动作，如"打9折"）、条件项（针对各条件桩的具体取值，如 T/F/—）、动作项（针对各条件组合要执行的动作）。各行规则对应一个条件组合。化简规则是：若两列或多列除"一个条件项不同"外其余条件项相同，且动作也相同，则可以把这些列合并为一列，用"—"（任意/不关心）表示该不同的条件项，从而减少规则数。例如"金额>100 且 会员=是"与"金额>100 且 会员=否"都打9折，则可合并为"金额>100"且"会员=—"打9折。化简时需保证合并后的列不改变任何原始组合的执行结果，即逻辑等价。

判定表化简的本质是"找出冗余条件"——当某条件对动作结果无影响时，它就是冗余的，可用"—"替代。化简后判定表不仅更简洁，还能暴露"哪些条件实际不影响决策"这一业务洞察。化简的正确性由"合并后每个原始组合的结果不变"保证，这是化简的核心约束。

• Impossible（不可能）与 Any（任意）约束
• 约束消减规则数的原理
• 化简的正确性

判定表简化通过两类约束减少规则数量。一是 Impossible（不可能/无效）约束：某些条件组合在业务上不可能发生（如"支付方式=货到付款"与"金额=0"），这样的组合被标记为 Impossible 并从规则中剔除，从而直接减少"需要考虑的规则数"。二是 Any（任意/不关心）约束：当某条件对动作结果无影响时，用"—"表示任意取值，从而把多个条件列合并为一行。两者综合原理是"缩小合法组合空间 + 合并等价组合"，使规则数从 2^n 大幅下降。化简时需确认：Impossible 组合确实不可能（有业务依据），Any 合并不改变逻辑（合并前后动作结果一致），否则化简会引入错误。

规则爆炸的根源是"所有条件组合都被当成需要覆盖"，而实际上很多组合在业务上不可能或对结果无影响。Impossible 从"语义上"排除不可能组合，Any 从"逻辑上"合并等价组合，二者是控制判定表规模的两大杠杆。化简的正确性由"业务依据"与"逻辑等价"双重保证。

• 因果图约束（E、I、O、R、M 约束）
• 各约束的适用边界
• 约束的工程价值

因果图在原因与原因之间、结果与结果之间可以标注约束：E（Exclude，互斥）——至多一个成立；I（Include/At least one，至少一个成立）；O（One and only one，恰好一个成立）；R（Requires，要求——一个成立要求另一个也成立）；M（Mask，屏蔽——一个结果成立则屏蔽另一个结果）等。这些布尔约束用来表达"同时满足的逻辑关系"之外的限制。工程边界在于：约束只能表达"同一时刻"的静态逻辑关系，无法表达时序依赖、状态保持或动态变化（如"先登录后支付"这种时序），因此因果图适用的边界是"无时序、无状态组合"的纯组合逻辑；对有时序/状态的场景应改用状态转换图。约束的工程价值是让因果图更贴近真实业务，减少生成不可能组合的用例。

因果图的约束（E/I/O/R/M）是在"逻辑门"之上的"语义约束"，用于剔除逻辑上不成立或业务上不允许的组合。但约束本质是静态的，无法表达时间维度的依赖，这是因果图表达能力的边界。理解这一边界，才能判断何时用因果图、何时应改用状态转换图或时序建模。

• 约束关系的识别（互斥/包含/唯一/要求）
• 因果图到判定表的转换步骤
• 由判定表生成用例

转换步骤为：第一步，从需求中识别所有原因（输入/条件）与结果（动作/输出），并识别约束关系——互斥（两条件不能同时成立）、包含（至少一个成立）、唯一（恰好一个成立）、要求（一个成立要求另一个成立）。第二步，据此绘制因果图，用逻辑门连接原因与结果，并标注约束。第三步，把因果图展开为判定表：列出所有条件桩与动作桩，枚举原因组合（2^n 列），对每个组合判定结果与动作，并剔除被约束排除的组合。第四步，把判定表每一列转化为一个测试用例，覆盖条件组合与期望动作。例如"支付方式=cash 或 card、金额>0、库存充足"等条件的组合，在判定表中逐列确定是否"支付成功"。

这一流程的核心是"先建模、后落地"：因果图帮助从需求中梳理约束与逻辑，判定表把模型穷举为用例。约束识别（互斥/包含/唯一/要求）是保证模型正确的关键，避免生成"逻辑上不可能"的组合。最终判定表每一行即一个用例，实现"设计即用例"的无缝衔接。

• 判定表与等价类/边界值的分工
• 判定表高效的多条件组合场景
• 规则爆炸的控制

等价类/边界值擅长"单字段取值空间"的划分，判定表擅长"多字段条件组合"的表达。当业务规则由多个条件共同决定动作（如"满减 + 会员折扣 + 优惠券叠加"），且条件间存在组合关系时，判定表比逐项等价类更高效——因为逐项等价类只覆盖"每个字段举几个值"，会漏掉"字段间组合"决定的规则分支；而判定表穷举条件组合，保证每个规则分支都被覆盖。避免规则爆炸的方法：先用约束剔除不可能组合（Impossible），再用 Any 合并等价列，必要时用 Pairwise 而非全组合（对条件多、组合非关键的场景）。即"等价类划分取值域 + 判定表表达组合 + 约束/Pairwise 控制规模"。

判定表的高效在于"组合覆盖"，这正是等价类/边界值覆盖不到的维度。但判定表随条件数呈 2^n 爆炸，因此加工重点是"先约束、后合并、必要时抽样"。工程上通常先用等价类/边界值选定每个字段的取值，再把这些取值作为判定表条件项取值，从而既保证取值覆盖又保证组合覆盖。

• 复杂业务规则的条件桩提取
• 条件桩数量与规则数的关系
• 控制规则数的方法

复杂业务规则（如保险核保）中，条件桩从业务规则中提取的原则是：把对"决策结果"有区分力的条件作为条件桩，剔除对结果无影响的因素。例如核保规则中，条件桩可能为"年龄区间""疾病史""体检结果""既往理赔记录"，每个条件桩取值为若干水平（如年龄分档）。规则数 = 各条件桩水平数的乘积，故需控制：一是合并水平（把相近年龄分档减少到必要数），二是剔除无关条件（用独立判据验证某条件对结果无影响），三是用约束排除不可能组合，四是必要时用 Pairwise 覆盖。优惠计算中，条件桩为"会员等级×优惠券×满减门槛"，审批流中条件桩为"金额级别×审批人层级×是否加急"。落地时用判定表把"条件组合→动作"映射为规则，供规则引擎或人工执行。

复杂业务规则的核心挑战是"条件多、规则多、易矛盾"。判定表的价值是结构化表达"条件组合→动作"，条件桩提取的关键是"只保留对决策有区分力的条件"。控制规则数要"减水平、删无关、加约束、用 Pairwise"，否则规则会随条件数爆炸。这也是保险、电商、审批等规则密集型系统的标准做法。

• 两者适用场景的区分
• 输入依赖与逻辑关系的表达
• 判据

判定表适合"条件已明确、逻辑相对直接、重点是穷举组合"的场景，此时直接列出条件桩、动作桩、条件项、动作项即可高效生成用例，不必先画因果图。因果图适合"需求中隐藏的逻辑关系复杂、条件之间存在依赖/约束、需要先梳理输入之间的逻辑结构"的场景——此时直接列判定表容易遗漏或误解条件间的关系，应先画因果图把原因、结果与逻辑门、约束显式化，再转换成判定表。简单说：逻辑清晰、条件独立时用判定表；逻辑隐蔽、条件有依赖或约束时用因果图梳理后再转判定表。因果图是"分析工具"，判定表是"落地工具"。

判定表解决"覆盖"问题，因果图解决"理解"问题。当需求逻辑已清晰、直接列判定表即可；当需求逻辑复杂、条件间有隐含依赖或约束，需先用因果图建模以防遗漏。因此边界判据是"逻辑是否清晰、条件是否独立"，而非简单地二选一。

• 规则数 = 2^n 的爆炸原理
• 约束、合并控制规模
• 正交表作为替代方案

当每个条件桩是二值（T/F）时，规则数 = 2^n（n 为条件桩数），条件桩每增加一个，规则数翻倍，5 个条件即 32 条规则、6 个即 64 条，容易爆炸。控制规模的手段有三类：一是约束（Impossible）——剔除业务上不可能的组合，直接减少有效规则数；二是合并（Any/折叠）——把对结果无影响的条件用"—"合并，多列合一；三是当条件的组合覆盖率要求不高时，改用正交表/Pairwise——只覆盖两两组合（或 t 组合）而非全组合，把用例数从 2^n 降到接近线性/平方级。工程上"先约束、再合并、必要时正交"，在保证覆盖与成本间平衡。

2^n 爆炸是判定表的固有数学特性，控制手段本质是"减少组合空间"（约束）与"降低覆盖要求"（合并/正交）。约束保留全部逻辑组合但剔除不可能者，合并保留行为但压缩冗余，正交则牺牲部分高阶组合换取规模可控。三者按需组合，是判定表规模化应用的关键。

• 判定表在需求评审中的价值
• 矛盾规则、遗漏条件、不可达组合的识别
• 评审方法

判定表在需求评审中的价值是"把文字需求转成结构化矩阵，让逻辑漏洞显形"。评审时逐列检查：矛盾规则——同一条件组合在需求中规定了两个不同动作（同一列动作矛盾），或不同条件组合却给出冲突结果，说明需求存在歧义；遗漏条件——某些条件组合没有定义动作（动作列为空），说明需求遗漏了该场景的处理；不可达组合——某些条件组合逻辑上不可能（如互斥条件同时为真），说明需求存在冗余或错误描述。评审方法：先建判定表，再逐列核对"每个组合是否有且仅有一个合理动作"，对缺失/矛盾/不可达的组合标记并回需求确认。这能显著提升需求评审的严谨性。

判定表是需求评审的"逻辑显微镜"：它强制把所有条件组合显式化，使"没写到的组合""写冲突的组合""写矛盾的组合"一目了然。评审关注点就是"覆盖完整性、动作一致性、组合可达性"三点，一旦发现空动作、矛盾动作或不可达组合，即需求缺陷，需与需求方澄清。

• 因果图的静态组合本质
• 时序依赖与状态保持的表达局限
• 状态转换测试的替代

因果图本质是"静态组合逻辑"模型，它表达的是"同一时刻条件组合与结果的关系"，无法表达"事件发生的先后顺序"和"状态随时间的保持与变化"。时序依赖（如"先注册后登录""先下单后支付"）和状态保持（如"登录后一直保持登录态直到退出"）涉及时间维度的前后关系，因果图无法刻画。此类场景应改用状态转换测试（State Transition Testing）或状态图建模：把系统状态（如"未登录/已登录/已下单/已支付"）作为节点，把事件（如"登录/登出/下单/支付"）作为迁移，用状态转换图表达"状态下某事件→迁移到新状态"的时序关系，并设计状态覆盖、迁移覆盖、路径覆盖用例。

因果图只关心"输入组合→输出"，不关心"顺序与状态"，这是其表达边界。状态转换模型专门处理"状态+事件+迁移"的时序语义，是时序/状态类需求的标准方法。理解这一边界，能正确选择测试设计技术，避免用因果图硬套时序场景。

• 正交表的思想与原理
• 正交表 vs 判定表全组合
• 因子与水平的确定

正交实验法（Orthogonal Array Testing）用正交表从全组合中挑选"均匀分散、整齐可比"的代表性组合，使得任意两个因子的各水平组合都至少出现一次，从而用少量试验覆盖条件组合的主要交互。当条件多到判定表全组合（2^n）规则爆炸时，改用正交表能把用例数从指数级降到接近"因子数×水平数"的平方级，同时在覆盖与成本间保持平衡。确定因子与水平的方法是：因子即影响结果的条件（条件桩），水平即每个因子的取值（如高/中/低）。先确定因子集合与各因子水平数，再选择或构造匹配的正交表（如 L9(3^4) 表示4因子3水平9次试验），按表生成用例。适合水平数相同或相近、组合交互以两两为主、无需全组合覆盖的场景。

正交表是"全组合"的统计学抽样替代，它保证"两两覆盖"（任意两因子各水平组合出现）而牺牲高阶组合，这与 Pairwise 思想一致，但正交表有严格的"均衡性"（正交性）。因子与水平确定是前提：因子过多或水平过密会让正交表规模也过大，故需先合并无关因子、精简水平。这与"约束+合并"共同控制判定表爆炸。

• 规则引擎的规则冲突与优先级
• 默认规则的作用
• 判定表测试的落地

规则引擎（如 Drools）中，同一输入可能命中多条规则，需测试规则冲突、优先级与默认规则三类行为。规则冲突测试：精心构造"同时满足多条规则"的输入，验证引擎按预定优先级（salience、规则顺序）执行，且执行结果符合预期而不产生歧义/歧义告警。优先级测试：设计优先级相邻与反转的规则，验证高优先级规则先执行、低优先级规则在其后执行或被覆盖。默认规则测试：构造"不命中任何常规规则"的输入，验证默认规则（兜底规则）被正确触发，返回合理的默认结果而非无动作或异常。设计时把规则转成判定表（条件桩+动作桩），逐规则核对"命中条件→动作→优先级"，再针对冲突、边界、缺失场景补充用例。还需验证规则条件重叠、优先级相等时的行为确定性。

规则引擎测试的核心是"规则集整体行为"，而非单条规则。冲突、优先级、默认规则是规则集最容易出错的三处，需专门构造"多规则命中""优先级竞争""无规则命中"的场景。判定表把规则结构化，便于核对"条件→动作"映射与优先级，是规则引擎测试的标准工具。

• 判定表 → 数据驱动用例的映射
• CSV/JSON 表达判定表
• 规则变更的同步维护

判定表可参数化为数据驱动用例：把判定表每一列（一个条件组合+动作）转为数据文件中的一行，字段为条件项取值与期望动作，测试代码读取数据文件逐行执行并断言动作。CSV 适合简单表格、便于非技术成员编辑；JSON 适合嵌套结构、可表达复杂条件与期望结果。落地时，判定表的条件桩映射为数据行的输入字段，动作桩映射为期望结果字段，每行即一个用例。随规则变更同步维护的关键是"单一数据源"：判定表作为唯一事实来源，规则变更时同步更新判定表与数据文件（或通过脚本从判定表生成数据文件），并建立基线/版本管理，避免规则与用例脱节。这样规则变更时只需改数据行，测试代码逻辑不变。

判定表的数据驱动落地把"设计表"与"测试数据"统一，实现"一条规则一行数据"，可维护性高。核心是"单一数据源"治理——判定表驱动数据文件，避免人肉同步造成规则与用例不一致。CSV/JSON 的选择取决于表格复杂度与协作方式。

• 判定表与审批流/状态机的结合
• 条件桩→流程条件，动作桩→状态变更
• 组合技术与状态模型的协同

审批流/状态机类业务中，判定表可用来表达"当前状态下，给定条件组合，应执行哪个动作/迁移到哪个状态"。条件桩映射为流程节点的判断条件（如"金额级别""审批人层级""是否加急""当前节点"），动作桩映射为流程动作与状态变更（如"通过""驳回""转交""状态迁移到已通过/已驳回"）。例如审批流中，条件桩"金额>1万""需要总经理审批"，动作桩"流转到总经理审批节点"。设计时把"当前状态+触发条件"作为条件桩，把"目标状态+动作"作为动作桩，逐列定义状态迁移规则。但需注意：状态流的核心是"状态+事件+迁移"的时序语义，判定表只表达"组合→动作"的静态映射，故应把判定表与状态转换图结合——状态图表达状态拓扑，判定表定义每个状态下条件组合对应的迁移动作。

判定表适合表达"在某状态下，条件组合决定迁移动作"的决策逻辑，但状态机本身的时序结构（哪些迁移合法、状态如何流转）需用状态转换图表达。二者结合：状态图定拓扑与合法性，判定表定义每个状态下的条件化决策，覆盖"条件→动作"与"状态→迁移"两个维度。

• 化简等价性的含义
• 真值表校验方法
• 化简正确性的保证

判定表化简（合并相同动作列）后，必须验证化简未改变原始逻辑，即"化简前后对任意条件组合，动作结果一致"。等价性验证方法：对化简前的原始判定表与化简后的判定表分别构建真值表（枚举所有条件组合，查找各自命中的动作），逐组合比对两个表的动作是否一致；若所有组合动作一致，则化简等价。若用"—"（任意）合并，验证时需对"—"展开为所有取值，逐一确认动作不变。更严谨的做法是用逻辑推导或借助工具（如 SAT/真值表工具）自动化校验。凡化简后出现"某组合动作改变"即化简错误，需回退。真值表校验是化简正确性的最直接保障。

化简的收益是"简洁"，但代价是"可能引入等价性错误"。真值表校验通过穷举所有组合比对新旧表，是验证化简正确性的金标准。工程上"化简后必须校验等价"是一条铁律，避免为追求简洁而破坏规则正确性。