用例模型评审时，团队常会陷入“这一步算不算一个用例”的反复争论：有的用例把多个角色、多个目标混在一条主成功场景里，有的则把同一目标的界面操作拆成十几个独立用例。本文从评审现场可观察的症状入手，给出判断用例过粗、过细或混合问题的线索，再按“参与者—目标”这一基本单位排查原因、执行归并或拆分，最后提供调整后的验证检查项与复发预防措施。
要点总览（TL;DR）
- 判断粒度异常先看用例清单与业务目标清单能否对上：过粗表现为一个用例覆盖多个业务结果，过细表现为同一目标被拆成多条用例、离开其他用例无法理解。
- 粒度问题的常见原因包括参与者识别不清、把流程步骤或界面操作当成用例、用包含扩展关系替代目标分解、缺少命名与前置后置条件约定，需用参与者清单、业务目标清单和用例清单交叉验证。
- 调整以“一个参与者、一个可观察目标、一次完整交互”为边界：过粗按独立业务结果拆分，过细按同一目标归并并把分支写入扩展场景，同时统一命名与前置后置条件。
- 调整后按独立理解、独立验收、目标一一对应、追溯完整、命名一致五项检查确认效果，并把粒度约定写入建模规范、纳入用例评审固定环节。
- 调整前备份初版模型并保留变更记录，拆分到写不出独立后置条件或归并后出现多个可观察结果时，应回退到上一步重新判断。
粒度问题在评审中有哪些典型症状
判断粒度是否异常，先看用例清单与业务目标清单能否对得上。评审现场的症状通常集中在数量关系、单条描述长度、重复程度和争论焦点四个方面，可以对照下表逐项核对。
| 观察维度 | 过粗的表现 | 过细的表现 |
|---|---|---|
| 用例数量与业务目标数量 | 用例数明显少于参与者目标数，一个用例覆盖多个业务结果 | 用例数远多于业务目标数，同一目标下出现多条用例 |
| 单条用例描述 | 主成功场景步骤跨多个角色目标，步骤数多且分支嵌套 | 单条用例只有两三个步骤，离开其他用例就无法理解 |
| 用例之间的关系 | 大量使用包含、扩展关系承载本应独立的目标 | 用例之间互相引用频繁，前置条件依赖另一条用例的完成 |
| 评审争论焦点 | 反复讨论“这条用例到底交付了什么结果” | 反复讨论“这一步算不算一个用例” |
混合问题也很常见：一部分用例过粗，另一部分过细，整体数量看起来正常，但评审时两类争论交替出现。遇到这种情况，不要用总数判断，而应逐条标注每个用例对应的参与者目标，再统计哪些目标被合并、哪些被拆散。
需要界定的是，本文讨论的是需求表示层面的粒度问题，即用例边界划分是否与参与者目标匹配。用例内容本身是否正确、系统架构如何设计、界面如何绘制，属于其他环节，不在本文诊断范围内。
粒度异常的常见原因与排除证据
症状只是线索，原因需要证据支撑。评审中提出的粒度判断往往是印象，例如“感觉太细了”，这类判断不能直接作为调整依据。可行的做法是先列出原因假设，再用三份清单交叉验证：参与者清单、业务目标清单、用例清单。
| 原因假设 | 验证证据 | 排查顺序 |
|---|---|---|
| 参与者识别不清，目标边界模糊 | 同一用例中出现多个参与者，且各自目标不同；参与者清单中存在职责重叠的角色 | 第一步：核对参与者清单 |
| 把业务流程步骤或界面操作当成用例 | 用例名称是动词短语加界面元素，如“点击提交按钮”；用例无法独立产生可观察的业务结果 | 第二步：核对用例命名 |
| 用包含、扩展关系替代目标分解 | 被包含用例单独看没有业务意义；扩展用例描述的是另一角色的独立目标 | 第三步：核对用例关系图 |
| 缺少统一的命名与前置后置条件约定 | 同类用例命名风格不一致；前置条件写成操作步骤而非状态；后置条件缺失或写成“完成操作” | 第四步：抽查用例模板字段 |
交叉验证的具体做法是：从业务目标清单中取一个目标，在用例清单中找到对应用例，检查该用例的参与者是否与目标归属一致、前置条件是否描述该目标启动时的系统状态、后置条件是否描述目标达成后的可观察结果。三处对不上，说明该用例的边界存在问题，而不是描述细节需要润色。
排查顺序建议从参与者开始，因为参与者定义错误会连带影响目标划分和用例命名，先修上游再查下游可以避免重复返工。若参与者清单本身存在争议，应先暂停粒度调整，把参与者与职责确认清楚再继续。
按目标层级归并或拆分的调整步骤
调整的核心判断标准是：一个用例对应一个参与者为达成一个可观察目标而完成的一次完整交互。按以下步骤执行，可以在控制风险的前提下完成初版模型的修订。
- 备份初版模型并建立变更记录。调整前保存初版用例清单和关系图，调整过程中为每条被修改的用例记录原边界、调整原因和调整后边界，便于评审回溯和对比。
- 以参与者目标为单位重新划定边界。逐条检查用例，标注其对应的参与者和目标。一个用例对应多个目标的，标记为待拆分；多个用例对应同一目标的，标记为待归并。
- 拆分过粗用例。按独立业务结果拆分，每个拆分出的用例应有自己的触发条件、主成功场景和后置条件。拆分后检查是否存在共享步骤，共享部分可用包含关系表达，但被包含用例应保持可独立理解。
- 归并过细用例。把同一目标下的步骤型、分支型用例合并为一条用例，分支写入扩展场景或备选流，保留原有分支描述，避免归并后丢失业务规则。
- 统一命名与条件字段。用例名称采用“参与者+动作+目标”的表达；前置条件描述启动时的系统状态，后置条件描述目标达成后的可观察结果；主成功场景按交互顺序书写，不混入界面细节。
调整过程中有两个停止点需要把握：当拆分出的用例无法写出独立的后置条件时，说明拆分过度，应回退合并；当归并后的用例主成功场景出现两个以上可观察结果时，说明归并过度，应重新拆分。每次调整后更新变更记录，避免多轮修改后无法追溯原始边界。
初版模型评审与调整涉及需求条目的版本、评审记录和追溯关系。ONES 测试管理的用例库支持通过不同方式导入用例并以结构化方式组织管理，也提供自定义属性以适应不同团队的字段约定，可用于承载调整后的用例清单与属性标注。用例与需求条目、业务目标的追溯配置方式，建议在落地前结合实际环境确认。
调整后如何验证并防止粒度问题复发
调整完成不等于问题解决，需要用检查项确认恢复效果，再把粒度约定固化到团队流程中。验证分两层：单条用例的可理解性，以及用例与上下游的追溯完整性。
| 验证检查项 | 通过标准 |
|---|---|
| 独立理解 | 不阅读其他用例，仅凭本条用例的名称、前置条件、主成功场景和后置条件即可说明业务目标 |
| 独立验收 | 该用例的后置条件可以作为一条可观察的验收依据，无需依赖其他用例的完成状态 |
| 目标对应 | 每条用例在业务目标清单中有且仅有一个对应目标 |
| 追溯完整 | 用例与需求条目、业务目标之间的关联关系完整，调整后的用例仍能回溯到原始需求来源 |
| 命名一致 | 全部用例遵循统一的命名规则，抽查无例外 |
复发预防依赖规范与流程两个层面。规范层面，在建模规范中写明粒度约定：一个用例对应一个参与者目标、包含与扩展关系的适用条件、命名规则、前置后置条件的书写要求，并附正反示例。流程层面，把粒度检查纳入用例评审的固定环节，评审前由建模人按症状清单自检，评审中按验证检查项逐条确认，评审记录中保留粒度判断结论。
对于用例规模较大的团队，可以在评审前用参与者清单、业务目标清单和用例清单做一次数量比对，数量关系明显偏离时提前标记，减少评审现场的争论时间。ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面等真实工作上下文回答问题并执行后续操作，在整理评审背景资料、汇总变更记录等环节可作为辅助手段，具体可用范围以实际产品能力为准。
粒度调整的目标是让每条用例都能被独立理解、独立验收，并与业务目标保持一一对应。症状清单用于发现问题，原因与证据对照用于确认问题，调整步骤用于修复问题，验证检查项与规范用于防止问题再次出现。四步走完，初版用例模型才能进入下一阶段的细化与实现。
常见问题
评审时对同一条用例，有人说过粗、有人说过细，怎么判断？
先停止凭印象争论，把这条用例对应的参与者目标和业务目标清单摆出来核对。判断依据是边界是否与目标匹配：一条用例对应多个可观察业务结果，属于过粗；一条用例只覆盖某个目标的一个步骤、离开其他用例无法说明业务结果，属于过细。
如果双方对目标的认定本身不一致，说明分歧在参与者与目标定义，应先确认参与者职责和目标清单，再回到粒度判断，否则调整会反复。
用例数量看起来正常，但评审中两类争论交替出现，是什么情况？
这通常是混合粒度问题：一部分用例过粗，另一部分过细，总数相互抵消后看起来正常。此时不要用总数判断，应逐条标注每个用例对应的参与者目标，统计哪些目标被合并进同一条用例、哪些目标被拆散到多条用例，再分别按拆分和归并处理。
拆分和归并做到什么程度可以停？
有两个可操作的停止点。拆分时，如果拆出的用例写不出独立的后置条件、无法单独说明目标达成后的可观察结果，说明拆过头了，应回退合并。归并时，如果合并后的主成功场景出现两个以上可观察结果，说明并过头了，应重新拆分。
每次调整后更新变更记录，保留原边界和调整原因，便于后续评审回溯。
调整后的用例清单放在哪里管理，评审记录和追溯关系怎么保留？
用例清单需要承载结构化字段（名称、前置条件、后置条件、主成功场景）和评审结论，并与需求条目、业务目标保持关联。ONES 测试管理的用例库支持通过不同方式导入用例并以结构化方式组织管理，也提供自定义属性以适应不同团队的字段约定，可用于承载调整后的用例清单与属性标注。
用例与需求条目、业务目标的追溯配置方式，建议在落地前结合实际环境确认。ONES Assistant 智能助手可基于项目、工作项和 Wiki 页面等真实工作上下文回答问题并执行后续操作，在整理评审背景资料、汇总变更记录等环节可作为辅助手段，具体可用范围以实际产品能力为准。
粒度约定写进规范后，怎么保证评审时真的执行？
把粒度检查拆成评审前和评审中两个动作：评审前由建模人按症状清单自检，重点核对用例数量与业务目标数量的关系；评审中按独立理解、独立验收、目标对应、追溯完整、命名一致五项逐条确认，并把粒度判断结论写入评审记录。
用例规模较大时，可在评审前先做一次三份清单的数量比对，数量关系明显偏离时提前标记，减少现场争论时间。
