决策表规则膨胀通常来自条件枚举过细、组合全展开和历史规则叠加，表现为规则行数快速增加、评审难以逐条读完。化简的核心做法是先建立可追溯的规则基线，再按“同结果可合并、无关条件标为不关心、不可达组合删除、关键规则单独保留”四类动作处理，并记录每次合并或删除的依据。这样既能减少规则行和用例数量，也能让合规、金额、权限等关键业务规则保持可判定、可复核。
要点总览（TL;DR）
- 决策表膨胀多来自条件枚举过细、组合全展开和历史规则叠加，化简前先建立包含规则列数、条件数、变更记录和业务例外清单的基线。
- 按同结果合并、无关条件标为不关心、不可达组合删除、关键规则白名单四类动作依次处理，每步在化简日志中记录改动列与依据。
- 合规、金额、权限、退款等关键规则独立成列，由业务方和测试负责人共同确认白名单，不参与合并。
- 化简成立依赖规则来源可追溯、业务方参与确认和规则相对稳定；不关心标注与化简日志需要随规则变更同步维护。
- 用化简前后规则对照表、业务场景抽样比对和条件取值覆盖核对验证关键规则未丢失，回归用例覆盖白名单规则与合并边界。
当前做法与化简目标
决策表一般由条件桩、动作桩和规则列组成：每一列是一条规则，列出各条件取值与对应动作。规则膨胀指规则列数量超出评审和用例维护可承受的范围，常见于促销、风控、计费、审批等条件组合密集的业务。先盘点现状，才能判断哪些行可以化简、哪些必须保留。
膨胀的典型来源可以归为三类。第一类是条件枚举过细，把本可归为一类的取值拆成多个条件行，例如把“会员等级”拆成六个独立条件。第二类是组合全展开，对所有条件做笛卡尔积，把业务上不会同时出现或结果相同的组合也各列一行。第三类是历史规则叠加，新规则追加在旧规则之后，旧规则未清理，形成语义重叠的多行。
化简目标应写成可检验的表述：减少规则列数量，同时保证每条关键业务规则仍能在表中找到唯一、明确的判定结果；化简前后的规则对应关系可追溯；用于回归的用例能覆盖关键规则。本文讨论范围限于用例设计层面的规则整理与化简，不涉及测试脚本实现，也不涉及跨项目测试资产复用。
建议先产出一份现状基线，包含：当前规则列总数、条件个数、动作个数、近三次变更记录、已知的业务例外清单。基线的作用是给后续每一步化简提供对照物，避免化简完成后无法说明改动了什么。
规则膨胀背后的瓶颈与常见误区
直接删规则之所以会丢业务规则，原因在于规则行数与业务规则数量并不等价。一个业务规则可能对应多行条件组合，多行也可能只是同一规则的不同写法。化简中的误区多来自把这两者混为一谈。
| 误区 | 典型表现 | 可能后果 |
|---|---|---|
| 把条件组合多等同于规则多 | 看到几十列就按列删减，未分析列间语义 | 删掉的是同一规则的不同组合，关键分支被误删 |
| 合并时未区分结果不同的规则 | 条件相近就合并，忽略动作列差异 | 不同处理结果被压成一条，判定结果出错 |
| 把业务例外当冗余删除 | 低频例外被视为“用不到”而移除 | 合规、退款、特殊权限等场景失去判定依据 |
| 缺少规则来源追溯 | 表中无需求编号、业务依据或变更记录 | 化简后无法向业务方证明规则仍完整 |
这些误区的共同点是缺少判定依据：删或并之前没有回答“这条规则对应哪条业务要求、结果是否相同、组合是否可达”。因此化简的第一步是补齐追溯信息，再进入动作阶段。把误区与后果对应起来记录，也有助于在评审时说服业务方接受化简方案。
优先改进动作：四类化简与保留策略
四类动作有先后顺序：先合并同结果规则，再标注无关条件，然后删除不可达组合，最后确认关键规则白名单。每完成一步，都在规则基线中记录被改动的规则列、改动类型和依据，形成化简日志。
动作一：同结果规则合并
判定条件是两个规则列的动作完全一致，且条件取值可以归并为同一语义类别。例如多个会员等级在折扣动作上结果相同，可合并为“会员等级为高价值类”一行，并在备注中列出归并的原始取值。合并后需检查归并是否改变边界，例如等级归并是否影响后续条件判断。
动作二：无关条件标注为不关心
当某条件在特定规则下不影响动作结果时，将该单元格标为“不关心”（don’t care），用符号统一表示。这样可以把原本因该条件取值不同而拆开的多列压缩为一列。标注时要写明“为什么不影响”，例如“该分支在支付前拦截，与配送方式无关”。不关心标注越多，表越紧凑，但每个标注都需要业务确认，否则会掩盖真实的条件依赖。
动作三：不可达或互斥组合的识别与删除
不可达组合指业务上不可能同时成立的条件取值，例如“未实名认证”与“已开通高级权限”同时为真。识别方法包括：对照业务状态机检查条件间约束、与业务方逐条确认、检查历史用例是否出现过该组合。确认不可达后删除对应规则列，并在化简日志中记录判定依据，避免后续被误认为遗漏。
动作四：关键业务规则白名单
合规校验、金额计算、权限判定、退款与冲正等规则，即使条件组合看似可合并，也应单独保留为独立规则列，并在表中标注“关键规则”。白名单由业务方和测试负责人共同确认，确认结果写入基线。白名单规则不参与前两类化简，只允许在不改变判定结果的前提下调整表述。
| 动作 | 判定条件 | 保留原则 | 记录要求 |
|---|---|---|---|
| 同结果合并 | 动作一致且条件可归并 | 归并后边界不变 | 记录原始取值与归并依据 |
| 不关心标注 | 该条件不影响本列动作 | 业务方确认无隐性依赖 | 记录不影响的原因 |
| 不可达删除 | 条件组合业务上不可能成立 | 有状态约束或业务确认支撑 | 记录判定依据与确认人 |
| 关键规则保留 | 涉及合规、金额、权限等 | 独立成列，不参与合并 | 记录白名单确认结果 |
四类动作完成后，规则列数量通常明显下降，但每列承载的信息更集中。此时应重新通读整张表，检查是否存在因合并产生的语义重叠列，以及不关心标注是否让某列变得过于宽泛。规则基线与化简日志可以放在需求或测试用例管理工具中维护，例如在ONES中把规则来源关联到需求条目、把化简评审记录留在工作项下，便于后续变更时追溯。这一步只解决记录承载问题，化简判断仍由业务与测试人员完成。
适用前提与化简代价
化简成立的前提有三项：规则来源可追溯，每条规则能对应到需求、业务口径或历史缺陷；业务方参与确认，尤其是不关心标注和不可达判定；规则本身相对稳定，短期内不会频繁变更。缺少任一项时，化简结果可能无法评审通过，或很快失效。
化简需要付出维护成本。不关心标注需要随业务变化同步复核，一旦条件重新变得相关，标注必须撤销；规则变更时，化简日志和基线要同步更新，否则追溯链断裂。评审成本也会转移：表变短了，但每列的语义更密集，评审人需要结合日志才能理解合并过程。
以下情形不适合直接化简：规则尚在频繁调整、业务口径存在争议、关键规则边界尚未与业务方达成一致。此时应先稳定规则来源，再启动化简。化简后决策表的可读性与评审成本需要权衡：过度压缩会让单列承载过多语义，反而增加理解难度，建议以评审人能逐列复述判定逻辑为可读性下限。
效果验证：怎么确认关键规则没丢
验证的目标是证明化简前后关键业务规则的判定结果一致。建议用三张核对表配合回归用例完成，所有结论来自实际核对记录，不预设比例或数字。
- 化简前后规则对照表：逐条列出白名单规则和业务例外，标注化简后对应的规则列，确认每条关键规则仍有唯一判定结果。
- 业务场景抽样验证：按业务频次和风险选取场景，分别用化简前后的决策表推导动作结果，比对是否一致；不一致的列回到化简日志查找原因。
- 覆盖核对：检查条件取值与动作结果的组合覆盖，确认每个条件取值至少出现在一条规则中，每个动作至少被一条规则触发。
回归用例应覆盖白名单规则、被合并规则的原始边界取值、被标注不关心的条件在极端取值下的表现，以及被删除的不可达组合所依据的业务约束。规则变更后，复核机制包括：变更时更新基线与化简日志、重新执行关键规则对照、在评审中确认白名单是否调整。效果指标可记录规则列减少数、关键规则覆盖数、回归用例通过情况，具体数值以实际核对记录为准。
常见问题
决策表化简后，业务方仍认为规则不完整，通常是什么原因？
常见原因有三类：一是化简日志没有记录被合并规则的原始取值，业务方无法确认归并边界；二是不可达组合的删除缺少业务确认人，被视为遗漏；三是关键规则白名单未经业务方共同确认，合规或例外场景被当作普通规则合并。处理方式是回到规则基线，补齐每条改动对应的需求或业务依据，并邀请业务方逐条复核白名单和删除项。
不关心标注用多了会不会掩盖真实的条件依赖？
会。不关心标注的前提是该条件在当前规则下确实不影响动作结果，并且业务方确认不存在隐性依赖。如果标注时只凭测试人员判断，后续业务规则变化后，原本无关的条件可能重新变得相关，标注就会掩盖真实依赖。建议每个不关心标注都写明原因和确认人，并在规则变更时优先复核这些标注。
规则还在频繁调整时，是否应该先化简再继续迭代？
规则尚在频繁调整、业务口径存在争议时，直接化简容易返工。此时可以先做轻量整理：补齐规则来源追溯、标记明显重复的规则列、记录待确认的不可达组合，把合并和删除动作留到规则稳定后再执行。规则稳定后再按四类动作完整化简，并同步更新基线与化简日志。
化简后规则列变少，回归用例是否也要相应减少？
规则列减少不等于用例可以减少。回归用例需要覆盖白名单规则、被合并规则的原始边界取值、不关心条件在极端取值下的表现，以及被删除不可达组合所依据的业务约束。用例数量应根据这些覆盖点确定，而不是按规则列数等比例缩减。化简后应重新核对覆盖关系，确认每个关键规则仍有对应用例。
化简记录和规则基线放在哪里维护比较合适？
关键是让规则来源、化简依据和评审记录能被后续变更的人查到。可以把规则基线关联到需求条目，把化简日志和评审结论留在对应工作项下，使规则变更时能沿同一处追溯。例如在ONES中通过需求与测试用例的关联承载规则来源，评审记录随工作项留存，便于复核白名单和删除项。具体承载方式按团队现有工具链选择即可。
