用例粒度没有唯一正确值，判断依据是“一个用例能否被独立执行、独立验证、独立交接”。过粗的典型信号是一个用例里塞进多个可独立完成的目标或大量分支；过细的典型信号是用例退化成界面点击步骤或单个字段校验，失去业务价值。本文按症状识别、判断依据、拆分、合并、验证五个环节展开，帮助你把评审未通过或自己觉得别扭的用例调整到可执行、可验证的粒度。
要点总览（TL;DR）
- 用例粒度的核心判断依据是目标单一、可独立执行、可独立验证、参与者与触发明确、异常分支可枚举，其中可独立执行与可独立验证最硬。
- 过粗的信号是一个用例包含多个可独立完成的目标或跨角色反复交接；过细的信号是用例退化为界面点击步骤或单个字段校验。
- 过粗用例按“标出多目标—按目标拆分—显化角色交接—整理扩展场景—补齐三要素”调整，拆到单个测试人员能独立设计并验证即停止。
- 过细用例按“按目标归组—合并—规则与校验上移—保留有价值异常分支—回看标题”调整，涉及不同参与者或不同后置状态的不宜强行合并。
- 调整后用未参与编写者复述和独立设计测试场景验证，并把粒度检查项写入评审清单、在需求评审阶段确认目标边界，减少反复。
用例粒度问题的典型症状与影响范围
先给手中的用例打标签，再决定往哪个方向调。过粗和过细的症状表现不同，调整方向相反，混在一起改容易越改越乱。下面这张对照表可以逐条比对。
| 观察维度 | 过粗的信号 | 过细的信号 |
|---|---|---|
| 用例标题 | 标题概括一个大流程，如“订单处理” | 标题是界面动作，如“点击保存按钮”“输入手机号后失焦” |
| 业务目标 | 一个用例里包含多个可独立完成的目标 | 一个用例只覆盖一个校验点或一次点击 |
| 参与者与交接 | 主成功场景跨多个角色来回交接 | 参与者单一且几乎没有业务交接 |
| 分支表达 | 分支条件写成大段文字，扩展场景难以枚举 | 步骤中混入按钮名称、页面名称、控件位置 |
| 步骤内容 | 步骤粒度跳跃，有的粗到一句话，有的细到字段 | 步骤是操作说明书，删掉界面描述后所剩无几 |
两类问题对下游工作的影响方式不同。过粗的用例让测试人员难以设计覆盖完整的测试场景，评审时各方对“这个用例到底验什么”理解不一致，开发估算时也无法判断工作量边界，交接给新成员时对方只能靠追问补全上下文。过细的用例则把评审拖进界面细节的讨论，测试设计变成逐条核对点击步骤，业务规则散落在各条碎片用例中难以追溯，需求变更时维护成本成倍增加。
混杂情况同样常见：一个用例前半段过粗地概括业务流程，后半段又细到某个字段的提示文案。遇到这种用例，先按业务目标把它切成几块，再分别判断每块偏粗还是偏细，不要试图一次性整体重写。
圈定调整范围时，建议按以下顺序收敛：优先处理评审未通过的用例清单，其次处理本迭代要进入测试设计的模块，最后处理交接给新成员的核心业务用例。范围一旦确定，记录在案，避免边改边扩导致调整工作失控。
判断粒度是否合适的依据与排除思路
核心判断标准有五条：目标单一性、可独立执行、可独立验证、参与者与触发明确、异常分支可枚举。五条同时满足，粒度基本合适；其中“可独立执行”和“可独立验证”是最硬的两条，其余三条用于辅助确认。
验证过粗有一个直接动作：尝试把这条用例拆成两个可独立交付的结果。如果拆分自然成立，两个结果各自有明确的完成标志，说明原用例确实过粗；如果拆出来的两半互相依赖、单独看都不完整，说明原粒度可以接受。验证过细也有一个直接动作：删掉所有界面描述，看用例还剩什么。如果剩下的仍是完整的业务目标、参与者和结果，说明细节只是步骤说明的一部分，用例本身粒度合适；如果删完只剩一个字段名或一次点击，这条用例就该合并或上移。
有些问题看起来像粒度问题，实际原因在别处，调整粒度解决不了：
- 需求本身未澄清：业务目标边界模糊，用例怎么写都显得粗。此时应先回到需求澄清，确认目标后再定粒度。
- 业务规则缺失：校验条件没有权威来源，编写者只能把猜测写进步骤，表现为过细。应先补齐规则说明。
- 术语不统一：同一对象在不同用例中叫法不同，评审时误判为覆盖不全或重复。应先统一术语表。
- 评审口径不一致：评审人各自按习惯判断粗细，没有共同标准。应先对齐评审检查项，再谈调整。
把判断当假设，用证据收口。“这条用例过粗”只是假设，验证方式有两种：一是做拆分测试，看拆出的结果是否各自可独立交付；二是请一位未参与编写的同事按用例复述目标与步骤，如果对方复述出的目标与原标题不一致，或需要反复追问才能说清主成功场景，假设成立。两种验证都通过，再进入调整步骤。
过粗用例的调整步骤
过粗用例的调整方向是拆，按以下顺序操作。
- 标出多个业务目标：通读用例，把主成功场景中每一个可独立完成、有独立完成标志的结果圈出来。圈出的数量就是潜在用例数量。
- 按目标拆分为独立用例：每个目标对应一条用例，标题直接表达该目标。拆分后原用例的主成功场景被分配到各条新用例中，重复部分提取为共同前置条件。
- 显化跨角色交接：原用例中角色来回交接的位置，改为参与者切换的明确步骤，或拆成由不同参与者主导的独立用例，并在用例之间注明触发关系。
- 整理分支：把大段分支条件整理为主成功场景加可枚举的扩展场景。每条扩展场景写清触发条件、处理结果和结束状态，无法枚举的分支说明规则本身还没定清楚，回到需求澄清。
- 补齐三要素：为每条拆分后的用例补齐前置条件、触发事件与后置结果，确保单独拿出来也能被执行和验证。
拆分要有停止点。当一条用例已经能被单个测试人员独立设计测试场景并完成验证，不再需要追问“这一步属于哪个目标”，就停止继续拆。继续拆下去会滑向过细，把本可放在步骤说明里的内容变成新用例。
过细用例的调整步骤
过细用例的调整方向是合并与上移，按以下顺序操作。
- 按业务目标归组：把同一业务目标下的碎片用例找出来，它们通常标题相近、参与者相同、后置状态连续。归组后确认这些碎片合起来能构成一个完整目标。
- 合并为一个用例：以业务目标为标题建立合并后的用例，原碎片用例中的界面操作下沉为步骤说明，保留必要的操作顺序，删除重复的进入路径描述。
- 上移规则与校验：字段级校验、格式要求、业务规则从步骤中抽出，写入前置条件、补充约束或独立的规则说明，用例正文只引用规则编号或名称。
- 保留有价值的异常分支：有独立业务后果的异常分支保留为扩展场景，纯界面层面的重复步骤删除。
- 回看标题：调整完成后检查每条用例标题是否表达业务目标。标题仍是界面动作的，说明合并没做到位。
合并有风险边界，以下情况不宜强行合并：涉及不同参与者的用例，合并后参与者切换会掩盖职责划分；后置状态不同的用例，合并后无法判断执行完成标志；分属不同业务规则的校验，合并后规则追溯变难。遇到这些情况，保持独立用例，通过共同前置条件或规则说明建立关联即可。
调整后的验证与复发预防
调整是否有效，用两个动作验证。第一，请未参与编写的测试或开发人员按用例复述目标与步骤，复述准确、无需追问即通过；复述中出现“这条用例到底验什么”的疑问，说明目标仍不单一。第二，按用例独立设计一轮测试场景，能覆盖主成功场景和已枚举的扩展场景即通过；设计过程中被迫补充大量隐含前提，说明前置条件或规则上移不完整。
评审环节设置固定检查点，把粒度判断标准变成可勾选的检查项：
- 标题表达业务目标，不包含界面动作或字段名称；
- 参与者与触发事件明确，主成功场景中角色交接位置清晰；
- 主成功场景可独立走通，不依赖其他用例的中间状态；
- 扩展场景可枚举，每条有触发条件与结束状态；
- 界面细节位于步骤说明，业务规则位于前置条件或补充约束。
预防复发要从需求评审阶段做起。需求评审时同步确认每个业务目标的边界和完成标志，用例编写就有了稳定的拆分依据，后续反复拆分合并的情况会明显减少。用例进入评审和交接时，把目标、前置条件、扩展场景作为评审记录的一部分留存，调整历史可追溯。
这类检查项和状态流转如果放在需求管理工具中承载，评审意见、调整记录和用例状态可以关联在同一工作项下。以 ONES 为例，可以把粒度检查项配置为用例评审的固定字段或检查清单，拆分与合并后的用例通过关联关系保留与原需求的追溯，评审未通过时状态与意见同步可见，交接时新成员从工作项直接看到目标、规则和评审结论，减少口头补全上下文的情况。工具承载的是评审与交接的管理动作，粒度判断本身仍按前文的五条标准执行。
复发信号需要提前约定：同一用例再次出现多目标，或同一目标下再次散出多条碎片用例，说明判断标准在执行中走样。此时回到判断依据一节，重新做拆分测试或复述验证，确认是粒度问题还是需求、规则、术语层面的原因，再决定调整方向。把每次复发的原因记录在评审清单旁，积累几轮后就能看出团队最容易在哪个环节失守，针对性收紧检查项。
常见问题
用例拆分到什么程度就该停？
停止点可以这样判断：一条用例已经能被单个测试人员独立设计测试场景并完成验证，执行过程中不需要追问“这一步属于哪个目标”，就可以停止拆分。继续拆下去，原本可以放在步骤说明里的内容会被拆成新用例，粒度从过粗滑向过细。拆分前先确认业务目标边界，目标本身没定清楚时，拆出来的用例仍会显得含糊。
几条碎片用例看起来目标相同，但参与者不同，能合并吗？
不建议强行合并。参与者不同的用例合并后，角色切换会被压进同一条主成功场景，职责划分变得模糊，执行时也难以判断由谁完成。更稳妥的做法是保持独立用例，通过共同前置条件或触发关系建立关联，并在用例之间注明交接点。后置状态不同、分属不同业务规则的碎片用例同理，合并会削弱完成标志和规则追溯。
评审时大家对粗细判断不一致，怎么统一口径？
先把判断标准落成可勾选的检查项，再讨论具体用例。检查项至少覆盖：标题表达业务目标、参与者与触发明确、主成功场景可独立走通、扩展场景可枚举、界面细节位于步骤说明而业务规则位于前置条件或补充约束。评审时逐条对照，分歧会从“感觉太粗”收敛到具体哪一条不满足。若分歧集中在业务目标本身，说明问题在需求澄清，应先确认目标边界再定粒度。
调整后怎么确认真的改好了？
用两个动作验证。一是请未参与编写的测试或开发人员按用例复述目标与步骤，复述准确且无需追问即通过；出现“这条用例到底验什么”的疑问，说明目标仍不单一。二是按用例独立设计一轮测试场景，能覆盖主成功场景和已枚举的扩展场景即通过；设计时被迫补充大量隐含前提，说明前置条件或规则上移不完整。两项都通过，再进入评审和交接。
用例反复出现过粗或过细，问题出在哪？
先区分是粒度问题还是上游原因。需求目标边界模糊、业务规则缺失、术语不统一、评审口径不一致，都会表现为用例偏粗或偏细，单靠调整用例解决不了。排除这些原因后，把粒度检查项固定进评审清单，并在需求评审阶段同步确认每个业务目标的边界和完成标志。同一用例再次出现多目标或同一目标下再次散出碎片用例时，回到判断标准重新做拆分测试或复述验证，并记录复发原因，几轮之后能看出团队最容易在哪个环节失守。
