测试用例设计方法是否要组合使用，取决于输入域、业务规则、状态流转和端到端流程的复杂程度。输入条件多、规则交叉、状态变化明显时，用等价类与边界值压缩输入空间，用决策表处理多条件规则，用状态迁移覆盖流转，用场景法串联主流程，再用正交或成对组合控制多因素规模，能覆盖不同类型的缺陷；输入简单、规则单一、风险集中在一个维度时，选一种方法做扎实更划算。本文给出组合的判断信号、方法分工、衔接顺序，以及投入前提、暂缓条件和试点验证方式。
要点总览（TL;DR）
- 组合多种设计方法的价值在于覆盖不同类型的缺陷：输入域复杂、业务规则多条件、状态流转明显、端到端流程长四类信号出现时，组合才值得投入。
- 方法分工按覆盖对象区分：等价类与边界值处理输入取值，决策表处理多条件规则，状态迁移处理对象流转，场景法串联端到端流程，正交法收敛多因素组合规模。
- 组合顺序建议先输入、再规则、后流程、最后收敛：等价类与边界值打底，决策表与状态迁移补规则，场景法串联流程，正交法控制组合数量。
- 组合方法需要规则文档完整、团队有方法把关人、用例维护成本可控、用例可追溯四项前提；需求不稳定、周期极短、方法基础薄弱时应先暂缓。
- 推广前选一个同时具备多条件规则和状态流转的模块试点，用覆盖情况、缺陷发现和投入数据判断是否扩大范围。
先判断：哪些条件下值得组合多种设计方法
组合多种设计方法的价值，在于让不同方法覆盖不同类型的缺陷。等价类擅长处理输入取值，边界值盯住临界点，决策表处理多条件规则组合，状态迁移覆盖状态流转，场景法串联端到端业务，正交法收敛多因素组合的数量。方法叠加本身不产生覆盖，只有当单一方法留下的盲区恰好是项目的主要风险时，组合才值得投入。
出现以下四类信号时，可以认真考虑组合：
- 输入域复杂：同一功能有多个输入字段，每个字段有有效、无效、特殊取值，且字段之间存在约束关系。单靠等价类容易漏掉字段间的组合。
- 业务规则多条件：审批、计费、权限、优惠等逻辑由多个条件共同决定结果，条件之间存在“与”“或”和优先级。这类规则用决策表逐条列出条件与动作，比逐条读需求更可靠。
- 状态流转明显：订单、工单、支付、账号等对象有明确的状态和允许的迁移路径。状态迁移能暴露非法跳转、遗漏回退、重复触发等问题。
- 端到端流程长：一个业务从发起到完成跨越多个模块和角色，单点用例无法验证流程贯通。场景法把各环节串起来，验证主流程和关键分支。
单一方法足够的判断标准同样清晰：输入字段少且相互独立，业务规则可以用几条判断句说清，对象没有明显状态变化，流程在一两个页面内完成。此时用等价类加边界值即可覆盖主要风险，再叠加决策表或状态迁移，增加的用例大多重复已有覆盖，维护成本却会上升。判断时可以问一句：现有方法漏掉的缺陷类型，是否真的在本项目出现过或有可能出现？答案是否定时，先不组合。
各方法解决什么问题：适用条件对照
每种方法都有明确的输入特征和覆盖边界，理解它们各自覆盖不到什么，才能判断哪些方法需要搭配使用。下表按同一口径对照六种常用方法。
| 方法 | 适用条件 | 典型场景 | 覆盖不到的缺陷 |
|---|---|---|---|
| 等价类划分 | 输入取值可划分为若干有效类和无效类，类内处理逻辑一致 | 表单字段、参数校验、枚举值 | 类与类之间的组合、临界值附近的偏差 |
| 边界值分析 | 输入或输出存在明确的上下限、长度、数量区间 | 数值范围、字符串长度、分页条数 | 非边界区域的逻辑错误、多字段联合边界 |
| 决策表 | 结果由多个条件的组合决定，条件之间有逻辑关系 | 审批规则、计费规则、权限判定、优惠叠加 | 状态随时间变化的过程、流程顺序问题 |
| 状态迁移 | 对象有有限状态集合和明确的迁移条件 | 订单状态、工单流转、支付状态、账号状态 | 单状态内的字段校验、跨对象的流程协同 |
| 场景法 | 业务由多个步骤和角色串联，存在主流程与分支流程 | 下单到履约、申请到审批、注册到开通 | 单点输入的边界与组合、规则表的完备性 |
| 正交/成对组合 | 多个因素各自有多个取值，需要控制组合数量 | 配置项组合、多参数兼容性、环境矩阵 | 三因素以上的强交互缺陷、业务流程顺序 |
互补关系体现在覆盖对象的差异上：等价类和边界值处理“一个输入怎么取值”，决策表处理“多个条件怎么共同决定结果”，状态迁移处理“对象在时间维度上怎么变化”，场景法处理“多个环节怎么串成业务”，正交法处理“因素多到无法穷举时怎么取样”。前两类方法产出的用例是单点或单规则级别，后三类方法产出的用例是流程或组合级别，两者不能互相替代。
组合顺序与衔接：从输入域到业务流程
组合顺序建议按“先输入、再规则、后流程、最后收敛”推进，每一步的产出作为下一步的输入，避免重复设计。
- 先划分输入域，再补边界值。先梳理每个输入字段的取值区间和有效无效类，形成等价类表；再对每个有明确范围的字段补充边界值。先做等价类是因为它决定了输入空间的骨架，边界值是在骨架的关键位置上加密。顺序反过来，容易在未理清的取值上反复补用例。
- 用决策表处理多条件规则。把业务规则整理成条件桩与动作桩，列出条件组合及对应结果，合并不可能组合和结果相同的列。决策表的输入来自需求中的规则描述，输出是一组规则级用例，正好补上等价类无法覆盖的条件交叉。
- 用状态迁移覆盖流转。识别对象的状态集合、允许的迁移和触发事件，画出状态图，再为每条迁移和每个非法迁移设计用例。决策表管“当前条件下结果是什么”，状态迁移管“对象从哪个状态能到哪个状态”，两者分工明确，在审批、订单类功能中常常同时需要。
- 用场景法串联端到端流程。在单点、规则、状态用例完成后，选取主业务流程和关键分支，按角色和步骤串成场景用例。场景法放在这个位置，是因为它依赖前面已经理清的单点校验和状态规则，串联时可以直接引用，不必在场景中重复验证细节。
- 用正交或成对组合收敛多因素规模。当配置项、环境、参数等因素较多、全组合数量不可接受时，用正交表或成对算法选取组合。这一步放在最后，是因为它处理的是“组合数量”问题，前提是各因素的取值已经明确，否则取样基础不成立。
衔接时可以用一张覆盖对照表记录每个需求点由哪类方法覆盖，例如某字段的取值由等价类和边界值覆盖，某审批规则由决策表覆盖，某订单流转由状态迁移覆盖，主流程由场景法覆盖。这样在评审时能快速看出是否存在无人覆盖的需求点，也能避免同一逻辑被多种方法重复设计。
投入与前提：组合方法需要什么准备
组合方法对输入信息的要求高于单一方法，准备不足时，方法本身会变成额外负担。主要前提包括：
- 需求与规则文档的完整度。决策表需要规则可被逐条列出，状态迁移需要状态和迁移条件明确，场景法需要流程步骤和角色清晰。规则含糊时，先澄清再设计，比先用方法套出错误用例更省成本。
- 设计人员的方法掌握程度。等价类和边界值门槛较低，决策表要求能正确合并条件组合，状态迁移要求能识别状态与事件的边界，正交法要求理解因素与水平的定义。团队中至少有一人能承担方法把关，否则组合容易流于形式。
- 用例数量与维护成本。组合会带来用例数量上升，规则变化时决策表和状态迁移用例需要同步更新。设计时应合并等价用例、标注覆盖来源，控制总量；对低频规则可以降低覆盖密度。
- 评审与追溯所需的基础信息。每条用例应能追溯到需求点或规则编号，并记录所采用的设计方法，便于评审时判断覆盖是否充分、变更时定位受影响用例。
组合后的用例需要被承载、评审和追溯。以 ONES 为例，测试用例可以按需求或模块组织进用例库，用例上记录设计方法和覆盖来源，评审时按需求点核对覆盖情况，需求变更后通过关联关系定位需要更新的用例。这样组合方法产出的规则级、状态级、场景级用例不会散落在个人表格里，覆盖对照和追溯有统一入口。
暂缓条件：哪些情况先不组合
组合方法并非越早越好，以下情形建议先暂缓，等条件具备再推进：
- 需求不稳定或规则尚未澄清。规则还在频繁调整时，决策表和状态迁移用例会反复返工。此时先用等价类和场景法覆盖主要路径，等规则稳定后再补规则级用例。
- 迭代周期极短、风险集中在单一维度。如果本迭代的变更只涉及少量字段校验，用等价类和边界值就能覆盖主要风险，引入决策表和正交法的时间投入难以在周期内收回。
- 团队方法基础薄弱。先在一两个模块把等价类和边界值用扎实，再逐步引入决策表和状态迁移。一次铺开多种方法，容易出现表格填了但没人看得懂、评审无法判断覆盖的情况。
- 组合成本高于预期风险收益。当规则组合数量庞大但历史缺陷集中在少数路径时，优先覆盖高风险路径，其余组合用抽样或成对组合控制规模，不必追求全组合覆盖。
暂缓不等于放弃。可以在用例库中标记待补充的规则点和状态迁移，随需求稳定和团队熟练度提升分批补齐。
试点判断：小范围验证组合是否有效
在全面推广组合方法前，选一个模块做小范围试点，用实际结果判断是否值得扩大。
选取模块的标准：优先选择同时具备多条件规则和状态流转的模块，例如审批或订单类功能；模块需求相对稳定，有可追溯的规则文档；模块有历史缺陷记录，便于对比。避免选过于简单或正在大改的模块，前者看不出组合价值，后者无法形成稳定结论。
观察指标：试点期间记录三类信息。一是覆盖情况，需求点和规则条目是否都有对应用例，覆盖对照表是否完整；二是缺陷发现情况，组合方法产出的用例是否发现了单一方法遗漏的规则交叉、非法状态迁移或流程断点；三是投入情况，设计、评审和维护用例的实际工时，以及用例总量相比以往的变化。
判断标准：如果组合用例发现了此前方法遗漏的有效缺陷，且新增用例数量和维护成本在可接受范围内，可以推广到同类模块；如果新增用例大多重复已有覆盖，或评审无法判断覆盖是否充分，说明方法选择或衔接方式需要调整，先回到单一方法加场景法的组合，再逐步增加。
记录与评审方式：试点结束后整理一份简短记录，包含模块范围、采用的方法与顺序、覆盖对照表、发现的缺陷类型和投入数据，在测试评审中讨论。结论可以是推广、调整后推广或暂缓，并明确下一步在哪些模块继续验证。试点记录本身也是后续新成员理解组合方法的材料。
常见问题
输入字段之间存在约束关系时，等价类和边界值还够用吗？
字段之间存在约束关系时，等价类和边界值只能覆盖单个字段的取值和临界点，字段之间的联合约束需要额外处理。常见做法是把约束关系整理成条件组合，用决策表列出哪些字段组合是允许的、哪些应被拒绝；如果约束涉及的因素较多，再用成对组合控制用例数量。判断标准是：约束是否会导致“单字段都合法、组合起来却非法”的情况，存在这种情况就需要在等价类之外补充组合级用例。
决策表和状态迁移在同一个功能里都要用吗？
取决于功能是否同时包含规则判定和状态变化。审批类功能常见这种叠加：审批结果由金额、角色、类型等多个条件共同决定，适合决策表；审批单本身又有待提交、审批中、已通过、已驳回等状态和迁移路径，适合状态迁移。两者分工不同，决策表管当前条件下结果是什么，状态迁移管对象能从一个状态走到哪个状态。如果功能只有规则判定而没有状态集合，用决策表即可；如果只有状态流转而迁移条件简单，用状态迁移即可。
组合方法产出的用例数量太多，维护不过来怎么办？
先合并重复覆盖的用例，再按风险分层控制密度。具体做法包括：决策表中结果相同且条件可合并的列合并为一列；状态迁移只覆盖允许的迁移和关键非法迁移，低频路径降低覆盖密度；正交或成对组合用于因素多但强交互少的场景，避免全组合。每条用例标注覆盖来源和设计方法，规则变更时按来源定位受影响用例，避免全量重审。如果合并后数量仍超出维护能力，说明当前模块不适合全面组合，可回到等价类加场景法覆盖主要风险。
试点模块选得太简单或太复杂，会有什么问题？
选得过于简单，单一方法就能覆盖主要风险，组合方法产出的用例大多重复已有覆盖，试点结论无法反映组合的真实价值；选得过于复杂或正在大改，需求和规则频繁变动，用例反复返工，试点期间难以形成稳定结论。较合适的做法是选需求相对稳定、同时具备多条件规则和状态流转的模块，例如审批或订单类功能，并且有历史缺陷记录可供对比。试点结束后用覆盖完整性、组合用例发现的缺陷类型和实际投入工时三项数据判断是否推广。
团队只有个别人熟悉决策表和状态迁移，能直接推广组合方法吗？
建议先补齐方法基础再推广。可以由熟悉方法的人先在一两个模块做示范，产出决策表和状态迁移的样例，配合评审讲解条件合并、状态识别和非法迁移设计的要点；其他成员先从等价类和边界值做起，再逐步承担规则级和状态级用例设计。推广节奏上，一次铺开多种方法容易出现表格填了但评审无法判断覆盖是否充分的情况。等团队能独立完成决策表合并和状态图绘制后，再引入正交法处理多因素组合。
