缺陷提交检查清单的价值在于让提交人逐项核对，减少“描述太笼统、步骤复现不了、日志缺失、敏感信息外泄”这几类返工。下面这份模板按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组组织，敏感信息处理单独成块，可直接复制到缺陷单、评审表或团队文档中使用。
要点总览（TL;DR）
- 模板按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组核对项组织，敏感信息处理单独成块，可直接复制到缺陷单或评审表。
- 必填与选填以“缺该项是否会导致缺陷无法复现或无法定位”为判断依据；敏感信息处理组默认全部必填，不随项目类型放宽。
- 敏感信息处理核对项按识别、脱敏、替换、授权、复核五步设计，核对结果统一填“通过/不通过/不适用”，不适用时需写明理由。
- 模板头部保留版本号、生效日期、责任人和变更摘要，每季度复核一次，调整后用一条近期缺陷重填验证再发布。
可复制空白检查清单模板
模板采用“核对项—填写内容—必填/选填—核对结果”四列结构。核对结果统一填“通过 / 不通过 / 不适用”，不通过时在备注列写明原因。复制时保留表头，按缺陷实际情况逐行填写。
第一组：缺陷描述
| 编号 | 核对项 | 填写内容 | 必填/选填 | 核对结果 |
|---|---|---|---|---|
| D1 | 缺陷标题 | 一句话说明“什么功能在什么条件下出了什么问题” | 必填 | |
| D2 | 问题现象 | 实际看到的结果，含报错文案或异常表现 | 必填 | |
| D3 | 预期结果 | 按需求或常识应当出现的结果 | 必填 | |
| D4 | 影响范围 | 受影响的用户、模块或数据范围 | 选填 | |
| D5 | 发现时间与发现人 | 首次发现的时间点和提交人 | 必填 |
第二组：复现步骤
| 编号 | 核对项 | 填写内容 | 必填/选填 | 核对结果 |
|---|---|---|---|---|
| R1 | 前置条件 | 账号角色、数据状态、开关配置等起始条件 | 必填 | |
| R2 | 操作步骤 | 按顺序编号的操作动作，一步一个动作 | 必填 | |
| R3 | 复现频率 | 必现、偶现或特定条件下出现，偶现需注明尝试次数 | 必填 | |
| R4 | 最小复现路径 | 去掉无关步骤后的最短操作序列 | 选填 |
第三组：环境信息
| 编号 | 核对项 | 填写内容 | 必填/选填 | 核对结果 |
|---|---|---|---|---|
| E1 | 产品版本或构建号 | 出现问题的版本、分支或构建标识 | 必填 | |
| E2 | 运行环境 | 测试/预发/生产，以及操作系统、浏览器或客户端版本 | 必填 | |
| E3 | 账号与权限 | 复现所用账号的角色与权限范围（账号本身需脱敏） | 必填 | |
| E4 | 网络与设备 | 网络类型、设备型号等与问题相关的条件 | 选填 |
第四组：日志与证据
| 编号 | 核对项 | 填写内容 | 必填/选填 | 核对结果 |
|---|---|---|---|---|
| L1 | 日志片段 | 与问题时间点对应的日志，标注时间戳 | 必填 | |
| L2 | 截图或录屏 | 能体现问题现象的画面，敏感区域需先处理 | 必填 | |
| L3 | 请求与响应 | 相关接口的请求参数与返回结果（需脱敏） | 选填 | |
| L4 | 关联记录 | 相关需求单、用例或其他缺陷的编号 | 选填 |
第五组：敏感信息处理（单独成块）
| 编号 | 核对项 | 填写内容 | 必填/选填 | 核对结果 |
|---|---|---|---|---|
| S1 | 敏感信息识别 | 列出缺陷内容中涉及的账号、手机号、身份证号、地址、密钥、内部域名等 | 必填 | |
| S2 | 脱敏处理 | 说明采用的脱敏方式，如掩码、截断、打码，并确认处理后的内容 | 必填 | |
| S3 | 替换与示例化 | 用虚构值替换真实数据，注明“示例数据” | 必填 | |
| S4 | 授权确认 | 确需保留原始信息时，记录授权人、授权范围与用途 | 必填 | |
| S5 | 复核签署 | 由第二人复核脱敏结果并记录复核人 | 必填 |
字段说明：每个核对项要填什么
字段说明的作用是统一填写口径，避免同一核对项在不同人手里填出不同颗粒度。下表逐项解释含义，与上面的空白模板一一对应。
缺陷描述组
| 编号 | 字段含义 | 填写口径 |
|---|---|---|
| D1 | 缺陷标题 | 写清功能点、触发条件和异常结果，避免只写“页面报错”这类无法定位的标题 |
| D2 | 问题现象 | 照实记录看到的内容，报错文案原样摘录，不做主观归纳 |
| D3 | 预期结果 | 引用需求文档条款或业务规则，说明依据来源 |
| D4 | 影响范围 | 说明受影响的用户群体、功能模块或数据条数，无法判断时写“待评估” |
| D5 | 发现时间与发现人 | 记录首次发现的时间，便于与日志时间对齐 |
复现步骤组
| 编号 | 字段含义 | 填写口径 |
|---|---|---|
| R1 | 前置条件 | 写清起始状态，包括账号角色、已有数据、功能开关 |
| R2 | 操作步骤 | 一步一个动作，使用“点击、输入、提交”等可执行动词 |
| R3 | 复现频率 | 偶现问题注明尝试次数与出现次数，如“10 次出现 3 次” |
| R4 | 最小复现路径 | 在完整步骤基础上删减无关操作，保留能触发问题的最短序列 |
环境信息组
| 编号 | 字段含义 | 填写口径 |
|---|---|---|
| E1 | 产品版本或构建号 | 填写可追溯的版本标识，避免只写“最新版” |
| E2 | 运行环境 | 写明环境类型及终端信息，多端问题分别列出 |
| E3 | 账号与权限 | 描述角色与权限，账号标识做掩码处理 |
| E4 | 网络与设备 | 仅填写与问题相关的条件，如弱网、特定机型 |
日志与证据组
| 编号 | 字段含义 | 填写口径 |
|---|---|---|
| L1 | 日志片段 | 截取问题时间窗口内的日志，保留时间戳与错误级别 |
| L2 | 截图或录屏 | 画面需能体现问题现象，涉及个人信息的部分先处理再上传 |
| L3 | 请求与响应 | 保留接口地址、状态码与关键字段，令牌与参数值需脱敏 |
| L4 | 关联记录 | 填写需求单、用例或缺陷编号，便于追溯上下文 |
敏感信息处理组
| 编号 | 字段含义 | 填写口径 |
|---|---|---|
| S1 | 敏感信息识别 | 逐类列出缺陷内容中出现的敏感字段，识别范围以团队数据分类清单为准 |
| S2 | 脱敏处理 | 写明处理方式与处理后的呈现形式，如“手机号中间四位掩码” |
| S3 | 替换与示例化 | 用虚构值替换真实数据，并在内容中标注“示例数据” |
| S4 | 授权确认 | 确需保留原始信息时，记录授权人、授权范围、使用期限与用途 |
| S5 | 复核签署 | 由提交人以外的人员复核，记录复核人与复核时间 |
必填与选填怎么划分
必填与选填的划分依据一条判断标准：缺少该项是否会导致缺陷无法复现或无法定位。会导致的列为必填，只影响排查效率的列为选填。敏感信息处理组默认全部必填，这是模板的底线，不随项目类型放宽。
| 组别 | 默认必填项 | 默认选填项 | 可调整说明 |
|---|---|---|---|
| 缺陷描述 | D1、D2、D3、D5 | D4 | 面向外部用户的产品可将 D4 调整为必填 |
| 复现步骤 | R1、R2、R3 | R4 | 复杂业务链路建议将 R4 调整为必填 |
| 环境信息 | E1、E2、E3 | E4 | 移动端或弱网相关问题将 E4 调整为必填 |
| 日志与证据 | L1、L2 | L3、L4 | 接口类缺陷将 L3 调整为必填 |
| 敏感信息处理 | S1—S5 全部 | 无 | 不设选填，仅在“不适用”时说明理由 |
按项目类型调整时遵循三条规则。第一，涉及真实用户数据的项目，敏感信息处理组只能加严不能放宽，例如增加“数据导出审批”核对项。第二，内部工具类项目可精简 D4、R4、L4 等辅助项，但 D1—D3、R1—R3、E1—E3、L1—L2 保持必填。第三，任何调整都记录在模板版本说明中，写明调整人、调整日期和适用项目，避免不同项目各用一套口径却无从追溯。
填写示例：一条完整缺陷记录
以下为演示情景，用于说明字段填写口径，数据均为虚构示例。
| 编号 | 核对项 | 填写内容 | 核对结果 |
|---|---|---|---|
| D1 | 缺陷标题 | 订单列表页在筛选“已发货”状态后点击第二页，列表回到第一页 | 通过 |
| D2 | 问题现象 | 筛选已发货后翻至第二页，页面刷新并显示第一页数据，筛选条件仍保留 | 通过 |
| D3 | 预期结果 | 按需求文档 3.2 节，翻页应保留当前筛选条件并展示对应页数据 | 通过 |
| D4 | 影响范围 | 订单管理模块，影响使用筛选后翻页的运营人员 | 通过 |
| D5 | 发现时间与发现人 | 2024-06-12 10:20，测试账号 tester_demo | 通过 |
| R1 | 前置条件 | 运营角色账号，订单数据超过 50 条，存在已发货状态订单 | 通过 |
| R2 | 操作步骤 | 1. 进入订单列表；2. 筛选状态选“已发货”；3. 点击下一页 | 通过 |
| R3 | 复现频率 | 必现，连续 5 次均出现 | 通过 |
| R4 | 最小复现路径 | 筛选已发货后直接翻页即可触发 | 通过 |
| E1 | 产品版本或构建号 | v2.8.1-rc3 | 通过 |
| E2 | 运行环境 | 测试环境，Chrome 126，Windows 11 | 通过 |
| E3 | 账号与权限 | 运营角色，账号 t***r_demo | 通过 |
| E4 | 网络与设备 | 公司内网，普通办公电脑 | 通过 |
| L1 | 日志片段 | 10:20:31 请求 /order/list 返回 200，参数 page=2 被重置为 page=1 | 通过 |
| L2 | 截图或录屏 | 录屏 15 秒，订单号区域已打码 | 通过 |
| L3 | 请求与响应 | 请求参数中 token 已替换为示例值，订单号后四位掩码 | 通过 |
| L4 | 关联记录 | 关联需求单 REQ-1024 | 通过 |
| S1 | 敏感信息识别 | 涉及订单号、收货人手机号、登录 token | 通过 |
| S2 | 脱敏处理 | 订单号保留后四位，手机号中间四位掩码，token 整体替换 | 通过 |
| S3 | 替换与示例化 | 录屏中收货人姓名替换为“示例用户” | 通过 |
| S4 | 授权确认 | 无需保留原始信息，未申请授权 | 不适用 |
| S5 | 复核签署 | 复核人 reviewer_demo，2024-06-12 11:05 复核通过 | 通过 |
示例中 S4 填“不适用”而非留空，是因为该缺陷经脱敏后无需保留原始数据，核对结果需要明确表达这一判断。若确需保留原始订单号用于对账，则 S4 应填写授权人、授权范围与使用期限，并由 S5 复核人确认。
当缺陷记录需要进入团队的工作项系统流转时，可以把这份清单作为缺陷工作项的填写依据。ONES Project 适配缺陷管理等研发场景，支持一键提交 Bug 至对应项目或迭代，并与 TestCase 数据互通，缺陷状态分布也可统计沉淀。提交人按清单核对后录入工作项，评审人依据核对结果判断信息是否完整，修复完成后状态流转与经验沉淀在同一处完成。
模板调整与维护方法
模板需要随项目类型和合规要求变化而调整，维护的重点是让每次变更都有依据、有记录、有责任人。
新增或删减核对项的判断
- 新增依据：同类缺陷因缺少某项信息被退回两次以上，或评审中反复追问同一字段，即考虑新增核对项。
- 删减依据：连续两个版本周期内某项核对结果全部为“不适用”，且无评审追问，可评估删减或降为选填。
- 合并依据：两个核对项填写内容高度重叠时合并，避免重复填写。
敏感信息处理项的更新触发条件
- 团队数据分类清单或合规要求发生变化时，同步更新 S1 的识别范围。
- 出现新的敏感信息类型（如新增证件号、生物特征字段）时，补充识别与脱敏口径。
- 发生敏感信息外泄事件后，复盘并增加对应核对项，例如增加“附件上传前二次检查”。
- 授权流程或审批人调整时，更新 S4 的填写要求。
版本与责任人维护
模板文件头部保留版本号、生效日期、责任人和变更摘要四项信息。每次调整升一位版本号，变更摘要写清改了哪几项、为什么改。责任人负责解释填写口径和处理争议，人员变动时同步移交并在版本说明中记录。
定期复核与失效项清理
建议每个季度复核一次模板，核对各核对项的实际使用情况：统计“不适用”比例过高的项、被评审反复追问的项、与当前流程脱节的项。复核结论记录在版本说明中，失效项清理后通知全体提交人，避免新旧版本混用。模板调整后，用一条近期缺陷按新模板重填一遍，确认字段说明与示例仍然一致，再正式发布。
常见问题
缺陷涉及真实用户数据，但业务方要求保留原始信息用于对账，清单里怎么处理？
在 S4 授权确认项中记录授权人、授权范围、使用期限与用途，并让 S5 复核人确认后再提交。原始信息只保留对账必需的最小字段，其余字段仍按 S2 脱敏。对账完成后按团队数据管理要求清理原始信息，并在缺陷记录中注明清理时间。
偶现缺陷按清单填完后仍无法复现，提交前还应补充什么？
在 R3 复现频率中写清尝试次数与出现次数，例如“10 次出现 3 次”，并补充出现时的操作时间点，便于与 L1 日志时间戳对齐。若多次尝试仍无法稳定触发，可在 L2 中附上出现瞬间的录屏，并在备注中说明尝试过的环境组合，供后续排查参考。
团队已有缺陷单必填字段，这份清单还要逐项填吗？
清单与缺陷单字段可以对应使用：缺陷单已必填的字段在清单中核对“通过”即可，不必重复录入内容；清单重点补足缺陷单未覆盖的核对项，尤其是敏感信息处理组。若团队在 ONES Project 中管理缺陷，可将清单作为提交前的自查依据，按核对结果录入工作项，评审人依据核对结果判断信息是否完整。
敏感信息处理组什么情况下可以填“不适用”？
S1 至 S3、S5 需要逐项执行，缺陷内容确实不涉及任何敏感字段时，S1 填写“未涉及敏感信息”并将 S2、S3 标为不适用；S4 仅在无需保留原始信息时填“不适用”。任何“不适用”都要写明判断理由，不能留空，S5 复核人需确认该判断成立。
模板调整后，如何避免新旧版本混用？
每次调整升一位版本号，在模板头部变更摘要中写清改了哪几项、为什么改，并注明生效日期。发布后通知全体提交人，旧版本标记为失效。调整后的首个版本周期内，用一条近期缺陷按新模板重填一遍，确认字段说明与示例一致；复核时抽查核对结果，发现仍按旧口径填写的记录及时纠正。
