缺陷与测试用例的关联，核心是建立一条从缺陷到执行记录再到用例的可追溯链路，让每条缺陷都能回答三个问题：由哪条用例的哪次执行发现、该用例覆盖了什么、修复后需要回归哪些用例。本文按字段设计、操作步骤、角色分工、完整示例和完成检查五个部分展开，适用于正在梳理缺陷流程、希望把关联动作落到具体节点和字段上的测试与研发团队。
要点总览（TL;DR）
- 缺陷与用例之间通过执行记录建立关联：缺陷单记录发现用例编号、执行记录ID、发现版本/环境，用例侧保留编号与所属需求，形成可双向追溯的链路。
- 关联动作嵌入现有节点：执行失败时记录失败步骤与构建版本，提交缺陷时从执行记录带入用例信息，评审时校验关联完整性，修复时标注影响范围，关闭前核对回归结果。
- 角色分工明确：测试执行人负责提交时关联，缺陷评审人校验关联与影响范围，开发标注受影响模块，测试负责人发布前汇总关联情况与回归结果。
- 整体链路验收按版本核对：每条缺陷有发现用例与执行记录、关联用例指向明确需求或功能点、修复后有关联回归执行结果、发布前关联覆盖率达到团队约定阈值。
先定关联对象与字段：缺陷、用例、执行记录怎么挂
关联链路的最小数据模型包含三个对象：缺陷、用例、执行记录。缺陷与用例之间通过执行记录建立关系，缺陷单上挂的不只是一个用例编号，还包括这次执行发生的时间、执行人和构建版本。只挂用例编号时，同一个用例在多个版本反复执行，缺陷无法说明是哪一次执行暴露的问题，回归范围也难以界定。
执行记录作为中间对象，承载三类信息：执行时间、执行人、被测构建版本。缺陷通过执行记录ID指向具体某次执行，再经由该记录指向用例，形成“缺陷—执行记录—用例”的单向可追溯结构；用例侧保留反向引用，即可从用例查到历史上由它发现的缺陷。
缺陷—执行记录—用例字段对照
| 对象 | 字段 | 填写要求 | 作用 |
|---|---|---|---|
| 缺陷 | 发现用例编号 | 必填，从执行记录带入 | 定位发现缺陷的用例 |
| 缺陷 | 执行记录ID | 必填，指向具体一次执行 | 区分同一用例的不同执行批次 |
| 缺陷 | 发现版本/环境 | 必填，写明构建号与测试环境 | 支撑复现与影响判断 |
| 缺陷 | 复现步骤 | 必填，对应失败步骤 | 让开发按步骤复现 |
| 执行记录 | 执行时间、执行人、构建版本 | 系统记录或执行时填写 | 提供发现时点与责任人 |
| 用例 | 用例编号 | 唯一且稳定 | 作为关联主键 |
| 用例 | 所属需求或功能点 | 必填 | 从缺陷反查业务影响面 |
| 用例 | 最近执行结果 | 随执行更新 | 判断回归是否已覆盖 |
关联粒度的选择
用例级关联指缺陷挂到整条用例上，落地快、维护成本低，适合用例步骤少、失败点集中的场景。步骤级关联指缺陷挂到具体失败步骤，适合复现路径长、同一条用例不同步骤可能暴露不同问题的场景。两种粒度可以并存，但需要在缺陷模板中约定哪些项目必填步骤级关联，避免同一团队内标准不一。
操作步骤：从发现缺陷到建立关联的五个动作
关联动作应嵌入现有节点，不额外新增流程环节。以下五步按时间顺序排列，每步给出输入、动作、输出和完成标志。
动作一：执行失败时当场记录
输入是待执行的用例与当前构建版本。测试人员执行用例，失败时在用例执行界面标记失败步骤，记录实际结果与构建版本。输出是一条状态为失败的执行记录。完成标志是该执行记录已保存，且失败步骤与实际结果可被后续查阅。
动作二：提交缺陷时从执行记录带入用例信息
输入是失败的执行记录。测试人员从该记录直接创建缺陷，用例编号、执行记录ID、发现版本由系统带入缺陷单，测试人员补充复现步骤、期望结果与实际结果。输出是一张关联信息完整的缺陷单。完成标志是缺陷单上发现用例编号与执行记录ID均非空，且与失败执行一致。手工填写用例编号容易错号或漏填，从执行记录带入是减少这类错误的关键动作。
动作三：缺陷评审时校验关联完整性
输入是待评审的缺陷单。缺陷评审人核对三件事：发现用例是否唯一指向一条执行记录、该用例所属需求或功能点是否明确、是否存在同一问题由多条用例发现而需要补充关联的情况。输出是评审通过的缺陷单或退回补充的缺陷单。完成标志是关联字段齐全，且影响范围有初步判断。
动作四：修复提交时标注影响范围
输入是已定位原因的缺陷单。开发在提交修复时，在缺陷中标注改动涉及的模块、接口或功能点，并说明可能受影响的用例范围。测试据此圈定回归用例清单，补充关联到缺陷单。输出是修复说明加回归用例清单。完成标志是缺陷单上既有发现用例，也有回归用例，且回归范围与开发标注的影响范围对应。
动作五：关闭前核对回归结果
输入是待关闭的缺陷单与回归用例清单。测试执行回归用例，将执行结果关联回缺陷单，确认原失败步骤已通过、关联回归用例均通过。输出是带回归执行结果的缺陷单。完成标志是缺陷单状态可关闭，且关联用例的最近执行结果为通过。
角色与交付物：谁在哪个节点负责关联
关联动作分散在多个节点，需要明确每个角色的职责与产出，否则容易出现“缺陷提了但没人补关联”或“回归范围靠口头约定”的情况。下表按角色列出节点与交付物。
| 角色 | 负责节点 | 主要动作 | 交付物 |
|---|---|---|---|
| 测试执行人 | 用例执行、缺陷提交 | 记录失败步骤与构建版本，从执行记录创建缺陷 | 关联完整的缺陷单 |
| 缺陷评审人 | 缺陷评审 | 校验关联唯一性与影响范围，退回补充 | 评审通过的缺陷单 |
| 开发 | 修复提交 | 标注改动模块与受影响范围 | 修复说明与影响范围说明 |
| 测试负责人 | 发布前核对 | 汇总缺陷关联情况与回归结果 | 回归用例清单、发布核对记录 |
测试负责人汇总时关注两类信息：本版本缺陷是否都带有发现用例与执行记录，以及修复缺陷的回归用例是否都已执行。这两项信息构成发布核对记录的主要内容，也是判断关联链路是否可用的直接依据。
当团队使用 ONES 承载测试与缺陷流程时，ONES TestCase 支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。这与上述“从执行记录创建缺陷、在缺陷中补充回归用例”的动作方向一致，具体字段名称与带入方式需按实际配置确认。
示例：一条缺陷的完整关联链路
以下为演示情景，用于说明字段填写与状态流转，不代表真实项目数据。
场景设定：某功能用例“订单提交—优惠券叠加”在构建版本 V2.3.1 的测试环境执行失败，失败步骤为“选择两张可叠加优惠券后提交订单”。
缺陷单填写示例
- 发现用例编号：TC-ORDER-0187
- 执行记录ID：EXE-20240612-0042
- 发现版本/环境：V2.3.1 / 测试环境
- 复现步骤：登录测试账号，加入两件参与活动的商品，选择两张可叠加优惠券，提交订单，页面提示“优惠金额计算异常”
- 期望结果：订单金额按叠加规则扣减；实际结果：优惠金额只计算了第一张券
修复与回归关联
开发定位为优惠计算服务在叠加场景下的取券逻辑问题，在缺陷中标注影响范围为“优惠计算服务、订单提交接口”，并说明可能影响“多券叠加”“单券使用”“无券下单”三类用例。测试据此补充关联回归用例 TC-ORDER-0187、TC-ORDER-0190、TC-ORDER-0192，并加入本版本回归清单。
关闭前核对
测试在 V2.3.2 构建上执行三条回归用例，结果均为通过，并将执行结果关联回缺陷单。缺陷单此时同时具备发现用例、执行记录、回归用例与回归结果，满足关闭条件。
反查路径
从该缺陷出发，可查到发现用例 TC-ORDER-0187 及其所属功能点“订单优惠”，进而看到该功能点下其他用例的历史执行情况；从用例出发，可查到由它发现的历史缺陷。这条双向路径就是关联链路可用的直接体现。
完成检查：关联链路是否可用的核对项
单步完成标志针对每个动作，整体链路验收需要一套覆盖全流程的核对项。以下清单可按版本逐项核对。
| 核对项 | 通过标准 | 不通过时的处理 |
|---|---|---|
| 每条缺陷是否都有发现用例与执行记录 | 关联字段非空且指向有效记录 | 阻断关闭，退回补充关联 |
| 关联用例是否指向明确的需求或功能点 | 用例所属需求或功能点已填写 | 补录用例归属信息 |
| 修复后是否有关联的回归执行结果 | 回归用例均有执行记录且结果为通过 | 阻断关闭，安排回归执行 |
| 发布前缺陷关联覆盖率是否达到约定阈值 | 达到团队按版本风险约定的比例 | 未达阈值时列出缺失清单，评估是否放行 |
| 关联缺失或错挂是否有补录规则 | 明确补录责任人与时限 | 按规则补录并记录原因 |
覆盖率阈值由团队按版本风险约定，高风险版本可要求全部缺陷带关联，常规迭代可设定一个可接受比例并记录例外。关联缺失或错挂时，补录规则应写明由谁在什么时限内补齐、是否需要评审确认，避免补录动作本身无人跟踪。
当缺陷与用例的关联需要在工具中持续维护时，ONES 测试管理解决方案支持一键创建并关联缺陷，缺陷可关联至迭代，便于在版本维度汇总缺陷与回归情况；ONES TestCase 还支持自动生成测试报告与项目缺陷分布统计，可作为发布前核对的参考数据，报表字段与统计口径需按实际配置确认。需求覆盖率统计与需求追溯矩阵的建设属于需求追溯与覆盖管理范畴，跨对象变更的影响分析属于研发变更控制与影响分析范畴，本文聚焦从缺陷出发的关联与回归链路。
常见问题
缺陷关联用例时，只填用例编号不填执行记录ID可以吗？
不建议只填用例编号。同一个用例会在多个构建版本反复执行，只挂编号时，缺陷无法说明是哪一次执行暴露的问题，回归范围也难以界定。执行记录ID承载了执行时间、执行人和构建版本，缺陷通过它指向具体某次执行，再经由该记录指向用例，才能形成完整的追溯链路。如果团队当前只填用例编号，可以先把执行记录ID设为必填字段，从执行记录创建缺陷时自动带入。
用例级关联和步骤级关联应该选哪种？
两种粒度可以并存，选择取决于用例的失败特征。用例步骤少、失败点集中时，用例级关联落地快、维护成本低；复现路径长、同一条用例不同步骤可能暴露不同问题时，步骤级关联能更准确定位失败位置。建议在缺陷模板中约定哪些项目必填步骤级关联，避免同一团队内标准不一。初期可以从用例级起步，积累一段时间后再对高频失败用例启用步骤级关联。
开发修复后，测试怎么确定要回归哪些用例？
开发在提交修复时，在缺陷中标注改动涉及的模块、接口或功能点，并说明可能受影响的用例范围。测试据此圈定回归用例清单，补充关联到缺陷单。回归范围与开发标注的影响范围对应，而不是只回归发现缺陷的那一条用例。如果开发未标注影响范围，缺陷评审人或测试负责人应退回补充，避免回归范围靠口头约定。
发布前缺陷关联覆盖率达不到约定阈值怎么办？
先列出缺失关联的缺陷清单，逐条判断是补录关联还是评估放行。补录规则应写明由谁在什么时限内补齐、是否需要评审确认。高风险版本可要求全部缺陷带关联，常规迭代可设定一个可接受比例并记录例外。阈值由团队按版本风险约定，不宜直接套用统一数值；未达阈值时，发布核对记录中应体现缺失清单和放行判断依据。
缺陷关联链路和需求追溯是什么关系？
本文聚焦从缺陷出发的关联与回归链路：缺陷指向执行记录，执行记录指向用例，用例再指向所属需求或功能点，从而反查业务影响面。需求覆盖率统计与需求追溯矩阵的建设属于需求追溯与覆盖管理范畴，跨对象变更的影响分析属于研发变更控制与影响分析范畴。两者衔接的地方在于用例所属需求或功能点字段，该字段填写完整，缺陷才能反查到业务影响面。
