缺陷预防措施清单要能支撑“从原因到措施再到验证”的闭环，核心信息包括缺陷与原因来源、根因归类、预防措施描述、措施类型与责任角色、落地时点与载体、验证方式与通过标准、状态与关闭条件、复发监控。清单按“原因确认—措施定义—落地执行—效果验证—关闭归档”分阶段设置检查项，每项写明通过标准、证据和负责人，并把根因未确认、措施无验证方式、无责任人与时点列为阻断项。
要点总览（TL;DR）
- 缺陷预防措施清单的核心是支撑“原因确认—措施定义—落地执行—效果验证—关闭归档”的闭环，字段表回答填什么，分阶段检查表回答怎么判断合格。
- 必填字段包括缺陷编号、发现阶段与影响范围、原因分析记录、直接原因与根本原因、根因类别、措施描述、措施类型、覆盖缺陷类型、负责人与完成时间、落地载体、验证方式与通过标准、验证人、当前状态和关闭条件。
- 每项检查项都要有可核验的证据、提供人和确认人；证据缺失按阶段处理，原因确认缺证据不进入措施定义，验证缺数据不得标记为已验证。
- 阻断项包括根因未确认、措施与根因无对应、无负责人或完成时间、无验证方式与通过标准、验证未通过即关闭、落地载体缺失；四项完成条件同时满足才可关闭。
- 清单由缺陷处理人、模块负责人、质量或过程改进角色、验证人和评审人在不同时点分段使用，周期性复发复盘时回到原清单核对措施是否仍有效。
谁在什么时点使用这份清单
这份清单承接缺陷原因分析，输出可执行的预防措施与验证结论，在缺陷闭环中位于“原因已查清”之后、“措施排期”之前，并贯穿到措施上线后的效果验证。把使用角色和介入时点定清楚，清单才不会被当成缺陷关闭前的事后补录表。
缺陷处理人通常是清单的第一填写人，负责把缺陷编号、原因分析记录和初步措施填完整；模块负责人确认措施是否落在自己可控的设计或代码范围内，并承担落地责任；质量或过程改进角色关注根因归类是否准确、措施类型是否覆盖同类缺陷、是否存在跨模块的共性问题；评审人负责在措施排期前和验证结论出来后做两次确认。
| 角色 | 介入时点 | 该时点要完成的检查段 |
|---|---|---|
| 缺陷处理人 | 根因分析完成后 | 填写缺陷与原因来源、根因归类，提出初步预防措施 |
| 模块负责人 | 措施排期前 | 确认措施针对根因、可执行，认领负责人与完成时间 |
| 质量或过程改进角色 | 措施排期前、周期性复盘 | 审核措施类型与覆盖范围，识别跨模块共性问题 |
| 验证人 | 措施上线后 | 按验证方式与通过标准执行验证，记录验证结果 |
| 评审人 | 措施排期前、关闭前 | 确认阻断项清零、验证结论已记录，决定是否关闭 |
周期性复发复盘是容易被忽略的时点：同类缺陷在后续版本再次出现时，应回到原清单检查措施是否失效、覆盖范围是否不足，而不是重新开一张清单从零分析。
清单必填信息字段表
字段表回答“需要包含哪些信息”这一核心问题。建议把缺陷编号、根因归类、措施描述、负责人、完成时间、验证方式与通过标准设为必填，其余字段按团队实际情况选填，但选填字段一旦填写就要能核验。
| 字段名 | 填写要求 | 是否必填 | 示例 |
|---|---|---|---|
| 缺陷编号 | 关联原始缺陷记录，可回溯 | 必填 | BUG-2317 |
| 发现阶段与影响范围 | 写明在需求、开发、测试、上线哪个阶段发现，影响哪些功能或用户 | 必填 | 测试阶段发现，影响订单导出功能 |
| 原因分析记录链接 | 指向根因分析文档或讨论记录 | 必填 | 根因分析文档链接 |
| 直接原因 | 描述触发缺陷的具体条件 | 必填 | 导出字段为空时未做判空处理 |
| 根本原因 | 落到可改变的过程或设计点 | 必填 | 导出模板变更后缺少字段校验环节 |
| 根因类别 | 需求、设计、编码、测试、环境、流程等 | 必填 | 流程 |
| 预防措施描述 | 写清做什么、改哪里，避免只写“加强检查” | 必填 | 导出模板变更时增加字段完整性校验步骤 |
| 措施类型 | 防呆、检查项、流程调整、自动化校验、培训等 | 必填 | 检查项＋自动化校验 |
| 覆盖的缺陷类型 | 说明该措施能预防哪一类问题再次发生 | 必填 | 模板变更类导出异常 |
| 措施负责人与协同角色 | 明确主责人和配合人 | 必填 | 主责：模块负责人；协同：测试负责人 |
| 计划完成时间 | 具体日期，不用“尽快” | 必填 | 2025-06-30 |
| 落地载体 | 文档、流程、工具规则、评审项等具体位置 | 必填 | 导出流程文档第 3 节、评审检查单 |
| 验证方式 | 如何证明措施有效 | 必填 | 构造同类模板变更场景回归测试 |
| 通过标准 | 可判断的量化或明确条件 | 必填 | 回归用例全部通过，且连续两个版本无同类缺陷 |
| 验证人 | 与措施负责人分离 | 必填 | 测试负责人 |
| 当前状态 | 待定义、执行中、待验证、已验证、已关闭 | 必填 | 待验证 |
| 关闭条件 | 满足哪些条件才能关闭 | 必填 | 验证通过且证据已归档 |
| 复发监控方式 | 后续如何观察同类问题 | 选填 | 纳入月度缺陷分类统计 |
字段设计的关键是让每条措施都能回答三个问题：针对哪个根因、由谁在什么时间落到哪里、用什么证明有效。回答不了其中任何一个，这条措施就还不具备进入排期的条件。
分阶段检查项与通过标准
字段表定义填什么，检查表定义怎么判断填得合格。五个阶段按顺序推进，前一阶段未通过不进入下一阶段，避免措施在根因不清的情况下仓促上马。
| 阶段 | 检查项 | 通过标准 | 证据 | 负责人/检查时点 |
|---|---|---|---|---|
| 一、原因确认 | 根因是否落到可改变的过程或设计点 | 根因指向具体环节，能说明改动后同类缺陷可被拦截 | 根因分析记录 | 缺陷处理人，分析完成后 |
| 一、原因确认 | 根因是否有证据支撑 | 有日志、复现步骤、代码或流程记录佐证，非主观推测 | 复现记录、日志片段 | 缺陷处理人，分析完成后 |
| 二、措施定义 | 措施是否针对根因 | 措施与根因一一对应，能说清拦截路径 | 措施描述与根因对照 | 模块负责人，排期前 |
| 二、措施定义 | 措施是否可执行 | 写明具体动作和改动位置，不停留在原则性表述 | 措施描述、涉及文档或代码位置 | 模块负责人，排期前 |
| 二、措施定义 | 类型与覆盖范围是否明确 | 措施类型已选，覆盖的缺陷类型写清 | 字段表对应项 | 质量角色，排期前 |
| 三、落地执行 | 措施是否进入载体 | 已写入流程文档、评审项或工具规则，可在对应位置查到 | 文档链接、规则配置记录 | 措施负责人，计划完成时间前 |
| 三、落地执行 | 负责人与时间是否落实 | 主责人明确，完成时间具体到日期 | 字段表对应项 | 模块负责人，排期前 |
| 四、效果验证 | 验证方式与通过标准是否可执行 | 验证步骤可复现，通过标准可判断 | 验证方案 | 验证人，措施上线后 |
| 四、效果验证 | 验证结果是否记录 | 有验证数据或测试结果，结论明确为通过或不通过 | 测试报告、验证记录 | 验证人，验证完成时 |
| 五、关闭归档 | 关闭条件是否满足 | 必填字段完整、验证通过、证据已归档 | 清单全量记录 | 评审人，关闭前 |
| 五、关闭归档 | 是否纳入复发监控 | 已确定观察方式和观察周期 | 监控安排记录 | 质量角色，关闭时 |
以“导出字段为空未判空”为例：原因确认阶段要能指出模板变更后缺少校验环节，而不是停在“开发疏忽”；措施定义阶段对应增加字段完整性校验步骤，并说明能拦截模板变更类导出异常；落地执行阶段把校验步骤写进导出流程文档和评审检查单；效果验证阶段构造同类模板变更场景做回归；关闭归档阶段确认连续两个版本无同类缺陷后关闭。每个阶段的产物都能被下一个人直接检查。
证据留存与负责人分工
清单要可核验，就不能只靠口头确认。每类检查项都应有对应的证据类型、提供人和确认人，证据存放位置在措施定义阶段就确定，避免验证时临时找材料。
| 检查项 | 证据 | 提供人 | 确认人 | 留存位置 |
|---|---|---|---|---|
| 根因确认 | 原因分析记录、复现步骤、日志 | 缺陷处理人 | 模块负责人 | 缺陷关联文档 |
| 措施定义 | 措施描述、根因对照说明 | 模块负责人 | 质量角色 | 清单记录 |
| 落地执行 | 流程文档链接、规则配置截图、评审项更新记录 | 措施负责人 | 模块负责人 | 文档库或工具配置页 |
| 效果验证 | 测试结果、验证数据、回归记录 | 验证人 | 评审人 | 测试记录或验证报告 |
| 关闭归档 | 完整清单、验证结论、监控安排 | 清单维护人 | 评审人 | 归档目录 |
分工上，措施负责人对“措施是否真的落地”负责，验证人对“验证是否按标准执行”负责，评审人对“阻断项是否清零”负责，清单维护人负责字段完整和证据归档。证据更新时点跟随状态变化：措施进入载体时补落地证据，验证完成时补验证结果，关闭时补齐归档材料。
证据缺失时按阶段处理：原因确认阶段缺证据，退回补充分析，不进入措施定义；落地执行阶段缺载体证据，视为措施未完成，完成时间顺延并记录原因；验证阶段缺验证数据，不得标记为已验证。证据缺失本身要写进清单备注，作为复盘时的过程问题。
当措施、负责人、完成时间和验证状态需要在工作项与文档之间流转时，可以把缺陷作为工作项跟踪，把根因分析记录和措施清单放在关联文档中，让状态变化和证据链接留在同一处。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录修复情况，也能统计缺陷状态分布；ONES Wiki 支持文档关联任务并插入工作项列表，便于把清单与缺陷记录放在一起查看；ONES TestCase 支持未通过用例快速创建缺陷任务，并在测试与研发团队间流转。具体字段与状态配置以实际产品版本为准。
阻断项与完成条件
阻断项用于防止措施空转。出现以下任一情形，清单不得进入下一阶段，也不得关闭：
- 根因未确认，或根因停留在“人为疏忽”等不可改变表述；
- 措施与根因无对应关系，说不清拦截路径；
- 无措施负责人，或完成时间只写“尽快”；
- 无验证方式，或通过标准无法判断；
- 验证未通过即标记关闭；
- 落地载体缺失，措施只存在于清单文字中。
整份清单的完成条件为：全部必填字段完整；阻断项清零；验证结论已记录且为通过；措施已进入对应载体并可查到。四项同时满足才可关闭，缺一项即视为未完成。
未通过时的退回规则按阶段设定：原因确认未通过退回缺陷处理人补充分析；措施定义未通过退回模块负责人修改措施；落地执行未通过退回措施负责人补齐载体；效果验证未通过则重开措施，调整方案后重新走落地与验证，原验证记录保留作为过程证据。退回和重开都要记录次数与原因，便于识别反复卡住的环节。
周期性复查的触发条件包括：同类缺陷在后续版本再次出现；措施覆盖的模块发生较大变更；季度或月度缺陷分类统计中同类问题占比上升。触发后回到清单核对措施是否仍有效、覆盖范围是否足够，必要时新增措施并重新验证，而不是直接沿用原结论。
常见问题
缺陷预防措施清单和缺陷记录、根因分析报告是什么关系？
三者是上下游关系：缺陷记录保存问题现象和修复过程，根因分析报告回答“为什么会发生”，预防措施清单则把根因转化为可执行、可验证的措施并跟踪到关闭。清单里的缺陷编号和原因分析记录链接就是用来回溯上游材料的，缺少这两项，措施容易脱离原始问题。
小团队也需要把字段表里的所有必填项都填完吗？
建议保留全部必填字段，但可以简化填写深度。例如发现阶段与影响范围可以只写一句话，验证方式可以是一次回归测试。字段的价值在于让每条措施都能回答三个问题：针对哪个根因、由谁在什么时间落到哪里、用什么证明有效。字段数量可以随团队规模调整，这三个问题不能省。
措施已经上线，但短期内没有同类缺陷出现，能否直接关闭？
不能仅凭“没有复发”关闭。关闭需要同时满足：必填字段完整、阻断项清零、验证结论已记录且为通过、措施已进入对应载体并可查到。如果验证方式本身是观察一段时间，应把观察周期和判断标准写进通过标准，到期后按记录结论关闭，而不是凭感觉放行。
周期性复查发现原措施失效，应该修改原清单还是新开一张？
建议回到原清单核对并补充记录，保留原措施和原验证结论作为过程证据，再新增调整后的措施并重新走落地与验证。这样能看出措施为什么失效、覆盖范围哪里不足。只有原缺陷与当前问题确实无关时，才另开新清单。
清单里的措施、负责人和验证状态如何在工具中流转和留痕？
可以把缺陷作为工作项跟踪，把根因分析记录和措施清单放在关联文档中，让状态变化和证据链接留在同一处。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录修复情况，也能统计缺陷状态分布；ONES Wiki 支持文档关联任务并插入工作项列表；ONES TestCase 支持未通过用例快速创建缺陷任务，并在测试与研发团队间流转。具体字段与状态配置以实际产品版本为准。
