缺陷关联图把一个缺陷与它影响的需求、模块、接口、用例、版本和关联缺陷连成一张可读的关系图，用来判断“会波及哪里、修它要动谁、验证到什么程度算够”。下面给出一份已填写的演示示例，以登录验证码缺陷为起点，逐项说明节点、连线、影响等级和验证范围怎么填，并提炼可迁移到其他缺陷的规则。
要点总览（TL;DR）
- 缺陷关联图以单个缺陷为起点，把受影响的需求、模块、接口、用例、版本和关联缺陷连成一张关系图，回答影响范围、修复依赖和验证范围三个问题。
- 示例以弱网下登录验证码校验失败为起点，节点表给出14个节点及影响等级，连线表用触发、影响、依赖、验证、重复/相关五类关系说明方向。
- 影响等级按用户可见性与波及范围确定，并与验证动作对应：高等级进入回归清单覆盖主要路径，中等级做针对性验证，低等级保留观察。
- 填写顺序可迁移：先写缺陷起点，再定影响对象，后定连线类型，标影响等级，最后从验证连线推导回归清单。
- 需求覆盖与追溯、跨对象变更治理不属于缺陷关联图的主场，应分别归入需求追溯与覆盖管理、研发变更控制与影响分析。
示例目标：这张缺陷关联图要回答什么
本文示例设定为演示情景，缺陷、需求、模块、接口、用例与版本信息均为虚构，用于说明填写方法，不构成真实客户案例，也不代表任何实测结论。读者可以把它当作一张“填好的样表”，对照自己的缺陷记录逐项替换。
这张图要回答三个问题：
- 影响哪些对象：这个缺陷直接或间接波及哪些需求、模块、接口和用例，哪些对象只是同处一个功能区域但不受影响。
- 修复波及哪些改动：修复动作会落在哪个模块、是否需要同步调整上下游接口或关联缺陷，改动边界在哪里。
- 验证覆盖到哪：修完之后要回归哪些用例、在哪些版本和环境上验证，达到什么结果可以关闭缺陷。
图的读者包括缺陷评审人、开发负责人和测试负责人。使用时机主要有三个：缺陷评审会上确认影响范围，修复排期时评估改动工作量与依赖，回归验证前确定用例与版本范围。画图的目的在于支撑这三类判断，节点和连线都围绕判断需要保留。
完整示例：登录验证码缺陷的关联图填写结果
示例背景：某系统登录环节的图形验证码在弱网条件下偶发失效，用户提交正确账号密码后因验证码校验失败被拒绝登录。该缺陷标记为“示例”，以下节点与连线均围绕它展开。
节点表
| 节点编号 | 节点类型 | 节点名称（示例） | 与缺陷的关系 | 影响等级 |
|---|---|---|---|---|
| D1 | 缺陷 | 弱网下登录验证码校验失败 | 起点 | 高 |
| R1 | 需求 | 账号密码登录（含验证码校验） | 受影响 | 高 |
| R2 | 需求 | 登录失败提示与重试 | 受影响 | 中 |
| M1 | 模块 | 登录页前端验证码组件 | 受影响 | 高 |
| M2 | 模块 | 认证服务校验逻辑 | 依赖 | 中 |
| I1 | 接口 | 验证码获取接口 | 受影响 | 高 |
| I2 | 接口 | 登录鉴权接口 | 依赖 | 中 |
| C1 | 用例 | 正常网络下验证码登录 | 验证覆盖 | — |
| C2 | 用例 | 弱网下验证码登录与重试 | 验证覆盖 | — |
| C3 | 用例 | 验证码超时后重新获取 | 验证覆盖 | — |
| V1 | 版本 | 移动端 3.2 发布版本 | 受影响 | 高 |
| V2 | 版本 | Web 端 3.2 发布版本 | 相关 | 低 |
| D2 | 关联缺陷 | 验证码图片加载超时无提示 | 相关 | 中 |
| D3 | 关联缺陷 | 弱网下登录按钮重复提交 | 重复/相关 | 低 |
连线表
| 起点 | 终点 | 连线类型 | 方向说明 |
|---|---|---|---|
| D1 | R1 | 影响 | 缺陷使该需求的验收条件在弱网场景下不成立 |
| D1 | R2 | 影响 | 校验失败后的提示与重试路径被触发 |
| D1 | M1 | 触发 | 缺陷现象由前端验证码组件在弱网下的行为引发 |
| M1 | I1 | 依赖 | 组件依赖验证码获取接口的返回时序 |
| D1 | M2 | 依赖 | 修复需确认认证服务对过期验证码的判定逻辑 |
| M2 | I2 | 依赖 | 校验逻辑通过登录鉴权接口生效 |
| D1 | C2 | 影响 | 该用例可稳定复现缺陷 |
| C1 | D1 | 验证 | 修复后需回归确认正常网络不受影响 |
| C3 | D1 | 验证 | 修复后需回归确认超时重取路径 |
| D1 | V1 | 影响 | 缺陷在移动端发布版本中可复现 |
| D1 | V2 | 相关 | 同版本 Web 端未复现，保留观察 |
| D1 | D2 | 相关 | 同属验证码加载链路，现象不同但根因可能相邻 |
| D1 | D3 | 重复/相关 | 弱网下重复提交与校验失败可能同源，待确认后合并或保留关联 |
影响与验证结论
影响结论：缺陷直接影响登录需求 R1 与失败提示需求 R2，触发点在前端验证码组件 M1，依赖验证码获取接口 I1 与认证服务 M2 的时序配合；受影响版本为移动端 V1，Web 端 V2 暂列相关观察。
验证范围：修复后至少回归 C1、C2、C3 三条用例，覆盖正常网络、弱网与超时重取三种路径；验证环境需包含弱网模拟条件；D2、D3 在根因确认前保持关联，确认同源后按重复处理，否则各自独立跟踪。
逐项解释：每个字段为什么这样填
为什么 R1 列为受影响，R2 也列为受影响
R1 的验收条件包含“在正常与弱网条件下均可完成验证码校验”，缺陷使该条件在弱网下不成立，因此属于受影响而非仅相关。R2 描述失败提示与重试，缺陷发生时用户会进入这条路径，提示是否准确、重试是否顺畅都受缺陷影响，所以同样列为受影响。判断标准是：缺陷是否使该对象的验收条件或用户路径发生偏离。仅在同一功能区域出现、验收条件不受影响的对象，列为相关即可。
影响等级如何确定
影响等级依据两个维度：用户可见性与波及范围。D1 导致用户无法登录，属于核心路径阻断，用户可见性高；波及移动端全部登录用户，范围广，因此定为高。M2 与 I2 属于修复时需要确认的依赖对象，用户不直接感知，定为中。V2 在同版本 Web 端未复现，定为低并保留观察。等级用于排序处理优先级，不替代缺陷本身的严重程度字段，两者可以不同。
关联缺陷为什么标为相关或重复
D2 与 D1 同属验证码加载链路，但现象是“无提示”而非“校验失败”，根因可能相邻也可能不同，标为相关并保留独立跟踪。D3 与 D1 都出现在弱网场景，重复提交可能加剧校验失败，存在同源可能，先标为重复/相关，待根因确认后再决定合并或拆分。判断依据是现象、触发条件与疑似根因的重合程度，重合度高才合并，重合度不确定时保留关联更稳妥。
验证范围如何从连线推导
验证范围来自指向缺陷的“验证”连线，以及受影响对象所对应的用例。示例中 C2 能稳定复现缺陷，C1 与 C3 覆盖修复可能波及的正常路径与超时路径，因此三条都进入回归范围。受影响版本 V1 决定验证环境，依赖对象 M2、I2 决定是否需要接口级验证。验证范围的完成标志是：三条用例在弱网与正常网络条件下均通过，且 D2、D3 的关联状态已确认。
哪些字段应留待确认
D3 的“重复/相关”属于待确认状态，根因未定位前不写成确定重复。V2 是否受影响同样留待确认，示例中只写“未复现、保留观察”。当接口归属、版本范围或根因信息不足时，字段填“待确认”并注明确认人，比填一个看似确定的结论更可靠，也便于后续评审时追踪。
可迁移规律：换一个缺陷也能照着画
示例的价值在于填写顺序和判断规则可以复用。换一个缺陷时，按下面的步骤推进，能得到结构一致、结论可核对的关联图。
- 先写缺陷起点：用一句话描述现象、触发条件与可复现环境，作为图中唯一的起点节点。
- 再定影响对象：沿用户路径和验收条件逐层找受影响的需求、模块、接口、用例与版本，先列全再收敛。
- 后定连线类型：区分触发（缺陷由谁引发）、影响（谁的条件被破坏）、依赖（修复需确认谁）、验证（谁用来确认修复）、重复/相关（与哪些缺陷同源或相邻）。方向统一从原因指向结果，或从缺陷指向受影响对象，全图保持一致。
- 标影响等级：按用户可见性与波及范围给出高、中、低，等级与验证优先级对应。
- 推导验证范围：把指向缺陷的验证连线与受影响对象对应的用例合并，形成回归清单，并写明环境与完成标志。
节点收敛原则：只保留对判断有影响的对象。同一模块下的多个页面若影响结论相同，合并为一个节点；与判断无关的历史关联不画入图中，避免图面膨胀后失去可读性。
影响等级与验证范围的对应关系可以固定下来：高等级对象必须进入回归清单并覆盖主要路径；中等级对象至少做一次针对性验证；低等级对象保留观察并在版本发布前复查。这样等级不只是标签，而能直接转化为验证动作。
图需要与缺陷记录、用例和版本信息同步维护。缺陷状态变化、用例增删或版本范围调整时，同步更新节点与连线，并在图中注明更新时间和确认人。示例中的缺陷、关联工作项与验证状态可以在 ONES 中承载：ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug，缺陷可提交至对应项目或迭代；ONES TestCase 支持用例与需求、任务关联，未通过的用例可快速创建缺陷任务。把关联结论回写到缺陷记录和用例上，图才不会与实际情况脱节。
适用边界：什么时候该换别的方法
缺陷关联图适合从单个缺陷出发看影响链路，典型场景包括：缺陷评审时确认波及范围、修复前评估改动依赖、回归前确定用例与版本范围、判断多个缺陷是否同源。它的视角以缺陷为中心，回答的是“这个缺陷牵动什么”。
以下情况应改用其他方法：
- 需求覆盖与追溯：当问题变成“需求是否被用例完整覆盖、每条需求追溯到哪些测试”时，应归入需求追溯与覆盖管理，用需求—用例—缺陷的双向追溯矩阵处理，缺陷关联图只提供其中一个视角。
- 跨对象变更治理：当问题变成“一次变更会影响哪些需求、接口、版本和团队”时，应归入研发变更控制与影响分析，按变更单和影响分析流程推进，缺陷关联图不足以承载变更审批与跨团队协调。
- 信息不全的情形：根因、接口归属或版本范围尚未确认时，图中相应字段写“待确认”并注明确认人，不用推测填补。待信息补齐后再更新连线与等级，避免把假设当成结论传递到排期和验证环节。
把边界分清之后，缺陷关联图在它擅长的范围内能稳定发挥作用：一张图、一组连线、一份验证清单，让缺陷评审、修复排期和回归验证围绕同一份事实展开。
常见问题
缺陷关联图里的节点要画多细，模块下面的页面要不要逐个列出？
按判断需要决定粒度。如果同一模块下的多个页面在影响结论、修复方式和验证用例上完全一致，合并成一个模块节点即可；如果某个页面有独立的接口依赖或需要单独的回归用例，就拆成独立节点。判断标准是：这个节点是否改变影响等级、修复范围或验证清单中的任何一项。三项都不变，合并更利于读图。
缺陷还没定位根因，关联图可以先画吗？
可以先画，但要把不确定的部分标成待确认。起点缺陷、已复现的版本和能稳定复现的用例通常可以先确定；疑似同源的关联缺陷、尚未确认的接口归属、未复现的版本，写成“待确认”并注明确认人。等根因定位后再补连线、调整影响等级，避免把假设当成结论传递到排期和验证环节。
关联缺陷什么时候合并为重复，什么时候只保留关联？
看现象、触发条件与疑似根因的重合程度。三者高度重合、修复动作可以一次覆盖时，合并为重复；现象不同但同处一条链路、根因可能相邻时，保留关联并各自跟踪。示例中“验证码图片加载超时无提示”标为相关，“弱网下登录按钮重复提交”标为重复/相关，就是因为后者存在同源可能但根因尚未确认。合并前建议先确认修复方案是否一致。
缺陷关联图和需求追溯矩阵是什么关系，能不能只维护一份？
两者视角不同。缺陷关联图以缺陷为中心，回答这个缺陷牵动哪些对象；需求追溯矩阵以需求为中心，回答每条需求被哪些用例覆盖、关联哪些缺陷。日常可以从缺陷关联图入手做影响评估，再把结论回写到需求与用例的追溯关系中。如果团队的主要问题是需求覆盖率不足或追溯链条缺失，应直接维护需求追溯矩阵，缺陷关联图只作为其中一个视角。
关联图里的缺陷、用例和验证状态放在哪里维护比较合适？
放在团队日常处理缺陷和用例的工具里，避免图与记录各存一份。示例中的缺陷、关联工作项与验证状态可以在 ONES 中承载：ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug，缺陷可提交至对应项目或迭代；ONES TestCase 支持用例与需求、任务关联，未通过的用例可快速创建缺陷任务。关联结论回写到缺陷记录和用例上，图才能随状态变化同步更新。
