用例的主流程按“参与者发起—系统响应—状态推进—目标达成”的顺序写，每一步用“谁做什么、系统给出什么结果”的句式，只保留一条能走通的最短路径；异常流程从主流程的某个步骤分叉，写清触发条件、系统提示或拦截动作、参与者的补救选择，以及最终回到主流程还是终止。动笔前先固定用例规约的六个要素，再逐项填写并做覆盖检查，可以避免主流程写成操作手册、异常流程写成零散备注。
要点总览（TL;DR）
- 先固定用例规约的六个要素——参与者、前置条件、触发事件、主流程、异常流程、后置条件，再动笔写流程，主流程和异常流程才有稳定的挂载位置。
- 主流程只保留一条能走通的最短路径，按“参与者动作—系统响应”交替编号，一步一个动作，遇到条件判断先移到异常清单。
- 异常流程从主流程的具体步骤分叉，编号引用主流程步骤号（如 4a），每条写清触发条件、系统处理、参与者选择和结束方式。
- 每条异常都要说明是回到主流程第几步还是终止，终止时系统停留在什么状态，并与后置条件对应。
- 定稿前按检查清单核对：主流程唯一可走通、关键步骤覆盖异常、前后置条件可验证、编号可追溯。
用例规约先写哪些要素
用例规约的价值在于让开发、测试和业务方对同一条用例有一致理解。动笔写流程之前，先把字段固定下来，后续主流程和异常流程才有稳定的挂载位置。下面六个要素构成一份最小可评审的规约。
| 要素 | 填写口径 | 示例值 |
|---|---|---|
| 参与者 | 与系统交互的角色或外部系统，按职责命名 | 订单专员、支付网关 |
| 前置条件 | 流程开始前系统或数据必须已满足的状态 | 订单已提交且处于“待支付”状态 |
| 触发事件 | 让用例开始的那个动作或外部事件 | 订单专员点击“发起支付” |
| 主流程 | 一条能达成目标的最短成功路径，按步骤编号 | 见后文示例 |
| 异常流程 | 从主流程某一步分叉的偏离路径及处理结果 | 支付超时后的重试或取消 |
| 后置条件 | 流程结束后系统应处于的可验证状态 | 订单状态为“已支付”，生成支付流水 |
常见错误集中在三处：前置条件写成操作步骤，例如“用户登录后点击菜单”，这属于流程内容；触发事件与前置条件混为一谈，把“订单已提交”当成触发；后置条件写成主观描述，例如“用户满意”，无法验证。要素之间是承接关系：前置条件支撑主流程的起点，触发事件启动流程，后置条件承接主流程和异常流程各自的结束状态。写异常流程时如果发现某条分支结束后无法落到任何后置条件，通常说明该分支的结束方式还没想清楚。
参与者与前置条件怎么写
参与者按角色描述，不写具体人名或岗位上的某个人。“订单专员”是角色，“张三”不是；“财务审核员”是角色，“财务部”作为组织也不够精确，因为它没有说明是谁在执行动作。主要参与者是发起并推动用例达成目标的一方，支撑系统是参与交互但不以该用例为目标的外部系统，例如支付网关、短信平台。两者都要列出，因为支撑系统的失败往往正是异常流程的来源。
前置条件写成系统或数据必须已满足的状态，并且可以被检查。判断标准是：测试人员能否在流程开始前通过查询数据或界面状态确认它成立。可验证的写法如“账户状态为正常且余额不低于订单金额”，不可验证的写法如“用户已了解支付规则”。前置条件也不应包含操作步骤，凡是“点击、进入、选择”这类动作，都属于主流程的内容。
前置条件与触发事件的区分可以用一句话检验：前置条件是“已经为真的状态”，触发事件是“让流程开始的那个动作”。前者用陈述状态的名词句，后者用动词句。两者相邻书写，读者能清楚知道流程从哪一刻起算。
| 项目 | 不推荐写法 | 推荐写法 |
|---|---|---|
| 参与者 | 张三、财务部 | 订单专员、财务审核员 |
| 前置条件 | 用户登录系统并打开订单页 | 订单已提交，状态为“待支付”，且未超过支付时限 |
| 触发事件 | 订单处于待支付状态 | 订单专员点击“发起支付” |
主流程的编写步骤
主流程只保留一条能走通的最短路径，编写时可以按以下步骤推进，每一步都有明确的输入和产出。
- 确定成功目标。输入是用例名称和业务意图，动作是写出流程结束时必须成立的结果，输出是一句可验证的目标，例如“订单完成支付并生成支付流水”。这个目标同时决定后置条件。
- 倒推最短路径。从目标出发，问“达成它之前系统必须处于什么状态”，逐层向前推，直到回到触发事件。倒推能过滤掉可有可无的中间操作。
- 按“参与者动作—系统响应”交替编号。一步只写一个动作或一个响应，编号连续。参与者动作写“谁做什么”，系统响应写“系统给出什么结果”，例如“系统校验余额并冻结相应金额”。
- 把分支移出主干。写作过程中遇到“如果……则……”的句子，先记到异常清单，主流程只保留默认成立的那条路。主干越短，异常与主干的对应关系越清楚。
- 核对状态推进。逐步检查每个系统响应是否让状态向前走了一步，是否存在两步之间状态没有变化的空转步骤。空转步骤通常可以合并或删除。
- 验证可连续走通。完成标志是从触发事件开始，按编号顺序读完，能够自然到达后置条件，中间不需要补充任何隐含假设。
一条完整的主流程示例如下（演示场景）：
- 订单专员在订单详情页点击“发起支付”。
- 系统校验订单状态为“待支付”，展示可用的支付方式。
- 订单专员选择支付方式并确认支付金额。
- 系统生成支付单，调用支付网关发起扣款。
- 支付网关返回扣款成功。
- 系统将订单状态更新为“已支付”，记录支付流水并提示支付成功。
这六步中，每一步都有明确的责任方和可见结果，步骤之间状态连续推进，没有出现条件判断。凡是需要判断的地方，都留给异常流程处理。
异常流程怎么从主流程分叉
异常流程不是把所有可能出错的情况罗列一遍，而是从主流程的具体步骤分叉，并写清处理结果。识别异常时可按来源分类，逐类对照主流程检查：输入校验失败（金额、格式、必填项不合法）、权限或状态不满足（无操作权限、订单状态已变更）、外部依赖失败（支付网关超时、短信发送失败）、参与者中途放弃（取消、关闭页面、超时未操作）。
编号上建议采用“主流程步骤号 + 分支序号”的方式，例如主流程第 4 步的分支记为 4a、4b。这样评审时可以直接定位分叉点，修改主流程后也容易发现哪些异常需要同步调整。每条异常流程按四段式书写：触发条件、系统处理、参与者选择、结束方式。结束方式必须明确写成“回到主流程第 N 步”或“用例终止”，并与后置条件对应：终止的异常也要说明系统停留在什么状态，例如“订单保持待支付，释放已冻结金额”。
| 字段 | 写法要求 | 示例 |
|---|---|---|
| 编号 | 引用主流程步骤号加分叉序号 | 4a |
| 触发条件 | 可观察的事件或判断结果 | 支付网关在约定时限内未返回结果 |
| 系统处理 | 提示、拦截、回滚或重试等具体动作 | 系统标记支付单为“处理中”，提示稍后查询 |
| 参与者选择 | 可执行的补救选项 | 订单专员选择“重新查询”或“取消支付” |
| 结束方式 | 回到主流程某步，或终止并说明状态 | 查询成功则回到主流程第 5 步；取消则终止，订单保持待支付 |
异常流程与后置条件的关系需要专门检查：每条异常结束时，系统状态都应能被后置条件或状态说明覆盖。如果一条异常写完后说不清数据处于什么状态，说明系统处理动作还缺失，应回到需求层面确认，而不是在文字上含糊带过。
完整示例：一条用例的主流程与异常流程
以下是一条已填写的用例规约（演示场景），用于展示各要素如何配合。
用例名称：订单支付。参与者：订单专员（主要参与者）、支付网关（支撑系统）。前置条件：订单已提交，状态为“待支付”，且未超过支付时限。触发事件：订单专员点击“发起支付”。后置条件：支付成功时订单状态为“已支付”并生成支付流水；支付未完成时订单保持“待支付”，已冻结金额被释放。
主流程：
- 订单专员在订单详情页点击“发起支付”。
- 系统校验订单状态为“待支付”，展示可用支付方式。
- 订单专员选择支付方式并确认支付金额。
- 系统生成支付单，调用支付网关发起扣款。
- 支付网关返回扣款成功。
- 系统将订单状态更新为“已支付”，记录支付流水并提示成功。
异常流程：
- 2a（状态不满足）：系统校验时发现订单已被取消。系统提示“订单已取消，无法支付”并关闭支付入口，用例终止，订单保持已取消状态。
- 3a（输入校验失败）：订单专员确认的金额与订单应付金额不一致。系统拦截提交并提示差额，订单专员可修正金额后回到主流程第 3 步，或放弃操作终止用例。
- 4a（外部依赖失败）：支付网关在约定时限内未返回结果。系统将支付单标记为“处理中”并提示稍后查询，订单专员选择重新查询，查询到成功结果则回到主流程第 5 步；选择取消则终止，系统释放冻结金额，订单保持“待支付”。
从这个示例可以提炼几条可迁移的做法：主流程保持六步以内，判断全部外移；异常编号直接指向分叉步骤，评审时一眼能对上；每条异常都写明了结束方式和结束时的数据状态；支撑系统作为参与者出现，其失败自然成为异常来源。换到审批、退款、开户等场景时，这套结构同样适用，只需替换参与者、状态和外部依赖。
当多条用例需要一起评审时，规约文档的版本和评审意见容易分散。ONES 支持将需求以工作项承载，把用例规约作为文档关联到对应工作项，评审意见和修改记录随文档版本留存，便于在需求变更后回查某条异常流程是何时补充的。这一衔接适用于需要多人评审和版本追溯的团队，规约本身的写法仍以上述要素和步骤为准。
写完后的覆盖检查
规约达到可评审状态前，按下面清单逐项核对，每项都给出可判断的通过标准。
| 检查项 | 通过标准 |
|---|---|
| 主流程唯一且可走通 | 只有一条主干，从触发事件按编号读完可到达后置条件，无需补充隐含假设 |
| 关键步骤覆盖异常 | 每个涉及校验、权限、状态变更和外部调用的步骤，都有对应异常或写明“无预见异常及理由” |
| 异常有明确结束方式 | 每条异常写明回到主流程第几步或终止，并说明终止时的系统状态 |
| 前后置条件可验证 | 前置条件和后置条件都能通过查询数据或界面状态确认，不含操作步骤和主观描述 |
| 参与者与分工清晰 | 参与者按角色命名，主要参与者与支撑系统分开列出，每个步骤都能对应到责任方 |
| 编号可追溯 | 异常编号引用主流程步骤号，主流程调整后能快速定位需同步修改的异常 |
检查中发现的问题按两类处理：属于描述遗漏的，直接补写；属于需求本身没想清楚的，例如某条异常结束后数据状态无法确定，应回到需求澄清环节确认后再改规约，避免用模糊措辞掩盖未决问题。完成以上核对后，规约即可提交评审，并在评审中重点确认异常流程的结束方式是否与业务预期一致。
常见问题
主流程里出现“如果……则……”的判断，应该怎么处理？
把判断整体移到异常流程，主流程只保留默认成立的那条路。具体做法是：在主流程对应步骤旁记下分叉点，异常流程用“主流程步骤号 + 分支序号”编号，例如第 4 步的判断写成 4a、4b。这样主干保持连续可读，评审时也能直接定位分叉位置。如果发现某个判断几乎每次都会触发、默认路径反而很少走，说明主流程选错了成功路径，应重新确认目标后再调整主干。
异常流程结束后一定要回到主流程吗？
不要求。结束方式有两种：回到主流程第 N 步继续，或者终止用例。关键是写清楚选了哪一种，以及终止时系统处于什么状态，例如“订单保持待支付，释放已冻结金额”。如果一条异常写完后说不清数据状态，通常说明系统处理动作还没定义，应回到需求层面确认，而不是在文字上含糊带过。
前置条件和触发事件容易混，怎么快速区分？
用句式判断：前置条件是“已经为真的状态”，用陈述状态的名词句，例如“订单已提交，状态为待支付”；触发事件是“让流程开始的那个动作”，用动词句，例如“订单专员点击发起支付”。另一个检验标准是测试人员能否在流程开始前通过查询数据或界面状态确认前置条件成立，凡是“点击、进入、选择”这类动作，都属于主流程内容。
一条用例要写多少条异常流程才算够？
按来源逐类对照主流程检查，而不是追求数量。常见来源有四类：输入校验失败、权限或状态不满足、外部依赖失败、参与者中途放弃。每个涉及校验、权限、状态变更和外部调用的主流程步骤，都应有对应异常，或者明确写下“无预见异常及理由”。覆盖判断以关键步骤为准，与业务影响小的边角情况可以在评审时由测试和业务方共同确认是否补充。
多条用例一起评审时，规约版本和评审意见怎么管？
规约文档分散在多处时，修改记录和评审意见容易丢失。可以把需求以工作项承载，用例规约作为文档关联到对应工作项，评审意见和版本随文档留存，需求变更后能回查某条异常流程是何时补充的。ONES 的工作项与文档关联方式适合需要多人评审和版本追溯的团队，规约本身的写法仍以上述要素和步骤为准。
