决策表测试在研发团队落地，核心是把业务规则整理成条件与动作的完整组合表，再按规则列派生用例、标注预期结果，并把决策表作为评审与回归维护的基线。本文按“划定范围—收集规则—建表—化简合并—派生用例—评审—纳入回归”的主线，说明每一步的输入、动作与产出，并给出字段规范、角色分工、完整示例和完成检查清单，帮助测试负责人把方法变成团队可重复执行的动作。
要点总览（TL;DR）
- 落地决策表测试的主线是：划定范围、收集条件与动作、建初始表、化简合并、按规则列派生用例、评审、纳入回归，每一步都有明确的输入与完成标志。
- 决策表由条件桩、条件项、动作桩、动作项和规则列组成，无关项只能用于动作结果一致的列，合并前需业务角色确认。
- 测试负责人主导建表与用例派生，产品与业务角色确认规则与优先级，开发核对条件边界与不可达组合，规则维护按模块指定责任人。
- 判断是否落地到位，看每条规则列是否至少对应一条用例、用例与动作项是否一致、规则变更是否触发用例同步，三者齐备才纳入回归。
决策表测试落地的核心步骤
落地决策表测试不需要一次覆盖所有功能，先选一个规则密集、条件组合容易出错的模块试点，跑通一轮完整流程后再推广。以下七个步骤构成一条可执行的主线，每一步都明确输入、动作、输出和完成标志，团队可以据此排期和检查进度。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 划定范围 | 需求文档、业务规则说明、历史缺陷记录 | 选出条件多、分支多、规则交叉的功能，明确本次建表的边界 | 范围说明：功能清单与不纳入的部分 | 范围经产品与测试双方确认，无歧义 |
| 2. 收集规则 | 需求、原型、接口说明、业务方口述规则 | 逐条摘出判断条件和对应处理动作，标注规则来源 | 条件清单与动作清单 | 每条规则都能追溯到需求条目或业务确认 |
| 3. 建初始决策表 | 条件清单、动作清单 | 把条件填入条件桩、动作填入动作桩，按组合展开规则列 | 初始决策表 | 所有已知条件和动作都已入表，无遗漏项 |
| 4. 化简合并 | 初始决策表 | 识别等价规则与无关项，合并可合并的列，检查是否有矛盾或不可达组合 | 化简后的决策表 | 每一列都对应一个可执行的业务场景，合并理由有记录 |
| 5. 派生用例 | 化简后的决策表 | 按规则列逐条编写用例，写明输入条件取值、操作步骤和预期结果 | 用例集，每条用例标注对应规则列编号 | 每条规则至少有一条用例覆盖，用例可独立执行 |
| 6. 评审 | 决策表、用例集 | 组织产品、开发、测试共同核对规则正确性与覆盖完整性，记录结论和修改项 | 评审记录与修订后的表、用例 | 评审结论明确，修改项闭环 |
| 7. 纳入回归 | 评审通过的决策表与用例 | 把用例加入回归集，指定规则变更时的同步责任人和更新方式 | 回归用例集与维护约定 | 规则变更能触发对应用例更新，形成固定动作 |
推进时有两个节奏上的建议。建表阶段由测试负责人集中完成初稿，避免多人同时编辑造成结构混乱；化简合并阶段要拉上开发一起看，因为部分条件组合在代码层面不可达，只有开发能判断哪些列可以合并或删除。完成标志不是“表画完了”，而是“每一列都能说清对应哪个业务场景、由谁确认过”。
决策表的字段结构与填写规则
一张可评审的决策表由四个部分组成：左上条件桩、左下动作桩、右上条件项、右下动作项，纵向的每一列构成一条规则。填写规范决定了这张表能否被他人读懂并直接派生用例。
条件桩与条件项
条件桩列出所有影响处理结果的判断条件，每个条件写成可判定的陈述，例如“订单金额是否满 200 元”“用户是否为会员”，避免写成“订单情况”这类无法取值的描述。条件项是每个条件在各规则列中的具体取值，常用“是/否”“Y/N”或枚举值表示。条件之间尽量相互独立，如果一个条件的取值依赖另一个条件，考虑拆成两个条件或调整顺序。
动作桩与动作项
动作桩列出系统在特定条件组合下要执行的处理，例如“打 9 折”“赠送优惠券”“拒绝下单”。动作项在对应规则列中标记该动作是否执行，通常用“√”或“×”。动作描述要具体到可观察的结果，便于直接转成预期结果。
规则列与组合覆盖
规则列是条件项与动作项的一组纵向组合，代表一个完整的业务场景。初始建表时按条件的全部取值组合展开，规则列数等于各条件取值数量的乘积。组合数较多时，先保证业务上真实存在的组合全部列出，再对不可能出现的组合做标注，而不是直接删除。
无关项与合并写法
当某个条件的取值不影响动作结果时，该单元格填“—”，表示无关项。利用无关项可以把多列合并为一列，减少规则数量。合并的前提是这些列的动作项完全一致，且条件取值的差异确实不改变处理逻辑。误用无关项是常见问题：把“暂时没想到差异”写成无关项，会掩盖真实规则，合并前应由业务角色确认。
预期结果的标注位置
预期结果直接写在动作项区域，动作项标记为执行的动作即为该规则的预期结果。对于需要校验具体数值或文案的场景，在动作描述后补充取值说明，例如“打 9 折（实付金额 = 原价 × 0.9）”。派生用例时，预期结果从动作项原样转写，保证表与用例一致。
角色分工与各环节交付物
决策表测试的落地效果很大程度取决于角色边界是否清楚。测试负责人主导建表与用例派生，产品与业务角色确认规则和优先级，开发参与条件边界与实现约束核对，评审结论和后续维护都要落到具体的人。
| 角色 | 主要动作 | 交付物 | 交接对象 |
|---|---|---|---|
| 测试负责人 | 划定范围、建初始决策表、化简合并、派生用例、组织评审 | 决策表、用例集、评审议程 | 产品、开发、评审参与人 |
| 产品/业务角色 | 提供规则来源、确认条件与动作的完整性、标注规则优先级 | 规则确认意见、优先级说明 | 测试负责人 |
| 开发 | 核对条件边界取值、指出不可达组合、说明实现约束 | 边界核对记录、合并建议 | 测试负责人 |
| 评审组织者 | 召集评审、记录结论与修改项、跟踪闭环 | 评审记录、修改项清单 | 全体参与人 |
| 规则维护责任人 | 规则变更时更新决策表、同步用例、通知回归执行人 | 变更记录、更新后的表与用例 | 回归执行人 |
规则维护责任人建议按功能模块指定，由最熟悉该模块规则的测试人员担任，避免所有变更集中到一个人身上造成积压。规则变更的记录至少包含变更内容、影响的条件列、对应更新的用例编号和确认人，这样回归时能快速判断哪些用例需要重跑。
当决策表和派生用例需要在团队内长期维护时，可以借助测试管理工具承载。ONES 测试管理支持编写测试用例、组织用例库，并支持自定义用例属性，团队可以为用例增加“规则列编号”“决策表版本”等属性，便于按规则回溯；用例库支持树状结构组织，所有用例属性都支持筛选，规则变更后能较快定位受影响用例。用例与需求、任务关联，测试计划与迭代关联，评审结论和变更记录可以跟随工作项流转，减少表与用例脱节的情况。具体字段配置需结合团队实际环境确定。
示例：一个订单优惠规则的决策表与用例
以下示例为演示情景，用于说明从规则到决策表再到用例的转化过程，不代表任何真实业务系统的完整规则。
示例业务规则描述
某订单优惠规则：订单金额满 200 元且用户为会员时，打 9 折并赠送优惠券；订单金额满 200 元但用户非会员时，仅打 9 折；订单金额不满 200 元时，会员赠送优惠券，非会员无优惠。所有情况下订单状态正常才执行优惠，订单已取消则不处理。
初始决策表
| 条件/动作 | R1 | R2 | R3 | R4 | R5 | R6 | R7 | R8 |
|---|---|---|---|---|---|---|---|---|
| 订单状态正常 | Y | Y | Y | Y | Y | Y | Y | N |
| 金额满 200 元 | Y | Y | Y | Y | N | N | N | — |
| 用户为会员 | Y | Y | N | N | Y | Y | N | — |
| 打 9 折 | √ | √ | √ | √ | × | × | × | × |
| 赠送优惠券 | √ | √ | × | × | √ | √ | × | × |
化简合并过程
观察初始表，R1 与 R2 的条件项完全相同，属于重复列，合并为一列。R5 与 R6 同样重复，合并为一列。R8 中订单状态为 N，金额和会员条件均为无关项，动作全部不执行，单独保留一列表示取消场景。合并后规则列从 8 列减少为 5 列：满 200 元会员、满 200 元非会员、不满 200 元会员、不满 200 元非会员、订单取消。合并时需由业务角色确认 R1 与 R2 确实不存在隐藏差异，例如不同渠道的优惠上限，确认后再合并。
派生出的用例与预期结果
| 用例编号 | 对应规则列 | 输入条件 | 操作步骤 | 预期结果 |
|---|---|---|---|---|
| TC-01 | 满 200 元会员 | 订单 250 元，会员，状态正常 | 提交订单并结算 | 实付 225 元，账户到账 1 张优惠券 |
| TC-02 | 满 200 元非会员 | 订单 250 元，非会员，状态正常 | 提交订单并结算 | 实付 225 元，无优惠券 |
| TC-03 | 不满 200 元会员 | 订单 150 元，会员，状态正常 | 提交订单并结算 | 实付 150 元，账户到账 1 张优惠券 |
| TC-04 | 不满 200 元非会员 | 订单 150 元，非会员，状态正常 | 提交订单并结算 | 实付 150 元，无优惠 |
| TC-05 | 订单取消 | 任意金额，任意会员状态，订单已取消 | 对已取消订单触发结算 | 不执行折扣与赠券，返回取消状态提示 |
示例的适用边界需要说明：这里只覆盖了金额、会员、订单状态三个条件，实际业务中可能还有优惠叠加、渠道限制、时间窗口等条件，条件增加后规则列会成倍增长，需要重新评估组合数量和化简空间。示例中的金额阈值和折扣比例仅用于演示，落地时应以实际业务规则为准。
落地完成检查与常见问题
判断决策表测试是否真正落地，可以按以下清单逐项核对。清单同时适用于试点模块验收和后续模块推广前的自检。
决策表覆盖完整性检查项
- 所有已知条件都已进入条件桩，每个条件有明确取值，无“其他”“视情况”这类模糊表述。
- 每个动作都能对应到可观察的系统结果，动作项标记完整。
- 业务上真实存在的条件组合全部出现在规则列中，不可能出现的组合有标注和理由。
- 合并后的每一列都有业务确认记录，无关项的使用经过业务角色核对。
用例与规则列对应关系检查
- 每条规则列至少对应一条用例，用例中标注了规则列编号。
- 用例的输入条件取值与规则列条件项一致，预期结果与动作项一致。
- 不存在只存在于用例中、决策表未体现的隐藏规则。
规则变更同步检查
- 规则变更时有变更记录，写明影响的条件列和用例编号。
- 决策表版本与用例集版本保持对应，旧版本可追溯。
- 变更后的用例已通知回归执行人，回归范围有明确说明。
常见偏差与处理方式
| 偏差 | 表现 | 处理方式 |
|---|---|---|
| 组合遗漏 | 规则列只覆盖了常见场景，边界组合缺失 | 按条件取值做组合核对，补充缺失列并标注来源 |
| 无关项误用 | 把未确认的差异写成“—”，合并后掩盖真实规则 | 合并前由业务角色逐列确认，保留确认记录 |
| 表与用例脱节 | 决策表更新后用例未同步，或用例中有表外规则 | 建立规则列编号与用例编号的双向对应，变更时同步更新 |
纳入回归的门槛
决策表与用例纳入回归集前，应满足三个条件：规则经产品与业务角色确认，评审结论中的修改项全部闭环，用例能独立执行且预期结果明确。满足门槛后，把用例加入回归集并指定维护责任人，规则每次变更都触发对应用例的复核，决策表测试才算形成可持续的机制，而不只是一次性的文档产出。
常见问题
试点模块应该怎么选，选错了会有什么影响？
试点模块建议满足三个特征：条件数量适中（大约三到五个条件）、规则来源清晰、近期有需求变更或缺陷集中。条件太少体现不出决策表的价值，条件太多则组合数膨胀，第一轮容易卡在化简环节。选错模块的典型影响是团队把大量时间花在梳理模糊规则上，误以为方法本身成本过高。如果某个模块的业务规则本身还在频繁变动，可以等规则稳定一轮后再建表，或先只覆盖已确认的部分并标注待定列。
条件组合数量很大时，是否必须全部展开成规则列？
不必一次展开全部组合。可以先列出业务上真实存在的组合，对不可能出现的组合做标注并写明理由，再借助无关项合并动作结果一致的列。合并的前提是差异确实不影响处理逻辑，且经过业务角色确认。如果条件数量多到难以人工核对，可以按条件分组分批建表，例如先固定订单状态，再展开金额与会员条件，最后合并成一张总表。无论采用哪种方式，未覆盖的组合都应有记录，避免后续误以为已经覆盖。
规则在迭代中发生变化，决策表和用例怎么同步更新？
建议把规则变更当作一次小型评审来处理：变更提出时记录影响的条件列和用例编号，由规则维护责任人更新决策表并调整对应用例，再通知回归执行人确认重跑范围。决策表保留版本记录，旧版本可追溯，便于判断某条用例对应的是哪一版规则。若团队使用测试管理工具承载用例，可以为用例增加“规则列编号”“决策表版本”等自定义属性，变更后按属性筛选定位受影响用例；ONES 测试管理支持自定义用例属性并支持按属性筛选，具体字段配置需结合团队实际环境确定。
决策表和普通测试用例集是什么关系，会不会重复维护？
决策表是规则的结构化表达，用例是可执行的验证步骤，两者是源与派生的关系，不构成重复维护。做法是让每条用例标注对应的规则列编号，预期结果从动作项转写，规则变更时先改表再改用例，用例中不另写表外规则。检查时反向核对：用例里出现的判断条件是否都能在决策表中找到，找不到就说明表有遗漏。这样维护成本集中在一处，评审时也能按规则列逐条核对覆盖情况。
评审会上产品和开发各自需要确认什么，评审结论怎么算闭环？
产品与业务角色确认条件的完整性、动作描述是否符合业务预期、规则优先级是否合理；开发确认条件边界取值、哪些组合在实现上不可达、是否存在未写入需求的实现约束。评审结论闭环的判断标准是：每条修改意见都有明确处理结果（采纳并修改、确认无需修改、转为待定并记录原因），修改后的表与用例经过确认人复核。仅有会议记录而修改项未回填，不算闭环，也不建议此时纳入回归。
