从业务流程提取测试场景，可以按“拆流程要素—列场景清单—转可执行用例”的路径推进：先把流程拆成角色、任务、步骤、判定点和异常分支，再按主流程、分支、异常、边界逐层展开，最后补齐前置条件、操作步骤、预期结果和测试数据。关键产物是流程要素表、场景清单和用例转换表，完成标志是场景能追溯到流程节点、用例能独立执行。
要点总览（TL;DR）
- 从业务流程提取测试场景，按“拆流程要素—列场景清单—转可执行用例”推进，核心产物是流程要素表、场景清单和用例转换表。
- 流程要素表围绕角色、任务、步骤、判定点、异常分支五类要素设计字段，判定点要写清条件和分支去向，异常分支按步骤逐条挂接。
- 场景按主流程、分支与判定点组合、异常与中断、边界与数据条件四类展开，粒度以“一个可独立验证的业务结果”为准，按角色、任务、判定分支、数据条件去重。
- 场景转用例时补齐前置条件、操作步骤、预期结果和测试数据，可执行性看三条：能独立操作、每步有明确输入、每个预期结果可观察。
- 验收时逐项检查流程覆盖、场景可追溯和用例可执行，出现主流程缺失、关键分支未覆盖或预期结果不可观察时返工后再形成基线。
先给答案：提取测试场景的五步操作
测试场景来自业务流程，但流程文档通常按业务叙述组织，不能直接当测试输入。提取工作要做的是把叙述性流程转成结构化要素，再按测试视角展开成可验证的场景。整个过程可以拆成五步，每步都有明确的输入、动作、输出和完成标志，便于分工和检查。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 收集并确认流程 | 业务流程文档、需求说明、操作手册、业务方口述 | 与业务方逐段走查流程，确认起止点、参与角色和关键业务规则 | 确认版流程说明，标注待澄清问题 | 流程起止、角色和规则无歧义，遗留问题有结论或明确责任人 |
| 2. 拆流程要素 | 确认版流程说明 | 按角色、任务、步骤、判定点、异常分支拆成结构化字段 | 流程要素表 | 每个流程节点都能在要素表中找到对应行，判定点和数据依赖已标注 |
| 3. 展开场景清单 | 流程要素表 | 先提主流程场景，再按判定点组合提分支场景，补充异常、中断和边界场景 | 场景清单 | 每个场景能追溯到要素表中的节点或判定点，场景之间无重复 |
| 4. 转换为可执行用例 | 场景清单、测试数据、环境说明 | 为每个场景补前置条件、操作步骤、预期结果和测试数据 | 用例转换表 | 用例可由他人独立执行，预期结果可观察、可判定 |
| 5. 评审与修订 | 流程要素表、场景清单、用例转换表 | 组织业务方和开发评审覆盖度与准确性，修订遗漏和错误 | 评审通过的场景与用例基线 | 评审意见闭环，覆盖检查通过 |
展开顺序建议固定为：主流程优先，保证业务主干可跑通；其次按判定点展开分支流程；再补充异常与中断场景；最后处理边界和数据条件。这个顺序的好处是先建立主干，再逐步加密，避免一开始陷入细节而遗漏主路径。五步走完后，流程要素表、场景清单和用例转换表三份产物应能互相对应，任一场景都能向上追溯到流程节点，任一用例都能向下落到具体操作。
流程要素表：把业务流程拆成可测试的字段
流程要素表是提取工作的中间产物，作用是把叙述性流程转成结构化输入。字段设计围绕五类要素展开，每个字段都要有统一填写口径，否则不同人拆出的表无法合并使用。
| 字段 | 填写口径 | 示例 |
|---|---|---|
| 流程编号 | 按业务域加序号，全表唯一 | ORD-01 |
| 角色 | 发起或执行该步骤的岗位或系统角色，写具体角色名 | 下单客户、客服专员、库存服务 |
| 任务 | 该角色在此流程中要完成的一件事，用动宾结构 | 提交订单、审核退款 |
| 步骤 | 任务下的具体操作，按执行顺序编号 | 选择商品→填写收货信息→确认支付 |
| 判定点 | 流程中出现条件判断的位置，写明判断条件和各分支去向 | 库存是否充足：充足走正常发货，不足走缺货处理 |
| 数据依赖 | 该步骤依赖或产生的数据，注明来源和状态要求 | 依赖有效收货地址；产生待支付订单 |
| 异常分支 | 该步骤可能出现的失败、超时、取消、重复提交等情况及处理方式 | 支付超时关闭订单；重复提交需幂等处理 |
填写时有几个口径需要统一。角色写到岗位或系统边界，避免用“用户”这类笼统称呼，否则后续无法判断谁能执行该场景。判定点必须写清条件和分支去向，只写“判断库存”不够，要写“库存充足”和“库存不足”分别走向哪里。数据依赖要标注状态要求，例如“已支付订单”和“待支付订单”对应不同场景。异常分支按步骤逐条挂接，不要集中写在流程末尾，否则展开场景时容易漏掉某一步的异常。
示例行可以这样组织：流程编号 ORD-01，角色为下单客户，任务为提交订单，步骤为选择商品、填写收货信息、确认支付，判定点为库存是否充足，数据依赖为有效收货地址和商品库存状态，异常分支为支付超时、库存不足、地址无效。一行要素表对应一个可测试的流程节点，后续场景清单直接从这些行展开。
场景清单：从要素表展开主流程、分支与异常
场景清单由流程要素表逐层展开而来，展开规则决定了覆盖度和场景数量。建议按四类场景分别提取，再统一做粒度和去重处理。
主流程场景
主流程场景取每个任务的正常路径，即所有判定点都走“顺利”分支时的完整链路。提取方法是沿要素表按步骤顺序串联，形成一个端到端场景，例如“客户提交订单—库存充足—支付成功—发货”。主流程场景数量少，但它是后续分支和异常场景的基准，必须先确认无误。
分支与判定点组合场景
每个判定点至少产生两个分支场景。判定点较多时，不必做全组合，按业务影响筛选：影响资金、库存、权限、状态流转的组合优先覆盖；相互独立的判定点可以分别覆盖，存在先后依赖的判定点按实际可达路径组合。例如“库存充足”与“支付成功”可以组合，“库存不足”与“支付成功”在业务上不可达，就不必生成。
异常与中断场景
异常场景从要素表的异常分支字段逐条提取，包括操作失败、超时、取消、重复提交、并发冲突和外部依赖不可用。中断场景关注流程执行到一半被打断后的状态，例如支付中途退出后订单状态是否正确、能否继续支付。每条异常分支至少对应一个场景，处理方式不同的异常要拆开。
边界与数据条件场景
边界场景围绕数值、时间、数量和状态条件展开，例如库存为 0、订单金额为 0、支付超时临界点、地址数量上限。数据条件场景关注不同数据状态对流程的影响，例如新客户与老客户、有优惠券与无优惠券。边界值取自业务规则中明确写出的阈值，规则未写明的阈值应先向业务方确认，再补入场景。
场景粒度与去重规则
场景粒度以“一个可独立验证的业务结果”为准：同一组前置条件和操作步骤、预期结果相同的，合并为一个场景；前置条件或预期结果不同的，拆分为不同场景。去重时按“角色+任务+判定分支+数据条件”比对，四项相同即视为重复。场景清单建议包含场景编号、场景名称、来源流程节点、场景类型、前置条件概述和优先级，便于后续转换和评审。
从场景到可执行用例：转换表与示例
场景描述业务上要验证什么，用例描述具体怎么验证。转换的核心是把场景中的概述性条件落到可操作、可观察的字段上，字段映射关系如下。
| 场景字段 | 用例字段 | 转换要求 |
|---|---|---|
| 场景名称 | 用例标题 | 保留角色、动作和验证点，标题可独立读懂 |
| 前置条件概述 | 前置条件 | 写成可准备的状态，注明数据、账号、环境和系统状态 |
| 操作路径 | 操作步骤 | 每步一个动作，写清操作对象和输入值 |
| 预期业务结果 | 预期结果 | 写成可观察的界面、数据或状态变化，避免“正常”“成功”这类笼统表述 |
| 数据条件 | 测试数据 | 给出具体值或取值规则，注明数据准备方式 |
| 来源流程节点 | 追溯标识 | 保留流程编号和场景编号，供覆盖检查使用 |
以一个订单支付场景为例。场景为“库存充足时客户支付成功，订单进入待发货状态”。转换为用例时，前置条件写为：存在一件库存充足的商品，客户账号已登录且收货地址有效；测试数据写为：商品编号与单价、订单金额、支付方式；操作步骤写为：加入购物车、提交订单、选择支付方式、完成支付、查看订单状态；预期结果写为：支付成功后订单状态变为待发货，库存扣减一件，支付流水生成一条成功记录。这样一条用例，其他测试人员按步骤即可独立执行，结果也能逐项核对。
可执行性判断可以看三条：不看场景描述也能按用例独立操作；每步操作都有明确的输入或对象；每个预期结果都能通过界面、数据或日志观察到。三条中有一条不满足，就说明用例还需要补充前置条件、数据或判定口径。
角色分工与交付物
提取工作涉及业务、测试和开发三方，职责按产物划分，交接节点设在每份产物完成评审时。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 业务方或业务分析人员 | 提供并确认流程、业务规则和判定条件，澄清异常处理方式 | 确认版流程说明、业务规则清单 |
| 测试人员 | 拆流程要素、展开场景清单、编写用例、组织评审 | 流程要素表、场景清单、用例转换表 |
| 开发人员 | 确认技术实现约束、接口和状态流转，参与异常场景评审 | 技术约束说明、评审意见 |
| 测试负责人 | 确定覆盖范围和优先级，把关验收 | 评审结论、场景与用例基线 |
交接节点建议设三个：流程说明确认后移交测试人员拆要素；场景清单完成后由业务方确认业务覆盖、开发确认技术可达；用例转换完成后组织评审并形成基线。交付物清单包括确认版流程说明、流程要素表、场景清单、用例转换表和评审记录，五份材料按流程编号关联，便于后续追溯和变更。
当场景和用例需要在需求、测试和缺陷之间保持关联时，可以把流程要素表和场景清单作为文档沉淀，把用例作为测试工作项管理，并在工作项上保留来源流程节点和场景编号。ONES 支持需求、测试用例与缺陷之间的关联和评审流转，适合在这种多方交接的场景中承载追溯关系；具体字段和流程配置可按团队现有管理方式设置。
完成检查：场景与用例的验收清单
提取结果是否可用，可以按以下清单逐项核对。检查以流程要素表、场景清单和用例转换表三份产物为对象，任一项不通过即需返工。
| 检查类别 | 检查项 | 通过标准 |
|---|---|---|
| 流程覆盖 | 每个流程节点是否有对应场景 | 要素表中每一行至少被一个场景引用 |
| 流程覆盖 | 每个判定点是否覆盖各分支 | 每个判定点的可达分支均有场景，不可达分支有说明 |
| 流程覆盖 | 异常分支是否逐条覆盖 | 要素表中的异常分支均有对应场景 |
| 场景可追溯 | 场景是否标注来源节点 | 每个场景可回溯到流程编号和步骤 |
| 场景可追溯 | 场景之间是否重复 | 按角色、任务、判定分支、数据条件比对无重复 |
| 用例可执行 | 前置条件和测试数据是否可准备 | 数据有具体值或取值规则，环境要求明确 |
| 用例可执行 | 预期结果是否可观察 | 每个预期结果对应界面、数据或状态变化 |
| 用例可执行 | 用例能否被他人独立执行 | 不依赖场景描述即可按步骤操作并判定结果 |
阻断项包括：主流程场景缺失或无法跑通；关键判定点存在未覆盖分支且无合理说明；用例预期结果无法观察。出现任一阻断项时，应回到对应步骤返工，而不是在评审记录中标注遗留。返工完成后重新执行覆盖检查和可执行检查，通过后再形成基线。基线形成后，业务流程发生变更时，按流程编号定位受影响的要素行、场景和用例，同步修订并重新评审，保持三份产物一致。
常见问题
业务流程文档写得很粗，判定点和异常处理都没写清，怎么开始拆要素？
先做一轮流程走查，把文档中缺失的部分补到可拆解的粒度。具体做法是带着流程要素表的字段去和业务方逐段确认：每个步骤由哪个角色执行、在哪些位置存在条件判断、判断不通过时怎么处理。走查中确认不了的内容记为待澄清问题，标注责任人和结论时间，不要自行假设。
判定点和异常分支是拆要素时最容易缺失的部分。可以按步骤逐条追问“这一步什么情况下会失败”“失败后流程走向哪里”，把回答直接填入异常分支字段。流程说明确认到起止点、角色和规则无歧义后，再进入场景展开，避免在含糊的流程上生成大量返工场景。
判定点很多时，分支场景要不要做全组合？
通常不做全组合。判定点较多时按业务影响筛选：影响资金、库存、权限和状态流转的组合优先覆盖；相互独立的判定点分别覆盖即可；存在先后依赖的判定点按实际可达路径组合。业务上不可达的组合，例如库存不足却支付成功，不必生成场景，但建议在场景清单中注明不可达原因，便于评审时确认。
这样处理能在覆盖关键风险和场景数量之间取得平衡。如果业务规则对某些组合有明确要求，以规则为准补充场景。
场景清单和测试用例需要分开维护吗？
建议分开，至少保留两层结构。场景清单回答“业务上要验证什么”，粒度较粗，便于和业务方确认覆盖度；用例回答“具体怎么验证”，包含前置条件、操作步骤、预期结果和测试数据，供测试人员执行。两者通过场景编号和流程编号关联，场景变更时能定位到受影响的用例。
团队规模较小、流程简单时，也可以把场景作为用例的分组或标签管理，但来源流程节点的追溯标识应保留，否则后续做覆盖检查时无法判断哪个流程节点还没有对应场景。
业务流程发生变更后，已经提取的场景和用例怎么同步？
按流程编号定位受影响范围。流程变更通常落在某个步骤、判定点或异常分支上，先修订流程要素表中对应的行，再检查引用该行的场景是否需要增删，最后修订对应用例并重新评审。三份产物按流程编号关联，是同步修订的前提。
如果变更涉及新增判定点或异常分支，需要补充新场景并确认原有用例是否仍有效。修订完成后重新执行覆盖检查和可执行检查，通过后再更新基线，避免基线与实际流程脱节。
场景和用例需要在需求、测试、缺陷之间保持关联时，工具上怎么承载？
可以把流程要素表和场景清单作为文档沉淀，把用例作为测试工作项管理，并在工作项上保留来源流程节点和场景编号。ONES 支持需求、测试用例与缺陷之间的关联和评审流转，适合在业务、测试、开发多方交接时承载追溯关系；具体字段和流程配置可按团队现有管理方式设置。
工具承载的是关联关系，提取方法本身仍按流程要素表、场景清单、用例转换表推进。关联建立后，需求变更时可以从需求反查受影响的用例，缺陷修复后也能回溯到对应的场景和流程节点。
