用例规约应包含哪些要素：参与者、前置条件与流程写法

用例规约把“谁在什么条件下做什么、系统如何响应、失败时怎么办”写成可执行、可评审的文本。一份完整的规约通常包含用例名称与编号、参与者与目标、前置条件、触发事件、主流程、异常流程、后置条件、业务规则与数据约束、非功能约束、关联需求与界面引用。下面按字段清单、参与者与前置条件、流程写法、完整示例、评审与完成检查的顺序展开，写完后可直接对照检查。文中示例为演示情景，ONES 相关内容用于说明用例规约在需求管理中的承载方式。

要点总览（TL;DR）

• 一份可执行的用例规约通常包含用例名称与编号、参与者与目标、前置条件、触发事件、主流程、异常流程、后置条件、业务规则与数据约束、非功能约束、关联需求与界面引用，可按项目裁剪但要留下记录。
• 参与者按角色而非人名书写，区分主要参与者与支撑系统；前置条件只写进入用例前必须成立的状态，触发事件写启动用例的那个动作，两者相邻书写。
• 主流程保持单一成功路径，按参与者动作与系统响应交替编号；异常流程从主流程具体步骤分叉，标注来源步骤号，并写明触发条件、处理动作与结束状态。
• 业务规则单独编号、流程直接引用编号，能避免同一规则多处重复描述；评审时先看参与者目标与后置条件是否首尾呼应，再检查异常分支覆盖。
• 完成标准可定为：检查表全部通过或待补充项已明确责任人与期限，开发能据此估算、测试能据此设计场景、业务方确认规则无误。

用例规约的要素清单与字段说明

先建立字段基准，再动笔写流程。字段的价值在于让不同角色读到同一份信息：业务方确认目标与规则，开发确认分支与状态，测试据此设计场景。字段写得过粗，流程会靠口头补充；写得过细，又会把界面细节和实现方案混进来。判断粒度的一个实用标准是：每条内容都能被验证，且不依赖某一种实现方式。

下表给出常用字段、填写内容、必填性与示例片段。必填性按“缺少后无法评审或无法设计测试”来判断，可按项目裁剪，但裁剪要有记录。

字段	填写内容	必填性	示例片段
用例名称与编号	动宾结构名称，编号与需求或工作项对应	必填	UC-ORDER-012 提交订单
参与者与目标	按角色列出主要参与者与支撑系统，写明参与者希望通过用例达成的结果	必填	主要参与者：注册买家；目标：完成订单提交并获得订单号
前置条件	用例开始前系统、数据、权限必须成立的状态	必填	买家已登录且购物车中存在可售商品
触发事件	启动用例的动作或事件	必填	买家在购物车页点击“提交订单”
主流程	参与者动作与系统响应交替编号的单一成功路径	必填	1. 买家点击提交；2. 系统校验库存并生成订单
异常流程	从主流程具体步骤分叉的失败或替代路径，含触发条件、处理动作与结束状态	必填	2a 库存不足：系统提示缺货商品，流程结束于购物车页
后置条件	用例成功或失败结束后系统应处于的状态	必填	成功：订单状态为“待支付”，库存已锁定
业务规则与数据约束	影响判断的规则、取值范围、计算口径	按需，涉及判断时必填	单笔订单金额上限 5 万元
非功能约束	与本用例相关的性能、安全、合规要求	按需	提交响应时间不超过 2 秒
关联需求与界面引用	上游需求编号、原型或界面说明的位置	按需	关联需求 REQ-208；界面见订单确认页原型

字段之间要保持对应关系：参与者目标决定主流程的终点，主流程的每一步又决定后置条件写成什么状态。常见的不一致是目标写“完成退款”，主流程却停在“提交退款申请”，后置条件也随之含糊。评审时先看目标与后置条件是否首尾呼应，再检查异常流程是否覆盖了主流程中所有可能失败的判断点。

业务规则建议单独编号，例如 BR-01、BR-02，流程步骤直接引用编号，避免同一条规则在多处重复描述、改一处漏一处。非功能约束只写与本用例直接相关的部分，全局性的性能与安全要求放在需求或架构文档中引用即可。

参与者、前置条件与触发事件怎么写

参与者按角色写，不按人名写。“注册买家”“区域运营专员”“对账系统”是角色，“张三”“财务部小李”不是。角色划分的依据是权限与职责差异：同一类人在系统中的可用操作和目标一致，就归为一个角色。主要参与者是发起用例并从中获得结果的角色；支撑系统是参与交互但不以该用例为目标的外部系统，例如支付网关、短信平台，需要单独列出，因为它们的响应会直接影响异常流程。

参与者目标要与用例目标对应。写法上建议一句“参与者希望通过本用例……”来检验：如果写不出参与者获得的具体结果，说明用例边界还没定清。一个用例只服务一个主要参与者的一个目标；当两个角色的目标明显不同，通常应拆成两个用例，或明确其中一个是用例的支撑角色。

前置条件描述进入用例前必须成立的状态，通常分三类：系统状态（服务可用、订单模块已开通）、数据状态（购物车非空、账户余额充足）、权限状态（已登录、具备提交权限）。前置条件只写“必须为真”的事实，不写操作步骤，也不写“用户打开页面”这类动作，动作属于触发事件或主流程。

触发事件与前置条件的区别在于：前置条件是静态状态，触发事件是启动用例的那个动作或事件。前置条件写“买家已登录”，触发事件写“买家点击提交订单”。两者相邻书写，读者才能判断用例从哪一刻开始计算。

前置条件写得过多，会把本应放在流程中的校验提前成进入门槛，导致异常流程无处安放；写得过少，流程中会冒出未交代的状态，开发和测试只能自行假设。一个可操作的判断是：如果某个条件不成立时系统需要给出提示或走替代路径，它更适合作为流程中的校验步骤；只有当条件不成立时用例根本不应启动，才写进前置条件。

主流程与异常流程的编写步骤

主流程只保留一条成功路径，按“参与者动作—系统响应”交替编号。每一步只写一个可观察的动作或响应，避免把多个操作塞进同一步。编号连续，便于异常流程引用。下面给出编写步骤。

1. 确定起点：从触发事件之后的第一步写起，前置条件不重复写入流程。
2. 按交替节奏展开：参与者动作一步，系统响应一步，直到参与者目标达成。
3. 检查单一成功路径：出现“如果……则……”的分支，说明该内容应移入异常流程或业务规则。
4. 写出终点状态：最后一步的系统响应应能直接支撑后置条件的表述。

异常流程从主流程的具体步骤分叉，并标注来源步骤号，常用写法是“2a”“2b”，表示从第 2 步分出的第一条、第二条异常路径。每条异常流程写清三件事：触发条件（什么情况下进入）、处理动作（系统与参与者各自做什么）、结束状态（用例在此结束、回到主流程某步，还是转入另一用例）。

示例片段：主流程第 2 步为“系统校验库存并生成订单”，则异常流程可写“2a 库存不足：系统列出缺货商品并保留购物车内容，用例结束于购物车页”；“2b 支付方式不可用：系统提示更换支付方式，返回主流程第 3 步”。前者是终止型异常，后者是恢复型异常，结束状态必须写明，否则测试无法判断预期结果。

异常流程与业务规则通过编号引用建立关系。例如“2a”的触发条件引用 BR-03（库存锁定规则），读者不必在两处重复阅读同一规则。异常流程不宜穷举所有技术故障，重点覆盖业务上可预期、需要产品决策的分支；系统级故障由非功能约束或运维预案承接。

完整示例：一条用例规约的填写示范

以下为演示情景，用于展示字段与流程如何串联，不代表真实项目案例。

字段	填写内容
用例名称与编号	UC-ORDER-012 提交订单
参与者与目标	主要参与者：注册买家；支撑系统：库存服务、支付网关。目标：买家将购物车商品提交为待支付订单并获得订单号
前置条件	买家已登录并具备下单权限；购物车中存在可售商品；库存服务与支付网关可用
触发事件	买家在购物车页点击“提交订单”
主流程	1. 买家点击“提交订单”；2. 系统校验商品可售状态与库存，锁定库存；3. 系统生成订单并返回订单号；4. 系统跳转至支付页，展示应付金额；5. 买家确认支付方式，用例结束
异常流程	2a 库存不足：系统列出缺货商品并保留购物车内容，用例结束于购物车页（引用 BR-03）；2b 商品已下架：系统提示下架商品并允许移除后重新提交，返回主流程第 1 步；4a 支付页加载失败：系统提示重试并保留订单为“待支付”，用例结束
后置条件	成功：订单状态为“待支付”，库存已锁定，订单号可查询；失败：购物车内容保留，未产生订单或订单保持“待支付”
业务规则与数据约束	BR-03 库存锁定以提交时刻为准；BR-04 单笔订单金额上限 5 万元
非功能约束	提交响应时间不超过 2 秒；订单号全局唯一
关联需求与界面引用	关联需求 REQ-208；界面见订单确认页与支付页原型

这个示例体现了三条写法规则：主流程保持单一成功路径，所有判断分支都进入异常流程；异常流程标注来源步骤号并写明结束状态；业务规则单独编号后被流程引用。迁移到其他业务时，字段结构可以沿用，但前置条件与异常分支要按实际业务重新判断，不能照搬示例中的库存与支付假设。

当团队把用例规约作为需求工作项管理时，规约正文、评审意见和变更记录需要放在同一处可追溯的位置。ONES 提供需求与测试相关的管理能力，用例库支持通过不同方式导入用例并以结构化方式组织管理，也提供自定义属性以适应不同场景的字段需求；用例规约可以作为需求工作项的交付内容承载，评审与变更在同一工作项下留痕，便于后续追溯。

角色分工、评审与完成检查

编写者通常是需求分析或产品角色，负责把业务目标转成字段与流程；评审者包括开发、测试和对口业务方，分别检查可实现性、可测性与业务规则准确性；需求提出方确认目标、前置条件和业务规则符合实际。三方分工的意义在于：编写者对完整性负责，评审者对可执行性负责，提出方对业务正确性负责。

评审按检查表逐项过，避免停留在“看起来差不多”。下表可作为评审记录模板。

检查项	通过标准	结论
要素齐全	必填字段均有内容，按需字段的缺失有说明	通过 / 待补充
参与者与目标	按角色书写，主要参与者与支撑系统区分清楚，目标可验证	通过 / 待修改
前置条件	只写进入前必须成立的状态，未混入操作步骤	通过 / 待修改
主流程可执行	动作与响应交替编号，单一成功路径，终点支撑后置条件	通过 / 待修改
异常覆盖	业务上可预期的分支均有来源步骤号、触发条件与结束状态	通过 / 待补充
规则引用	业务规则单独编号，流程引用编号且无重复描述	通过 / 待修改
可测性	测试可据主流程与异常流程直接设计场景与预期结果	通过 / 待修改

完成标志可以定为：检查表全部通过或待补充项已明确责任人与期限；开发能据此估算，测试能据此列出场景，业务方确认规则无误。达到这一状态后，用例规约随需求进入设计与开发环节。

变更维护方面，规约修改应保留版本与修改原因，流程步骤编号尽量稳定，新增分支用字母后缀扩展而不重排既有编号，避免测试用例与评审记录失去对应。评审意见与变更记录随需求工作项留存，后续追溯时能看清每次调整的依据。

常见问题

前置条件和触发事件容易混在一起，怎么区分？

看它是静态状态还是启动动作。前置条件写“买家已登录并具备下单权限”“购物车中存在可售商品”这类进入用例前必须成立的事实；触发事件写“买家在购物车页点击提交订单”这个启动用例的动作。两者相邻书写，读者才能判断用例从哪一刻开始计算。

另一个判断标准是：条件不成立时用例是否根本不应启动。如果是，写进前置条件；如果系统需要给出提示或走替代路径，更适合作为流程中的校验步骤。

异常流程要覆盖到什么程度，技术故障也要逐条写吗？

重点覆盖业务上可预期、需要产品决策的分支，例如库存不足、商品下架、支付方式不可用。每条异常流程写清触发条件、处理动作和结束状态，并标注从主流程哪一步分叉。

系统级故障通常由非功能约束或运维预案承接，不必在用例规约里穷举。判断依据是：这个分支是否需要业务方决定处理方式，需要就写进规约。

用例规约写完由谁评审，评审通过后还能改吗？

编写者通常是需求分析或产品角色，评审者包括开发、测试和对口业务方，分别检查可实现性、可测性与业务规则准确性。评审按检查表逐项过，避免停留在“看起来差不多”。

通过后仍可修改，但要保留版本与修改原因。流程步骤编号尽量稳定，新增分支用字母后缀扩展而不重排既有编号，避免测试用例与评审记录失去对应。评审意见与变更记录随需求工作项留存，后续追溯时能看清每次调整的依据。

团队把用例规约放在文档里还是需求工作项里，怎么选？

看追溯需求。如果规约需要和需求、评审意见、变更记录保持对应，放在需求工作项下承载更便于留痕；如果规约以说明性文档为主、需要多人协同编辑，文档工具更顺手。

ONES 提供需求与测试相关的管理能力，用例库支持通过不同方式导入用例并以结构化方式组织管理，也提供自定义属性以适应不同场景的字段需求；用例规约可以作为需求工作项的交付内容承载，评审与变更在同一工作项下留痕。具体采用哪种承载方式，按团队的追溯要求和协作习惯决定。

用例规约的字段可以按项目裁剪吗？裁剪后要注意什么？

可以裁剪，必填性按“缺少后无法评审或无法设计测试”来判断。裁剪后要留下记录，说明去掉了哪些字段、原因是什么，避免后续接手的人误以为遗漏。

裁剪时优先保留参与者与目标、前置条件、主流程、异常流程、后置条件这几项，它们直接决定开发能否估算、测试能否设计场景。非功能约束和界面引用可按项目实际情况决定是否单列。