重复缺陷识别需要三类依据：缺陷描述中的可复现事实、可对照的痕迹证据，以及缺陷库中的历史记录。判定时先检索比对，再按“现象一致、触发条件一致、根因指向一致”逐项核对，三项都成立才合并为重复；仅现象相似时标注疑似重复并挂关联，交由缺陷责任人确认。以下给出依据分类、操作步骤、角色分工、完整示例与完成检查。
要点总览（TL;DR）
- 重复缺陷识别需要三类依据：可复现事实（复现步骤、环境版本、实际与预期结果）、痕迹证据（日志、堆栈、截图录屏、请求响应、数据条件）、库内记录（历史缺陷、关联需求、已知问题）。
- 判定成立采用三项核对：现象一致、触发条件一致、根因指向一致；三项全中才合并为重复，仅现象相似时标注疑似重复并挂关联，由缺陷责任人确认。
- 操作顺序为受理检索、逐项比对、判定处置、合并通知、升级处理，每步留下检索记录与比对记录，判定过程随缺陷单留存。
- 角色分工上，报告人提供事实与痕迹，受理人做检索与初步比对，模块负责人或缺陷责任人确认根因并决定合并或拆分。
- 判定完成后按清单核对依据完整性、比对记录、信息保留、报告人通知与疑似重复跟踪，误合并与漏合并分开统计复盘。
判定重复缺陷的三类依据
重复缺陷判定容易陷入两种偏差：凭标题相似就合并，或凭印象认为“见过类似问题”而挂起。要减少这类偏差，需要把依据分成事实、痕迹、库内记录三层，每层承担不同的证明任务，并明确它单独使用时能证明到什么程度。
事实类依据回答“问题是什么、在什么条件下出现”。复现步骤要写到可被他人照做的粒度，环境与版本要具体到构建号或配置项，实际结果与预期结果要分开写清。这类依据能证明现象存在且可复现，但无法证明两个缺陷由同一原因引起。
痕迹类依据回答“系统内部发生了什么”。错误日志、堆栈、截图录屏、请求响应报文、触发问题所需的数据条件，都属于这一类。日志与堆栈能支撑技术层面的比对，截图录屏适合界面类问题，请求响应与数据条件适合接口和数据处理类问题。痕迹证据能提高根因比对的可靠性，但缺少库内对照对象时，仍无法单独得出“重复”的结论。
库内依据回答“以前是否有人报过、当时怎么处理”。历史缺陷单、关联需求、已知问题记录与发布说明，提供了对照对象。检索结果能证明存在相似记录，但历史单本身也可能描述不全，需要回到事实与痕迹层面逐项比对，不能仅凭标题或模块相同就认定重复。
| 依据类别 | 具体内容 | 能证明什么 | 不能单独证明什么 | 采集人 |
|---|---|---|---|---|
| 事实类 | 复现步骤、环境与版本、实际结果与预期结果 | 现象真实存在且可复现 | 两个缺陷根因相同 | |
| 痕迹类 | 错误日志、堆栈、截图录屏、请求响应、数据条件 | 故障发生位置与技术特征 | 库内是否已有同问题记录 | |
| 库内依据 | 历史缺陷单、关联需求、已知问题、发布说明 | 存在可对照的既往记录 | 记录与当前缺陷完全同一 |
从受理到判定的操作步骤
判定流程的目标是让每一次“重复”结论都有检索记录和比对记录可查。以下五步按顺序执行，每步都有明确的输入、动作、输出与完成标志。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 受理检索 | 新提交缺陷单 | 提取模块、关键词、版本、错误特征，在缺陷库中检索，记录检索词与命中结果 | 检索记录（检索词、范围、命中单号） | 检索记录已附在缺陷单中 | |
| 2. 逐项比对 | 检索记录、候选历史单 | 按现象、触发条件、根因指向三项逐项比对，写明一致项与差异项 | 比对记录 | 三项均有明确结论 | |
| 3. 判定处置 | 比对记录 | 三项全中判重复并合并；部分命中标疑似重复并挂关联 | 判定结论与处置动作 | 缺陷单状态与关联关系已更新 | |
| 4. 合并与通知 | 判定结论 | 合并时保留原单信息、补充差异说明、通知报告人 | 合并记录与通知记录 | 报告人已收到处理说明 | |
| 5. 升级处理 | 无法判定的缺陷单 | 提交模块负责人或缺陷责任人裁定，设定答复时限 | 裁定结论 | 在约定时限内给出合并、挂关联或独立的结论 |
第1步的检索范围要覆盖当前项目与相关历史项目，检索词至少包含模块名、报错关键词和版本号三类，避免只用标题检索造成漏检。第2步的三项比对中，现象一致看实际结果是否相同，触发条件一致看操作路径、环境、数据条件是否吻合，根因指向一致看日志、堆栈或代码路径是否指向同一处。三项全中才合并；只有现象相似、触发条件或根因无法确认时，标注疑似重复并挂关联，保留独立跟踪，等责任人确认后再决定合并或拆分。
第5步的时限建议由团队在缺陷管理规范中约定，例如一个工作日内给出初步结论。时限本身不是判定依据，但能防止疑似重复长期悬空。缺陷受理、检索比对、关联与判定记录需要在工作项中承载时，可以在缺陷工作项上记录检索词、候选单号、比对结论和处置动作，让判定过程随缺陷单一起留存；ONES Project 支持缺陷跟踪与质量统计，可一键提交 Bug 至对应项目或迭代，并记录和跟踪缺陷修复情况，适合承载这类受理与判定记录。
角色分工与各环节交付物
重复缺陷判定悬空的常见原因是“谁都能看，但没人负责下结论”。把收集、比对、确认三类动作分到具体角色，并为每个角色规定交付物，判定才有落点。
| 角色 | 动作 | 交付物 |
|---|---|---|
| 缺陷报告人 | 提交可复现事实与痕迹证据，补充缺失信息 | 完整的缺陷描述、日志或截图、复现环境 |
| 受理人/分诊人 | 执行检索与初步比对，给出初步判定 | 检索记录、比对记录、初步结论 |
| 模块负责人或缺陷责任人 | 确认根因指向，决定合并、挂关联或拆分 | 最终判定结论与理由 |
| 测试人员 | 在疑似重复阶段补充复现条件与差异说明 | 补充复现记录、差异点说明 |
| 开发人员 | 从日志、堆栈、代码路径判断根因是否同一 | 根因判断意见 |
测试与开发在疑似重复上的协作方式是：测试负责把现象和触发条件对齐，开发负责判断技术根因是否同一，两边结论都写入比对记录，由模块负责人做最终确认。判定记录作为可追溯交付物留存，内容包括检索词、候选单号、三项比对结论、处置动作和确认人。记录随缺陷单保存，后续复盘误判时可以直接调取。
判定记录需要与缺陷单一起被检索和追溯时，可以借助工作项与文档的关联方式承载：ONES Project 的缺陷跟踪管理与 TestCase 数据互通，支持一键提 Bug；ONES Wiki 支持文档关联任务，并支持插入 ONES Project 的工作项列表，适合把判定规范、检索记录与缺陷单放在同一协作上下文中查阅。
示例：一条缺陷如何被判为重复
以下为演示情景，用于说明依据收集与比对过程，不对应真实项目数据。
某版本提交一条缺陷，标题为“订单列表页翻页后数据重复”，描述只有一句“翻到第二页出现重复订单”，缺少环境、版本、复现步骤和日志。受理人先做检索，用“订单列表”“翻页”“重复”三个关键词检索，命中三条历史单，其中两条属于其他模块，一条属于同一模块的上一版本。
受理人要求报告人补充信息。报告人补充：环境为测试环境，版本为当前迭代构建，复现步骤为进入订单列表、点击下一页、观察首行数据；实际结果为第二页首行与第一页末行相同，预期结果为两页数据不重叠；附带了浏览器控制台截图和接口响应片段。痕迹证据显示分页参数在第二页请求中未正确递增。
受理人将当前缺陷与同模块历史单逐项比对：现象一致，都是翻页后出现重复行；触发条件一致，都是第二页请求、相同分页参数；根因指向一致，历史单的接口响应片段显示同一处分页参数问题，且该问题在上一版本已记录、尚未修复。三项全部成立，判定为重复。
处置时把当前缺陷合并到历史单，保留原报告人信息和补充的截图、响应片段，在历史单中补充“当前版本仍可复现”的差异说明，并通知报告人处理结果。这个示例的可迁移规律是：检索先行、缺失信息回补、三项逐项比对、合并时保留原单信息并通知报告人。
判定质量的完成检查
判定完成后，用一张检查清单逐项核对，可以把误合并和漏合并挡在流程内。检查项与通过标准如下。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 依据完整性 | 事实、痕迹、库内检索三类依据齐全，缺失项有说明 | 缺陷单附件与检索记录 | 受理人 |
| 比对记录 | 写明一致项与差异项，三项均有结论 | 比对记录 | 受理人 |
| 合并信息保留 | 原单信息、报告人、补充证据均已保留 | 合并后的缺陷单 | 模块负责人 |
| 报告人通知 | 报告人已收到处理说明与后续跟踪方式 | 通知记录 | 受理人 |
| 疑似重复跟踪 | 挂关联的疑似单有责任人和关闭条件，未长期悬空 | 关联关系与跟踪记录 | 缺陷责任人 |
| 误判复盘 | 误合并与漏合并分开统计，分别定位原因 | 复盘记录 | 质量负责人 |
疑似重复的关闭条件建议写清：责任人确认根因同一则合并，确认不同则拆分并保留关联说明，超过约定时限未确认则升级处理。误判复盘时把误合并与漏合并分开统计，误合并多说明比对过松或检索范围过窄，漏合并多说明检索词覆盖不足或依据收集不全，两类问题的改进动作不同，混在一起统计会掩盖真实原因。
常见问题
缺陷描述信息不全时，还能先做重复判定吗？
可以先做检索，但不宜直接下重复结论。受理人可先用模块、关键词、版本检索缺陷库，把命中的候选单记录下来，同时向报告人回补复现步骤、环境版本、实际与预期结果以及日志或截图。候选单与当前缺陷在现象上相似、触发条件或根因指向无法确认时，标注疑似重复并挂关联，保留独立跟踪，等补充信息到位或责任人确认后再决定合并或拆分。
三项核对中根因指向无法确认，应该合并还是挂关联？
三项核对要求现象、触发条件、根因指向都成立才合并。根因指向无法确认时，按疑似重复处理：挂关联、保留独立跟踪，并请开发人员从日志、堆栈或代码路径给出根因判断意见，由模块负责人或缺陷责任人做最终确认。这样既避免误合并丢失独立信息，也避免疑似单长期悬空。
合并重复缺陷后，原报告人的信息和补充证据怎么处理？
合并时把原单信息、报告人、补充的截图与响应片段保留到目标缺陷单中，并补充差异说明，例如当前版本仍可复现或触发条件略有不同。随后通知报告人处理结果与后续跟踪方式，让报告人知道问题已并入哪条缺陷、由谁跟进。这一步是判定记录可追溯的一部分，也避免沟通断点。
疑似重复的缺陷单什么时候可以关闭？
建议在缺陷管理规范中写清关闭条件：责任人确认根因同一则合并到目标单；确认根因不同则拆分并保留关联说明；超过约定时限未确认则升级处理。疑似单应明确责任人和关闭条件，避免长期挂在关联关系里无人跟进。时限本身不是判定依据，作用是防止判定悬空。
误合并和漏合并为什么要分开统计？
两类误判的原因不同，改进动作也不同。误合并多来自比对过松或检索范围过窄，需要收紧三项核对、扩大检索范围；漏合并多来自检索词覆盖不足或依据收集不全，需要补充检索词类别、要求报告人补齐事实与痕迹证据。混在一起统计会掩盖真实原因，分开统计才能定位到具体环节。
