缺陷确认要收集的依据可以归为三类：能证明问题存在的事实证据，能说明预期是什么的标准依据，以及能判断影响和归属的信息。确认本身是一次受理决策，结论应当落到“成立进入修复、退回补充信息、转为需求变更或按非缺陷关闭”中的一种，并记录判断人、时间和所依据的材料。下面按判断框架、操作步骤、角色分工、示例和检查清单展开。
要点总览（TL;DR）
- 缺陷确认是一次受理决策，依据分为三类：证明问题存在的事实证据、说明预期标准的需求或设计依据、判断影响与归属的模块和责任人信息。
- 确认过程按接收初筛、复现验证、标准对照、影响与归属判断、给出结论并记录五步推进，每步都要留下可追溯的产物。
- 结论保持四种类型：成立进入修复、退回补充信息、转为需求变更、按非缺陷关闭；每种结论写明理由、判断人和时间。
- 报告人、测试、开发或模块负责人、产品负责人、分诊角色各自提供对应依据，分诊角色负责汇总和推动结论落地。
- 完成检查围绕证据完整性、标准对照留痕、影响与归属明确、结论可追溯和退回补充的阻断条件展开。
缺陷确认要回答的三个判断
缺陷确认发生在缺陷报告提交之后、进入修复之前。它要回答三个问题：问题是否真实发生，实际表现是否偏离了约定标准，以及影响多大、应由谁处理。三个问题都得到回答，确认才算完成；任何一个缺少依据，结论就应当停留在“退回补充信息”，而不是凭印象受理。
第一个判断是事实成立。依据是环境、版本、复现步骤、实际结果、日志、截图或录屏。最低要求是他人能按报告中的步骤在相同环境和版本下看到相同现象。偶发问题也应记录发生频率和已尝试的复现条件。
第二个判断是标准偏离。依据是需求条目、验收标准、设计说明、接口契约或已确认的原型。报告人认为“不对”只是线索，确认时需要指出实际表现与哪一条约定不一致。找不到对应约定时，应转由产品负责人判断是否属于需求变更或新增诉求。
第三个判断是影响与归属。依据是影响范围（受影响用户、功能、数据或版本）、严重程度、涉及模块和候选责任人。影响范围决定优先级，涉及模块决定由谁进一步判断技术可行性和修复归属。
| 判断 | 要回答的问题 | 最小依据清单 | 依据不足时的处理 |
|---|---|---|---|
| 事实成立 | 问题能否被复现和观察 | 环境、版本、复现步骤、实际结果、日志或截图录屏 | 退回报告人补充，或由测试角色协助复现 |
| 标准偏离 | 实际表现是否偏离约定预期 | 需求条目、验收标准、设计说明、接口契约 | 转产品负责人判断是否为需求变更 |
| 影响与归属 | 影响多大、涉及哪个模块和责任人 | 影响范围说明、严重程度判断、涉及模块、责任人 | 由模块负责人补充技术判断后再定结论 |
按步骤完成一次缺陷确认
确认过程可以固定为五步。每一步都有明确输入、动作、输出和完成标志，避免确认停留在口头讨论。团队规模较小时，同一个人可以承担多个步骤，但每步的产物仍应留下记录。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 接收与初筛 | 缺陷报告 | 检查环境、版本、步骤、实际结果、预期结果是否齐全 | 完整报告或退回补充通知 | 缺项已列明并退回，或报告进入复现队列 |
| 复现验证 | 完整报告、测试环境 | 在指定环境和版本下按步骤执行，记录实际结果 | 复现结论与补充证据 | 复现成功并附证据，或记录无法复现的尝试条件 |
| 标准对照 | 需求条目、验收标准、设计说明 | 比对实际表现与约定预期，标出偏离点 | 偏离说明及引用条目 | 能指出具体条款，或明确判定无对应约定 |
| 影响与归属判断 | 复现结果、模块信息 | 评估影响范围与严重程度，定位涉及模块和责任人 | 影响说明、严重程度、责任人 | 责任人和严重程度已确定，影响范围有描述 |
| 给出结论并记录 | 以上全部材料 | 选择结论类型，记录判断人、时间和依据 | 受理结论记录 | 结论类型明确，依据可追溯，判断人和时间完整 |
复现验证需要特别注意无法复现的情况。此时应记录尝试过的环境、版本、步骤和数据条件，再决定是退回报告人补充信息，还是保留观察继续排查。直接把无法复现的问题关闭，会让真实缺陷失去跟踪机会；无限期挂起同样会消耗分诊精力，因此需要给出明确的下一步和时限。
结论类型建议保持四种：成立并进入修复、退回补充信息、转为需求变更、按非缺陷关闭。每种结论都要写明理由。例如按非缺陷关闭时，应说明是环境配置问题、重复报告还是预期行为，便于后续回溯。
角色分工与各角色交付物
确认环节常见的卡点是“大家都知道要看，但没人对结论负责”。把依据提供、判断和记录分配到具体角色，可以减少来回追问。以下分工适用于有独立测试角色的研发团队；角色合并时，交付物要求不变。
| 角色 | 提供的依据 | 交付物 |
|---|---|---|
| 报告人 | 复现步骤、环境、版本、日志、截图或录屏、实际与预期结果 | 信息完整的缺陷报告 |
| 测试或质量角色 | 复现结果、补充证据、与需求或验收标准的对照结论 | 复现记录与偏离说明 |
| 开发或模块负责人 | 技术可行性判断、涉及模块与修复归属确认 | 归属结论与技术判断意见 |
| 产品负责人 | 需求预期解释、是否属于需求变更的判断 | 预期确认或需求变更结论 |
| 缺陷管理或分诊角色 | 汇总各方依据，检查完整性 | 受理结论记录，含判断人、时间与依据 |
分诊角色并不替代专业判断，它的职责是推动每个判断找到对应负责人，并确保结论和依据被记录下来。当报告人与开发对是否为缺陷存在分歧时，应以需求条目或验收标准为依据，由产品负责人给出预期解释，而不是由声音更大的一方决定。
示例：一条缺陷报告的确认过程
以下为演示情景，用于说明依据如何逐步补齐并形成结论。
原始报告写道：“订单列表页筛选日期后结果不对，请修复。”报告缺少环境、版本和具体步骤，预期结果也未说明。初筛时该报告被退回补充，退回通知列明需要补充的四项信息。
报告人补充后得到：测试环境、版本号、操作步骤为进入订单列表、选择近七天、点击查询；实际结果是列表出现七天前的订单；预期结果是仅显示近七天订单；附有截图和接口返回日志。测试角色在相同环境和版本下复现成功，并补充了另一组日期范围的结果，确认问题稳定出现。
标准对照阶段，测试角色找到订单列表的需求条目，其中写明“日期筛选按创建时间过滤，范围为所选区间”。实际结果与条目不符，偏离点明确。影响判断阶段，模块负责人确认问题涉及查询条件拼接，影响所有使用日期筛选的用户，严重程度定为高，责任人为订单模块开发。分诊角色汇总后给出结论：缺陷成立，进入修复，并记录判断人、时间、引用的需求条目和复现证据。
这个示例可迁移的规律是：报告信息不全时先退回而不是猜测；复现证据要能被他人重复；标准对照必须落到具体条目；影响和归属由了解模块的人确认；结论与依据一起记录。
确认环节的完成检查
确认质量可以通过逐项核对来保证。以下清单可用于分诊角色自查，也可用于团队定期抽查已受理缺陷的记录质量。
- 证据完整性：环境、版本、复现步骤、实际结果、预期结果齐全；日志、截图或录屏能支撑结论。
- 复现留痕：复现成功时附结果；无法复现时记录尝试过的条件和后续安排。
- 标准对照留痕：引用了具体需求条目、验收标准或设计说明；无对应约定时有产品负责人的判断记录。
- 影响与归属明确：影响范围有描述，严重程度已判定，涉及模块和责任人已确定。
- 结论明确可追溯：结论属于四种类型之一，写明理由、判断人和时间。
- 退回补充的阻断条件：报告缺少复现信息、缺少预期结果或无法定位对应标准时，不应直接受理进入修复。
检查中发现缺项时，应退回对应角色补充，而不是由分诊角色代为填写判断。定期抽查可以暴露反复出现的缺项类型，例如报告人普遍不写版本，进而在提交入口增加必填提示。
用工作项承载确认依据与结论
上述证据、判断和结论如果散落在聊天记录和邮件里，回溯成本很高。把缺陷作为工作项管理，可以让依据与结论跟随同一条记录流转。ONES Project 支持缺陷跟踪管理，并与 TestCase 数据互通、支持一键提 Bug，缺陷可提交至对应项目或迭代中记录和跟踪修复情况；ONES TestCase 支持测试用例与需求、任务关联，未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。这些能力适合承载确认环节的以下动作。
报告与证据阶段，在缺陷工作项中记录环境、版本、复现步骤和实际结果，并附上日志、截图或录屏，使复现条件与问题描述放在同一处。判断阶段，用字段记录严重程度、影响范围和责任人，把分诊结论结构化，便于筛选和统计。结论与流转阶段，用状态表达受理、退回补充和关闭等处理结果，使每条缺陷当前处于哪个判断环节一目了然。交接与回溯阶段，通过评论、评审或交接记录保留判断人、时间和引用依据，后续复盘时可以直接查看当时的判断材料。
工具字段和状态的具体配置应结合团队现有流程设定，状态名称和字段项可按组织习惯调整。重点在于让每一类依据都有固定位置可填、每一个结论都有记录可查，而不是额外增加一套与现有流程并行的登记表。
常见问题
缺陷报告信息不全时，应该直接受理还是退回补充？
建议退回补充。受理的前提是他人能按报告中的步骤在相同环境和版本下看到相同现象，缺少环境、版本、复现步骤或预期结果时，确认无法完成。退回通知应逐项列明缺什么，并指定补充责任人；补充后重新进入初筛，而不是在信息不全的状态下先挂上“待修复”。
问题无法复现时，缺陷确认该如何收尾？
无法复现不等于问题不存在。确认时应记录尝试过的环境、版本、步骤和数据条件，再给出明确的下一步：退回报告人补充更具体的触发条件，或保留观察并约定复查时限。直接把无法复现的问题关闭，会让真实缺陷失去跟踪机会；无限期挂起则会持续消耗分诊精力，因此结论里要写清后续动作和责任人。
报告人和开发对“这算不算缺陷”有分歧时，以什么为依据？
以需求条目、验收标准或设计说明为依据，由产品负责人给出预期解释。分歧的焦点通常是“实际表现是否偏离约定”，把讨论拉回到具体条款上，比争论严重程度更有效。如果确实找不到对应约定，应转为需求变更判断，而不是在缺陷流程里反复拉锯。
团队规模小、没有独立测试角色，确认分工还能执行吗？
可以执行，角色可以合并，但交付物要求不变。例如开发兼任复现验证时，仍需留下复现记录和对照的需求条目；产品负责人缺席时，需求预期的判断要指定代行人并记录。关键在于每个判断都有明确负责人和留痕，而不是每个角色都必须独立设置。
确认结论和依据记录在聊天工具里，后续复盘会遇到什么问题？
聊天记录分散且难以按缺陷检索，复盘时往往找不到当时的判断材料。把缺陷作为工作项管理，可以让环境、版本、复现步骤、附件、严重程度、责任人和结论跟随同一条记录流转。ONES Project 支持缺陷跟踪管理，并与 TestCase 数据互通、支持一键提 Bug；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。字段和状态的具体配置可结合团队现有流程设定。
