缺陷提交检查清单模板应覆盖五类核对项：缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理。模板以勾选表形式组织，每项配必填或选填标记与填写规范，提交人逐项打勾确认后再提交。本文给出一份可直接复制到文档或表格工具中的空白清单，并说明字段口径、必填划分、填写示例与维护方法，适用于团队在缺陷提交前做统一自查。
要点总览（TL;DR）
- 清单模板按五组核对项组织：缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理，每组下设具体条目。
- 空白模板采用勾选表结构，设“核对项、填写规范、必填/选填、是否确认”四列，可直接复制到文档或表格工具中使用。
- 必填项为提交阻断项，缺一项即退回；设备与系统、部署环境、数据条件、日志片段、附件权限范围按缺陷类型条件必填；关联需求或用例、留存范围说明为选填。
- 填写时以“未参与测试的同事能按描述复现”为判断标准，示例中的版本号、时间与编号均为演示数据。
- 清单需指定维护人按版本迭代，结合评审退回案例与抽查结果调整条目，并把变更记录到版本表。
可复制空白清单模板
下表为空白勾选表，可直接复制到在线文档、电子表格或缺陷工作项的描述模板中。表头字段记录本次提交的基本信息，主体部分按五组核对项排列，每行包含核对内容、填写规范、必填标记和确认列。
| 表头字段 | 填写内容 |
|---|---|
| 缺陷编号 | （提交后由系统生成或按团队规则预填） |
| 提交人 | |
| 提交时间 | |
| 所属项目 / 迭代 | |
| 缺陷标题 |
| 分组 | 核对项 | 填写规范 | 必填/选填 | 是否确认 |
|---|---|---|---|---|
| 一、缺陷描述 | 标题 | 一句话说明“在什么场景下出现什么异常”，包含对象与结果 | 必填 | □ |
| 现象描述 | 写清实际表现，附错误提示原文，避免只写“有问题” | 必填 | □ | |
| 影响范围 | 说明受影响的用户、功能模块或数据范围 | 必填 | □ | |
| 二、复现步骤 | 前置条件 | 账号角色、数据状态、配置项等开始操作前的状态 | 必填 | □ |
| 操作序列 | 按顺序编号列出每一步操作 | 必填 | □ | |
| 预期结果 | 依据需求或设计说明应出现的结果 | 必填 | □ | |
| 实际结果 | 实际操作后观察到的结果 | 必填 | □ | |
| 三、环境信息 | 产品版本 / 构建号 | 填写测试所针对的版本标识 | 必填 | □ |
| 设备与操作系统 | 机型、系统版本、浏览器及版本 | 条件必填 | □ | |
| 网络与部署环境 | 测试环境、预发布环境或生产环境，网络条件 | 条件必填 | □ | |
| 数据条件 | 触发缺陷所需的特定数据或账号状态 | 条件必填 | □ | |
| 四、日志与证据 | 截图或录屏 | 标注关键操作位置与异常出现的时间点 | 必填 | □ |
| 日志片段 | 截取异常时间窗内的日志，保留时间戳与错误码 | 条件必填 | □ | |
| 发生时间点 | 精确到分钟，便于与日志、监控对齐 | 必填 | □ | |
| 关联需求或用例 | 填写对应的需求编号或用例编号 | 选填 | □ | |
| 五、敏感信息处理 | 脱敏检查 | 截图、日志中的手机号、身份证号、密钥等已遮盖 | 必填 | □ |
| 附件权限范围 | 确认附件可见范围与缺陷记录一致 | 条件必填 | □ | |
| 留存范围说明 | 注明证据材料的保存位置与保留期限 | 选填 | □ |
复制时保留“是否确认”列，提交前逐行打勾；未打勾的必填项视为未完成自查。
字段说明：每个核对项要填什么
下表逐项解释核对项的填写口径，字段名与空白模板一一对应。填写时以“能让未参与测试的同事按描述复现”为判断标准。
| 核对项 | 填写口径 | 常见错误 |
|---|---|---|
| 标题 | 包含操作对象、触发场景和异常结果，例如“订单列表按金额排序后分页重复” | 只写“列表有问题”，无法定位 |
| 现象描述 | 描述可观察的实际表现，错误提示保留原文 | 混入推测原因，把猜测当结论 |
| 影响范围 | 写明受影响的角色、模块、数据量级 | 笼统写“影响用户”，无法判断优先级 |
| 前置条件 | 列出开始操作前必须满足的账号、数据、配置状态 | 遗漏特定数据状态，导致他人无法复现 |
| 操作序列 | 逐步编号，每步一个动作，包含输入值 | 把多步合并成一句，步骤顺序不清 |
| 预期结果 | 引用需求文档或设计稿中的对应描述 | 凭个人理解写预期，与需求不一致 |
| 实际结果 | 如实记录观察到的结果，与预期逐条对应 | 只写“不符合预期”，缺少具体差异 |
| 产品版本 / 构建号 | 填写测试对象的准确版本标识 | 写“最新版”，无法回溯 |
| 设备与操作系统 | 机型、系统版本、浏览器及版本分别列出 | 只写“手机端”，缺少系统与版本 |
| 网络与部署环境 | 注明环境名称及特殊网络条件 | 把测试环境问题写成生产问题 |
| 数据条件 | 说明触发缺陷所需的特定数据或账号状态 | 使用个人临时数据，他人无法构造 |
| 截图或录屏 | 完整呈现操作路径与异常画面，标注时间点 | 只截异常结果，缺少操作上下文 |
| 日志片段 | 保留时间戳、错误码和关键堆栈 | 截取过长日志，关键行被淹没 |
| 发生时间点 | 精确到分钟，与日志、监控时间对齐 | 只写日期，无法与日志匹配 |
| 关联需求或用例 | 填写需求编号或用例编号，便于追溯 | 填写已失效的旧编号 |
| 脱敏检查 | 逐张检查截图与日志，遮盖个人信息与密钥 | 只处理截图，忽略日志中的账号信息 |
| 附件权限范围 | 确认附件可见范围与缺陷记录权限一致 | 附件放在公开目录，扩大可见范围 |
| 留存范围说明 | 注明证据材料的保存位置与保留期限 | 证据散落在个人目录，评审时找不到 |
必填与选填的划分
必填项是提交阻断项：缺少任一项，缺陷记录不予受理或退回补充。条件必填项按缺陷类型触发，选填项用于补充上下文。下表给出三档划分及判定规则。
| 档位 | 核对项 | 判定规则 |
|---|---|---|
| 必填（提交阻断） | 标题、现象描述、影响范围、前置条件、操作序列、预期结果、实际结果、产品版本 / 构建号、截图或录屏、发生时间点、脱敏检查 | 任何缺陷提交均须完成，缺一项即退回 |
| 条件必填 | 设备与操作系统、网络与部署环境、数据条件、日志片段、附件权限范围 | 界面或兼容类缺陷须填设备与系统；环境相关缺陷须填部署环境；依赖特定数据的缺陷须填数据条件；涉及后端报错须附日志；附件含内部信息时须确认权限范围 |
| 选填 | 关联需求或用例、留存范围说明 | 有明确需求或用例时建议填写；证据材料需要长期保存时补充留存说明 |
缺项处理建议：必填项缺失时退回提交人补充，并在缺陷记录中注明退回原因；条件必填项由提交人判断是否触发，评审人可在评审时要求补填；选填项缺失不影响受理。团队可将必填规则写入缺陷工作项的提交说明，减少来回沟通。
填写示例：一条完整缺陷的清单
以下为演示情景，缺陷内容为虚构，仅用于示范各项如何落笔。
| 核对项 | 填写内容 | 是否确认 |
|---|---|---|
| 缺陷编号 | BUG-1042（示例） | — |
| 提交人 / 提交时间 | 测试同学A / 2025-03-11 14:20 | — |
| 标题 | 订单列表按金额降序排序后，翻至第二页出现重复订单 | ☑ |
| 现象描述 | 第一页最后一条订单在第二页首条再次出现，页面无报错提示 | ☑ |
| 影响范围 | 订单管理模块，影响所有使用金额排序的运营账号 | ☑ |
| 前置条件 | 测试账号具备订单查看权限，账号下存在 60 条以上订单 | ☑ |
| 操作序列 | 1. 进入订单列表；2. 选择按金额降序排序；3. 点击下一页；4. 对比第一页末条与第二页首条 | ☑ |
| 预期结果 | 分页数据不重复，第二页从第 21 条开始展示 | ☑ |
| 实际结果 | 第二页首条与第一页末条为同一订单号 | ☑ |
| 产品版本 / 构建号 | 订单服务 v3.8.2（示例构建号） | ☑ |
| 设备与操作系统 | Chrome 122，macOS 14（示例） | ☑ |
| 网络与部署环境 | 测试环境，公司内网 | ☑ |
| 数据条件 | 账号下订单数超过 60 条，金额存在并列值 | ☑ |
| 截图或录屏 | 录屏 40 秒，展示排序、翻页与重复订单对比 | ☑ |
| 日志片段 | 截取 14:12 至 14:15 的分页查询日志，保留请求参数与时间戳 | ☑ |
| 发生时间点 | 2025-03-11 14:12 | ☑ |
| 关联需求或用例 | REQ-208 订单列表分页规则（示例） | ☑ |
| 脱敏检查 | 截图与日志中的收件人手机号已打码，账号 ID 已替换 | ☑ |
| 附件权限范围 | 附件仅项目成员可见，与缺陷记录权限一致 | ☑ |
| 留存范围说明 | 录屏与日志存放于项目附件目录，保留至版本发布后 90 天 | ☑ |
对照检查时，先看必填项是否全部打勾，再确认条件必填项是否因缺陷类型触发，最后核对脱敏与权限两项是否完成。示例中的版本号、时间与编号均为演示数据，实际填写以团队真实记录为准。
清单的调整与维护方法
清单需要随项目类型和评审反馈迭代。建议指定一名维护人，按版本记录每次变更，避免多人各自修改导致口径不一致。
新增或删减核对项的触发条件可以包括：某类缺陷连续多次因同一信息缺失被退回；项目引入新的端类型或部署形态；评审中发现核对项与当前流程不符；复盘显示某类证据对定位问题贡献有限。触发后由维护人提出变更，经测试与开发代表确认后生效。
| 版本 | 生效日期 | 变更内容 | 变更原因 | 确认人 |
|---|---|---|---|---|
| v1.0 | （填写） | 初始五组核对项 | 团队首次统一提交规范 | （填写） |
| v1.1 | （填写） | （新增或调整的核对项） | （评审或复盘反馈） | （填写） |
与评审、复盘的联动方式：在缺陷评审会上记录因信息缺失退回的案例，按核对项归类；复盘时统计各类缺项的出现频次，频次高的项考虑升级为必填或补充填写规范。执行情况可通过抽查近期缺陷记录完成，检查必填项完整率与退回原因分布，抽查结果作为下一版清单的输入。
当团队使用 ONES Project 管理缺陷时，清单可以作为缺陷工作项描述中的固定段落，提交人填写后随记录一并保存；ONES Project 支持缺陷跟踪管理并可统计缺陷状态分布，与 TestCase 数据互通后可一键提交 Bug 至对应项目或迭代，便于把提交前核对与后续跟踪放在同一流程中。清单中的必填校验、附件权限等具体配置方式，需结合团队实际使用的系统能力确认。
常见问题
缺陷提交检查清单里的必填项太多，团队觉得填写负担重，怎么取舍？
先保留与“能否复现、能否定位”直接相关的项：标题、现象描述、复现步骤、预期与实际结果、版本号、截图或录屏、发生时间点、脱敏检查。这些项缺失时，开发往往需要回头找提交人补充，反而增加往返成本。
设备与系统、部署环境、数据条件、日志片段可以设为条件必填，只在对应缺陷类型触发时要求填写。关联需求或用例、留存范围说明保持选填。团队可以先按这套划分运行一个迭代，统计退回原因分布，再决定是否增减必填项。
提交人判断不了某个条件必填项是否触发，应该怎么处理？
条件必填的判定责任可以分两层：提交人按缺陷类型初步判断，评审人在评审时补充要求。例如界面显示异常但不确定是否与设备相关，提交人可先填写已知的设备与系统信息；评审人认为需要更多环境细节时，在缺陷记录中注明补充要求，由提交人补填。
如果某类缺陷反复因同一条件项缺失被退回，说明判定规则不够清晰，应把该情形写入清单的填写规范，或直接升级为必填。
日志和截图里的敏感信息怎么处理才算完成脱敏？
脱敏检查要覆盖截图、录屏和日志三类材料。截图与录屏中的手机号、身份证号、收件地址、账号 ID 等个人信息应遮盖或替换；日志中的密钥、令牌、完整账号信息应删除或打码，同时保留时间戳、错误码和关键堆栈，保证证据仍可用于定位。
附件权限范围与缺陷记录权限保持一致，避免把含内部信息的材料放到公开目录。留存范围说明可注明证据的保存位置与保留期限，便于后续评审和清理。
清单模板在缺陷管理工具里怎么落地，需要系统支持哪些配置？
常见做法是把清单作为缺陷工作项描述中的固定段落，提交人填写后随记录保存。团队使用 ONES Project 管理缺陷时，缺陷工作项可承载这份清单，ONES Project 支持缺陷跟踪管理并可统计缺陷状态分布，与 TestCase 数据互通后可一键提交 Bug 至对应项目或迭代，便于把提交前核对与后续跟踪放在同一流程中。
清单中的必填校验、附件权限等具体配置方式，需结合团队实际使用的系统能力确认，本文不对未核实的功能细节作断言。
清单多久更新一次比较合适，谁来负责？
更新节奏由触发条件决定，不必固定周期。出现以下情况时启动修订：某类缺陷连续多次因同一信息缺失被退回；项目引入新的端类型或部署形态；评审发现核对项与当前流程不符；复盘显示某类证据对定位问题贡献有限。
建议指定一名维护人统一收集变更，经测试与开发代表确认后发布新版本，并在版本表中记录生效日期、变更内容、变更原因和确认人。执行情况可通过抽查近期缺陷记录的必填项完整率与退回原因分布来评估。
