重复缺陷处理是什么
重复缺陷指与已有工单描述同一问题的提交：可能是同一根因的不同表现，也可能是不同场景暴露的同一处代码问题。规范的做法是关联合并、保留信息、统一跟踪——而不是简单关闭了事。粗暴打回会打击报告积极性，合并太随意又会丢失不同触发条件的细节，处理流程要在效率与信息留存之间拿捏。
基本信息
| 判定依据 | 同一根因、同一模块、可互相替代复现的组合 |
|---|---|
| 处理动作 | 关联主工单、合并讨论、保留原报告人的复现信息 |
| 信息留存 | 不同触发条件与环境差异记入主工单，作为回归输入 |
| 沟通要点 | 说明重复判定依据并感谢补充，维护报告积极性 |
| 统计口径 | 重复率单列统计，反映需求传达与用例清晰度 |
| 自动化手段 | 提报时按关键词与组件提示相似工单，减少重复产生 |
典型使用场景
- 批量回归后报障：同一问题多人同时提交，集中关联到主工单。
- 用户侧反馈：同一现象不同描述，需要人工判断是否同根因。
- 跨端问题：Web 与 App 同一后端缺陷分别提交，合并跟踪。
- 历史重开：与已关闭的旧工单同根因，关联历史结论避免重复分析。
- 外包协作：外部团队误报重复单时，用流程引导而非直接打回。
处理方式对比
| 方式 | 做法 | 后果 |
|---|---|---|
| 关联合并 | 挂到主工单并保留信息 | 信息集中，跟踪清晰 |
| 直接关闭 | 标注重复即关 | 信息丢失，报告人受挫 |
| 各自跟踪 | 重复单独立修 | 工时浪费，状态难同步 |
| 错误合并 | 根因不同却强行合并 | 漏修一个场景，缺陷复现 |
判定重复要写依据：引用主工单编号与相同复现点，双方对判定都有据可查。
重复率高是信号：需求文档或界面引导不清时，用户与测试都容易重复报障。
合并后主工单要回写：把后提交信息里的新场景补进去，回归时一并覆盖。