缺陷验证记录要回答四个问题：缺陷是什么、修复改了什么、验证依据是什么、结论与后续动作是什么。一份可用的记录通常包含缺陷标识与严重程度、复现步骤与预期结果、修复说明与影响范围、验证环境与验证步骤、验证结论、证据附件和回归范围建议。下面以一条“订单金额显示错误”缺陷为例，给出完整填写示范，并逐项解释填写依据。示例中的项目、人员、编号均为演示情景，不代表真实客户案例。
要点总览（TL;DR）
- 缺陷验证记录要回答四件事：缺陷是什么、修复改了什么、验证依据是什么、结论与后续动作是什么，字段围绕这四件事组织。
- 示例以“订单金额显示错误”演示：修复说明写明改动点与影响范围，验证步骤就围绕优惠券、满减、无券三种金额场景展开，结论与证据一一对应。
- 严重程度按业务影响判断，优先级按排期紧迫性判断；复现步骤写到他人可独立执行，结论取通过、不通过、部分通过三种口径。
- 换缺陷类型时调整验证步骤重点：界面类看多环境展示，计算类补边界与组合用例，接口类核对参数与落库，权限类按角色分别执行。
- 一条验证记录对应一个缺陷的一次修复确认；整体回归归回归测试管理，批量验证按缺陷拆分记录，验证不通过在原记录续写。
示例目标：这份缺陷验证记录要解决什么问题
这份示例面向三类读者：提交修复的开发人员、执行验证的测试人员，以及需要依据记录判断能否关闭缺陷的负责人。它展示的是一份记录从缺陷描述、修复交接、验证执行到结论关闭的完整填写方式，帮助读者照着写出可独立阅读、可追溯的记录。
判断一份记录是否合格，可以看三个标准。第一，未参与该缺陷的人能否仅凭记录复现问题并执行验证；第二，修复说明能否让验证者判断应该重点检查哪些功能；第三，结论是否有对应的验证步骤和证据支撑，而不是只写一句“已验证”。
需要区分的是，验证记录聚焦单个缺陷的修复确认，回答“这个缺陷是否被修好、修得对不对”。变更上线前的整体回归范围规划、回归用例集维护属于回归测试管理的工作；具体代码怎么写、补丁如何提交属于开发环节。本文只讨论记录本身的填写，不展开这两部分内容。
完整示例：一条“订单金额显示错误”缺陷的验证记录
以下为演示情景中的已填写记录，项目名称、人员、编号均为虚构，用于说明字段之间的对应关系。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | BUG-2417（演示编号） |
| 缺陷标题 | 订单确认页在使用优惠券后，应付金额仍显示优惠前金额 |
| 所属模块 | 订单结算 / 优惠计算 |
| 严重程度 | 严重 |
| 优先级 | 高 |
| 发现版本与环境 | 演示商城 v3.2.0，测试环境，浏览器 Chrome 最新稳定版 |
| 复现步骤 | 1. 登录演示账号，加入一件单价 200 元的商品；2. 进入结算页，选择满 200 减 30 的优惠券；3. 点击“提交订单”进入确认页；4. 查看“应付金额”一栏 |
| 预期结果 | 应付金额显示 170 元，优惠明细显示“优惠券 -30 元” |
| 实际结果 | 应付金额显示 200 元，优惠明细已显示 -30 元，两处金额不一致 |
| 修复说明 | 确认页金额取值改为读取优惠计算后的最终金额字段；改动点为订单确认页金额渲染逻辑，涉及优惠券、满减两类优惠的金额汇总；影响范围为订单确认页与订单详情页的金额展示 |
| 修复提交 | 提交记录 fix/order-amount-2417（演示），由开发人员 A 提交，附改动说明 |
| 验证环境 | 演示商城 v3.2.1 修复包，测试环境，Chrome 与移动端浏览器各验证一次 |
| 验证数据 | 单价 200 元商品一件；满 200 减 30 优惠券一张；另备满 300 减 50 券与无券订单各一例 |
| 验证步骤 | 1. 按原复现步骤下单并查看确认页金额；2. 核对优惠明细与应付金额是否一致；3. 换用满 300 减 50 券重复一次；4. 提交无券订单核对金额；5. 进入订单详情页核对金额展示 |
| 验证结论 | 通过 |
| 证据附件 | 确认页金额截图 2 张（优惠券场景、满减场景）、订单详情页截图 1 张、验证操作录屏 1 段 |
| 回归范围建议 | 订单确认页与订单详情页的金额展示；优惠券与满减叠加场景；退款金额计算需在后续回归中一并覆盖 |
| 后续动作 | 缺陷状态置为“已验证关闭”；将金额展示相关场景补充进回归用例；通知产品确认退款页金额口径 |
这份记录的特点在于前后自洽：修复说明指出改动在金额渲染与优惠汇总，验证步骤就围绕优惠券、满减、无券三种金额场景展开；结论写“通过”，证据附件与验证步骤一一对应；后续动作既包含状态关闭，也包含回归用例补充和跨角色确认，避免缺陷关闭后遗留问题无人跟进。
逐项解释：每个字段为什么这样填
严重程度与优先级
严重程度描述缺陷对业务的影响，优先级描述修复的排期紧迫性，两者依据不同。本例中金额显示错误会直接影响用户下单判断，属于核心交易链路上的错误展示，因此严重程度填“严重”。优先级填“高”，是因为该问题出现在结算环节、用户可感知，且修复改动范围可控。若同类金额问题只出现在后台报表且不影响用户下单，严重程度可以下调，优先级也可随版本排期调整。填写时给出判断理由，比只选一个等级更有助于后续复盘。
复现步骤写到可独立执行
复现步骤的目标是让没接触过该缺陷的人照着操作就能看到问题。本例写明了账号类型、商品单价、优惠券门槛、操作路径和观察位置，读者不需要再询问“用的哪张券”“看哪个字段”。常见问题是步骤写成“下单后发现金额不对”，缺少前置数据和观察点，验证者只能凭猜测还原场景。
修复说明写清改动点与影响范围
修复说明服务于验证者判断检查重点。本例写明改动点是确认页金额渲染逻辑，涉及优惠券与满减两类优惠的汇总，影响范围包括确认页和订单详情页。验证者据此知道要覆盖两类优惠，并顺带检查详情页。只写“已修复”或只贴提交链接，验证者无法判断哪些场景需要重点验证。
验证步骤与验证数据对应缺陷场景
验证步骤应覆盖原复现路径，并补充修复影响范围内的相邻场景。本例除原优惠券场景外，增加了满减券和无券订单两个对照，用来确认金额计算在多种优惠组合下都正确；再检查订单详情页，对应修复说明中的影响范围。验证数据要写清具体金额和券门槛，保证他人可以复现同样的验证过程。
结论取值与证据要求
结论通常取“通过”“不通过”“部分通过”三种口径。“通过”要求验证步骤全部执行且结果符合预期；“部分通过”用于主场景已修复但相邻场景仍有问题，需要在记录中写明未通过的具体项；“不通过”则要附上失败现象和复现路径。证据附件与验证步骤对应，本例每个金额场景配截图，操作过程配录屏，便于结论被复核。
可迁移规律：换一个缺陷怎么套用这份记录
这份示例的结构可以迁移到其他缺陷，调整重点在验证步骤的写法。不同缺陷类型的验证关注点不同，可参照下表调整。
| 缺陷类型 | 验证步骤的调整重点 | 证据附件取舍 |
|---|---|---|
| 界面展示类 | 覆盖不同分辨率、浏览器与语言环境下的展示效果 | 各环境截图对比，标注差异位置 |
| 计算逻辑类 | 补充边界值、异常输入与多条件组合的对照用例 | 输入数据与计算结果的对照截图或日志 |
| 接口与数据类 | 核对请求参数、返回结果与数据落库的一致性 | 接口返回记录、数据查询结果 |
| 权限与流程类 | 按不同角色分别执行同一操作，核对可见范围与流转结果 | 各角色操作截图、流程状态变化记录 |
证据附件的取舍原则是“能支撑结论即可，不追求数量”。结论为通过时，附上关键场景的结果证据；结论为不通过时，附上失败现象和复现路径，便于开发定位。附件命名带上场景和步骤编号，复核时更容易对应。
结论与后续动作要成对出现。结论为通过，后续动作通常是关闭缺陷、补充回归用例、通知相关角色；结论为部分通过，后续动作是拆分未通过项另建记录或退回修复；结论为不通过，后续动作是退回开发并附失败证据。记录在缺陷流转中的状态衔接也应一致：修复提交后状态进入“待验证”，验证执行后进入“已验证”或“重新打开”，避免记录写完了状态却停在原处。
当团队在工具中管理缺陷时，这些字段可以直接落在工作项上：缺陷单承载标识、严重程度与复现步骤，修复提交与验证记录作为关联信息挂在同一工作项下，附件随验证结论一起留存，状态流转由工作项状态驱动。ONES 的工作项与文档协作能力可以承载这类记录方式，让修复提交、验证结论和回归建议在同一条缺陷记录中保持可追溯。是否采用工具承载，取决于团队已有的缺陷管理习惯和流程规范。
适用边界：哪些情况需要另建记录或转其他流程
本文示例适用于单个缺陷从修复提交到验证关闭的记录填写。以下情形需要另行处理。
- 变更上线前的整体回归：验证记录只确认单个缺陷的修复结果，整体回归的范围规划、用例执行与准入判断归回归测试管理，应另建回归计划或在发布流程中管理。
- 代码修复本身：本文不涉及具体代码修改方法、补丁提交规范和代码评审要求，这些属于开发流程。
- 跨多个缺陷的批量验证：一次修复涉及多个缺陷时，应按缺陷分别记录验证结论，共享的验证环境与验证数据可以在各记录中引用同一说明，避免把多个结论混写在一条记录里导致无法追溯。
- 验证不通过：在原记录中续写失败现象、复现路径和退回说明，保留原有修复信息，不另起一条新记录覆盖历史；若失败原因指向新的独立问题，再另建缺陷记录并关联原缺陷。
- 需求变更引发的重新验证：修复范围因需求调整而扩大时，应更新修复说明与影响范围，并补充对应的验证步骤，必要时由负责人重新确认验证范围。
把握这条边界的关键是：一条验证记录对应一个缺陷的一次修复确认。范围扩大、结论变化或问题拆分时，通过续写、关联或另建记录保持可追溯，而不是让一条记录承担多个流程的职责。
常见问题
验证结论写“部分通过”时，记录应该怎么续写？
“部分通过”用于主场景已修复、相邻场景仍有问题的情况。记录中要写明哪些验证步骤通过、哪些未通过，未通过项附上失败现象和复现路径，并给出后续动作：未通过项退回修复或另建缺陷记录，通过部分保留原证据。这样复核时能区分已确认修复的范围和仍待处理的范围，避免整条记录被笼统标成通过。
一次修复涉及多个缺陷，验证记录要合并成一条吗？
建议按缺陷分别记录验证结论。共享的验证环境和验证数据可以在各记录中引用同一说明，但结论要各自独立，否则后续追溯时无法判断某个缺陷是否真的验证过。如果多个缺陷的失败原因指向同一个新问题，可以另建一条缺陷记录并关联原缺陷，保持关联关系清晰。
验证不通过退回开发后，原记录需要清空重填吗？
不需要清空。在原记录中续写失败现象、复现路径和退回说明，保留原有修复信息，形成“修复—验证—退回”的完整过程。开发再次提交修复后，在同一记录中补充新的修复说明和验证步骤，状态从“重新打开”回到“待验证”。只有失败原因指向新的独立问题时，才另建缺陷记录并关联原缺陷。
缺陷关闭后，回归范围建议由谁跟进？
回归范围建议是验证记录的一部分，需要有人承接才能落地。常见做法是在记录中写明建议覆盖的场景，并在关闭缺陷时同步给负责回归用例维护的角色，由其在回归用例集中补充或更新对应场景。如果团队在工具中管理缺陷，可以把回归建议作为工作项的关联信息保留，状态关闭后仍可查到，避免建议停留在记录里无人处理。
记录里的证据附件需要保留多久、保留到什么粒度？
附件粒度以能支撑结论为准：通过时保留关键场景的结果证据，不通过时保留失败现象和复现路径。保留时长取决于团队的缺陷管理规范与版本追溯要求，本文不给出统一期限。实际操作中可以按版本或发布批次归档，附件命名带上场景和步骤编号，便于后续复核时与验证步骤对应。
