用例粒度以“一个参与者为达成一个可观察目标、完成一次有业务意义的交互闭环”为基准。主成功场景能独立走通，前置条件与后置结果可验证，异常分支在用例内部展开。判断过粗，看是否混入多个目标或多个参与者；判断过细，看是否把界面步骤、单个校验或内部处理拆成了用例。本文围绕这套基准，给出识别信号、调整步骤、角色分工与评审清单。
要点总览（TL;DR）
- 用例粒度以“一个参与者为达成一个可观察目标、完成一次有业务意义的交互闭环”为基准，主成功场景能独立走通、前置与后置可验证。
- 过粗的信号：一个用例混入多个参与者或并列目标、主成功场景分支混杂、前置条件写成整段流程、后置结果无法核对。
- 过细的信号：点击跳转、单个字段校验、系统内部处理被拆成独立用例，用例数量随界面调整膨胀。
- 调整顺序先合并再拆分，最后统一前置条件、触发事件、主成功场景、异常分支与后置结果五个字段，并回查引用关系。
- 用评审清单逐项核对目标唯一性、场景可走通、异常在篇内展开、无重复条目，出现阻断项不进入基线。
先定粒度基准：一个用例对应一个可观察目标
讨论粒度之前，团队需要先有一把统一的尺子，否则“太粗”“太细”只是个人感觉。可操作的基准是：一个用例对应一个参与者为达成一个可观察目标而完成的一次交互闭环。参与者发起动作，系统给出可观察的响应，目标达成或明确失败，这次交互即告结束。
这个基准包含三条规则，可以直接写进团队的用例编写规范。
- 目标规则：用例名称应能表达“参与者做什么、得到什么结果”，例如“提交报销申请”“查询订单物流”。名称中出现“和”“以及”连接两个动作时，通常意味着混入了多个目标。
- 边界规则：主成功场景从触发事件开始，到后置结果成立为止，中间步骤应能独立走通。前置条件描述开始前已成立的事实，后置结果描述结束后可验证的状态，两者都不应写成一段业务流程。
- 异常归属规则：同一目标下的校验失败、权限不足、数据缺失等异常，作为该用例的异常分支展开，不单独成篇。只有当异常处理本身构成另一个参与者目标时，才考虑独立用例。
粒度基准还需要与需求层级对应起来。业务目标层面描述组织要达成什么，通常体现为业务流程或业务用例；用户目标层面描述某个角色用系统完成一件完整的事，这是用例的主体层级；子功能层面描述系统提供的局部能力，适合写在用例步骤或补充说明中，不宜单独提升为用例。把三层混在同一层级书写，是用例粒度失控的常见来源。
识别过粗：多目标、多参与者与分支混杂的信号
过粗的用例看起来覆盖面广，实际难以评审、难以测试，变更时也难以定位影响范围。以下信号可以帮助快速识别。
- 多个参与者：一个用例中先后出现申请人、审批人、财务人员各自的操作，且各自都有独立目标。这说明用例把一条跨角色的流程压进了一篇。
- 多个可独立达成的目标：用例名称或主成功场景中出现“创建并审批”“录入并导出”这类并列动作，任一动作单独完成都有业务意义。
- 分支混杂：主成功场景步骤中出现“或者”“根据情况选择”“若为某类型则……”等表述，且不同分支走向不同的业务结果。
- 前置条件写成流程：前置条件中出现“申请人已提交、主管已审批、财务已复核”这类连续动作描述，说明用例起点被推到了流程上游。
- 后置结果无法验证：后置结果写成“流程顺利完成”“相关人员知晓”这类无法核对的状态，评审时无法判断用例是否真正结束。
过粗带来的代价是具体的：评审时各方对范围理解不一致，讨论容易跑题；测试人员难以从一篇用例推导出完整的测试场景，只能自行拆分；需求变更时，一处修改牵动整篇，影响分析成本上升。识别出上述信号后，拆分方向也随之明确——按参与者目标拆、按业务结果拆、把流程性前置条件还原为可验证的事实状态。
识别过细：界面步骤、单点校验与内部处理被拆成用例
过细的用例把操作步骤当成了目标。典型表现包括：把“点击提交按钮”“跳转至详情页”“校验手机号格式”写成独立用例；把系统内部的定时任务、消息推送、数据同步当作参与者目标；用例名称是界面元素或字段名，而非业务动作。
这类用例单篇看似清晰，整体代价却不小。用例数量随界面调整而膨胀，一次页面改版可能作废多篇用例；评审时大量时间花在确认步骤细节上，目标层面的遗漏反而无人发现；维护人员难以判断哪些用例可以随版本下线。更隐蔽的问题是，过细用例让读者误以为需求已经描述完整，而真正的业务规则和异常处理仍散落在别处。
需要划清一条边界：用例内容写得对不对，属于需求分析与澄清的工作；本文处理的是表达粒度，即同样的内容应该放在哪一层。一个字段校验规则写错了，是内容问题；把它单独写成一篇用例，是粒度问题。两者可以同时存在，但修订动作不同，评审时也应分开记录。
合并原则与拆分原则对称：同一参与者、同一目标下的细碎条目，归并为一个主成功场景，界面步骤和字段校验作为场景中的步骤或补充约束保留；系统内部处理不设参与者，写入用例的补充说明或设计约束，不单独成篇。
调整操作步骤：合并、拆分与字段统一
识别出问题后，按以下四步调整。每一步都说明输入、动作、输出与完成标志，便于在评审会上直接执行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 按目标合并 | 同一参与者、同一目标下的多篇细碎用例 | 保留一篇作为主用例，其余内容并入主成功场景步骤或补充约束，删除独立条目 | 合并后的用例及被合并条目清单 | 合并后主成功场景可独立走通，无遗留孤立条目 |
| 2. 按目标拆分 | 含多个目标或多参与者的过粗用例 | 为每个可观察目标建立独立用例，明确各自参与者、触发事件与结果 | 拆分后的用例集合及原用例的处置说明 | 每篇用例只有一个参与者目标，名称不含并列动作 |
| 3. 字段统一 | 拆分或合并后的用例草稿 | 统一前置条件、触发事件、主成功场景、异常分支、后置结果五个字段的写法与详略 | 字段完整的用例正文 | 前置条件为可验证事实，后置结果可核对，异常分支在篇内展开 |
| 4. 引用回查 | 调整后的用例集合 | 检查与其他用例、需求条目、测试用例的引用关系，处理重复与失效链接 | 更新后的引用关系与重复条目处理记录 | 无指向已删除用例的引用，无内容重复的用例 |
调整顺序建议先合并再拆分。先合并可以消除细碎条目带来的干扰，让多目标问题暴露得更清楚；随后拆分时，参与者与目标边界更容易判断。字段统一放在结构调整之后，避免在错误的边界上反复打磨文字。
当用例作为需求工作项在工具中管理时，调整动作需要与条目状态同步。以ONES为例，合并或拆分后的需求条目可以在系统中更新描述、关联关系与状态，评审意见与修改记录保留在同一工作项下，便于后续追溯哪次调整改变了粒度。这里只涉及条目承载与记录，粒度判断规则仍以本文基准为准。
角色分工与交付物：谁定粒度、谁评审、谁维护
粒度把控如果只靠个人经验，人员变动后标准就会漂移。把职责和交接物固定下来，粒度才具备可重复性。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 需求分析人员 | 识别参与者目标，划分用例边界，按基准编写或调整用例 | 用例正文、拆分合并说明 |
| 评审角色（业务代表、资深需求人员） | 按粒度基准核对过粗过细信号，确认目标与边界 | 评审意见、粒度问题记录 |
| 开发人员 | 从可实现角度反馈用例是否覆盖关键处理与约束 | 实现相关疑问与补充约束建议 |
| 测试人员 | 从可验证角度反馈主成功场景与异常分支是否足以推导测试场景 | 可测试性问题清单 |
| 用例基线维护人 | 维护用例基线，变更时复核粒度是否被破坏 | 基线版本记录、变更复核结论 |
交接的关键在于评审输入。评审前，需求分析人员应提交用例正文与本次调整说明，标明哪些条目被合并、哪些被拆分及理由；评审中，评审角色对照识别信号逐条核对，把结论写成可跟踪的问题项；评审后，维护人确认问题关闭并将用例纳入基线。开发与测试的反馈不必等到正式评审，在用例草稿阶段提出，修改成本更低。
示例：一个过粗用例的拆分与一个过细用例的合并
以下示例为演示情景，用于说明判断依据，不代表特定项目。
过粗示例。原用例名为“处理报销”，参与者写“员工、主管、财务”，主成功场景依次描述员工填写单据、主管审批、财务付款。拆分依据是三个角色各自有独立可观察目标：员工的目标是提交报销申请，主管的目标是审批报销申请，财务的目标是完成报销付款。拆分后得到三篇用例，各自明确参与者、触发事件与后置结果；原用例中跨角色的流转关系，改为在补充说明中描述前置依赖，例如“审批用例的前置条件为报销申请已提交且状态为待审批”。
过细示例。原有用例“点击提交按钮”“校验发票金额”“跳转审批页面”三篇，参与者均为员工。合并依据是三者同属“提交报销申请”这一目标，点击与跳转是界面步骤，金额校验是该目标下的异常分支。合并后得到一篇用例：主成功场景描述员工填写并提交申请、系统校验通过并生成待审批记录；金额校验失败作为异常分支在篇内展开；界面跳转写入步骤说明，不单独立项。
| 对比项 | 调整前 | 调整后 |
|---|---|---|
| 用例数量 | 过粗示例1篇；过细示例3篇 | 过粗示例拆为3篇；过细示例合并为1篇 |
| 参与者 | 过粗示例含3个角色；过细示例均为员工 | 每篇一个主要参与者 |
| 后置结果 | 过粗示例为“流程完成”，不可核对 | 各篇后置结果为可核对的状态，如“生成待审批记录” |
| 异常处理 | 过粗示例未展开；过细示例独立成篇 | 在目标用例内作为异常分支展开 |
示例的适用边界需要说明：拆分与合并的结论依赖业务目标本身的划分。如果组织把“审批”定义为独立业务能力，拆成独立用例是合理的；如果审批只是提交动作的附带环节，则可能保留在同一用例的异常或扩展流程中。判断时以参与者的可观察目标和业务意义为准，不以条目数量多少为准。
完成检查：粒度评审清单与通过标准
调整完成后，用以下清单逐项核对。清单可作为评审记录的一部分，也可作为用例入库前的自检项。
- 每个用例是否只有一个可观察目标，且名称中不含并列动作？
- 参与者是否明确，是否存在多个角色在同一用例中各自完成独立目标？
- 主成功场景是否可从触发事件独立走通，不依赖其他用例的中间状态？
- 前置条件是否为可验证的事实，而非一段业务流程？
- 后置结果是否可核对，能否据此判断用例成功结束？
- 异常分支是否在用例内展开，是否存在应合并回本篇的独立异常用例？
- 是否存在与其他用例内容重复、可合并的细碎条目？
- 界面步骤、字段校验、内部处理是否被误设为独立用例？
- 调整后的用例是否已回查引用关系，无失效链接？
通过标准是：上述条目全部核对为“是”，且评审角色对目标与边界无异议。阻断项包括：存在多个参与者目标未拆分、主成功场景无法独立走通、后置结果不可验证、存在内容重复的用例未处理。出现任一阻断项，用例不进入基线，修改后重新核对。粒度评审通过后，用例即可作为后续设计与测试推导的稳定输入。
常见问题
用例粒度和需求层级怎么对应，业务用例和用户用例要不要都写？
粒度基准需要与需求层级对齐。业务目标层面描述组织要达成什么，通常体现为业务流程或业务用例；用户目标层面描述某个角色用系统完成一件完整的事，这是用例的主体层级；子功能层面描述系统提供的局部能力，适合写在用例步骤或补充说明中。三层混在同一层级书写，是粒度失控的常见来源。团队可以只维护用户目标层用例，业务目标用流程说明承载，子功能不单独提升为用例，关键是同一份用例集保持在同一层级。
拆分和合并的先后顺序会影响结果吗？
会。建议先合并再拆分：先合并可以消除细碎条目带来的干扰，让多目标问题暴露得更清楚；随后拆分时，参与者与目标边界更容易判断。字段统一放在结构调整之后，避免在错误的边界上反复打磨文字。如果团队现有用例以过粗为主，也可以先拆分再合并，但两轮之间要重新核对目标，防止拆分后产生新的细碎条目。
同一个异常处理，什么时候作为异常分支写在用例内，什么时候独立成用例？
判断依据是异常处理本身是否构成另一个参与者的可观察目标。同一目标下的校验失败、权限不足、数据缺失，作为该用例的异常分支展开，不单独成篇。如果异常处理需要另一个角色发起独立交互并产生独立的业务结果，例如审批不通过后由申请人重新提交并再次进入审批，这时可以拆成独立用例，并在原用例中说明前置依赖。拆分后要回查两篇用例的引用关系，避免状态描述互相矛盾。
用例作为需求工作项在工具里管理时，调整粒度要注意什么？
合并或拆分后，需求条目的描述、关联关系与状态需要同步更新，评审意见与修改记录保留在同一工作项下，便于追溯哪次调整改变了粒度。以ONES为例，可以在系统中更新需求条目描述、关联关系与状态，把评审意见和修改记录留在同一工作项下。工具承载的是条目与记录，粒度判断规则仍以团队约定的基准为准，不因工具字段齐全就默认粒度合格。
粒度评审通过后，后续需求变更时还要重新评审粒度吗？
需要复核，但不必每次全量重评。变更涉及新增参与者、新增并列目标或调整前置条件时，应重新核对粒度；仅修改字段校验规则、界面文案或补充异常说明，通常不影响粒度，按普通变更流程处理即可。用例基线维护人在变更复核时确认粒度是否被破坏，把结论记入变更记录，这样粒度标准在多次迭代后仍能保持一致。
