测试用例设计方法的选择，取决于被测对象的输入结构、业务规则复杂度和风险分布。输入有取值范围时，用等价类划分与边界值分析打底；业务规则存在多条件组合时，用决策表；状态随事件迁移时，用状态迁移法；流程分支多时，用场景法；参数组合多且交互影响明显时，用正交试验或成对组合。本文按条件说明这些方法如何搭配、需要哪些投入，以及什么情况下应简化处理。
要点总览（TL;DR）
- 方法组合从被测对象的结构特征出发：输入有取值范围时先用等价类划分与边界值分析打底，再按规则、状态、流程、参数等维度叠加增强方法。
- 业务规则可枚举且多条件组合决定输出时叠加决策表；状态随事件迁移时叠加状态迁移法；流程分支多时用场景法串联端到端用例；参数多且交互明显时用正交试验或成对组合。
- 组合的目标是覆盖风险而非追求方法数量，每增加一种方法都要评估其针对的缺陷类型在当前模块是否真实存在。
- 采用组合方法需要规则文档可读、状态模型可建，并预留规则梳理、模型建立和用例评审维护的工时；需求简单、规则频繁变动或时间紧张时应简化处理。
- 可通过一个模块的小范围试点，观察缺陷发现分布、用例冗余度和设计维护工时，再决定是否推广到其他模块。
组合选择的条件式结论
方法组合的判断起点是被测对象的结构特征，而非方法清单的长短。先识别输入、规则、状态、流程、参数这五个维度中哪些存在，再决定叠加哪些方法。基础层负责输入域覆盖，增强层负责规则、状态与流程的深度覆盖，两者是层次关系：基础层缺失时，增强层的用例再细也会留下明显的输入盲区。
下表按条件给出组合建议，可对照被测模块的实际特征查找。
| 条件特征 | 建议组合 | 组合理由 |
|---|---|---|
| 输入有明确取值范围或类型划分 | 等价类划分 + 边界值分析 | 先划分有效与无效类，再取区间端点及邻近值，覆盖输入域的主要缺陷 |
| 业务规则由多个条件组合决定输出，且规则可枚举 | 等价类 + 边界值 + 决策表 | 决策表复用等价类整理出的条件取值，覆盖条件组合对应的动作 |
| 对象状态可识别，状态随事件迁移 | 等价类 + 边界值 + 状态迁移法 | 在输入覆盖基础上补充合法迁移与非法迁移的验证 |
| 端到端流程分支多，涉及多个环节交接 | 上述方法 + 场景法 | 用场景法串联主流程与备选流程，验证跨环节的业务连续性 |
| 参数数量多、全组合不可行且参数间存在交互 | 等价类 + 边界值 + 正交试验或成对组合 | 用少量组合覆盖主要参数交互，控制用例规模 |
| 规则复杂且状态迁移并存 | 决策表 + 状态迁移法 + 场景法 | 决策表管规则分支，状态迁移管状态合法性，场景法管流程串联 |
组合的目标是覆盖风险，而非追求方法数量。每增加一种方法，都会带来用例编写、评审和维护的额外工作量。判断是否叠加某方法时，可以问：该方法针对的缺陷类型，在当前模块的历史缺陷或风险评估中是否真实存在。若某类缺陷从未出现且业务影响有限，用基础方法覆盖即可。
各方法解决什么问题、在什么条件下优先
理解每种方法针对的缺陷类型，是组合判断的依据。方法之间并非互相替代，各自覆盖不同的缺陷来源。
| 方法 | 目标问题 | 适用前置条件 | 单独使用时的覆盖盲区 |
|---|---|---|---|
| 等价类划分 | 输入域过大，无法逐一取值；需要覆盖有效与无效输入 | 输入项可识别，取值可划分为有意义的类 | 类内部的取值差异、区间端点附近的缺陷 |
| 边界值分析 | 取值区间端点及邻近值容易出错 | 输入存在明确的数值或长度边界 | 非边界区域的逻辑错误、多输入之间的组合影响 |
| 决策表 | 多个条件组合决定不同输出，规则之间存在交叉 | 业务规则可枚举，条件与动作能梳理清楚 | 状态随时间变化的场景、流程环节之间的衔接 |
| 状态迁移法 | 对象状态随事件变化，非法迁移需要拦截 | 状态可识别，迁移事件与目标状态可建模 | 单个状态内部的输入校验、跨对象的流程编排 |
| 场景法 | 端到端流程分支多，主流程与备选流程需要验证 | 业务流程可描述，角色与操作步骤明确 | 细粒度的输入边界、规则组合的穷举覆盖 |
| 正交试验 / 成对组合 | 参数多、全组合不可行，参数间存在交互影响 | 参数及取值水平可列举，交互关系有判断依据 | 三个及以上参数的高阶交互、业务规则的语义约束 |
等价类与边界值通常配合使用：等价类负责把输入空间压缩为可管理的类，边界值负责在类与类的交界处加密取值。决策表的价值在于把散落在需求文档中的规则整理成条件与动作的对应关系，规则数量多时需要先做化简，合并结果相同的规则列。状态迁移法要求先建立状态模型，覆盖合法迁移的同时，非法迁移的拦截同样需要设计用例。场景法适合放在输入与规则覆盖完成之后，用于验证跨环节的业务连续性。正交试验与成对组合解决的是组合爆炸问题，适用于参数水平明确、交互影响有依据的场景。
组合使用的典型顺序与衔接方式
方法之间的衔接有相对稳定的顺序：从输入分析开始，逐步扩展到规则、状态和端到端流程。按此顺序推进，前一步的产出可以作为后一步的输入，减少重复分析。
- 输入分析：等价类划分先行。梳理每个输入项的类型、取值范围和有效无效划分，形成输入条件清单。这份清单是后续方法共用的基础材料。
- 边界加密：边界值分析补充。在等价类确定的区间上取端点及邻近值，形成边界用例。等价类与边界值的用例可以合并编写，一条用例同时标注所属等价类和边界位置。
- 规则覆盖：决策表复用输入条件。把等价类清单中的条件取值代入决策表的条件桩，梳理条件组合与动作的对应关系。这一步不需要重新分析输入，直接复用前两步的成果。
- 状态验证：状态迁移法建立模型。识别对象的状态集合与迁移事件，绘制状态迁移图，覆盖合法迁移与非法迁移。状态迁移中的事件往往对应具体输入，可与等价类用例建立关联。
- 流程串联：场景法组织端到端用例。以主业务流程为主线，把前面生成的输入、规则、状态用例挂接到流程节点上，补充备选流程和异常流程。
- 组合收敛：去重与优先级标注。合并重复覆盖的用例，按风险高低标注优先级，明确哪些用例必须在每轮回归中执行，哪些可以按版本抽检。
去重时重点检查三类重复：同一等价类被多条用例重复覆盖、决策表中结果相同的规则列被分别编写、场景用例与状态迁移用例验证了同一迁移路径。优先级标注建议结合缺陷历史与业务影响，把高风险区域的用例排在执行序列前面。组合后的用例集合应有清晰的来源标注，便于后续需求变更时定位需要调整的用例。
当用例按上述链路设计完成后，用例的组织方式会影响后续的评审与执行效率。ONES TestCase 支持用例模块的树状结构组织与拖拽排序，可按模块或方法分层存放用例；用例属性支持自定义，可用于标注设计方法、优先级和关联需求；用例库中的属性支持筛选，便于按方法或优先级快速定位用例。这些能力承载的是组合设计之后的组织与流转工作，方法选择本身仍依赖测试人员对被测对象的分析。
投入与前提：组合方法需要什么
组合方法带来的覆盖提升，以额外的分析投入为代价。采用前需要评估以下条件是否具备。
- 需求与规则文档的可读性。决策表要求规则可枚举，状态迁移要求状态与事件可识别。若需求文档只描述界面操作而缺少规则说明，需要先补充规则梳理，这部分工作往往由测试人员发起。
- 业务规则与状态模型的分析投入。建立状态迁移图和决策表需要专门的分析时间，复杂模块可能需要数小时到数天。这部分投入应在测试计划中单独估算，而非隐含在用例编写工时里。
- 与开发、产品确认规则边界的协作成本。规则中的隐含条件、状态迁移的触发时机，常需要与开发和产品逐条确认。确认过程本身也是发现需求歧义的机会，但会占用多方时间。
- 用例维护与评审的额外工作量。决策表和状态迁移用例与规则强关联，规则变更时需要同步更新。组合后的用例数量增加，评审工作量随之上升，需要建立对应的评审节奏。
这些投入是否值得，取决于模块的业务重要性和缺陷历史。核心交易链路、权限与状态控制、计费规则等区域，规则复杂且缺陷影响大，组合方法的投入通常能获得对应回报。辅助功能或低频使用的配置项，基础方法覆盖即可。
暂缓条件：什么情况下不必组合
组合方法并非所有场景都适用。以下情形应简化处理或暂缓叠加方法。
- 需求简单、输入单一。功能只有一个输入项且取值有限时，等价类加边界值即可完成覆盖，引入决策表或状态迁移只会增加文档负担。
- 规则频繁变动。决策表的维护成本与规则稳定性直接相关。规则每周调整的模块，决策表刚整理完就可能过时，此时先用场景用例覆盖主要业务路径，待规则稳定后再补决策表更划算。
- 时间窗口紧张。版本临近发布、可用测试时间不足时，应执行最小覆盖策略：优先保证主流程场景和核心输入的边界用例，规则组合与状态迁移的深度覆盖排到后续版本补充，并在测试报告中说明覆盖范围。
- 状态模型不清晰。状态定义模糊、迁移条件依赖未确认的外部系统时，直接编写状态迁移用例容易产生错误假设。此时应先与产品、开发补齐状态模型，再决定是否采用状态迁移法。
暂缓不等于放弃。可以在用例库中保留待补充的标注，记录哪些区域尚未做深度覆盖，作为后续版本的设计输入。
试点判断：如何验证组合是否有效
方法组合是否合适，可以通过一个模块的小范围试点来验证，再决定是否推广。
试点模块的选择建议满足两个条件：业务规则有一定复杂度，且历史缺陷有记录可对比。试点周期覆盖一个完整的测试轮次，按前述顺序完成方法组合的用例设计，同时保留原有方法的用例作为对照。
观察指标建议包括：
- 缺陷发现分布。记录新增用例发现的缺陷数量与类型，重点看决策表、状态迁移用例是否发现了基础方法遗漏的规则类或状态类缺陷。
- 用例冗余度。统计组合后用例总数与去重后数量，评估重复覆盖的比例。冗余度过高说明方法叠加时衔接没有做好。
- 设计与维护工时。记录规则梳理、模型建立、用例编写和评审的实际工时，与预估对比，判断投入是否在可接受范围。
- 执行反馈。收集执行人员对用例可读性和可执行性的反馈，规则类用例是否便于判断预期结果。
试点结束后做一次复盘：若新增方法带来的缺陷发现集中在少数规则或状态上，说明该方法对该模块有效，可以固化到用例设计规范中；若新增用例大量重复且缺陷发现有限，应缩减方法范围。推广条件建议设定为：试点模块的缺陷发现率有可观察的提升，且用例维护工时在团队可承受范围内。推广时优先复制到业务结构相似的模块，逐步扩展，避免一次性在全项目铺开。
常见问题
等价类划分和边界值分析一定要一起用吗？
两者通常配合使用，但并非必须同时出现。等价类划分负责把输入空间压缩为可管理的有效类与无效类，边界值分析负责在类与类的交界处加密取值。如果输入项只有少量离散取值、不存在区间端点，等价类覆盖即可；如果输入存在明确的数值或长度边界，边界值分析能补上等价类容易遗漏的端点缺陷。实际编写时可以把两者合并到一条用例中，同时标注所属等价类和边界位置，减少重复。
决策表整理出来规则太多，怎么控制规模？
规则数量多时，先做化简再编写用例：合并结果相同的规则列，把不可能出现的条件组合标注为不适用，保留有业务意义的组合。化简后仍偏多时，可以按风险拆分，优先覆盖高频路径和涉及金额、权限、状态变更的规则，其余规则列入待补充清单。若规则本身每周都在调整，决策表的维护成本会很高，此时先用场景用例覆盖主要业务路径，待规则稳定后再补决策表更划算。
状态迁移法和场景法都涉及流程，应该先做哪个？
建议先建立状态模型，再用场景法组织端到端用例。状态迁移法关注单个对象在事件驱动下的状态合法性与非法迁移拦截，产出的是状态与迁移路径的覆盖；场景法关注跨环节的业务连续性，需要把输入、规则、状态用例挂接到流程节点上。状态模型不清晰时直接写场景用例容易产生错误假设，应先与产品、开发补齐状态定义和迁移条件，再决定是否采用状态迁移法。
组合方法后用例数量增加，评审和维护怎么安排？
组合后先做去重，重点检查三类重复：同一等价类被多条用例重复覆盖、决策表中结果相同的规则列被分别编写、场景用例与状态迁移用例验证了同一迁移路径。去重后按风险标注优先级，明确哪些用例每轮回归必执行、哪些按版本抽检。评审节奏上，规则类和状态类用例与需求强关联，建议在需求评审后同步评审，规则变更时定向更新相关用例，而不是每轮全量重审。
试点验证组合方法有效，主要看哪些指标？
试点模块建议选业务规则有一定复杂度、历史缺陷有记录可对比的模块，覆盖一个完整测试轮次，并保留原有方法的用例作对照。观察指标包括：新增用例发现的缺陷数量与类型，重点看决策表、状态迁移用例是否发现了基础方法遗漏的规则类或状态类缺陷；组合后用例总数与去重后数量的比例，评估冗余度；规则梳理、模型建立、用例编写和评审的实际工时；执行人员对用例可读性和预期结果可判断性的反馈。若新增方法带来的缺陷发现集中在少数规则或状态上，说明对该模块有效，可固化到设计规范；若新增用例大量重复且缺陷发现有限，应缩减方法范围。
