缺陷验证记录把“修复提交—验证执行—结论与关闭”串成一条可追溯的记录。最小可用版本包含缺陷编号、缺陷描述、严重程度、修复人、修复说明、提交验证时间、验证人、验证环境与版本、验证步骤与结果、验证结论、关闭状态和备注。下面先给一张可直接复制到表格工具或缺陷系统的空白表，再逐字段说明填写口径、必填取舍，并用一条完整记录示范通过和不通过两种写法。
要点总览（TL;DR）
- 缺陷验证记录的最小字段集：缺陷编号、缺陷描述、严重程度、修复人、修复说明、提交验证时间、验证人、验证环境与版本、验证步骤与结果、验证结论、关闭状态，备注按需填写。
- 除备注外，其余字段均为必填；缺任一项，记录无法回答“谁修的、在什么版本验的、结论是什么”，不能作为关闭依据。
- 验证结论限定为通过、不通过、部分通过三档：通过对应已关闭，不通过和部分通过对应退回修复，尚未验证保持待验证。
- 不通过时在备注写清复现条件和未覆盖路径，让修复人知道下一轮改哪里；部分通过不能直接关闭缺陷。
- 模板调整以“是否影响复核和流转”为判断标准，保留版本号与变更说明，历史记录按当时版本解读。
可直接复制的缺陷验证记录空白模板
下表为空白模板，复制到 Excel、在线表格或缺陷系统的自定义字段中即可使用。一行对应一条缺陷的一次验证；同一缺陷多次验证时，保留多行并共用缺陷编号，便于追溯每一轮的修复与验证过程。
| 缺陷编号 | 缺陷描述 | 严重程度 | 修复人 | 修复说明 | 提交验证时间 | 验证人 | 验证环境与版本 | 验证步骤与结果 | 验证结论 | 关闭状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
模板覆盖三个连续环节：修复人填写修复说明并提交验证，验证人记录环境、步骤与结果并给出结论，结论决定关闭状态。若团队使用缺陷系统，可将这些列映射为工作项字段；若暂用表格，建议固定表头并锁定首行，避免多人编辑时列错位。
每个字段记录什么：字段说明与填写口径
字段说明的作用是让不同的人填出同一种口径。下表按“标识与描述、修复与验证过程、结论与状态、时间与责任人”四组给出含义、取值示例和常见错误。
| 字段名 | 含义 | 取值示例 | 易错点 |
|---|---|---|---|
| 缺陷编号 | 缺陷的唯一标识，与缺陷系统中的编号一致 | BUG-2024-0317 | 手写临时编号，与系统编号对不上，后续无法回溯 |
| 缺陷描述 | 现象、触发条件和预期结果的简要说明 | 订单列表按金额排序后，第二页数据重复出现 | 只写“列表有问题”，缺少触发条件，验证人无法判断是否复现 |
| 严重程度 | 缺陷对业务的影响等级 | 严重 / 一般 / 轻微 | 按修复难度定级，而非按业务影响定级 |
| 修复人 | 实际提交修复的责任人 | 张明 | 填写缺陷发现人或模块负责人，导致验证时找不到修复说明 |
| 修复说明 | 改了什么、影响范围、是否需要特殊验证 | 修正分页参数偏移，涉及订单列表与导出两处调用 | 只写“已修复”，验证人不知道要重点验证哪些路径 |
| 提交验证时间 | 修复完成并进入待验证的时间 | 2024-03-18 14:20 | 填成缺陷创建时间，无法计算修复到验证的间隔 |
| 验证人 | 执行验证的责任人，通常为测试人员 | 李婷 | 由修复人自己验证并签字，缺少独立确认 |
| 验证环境与版本 | 验证所用的环境、构建号或版本号 | 测试环境，构建 2.7.1-rc3 | 只写“测试环境”，版本变化后无法判断结论对应哪次构建 |
| 验证步骤与结果 | 按步骤记录操作与观察到的结果 | 1. 进入订单列表；2. 按金额排序；3. 翻至第二页——数据无重复，符合预期 | 只写“验证通过”，没有步骤，结论无法复核 |
| 验证结论 | 本轮验证的判定结果 | 通过 / 不通过 / 部分通过 | 写成“基本没问题”“待观察”等模糊表述，无法驱动状态流转 |
| 关闭状态 | 缺陷当前所处状态 | 已关闭 / 退回修复 / 待验证 | 结论为不通过却把状态写成已关闭，记录自相矛盾 |
| 备注 | 补充信息，如关联缺陷、遗留风险、复现条件 | 不通过：第二页正常，导出文件仍重复，见 BUG-2024-0319 | 把关键复现条件只写在聊天记录里，未落到记录中 |
填写时把握两条口径：验证步骤要写到他人可照着复现，验证结论要落到三档取值之一。描述类字段写现象和条件，过程类字段写动作和观察结果，两者不要混在同一格里。
必填与选填：哪些字段不能空
必填项决定这条记录能否支撑关闭决策。缺任何一项，记录都无法回答“谁修的、在什么版本验的、结论是什么”，应视为不可用记录，不能作为关闭依据。
必填字段清单
- 缺陷编号：没有唯一标识，记录无法与缺陷条目对应。
- 缺陷描述：验证人需要据此判断现象是否消失。
- 严重程度：决定验证深度和是否允许带风险关闭。
- 修复人：不通过时需要明确退回对象。
- 修复说明：指明影响范围，验证才能覆盖相关路径。
- 提交验证时间：用于计算修复到验证的周期。
- 验证人：独立确认的责任主体。
- 验证环境与版本：结论只对特定构建有效，缺版本则结论不可复核。
- 验证步骤与结果：结论的依据。
- 验证结论：驱动关闭或退回的唯一判定。
- 关闭状态：记录当前流转位置。
选填字段及适用场景
- 备注：结论为不通过、部分通过，或存在遗留风险、关联缺陷时填写；一次通过的简单缺陷可留空。
按缺陷类型增减字段
字段可随缺陷类型调整，调整时保持必填骨架不变。界面显示类缺陷建议在验证步骤中固定写入截图或录屏位置；性能类缺陷建议在备注中补充压测数据与阈值；兼容性缺陷建议把验证环境与版本细化为设备、浏览器与系统版本组合；涉及多模块联调的缺陷，可在备注中列出联动验证的模块清单。增减字段的判断标准是：该字段是否影响他人复核结论。影响则纳入必填，仅作补充说明则留在备注。
当缺陷记录进入系统管理，验证交接和状态流转需要落到具体工作项上。ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；ONES 测试管理支持一键创建并关联缺陷，让成员围绕缺陷协作。团队可将上述字段映射为缺陷工作项的属性，把“待验证、退回修复、已关闭”对应到状态流转中，验证结论与状态保持一致。具体字段配置与状态取值以团队实际使用的版本和配置为准。
完整填写示例：一条缺陷从修复到关闭
以下为演示情景，数据为示例，用于说明各字段如何配合。同一条缺陷经历一次不通过和一次通过，保留两行记录。
| 缺陷编号 | 缺陷描述 | 严重程度 | 修复人 | 修复说明 | 提交验证时间 | 验证人 | 验证环境与版本 | 验证步骤与结果 | 验证结论 | 关闭状态 | 备注 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| BUG-2024-0317 | 订单列表按金额排序后，第二页数据重复出现 | 严重 | 张明 | 修正分页参数偏移，涉及订单列表与导出两处调用 | 2024-03-18 14:20 | 李婷 | 测试环境，构建 2.7.1-rc3 | 1. 进入订单列表；2. 按金额排序；3. 翻至第二页——列表数据无重复；4. 导出当前列表——导出文件第二页仍出现重复行 | 不通过 | 退回修复 | 列表已修复，导出路径未覆盖；复现条件：排序后导出且数据超过一页 |
| BUG-2024-0317 | 订单列表按金额排序后，第二页数据重复出现 | 严重 | 张明 | 补充修正导出模块的分页参数，与列表共用同一分页逻辑 | 2024-03-19 10:05 | 李婷 | 测试环境，构建 2.7.1-rc4 | 1. 进入订单列表；2. 按金额排序；3. 翻至第二页——无重复；4. 导出当前列表——导出文件无重复行；5. 切换升序、降序各验证一次——结果一致 | 通过 | 已关闭 | 已覆盖列表与导出两条路径 |
不通过的写法要点：结论写“不通过”，状态写“退回修复”，备注写清复现条件和未覆盖的路径，让修复人知道下一轮改哪里。通过的写法要点：步骤覆盖修复说明中提到的全部影响范围，结论写“通过”，状态写“已关闭”。若部分路径通过、部分未通过，结论取“部分通过”，状态保持“退回修复”，并在备注中分别列出已通过和未通过的路径，避免用“部分通过”直接关闭缺陷。
结论与状态必须一致：通过对应已关闭，不通过和部分通过对应退回修复，尚未开始验证则保持待验证。出现结论与状态不一致时，以验证步骤与结果为依据修正状态，而不是修改结论去迁就状态。
模板的调整与维护方法
模板用起来之后，调整应围绕“是否影响复核和流转”展开，避免每次项目变化都重做表头。可按以下要点操作。
- 字段增删的判断依据：某类缺陷反复因缺少同一信息导致验证争议，就把该信息升为字段；某字段长期为空且不影响结论复核，可并入备注或删除。每次只调整一到两个字段，观察一个迭代再决定是否保留。
- 模板版本与变更记录：在模板文件或系统说明中保留版本号和变更说明，记录调整日期、调整字段、调整原因。历史记录按当时版本解读，不回溯改写已关闭缺陷的字段内容。
- 与缺陷状态流转的对应关系：明确每个状态由谁触发、需要哪些字段已填写。例如进入待验证前，修复说明和提交验证时间必须完整；进入已关闭前，验证结论必须为通过且验证环境与版本已填。状态与字段的对应关系写入团队填写规范，减少口头约定。
- 定期复核：每个版本周期抽查若干条已关闭记录，检查验证步骤是否可复现、结论与状态是否一致，把发现的问题反馈到模板调整中。
模板维护的边界需要说清：变更后的整体回归测试安排、具体代码修复方法和缺陷根因分析属于相邻流程，不在本模板范围内，可在备注中引用对应记录，避免把验证记录写成修复日志或测试计划。
常见问题
同一缺陷多轮验证，记录应该新增一行还是覆盖原记录？
建议新增一行，共用同一个缺陷编号，每行对应一次验证。这样能保留每轮的修复说明、验证环境和结论，退回原因和修复过程都可追溯。覆盖原记录会丢失上一轮的不通过信息，后续复盘时无法判断问题是否反复出现。
如果使用缺陷系统，可在同一缺陷工作项下追加验证记录或评论，字段口径与表格保持一致。
验证人可以是修复人自己吗？
模板把验证人列为必填，目的是保留独立确认的责任主体。由修复人自己验证并签字，等于同一人对修复结果做判定，容易漏掉修复说明中未覆盖的路径。团队人手紧张时，至少安排同模块内另一位成员执行验证，并在备注中说明交叉验证的安排。
验证结论写“部分通过”后，缺陷能不能先关闭？
不建议。部分通过意味着仍有路径未达预期，状态应保持退回修复，并在备注中分别列出已通过和未通过的路径。直接关闭会让未通过部分失去跟踪，后续只能靠记忆或聊天记录找回。若未通过部分影响很小且团队决定带风险上线，应另建一条缺陷记录承接遗留问题，再关闭原缺陷。
验证环境与版本要写到什么颗粒度？
至少写到构建号或版本号，例如“测试环境，构建 2.7.1-rc3”。只写“测试环境”时，版本更新后无法判断结论对应哪次构建，复核时只能重跑。兼容性类缺陷还需补充设备、浏览器与系统版本组合；涉及配置差异的缺陷，把关键配置项一并写入。
把这张表搬进缺陷系统后，还需要维护表格模板吗？
可以以系统字段为主，表格模板作为字段口径说明保留。系统里配置缺陷工作项属性时，按模板的必填清单设置必填校验，把验证结论与状态流转绑定。表格模板继续用于新成员培训和字段变更讨论，两者保持同一套字段名，避免口头叫法和系统字段对不上。
ONES Project 支持一键提交 Bug 至对应项目或迭代，记录和跟踪缺陷修复情况，并可统计缺陷状态分布；ONES 测试管理支持一键创建并关联缺陷。团队可将模板字段映射为缺陷工作项属性，具体字段配置与状态取值以实际使用的版本和配置为准。
