缺陷提交检查清单模板应覆盖五组核对项：缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理。模板以表格呈现，每行标注必填或选填、通过标准和核对结果，提交人逐项核对后再提单。下面给出一份可直接复制到文档或缺陷单中的空白表，并说明字段含义、必填划分、填写示例与维护方法。
要点总览（TL;DR）
- 清单模板按缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理五组组织，每行标注必填或选填、通过标准和核对结果。
- 核对结果建议用“已核对、不适用、待补充”三态，标记不适用时写明理由，避免只打勾掩盖缺失项。
- 描述三项、步骤三项、版本与设备、截图与日志片段、敏感信息两项默认必填，缺失时阻断提交；界面、性能、数据、兼容性缺陷可按类型追加必填项。
- 模板可直接复制到文档或缺陷单，落地时把核对项映射为缺陷单字段与必填校验，减少文档与系统两处维护。
- 清单需按季度或迭代回顾，记录版本变更，并明确严重程度判定、分类分级与服务事件受理属于相邻流程。
可复制空白检查清单模板
将下表复制到团队文档或缺陷单描述区即可使用。核对结果一栏建议从“已核对、不适用、待补充”三个值中选择，避免只打勾而掩盖未完成项。备注用于记录豁免理由、补充材料位置或待确认事项。
| 分组 | 核对项 | 必填/选填 | 通过标准 | 核对结果 | 备注 |
|---|---|---|---|---|---|
| 缺陷描述 | 标题写明模块、操作与异常结果 | 必填 | 不看正文即可判断问题位置和现象 | ||
| 现象描述具体到可观察的界面、数据或报错 | 必填 | 无“有问题”“不正常”等笼统表述 | |||
| 影响范围说明受影响的用户、功能或数据 | 必填 | 写明单点、部分用户或全量，以及是否阻断主流程 | |||
| 复现步骤 | 前置条件（账号角色、数据状态、开关配置） | 必填 | 他人按条件准备后能进入同一场景 | ||
| 操作序列按顺序编号，一步一个动作 | 必填 | 步骤可被他人独立执行，无省略跳步 | |||
| 预期结果与实际结果分列写明 | 必填 | 两者可直接对照，差异点明确 | |||
| 环境信息 | 产品版本或构建号 | 必填 | 精确到可定位的版本标识 | ||
| 设备、操作系统与浏览器版本 | 必填 | 写明实际使用的终端与版本 | |||
| 相关配置项与开关状态 | 选填 | 与缺陷相关的配置已记录 | |||
| 测试数据条件（数据类型、数量、来源） | 选填 | 能说明触发问题所需的数据特征 | |||
| 日志与证据 | 关键界面截图，标注异常位置 | 必填 | 截图清晰，异常处有圈注或说明 | ||
| 操作录屏（步骤复杂或偶现问题时） | 选填 | 录屏覆盖从操作到异常出现的完整过程 | |||
| 日志片段与报错原文 | 必填 | 包含时间点、错误码或堆栈关键行 | |||
| 关联标识（订单号、请求 ID、用户 ID 脱敏后） | 选填 | 可据此在日志中检索到同一次请求 | |||
| 敏感信息处理 | 账号、密码、密钥已替换或删除 | 必填 | 正文与附件中不出现真实凭据 | ||
| 客户数据、手机号、身份证号等已脱敏 | 必填 | 按团队脱敏规则替换，保留可复现特征 | |||
| 确需保留的原始材料另行存放并注明位置 | 选填 | 存放位置有访问限制，缺陷单中只写引用 |
各组核对项的字段说明
表格给出结构，填写质量取决于对每个核对项的理解。以下按五组说明每项要填什么、依据什么判断通过。
缺陷描述组
标题采用“模块＋操作＋异常结果”的写法，例如“订单列表按日期筛选后分页回到第一页”。标题的作用是让处理人在列表中快速判断是否与自己相关，因此要写异常本身，避免写“订单模块 bug”这类无法区分的信息。现象描述写实际看到的内容：报错文案、界面错位位置、数据偏差的具体数值。影响范围回答三个问题：影响哪些用户角色、影响哪个功能环节、是否阻断主流程。这三项共同决定后续处理优先级，但优先级判定本身不在本清单范围内。
复现步骤组
前置条件写清楚进入场景所需的账号角色、数据状态和配置开关，例如“使用普通成员账号，项目中已有 3 条以上待办任务”。操作序列按实际点击顺序编号，一步只写一个动作，避免把“打开页面并筛选”合并成一步。预期结果依据需求文档或产品约定，实际结果依据本次观察，两者分列书写，差异点自然显现。步骤写到异常出现为止，无需继续描述后续操作。
环境信息组
版本或构建号是定位问题的第一依据，缺失时开发往往无法判断问题是否已在修复版本中存在。设备和浏览器版本用于区分兼容性问题，同一功能在桌面端与移动端表现可能不同。配置项与开关状态属于选填，当缺陷与特定配置相关时必须填写，例如灰度开关、权限策略。测试数据条件同样按需填写，涉及数据计算、导入导出、列表分页的问题应说明数据量级和特征。
日志与证据组
截图用于直观呈现界面异常，应在异常位置做圈注，避免提交整屏无标注的图片。录屏适用于步骤较多或偶现的问题，录制范围覆盖从操作开始到异常出现。日志片段要包含时间点和错误码或堆栈关键行，便于在日志系统中检索。关联标识如订单号、请求 ID 能帮助开发定位同一次请求的完整链路，填写时按脱敏规则处理。
敏感信息处理组
账号、密码、密钥在提交前替换为占位符或直接删除，缺陷单正文和附件都不应出现真实凭据。客户数据、手机号、身份证号等按团队既定规则脱敏，保留足以复现问题的特征，例如保留手机号前三位和后四位。确需保留原始材料的，存放到有访问限制的位置，在缺陷单中只写存放位置和访问方式，不直接粘贴内容。这一组的核对发生在提交之前，属于提交人的责任。
必填项与选填项的划分
必填项的作用是保证缺陷可被独立理解和复现。默认建议将缺陷描述三项、复现步骤三项、版本与设备信息、截图与日志片段、敏感信息两项设为必填；缺失任一项时，提交动作应被阻断或退回补充。选填项在特定条件下转为必填，团队可按缺陷类型调整范围。
| 缺陷类型 | 默认必填范围 | 按类型追加的必填项 | 可标记不适用的条件 |
|---|---|---|---|
| 界面类 | 描述三项、步骤三项、版本与设备、截图 | 浏览器版本、分辨率或缩放比例 | 纯文案错误可不附日志 |
| 性能类 | 描述三项、步骤三项、版本与设备、日志片段 | 测试数据量级、操作耗时或资源占用记录 | 无法稳定复现时以录屏替代步骤细化 |
| 数据类 | 描述三项、步骤三项、版本、日志片段、关联标识 | 测试数据条件、数据来源与数量 | 涉及客户真实数据时以脱敏样本替代 |
| 兼容性类 | 描述三项、步骤三项、版本与设备、截图 | 对照环境信息（正常设备与异常设备各一组） | 仅单一设备可复现时注明对照结果 |
标记“不适用”需要写明理由，例如“该问题为后端接口报错，无界面截图，已附日志片段”。豁免由提交人发起、缺陷处理人确认，豁免记录保留在备注栏。团队可将阻断规则配置在缺陷单的必填字段校验中，让缺失项在提交环节暴露，而非等到处理人追问。
完整填写示例
以下示例演示一份已填好的缺陷记录，字段与前面的模板和说明保持一致。示例为演示情景，数据均为虚构。
| 分组 | 核对项 | 填写内容 | 核对结果 |
|---|---|---|---|
| 缺陷描述 | 标题 | 订单列表按日期筛选后翻页，页码重置回第一页 | 已核对 |
| 缺陷描述 | 现象描述 | 在订单列表选择日期范围后点击第 2 页，列表内容刷新为第 1 页数据，页码显示仍为 2 | 已核对 |
| 缺陷描述 | 影响范围 | 全部使用订单列表筛选的运营人员，影响订单核对效率，不阻断下单流程 | 已核对 |
| 复现步骤 | 前置条件 | 运营角色账号，项目内订单数据不少于 50 条 | 已核对 |
| 复现步骤 | 操作序列 | 1. 进入订单列表；2. 选择近 30 天日期范围；3. 点击第 2 页 | 已核对 |
| 复现步骤 | 预期与实际 | 预期：显示第 2 页数据；实际：显示第 1 页数据，页码仍为 2 | 已核对 |
| 环境信息 | 版本 | v3.8.2 构建 20240612 | 已核对 |
| 环境信息 | 设备与浏览器 | Windows 11，Chrome 125 | 已核对 |
| 环境信息 | 配置与数据条件 | 默认配置；测试数据 120 条，日期分布跨 60 天 | 已核对 |
| 日志与证据 | 截图 | 附截图 2 张，圈注页码与列表首行订单号 | 已核对 |
| 日志与证据 | 日志片段 | 14:32:07 请求 list?page=2 返回 page=1 数据，附请求 ID | 已核对 |
| 日志与证据 | 关联标识 | 请求 ID：req-****-8821（已脱敏） | 已核对 |
| 敏感信息 | 账号与密钥 | 示例账号已替换为 test_user，无密钥 | 已核对 |
| 敏感信息 | 客户数据脱敏 | 订单号保留后四位，收件人姓名替换为“张*” | 已核对 |
| 敏感信息 | 原始材料存放 | 原始日志存放于受限目录，缺陷单仅写路径 | 已核对 |
示例中录屏一项未使用，因步骤可稳定复现，属于选填项的正常取舍；若该问题偶现，则应补充录屏并将核对结果改为“待补充”，待材料齐全后再提交。
清单的调整与维护方法
清单需要随项目和缺陷类型变化更新，否则会退化为形式化打勾。建议由测试负责人或质量接口人持有模板，按以下规则调整。
- 新增核对项的触发条件：同类缺陷连续出现两次以上因信息缺失被退回，或新引入的技术栈（如新的客户端、第三方集成）带来新的环境变量，可提议新增核对项。新增需经测试与开发共同评审，确认该项确实影响定位效率后再纳入。
- 版本与变更记录：每次调整记录版本号、变更内容、提出人和生效日期，旧版本保留可查，便于回溯某次缺陷提交适用的核对范围。
- 定期回顾：按季度或按迭代抽查已提交缺陷，统计因信息缺失被退回的比例和常见缺失项，据此删减长期无人使用的核对项、修订通过标准。
- 边界说明：本清单只管提交环节的信息完整性。缺陷严重程度与优先级的判定、缺陷分类分级规则、服务事件的受理与流转属于相邻流程，应在各自规范中定义，清单中只引用不展开。
| 版本 | 变更内容 | 提出人 | 生效日期 |
|---|---|---|---|
| v1.0 | 初始五组核对项与必填划分 | 质量接口人 | （填写） |
| v1.1 | （示例）数据类缺陷追加关联标识为必填 | （填写） | （填写） |
清单落地时，可将核对项对应到缺陷单的字段与必填校验上，让提交人在提单界面完成核对，减少文档与系统两处维护。ONES Project 适配缺陷管理等研发场景，支持缺陷跟踪管理并统计缺陷状态分布；与 TestCase 数据互通时可一键提交 Bug 至对应项目或迭代。团队可将模板中的描述、步骤、环境、证据字段映射为缺陷单字段，把必填项配置为提交校验，评审与流转记录留在工作项中。模板文档本身可放在 ONES Wiki 中，通过文档关联任务与工作项列表保持模板与缺陷记录同步。
常见问题
缺陷提交检查清单里的核对项，和缺陷单本身的字段是什么关系？
两者可以一一对应，也可以分开维护。清单是填写前的核对依据，缺陷单字段是系统里的存储位置。落地时建议把描述、步骤、环境、证据、脱敏五组核对项映射为缺陷单字段，把默认必填项配置为提交校验，这样提交人在提单界面完成核对，清单文档只保留通过标准和示例说明。若团队暂时没有字段级校验，清单文档作为提交前的自查表使用，评审人按清单逐项确认。
偶现缺陷无法稳定复现，清单里的复现步骤和录屏怎么填？
偶现缺陷的步骤仍要写，但可以标注“偶现”并记录出现频率和已尝试的复现条件。此时录屏从选填转为必填，录制范围覆盖从操作开始到异常出现的完整过程，并记录出现时间点。步骤中无法确认的环节写“待确认”，核对结果选“待补充”，待材料齐全后再提交。若多次尝试仍无法复现，可在备注中说明尝试次数和环境，交由处理人判断是否需要补充日志埋点。
敏感信息脱敏后影响复现，应该怎么处理？
脱敏的原则是保留足以复现问题的特征，同时不暴露真实数据。手机号可保留前三位和后四位，订单号保留后四位，姓名替换为“姓＋*”。如果问题与具体数据值强相关，例如金额计算偏差，可用结构相同、数值不同的测试数据替代，并在备注中说明原始数据的特征。确需保留原始材料的，存放到有访问限制的位置，缺陷单中只写存放路径和访问方式，不直接粘贴内容。
团队规模小、缺陷量不大，还需要维护完整清单吗？
可以精简，但建议保留必填项的核心部分：标题与现象、复现步骤、版本与设备、截图或日志、敏感信息检查。选填项和按缺陷类型追加的必填项可以暂缓，等出现因信息缺失被退回的情况再逐步补充。清单的维护成本主要来自评审和版本记录，小团队可以合并为一次迭代回顾时顺带检查，不必单独设立流程。
清单里的必填校验配置在系统里，和文档模板冲突时以哪个为准？
以系统校验为准，文档模板作为填写说明和示例的载体。系统校验能直接阻断缺失项提交，执行力度更强；文档模板负责解释每个核对项的含义、通过标准和豁免理由的写法。两者内容应保持同步，每次调整清单版本时同步更新字段校验规则，并在变更记录中注明生效日期，避免提交人按旧模板填写却被新校验拦截。
