缺陷提交前核对清单可以做成一张按五个区块组织的表格：缺陷描述、复现步骤、环境、日志证据、敏感信息处理。每个区块列出核对项、是否必填、通过标准、核对结果和核对人，提交人逐项打勾，未通过项先补齐再提交。下面先给可直接复制的空白模板，再说明每项核对口径、必填与选填的划分规则，并用一条完整示例演示如何判断通过。
要点总览（TL;DR）
- 清单按缺陷描述、复现步骤、环境、日志证据、敏感信息处理五个区块组织，每行标注是否必填、通过标准、核对结果与核对人，可直接复制到缺陷模板。
- 必填与选填按“缺少该项就无法定位或复现”划分，默认仅截图或录屏为选填；界面类、接口类、数据错误类、偶现类缺陷可按类型调整必填范围。
- 敏感信息处理在所有缺陷类型中保持必填，日志与截图需完成脱敏检查，附件访问权限限于缺陷处理相关人员。
- 填写示例演示了逐项判断通过标准的方法，未通过项先补齐再重新核对，全部通过后再提交。
- 清单需标注版本、修订日期与责任人，按退回补充、环境变化、泄露事件等触发条件修订，并通过定期抽查发现常见缺失项。
可复制空白核对清单模板
下表可直接复制到缺陷模板文档、提交页说明或团队协作页面中使用。核对结果一栏填写“通过”或“待补齐”，核对人填写实际执行核对的人；同一人提交并核对时也建议留名，便于后续追溯。表格按区块分组，区块内行数可按项目增减，但五个区块建议保留。
| 区块 | 核对项 | 是否必填 | 通过标准 | 核对结果 | 核对人 |
|---|---|---|---|---|---|
| 缺陷描述 | 标题能概括现象与对象 | 必填 | 不看正文也能判断在哪个功能、出现什么异常 | ||
| 缺陷描述 | 现象描述具体可读 | 必填 | 写清发生了什么，避免“有问题”“不正常”等笼统表述 | ||
| 缺陷描述 | 期望结果与实际结果分列 | 必填 | 两项均有明确表述，且能看出差异 | ||
| 缺陷描述 | 影响范围已说明 | 必填 | 写明受影响的用户、数据、流程或模块范围 | ||
| 复现步骤 | 前置条件已列出 | 必填 | 账号状态、数据准备、权限等前提写清 | ||
| 复现步骤 | 操作步骤按顺序编号 | 必填 | 每步一个动作，他人可照做 | ||
| 复现步骤 | 复现频率已记录 | 必填 | 写明必现、偶现或尝试次数中的出现次数 | ||
| 环境 | 产品版本已填写 | 必填 | 版本号精确到可定位的构建或发布版本 | ||
| 环境 | 设备或系统信息已填写 | 必填 | 操作系统、浏览器、机型或客户端类型与实际一致 | ||
| 环境 | 数据与配置条件已说明 | 必填 | 涉及特定数据、开关、参数时写明取值 | ||
| 日志证据 | 日志片段已附上 | 必填 | 包含报错前后上下文，标明来源文件或模块 | ||
| 日志证据 | 截图或录屏已附上 | 选填 | 画面能对应描述中的现象，关键区域可见 | ||
| 日志证据 | 时间点已标注 | 必填 | 写明问题发生的时间及日志对应时间段 | ||
| 敏感信息 | 账号、密钥、个人信息已脱敏 | 必填 | 日志与截图中不出现明文密码、令牌、身份证号等 | ||
| 敏感信息 | 附件访问权限已确认 | 必填 | 附件仅对处理缺陷所需人员可见 |
清单本身是空白模板，团队复制后可在“核对项”列增删行，在“通过标准”列写入本项目可执行的判断口径。核对结果全部为“通过”后再提交缺陷；存在“待补齐”时，先补齐对应内容，再重新核对该项。
清单字段说明：每个核对项在核对什么
字段说明用于统一判断口径，避免不同提交人对同一核对项理解不一致。下表逐项解释含义，模板、说明与后文示例使用同一套表述。
| 区块 | 核对项 | 核对内容与判断口径 |
|---|---|---|
| 缺陷描述 | 标题 | 标题承担检索和快速分派的作用，应包含功能对象与异常现象，例如“订单导出在筛选日期后返回空文件”。 |
| 缺陷描述 | 现象 | 描述实际观察到的结果，包括报错文案、界面表现或数据异常，写清发生位置和触发时的可见变化。 |
| 缺陷描述 | 期望与实际结果 | 期望结果写业务上应有的行为，实际结果写当前观察到的行为，两者分列便于评审时直接对照。 |
| 缺陷描述 | 影响范围 | 说明受影响的用户群体、数据量、业务流程或模块，用于判断处理优先级，不替代严重程度判定。 |
| 复现步骤 | 前置条件 | 列出复现所需的账号、权限、数据状态和配置，缺少前置条件时他人往往无法复现。 |
| 复现步骤 | 操作步骤 | 按执行顺序编号，每步一个动作，写清点击位置、输入内容和选择项。 |
| 复现步骤 | 复现频率 | 记录必现、偶现及尝试次数中的出现次数，偶现问题应说明出现规律或已尝试的变体。 |
| 环境 | 版本 | 填写产品版本号或构建标识，涉及多端时分别注明各端版本。 |
| 环境 | 设备或系统 | 填写操作系统及版本、浏览器及版本、机型或客户端类型，与问题实际发生环境一致。 |
| 环境 | 数据与配置 | 写明触发问题所依赖的数据特征、功能开关、参数取值或租户配置。 |
| 日志证据 | 日志片段 | 附上包含报错信息及前后若干行的日志，标明来源文件、模块或服务名。 |
| 日志证据 | 截图或录屏 | 画面需能对应描述中的现象，关键区域清晰可见；动态过程优先用录屏。 |
| 日志证据 | 时间点 | 标注问题发生时间与日志时间段，便于在日志系统中定位同一时段记录。 |
| 敏感信息 | 脱敏检查 | 检查日志、截图和正文中是否出现明文密码、令牌、密钥、手机号、身份证号等，出现即替换或打码。 |
| 敏感信息 | 附件权限 | 确认附件可见范围限于缺陷处理相关人员，含敏感数据的附件按团队规定控制访问。 |
必填与选填怎么划分
划分原则可以归纳为一句话：缺少该项就无法定位或复现缺陷的，列为必填；用于补充说明、依赖缺陷类型或项目阶段才需要的，列为选填。按此原则，上表中的标题、现象、期望与实际结果、影响范围、前置条件、操作步骤、复现频率、版本、设备或系统、数据与配置、日志片段、时间点、脱敏检查、附件权限均为必填，截图或录屏默认选填。
必填范围可以按缺陷类型调整，调整规则建议写入模板说明：
- 界面显示类缺陷：截图由选填调整为必填，日志片段可放宽为选填，但需保留时间点。
- 接口或后端异常类缺陷：日志片段、请求标识和时间点为必填，截图可省略。
- 数据错误类缺陷：数据与配置条件、影响范围为必填，并建议附上出错数据样例的脱敏副本。
- 偶现类缺陷：复现频率为必填且需写明尝试次数与出现次数，录屏建议调整为必填。
- 探索阶段或内部预研项目：可暂时减少影响范围等描述性字段，但脱敏检查与附件权限不建议放宽。
敏感信息处理在所有缺陷类型中都保持必填，原因是日志和截图一旦带入明文凭据，后续流转和归档都会扩大暴露面。团队可在模板中为不同缺陷类型准备勾选说明，提交时先选类型，再按对应必填范围核对。
填写示例：一条缺陷走完整个清单
以下示例为演示情景，用于说明清单如何逐项填写与判断，不代表真实项目数据。
| 区块 | 核对项 | 示例填写内容 | 判断 |
|---|---|---|---|
| 缺陷描述 | 标题 | 订单导出在筛选近7天日期后返回空文件 | 通过：含功能对象与现象 |
| 缺陷描述 | 现象 | 点击导出后下载的表格仅有表头，无数据行，页面提示“导出成功” | 通过：写清可见结果与提示文案 |
| 缺陷描述 | 期望与实际结果 | 期望：导出所选日期范围内的订单明细；实际：文件仅含表头 | 通过：两项分列且差异明确 |
| 缺陷描述 | 影响范围 | 影响使用日期筛选导出的运营人员，涉及近7天订单核对流程 | 通过：写明人群与流程 |
| 复现步骤 | 前置条件 | 测试账号具备订单导出权限，账号下存在近7天订单数据 | 通过：账号、权限、数据均已说明 |
| 复现步骤 | 操作步骤 | 1. 进入订单列表；2. 日期筛选选择近7天；3. 点击导出；4. 打开下载文件 | 通过：步骤编号、动作单一 |
| 复现步骤 | 复现频率 | 尝试5次，5次均出现，必现 | 通过：写明次数与结论 |
| 环境 | 版本 | 产品版本 3.8.2，Web端 | 通过：版本可定位 |
| 环境 | 设备或系统 | Windows 11，Chrome 126 | 通过：系统与浏览器版本齐全 |
| 环境 | 数据与配置 | 账号所属租户开启新版导出开关，订单数据约1200条 | 通过：开关与数据量已说明 |
| 日志证据 | 日志片段 | 附 export-service 日志，含“query returned 0 rows”及前后5行 | 通过：有上下文与来源 |
| 日志证据 | 截图或录屏 | 附下载文件截图，显示仅表头 | 通过：画面与现象对应 |
| 日志证据 | 时间点 | 问题发生时间 2025-03-11 10:24，日志时间段 10:23–10:25 | 通过：时间与日志对应 |
| 敏感信息 | 脱敏检查 | 日志中账号ID已替换为 user_***，截图已遮挡客户手机号 | 通过：敏感字段已处理 |
| 敏感信息 | 附件权限 | 附件仅缺陷处理组可见 | 通过：访问范围已确认 |
示例中若“日志片段”一栏只贴了报错单行、没有上下文，判断为“待补齐”，补齐动作是回到日志系统截取报错前后若干行并标明来源模块；若截图未遮挡客户手机号，判断为“待补齐”，补齐动作是重新打码后再上传，并确认旧附件已删除或替换。补齐后重新核对对应行，全部通过再提交。
当缺陷记录在ONES工作项中提交时，可把清单中的核对结果写入缺陷工作项的检查项或描述模板，提交前由提交人逐项确认，评审人按同一张清单复核。这样清单、缺陷记录和后续流转使用同一份信息，减少在聊天工具与缺陷系统之间反复补材料。
清单的调整与维护方法
清单上线后需要随项目变化调整，否则会出现核对项与实际缺陷类型脱节、提交人绕过清单的情况。调整可以从触发条件、版本责任和抽查三方面入手。
新增或删除核对项的触发条件建议明确为：同类缺陷连续出现因缺少某项信息而退回补充；项目引入新的端、环境或数据源；团队发生敏感信息泄露或险些泄露事件；某核对项连续多个周期无人填写或填写内容无实际判断价值。满足任一条件时，由清单责任人发起修订，修订后在团队内说明变更点和生效时间。
版本与责任人维护方面，清单文件应标注版本号、修订日期和责任人，修订记录保留每次增删的核对项及原因。责任人负责解释判断口径、处理提交人对必填范围的疑问，并在项目阶段变化时同步调整按缺陷类型划分的必填范围。
定期抽查可采用抽样方式：每个周期抽取一定数量的已提交缺陷，按清单逐项复核信息是否齐全、通过标准是否被真实执行，记录退回补充的比例和常见缺失项。抽查结果用于下一轮修订，常见缺失项可考虑写入提交页提示或调整为更明确的通过标准。抽查频率和样本量由团队按缺陷量确定，缺陷量较小时可按月抽查，量较大时按周抽样。
常见问题
缺陷提交时日志片段只贴一行报错，算不算通过清单核对？
不算。清单的通过标准要求日志片段包含报错信息及前后若干行上下文，并标明来源文件、模块或服务名。只贴单行报错时，判断为“待补齐”，补齐动作是回到日志系统截取报错前后若干行，注明来源模块后再附上。若问题涉及接口调用，建议同时保留请求标识和时间点，便于在日志系统中定位同一时段记录。
偶现缺陷的复现频率怎么写才符合清单要求？
写明尝试次数与出现次数，并给出结论，例如“尝试10次，出现3次，偶现”。如果已尝试不同账号、数据或环境变体，把变体条件和对应结果一并记录。偶现类缺陷建议把录屏调整为必填，用于补充文字难以描述的操作过程。复现频率记录的是观察结果，不用于判定严重程度。
团队想减少必填项，哪些可以放宽、哪些不建议放宽？
探索阶段或内部预研项目可以暂时减少影响范围等描述性字段，界面显示类缺陷可把日志片段放宽为选填。脱敏检查与附件权限不建议放宽，原因是日志和截图一旦带入明文凭据，后续流转和归档都会扩大暴露面。放宽范围应写入模板说明，并注明适用阶段和恢复条件，避免长期沿用。
清单核对结果如何与缺陷记录关联，避免重复填写？
可以把清单中的核对结果写入缺陷工作项的检查项或描述模板，提交前由提交人逐项确认，评审人按同一张清单复核。在ONES工作项中提交缺陷记录时，清单、缺陷记录和后续流转使用同一份信息，减少在聊天工具与缺陷系统之间反复补材料。具体字段配置可按团队现有缺陷模板调整。
清单多久修订一次，由谁负责？
清单文件应标注版本号、修订日期和责任人，修订记录保留每次增删的核对项及原因。触发修订的条件包括：同类缺陷连续因缺少某项信息被退回补充、项目引入新的端或数据源、发生敏感信息泄露或险些泄露事件、某核对项连续多个周期无人填写。责任人负责解释判断口径并同步调整按缺陷类型划分的必填范围。抽查频率按缺陷量确定，量小时按月、量大时按周抽样。
