缺陷根因复核是在缺陷修复前后，对“为什么会发生”这一判断做一次有证据支撑的再确认。它要解决的问题是：初步分析给出的原因往往停留在表面，缺少独立验证，导致同类问题反复出现。本文按触发条件、执行步骤、角色分工、记录字段和完成检查展开，适用于已经开展缺陷分析、希望把结论做实的研发团队。复核的最终输出是一份可追溯的根因复核记录。
要点总览（TL;DR）
- 先按严重度、复发情况、生产逃逸、客户影响四个维度设定触发线，把缺陷分为必做复核、抽样复核和免复核三类，避免全量复核拖慢节奏。
- 复核按五个动作推进：整理证据包、提出并检验根因假设、交叉验证、形成预防动作、记录结论并回写缺陷单，每步都有明确输入和完成标志。
- 根因结论要区分直接原因、引入原因和漏检原因三层，分别对应代码修复、流程检查点和用例补强三类预防动作。
- 复核人由非原分析人担任，模块负责人确认预防动作排期，质量或流程角色跟踪关闭与效果验证，角色可以合并但复核独立性要保留。
- 判断复核是否到位，看结论是否有证据支撑、复核人是否独立、预防动作是否有责任人和验证时点、结论能否在缺陷单中检索到。
复核先定对象：哪些缺陷必须做根因复核
根因复核与普通缺陷分析的区别在于多了一道独立再确认。普通分析由处理人给出初步判断，复核则由非原分析人依据证据验证这个判断是否成立。两者都指向“为什么发生”，复核的价值在于降低单人判断的偏差，并把结论固化为可追溯的记录。因此复核不必覆盖全部缺陷，先定范围才能保证节奏。
触发条件建议从四个维度设定：严重度、复发情况、是否逃逸到生产、客户影响范围。严重度高的缺陷一旦判断错误，修复成本和外溢风险都大；复发缺陷说明上一次的原因判断或预防动作没有生效；逃逸到生产说明测试环节存在漏检；涉及客户投诉或数据问题的缺陷需要对外可交代。四个维度可以单独触发，也可以组合加权。
按触发结果把缺陷分为三类：必做复核、抽样复核、免复核。必做复核对应高严重度、复发、生产逃逸、客户影响中任一项命中的缺陷；抽样复核适用于中等严重度、同模块集中出现但单条影响有限的缺陷，按批次或周期抽取一定比例；免复核适用于低严重度、原因明确且已有成熟处理方式的缺陷，例如文案错误、配置项遗漏。
复核启动时点有两种选择。修复前做假设复核，适合原因不明、修复方案存在分歧的缺陷，能在动手改代码前纠正方向；修复后做结论复核，适合原因较清晰但需要确认预防动作是否到位的缺陷。团队应在缺陷单上标注采用哪种时点，避免复核悬空。
| 判定维度 | 必做复核 | 抽样复核 | 免复核 |
|---|---|---|---|
| 严重度 | 高（阻断主流程、影响核心数据） | 中 | 低 |
| 复发情况 | 同一根因或同模块重复出现 | 偶发但趋势上升 | 首次出现且原因明确 |
| 生产逃逸 | 已逃逸到生产环境 | 测试后期才发现 | 测试阶段正常拦截 |
| 客户影响 | 有客户投诉、数据错误或对外可见 | 内部用户感知 | 无外部感知 |
| 启动时点 | 修复前假设复核为主 | 修复后结论复核 | 不启动 |
复核的五个动作：从假设到预防措施
复核按五个动作推进，每个动作都有明确输入、输出和完成标志。动作之间是递进关系，前一步的输出是后一步的输入，跳过任何一步都会让结论失去支撑。
动作一：整理证据包
输入是缺陷单、复现步骤、相关日志、代码变更记录、关联需求与测试用例。做法是把这些材料归集到一处，标注时间线和版本信息，确保复核人不用再向多方索要。输出是一份完整的证据包，完成标志是复现步骤可被他人独立执行、日志能定位到具体请求或事务、变更记录能对应到引入版本。
动作二：提出并检验根因假设
输入是证据包。做法是用原因分类框架把假设拆成三层：直接原因指触发缺陷的那次具体错误；引入原因指这个错误是在哪个环节、哪次变更中被带进来的；漏检原因指为什么测试、评审或监控没有拦住它。每个假设都要写出对应的验证证据，例如“缺少输入校验”需要指向具体代码位置，“用例未覆盖边界”需要指向用例清单的缺口。输出是根因假设列表，完成标志是每条假设都有证据指向或明确标注待验证。
动作三：交叉验证
输入是根因假设列表和证据包。做法是由非原分析人逐条对照证据，确认假设成立、推翻假设或补充新假设。复核人可以要求补充日志、重跑复现步骤或查看变更评审记录。输出是验证结论，完成标志是每条假设都有“成立、推翻、证据不足”的明确判定，证据不足的假设不能进入最终结论。
动作四：形成预防动作
输入是验证后的根因结论。做法是按原因类型匹配动作：直接原因对应代码修复，引入原因对应变更流程或评审检查点，漏检原因对应补充用例、增加边界测试或调整监控告警。每个动作要指定责任人和验证时点，验证时点可以是下一个迭代结束、下一次回归测试或某个时间窗口后的复发观察。输出是预防动作清单，完成标志是每条动作都有责任人、完成时间和可观察的验证方式。
动作五：记录结论并回写缺陷单
输入是前四步的全部产出。做法是把根因结论、证据摘要、预防动作和复核人签署写入复核记录，并在缺陷单上更新复核状态和记录入口。输出是可追溯的复核记录，完成标志是缺陷单能直接检索到复核结论，且预防动作在任务或工作项中有对应跟踪项。
在缺陷工作项中承载这套流程时，ONES Project 支持缺陷跟踪管理，可统计缺陷状态分布，沉淀问题和经验；缺陷可一键提交至对应项目或迭代，记录和跟踪修复情况。ONES TestCase 支持未通过用例快速创建缺陷任务，并让用例与需求、任务关联，测试计划与迭代关联，便于在复核时回溯漏检环节的用例覆盖情况。复核记录的具体字段配置需结合团队实际工作项设置确定。
角色分工与交付物：谁复核、谁确认、谁跟踪
复核最容易失效的方式是原分析人自己复核自己。角色分工的核心是让提出假设的人和验证假设的人分开，让确认排期的人和跟踪关闭的人分开。
缺陷分析人负责提交证据包与初步根因假设，交付物是证据包和假设列表，交接时点是复核启动时。复核人由非原分析人担任，负责逐条验证假设并签署结论，交付物是验证结论和复核记录签署，交接时点是交叉验证完成后。模块负责人确认预防动作的可行性与排期，交付物是动作排期确认，交接时点是预防动作形成后。质量或流程角色跟踪预防动作关闭与效果验证，交付物是关闭状态和复发观察结果，交接时点是验证时点到期时。
| 角色 | 主要职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 缺陷分析人 | 归集证据、提出初步根因假设 | 证据包、根因假设列表 | 复核启动时 |
| 复核人（非原分析人） | 对照证据验证假设、签署结论 | 验证结论、复核记录签署 | 交叉验证完成后 |
| 模块负责人 | 确认预防动作可行性与排期 | 动作排期确认 | 预防动作形成后 |
| 质量或流程角色 | 跟踪动作关闭与效果验证 | 关闭状态、复发观察结果 | 验证时点到期时 |
小团队中复核人可由同模块其他开发或测试担任，模块负责人与质量角色可以合并，但复核人与原分析人分离这一条应保留。角色合并时要在复核记录中写明实际承担人，避免责任模糊。
一个复核示例：从“操作失误”追到漏检环节
以下为演示情景，用于说明复核的推理路径，不代表真实案例。
某功能上线后出现数据错乱缺陷，用户提交的表单在特定字符组合下写入异常。初步结论是“用户操作失误，输入了非法字符”。复核启动后，复核人先整理证据包：复现步骤显示按正常界面操作即可触发，日志显示写入前未做字符过滤，变更记录显示该表单校验逻辑在上一次重构中被简化，用例清单中没有该字符组合的边界用例。
复核人逐条对照假设：直接原因假设为“输入未校验”，证据是代码中校验分支被移除，判定成立；引入原因假设为“重构时简化校验”，证据是变更记录对应提交，判定成立；漏检原因假设为“用例未覆盖边界字符”，证据是用例清单缺口，判定成立。原“操作失误”结论被推翻，因为复现路径不依赖异常操作。
最终根因结论为：直接原因是输入校验缺失，引入原因是重构时移除校验分支且未在评审中识别，漏检原因是用例缺少边界字符覆盖。预防动作包括恢复并加固校验逻辑、在重构评审清单中增加校验类变更检查项、补充边界字符用例并纳入回归集，分别指定责任人和验证时点。该示例适用于功能缺陷的原因复核，不适用于服务事件根因分析，后者涉及故障链和应急响应，流程与角色不同。
复核记录写什么：字段与填写要求
复核记录是复核的正式产出，字段设计要保证结论可追溯、可统计。字段不必多，但每个字段都要能回答一个问题。
| 字段 | 填写要求 |
|---|---|
| 缺陷标识 | 缺陷单编号与标题，确保可回链 |
| 触发条件 | 命中的判定维度，如高严重度、复发、生产逃逸 |
| 复核时点 | 修复前假设复核或修复后结论复核，注明日期 |
| 根因假设列表 | 每条假设对应证据来源，标注成立、推翻或证据不足 |
| 根因分类结论 | 分别写明直接原因、引入原因、漏检原因 |
| 预防动作 | 动作内容、类型（代码、用例、流程、检查点）、责任人、验证时点 |
| 关闭状态 | 未开始、进行中、已验证关闭，附验证结果 |
| 复核人与确认记录 | 复核人姓名、签署时间，与原分析人分离 |
填写时注意两点：根因分类结论要三层都写，只写直接原因会让预防动作停留在修复层面；预防动作的验证时点要具体到可检查的时间或事件，例如“下个迭代回归测试通过”或“上线后两周无复发”。记录形成后回写缺陷单，使缺陷单成为复核结论的检索入口。
完成检查：复核做没做到位怎么判断
判断一次复核是否通过，可以按以下清单逐项核对。全部满足视为通过，任一项不满足则退回补充。
- 根因结论有证据支撑：每条结论都能指向日志、代码变更、复现记录或用例缺口，不依赖经验判断。
- 复核人独立于原分析人：复核记录中复核人与分析人不同，角色合并时已注明实际承担人。
- 根因分类完整：直接原因、引入原因、漏检原因三层均有结论，缺失层已说明理由。
- 预防动作可执行：每条动作有责任人、完成时间和可观察的验证方式。
- 结论已回写缺陷单：缺陷单可检索到复核记录，状态字段已更新。
- 复发缺陷已纳入复核：同一根因或同模块重复出现的缺陷已触发复核，而非按普通缺陷处理。
- 验证时点已跟踪：到期动作有关闭状态或复发观察结果，未关闭动作有延期说明。
这套检查可以按季度抽样执行，统计通过率和常见缺口，作为改进复核流程的依据。复核做到位的标志是：下一次同类缺陷出现时，团队能快速判断它是否属于已知根因，以及既有预防动作为何没有拦住。
常见问题
缺陷根因复核和普通缺陷分析有什么实质区别？
普通缺陷分析由处理人给出初步判断，重点是把缺陷修好；根因复核是在这个判断基础上，由非原分析人依据日志、代码变更、复现记录和用例清单再做一次独立验证。区别体现在三点：复核人独立于原分析人，结论必须指向具体证据，输出是一份可追溯的复核记录而非口头讨论。复核不替代修复，它解决的是原因判断是否可靠、预防动作是否落地的问题。
团队缺陷量很大，全量做根因复核不现实，怎么控制范围？
建议先设触发线再分流。高严重度、同一根因复发、已逃逸到生产、有客户投诉或数据错误的缺陷列为必做复核；中等严重度、同模块集中出现但单条影响有限的缺陷按批次或周期抽样；低严重度且原因明确、已有成熟处理方式的缺陷免复核。触发线要写进团队约定并定期回看，如果抽样复核中反复发现同类根因，应把对应场景上调为必做。
复核时原分析人和复核人对根因判断不一致，怎么处理？
以证据为准，不以职位或资历定结论。做法是把分歧点拆到假设层面，逐条对照证据判定成立、推翻或证据不足。证据不足的假设不能进入最终结论，需要补充日志、重跑复现步骤或查看变更评审记录后再判。如果补充证据后仍无法定论，可在复核记录中标注“证据不足”并说明已尝试的验证方式，同时把该缺陷列入后续观察，避免用猜测填补结论。
预防动作定了责任人和验证时点，到期没关闭怎么办？
到期未关闭的动作要有延期说明，写清未完成原因、新的完成时间和是否影响复发观察。质量或流程角色在验证时点到期时核对关闭状态，对延期动作定期汇总。如果同一类预防动作反复延期，说明排期确认环节没有做实，需要模块负责人在动作形成时就确认可行性，而不是等到期后再补。验证时点建议绑定可检查的事件，例如下个迭代回归测试通过、上线后两周无复发。
复核记录放在缺陷单里还是单独建文档？
优先让复核结论能回链到缺陷单，保证检索入口唯一。字段可以按缺陷标识、触发条件、复核时点、根因假设与验证证据、根因分类结论、预防动作与责任人及验证时点、关闭状态、复核人签署来设置。在缺陷工作项中承载时，ONES Project 支持缺陷跟踪管理，可统计缺陷状态分布，沉淀问题和经验；缺陷可一键提交至对应项目或迭代，记录和跟踪修复情况。复核记录的具体字段配置需结合团队实际工作项设置确定。
漏检原因一定要写吗，有些缺陷看起来就是代码写错了？
建议三层都写。只写直接原因，预防动作容易停留在修代码，同类问题换个位置还会出现。漏检原因回答的是“为什么测试、评审或监控没拦住”，对应的动作是补用例、加边界测试或调整告警，这类动作才能降低复发。如果确实判断不存在漏检环节，也要在记录中说明理由，例如该场景无法在测试环境复现且已有监控覆盖，而不是直接留空。
