用例写不清，往往不是流程没想明白，而是参与者与前置条件两栏没写对。参与者要写成“角色名称＋在系统中的身份或权限＋与系统的交互目标”，只列系统外部的人或其他系统；前置条件要写成用例启动前已经成立、且不由本用例动作产生的状态，逐条可判定。本文按用例规约的字段顺序，给出这两栏的写法、与主流程和异常流程的衔接方式，以及一份可直接对照的完整示例和评审检查清单。
要点总览（TL;DR）
- 参与者只写系统外部的人、角色或其他系统，按“角色名称＋身份或权限＋交互目标”描述，界面、数据库和内部服务不进入参与者栏。
- 前置条件写用例启动前已经成立、且不由本用例动作产生的状态，按业务、数据、权限、时间四类组织，每条都要能回答“由谁、何时、如何确认”。
- 主流程从触发事件开始，写成参与者动作与系统响应的交替；异常流程标明从主流程哪一步分叉，覆盖前置条件失效、分支失败和外部系统异常三类来源。
- 后置条件与前置条件状态呼应，成功与失败路径分别描述，读者能从前置条件一路读到后置条件，中间不出现无来源的状态。
- 评审时按检查清单逐项核对，重点看参与者边界、前置条件可判定性、异常流程覆盖度，以及测试人员能否仅凭用例设计出正向与异常测试。
用例规约包含哪些要素
用例规约是一份结构化文档，字段之间有明显依赖：参与者决定目标，目标决定主流程，前置条件约束流程起点，后置条件描述流程结束后的状态。填写顺序建议按“编号与名称→参与者→目标→前置条件→触发事件→主流程→异常流程→后置条件→业务规则”推进，因为后面的字段都要引用前面的结论。
下表给出一份常用字段框架。必填项是评审和测试设计的最低要求，按需补充项由团队根据业务复杂度约定，不必每份用例都写满。
| 字段名 | 填写内容 | 是否必填 | 示例 |
|---|---|---|---|
| 用例编号 | 团队内唯一、可检索的标识 | 必填 | UC-ORDER-012 |
| 用例名称 | 动宾结构，体现参与者要达成的结果 | 必填 | 提交订单并完成在线支付 |
| 参与者 | 系统外部的角色或其他系统，注明身份或权限 | 必填 | 已登录的注册买家 |
| 目标 | 参与者通过本用例获得的业务价值 | 必填 | 完成付款并获得订单支付凭证 |
| 前置条件 | 用例启动前已成立、不由本用例产生的状态 | 必填 | 购物车中存在至少一件有库存的商品 |
| 触发事件 | 启动主流程的那个动作或外部事件 | 必填 | 买家在结算页点击“提交订单” |
| 主流程 | 参与者动作与系统响应交替的步骤序列 | 必填 | 见第4节编号示例 |
| 异常流程 | 前置条件失效、分支失败或外部异常时的处理路径 | 必填 | 支付超时后订单转为待支付 |
| 后置条件 | 用例成功或失败结束后系统应处的状态 | 必填 | 订单状态为“已支付”，生成支付流水 |
| 业务规则 | 约束流程判断的规则条款，可被多条用例引用 | 按需 | 单笔订单金额超过5000元需二次验证 |
| 非功能约束 | 响应时间、并发量、合规要求等 | 按需 | 支付结果页3秒内返回 |
字段之间存在引用关系：异常流程要指回主流程的步骤编号，后置条件要与前置条件形成前后呼应，业务规则被主流程或异常流程的判断点引用。填写时先保证必填字段完整，再补充按需字段，避免在字段不全的情况下先写流程细节。
参与者怎么描述：角色、边界与写法
参与者的判定标准只有一条：它是否位于系统边界之外，并通过本用例与系统交互。人、岗位角色、外部系统都算参与者；界面、数据库、内部服务、消息队列属于系统内部构件，写进参与者会让用例边界失真，后续的接口设计和测试范围也会跟着错位。
推荐句式是“角色名称＋在系统中的身份或权限＋与系统的交互目标”，例如“已登录的注册买家，通过结算页提交订单并完成支付”。角色名称用业务语言，身份或权限说明该角色在本用例中的资格，交互目标与用例目标保持一致。具体人名、工号、某位同事的姓名不进入参与者栏，人员变动不应导致用例失效。
一个用例的主要参与者通常只有一个，即发起并推动用例达成目标的那一方。次要参与者单独列出，例如“支付网关（外部系统）”“仓库管理员（接收发货通知）”，并注明它在流程中承担的动作。参与者与目标要能对上：如果写了两个主要参与者，先确认是否其实是两条用例。
| 错误写法 | 问题 | 修改后 |
|---|---|---|
| 张三 | 写具体人名，人员调整后用例失效 | 已登录的注册买家 |
| 订单管理页面 | 界面属于系统内部，不是参与者 | 运营专员（具备订单查询权限） |
| 订单数据库 | 内部存储构件，不通过用例与系统交互 | 不列为参与者，在数据状态中描述 |
| 订单服务、库存服务 | 内部模块，属于实现设计 | 库存系统（外部系统，提供可售库存查询） |
| 用户、管理员、财务 | 角色堆叠，目标不唯一 | 拆为三条用例，各自写明身份与目标 |
当参与者是外部系统时，同样按角色描述，并说明它提供或接收什么。例如“发票服务平台（外部系统，接收开票请求并返回发票号）”，这样在异常流程中写“发票服务平台返回失败”时，读者能立刻定位到边界上的交互点。
前置条件怎么描述：可判定、不重复、不越界
前置条件的定义是：用例启动那一刻必须已经成立、且不由本用例的任何动作产生的状态。它回答“什么情况下这条用例才有资格开始”，不回答“用户先做什么”。把“用户已登录”写成前置条件可以，把“用户输入账号密码并点击登录”写进去就越界了，那是另一条用例的流程。
按类别组织前置条件，便于查漏：
- 业务状态：订单处于“待支付”状态；合同已完成双方签署。
- 数据状态：购物车中存在至少一件有库存的商品；客户档案中已维护开票信息。
- 权限状态：操作人具备“订单退款”权限；当前账号属于该门店的数据范围。
- 时间或触发条件：处于当月账单周期内；审批单已到达财务复核节点。
每条前置条件写成可验证的陈述句，评审时能回答“怎么确认它成立”。“系统正常”“数据完整”“网络通畅”这类表述无法判定，应改写为具体状态。下表给出改写对照。
| 模糊表述 | 问题 | 可判定表述 |
|---|---|---|
| 系统正常运行 | 无法验证，且属于环境假设 | 支付服务可用，且订单服务已返回订单详情 |
| 数据完整 | 未说明哪些数据、完整指什么 | 订单包含至少一条商品明细，且收货地址已填写 |
| 用户有权限 | 权限对象和范围不明 | 操作人拥有该订单所属门店的退款审批权限 |
| 库存充足 | 未说明判定口径 | 商品可售库存数量大于等于下单数量 |
| 已完成支付 | 若由本用例产生，则不应写在前置条件 | 移入后置条件，或改为“存在一笔已支付的关联订单” |
前置条件要与触发事件、后置条件区分开：触发事件是启动主流程的那个动作，前置条件是动作发生前已成立的状态，后置条件是用例结束后的结果。数量上控制在三到六条，只保留真正影响流程能否开始的条件；环境类假设统一写在文档头部，不逐条重复。评审时逐条追问“由谁、在什么时点、用什么方式确认”，确认不了的条目要么细化，要么删除。
主流程与异常流程如何衔接前置条件
主流程从触发事件开始，第一步就是参与者发起动作，随后是系统响应，如此交替推进。前置条件不写成步骤，但它决定了主流程的起点是否成立：如果前置条件不满足，流程根本不应进入第1步，而应走对应的异常分支或直接拒绝。
异常流程有三个常见来源：前置条件在实际运行时失效、主流程中的分支判断失败、外部系统或环境异常。每条异常流程要标明它从主流程的哪一步分叉，处理完后回到哪一步或在哪里终止。编号上建议采用“主流程步骤号＋分支字母”的方式，例如主流程第3步的分支写作3a、3b，读者可以按编号回溯。
| 编号 | 参与者动作 | 系统响应 |
|---|---|---|
| 1 | 买家在结算页点击“提交订单” | 校验前置条件，创建订单，状态置为“待支付” |
| 2 | 买家选择支付方式并确认支付 | 向支付网关发起支付请求 |
| 3 | — | 接收支付结果，更新订单状态并生成支付流水 |
| 3a | — | 支付网关返回超时：订单保持“待支付”，提示买家稍后查询 |
| 3b | — | 支付网关返回失败：订单保持“待支付”，记录失败原因 |
| 1a | — | 提交时库存已被占用：提示库存不足，流程终止 |
后置条件与前置条件要形成呼应：成功路径的后置条件通常把前置条件中的状态推进一格，例如前置“订单处于待支付”，后置“订单状态为已支付并生成支付流水”；失败路径的后置条件则说明状态保持或回退到什么程度。这样一份用例在评审时，读者能从前置条件一路读到后置条件，中间不出现无来源的状态。
完整示例：一条用例从参与者到异常流程
下面是一条填写完整的用例，场景为演示用途，团队可按自身业务替换字段内容。
| 字段 | 内容 |
|---|---|
| 用例编号 | UC-ORDER-012 |
| 用例名称 | 提交订单并完成在线支付 |
| 参与者 | 主要：已登录的注册买家，在结算页提交订单并完成支付。次要：支付网关（外部系统，受理支付请求并返回结果） |
| 目标 | 买家完成付款，获得可查询的支付凭证 |
| 前置条件 | 1. 买家已登录且账号状态正常；2. 购物车中存在至少一件可售库存大于等于下单数量的商品；3. 收货地址已填写且在该配送范围内；4. 订单金额未超过免二次验证阈值，或已完成二次验证 |
| 触发事件 | 买家在结算页点击“提交订单” |
| 主流程 | 1. 买家点击提交订单，系统校验前置条件并创建订单，状态为“待支付”；2. 买家选择支付方式并确认支付，系统向支付网关发起请求；3. 系统接收支付成功结果，将订单置为“已支付”并生成支付流水 |
| 异常流程 | 1a. 提交时库存不足：提示库存不足，流程终止；2a. 订单金额超过阈值且未完成二次验证：跳转验证，验证通过后回到第2步；3a. 支付网关返回超时：订单保持“待支付”，提示稍后查询；3b. 支付网关返回失败：订单保持“待支付”，记录失败原因并允许重新支付 |
| 后置条件 | 成功：订单状态为“已支付”，存在对应支付流水。失败：订单保持“待支付”，不生成支付流水 |
| 业务规则 | 单笔订单金额超过5000元需二次验证；支付结果以支付网关返回为准 |
逐项说明写法依据：参与者只保留买家与支付网关两个外部对象，界面和服务名未进入该栏；前置条件四条分别对应权限、数据、业务和规则状态，每条都能通过查询订单或账号数据确认；触发事件是单一动作，与前置条件不重叠；异常流程用1a、2a、3a、3b标明分叉点，其中1a对应前置条件2在实际提交时失效的情形；后置条件按成功与失败分别描述，与前置条件中的“待支付”状态衔接。
评审与完成检查
用例描述是否合格，可以用下面这份清单逐项核对。建议由需求提出人、用例编写人和测试设计人共同评审，检查结果记录在用例文档的评审意见中，未通过项回到对应字段修改后复审。
- 参与者栏只包含系统外部的人、角色或其他系统，未出现界面、数据库、内部服务。
- 参与者按角色描述，未写具体人名；身份或权限与用例目标对应。
- 主要参与者只有一个，次要参与者已单独列出并注明其动作。
- 每条前置条件都能回答“由谁、何时、如何确认”，无“系统正常”“数据完整”类表述。
- 前置条件中不含操作步骤，也不含本用例动作产生的结果。
- 触发事件是单一动作，与前置条件、主流程第1步不重复。
- 主流程步骤为参与者动作与系统响应的交替，编号连续。
- 异常流程覆盖前置条件失效、分支判断失败、外部系统异常三类来源，并标明分叉编号。
- 后置条件与前置条件状态呼应，成功与失败路径分别描述。
- 测试人员能仅凭本用例设计出正向与异常测试用例，无需额外口头补充。
当用例数量增多、需要跨版本复用时，把参与者、前置条件作为结构化字段管理会比散落在文档正文中更便于检索和比对。ONES 测试管理解决方案支持将用例导入用例库并以结构化方式组织管理，用例库提供自定义属性，可用来承载参与者、前置条件这类字段；用例与需求、缺陷在同一平台关联时，评审意见和修改记录也能随工作项留存。具体字段配置与可用范围以实际产品版本为准。
常见问题
参与者是外部系统时，前置条件里还要写它的可用状态吗？
要写，但只写与本用例启动相关的状态，不写它的内部实现。例如“支付网关可受理支付请求”可以作为前置条件，因为主流程第2步依赖它；至于网关内部如何路由、超时阈值多少，属于实现细节，放在非功能约束或接口约定中。若该外部系统的可用性只在流程中途才被检验，更适合写成异常流程的分支，而不是前置条件。
前置条件写多了会不会限制用例复用？
前置条件越多，用例适用的场景越窄，复用价值越低。控制方法有两条：一是只保留真正影响流程能否开始的条件，环境类假设统一写在文档头部；二是把只在部分场景出现的条件下沉为异常流程分支。例如“库存充足”可以保留为前置条件，而“库存刚好在提交时被占用”属于运行时变化，写成异常分支更合适。三到六条是常见区间，超出时先检查是否混入了操作步骤。
一条用例出现两个主要参与者，应该拆开还是合并？
先看两个参与者是否各自推动一个独立目标。如果双方的目标不同、成功标准不同，拆成两条用例，各自写明身份与目标，再通过业务规则或关联关系衔接。如果一方只是被动接收通知或提供数据，把它列为次要参与者并注明其动作即可，不必拆分。合并成一条用例时，主流程会变成两条目标线交织，评审和测试设计都难以判断覆盖是否完整。
前置条件在评审时确认不了，怎么处理？
确认不了通常有两种原因：条件本身模糊，或者缺少确认手段。前者改写为具体状态，例如把“数据完整”改成“订单包含至少一条商品明细且收货地址已填写”；后者说明该条件在当前阶段无法验证，应降级为假设写入文档头部，或补充数据查询、权限配置等确认方式。评审记录中保留未确认项和责任人，避免带着模糊条件进入测试设计。
用例数量多时，参与者和前置条件放在文档正文还是结构化字段里管理？
取决于复用和检索需求。用例需要跨版本比对、按参与者筛选或统计前置条件分布时，结构化字段更合适。ONES 测试管理解决方案支持将用例导入用例库并以结构化方式组织管理，用例库提供自定义属性，可用来承载参与者、前置条件这类字段；用例与需求、缺陷在同一平台关联时，评审意见和修改记录也能随工作项留存。具体字段配置与可用范围以实际产品版本为准。
