决策表测试的条件组合一旦膨胀，用例数量会迅速超出执行能力，真正需要保障的高风险规则反而被淹没。减少用例的关键是先把条件取值归并、把不影响结果的无关项合并，再排除不可达组合，并对低风险规则采用默认规则或抽样覆盖。本文按“量出现状—识别冗余—分步裁剪—判断代价—验证效果”的顺序展开，说明每一步保留哪些证据，以及如何确认关键业务规则仍然被覆盖。
要点总览（TL;DR）
- 先统计条件数、取值数、规则总数与已执行用例数，建立基线表，明确“用例数下降、关键规则命中率保持100%”的裁剪目标。
- 膨胀主要来自取值未归并、无关项未合并、约束未显式表达和风险等级未区分，四类冗余的判断依据各不相同。
- 裁剪按固定顺序执行：归并条件取值、合并无关项与等价规则、用约束排除不可达组合、低风险规则抽样、高风险规则单独保留。
- 规则频繁变更时合并逻辑需要持续维护，低频高影响的组合不适合抽样，每轮裁剪都要保留评审与回退记录。
- 用规则覆盖率、关键规则命中率、用例数与执行时间、缺陷发现情况做前后对照，漏测时回溯追溯表定位到具体裁剪动作。
先量出决策表的膨胀程度
裁剪之前需要一张能对照的基线表。没有基线，后续减少的用例数无法判断是消除了冗余，还是漏掉了规则。基线表至少记录四类信息：条件及每个条件的取值数、规则总数、当前已执行用例数、关键业务规则清单。
条件数与取值数决定理论组合规模。例如一张决策表有 6 个条件，每个条件 3 个取值，理论组合为 729 条；实际整理出的规则可能只有几十条，已执行用例又可能只覆盖其中一部分。这三个数字之间的差距，正好指出膨胀发生在哪一层：是取值没有归并导致组合爆炸，还是规则重复，还是用例只挑了部分规则执行。
| 基线项 | 记录内容 | 用途 |
|---|---|---|
| 条件与取值 | 条件名称、每个条件的取值个数、取值含义 | 计算理论组合规模，识别可归并的取值 |
| 规则总数 | 整理后的规则条数，标注有效规则、不可达组合、重复规则 | 确定可裁剪的规则基数 |
| 用例数 | 已编写用例数、已执行用例数、单轮执行耗时 | 作为裁剪前后对比的执行侧基线 |
| 关键规则清单 | 涉及资金、权限、合规、高频主流程的规则，逐条列出 | 作为裁剪中不可删减的保护名单 |
裁剪目标要写成可检验的表述：用例数下降到某个区间，同时关键规则命中率保持 100%，规则覆盖率不低于裁剪前。只写“减少用例”会失去约束，执行时容易把高风险规则一起删掉。
膨胀从哪里来：常见冗余与误区
条件组合过多通常有四类来源，每类的处理方式不同，判断依据也不同。把它们分开识别，才能区分哪些组合可以安全合并，哪些必须原样保留。
取值未归并，在笛卡尔积层面膨胀
条件取值按业务细节逐一列出，例如金额分成 0 元、1 元、100 元、101 元、1000 元、1001 元六档，而业务规则只在“是否超过 1000 元”处发生变化。这类取值应先做等价类归并，把对动作结果影响相同的取值合并为一类，再展开组合。判断依据是：两个取值在整张决策表中对应的动作列完全一致。
无关项未合并，产生重复规则
某个条件在特定规则下不影响动作结果，却仍被写成具体取值，导致多条规则实际表达同一业务含义。把该条件标为无关项（don’t care），这些规则即可合并为一条。判断依据是：合并后动作列不变，且不存在被合并规则之间的动作冲突。
约束未显式表达，产生不可达组合
条件之间存在互斥或依赖关系，例如“已实名”与“未实名”不会同时成立，某些取值组合在业务上永远不出现。这类组合不产生有效用例，应在决策表中显式写出约束并排除。判断依据是：该组合无法构造出真实的业务场景，或构造它需要违反已知业务前提。
风险等级未区分，平均用力
把所有规则按同一密度覆盖，会让低风险规则的用例挤占执行资源。涉及资金计算、权限判定、合规要求的规则需要逐条覆盖；提示文案、展示顺序等低风险规则可以采用默认规则或抽样。判断依据是规则失效后的业务影响范围，而不是规则出现的频率。
按优先级执行的合并与裁剪动作
裁剪按固定顺序执行，每一步都留下记录，避免多轮修改后无法回溯。建议顺序如下：
- 归并条件取值。对每个条件列出取值，按动作结果是否一致划分等价类，把同类取值合并。产出是归并后的条件取值表，注明每个等价类包含的原始取值。
- 合并无关项与等价规则。逐条比对规则，把不影响结果的条件标为无关项，合并动作列相同的规则。产出是合并后的规则表，每条规则标注它由哪些原始规则合并而来。
- 用约束排除不可达组合。把互斥、依赖关系写成显式约束，删除违反约束的组合。产出是约束清单和排除记录，说明每条被排除组合不可达的原因。
- 对低风险规则采用默认规则或抽样。为低风险规则设定默认动作，只保留少量代表性用例；抽样时优先选择边界值和近期变更涉及的取值。产出是抽样规则清单和抽样依据。
- 单独保留高风险与合规规则。把关键规则清单中的规则逐条保留为独立用例，并标注保留理由，例如涉及资金阈值、权限越权、监管报送。这些规则不参与合并和抽样。
每一步都要维护规则到用例的追溯关系。追溯表至少包含四列：原始规则编号、裁剪后规则编号、对应用例编号、处理方式（合并、排除、抽样、保留）。这张表是后续评审和回退的依据，也是验证阶段统计规则覆盖率的底稿。
裁剪后的规则与用例需要在测试管理工具中保持可查。ONES 测试管理支持用例与产品需求、研发任务关联，测试计划与迭代关联，可以把每条保留规则对应的用例挂到相应需求上；用例属性支持自定义，可用来记录规则编号、风险等级和处理方式；用例库属性支持筛选，便于按规则编号或风险等级快速找出对应用例。规则级追溯的具体呈现方式，建议在选型或落地时结合实际配置核验。
裁剪的适用前提与代价
合并与裁剪并非在所有情况下都划算。业务规则相对稳定、约束能够明确表达时，裁剪的收益最明显：一次归并可以在多个迭代中持续减少用例。规则频繁变更时，合并逻辑本身需要维护，每次规则调整都要检查等价类是否仍然成立、无关项标注是否失效，这部分维护成本会抵消部分收益。
| 情形 | 是否适合裁剪 | 需要注意的代价 |
|---|---|---|
| 规则稳定，约束可明确写出 | 适合，优先做取值归并与无关项合并 | 需要一次性投入整理基线表和追溯表 |
| 规则频繁变更 | 谨慎，缩小合并范围 | 每次变更需复核等价类与无关项标注，维护成本上升 |
| 存在低频但高影响的组合 | 不适合抽样，应保留独立用例 | 用例数下降幅度有限 |
| 合规或审计要求逐条留痕 | 保留原始规则与用例的完整对应 | 追溯表需要长期维护，不能随迭代清理 |
抽样覆盖的风险需要提前说明：低频组合在正常流量下很少触发，一旦触发往往影响面较大。对这类组合，判断依据应是失效后果而非发生概率，后果严重的组合不进入抽样范围。此外，每轮裁剪都应保留评审记录和回退方案，规则表、追溯表和用例集的变更纳入版本管理，出现漏测时可以定位到具体是哪一步合并或排除造成的。
如何验证裁剪后没有丢失关键规则
验证用裁剪前后的对照数据说话，指标口径在裁剪前就确定，避免事后挑选有利数字。建议对照以下四项：
| 指标 | 口径 | 观察方式 |
|---|---|---|
| 规则覆盖率 | 被至少一条用例覆盖的有效规则数 ÷ 有效规则总数 | 裁剪前后各统计一次，覆盖率不应下降 |
| 关键规则命中率 | 关键规则清单中被独立用例覆盖的条数 ÷ 清单总条数 | 目标为 100%，出现缺口即回退对应裁剪动作 |
| 用例数与执行时间 | 用例总数、单轮全量执行耗时 | 记录裁剪前后数值，确认减少来自冗余消除 |
| 缺陷发现情况 | 裁剪后若干轮执行中发现的缺陷数及所属规则 | 与裁剪前同口径对比，重点关注关键规则相关缺陷 |
举例说明口径（以下为演示假设，非实测数据）：某决策表原有 8 个条件、约 200 条规则、已执行用例 160 条。经过取值归并和无关项合并后规则降至 70 条，排除不可达组合 15 条，低风险规则抽样后用例降至 85 条，关键规则 20 条全部保留。裁剪后规则覆盖率从 78% 提升到 96%，关键规则命中率保持 100%，单轮执行时间相应缩短。这组数字只用于说明指标如何对照，实际项目中应以自身基线数据为准。
缺陷发现情况需要谨慎解读。裁剪后缺陷数下降，可能来自冗余用例减少，也可能来自覆盖范围缩小，两者需要结合规则覆盖率和漏测复盘区分。出现漏测时，回溯追溯表定位到具体规则和裁剪动作，判断是等价类划分有误、无关项标注过度，还是抽样范围过窄，再决定回退哪一步。相关性不等于因果，只有把缺陷对应到具体规则和裁剪记录，才能确认改进是否成立。
常见问题
条件取值已经按业务细节分得很细，归并等价类时如何避免把有差异的场景合并掉？
判断依据放在动作列上：两个取值在整张决策表中对应的动作结果完全一致，才可以归并为一类。归并时保留原始取值清单，注明每个等价类包含哪些取值，并检查边界值是否落在不同等价类中。如果某个取值只在个别规则下产生不同动作，应把它单独保留，而不是强行并入相邻类。归并结果建议经过业务方评审，确认没有把监管或合同约定的差异场景合并掉。
规则频繁变更的系统中，裁剪后的决策表如何维护才不至于失效？
缩小合并范围是主要手段：只对稳定条件做等价类归并，对易变条件保留原始取值。每次规则变更时，复核受影响的等价类划分和无关项标注，确认合并前提仍然成立。追溯表要记录每条裁剪后规则由哪些原始规则合并而来，变更时可以顺着追溯关系找到需要重新展开的规则。规则表、追溯表和用例集纳入版本管理，变更记录与迭代对应，便于回退。
低风险规则抽样覆盖时，抽样比例怎么定？
没有统一比例，取决于规则失效后的业务影响和近期变更情况。抽样时优先选择边界值、近期修改涉及的取值和历史上出过缺陷的规则。抽样规则清单要写明抽样依据，便于后续复盘。如果某条规则虽然当前判定为低风险，但失效后果涉及资金、权限或合规，应移出抽样范围，改为独立用例逐条覆盖。
裁剪后出现漏测，如何判断是哪一步造成的？
依靠追溯表逐层回溯：先确认漏测对应的原始规则编号，再查它在裁剪中被标记为合并、排除、抽样还是保留。如果是合并造成的，检查等价类划分是否把动作结果不同的取值并到了一起；如果是排除造成的，检查约束条件是否写得过宽；如果是抽样造成的，检查抽样范围是否漏掉了该组合。定位到具体动作后，只回退该步，保留其他裁剪成果，并补充一条针对该规则的用例。
裁剪后的规则与用例对应关系，在测试管理工具中如何承载？
常见做法是把规则编号、风险等级、处理方式写成用例的自定义属性，并让用例与对应需求或任务建立关联。ONES 测试管理支持用例与产品需求、研发任务关联，用例属性支持自定义，用例库属性支持筛选，可以按规则编号或风险等级筛出对应用例（依据 F1、F2、F4）。规则级追溯的具体呈现形式，建议在选型或落地时结合实际配置核验。
