决策表测试是一种用表格梳理业务规则、再据此设计测试用例的黑盒方法。它把影响结果的条件、条件取值、系统动作逐项列清，按规则行覆盖各种组合，适合判断逻辑中多个条件相互牵制的场景。理解它的组成、转换步骤和适用边界，能帮助测试人员把复杂规则写清楚、测完整。
要点总览（TL;DR）
- 决策表测试是以决策表为设计依据生成测试用例的黑盒方法，用条件桩、条件项、动作桩、动作项四要素把多条件组合与系统动作对应成规则行。
- 转换用例时按规则行逐条生成，一条规则至少一条用例；不可达或动作一致的规则行可合并，条件多时按风险取舍控制组合规模。
- 等价类和边界值面向单个输入的取值划分，决策表面向多条件组合下的规则判断，三者可先用取值收敛、再用决策表组织组合。
- 决策表行数不等于用例数，填完表也不等于覆盖完整，还需核对条件桩遗漏、合并合理性和规则与用例的对应关系。
- 决策表应作为设计资产进入用例编写、评审与维护，在ONES中可用文档承载决策表、用工作项关联用例并跟踪评审状态。
决策表测试的直接答案
决策表测试是以决策表为设计依据生成测试用例的方法。测试人员先识别业务判断中涉及的条件和系统要执行的动作，把条件取值与动作结果的对应关系整理成表格，每一列代表一条完整规则，再按规则逐条设计用例，验证系统在特定条件组合下的行为是否符合预期。
它回答的核心问题是：当多个条件同时影响结果时，系统的处理是否符合既定规则。例如订单能否提交，可能同时取决于库存是否充足、收货地址是否在配送范围、支付方式是否可用。单看某一个条件无法判断结果，只有把条件组合起来，才能确认系统在每种情形下执行了正确的动作。决策表把这些组合显性化，让遗漏和冲突更容易被发现。
这项工作的产出物有两项：一张结构完整的决策表，以及由规则行转化出的测试用例。决策表是设计说明，用例是可执行的验证单元，两者保持对应关系，后续评审和维护都以这张表为参照。
决策表的组成与规则表达
一张标准决策表由四个部分组成，上半部分描述条件，下半部分描述动作，左右方向则区分“有哪些项”和“取什么值”。
| 组成部分 | 位置 | 含义 |
|---|---|---|
| 条件桩 | 左上 | 列出所有影响判断的条件，如“库存充足”“地址可配送” |
| 条件项 | 右上 | 每个条件在各条规则下的取值，如Y、N或具体值 |
| 动作桩 | 左下 | 列出系统可能执行的处理，如“允许提交”“提示缺货” |
| 动作项 | 右下 | 每条规则下应执行的动作组合，用标记表示执行或不执行 |
规则是决策表的基本单位：一列条件项的组合对应一列动作项的组合。条件项常用Y表示满足、N表示不满足，用“—”表示该条件取值不影响本列结果。当某一条件取“—”时，说明这一列可以合并多条具体组合，合并后的规则行覆盖了该条件任意取值的情形，能有效压缩表格规模。使用合并写法时要确认被合并的组合确实产生相同动作，否则会掩盖真实差异。
填写决策表的过程本身也是梳理需求的过程。条件桩列不全，往往意味着业务规则还没想清楚；动作项出现同一组合对应互相矛盾的动作，则提示规则存在冲突，需要在设计阶段就与需求方确认。
从决策表到测试用例的转换步骤
决策表完成后，转换用例可以按以下顺序推进：
- 梳理条件与动作。确认条件桩覆盖所有影响结果的因素，动作桩覆盖系统全部可能处理，包括正常处理和异常提示。
- 填全条件项组合。按条件的取值范围列出组合，形成完整的规则列。条件较少时可穷举，条件较多时先标记明显不可达的组合。
- 按规则行逐条生成用例。一条规则至少对应一条用例，用例的输入对应条件项取值，预期结果对应动作项。规则行较多时，可在用例中注明所属规则编号，便于回溯。
- 合并不可达或等价规则行。业务上不可能出现的组合、或产生完全相同动作且无额外验证价值的组合，可以合并，避免重复用例占用执行资源。
- 处理组合规模。条件数量增加会使组合数快速增长，可按风险取舍：对高风险规则保留完整覆盖，对低风险且动作一致的规则采用合并写法，或按条件分层，先验证关键条件再补充次要组合。
规模控制的判断标准应写进测试设计说明，说明哪些组合被合并、合并依据是什么。这样评审时能区分“有意精简”和“无意遗漏”，避免覆盖口径含糊。
决策表测试与等价类、边界值的区别
三种方法面向的输入形态不同。等价类划分把单个输入的取值分成有效类和无效类，从每类中选取代表值；边界值分析关注取值区间的端点及其邻近值，用于发现边界处理错误。两者都围绕单个输入或单个参数的取值展开。
决策表面向多个条件组合下的规则判断。它关心的不是某个输入取什么值，而是若干条件同时成立或不成立时，系统执行哪个动作。当业务逻辑表现为“满足A且满足B则执行X，否则执行Y”这类规则时，决策表能把组合关系表达清楚。
三者可以组合使用。先用等价类和边界值收敛每个条件的取值，减少无意义的组合；再用决策表组织这些取值之间的规则关系，形成覆盖完整的用例集。例如“库存数量”这一条件，可先用边界值确定0、1、临界库存等代表值，再把这些值放进决策表与其他条件组合。
具体例子与常见误解
以一个会员折扣判断为例：条件包括“是否会员”“订单金额是否达到200元”“是否使用优惠券”，动作包括“按九折结算”“按原价结算”“拒绝使用优惠券”。整理后的决策表如下（示例为演示情景）：
| 规则 | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| 是否会员 | Y | Y | N | N |
| 金额达到200元 | Y | N | Y | — |
| 使用优惠券 | N | N | Y | Y |
| 按九折结算 | √ | |||
| 按原价结算 | √ | √ | √ | |
| 拒绝使用优惠券 | √ | √ |
这张表把三条规则行的组合关系摆在一起，R4用“—”合并了非会员在金额不同时的相同处理。据此可生成四条用例，分别验证九折、原价、优惠券冲突等情形。
围绕决策表测试，有几个常见误解需要澄清。
误解一：决策表只适用于复杂系统。实际上，只要判断涉及两个以上条件且结果随组合变化，就值得用决策表梳理，中小型业务的审批、计价、权限判断同样适用。
误解二：决策表行数等于用例数。规则行经过合并后，一行可能对应多条具体输入组合；反过来，一条规则也可能需要多条用例验证不同数据。用例数量取决于验证需要，不能直接按行数推算。
误解三：填了表就等于覆盖完整。表格完整只说明规则表达完整，是否覆盖还要核对条件桩是否遗漏、合并是否合理、每条规则是否都有对应用例。缺少这层核对，表格容易停留在文档层面。
决策表在用例管理中的落地方式
决策表要真正发挥作用，需要作为设计资产进入用例编写、评审和维护流程，而不是写完即归档。
在编写阶段，决策表与用例保持明确对应：每条规则行标注规则编号，关联的用例在描述中引用该编号，形成“规则—用例”的双向追溯。这样执行失败时能快速定位是哪条业务规则出了问题。
在评审阶段，核对重点包括条件桩是否覆盖全部影响因素、合并的规则行是否确实动作一致、每条规则是否至少有一条用例、是否存在无对应用例的规则行。评审记录应保留结论，便于后续复查。
在维护阶段，需求变化时先更新决策表，再同步调整关联用例。条件新增或动作改变会影响多条规则，借助规则编号可以快速找到受影响的用例范围，避免只改表格不改用例、或只改用例不更新设计说明。
在ONES中，可以用工作项承载决策表相关内容，用文档保存决策表本身，并将文档与对应用例工作项建立关联；规则变更时通过工作项状态和评审流程跟踪更新进度，使设计说明、用例和评审记录保持在同一处可查。这样决策表不再是一次性文档，而是随需求演进的测试设计依据。
常见问题
条件数量很多时，决策表组合爆炸怎么处理才不丢覆盖？
先确认哪些条件真正影响动作，把取值固定或与结果无关的条件从表中剔除；再对动作完全一致的规则行采用合并写法，用“—”表示该条件不影响本列结果。剩余组合按业务风险分层：高风险规则保留完整覆盖，低风险且动作一致的规则合并。合并的依据和取舍结论要写进测试设计说明，评审时据此区分有意精简和无意遗漏。
决策表里的“—”合并写法，什么情况下不能用？
“—”表示该条件取任意值都产生相同动作，前提是被合并的几条组合确实对应同一动作项。如果某个条件的不同取值会触发不同提示、不同后续流程，或涉及权限、金额等敏感差异，就不能合并，否则会掩盖真实规则差异。使用合并写法后，建议保留被合并组合的清单，便于评审时核对。
需求变更后，决策表和已有用例如何同步更新？
先更新决策表，确认新增或修改的条件、动作影响了哪些规则行，再按规则编号找到关联用例逐条调整。规则编号是追溯的纽带，用例描述中引用编号后，变更影响范围可以快速圈定。更新完成后同步修订评审记录，避免设计说明与用例出现版本不一致。
决策表测试能直接替代等价类和边界值吗？
不能替代，三者解决不同层面的问题。等价类和边界值负责把每个条件的取值收敛到有代表性的点上，决策表负责组织这些取值之间的组合规则。实际设计中通常先做取值划分，再把代表值放进决策表，形成既有取值覆盖又有组合覆盖的用例集。
决策表适合在什么阶段开始编写？
在需求分析或测试设计阶段就可以开始。编写决策表的过程会暴露条件遗漏、规则冲突和动作矛盾，这些问题越早发现，修改成本越低。如果等到用例执行阶段才补表，往往只能被动记录已有实现，失去设计校验的作用。
