缺陷提交检查清单模板应包含哪些核对项

缺陷提交检查清单模板应围绕五类核对项组织：缺陷描述是否说清现象与影响、复现步骤是否可独立执行、环境信息是否足以还原、日志与证据是否完整且已脱敏、敏感信息是否已处理。模板以空白表格为主体，逐项标注必填与选填，并配套字段说明、完整填写示例和维护方法，让提交人在提单前逐条勾选，减少因信息缺失导致的反复沟通。

要点总览（TL;DR）

• 清单模板按五类核对项组织：缺陷描述、复现步骤、环境信息、日志与证据、敏感信息处理，每类给出可判断的通过标准。
• 描述、复现步骤、环境、敏感信息处理设为必填；日志、截图录屏、附加数据、关联需求按缺陷类型裁剪。
• 不适用项要显式标注原因，核对结果列不允许空白提交，避免漏填被误读。
• 模板配套字段说明和完整填写示例，示例中每一项都能对应到模板与说明，便于直接复制使用。
• 清单上线后按漏填反馈、字段变更和抽样结果修订，保留版本号与变更记录，并与缺陷单字段保持同步。

可复制空白检查清单模板

下表可直接复制到缺陷单模板、文档或知识库页面中使用。核对结果列填写“通过”“不通过”或“不适用”，核对人填写实际执行核对的人。提交前所有必填项应达到“通过”或“不适用”，存在“不通过”项时先补齐信息再提交。

分组	核对项	是否必填	填写位置/字段	核对结果	核对人
缺陷描述	已写明实际现象，读者不看截图也能理解发生了什么	必填	缺陷标题、现象描述
	已写明预期结果与实际结果的差异	必填	预期结果、实际结果
	已说明影响范围（受影响用户、功能、数据）	必填	影响范围
复现步骤	已写明前置条件（账号、权限、数据准备）	必填	前置条件
	操作步骤按顺序编号，每步只含一个动作	必填	复现步骤
	已按步骤自行复现至少一次，确认可重复	必填	复现概率
环境信息	已填写产品版本或构建号	必填	版本号
	已填写设备、操作系统、浏览器及版本	必填	运行环境
	已说明相关配置与数据条件（开关、租户、数据集）	必填	配置说明
日志与证据	已附关键日志片段，并标注时间点	按类型	附件、日志
	截图或录屏能对应到具体步骤与现象	按类型	附件
	附加数据（请求、报文、样本文件）已提供或说明获取方式	按类型	附件、备注
敏感信息处理	账号、密钥、令牌已替换为占位符	必填	全文、附件
	个人信息与客户数据已脱敏或改为示例数据	必填	全文、附件
	截图与日志中可见的敏感字段已遮挡	必填	附件

表格中的“按类型”表示该核对项在部分缺陷类型中必须执行，具体取舍见第三节。复制使用时，建议保留分组列，便于提交人按顺序检查，也便于后续按组统计漏填情况。

核对项字段说明

核对项写得再全，如果判断标准模糊，填写人仍会凭感觉勾选。下面按分组说明每项要检查什么、依据什么判断，与上表逐项对应。

缺陷描述类

现象描述要能让未参与该功能的同事读懂：在哪个页面、执行什么操作后出现了什么结果。判断依据是“不看截图能否复述问题”。预期结果与实际结果要分开写，避免只写“不正常”“有问题”这类无法验证的表述。影响范围写清受影响的用户群体、功能模块和数据，例如“所有使用批量导入的运营账号，导入记录会重复写入”，这比“影响较大”更有助于后续判断处理顺序。

复现步骤类

前置条件包括测试账号、权限、已准备的数据和必要的开关状态。操作步骤按 1、2、3 编号，每步只描述一个动作，避免把“打开页面并点击保存后刷新”合并成一步。可重复性的判断标准是：提交人自己按步骤从头执行至少一次，结果与描述一致；偶发问题则记录复现次数与尝试次数，例如“5 次尝试出现 3 次”，并说明是否与特定数据或时序有关。

环境信息类

版本信息要精确到构建号或发布批次，仅写“最新版”无法定位。设备与浏览器信息包括型号、操作系统版本、浏览器及版本；移动端还需注明网络环境。配置与数据条件指影响该问题的功能开关、租户或组织、数据集规模等。环境信息的目标是让其他人能在相同条件下复现，缺少任一项都可能导致“我这边没问题”的往返。

日志与证据类

日志片段应截取与问题时间点相关的部分，标注发生时间、时区和日志级别，避免整份文件直接上传。截图要能对应到具体步骤，必要时在图上标注点击位置或异常区域；录屏适合描述多步交互或时序问题。附加数据如请求报文、样本文件，若无法直接提供，应写明获取方式和联系人。证据的作用是缩短定位时间，因此“有附件”不等于“证据有效”，需要核对附件是否指向同一问题。

敏感信息类

检查范围包括缺陷正文、附件、截图和日志。账号、密钥、令牌、会话标识应替换为占位符；个人信息如姓名、手机号、身份证号、地址应脱敏或改为示例数据；客户业务数据应替换为构造数据，确需保留真实数据时按团队的数据管理规定处理。判断标准是：把缺陷单转发给无关同事，是否会造成信息泄露风险。

必填与选填的划分

清单过重会让人跳过核对，过轻则漏掉关键信息。划分原则是：缺少后无法定位或无法复现的项设为必填，缺少后只影响定位效率的项按缺陷类型裁剪。

核对项	划分	说明
现象、预期与实际结果、影响范围	必填	缺少任一项，接收人无法判断问题性质
前置条件、操作步骤、复现概率	必填	缺少则无法独立复现
版本、设备与浏览器、配置与数据条件	必填	环境不明时复现结果不可比
敏感信息脱敏	必填	涉及信息安全，任何类型都不豁免
日志片段	按类型	性能、数据、接口类缺陷必附；纯文案或样式问题可不附
截图或录屏	按类型	界面与交互类必附；后端异常可用日志替代
附加数据	按类型	数据错误、导入导出类问题必附样本
关联需求或测试用例	选填	有助于追溯背景，不作为提交门槛

按缺陷类型裁剪时，可参考以下原则：界面类以截图和浏览器信息为重点，日志可省；性能类必须附时间点、数据规模和耗时数据，截图作用有限；数据类必须附样本数据与操作前后的对比；兼容性类必须写清设备矩阵中出问题的组合与正常组合。裁剪只针对“按类型”项，必填项不因类型不同而取消。

不适用项要显式标注“不适用”并写明原因，例如“纯文案修改，无日志可附”。留空会被后来人误读为漏填，也会让统计口径失真。核对结果列同理，不允许空白提交。

填写示例：一条完整缺陷的清单

以下示例为演示情景，用于说明清单如何逐项核对，产品与数据均为虚构。

分组	核对项	示例填写内容	核对结果
缺陷描述	实际现象	在订单列表页使用“批量导出”后，导出文件中的订单金额全部显示为 0	通过
缺陷描述	预期与实际差异	预期导出金额与列表一致；实际全部为 0，列表显示正常	通过
缺陷描述	影响范围	所有使用批量导出的运营账号，单次导出 50 条以上时出现	通过
复现步骤	前置条件	运营角色账号，订单列表存在 50 条以上测试订单	通过
复现步骤	操作步骤	1. 登录测试环境；2. 进入订单列表；3. 勾选 60 条订单；4. 点击批量导出；5. 打开导出文件查看金额列	通过
复现步骤	可重复性	按上述步骤执行 3 次，3 次均出现	通过
环境信息	版本	测试环境 2.8.0-rc3	通过
环境信息	设备与浏览器	Windows 11，Chrome 126	通过
环境信息	配置与数据	默认配置，测试租户，订单数据为构造数据	通过
日志与证据	日志片段	已附导出任务日志，标注 14:32 时间点，含导出任务 ID	通过
日志与证据	截图或录屏	已附列表金额截图与导出文件金额列截图各一张	通过
日志与证据	附加数据	已附脱敏后的导出文件样本	通过
敏感信息	账号与密钥	日志中的会话令牌已替换为 ***	通过
敏感信息	个人信息与客户数据	订单中的收件人姓名、电话已替换为示例值	通过
敏感信息	截图遮挡	截图中的账号栏已打码	通过

示例中每一项都能在第一节模板和第二节说明中找到对应位置。若某项核对结果为“不通过”，处理方式是先补齐信息再提交，而不是在缺陷单里写“待补充”。例如日志时间点缺失时，回到系统重新截取并标注后再勾选通过；敏感信息未脱敏时，替换后重新上传附件，旧附件应删除或替换，避免残留。

清单的调整与维护方法

清单上线后需要随缺陷类型分布、团队反馈和缺陷单字段变化持续修订，否则会逐渐变成形式化勾选。维护可以从触发条件、版本同步、抽样检查和变更通知四个方面入手。

新增或删除核对项的触发条件

出现以下情况时考虑调整清单：同一类信息在一个月内被多次追问补充，说明该项应前置为核对项；某核对项连续多个周期全部通过且从未拦截问题，可评估合并或降为选填；缺陷单新增或调整字段后，核对项的“填写位置/字段”列需同步更新。调整时一次只改少量条目，便于观察效果。

与缺陷单字段和模板版本同步

清单中的字段名称应与缺陷单实际字段保持一致，字段改名或拆分后，清单同步修订并更新版本号。建议在清单页脚记录版本号、修订日期和修订人，缺陷单模板引用清单时注明所依据的版本，避免新旧版本混用导致核对口径不一致。

定期抽样检查执行情况

每月抽取一定数量的已提交缺陷，检查必填项是否真实填写、不适用项是否写明原因、敏感信息是否处理到位。抽样结果按分组统计漏填率，漏填率高的分组优先修订说明或调整必填划分。抽样只用于改进清单，不用于评价个人。

变更记录与通知

每次修订保留变更记录，格式可采用“版本号、日期、变更内容、变更原因、影响范围”。修订后在团队例会上说明变化点，并更新缺陷单模板中的引用。涉及必填项增减的变更，应给出一段过渡期，过渡期内新旧口径并行，避免提交人因规则突变而集中返工。

清单最终要落到缺陷单的提交环节才能发挥作用。在 ONES Project 中，缺陷可作为工作项在项目或迭代内提交和跟踪，支持一键提交 Bug 并记录修复情况，也可与 TestCase 数据互通。团队可以把清单中的必填项对应到缺陷单字段，把核对结果作为提交前的确认动作；字段调整时，按上述维护规则同步更新清单版本，使模板与实际提交入口保持一致。

常见问题

清单里的核对项和缺陷单字段必须一一对应吗？

建议保持对应。核对项的“填写位置/字段”列如果指向缺陷单中不存在的字段，提交人只能把信息写进备注，后续统计和检索都会变困难。落地时先确认缺陷单有哪些字段可用，再把核对项映射过去；字段改名或拆分后，同步修订清单并更新版本号。若某个核对项暂时没有对应字段，可先放在描述或备注中，并在清单中注明位置，待字段调整后再迁移。

偶发缺陷的复现概率怎么写才算合格？

写清尝试次数与出现次数，例如“5 次尝试出现 3 次”，并补充是否与特定数据、账号、时段或操作顺序有关。只写“偶现”无法帮助定位，也无法判断修复后是否真正解决。若多次尝试均未复现，应在清单中标注“未能复现”并说明已尝试的条件，而不是勾选通过。

日志和截图属于按类型项，什么情况下可以都不附？

纯文案修改或样式微调类缺陷，在描述和复现步骤足以说明问题时，可以不附日志和截图。界面与交互类缺陷通常需要截图对应到具体步骤；性能、数据、接口类缺陷需要日志或样本数据支撑。裁剪时以“接收人能否据此定位”为判断标准，并在不适用项写明原因，例如“纯文案修改，无日志可附”。

敏感信息脱敏做到什么程度可以提交？

判断标准是：把缺陷单转发给无关同事，是否会造成信息泄露风险。账号、密钥、令牌、会话标识替换为占位符；姓名、手机号、身份证号等个人信息脱敏或改为示例数据；客户业务数据替换为构造数据。检查范围覆盖正文、附件、截图和日志，截图中的账号栏、日志中的令牌都要处理。替换附件后应删除旧附件，避免残留。

清单修订后，新旧版本并行期间怎么执行？

涉及必填项增减的修订，建议设置一段过渡期，过渡期内新旧口径并行，提交人可按原清单提交，新提交逐步适用新版本。清单页脚记录版本号、修订日期和修订人，缺陷单模板引用清单时注明所依据的版本。过渡期结束后统一按新版本执行，并在团队例会上说明变化点，减少集中返工。