缺陷根因复核记录表用于把一次缺陷分析从“口头结论”变成可追溯的记录。表格按“缺陷基本信息—根因判定—复核结论—预防措施—验证关闭”五段组织：先锁定缺陷对象与复现条件，再写清直接原因、根本原因及判定依据，由复核人给出确认或推翻的结论，随后登记预防措施、责任人与验证结果，最后记录关闭条件。填写时，每项根因结论都要能追溯到证据，复核人与原分析人分开署名。缺陷记录与复核文档需要在工作项和文档中流转时，ONES可承载缺陷工作项与复核文档的协作。
要点总览（TL;DR）
- 记录表按“缺陷基本信息—根因判定—复核结论—预防措施—验证关闭”五段组织，单条缺陷一行，可直接复制到文档或表格工具使用。
- 缺陷编号、标题、发现阶段、严重程度、复现条件、直接原因、根本原因、判定依据、原分析人、复核人、复核结论为必填；关联需求、影响版本、原因分类按情况填写。
- 复核人与原分析人必须分开署名，判定依据要与根因描述对应，预防措施要针对根本原因并落到可检查的动作。
- 字段暂缺时标注“待补”并写明补填时限；关闭前必须补齐验证结果，否则记录保持未关闭状态。
- 模板按团队缺陷量和项目特点增删字段，记录版本与变更内容，并定期抽查判定依据、署名分离和验证结果三项质量。
可复制空白模板：缺陷根因复核记录表
下面这张表可以直接复制到文档或表格工具中使用。整表分五段，每段先列字段名，再留出填写位置；单条缺陷占一行，多条缺陷向下追加行即可批量登记。表格中的“（留空）”表示该处由填表人按实际内容填写。
| 段落 | 字段名 | 填写位置 | 留空方式 |
|---|---|---|---|
| 一、缺陷基本信息 | 缺陷编号 | 首列 | （留空） |
| 缺陷标题 | 第二列 | （留空） | |
| 发现阶段 | 第三列 | （留空） | |
| 严重程度 | 第四列 | （留空） | |
| 复现条件 | 第五列 | （留空） | |
| 关联需求/影响版本 | 第六列 | （留空，选填） | |
| 二、根因分析 | 直接原因 | 第七列 | （留空） |
| 根本原因 | 第八列 | （留空） | |
| 原因分类 | 第九列 | （留空） | |
| 判定依据 | 第十列 | （留空） | |
| 三、复核结论 | 原分析人 | 第十一列 | （留空） |
| 复核人 | 第十二列 | （留空） | |
| 复核方式 | 第十三列 | （留空） | |
| 复核结论 | 第十四列 | （留空） | |
| 四、预防措施 | 预防措施 | 第十五列 | （留空） |
| 责任人 | 第十六列 | （留空） | |
| 计划完成时间 | 第十七列 | （留空） | |
| 五、验证与关闭 | 验证方式 | 第十八列 | （留空） |
| 验证结果 | 第十九列 | （留空） | |
| 关闭条件 | 第二十列 | （留空） | |
| 关闭日期 | 第二十一列 | （留空） |
如果团队习惯纵向填写，也可以把上表转成“字段名—填写内容”的两列式单条记录卡，每条缺陷一张卡。两种排布包含的字段相同，选一种固定下来，避免同一团队出现两套格式。
字段说明：每个字段记录什么、依据什么填
字段说明的作用是让填表人不靠猜测完成记录。下面按五段逐项解释含义与填写口径，模板、说明和示例使用同一套字段名。
缺陷基本信息类字段
- 缺陷编号：填写缺陷在缺陷库或工作项系统中的唯一标识，便于后续检索和关联。编号一经分配不再改动。
- 缺陷标题：用一句话描述“在什么场景下出现什么异常”，例如“订单提交后金额显示为0”。标题写现象，不写原因。
- 发现阶段：填写缺陷被发现的环节，如需求评审、开发自测、测试执行、上线后。发现阶段影响后续同类缺陷的排查范围。
- 严重程度：按团队既有分级填写，如致命、严重、一般、轻微。分级标准以团队质量规范为准，不在本表内另立一套。
- 复现条件：写清环境、数据、操作步骤和出现频率。复现条件是根因判定的前提，写“偶现”时要补充出现次数或触发线索。
根因类字段
- 直接原因：写导致缺陷出现的直接技术环节，例如某段判断逻辑缺少边界校验、某接口返回字段为空未处理。
- 根本原因：写直接原因背后的流程或管理环节，例如需求未明确边界值、代码评审未覆盖该分支、测试用例缺少该场景。根本原因要落到可改进的环节。
- 原因分类：按团队约定归类，如需求类、设计类、编码类、测试类、环境类。分类用于统计和预防措施归集。
- 判定依据：写支撑根因结论的证据，如日志片段、代码提交记录、复现截图、评审记录。判定依据要与根因描述对应，不能只写“经分析确认”。
复核类字段
- 原分析人：填写完成根因分析的人，对分析内容负责。
- 复核人：填写独立复核的人，与原分析人分开署名，不能是同一人。
- 复核方式：填写复核采用的方式，如查阅证据、重新复现、组织评审会。
- 复核结论：给出明确判断，如“确认根因”“根因不成立，退回补充”“部分确认，需补充证据”。结论要能对应到具体字段。
预防与验证类字段
- 预防措施：写针对根本原因的具体动作，如补充边界值用例、在评审清单中增加该检查项、修改接口校验规则。措施要可执行、可检查。
- 责任人：填写措施执行人，一项措施对应一名责任人。
- 验证方式：写如何确认措施生效，如回归测试、抽查评审记录、观察一段时间内的同类缺陷数量。
- 验证结果：填写验证后的实际结果，如“回归通过”“连续两个版本未复现”。结果与验证方式一一对应。
必填与选填：哪些字段缺失会导致复核无效
复核是否有效，取决于关键字段是否齐全。缺了缺陷对象、根因描述或复核署名，记录就无法支撑结论，应视为复核未完成。
| 字段 | 填写要求 | 缺失影响 |
|---|---|---|
| 缺陷编号、缺陷标题 | 必填 | 无法定位缺陷对象，记录失去追溯基础 |
| 发现阶段、严重程度 | 必填 | 无法判断影响范围与排查优先级 |
| 复现条件 | 必填 | 根因结论缺少验证前提 |
| 直接原因、根本原因 | 必填 | 复核无对象，结论无法成立 |
| 判定依据 | 必填 | 根因结论不可追溯，复核流于形式 |
| 原分析人、复核人 | 必填，且为不同人 | 缺少责任主体，复核独立性不成立 |
| 复核结论 | 必填 | 无法判断分析是否通过 |
| 预防措施、责任人 | 必填（结论为确认时） | 缺陷可能再次发生 |
| 验证方式、验证结果 | 必填（关闭前） | 无法确认措施生效，不能关闭 |
| 关联需求、影响版本 | 选填 | 影响同类缺陷排查范围，不影响单条复核有效性 |
| 原因分类 | 选填（建议填） | 影响统计归集，不影响单条结论 |
| 同类缺陷排查范围 | 选填 | 适用于批量或重复出现的缺陷 |
字段暂缺时，在对应单元格标注“待补”并写明补填时限，例如“待补，三个工作日内”。复核结论为“确认”但预防措施尚未确定的，可先记录复核结论，预防措施栏标注“待定”并约定补填日期；关闭前必须补齐验证结果，否则记录保持未关闭状态。
填写示例：一条完整缺陷的复核记录
以下示例为演示情景，用于说明各字段的写法，数据为虚构。示例覆盖模板全部必填字段，根因写到可验证的具体环节，复核结论与预防措施、验证结果前后对应。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | BUG-2024-0317 |
| 缺陷标题 | 订单提交后应付金额显示为0 |
| 发现阶段 | 测试执行 |
| 严重程度 | 严重 |
| 复现条件 | 测试环境，购物车含两件促销商品并使用满减券，连续操作5次出现4次 |
| 关联需求/影响版本 | 需求REQ-118；影响版本V2.3.0 |
| 直接原因 | 满减计算接口在优惠金额大于商品小计时返回负值，前端未做下限处理，直接显示为0 |
| 根本原因 | 需求文档未定义优惠金额超过商品小计时的处理规则，开发按默认逻辑实现，评审和测试用例均未覆盖该边界 |
| 原因分类 | 需求类 |
| 判定依据 | 接口日志显示返回金额为-12.5；代码提交记录显示未做下限判断；需求文档对应章节无该规则描述 |
| 原分析人 | 张明（开发） |
| 复核人 | 李华（测试负责人） |
| 复核方式 | 查阅日志与代码提交记录，重新复现两次 |
| 复核结论 | 确认根因，需求边界缺失成立 |
| 预防措施 | 在需求评审清单中增加“优惠计算边界值”检查项；补充满减金额超过商品小计的测试用例 |
| 责任人 | 王芳（需求）、李华（测试） |
| 计划完成时间 | 2024-04-10 |
| 验证方式 | 回归测试该场景，并抽查下一次需求评审记录 |
| 验证结果 | 回归通过，金额显示正常；评审清单已更新并在一项新需求中执行 |
| 关闭条件 | 预防措施全部完成且验证通过 |
| 关闭日期 | 2024-04-12 |
这条记录中，复核结论“确认根因”对应判定依据中的日志和代码记录，预防措施针对根本原因中的需求边界缺失，验证结果又回到同一场景确认修复。三处内容互相呼应，是填写时应当保持的一致性。
调整与维护：让模板适配团队并持续可用
模板落地后需要按团队实际情况调整，否则字段过多会增加填写负担，字段过少又无法支撑复核。调整时把握一条原则：影响根因判定和复核有效性的字段保留，只服务统计或参考的字段按需增删。
按缺陷类型或项目规模取舍字段
- 缺陷量较小的团队可合并“发现阶段”和“严重程度”为一列备注，保留根因、判定依据、复核结论等核心字段。
- 涉及多版本并行的项目，建议保留“影响版本”并设为必填，便于判断修复范围。
- 重复出现的同类缺陷，增加“同类缺陷排查范围”字段，记录已排查的模块或场景。
- 安全或合规相关缺陷，可增加“影响评估”字段，但不宜把所有缺陷都套用该字段。
模板版本与变更记录
模板每次调整都应记录版本号、变更内容和生效日期，例如“V1.1，新增同类缺陷排查范围字段，2024-05-01生效”。变更记录附在模板文件末尾或单独的说明页，历史记录保留原版本字段口径，避免新旧记录无法对照。
定期抽查填写质量
建议按季度抽查一批已关闭的复核记录，检查三项内容：判定依据是否与根因描述对应、复核人与原分析人是否分开、预防措施是否有验证结果。抽查中发现长期无人填写的字段，评估其是否仍有必要保留；发现反复标注“待补”的字段，检查是填写要求不清还是流程环节缺失。抽查结果用于下一版模板调整，形成“使用—抽查—修订”的循环。
当缺陷记录、复核结论和预防措施需要在不同角色之间流转时，可以把缺陷作为工作项管理，把复核记录作为关联文档维护，让复核人、责任人和验证结果在同一处可查。ONES的缺陷管理与文档协作能力可以承载这类流转，具体配置按团队现有流程设定。
常见问题
复核人和原分析人能否由同一人兼任？
不建议兼任。复核的作用是对根因结论做独立判断，同一人既分析又复核，结论缺少第二方视角，记录也难以支撑后续追溯。团队人手紧张时，可以请同组其他角色或相邻模块的负责人担任复核人，复核方式写明查阅证据或重新复现即可，不必组织正式评审会。
缺陷暂时无法复现，复现条件一栏怎么写？
复现条件仍要填写，写清已知的环境、数据、操作路径和出现次数，例如“生产环境，某类订单，用户反馈3次，本地未复现”。同时把“未能稳定复现”作为判定依据的一部分记录下来，说明根因结论是基于日志或代码推断。这样复核人能看到结论的证据强度，避免把推断当成已确认事实。
复核结论为“根因不成立”时，记录表还要继续填吗？
要继续填。复核结论写明“根因不成立，退回补充”，并在判定依据或备注中说明退回原因，例如证据与根因描述不对应、缺少日志支撑。原分析人补充后重新提交复核，记录保留前后两轮结论，便于查看分析过程。退回的记录不计入已关闭，预防措施栏暂不填写。
预防措施由多个责任人分别执行时怎么登记？
一项措施对应一名责任人。如果根本原因对应多条措施，可以拆成多行登记，每行写一条措施、一名责任人和一个计划完成时间；也可以在同一单元格内按“措施—责任人—时间”逐条列出，但每条措施都要能单独检查完成情况。验证结果按措施逐条对应，避免出现部分完成却整体标记为已验证的情况。
记录表放在文档里还是缺陷工作项里更合适？
取决于团队现有流程。缺陷量不大、复核以文档评审为主时，用文档维护整表更便于批量查看和版本留存；缺陷在工作项系统中流转时，把根因、复核结论和预防措施作为工作项字段或关联文档维护，能让复核人、责任人和验证结果在同一处可查。ONES的缺陷管理与文档协作能力可以承载这类流转，具体配置按团队流程设定。两种方式选一种固定下来，避免同一缺陷出现两份口径不同的记录。
