用例粒度太粗或太细如何诊断和调整

用例粒度是否合适，核心看它能否对应一个参与者为达成一个可观察目标而完成的完整交互，并且评审者能据此判断通过与否。团队在初版用例模型评审中遇到“太粗”或“太细”的争议时，先统一目标层级口径，再用目标数量、参与者数量、主成功场景步骤和异常分支归属四项证据定位问题，然后按合并、拆分或下沉场景描述的方式调整。本文覆盖症状识别、原因验证、处置步骤和修正后的验证，范围限于需求表示层面的粒度。

要点总览（TL;DR）

• 判断粒度是否合适，核心看一个用例能否对应一个参与者为达成一个可观察目标而完成的完整交互，且评审者能据此判断通过与否。
• 偏粗的典型信号是一个用例包含多个阶段性完成状态、标题用“及/与”连接多个目标；偏细的信号是用例标题只是按钮、页面或单个校验动作。
• 诊断时先统一目标层级口径，再用目标数量、参与者数量、主成功场景步骤数、异常分支归属四项证据交叉验证，避免凭印象下结论。
• 调整按诊断结果执行：多目标用例按参与者目标拆分，同目标碎片用例合并并把步骤下沉到场景描述；参与者识别不清时先修正参与者再动粒度。
• 调整前保留初版基线并确认需求条目关联的影响范围，调整后用目标唯一性、可评审性、目标覆盖、异常分支归属和关联完整性五项检查确认修正有效。

粒度问题的症状与范围界定

评审现场对粒度的争论往往表现为两种相反的意见同时出现：有人认为一个用例覆盖了太多内容，评审时无法逐段确认；有人认为用例被拆得太碎，读完一组用例仍说不清用户到底完成了什么。先把争议归入“偏粗”或“偏细”，后续的原因排查才有共同起点。

偏粗和偏细都有可观察的模型特征，可以直接从用例文本和场景描述中取证，不必依赖个人偏好。下表列出评审中常见的症状，可作为现场归类的对照依据。

观察项	粒度偏粗的表现	粒度偏细的表现
目标数量	一个用例里出现多个可独立成立的目标，标题常用“及”“与”连接	用例标题描述的是某个动作或界面操作，难以称为参与者目标
参与者	主参与者不唯一，或次要参与者承担了实质目标	参与者与相邻用例完全相同，区别只在操作步骤
主成功场景	步骤数明显偏多，中间出现阶段性的完成状态	主成功场景只有一两步，后续全靠扩展场景补充
异常分支	异常分支分散在多个目标下，归属难以判断	每个校验失败都单独成为一个用例
评审体验	评审者无法在一次评审中判断该用例是否通过	评审者需要连续读多个用例才能理解一个完整交互

评审中的典型争议还包括：业务方按业务流程讲述，模型按系统功能拆分，双方对“一个用例应该多大”没有共同参照；或者初版模型由不同成员分头编写，同一层级的用例大小差异明显。这类争议本身不是粒度错误，但会放大粒度判断的分歧，需要在诊断前先确认比较口径是否一致。

本文处理的是需求表示层面的粒度，即用例的划分方式、目标层级和场景组织是否便于评审与后续使用。需求内容本身是否正确、是否遗漏业务规则，属于需求分析与澄清的工作；系统架构划分和界面绘制也不在本文讨论范围内。把内容问题误判为粒度问题，会导致拆分或合并后问题依然存在，因此下一节先做原因假设与证据排除。

粒度偏粗或偏细的原因假设与排除证据

粒度失准通常有可追溯的建模原因，但在评审现场，人们容易把“读起来不舒服”直接当成结论。更稳妥的做法是先列出原因假设，再回到模型中寻找支持或否定该假设的证据，按排查顺序逐项确认。下表给出常见假设、对应证据和排查顺序。

排查顺序	原因假设	验证证据	排除或确认方式
1	目标层级未统一	同一批用例中，有的以业务目标命名，有的以系统功能或界面命名	抽取三到五个用例，写出各自服务的目标，检查是否处于同一抽象层级
2	参与者识别不清	主参与者不唯一，或参与者实际是系统内部模块	对每个用例追问“谁发起、谁获得可观察结果”，无法唯一回答即为证据
3	把业务流程当用例	一个用例跨越多个角色和多个阶段性结果，主成功场景步骤数明显偏多	检查场景中是否存在中间完成状态，若有则说明包含多个目标
4	把界面步骤当用例	用例标题为按钮、页面或单个校验动作，主成功场景极短	检查该用例是否只是另一用例主成功场景中的一步
5	内容缺失或需求歧义	用例读起来含糊，但目标、参与者和场景结构本身完整	补充业务规则后重新阅读，若粒度争议消失则不属于粒度问题

四项证据需要交叉使用，单项证据容易误判。目标数量多但参与者单一、主成功场景步骤适中，可能只是场景描述较详细；步骤数少但每个用例对应不同参与者目标，则属于合理拆分。建议在评审前由建模者填写一张简表，记录每个用例的主参与者、目标一句话描述、主成功场景步骤数和异常分支数量，评审时以此为基础讨论，减少凭印象判断。

排查顺序按影响面从大到小安排：目标层级不统一会同时造成偏粗和偏细的错觉，应先确认；参与者识别不清会连带影响目标划分；把业务流程当用例和把界面步骤当用例是两种方向相反的具体错误，放在后面逐项核对；最后排除内容缺失造成的表象。若前四项证据均不支持粒度问题，而用例仍然难以评审，应转向需求澄清，而不是继续拆分或合并。

按诊断结果调整用例粒度的处置步骤

确认原因后，调整动作应与诊断结论一一对应，避免在评审现场边讨论边改模型。开始前先完成两项前置动作：统一目标层级口径，明确本批用例以参与者可观察目标为划分单位；保留初版用例模型基线，记录调整前的用例清单和关联关系，作为后续回归比对的依据。

偏粗用例的拆分

1. 列出该用例中出现的所有阶段性完成状态，每个状态对应一个候选目标。
2. 按主参与者目标拆分，一个用例保留一个主参与者和一个可观察目标；次要参与者写入该用例的参与者列表。
3. 确定异常分支归属：与某个目标直接相关的校验失败和替代路径留在该目标用例内，跨目标的流程性异常回到上层业务流程描述中。
4. 拆分后检查新用例之间是否存在重复的主成功场景步骤，重复部分下沉为公共场景描述或被包含用例。
5. 停止点：当每个新用例都能用一句话说明参与者达成了什么结果，且评审者可独立判断通过与否时停止拆分。

偏细用例的合并

1. 找出主参与者和目标相同的相邻用例，确认它们是否属于同一完整交互的不同步骤。
2. 合并同目标步骤，保留一个主成功场景，把原有用例中的校验、提示和界面操作下沉到场景描述或扩展场景。
3. 合并后重新检查异常分支，确保原有失败路径仍有归属，不因合并而丢失。
4. 停止点：当合并后的用例主成功场景能够完整走通一次交互，且不再包含可独立成立的目标时停止合并。

参与者识别不清时的修正顺序

先修正参与者，再调整粒度。具体顺序为：确认每个用例的发起者和结果接收者；区分人与外部系统，排除把内部模块写成参与者的情形；对存在多个候选参与者的用例，判断哪个参与者以获得结果为目的，将其定为主参与者；参与者确定后重新检查目标描述，此时多数粒度争议会自然消解。若修正参与者后仍存在多目标，再进入拆分流程。

调整涉及需求条目关联时，先确认影响范围再动手。用例与需求条目、测试用例之间存在引用关系时，拆分或合并会改变引用对象，需要先列出受影响的条目和评审记录，设定回退条件：若调整后发现目标覆盖减少或关键异常分支无归属，回到初版基线重新评估，不在已改动的模型上继续叠加修改。

修正后的验证与复发预防

调整是否有效，用两条标准验证：每个用例对应单一可观察目标；评审者仅凭该用例的参与者、目标和场景描述就能判断通过与否。逐条核对后，再与初版模型做回归比对，确认原有目标没有在拆分合并中丢失。

检查项	通过标准	检查方式
目标唯一性	每个用例能用一句话描述参与者达成的结果	逐条阅读用例标题与目标描述
可评审性	评审者可独立给出通过或不通过结论	由未参与建模的成员试评审
目标覆盖	初版模型中的每个目标在新模型中都有对应用例	用初版目标清单逐项对照
异常分支归属	每条异常路径都能追溯到具体用例	抽查扩展场景与业务流程描述
关联完整性	受影响的需求条目和测试用例引用已更新	核对变更记录与引用清单

复发预防的重点是把粒度判断变成评审清单中的固定项，而不是每次重新争论。可在评审清单中增加：用例目标是否单一、主参与者是否唯一、主成功场景是否包含多个阶段性结果、是否存在仅描述界面操作的用例、异常分支是否有明确归属。同时把目标层级说明写入建模规范，明确本批用例以参与者目标为划分单位，新成员加入时先阅读该说明再编写用例。

在需求管理工具中固化这些做法，可以让粒度检查留下可追溯的记录。ONES 测试管理解决方案支持通过不同方式导入用例至用例库，并以清晰的结构组织与管理用例，同时提供自定义属性以满足不同场景的定制需求，团队可用属性记录用例的目标层级和评审状态。评审意见和调整结论可随需求条目与用例记录一并留存，缺陷也可关联至迭代，便于在后续迭代中回看粒度调整的影响。将用例状态、评审结论和变更记录放在同一处管理，回归比对时不必再跨文档查找，粒度检查项也更容易在每次评审中执行到位。

常见问题

评审现场对同一个用例，一方说太粗、一方说太细，怎么快速定论？

先不要争论“应该多大”，而是把讨论拉回四项可取证的事实：该用例有几个可独立成立的目标、主参与者是否唯一、主成功场景中是否存在阶段性完成状态、异常分支是否都归属于同一个目标。四项证据指向同一方向时，结论基本明确；证据互相矛盾时，多半是双方对目标层级的理解不一致，应先统一口径再判断。若补充业务规则后争议消失，说明问题出在需求内容而非粒度。

用例拆分后数量翻倍，评审工作量明显增加，是否拆过头了？

拆分是否过头，用停止点检验：每个新用例能否用一句话说明参与者达成了什么结果，评审者能否独立判断通过与否。如果拆分后出现多个用例主成功场景高度重复、只是操作步骤不同，说明拆到了界面动作层面，应把重复步骤下沉为公共场景描述或合并回同一目标用例。拆分的目标是让每个用例可独立评审，用例数量增加本身不是问题，重复和碎片化才是。

参与者识别不清和粒度问题同时存在时，应该先改哪个？

先修正参与者。参与者的发起者和结果接收者确定后，目标描述通常会随之收敛，一部分粒度争议会自然消解。具体顺序是：确认每个用例的发起者与结果接收者，排除把系统内部模块写成参与者的情况，多个候选参与者时以获取结果的一方为主参与者，然后重新检查目标描述。若修正参与者后仍存在多目标，再进入拆分流程，避免在参与者未定的情况下反复拆合。

调整粒度会改动已关联的需求条目和测试用例，如何控制影响范围？

动手前先保留初版用例模型基线，列出与待调整用例存在引用关系的需求条目、测试用例和评审记录，评估拆分或合并后引用对象的变化。设定回退条件：若调整后发现原有目标覆盖减少，或关键异常分支失去归属，回到初版基线重新评估，不在已改动的模型上继续叠加修改。调整完成后核对变更记录与引用清单，确认受影响条目已同步更新。

粒度检查如何固化为团队常规动作，避免每次评审重新争论？

把粒度判断写进评审清单，作为固定检查项：用例目标是否单一、主参与者是否唯一、主成功场景是否包含多个阶段性结果、是否存在仅描述界面操作的用例、异常分支是否有明确归属。同时把目标层级说明写入建模规范，明确本批用例以参与者目标为划分单位，新成员编写用例前先阅读。在需求管理工具中记录用例的目标层级属性和评审状态，可以让每次检查留下可追溯的记录，回归比对时不必跨文档查找。