从业务流程提取测试场景，核心是把流程拆成“角色—任务—步骤—判定点”四层，沿主流程、分支流程和异常路径逐条走查，把每个可观察的业务结果转成场景，再补齐前置条件、输入数据、预期结果和判定依据，形成可执行用例。本文聚焦用例设计与内容质量，不涉及脚本实现、环境搭建和跨项目资产复用。
要点总览（TL;DR）
- 先把流程拆成“角色—任务—步骤—判定点”四层，整理成流程—角色—判定点对照表，作为提取场景的输入清单。
- 按“拆主流程—标判定点—展分支异常—命名登记”四步推进，先选一条端到端主流程做样板，确认字段与粒度后再批量铺开。
- 场景转用例时补齐前置条件、输入数据、操作步骤、预期结果和判定依据，预期结果落到具体状态值、记录条数或字段内容。
- 业务方确认流程口径与规则来源，测试设计人员负责拆解转换，开发补充异常路径，测试负责人组织评审并维护版本基线。
- 用覆盖、字段、追溯三个维度逐项核对，出现判定点遗漏、用例无法追溯需求或重复用例时应返工。
先明确提取对象：流程、角色与判定点
提取场景之前，先把“从哪条流程、涉及哪些角色、在哪些位置做判断”这三件事固定下来。输入材料不齐就动手写场景，常见结果是场景粒度忽粗忽细、评审时反复返工。建议先整理一张流程—角色—判定点对照表，作为后续提取的输入清单。
需要准备的三类输入材料
- 业务流程清单与流程图：来源包括需求文档中的流程描述、业务方提供的操作手册、现有系统的页面跳转关系。流程图优先取业务方确认过的版本，避免拿开发设计稿代替业务口径。
- 角色与任务清单：列出流程中每个参与角色（如申请人、审批人、财务复核人、系统定时任务），以及该角色在流程中承担的任务。系统自动执行的环节也要单独列出，标注触发条件。
- 判定点清单：判定点是流程中会改变走向或结果的位置，主要包括三类——业务规则（如金额阈值、资格校验）、状态变化（如订单从待支付变为已支付）、审批节点（如一级审批通过后进入二级审批）。每个判定点记录规则来源和取值条件。
对照表怎么填
| 流程环节 | 执行角色 | 任务 | 判定点 | 规则来源 |
|---|---|---|---|---|
| 提交申请 | 申请人 | 填写并提交表单 | 必填项校验、附件格式校验 | 需求文档第3节 |
| 一级审批 | 部门主管 | 审批或驳回 | 金额是否超过审批权限 | 审批制度 |
| 支付回调 | 系统 | 更新订单状态 | 回调结果成功/失败/超时 | 接口约定 |
场景边界在这一步就要说清：本文讨论的范围是从流程中识别测试场景并写成用例，脚本实现、自动化框架选型、跨项目用例复用属于相邻主题，另行处理。对照表完成后，检查每个判定点是否都有规则来源，来源缺失的判定点先找业务方确认，不带着模糊规则进入下一步。
四步提取法：从流程走到测试场景
四步提取法按“拆步骤—标判定—展分支—登记场景”的顺序推进，每一步都有明确的输入、动作、输出和完成标志。建议先选一条端到端主流程做样板，确认字段和粒度后再批量铺开其他流程。
第一步：拆解主流程为有序步骤
输入是流程图和角色任务清单，动作是把主流程按时间顺序拆成编号步骤，每步写清“谁在什么条件下做什么、产生什么结果”。输出是一份带编号的主流程步骤表。完成标志是：每一步都能对应到一个角色和一个可观察的动作结果，步骤之间没有跳跃或合并。
第二步：标注每个步骤的判定点与业务规则
输入是主流程步骤表和判定点清单，动作是逐步骤标注该步骤包含的判定点，并写明规则的具体取值条件，例如“金额≤5000元走一级审批，>5000元走两级审批”。输出是带判定点标注的步骤表。完成标志是：每个判定点都有可验证的规则描述，不存在“视情况而定”这类无法判定的表述。
第三步：沿分支与异常路径展开场景
输入是带判定点的步骤表，动作是对每个判定点分别走成功路径、失败路径和边界取值，同时补充异常路径，如超时、重复提交、并发操作、外部系统返回异常。输出是按主流程、分支、异常分类的场景草稿。完成标志是：每个判定点的每个取值方向都至少对应一个场景，异常路径有明确的触发方式。
第四步：为场景命名并登记场景清单
输入是场景草稿，动作是按统一命名规则登记，建议采用“流程名-环节-条件-预期结果”的结构，例如“订单支付-回调超时-订单保持待支付并触发对账”。输出是一份按主流程、分支、异常分类的场景清单。完成标志是：场景名称能独立表达测试意图，清单中无重复场景，每条场景可追溯到来源步骤和判定点。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 拆解主流程 | 流程图、角色任务清单 | 按顺序编号拆步 | 主流程步骤表 | 每步对应角色与可观察结果 |
| 标注判定点 | 步骤表、判定点清单 | 逐步骤标注规则与取值 | 带判定点的步骤表 | 规则可验证、无模糊表述 |
| 展开分支异常 | 带判定点的步骤表 | 按取值方向和异常类型展开 | 分类场景草稿 | 每个取值方向均有场景 |
| 命名登记 | 场景草稿 | 统一命名并登记清单 | 分类场景清单 | 名称可独立表达意图、可追溯 |
把场景转成可执行用例：字段与写法
场景描述的是“要验证什么”，用例描述的是“怎么验证、验证到什么算通过”。一个场景通常对应一条或多条用例，例如“审批金额边界”这一场景，可以拆成等于阈值、略高于阈值、略低于阈值三条用例。转换时按固定字段填写，避免场景停留在描述层面。
用例必备字段
| 字段 | 填写要求 | 示例 |
|---|---|---|
| 用例名称 | 场景名+具体条件 | 订单支付-回调超时-订单保持待支付 |
| 前置条件 | 执行前必须存在的系统状态和数据 | 订单已创建且状态为待支付，支付网关可模拟超时 |
| 输入数据 | 具体取值，不用“正常数据”代替 | 订单号ORD20250101，金额4999元 |
| 操作步骤 | 按角色和动作编号，一步一个动作 | 1. 用户发起支付；2. 模拟网关超时返回 |
| 预期结果 | 落到可观察的业务对象或状态 | 订单状态仍为待支付，生成一条对账待处理记录 |
| 判定依据 | 规则来源或需求条目编号 | 需求文档第5.2节支付回调规则 |
粒度控制
粒度过粗的典型表现是一条用例覆盖多个判定点，失败时无法定位问题；粒度过细则是一个按钮点击拆成多条用例，维护成本高。判断标准是：一条用例只验证一个业务结果，步骤数量控制在执行人能在一次操作中完成的范围内。预期结果写成“系统正常”“页面显示正确”这类描述，等于没有判定依据，应改为具体的状态值、记录条数或字段内容。
角色分工与交付物
场景提取不是测试设计人员单独完成的工作。业务方提供流程口径和规则来源，测试设计人员负责拆解和转换，开发在评审中确认技术可行性和异常路径，三方分工明确才能减少返工。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 测试设计人员 | 拆解流程、标注判定点、展开场景、编写用例 | 流程—角色—判定点对照表、场景清单、用例 |
| 业务方 | 确认流程口径、规则来源和业务预期结果 | 确认后的规则说明、评审意见 |
| 开发 | 确认异常路径、状态变化和技术约束 | 异常场景补充建议、评审意见 |
| 测试负责人 | 组织评审、确认覆盖范围、维护版本 | 评审记录、场景清单与用例的版本基线 |
评审对象是场景清单和用例本身，评审重点是判定点是否遗漏、预期结果是否可判定、追溯关系是否完整。场景清单和用例的版本维护由测试负责人指定专人负责，需求变更时同步更新对应场景和用例，并在清单中记录变更原因。交付物在需求、开发、测试之间的交接方式是：需求评审后输出对照表，开发完成后补充异常场景，测试执行前完成用例评审并冻结基线版本。
场景清单和用例数量增加后，登记、评审和追溯需要工具承载。ONES 测试管理支持编写测试用例、组织用例库，并可自定义用例属性以适配不同业务场景；用例模块支持树状结构和拖拽排序，用例库中所有用例属性都支持筛选，便于按流程或场景分组查找。用例可与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；未通过的用例可快速创建缺陷任务，在测试与研发团队间流转。用例评审的具体流程和场景层级的追溯方式，需按团队实际配置确认。
示例：一条订单流程如何提取场景
以下示例为演示情景，用于说明四步提取法和用例转换的操作方式，不代表任何具体系统的真实规则。
主流程步骤拆解
- 用户提交订单，系统校验商品库存和收货信息。
- 用户发起支付，系统调用支付网关。
- 支付网关回调，系统更新订单状态。
- 系统通知仓库发货，仓库回传发货结果。
判定点与业务规则标注
- 步骤1：库存是否充足；收货信息必填项是否完整。
- 步骤2：支付金额与订单金额是否一致。
- 步骤3：回调结果为成功、失败或超时。
- 步骤4：仓库回传结果为发货成功或库存不足。
分支与异常场景展开
| 分类 | 场景 | 来源判定点 |
|---|---|---|
| 主流程 | 库存充足、支付成功、回调成功、发货成功 | 步骤1—4 |
| 分支 | 库存不足时提交订单被拦截 | 步骤1 |
| 分支 | 支付金额与订单金额不一致时拒绝支付 | 步骤2 |
| 异常 | 支付回调超时，订单保持待支付并生成对账记录 | 步骤3 |
| 异常 | 仓库回传库存不足，订单转为异常待处理 | 步骤4 |
场景到用例的字段填写示范
| 字段 | 内容 |
|---|---|
| 用例名称 | 订单支付-回调超时-订单保持待支付并生成对账记录 |
| 前置条件 | 订单已创建且状态为待支付，支付网关可模拟超时 |
| 输入数据 | 订单号ORD20250101，金额4999元 |
| 操作步骤 | 1. 用户发起支付；2. 模拟网关超时返回；3. 等待对账任务执行 |
| 预期结果 | 订单状态仍为待支付，对账记录新增一条且状态为待处理 |
| 判定依据 | 需求文档第5.2节支付回调规则 |
完成检查：场景覆盖与用例质量核对
提取工作是否完成，用一份检查清单逐项核对，比凭经验判断更可靠。检查分覆盖、字段、追溯三个维度，任一项不通过即返工。
覆盖检查
- 主流程：端到端主流程至少有一条完整场景，步骤与流程图一致。
- 分支：每个判定点的每个取值方向都有对应场景。
- 异常：超时、重复提交、并发、外部系统异常等路径已逐项走查。
- 边界：金额、数量、时间等阈值取等于、略高、略低三类取值。
用例字段完整性检查
- 前置条件、输入数据、操作步骤、预期结果、判定依据五项齐全。
- 预期结果落到具体状态值、记录条数或字段内容，无“正常”“正确”类描述。
- 一条用例只验证一个业务结果，步骤可由执行人一次完成。
追溯检查
- 每条场景可追溯到来源流程步骤和判定点。
- 每条用例可追溯到对应场景和需求条目。
- 需求变更后，受影响的场景和用例已同步更新并记录变更原因。
常见遗漏点包括：只覆盖成功路径、判定点规则来源缺失、异常路径只写“系统异常”不写具体触发方式、用例预期结果无法判定。出现以下情况应返工：评审中发现判定点遗漏、用例无法追溯到需求条目、同一场景存在多条重复用例。场景清单和用例登记到测试管理工具后，可利用用例属性筛选和需求关联做覆盖核对，具体字段配置按团队实际流程设定。
常见问题
业务流程文档不完整，只有零散的页面操作说明，还能提取测试场景吗？
可以，但需要先补齐流程口径再动手。做法是以现有页面操作说明为线索，找业务方确认端到端流程的起点、终点和中间环节，把缺失的判定点规则逐条问清并记录来源。规则来源暂时无法确认的判定点，先标注待确认，不带着模糊规则写场景。补齐后按流程—角色—判定点对照表登记，再进入四步提取法。
一个场景应该对应一条用例还是多条用例？
取决于场景中包含的判定条件数量。场景描述“要验证什么”，用例描述“怎么验证、验证到什么算通过”。当一个场景涉及多个取值方向时，通常拆成多条用例，例如金额阈值场景可拆成等于阈值、略高于阈值、略低于阈值三条。判断标准是一条用例只验证一个业务结果，步骤可由执行人一次完成。
需求变更后，已经提取的场景和用例怎么处理？
先定位受影响的流程步骤和判定点，再同步更新对应场景与用例，并在清单中记录变更原因。测试负责人维护版本基线，变更后重新走一次覆盖检查和追溯检查，确认新增或修改的判定点都有对应场景、每条用例仍能追溯到需求条目。变更频繁时，可在测试管理工具中利用用例属性筛选和需求关联做批量核对。
场景清单和用例数量多起来后，用什么方式登记和评审比较稳妥？
建议用测试管理工具承载登记、评审和追溯，减少表格多头维护。ONES 测试管理支持编写测试用例、组织用例库，用例模块支持树状结构与拖拽排序，用例库中所有用例属性都支持筛选，便于按流程或场景分组查找；用例可与需求、任务关联，未通过的用例可快速创建缺陷任务。用例评审的具体流程和场景层级的追溯方式，需按团队实际配置确认。
异常路径总是覆盖不全，有什么可操作的补充办法？
按异常类型逐项走查，比凭经验回忆更可靠。常见类型包括超时、重复提交、并发操作、外部系统返回异常、状态回退。对每个判定点问三个问题：这个环节的外部依赖失败会怎样、同一操作重复触发会怎样、两个角色同时操作同一数据会怎样。把答案写成带具体触发方式的场景，避免只写“系统异常”这类无法执行的描述。
