缺陷提交前核对清单模板：描述、复现步骤、环境与日志

缺陷提交前核对清单可以做成一张五区块表格：缺陷描述、复现步骤、环境信息、日志证据、敏感信息处理。每个核对项标注必填或选填、通过标准和责任人，提交人逐项勾选后提交，复核人用同一张表检查。本文给出可直接复制的空白模板、逐项字段说明、必填与选填的划分建议、一条完整填写示例，以及清单上线后的维护方法，适用于使用缺陷表单、工单系统或表格工具记录缺陷的团队。

要点总览（TL;DR）

• 清单按缺陷描述、复现步骤、环境信息、日志证据、敏感信息处理五个区块组织，每项标注必填/选填、通过标准与勾选栏，提交人逐项勾选后提交。
• 必填最低集合是现象描述、复现步骤、环境版本、证据附件；复现频率、影响范围、关联工单可先设为选填，偶发或跨模块缺陷再收紧。
• 勾选代表已按通过标准完成检查：描述只写观察结果，步骤可被他人照做，版本与构建号对应测试包，日志保留时间、级别与错误码。
• 敏感信息检查覆盖正文、附件与截图，密码、令牌、个人信息需脱敏后再提交；复核人用同一张表判断通过或退回补充。
• 清单上线后按退回原因增删核对项，维护版本号与更新记录，并定期抽样复核已提交缺陷的完整性。

可复制空白核对清单模板

下表可直接复制到缺陷表单说明、在线文档或表格工具中。使用时保留表头，按缺陷实际情况逐行填写“勾选”列；不适用的选填项在备注中说明原因，不要留空。

区块	核对项	必填/选填	通过标准	勾选
缺陷描述	一句话标题	必填	包含对象、动作和异常现象，20字左右可读	□
缺陷描述	现象描述	必填	说明用户看到什么异常，不含推测原因	□
缺陷描述	预期结果	必填	写明按需求或常识应出现的结果	□
缺陷描述	实际结果	必填	与预期结果逐点对应，可引用截图	□
缺陷描述	影响范围	选填	说明受影响的用户、模块或数据范围	□
复现步骤	前置条件	必填	账号角色、数据状态、开关配置等准备条件齐全	□
复现步骤	操作序列	必填	按顺序编号，每步一个动作，可被他人照做	□
复现步骤	复现频率	选填	注明尝试次数与成功次数，如“5次中3次”	□
环境信息	产品版本与构建号	必填	填写版本号或构建标识，与测试包一致	□
环境信息	操作系统与浏览器	必填	写明系统版本、浏览器及版本，客户端写明设备型号	□
环境信息	账号与数据条件	必填	说明测试账号角色、租户或数据集，不写真实密码	□
日志证据	日志片段	必填	截取异常前后关键行，保留级别与错误码	□
日志证据	截图或录屏	必填	画面能看清异常位置，录屏覆盖完整操作路径	□
日志证据	时间戳与请求标识	选填	记录发生时间、时区及请求ID或追踪号	□
敏感信息	账号密码与令牌	必填	正文与附件中无明文密码、密钥、访问令牌	□
敏感信息	个人信息与客户数据	必填	姓名、手机号、邮箱、地址等已打码或替换为示例值	□
敏感信息	附件与截图检查	必填	逐张检查截图、日志文件，确认无未脱敏内容	□

签署栏：提交人＿＿＿＿ 提交日期＿＿＿＿ 复核人＿＿＿＿ 复核日期＿＿＿＿ 复核结论：□通过 □退回补充

每个核对项在查什么：字段说明

勾选代表填写人已经完成该项检查，并确认内容达到通过标准。下表逐项说明判断依据，填写时对照检查，复核时按同一口径判断。

核对项	在查什么	判断依据
一句话标题	能否让接手人快速定位问题	标题含模块名与异常动作，避免“页面有问题”这类笼统表述
现象描述	异常是否被准确陈述	只写观察到的结果，原因推测放到备注，避免与事实混淆
预期结果	判断标准是否明确	能指向需求文档条款、设计稿或行业通用规则
实际结果	与预期的差异是否清楚	逐条对应预期结果，差异点可被截图或日志佐证
影响范围	修复优先级判断是否有依据	写明受影响的功能入口、用户角色或数据条数
前置条件	他人能否搭建同样的起点	账号、权限、数据、开关状态逐项列出，缺一不可
操作序列	步骤是否可执行、可复现	每步一个动作，含输入值；避免“正常操作后出错”
复现频率	问题稳定程度	记录尝试次数与出现次数，偶发问题注明观察时间窗
版本与构建号	问题定位到具体代码版本	与测试包发布记录一致，避免只写“最新版”
操作系统与浏览器	是否与运行环境相关	写全系统版本、浏览器内核版本；移动端写设备与系统
账号与数据条件	数据依赖是否交代	说明账号角色与数据来源，用测试账号替代真实账号
日志片段	是否有可分析的错误线索	保留时间、级别、错误码和堆栈关键行，避免只贴一行“报错”
截图或录屏	视觉证据是否完整	截图含操作入口与异常提示；录屏从操作起点到异常出现
时间戳与请求标识	能否在服务端日志中检索	记录发生时间与时区，附请求ID、追踪号或订单号
账号密码与令牌	凭证是否泄露	正文、附件、日志中均无明文密码、密钥、Cookie
个人信息与客户数据	是否包含可识别个人的信息	姓名、电话、证件号、地址已打码，或替换为构造数据
附件与截图检查	脱敏是否覆盖全部材料	逐张查看截图与日志文件，注意画面角落和日志头部

必填与选填的划分

必填项的最低集合是：现象描述、复现步骤、环境版本、证据附件。这四类信息决定缺陷能否被定位和复现，缺失时接手人需要反复追问，修复周期被拉长。其余核对项按团队流程设为选填。

类别	核对项	默认设置	调整说明
必填最低集合	现象描述、预期与实际结果、操作序列、版本与构建号、日志或截图	必填	任何缺陷类型都保留
可设为选填	复现频率、影响范围、关联需求或工单	选填	偶发缺陷、跨模块缺陷建议改为必填
按类型调整	界面类缺陷强化截图与浏览器信息；接口类缺陷强化日志、请求标识与时间戳；数据类缺陷强化账号与数据条件	按类型	在表单中按缺陷类型显示不同必填项
缺失处理	必填项缺失时退回补充，不进入修复队列	规则	复核人注明缺失项，提交人补齐后重新勾选

调整必填范围时遵循一个原则：缺少该项会导致接手人无法独立复现或无法判断修复结果，就设为必填；只影响优先级排序或统计分析的项，保持选填。团队初期可只保留最低集合，运行一段时间后根据退回原因补充。

填写示例：一条完整缺陷记录

以下示例为演示情景，展示清单逐项落地后的样子，字段与空白模板一一对应。

核对项	填写内容	勾选
一句话标题	订单列表页按金额筛选后分页跳转回第一页	☑
现象描述	在订单列表选择“金额从高到低”排序，翻到第3页后点击任一订单返回列表，页码重置为第1页，排序条件保留	☑
预期结果	返回列表后停留在第3页，排序与筛选条件不变	☑
实际结果	返回后显示第1页数据，排序条件仍为金额降序	☑
影响范围	订单管理模块列表页，影响使用排序后翻页查看的用户	☑
前置条件	测试账号 demo_operator，角色为订单管理员，租户内订单数据不少于60条	☑
操作序列	1. 登录并进入订单列表；2. 选择金额降序排序；3. 翻至第3页；4. 点击任一订单进入详情；5. 点击返回	☑
复现频率	5次尝试均复现	☑
版本与构建号	版本 3.8.2，构建号 20240612.3	☑
操作系统与浏览器	Windows 11，Chrome 125；另在 Edge 125 复现	☑
账号与数据条件	测试租户 tenant_demo，订单数据为构造数据，无真实客户信息	☑
日志片段	前端控制台记录：列表请求参数 page=1，排序参数保留；时间 2024-06-13 10:22:31	☑
截图或录屏	录屏 40 秒，覆盖排序、翻页、进入详情、返回全过程	☑
时间戳与请求标识	2024-06-13 10:22:31（UTC+8），请求ID req-7f3a91	☑
账号密码与令牌	正文与录屏中无密码、无令牌，登录过程已剪除	☑
个人信息与客户数据	订单中的收件人姓名、电话已替换为示例值	☑
附件与截图检查	逐帧检查录屏与日志截图，画面无未脱敏信息	☑

复核意见示例：“信息完整，可进入修复队列。建议补充后端分页参数日志，便于定位是前端状态丢失还是接口返回页码错误。”复核结论勾选“通过”，并注明补充建议不阻塞流转。

当缺陷记录需要承载字段、附件和状态流转时，可以把清单中的核对项落到工作项字段：描述、复现步骤、环境信息作为必填字段，日志与录屏作为附件，敏感信息检查作为提交前的人工确认项。ONES 的工作项支持自定义字段、附件与状态流转，团队可将上述核对项配置为提交时的必填校验，让清单从文档变成表单约束。

清单的调整与维护方法

清单上线后需要定期回看，避免核对项与实际缺陷类型脱节。以下规则可作为维护起点。

维护事项	触发条件	处理动作	责任人
核对项增删	同类缺陷连续出现退回补充；新增缺陷类型；团队引入新的日志或监控手段	评估后增删核对项，同步更新字段说明与示例	测试负责人
版本同步	缺陷表单字段调整；工作项模板变更	清单版本号加一，与表单字段逐项对照	测试负责人与工具管理员
抽样复核	每月或每季度	抽取已提交缺陷，按清单检查完整性，统计缺失项分布	质量负责人
更新记录	每次修改	记录版本号、修改内容、生效日期与影响范围	清单维护人

更新记录表可采用“版本号｜修改日期｜修改内容｜修改人｜生效范围”五列，每次调整后追加一行，旧版本保留归档，便于追溯某条缺陷提交时适用的核对标准。抽样复核的结果用于判断哪些核对项长期被跳过：连续多次缺失的项，要么改为必填并加强提示，要么从清单中删除，保持清单精简可用。

常见问题

缺陷提交后才发现日志里有明文令牌，应该怎么处理？

先撤回或标记该缺陷记录，替换附件与正文中的敏感内容，再重新提交。处理时同步检查同一批次提交的其他缺陷，确认是否使用了同一份未脱敏日志。若令牌已暴露在可被多人查看的系统中，按团队安全流程更换凭证，并在更新记录中注明本次脱敏修正，避免同类问题重复出现。

偶发缺陷复现频率低，复现步骤写不完整时还能提交吗？

可以提交，但要在复现步骤中写明已尝试的操作序列和观察时间窗，把复现频率从选填改为必填，记录尝试次数与出现次数。前置条件尽量列全，包括账号、数据状态和开关配置。复核人可据此判断是否需要补充监控或日志，而不是直接退回。偶发缺陷长期无法复现时，建议附上时间戳与请求标识，便于在服务端日志中检索。

不同缺陷类型是否要用同一张清单？

可以共用一张基础清单，再按类型调整必填项。界面类缺陷强化截图与浏览器信息，接口类缺陷强化日志、请求标识与时间戳，数据类缺陷强化账号与数据条件。调整时保持字段说明与空白模板一致，避免填写人按旧口径勾选。团队初期可只保留必填最低集合，运行一段时间后根据退回原因补充类型化核对项。

复核人退回补充时，应该指出哪些内容？

复核人按清单逐项对照，注明缺失或未达通过标准的具体核对项，例如“操作序列缺少输入值”“日志片段未保留错误码”“截图未脱敏”。退回意见指向可修改的动作，提交人补齐后重新勾选对应项。若缺失项属于选填内容，复核人可注明建议补充但不阻塞流转，避免把选填项当成退回理由。

清单维护多久回看一次比较合适？

建议每月或每季度抽样复核一次已提交缺陷，统计哪些核对项长期被跳过或反复缺失。出现同类缺陷连续退回、新增缺陷类型、团队引入新的日志或监控手段时，触发核对项增删评估。每次修改同步更新版本号、字段说明与填写示例，旧版本保留归档，便于追溯某条缺陷提交时适用的核对标准。