用例图评审时，包含与扩展关系画混是常见问题：可选行为被画成包含，公共步骤被画成扩展，业务分支被塞进扩展点。本文给出一套可在评审现场执行的检查路径——先把症状归类，再用三个判定问题逐条确认或排除，最后按风险顺序修正并验证。检查范围限定在用例图的关系表达，不涉及架构设计与界面绘制。
要点总览（TL;DR）
- 评审现场先按症状归类：可选行为画成包含、公共步骤画成扩展、业务分支误当扩展点，再逐条判定。
- 判断一条关系是包含还是扩展，依次回答三个问题：是否每次执行都发生、由主用例主动调用还是外部条件触发、触发条件是否单一可命名。
- 修正按风险排序：先改包含与扩展颠倒的方向性错误，再补扩展点名称，最后处理重复用例与命名规范。
- 无法判定的关系回到需求原文或找提出人确认，标记待澄清项并明确责任人，不凭图面猜测。
- 修正后用场景走查和测试用例反推验证，并把关系方向、扩展点、用例粒度固化为评审检查项。
评审中关系混乱的典型症状与影响范围
关系用错在图上通常有迹可循。评审开始前，先花几分钟把“感觉乱”转成具体症状，后续讨论才有共同对象。
可观察的图上症状
- 箭头方向与语义对不上：包含关系应指向被复用的步骤用例，扩展关系应指向被扩展的主用例。现场常见两种画法混淆：把包含箭头画向主用例，或把扩展箭头画向扩展用例，读图人需要反推才能理解。
- 同一用例既被包含又被扩展：一个用例同时出现在包含和扩展两端，说明它的定位没有想清楚——它到底是每次都要走的公共步骤，还是特定条件下才插入的行为。
- 扩展点缺失或指向不明：扩展关系没有标注在哪个扩展点插入，或扩展点名称写成“异常处理”“其他情况”这类无法对应具体触发条件的表述。
- 包含用例数量异常膨胀：主用例下挂了一长串包含用例，其中不少只在个别场景出现，这是把可选行为误画成包含的典型痕迹。
对下游工作的影响
关系错误不只是图面美观问题。包含关系意味着每次执行都会发生，开发会按必做逻辑估算工作量；扩展关系意味着条件触发，测试需要为每个扩展点设计分支用例。关系画反，估算口径和测试覆盖都会跟着偏。评审时若只改图不改判定依据，同类错误在下一版还会出现。
本次检查的范围
检查对象是本次评审涉及的用例图及其关系标注，包括包含、扩展的箭头方向、扩展点定义和用例粒度。需求内容本身是否正确、系统架构如何划分、界面如何呈现，不在本次检查范围内，发现相关问题记录后转交对应环节处理。
包含与扩展用错的常见原因假设
症状只是线索，原因需要逐条验证。以下假设可在评审时对照图面观察点逐项排查，确认成立的再进入判定环节，不成立的直接排除。
| 原因假设 | 对应观察点 |
|---|---|
| 把“每次都会执行的公共步骤”与“特定条件下才发生的行为”混为一谈 | 被包含的用例里是否混入了只在部分场景出现的行为；扩展用例里是否有每次必做的步骤 |
| 把业务规则分支当成扩展，导致扩展点过多且无法穷举 | 扩展点数量是否明显偏多；扩展点名称是否写成规则条款而非触发条件 |
| 参与者与用例边界划分不清，间接造成关系方向错误 | 同一功能是否被拆到多个用例又互相包含；参与者触发的是主用例还是被拆出的片段 |
| 绘图工具默认箭头方向或团队命名习惯带来的误用 | 箭头方向是否与团队约定一致；用例命名是否用动词短语清楚表达行为 |
这些假设之间会相互叠加。例如边界不清导致用例拆分过细，拆出的片段又被画成包含，最终图上出现大量方向可疑的关系。排查时先记录每条假设的观察结果，再进入逐条判定，避免在假设阶段就下结论。
用三个判定问题逐条排除错误关系
对图上每一条包含或扩展关系，按顺序回答三个问题。三个问题的答案组合基本能确定关系类型，答案矛盾或无法回答的，标记为待澄清项。
判定问题与结论对照
| 判定问题 | 回答 | 倾向结论 |
|---|---|---|
| 该行为是否在主用例每次执行时都发生 | 是，且是主用例流程中固定的一步 | 倾向包含关系 |
| 该行为是否在主用例每次执行时都发生 | 否，只在特定条件下出现 | 倾向扩展关系，继续问第二、三题 |
| 该行为由主用例主动调用，还是由外部条件触发 | 主用例流程主动调用、作为固定步骤执行 | 倾向包含关系 |
| 该行为由主用例主动调用，还是由外部条件触发 | 由条件、异常或可选需求触发，主用例不主动调用 | 倾向扩展关系 |
| 触发条件是否单一、可命名，能否写成明确的扩展点 | 能写出一个具体条件，如“支付超时”“用户选择加急” | 可作为扩展关系保留 |
| 触发条件是否单一、可命名，能否写成明确的扩展点 | 条件笼统、多个规则混在一起、无法穷举 | 不是合格的扩展点，回到需求澄清 |
判定记录的要求
每条关系记录四项内容：关系编号与两端用例、三个问题的答案、判定结论（包含/扩展/待澄清）、依据来源（需求原文条款或提出人确认）。记录的作用是让修正有据可查，也方便后续变更时追溯当初为什么这样画。
无法判定时的处理
三个问题答案互相矛盾，或图上信息不足以回答时，不要凭图面猜测。回到需求原文找对应描述，找不到就找需求提出人确认该行为的发生频率和触发方式。确认结果补进判定记录后再改图。评审现场无法当场确认的，标记为待澄清项，明确责任人和确认时间，不带着未决关系进入下一环节。
评审记录和判定结论需要随需求条目一起留存。在ONES中，可以把用例图所在的需求条目与评审记录关联，将待澄清项作为工作项跟踪到关闭，修正后的版本和判定依据留在同一条目下，后续变更时能直接查到当时的关系判定理由。
按排查顺序修正关系并控制改动风险
修正顺序影响返工量。先处理方向性错误，再处理命名和粒度，避免在细节上反复调整后又要因方向变化重做。
修正顺序清单
- 先修方向性错误：把包含与扩展颠倒的关系改正，箭头指向按语义调整——包含指向被复用步骤，扩展指向被扩展的主用例。
- 再修扩展点：为每条扩展关系补上明确的扩展点名称，名称写成可观察的触发条件；无法命名的扩展关系退回判定环节重新确认。
- 处理重复与过载用例：合并语义重复的用例；对职责过载、包含关系过多的主用例，按参与者目标拆分，拆分后重新检查关系方向是否仍然成立。
- 最后统一命名与图面规范：用例命名统一为动词短语，箭头样式与团队约定一致。
取舍原则
合并用例时，以“参与者的一次完整目标”为单位，目标相同就合并，目标不同就保留。拆分过载用例时，拆出的部分若每次都会执行，考虑作为包含用例；若只在特定条件下执行，考虑作为扩展用例；两者都不成立，说明拆分依据不是行为频率，应回到需求澄清。
改动前的风险控制
- 修改前保留原图版本或评审记录，确保可以回退和对比。
- 涉及跨团队引用的用例图，先同步修改范围和影响，再动图，避免其他团队按旧版继续工作。
- 批量调整关系前，先在一两个用例上试改并请提出人确认，确认判定口径一致后再推广到全图。
应暂停修改的情况
需求本身存在歧义、提出人无法确认行为频率、或关系争议涉及业务规则变更时，暂停调图，转为需求澄清。继续在图上调整只会把未决问题固化成一个看似确定的画法，后续更难发现。
修正后的验证与复发预防
改完图不等于改对。用两种方式交叉验证，再把检查动作固化到评审流程里。
场景走查
选取典型业务场景，从参与者触发开始沿主用例走一遍，每遇到一个扩展点，确认它能对应一个具体的触发条件，并说明该条件下会发生什么。走查中若某个扩展点找不到对应场景，或某个必做步骤被画成了扩展，说明修正不完整，回到判定环节。走查记录保留场景名称、经过的扩展点和结论。
测试用例反推
按修正后的图尝试写出测试用例：主流程一条，每个扩展点至少一条分支用例。写不出来的扩展点说明触发条件不明确；分支用例数量与扩展点数量对不上，说明关系仍有遗漏或多余。这一步同时验证了图的可测试性，产出的用例清单可以直接交给测试环节。
评审检查项固化
把本次排查中反复出现的问题整理成固定检查条目，纳入后续用例图评审：
- 每条包含关系的被包含用例，是否在主用例每次执行时都发生；
- 每条扩展关系是否标注了扩展点，扩展点名称是否为单一、可命名的触发条件；
- 是否存在同一用例既被包含又被扩展的情况；
- 用例粒度是否以参与者的一次完整目标为单位；
- 关系判定依据是否随图留存。
检查项随评审记录一起归档，下次评审直接对照执行。判定依据和图放在同一处管理，人员变动或需求变更时，后来者能看懂每条关系为什么这样画，同类错误的发生空间会明显收窄。
常见问题
评审时间有限，只能先查一部分关系，应该优先查哪些？
优先查三类高影响关系：一是同一用例既出现在包含端又出现在扩展端的情况，这类关系说明用例定位本身没想清楚；二是扩展点缺失或名称笼统的扩展关系，它们直接影响测试分支设计；三是主用例下包含用例数量异常多的部分，其中往往混入了只在个别场景出现的行为。方向性错误修正后可能连带影响其他关系，先处理能减少后续返工。
一个行为既像公共步骤又像条件触发，怎么定？
回到需求原文确认该行为的发生频率：如果主用例每次执行都会经过它，按包含处理；如果只在特定条件下出现，按扩展处理，并把条件写成扩展点。若需求原文本身没有说清发生频率，这属于需求歧义，应先找提出人确认，确认结果补进判定记录后再改图。不要为了图面完整先画一个关系，把未决问题固化成看似确定的表达。
扩展点数量很多，是不是说明关系画错了？
扩展点偏多是一个值得排查的信号，但不必然等于画错。先看扩展点名称：如果写成“异常处理”“其他情况”这类笼统表述，或把多条业务规则塞进一个扩展点，说明业务分支被误当成了扩展。若每个扩展点都能对应一个具体、单一的触发条件，数量多可能反映业务本身分支丰富，此时应检查用例粒度是否过细，而不是简单删减关系。
修正关系时改动了其他团队引用的用例图，需要做什么？
动图前先同步修改范围和影响，说明哪些关系会变、变化后对他们的工作有什么影响，确认后再改。修改前保留原图版本或评审记录，确保可以回退和对比。批量调整前先在一两个用例上试改并请提出人确认判定口径，口径一致后再推广到全图，避免改到一半发现方向又反了。
修正后的用例图怎么确认已经改对了？
用两种方式交叉验证。场景走查：从参与者触发开始沿主用例走一遍，每个扩展点都要能对应一个具体触发条件和该条件下的行为。测试用例反推：按修正后的图写主流程用例和每个扩展点的分支用例，写不出来的扩展点说明触发条件不明确，分支用例数量与扩展点对不上说明关系仍有遗漏或多余。两种验证的记录随图留存，后续变更时可追溯。
