一份可评审、可测试的用例规约，至少应包含用例编号与名称、参与者及其目标、前置条件与后置条件、触发事件、主流程、异常流程、业务规则与数据约束、非功能要求、关联需求与界面原型，以及评审与变更记录。本文按要素清单、参与者与前置条件、流程写法、角色分工、完整示例和自查项的顺序展开，帮助你把现有模板补齐并写成开发、测试都能直接使用的版本。
要点总览（TL;DR）
- 用例规约至少包含编号与名称、参与者与目标、前置与后置条件、触发事件、主流程、异常流程、业务规则、非功能要求与关联需求、评审与变更记录。
- 参与者按角色描述，主要参与者对应业务目标，支撑参与者写清其提供的服务；前置条件写成可观察的系统或业务状态，与触发事件分开。
- 主流程按编号逐步写“动作—系统响应”，判断分支拆到异常流程；异常流程从主流程具体步骤分叉，写明触发条件、处理动作和结束状态。
- 编写、评审、确认分工到需求分析人员、业务方、开发、测试，评审结论与版本变化留痕，规约才算完成闭环。
- 评审前用自查清单逐项判断：目标唯一、前置可观察、每步有响应、关键失败路径有覆盖、规则可追溯。
用例规约的必备要素清单
要素清单的价值在于让编写者知道每一栏回答什么问题，而不是把模板填满。下面这张表可以作为对照基准：现有模板缺哪一栏，就补哪一栏；某栏写了但回答不了对应问题，就按“作用”一列重写。
| 要素 | 回答什么问题 | 主要维护人 |
|---|---|---|
| 用例编号、名称与范围 | 这条用例在需求清单中如何被唯一引用？它覆盖哪段业务，明确不覆盖什么？ | 需求分析人员 |
| 参与者与目标 | 谁使用系统完成这件事？他希望通过这条用例达成什么业务结果？ | 需求分析人员，业务方确认 |
| 前置条件、后置条件与触发事件 | 开始前系统或业务必须处于什么状态？结束后应达到什么状态？由什么动作启动？ | 需求分析人员 |
| 主流程 | 在一切顺利的情况下，参与者与系统按什么顺序交互？ | 需求分析人员，开发与测试复核 |
| 异常流程 | 哪些步骤可能失败或出现分支？系统如何处理，最终停在哪里？ | 需求分析人员，开发补充技术性异常 |
| 业务规则与数据约束 | 流程中涉及哪些校验、权限、额度、格式或状态限制？ | 业务方提供规则，需求分析人员成文 |
| 非功能要求与关联需求 | 响应时间、并发量、可用性有何要求？关联哪些需求条目、界面原型或外部接口？ | 需求分析人员，开发与架构人员补充 |
| 评审与变更记录 | 谁在什么时间评审过？改了什么、为什么改？ | 需求分析人员维护，评审人签署 |
清单中每一项都对应一个后续动作：编号用于追溯，参与者与目标决定用例边界，前置与后置条件界定测试起点和验收终点，主流程与异常流程构成测试用例的来源，业务规则提供判定依据，评审记录保证变更有据可查。缺少任何一项，都会让某类读者无法使用这份规约——测试找不到预期结果，开发判断不了异常处理，业务方无法确认目标是否写对。
参与者与前置条件怎么写才可验证
参与者要按角色描述，不写具体人名。“门店店长”“财务审核员”“订单系统”是角色，“张三”“李经理”是人名。人名会随岗位调整失效，角色则能长期对应职责。当同一角色在不同场景下目标不同时，应拆成两条用例，而不是在一条用例里塞入两个目标。
参与者分两类。主要参与者是发起用例、并从中获得业务结果的角色，一条用例通常只有一个主要参与者；支撑参与者是系统需要调用或协作的对象，例如支付网关、短信平台、库存服务，它提供服务但不从这条用例中获得目标。把支撑参与者写进参与者栏，有助于在流程中交代外部依赖和失败处理。
参与者目标要与用例名称对应。用例名为“提交报销申请”，主要参与者“报销申请人”的目标就应是“完成报销单填写并提交，获得受理结果”。如果名称写“报销管理”，目标却写“审批报销单”，说明名称过宽或目标错位，需要拆分。
前置条件写成系统或业务已经成立、可以被观察或验证的状态，例如“申请人已登录且具有报销权限”“报销单处于草稿状态”“当期预算余额大于申请金额”。避免写“用户了解报销制度”这类无法检查的心理描述。前置条件与触发事件要分开：前置条件是静态状态，触发事件是启动用例的那个动作，例如“申请人点击提交按钮”。
正例与反例对照如下：
- 参与者：正例“仓库管理员”；反例“王主管”（人名，岗位变动后失效）。
- 目标：正例“完成入库单确认，使库存数量更新”；反例“使用入库功能”（描述操作而非业务结果）。
- 前置条件：正例“入库单已创建且状态为待确认”；反例“系统正常运行”（过于宽泛，无法判断是否满足）。
- 触发事件：正例“管理员点击确认入库”；反例“管理员有确认需求”（不是可执行动作）。
主流程与异常流程的分步写法
主流程按编号逐步书写，每一步采用“谁做什么—系统如何响应”的结构，一步只表达一个可执行动作。判断分支不放在主流程里，而是拆到异常流程或单独说明，这样主流程保持一条顺畅路径，测试也能据此写出正向用例。
步骤粒度以“一个动作产生一个可观察响应”为准。例如“填写收货信息并提交”应拆成“填写收货信息”和“提交订单”两步，因为提交后系统会返回校验结果，这是一个独立的响应点。步骤编号要稳定，后续异常流程引用“第3步”时才有意义。
异常流程从主流程的具体步骤编号分叉，写明三件事：触发条件、处理动作、结束状态。结束状态有两种——回到主流程某一步继续，或终止用例并给出提示。例如主流程第3步“系统校验库存”，异常流程可写“3a：库存不足时，系统提示缺货商品清单，用例终止，订单保持待支付状态”。
流程中涉及的业务规则用编号引用，不在步骤里重复展开规则内容。例如第4步写“系统按规则R2计算优惠金额”，规则R2单独列在业务规则栏，说明计算方式和适用条件。这样规则修改时只需改一处，流程描述保持稳定。
一个可套用的步骤模板如下：
- 参与者执行某动作。
- 系统校验某条件，返回结果。
- 系统按规则R1处理并更新某状态。
- 参与者确认，系统给出完成提示，用例结束。
异常流程模板：分叉点编号＋触发条件＋系统处理动作＋结束状态（回归主流程第N步或终止）。
角色分工与交付物：谁写、谁评审、谁确认
用例规约写完却无人确认，是常见返工来源。把编写、评审、确认拆到具体角色，并约定各自交付什么，可以让规约在进入开发前就完成闭环。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求分析人员 | 组织要素、成文主流程与异常流程、维护版本 | 用例规约文档、变更记录 |
| 业务方 | 确认参与者目标、业务规则与数据约束 | 目标与规则确认意见 |
| 开发人员 | 确认技术可行性、补充系统侧异常与外部依赖 | 异常处理补充说明、接口依赖清单 |
| 测试人员 | 确认流程可验证、每步有可观察结果 | 测试点映射、不可测项反馈 |
| 评审组织者 | 召集评审、记录结论与待办 | 评审记录、遗留问题清单 |
分工的关键是让每类角色只对自己能判断的内容签字：业务方判断目标与规则对不对，开发判断异常处理是否可实现，测试判断步骤是否可验证。需求分析人员负责把这些意见合并成一份文本，并保留每次修改的原因。评审记录至少包含评审时间、参与角色、结论（通过、有条件通过、退回）和待办责任人。
当用例规约作为需求文档在团队中流转时，文档需要与需求条目、测试用例建立关联，评审意见和版本变化也要能追溯。ONES 提供 Wiki 承载需求文档，测试管理中的用例库支持以结构化方式组织用例并配置自定义属性，便于把规约中的要素对应到用例字段；用例与缺陷、迭代的关联也能让后续变更找到影响范围。具体字段配置与版本能力以实际产品为准。
完整示例：一条用例从要素到流程
以下示例为演示情景，用于说明要素如何填满、流程如何对应，不代表任何真实业务系统。
用例编号与名称：UC-ORDER-012 提交订单并完成库存锁定。范围：覆盖从购物车提交订单到库存锁定的过程，不覆盖支付与发货。
参与者与目标：主要参与者“下单客户”，目标“提交有效订单并获得库存锁定结果”；支撑参与者“库存服务”，提供库存查询与锁定能力。
前置条件：客户已登录；购物车中至少有一件商品；商品处于可售状态。
触发事件：客户点击“提交订单”。
后置条件：成功时生成待支付订单且对应库存已锁定；失败时订单不生成，购物车内容保留。
业务规则：R1 单笔订单商品种类不超过20种；R2 库存锁定以提交时刻可用库存为准；R3 同一客户未支付订单不超过5笔。
主流程：
- 客户点击“提交订单”。
- 系统校验登录状态与未支付订单数量（R3），校验通过。
- 系统校验商品种类数量（R1），校验通过。
- 系统向库存服务查询并锁定库存（R2），返回锁定成功。
- 系统生成待支付订单，向客户展示订单号与支付入口，用例结束。
异常流程：
- 2a：未支付订单达到5笔时，系统提示“存在未支付订单，请先处理”，用例终止，购物车保留。
- 4a：库存服务返回部分商品库存不足时，系统展示缺货清单，不生成订单，用例终止，购物车保留。
- 4b：库存服务超时未响应时，系统提示“提交失败，请稍后重试”，用例终止，不锁定任何库存。
示例中每条异常流程都标注了分叉点（2a对应主流程第2步，4a、4b对应第4步），并写明结束状态。后置条件与业务规则一一对应：R2对应库存锁定结果，R3对应未支付订单校验。测试人员据此可以写出正向用例和三条异常用例，开发人员也能明确库存服务超时时的处理边界。
完成检查：用例规约评审前的自查项
评审前逐项判断，每项只有“通过”与“不通过”两种结论，不通过就回到对应章节修改。下面清单可直接复制到评审模板中使用。
| 检查项 | 判断标准 |
|---|---|
| 参与者与目标是否唯一明确 | 主要参与者只有一个，目标描述业务结果而非操作动作，且与用例名称对应 |
| 前置条件是否可观察 | 每条前置条件都是系统或业务中可检查的状态，不含心理或笼统描述 |
| 主流程是否每步有响应 | 每个编号步骤都有可观察的系统响应或状态变化，判断分支已拆出 |
| 异常流程是否覆盖关键失败路径 | 校验失败、外部服务失败、权限不足等关键路径均有对应异常流程，且标注分叉点与结束状态 |
| 业务规则与数据约束是否可追溯 | 规则单独编号，流程步骤按编号引用，规则内容可被业务方确认 |
| 评审与变更是否留痕 | 有评审记录、结论和待办责任人，版本变化注明原因 |
自查通过后再提交评审，可以把讨论集中在目标是否写对、异常是否遗漏这类实质问题上，减少格式和要素缺失带来的返工。评审结束后，把结论和待办记入变更记录，用例规约才算完成一次可追溯的交付。
常见问题
用例规约和需求文档、测试用例之间是什么关系？
用例规约是需求文档中描述单条业务交互的组成部分，回答“谁在什么条件下做什么、系统如何响应”。测试用例从规约的主流程和异常流程派生，把每个步骤和分叉点转成可执行的验证点。三者保持追溯关系时，需求变更能定位到受影响的测试用例；规约中的业务规则编号也便于测试写出判定依据。
一条用例里出现多个参与者目标时该怎么处理？
先判断这些目标是否属于同一次业务交互。若同一角色在不同场景下目标不同，例如“提交报销”和“撤回报销”，应拆成两条用例，各自写清前置条件与流程。若多个角色共同完成一件事，例如申请人提交、审核员审批，通常按角色拆成多条用例，用关联需求或流程编号衔接，避免一条用例里出现两个主要参与者导致边界模糊。
异常流程要写多细，是否每个可能失败点都要列？
优先覆盖影响业务结果的关键失败路径：校验不通过、权限不足、外部服务失败或超时、状态冲突。每条异常流程写明分叉点、触发条件、系统处理动作和结束状态。技术性异常可由开发补充，但需在评审时确认处理边界。把每个理论上的失败点都展开会让规约难以维护，判断标准是测试能否据此写出用例、开发能否据此确定处理方式。
用例规约写完后由谁确认才算定稿？
按判断内容分工确认：业务方确认参与者目标与业务规则，开发确认异常处理可实现，测试确认流程可验证，需求分析人员负责合并意见并成文。评审记录写明时间、参与角色、结论和待办责任人。定稿的标志是评审结论为通过或有条件通过且待办已闭环，版本变化注明原因，后续变更可追溯。
团队用文档工具管理用例规约时，需要注意什么？
文档需要与需求条目、测试用例建立关联，评审意见和版本变化要能追溯。ONES 提供 Wiki 承载需求文档，测试管理中的用例库支持以结构化方式组织用例并配置自定义属性，便于把规约中的要素对应到用例字段；用例与缺陷、迭代的关联也能让后续变更找到影响范围。具体字段配置与版本能力以实际产品为准。
