用例规约要写到能评审、能据此设计测试的程度，通常包含用例标识与名称、参与者与目标、触发条件、前置条件、主成功流程、异常与备选流程、后置条件与业务规则、数据与界面引用、非功能约束、关联需求与变更记录。本文按要素清单、字段写法、完整示例、角色分工和完成检查的顺序展开，重点说明参与者、前置条件、主流程与异常流程怎么写。
要点总览（TL;DR）
- 一份可评审的用例规约通常包含：用例标识与名称、参与者与目标、触发条件、前置条件、主成功流程、异常与备选流程、后置条件与业务规则、数据与界面引用、非功能约束、关联需求与变更记录。
- 参与者写角色或外部系统，主参与者与支撑系统分开；前置条件写成可验证的系统状态，并与触发条件分开。
- 主流程只保留一条成功路径，按步骤编号，每步写清谁做什么、系统如何响应，最后一步到达后置条件。
- 异常与备选流程从主流程的具体步骤编号分叉，写明触发条件、处理动作和结束状态，并标注恢复路径或终止路径。
- 提交评审前按要素完整性、前置条件可验证性、主流程与异常流程一致性逐项自查，确保开发和测试能据此判断行为。
用例规约的要素清单与最小可用版本
要素清单的作用是让写作者和评审者对照同一张表判断“写全了没有”。下面这张表按必填与按需划分，必填项是任何一条用例都绕不开的内容，按需项根据用例复杂度、涉及的数据和约束决定是否填写。
| 要素 | 说明 | 必填/按需 | 填写要点 |
|---|---|---|---|
| 用例标识 | 唯一编号，便于引用和追踪 | 必填 | 编号规则稳定，不随版本变化 |
| 用例名称 | 动宾结构概括参与者要达成的目标 | 必填 | 写“做什么”，不写“怎么做” |
| 参与者与目标 | 谁使用系统、想达成什么结果 | 必填 | 写角色或外部系统，不写具体人名 |
| 触发条件 | 启动用例的事件或时机 | 必填 | 与前置条件分开写 |
| 前置条件 | 用例开始前必须成立的系统状态 | 必填 | 可验证、可判断真假 |
| 主成功流程 | 一条从开始到目标达成的步骤序列 | 必填 | 编号，每步写动作与系统响应 |
| 异常与备选流程 | 主流程之外的分支与失败处理 | 必填 | 从主流程步骤编号分叉 |
| 后置条件 | 用例结束后系统应处于的状态 | 必填 | 与主流程最后一步对应 |
| 业务规则 | 约束判断、计算口径、权限规则 | 按需 | 规则复杂时单独列出并编号 |
| 数据与界面引用 | 涉及的数据项、字段、页面 | 按需 | 引用已有数据字典或原型，不重复描述 |
| 非功能约束 | 性能、安全、并发等要求 | 按需 | 只写与本用例直接相关的约束 |
| 关联需求 | 对应的需求条目或用户故事 | 必填 | 写明编号，保持双向可查 |
| 变更记录 | 版本、修改人、修改原因 | 必填 | 每次实质修改留痕 |
必填与按需的划分依据是“缺了它是否会导致开发或测试无法判断行为”。参与者、前置条件、主流程、后置条件缺失，读者无法确定系统该做什么；业务规则、数据引用、非功能约束在简单用例中可以并入流程步骤，在复杂用例中则需要独立成段。
最小可用版本包含标识、名称、参与者与目标、触发条件、前置条件、主流程、后置条件、关联需求和变更记录，足以支撑一次开发评审和基础测试设计。完整版本在此基础上补齐异常与备选流程、业务规则、数据与界面引用、非功能约束，适合跨团队协作、对外交付或质量要求较高的场景。团队可以先按最小版本建立统一格式，再对核心用例补充到完整版本。
参与者、前置条件与主流程的写法
参与者：写角色，不写人名
参与者描述的是与系统交互的角色或外部系统，例如“仓库管理员”“订单系统”“支付网关”。具体人名会随人员变动失效，也无法说明权限边界。主参与者是触发用例、以达成目标为目的的一方；支撑系统是用例运行中需要调用或依赖的外部系统，单独列出，避免与主参与者混在一起。
填写时给每个参与者标注类型和职责。例如：主参与者为“仓库管理员”，职责是发起入库单审核；支撑系统为“库存服务”，职责是提供实时库存数量。参与者名称应与权限模型中的角色名称保持一致，减少后续理解偏差。
前置条件：写成可验证的系统状态
前置条件是用例启动前系统必须满足的状态，判断标准是“能否用一条查询或检查确认它成立”。例如“操作人已登录且具有入库审核权限”“待审核入库单状态为‘待审核’”，这类条件可以被验证。写成“系统运行正常”“用户熟悉业务”则无法判断，也无法在测试中复现。
前置条件与触发条件要分开。前置条件是持续成立的状态，触发条件是让用例开始的那个事件。以入库审核为例，前置条件是“入库单已提交且状态为待审核、操作人具备审核权限”，触发条件是“操作人在待审核列表中点击‘审核’”。把触发事件写进前置条件，会让读者分不清用例从哪一刻开始。
主流程：一条成功路径，逐步编号
主流程只保留一条从触发到目标达成的成功路径，按步骤编号，每一步写清“谁在什么状态下做什么、系统如何响应”。步骤粒度以一次有意义的交互为准，避免把界面点击拆得过细，也避免把多个判断塞进同一步。
正例：
- 仓库管理员在待审核列表中选择一条状态为“待审核”的入库单，点击“审核”。
- 系统展示入库单明细，包括物料、数量、供应商和申请人。
- 仓库管理员核对明细后填写审核意见，点击“通过”。
- 系统将入库单状态更新为“已审核”，记录审核人和审核时间，并通知申请人。
反例是把多个动作和判断写进一句：“管理员审核入库单，如果没问题就通过，有问题就驳回，系统相应处理。”这句话既没有步骤编号，也把成功路径和分支混在一起，读者无法判断正常情况到底经过哪些步骤。
主流程的最后一步应当到达后置条件。上例的后置条件是“入库单状态为已审核，审核人、审核时间已记录，申请人收到通知”。写完主流程后回读最后一步，确认它与后置条件描述的是同一状态，这一步就是完成标志。
异常流程与备选流程如何描述
异常流程处理的是主流程中出现的错误、失败或系统无法继续的情况，例如校验不通过、外部系统超时、权限不足。备选流程处理的是参与者主动选择的其他成功路径，例如审核时选择“驳回”而不是“通过”，最终结果与主流程不同，但同样达成了某种业务目标。两者都不应混入主流程，否则主流程会失去“单一成功路径”的作用。
写法上，每条分支都要引用主流程的步骤编号作为分叉点，并写清三件事：触发条件、处理动作、结束状态。编号可以采用“主流程步骤号+分支序号”的方式，例如 3a、3b，便于读者回到主流程定位。
- 3a（备选，驳回）：若仓库管理员在步骤3选择“驳回”并填写驳回原因，系统将入库单状态更新为“已驳回”，记录驳回人和原因，通知申请人修改后重新提交。结束状态为入库单已驳回，用例结束。
- 3b（异常，明细校验失败）：若系统在步骤2发现入库数量与采购订单不一致，提示差异项并阻止提交审核结果。仓库管理员可返回核对或取消操作。选择取消时，入库单保持“待审核”，用例终止。
- 2a（异常，支撑系统超时）：若库存服务在步骤2响应超时，系统提示“库存校验暂不可用”，允许仓库管理员稍后重试。重试成功后回到步骤2继续；连续失败则终止本次审核，入库单状态不变。
每条分支还要标注它是恢复路径还是终止路径。恢复路径说明处理完成后回到主流程的哪一步继续；终止路径说明用例在什么状态下结束、系统留下什么结果。标注清楚后，测试人员可以直接据此设计异常场景，开发人员也能判断需要哪些补偿或回滚逻辑。
完整示例：一条用例规约的填写过程
下面以“仓库管理员审核入库单”为例，把前述要素落到一份可评审的文本中。示例为演示情景，用于说明字段之间的呼应关系。
| 要素 | 填写内容 |
|---|---|
| 用例标识 | UC-WMS-012 |
| 用例名称 | 审核入库单 |
| 主参与者 | 仓库管理员（具备入库审核权限） |
| 支撑系统 | 库存服务、消息通知服务 |
| 目标 | 对待审核入库单给出审核结论，使单据进入已审核或已驳回状态 |
| 触发条件 | 仓库管理员在待审核列表中点击某条入库单的“审核”按钮 |
| 前置条件 | 操作人已登录且具有入库审核权限；入库单状态为“待审核”；入库单已关联采购订单 |
| 后置条件 | 成功时：入库单状态为“已审核”，记录审核人、审核时间和审核意见，申请人收到通知；驳回时：状态为“已驳回”，记录驳回原因 |
| 业务规则 | BR-01 入库数量不得超过采购订单剩余可入库数量；BR-02 审核意见在驳回时必填，通过时选填 |
| 关联需求 | REQ-WMS-034 入库单审核流程 |
| 变更记录 | V1.0 初稿；V1.1 补充库存服务超时分支 |
主流程：
- 仓库管理员在待审核列表中选择一条入库单，点击“审核”。
- 系统展示入库单明细，并调用库存服务校验数量是否符合 BR-01。
- 仓库管理员核对明细，填写审核意见，选择“通过”。
- 系统将入库单状态更新为“已审核”，记录审核人、审核时间与意见，通过消息通知服务通知申请人。
异常与备选流程：
- 2a（异常，数量超限）：库存校验返回超出可入库数量，系统高亮差异项并阻止进入步骤3。仓库管理员可取消操作，入库单保持“待审核”，用例终止。
- 2b（异常，库存服务超时）：系统提示校验暂不可用，允许重试。重试成功回到步骤2；重试三次仍失败则终止，状态不变。
- 3a（备选，驳回）：仓库管理员选择“驳回”并填写原因，系统将状态更新为“已驳回”并通知申请人，用例结束。
回读这份示例可以看到字段之间的呼应：前置条件里的“状态为待审核”对应触发时列表中的可选范围，主流程步骤2对应业务规则 BR-01，步骤4对应后置条件中的状态与记录项，异常分支 2a、2b 都从具体步骤编号分叉并写明结束状态。评审时若发现某条业务规则没有对应步骤，或某个后置条件没有步骤产生，就说明规约存在缺口。
角色分工与评审交付物
用例规约通常由需求分析人员主笔，需求提出者提供业务背景和规则，开发和测试在评审中确认可实现性与可验证性。分工的关键是每个角色都有明确的输入和输出，避免规约成为一个人的文档。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 需求提出者 | 说明业务目标、参与角色、业务规则和例外情况 | 业务规则清单、例外场景说明 |
| 需求分析人员 | 主笔规约，统一要素格式，维护关联需求与变更记录 | 用例规约正文、要素清单 |
| 开发人员 | 确认流程可实现，指出缺失的系统响应和状态定义 | 评审意见、技术约束补充 |
| 测试人员 | 依据主流程与异常流程设计测试场景，检查前置条件可验证性 | 测试场景清单、评审意见 |
评审时重点检查四类问题：参与者是否覆盖了所有与系统交互的角色和外部系统；前置条件是否都能被验证；主流程每一步是否有明确的系统响应；每条异常分支是否有触发条件、处理动作和结束状态。评审结论应落到具体条目，而不是笼统的“通过”或“需完善”。
规约与需求条目、测试用例保持可追踪关系：每条用例规约关联至少一个需求条目编号，测试用例引用用例标识和具体步骤编号。变更时先更新规约正文和变更记录，再同步关联的测试场景，避免文档与测试脱节。在 ONES 中，需求条目、用例与测试用例可以放在同一套工作项体系里承载，评审意见和变更记录随条目留存，便于后续追溯；ONES 测试管理的用例库支持以结构化方式组织用例并配置自定义属性，可用来承载用例标识、前置条件等字段。具体字段如何配置，需要结合团队实际的用例模板确定。
完成检查：用例规约是否可交付
提交评审前，按下表逐项自查。每项给出可判断的通过标准，任一项不通过即视为未完成。
| 检查项 | 通过标准 | 阻断项 |
|---|---|---|
| 要素完整性 | 标识、名称、参与者与目标、触发、前置条件、主流程、异常流程、后置条件、关联需求、变更记录均已填写 | 缺少参与者、主流程或后置条件 |
| 前置条件可验证性 | 每条前置条件都能通过查询或检查判断真假，且与触发条件分开 | 出现“系统正常”“用户熟悉业务”等无法判断的表述 |
| 主流程一致性 | 主流程只有一条成功路径，步骤连续编号，最后一步到达后置条件 | 主流程中混入条件分支或缺少系统响应 |
| 异常流程一致性 | 每条分支引用主流程步骤编号，写明触发条件、处理动作、结束状态，并标注恢复或终止 | 分支无法定位到主流程步骤，或未写结束状态 |
| 参与者与目标清晰度 | 参与者为角色或外部系统，主参与者与支撑系统分开，目标为可观察的业务结果 | 使用具体人名，或目标写成操作步骤 |
| 规则与流程对应 | 每条业务规则至少对应一个流程步骤或分支 | 存在无步骤承载的业务规则 |
| 关联与变更 | 关联需求编号可查，变更记录包含版本、修改人和原因 | 关联需求缺失或变更无记录 |
自查通过的标准是：一位未参与编写的开发和一位测试人员，仅凭这份规约就能分别判断需要实现哪些系统响应、需要设计哪些正常与异常场景，并且对结果的理解一致。达到这个状态，用例规约就可以进入评审和后续的测试设计环节。
常见问题
用例规约和用户故事、需求条目之间是什么关系？
用户故事用一句话概括“谁想要什么、为什么”，适合做需求池里的轻量条目；用例规约把这条需求展开成可评审、可测试的行为描述。两者可以并存：需求条目负责记录业务目标和优先级，用例规约负责写清参与者、前置条件、主流程和异常流程。关联时在规约中写明对应的需求条目编号，保持双向可查，变更时同步更新。
前置条件写多少条合适，写多了会不会限制实现方式？
前置条件只写“用例开始时必须成立、且能被验证的系统状态”，例如登录状态、权限、单据状态、关联数据是否存在。与本次目标无关的环境描述不必写入。前置条件写多写少取决于用例依赖的状态数量，判断标准是：缺少这条，主流程是否可能无法按描述执行。它约束的是开始条件，不规定系统内部如何实现。
主流程中遇到判断分支，应该拆到异常流程还是保留在主流程里？
主流程只保留一条成功路径。凡是参与者主动选择的其他成功路径（如驳回、转交），放到备选流程；凡是校验失败、超时、权限不足等无法按主流程继续的情况，放到异常流程。两者都引用主流程的步骤编号作为分叉点，写明触发条件、处理动作和结束状态。这样主流程保持线性，测试人员也能按分支逐条设计场景。
用例规约写完由谁确认可以进入开发和测试？
通常由需求分析人员主笔，需求提出者确认业务规则和例外场景，开发和测试在评审中确认可实现性与可验证性。确认写完的判断标准是：未参与编写的开发和测试仅凭规约，就能分别判断需要实现哪些系统响应、需要设计哪些正常与异常场景，且理解一致。评审意见应落到具体条目，而不是笼统结论。
用例规约在系统中承载时，如何与测试用例保持同步？
常见做法是让测试用例引用用例标识和具体步骤编号，需求条目与用例规约互相记录编号。变更时先更新规约正文和变更记录，再同步关联的测试场景。在 ONES 中，需求条目、用例与测试用例可以放在同一套工作项体系里承载，评审意见和变更记录随条目留存；ONES 测试管理的用例库支持以结构化方式组织用例并配置自定义属性，可用来承载用例标识、前置条件等字段，具体字段如何配置需结合团队实际的用例模板确定。
