重复缺陷处理规则要同时管住两件事：减少重复提单带来的处理浪费，以及避免误判重复导致真实缺陷被漏掉。本文用一份标注为演示情景的完整规则表，演示如何按“同一根因、同一触发路径、同一影响对象”判定重复，如何把缺陷分为完全重复、部分重复、疑似重复三级并分别采取合并关闭、关联保留、挂起观察，以及如何在缺陷单上留下判定人、判定依据和关联单号，方便读者改造成自己团队的规则。
要点总览（TL;DR）
- 重复判定用三条口径组合：同一根因、同一触发路径、同一影响对象，标题相似只能作为线索。
- 按完全重复、部分重复、疑似重复三级处置：分别合并关闭、关联保留、挂起观察并设复查时点。
- 每张缺陷单至少留下判定人、判定时间、判定依据、关联缺陷单号，疑似重复另加复查时间与责任人。
- 规则可拆成判定口径—分级—处置动作—记录字段—复查机制五段迁移，按缺陷量与迭代节奏调整分级粒度和复查周期。
- 示例适用于已有稳定缺陷单模板与状态流转的团队；字段缺失、高频并发或跨团队共享模块时需先补字段或上移判定责任。
示例要解决什么问题：重复缺陷规则的目标与判定口径
这份示例规则面向两类常见问题。第一类是重复提单：同一问题被不同测试人员、在不同时间或不同入口反复提交，处理人需要逐单阅读、复现、沟通，修复工作被稀释在大量相似单据里。第二类是误判重复：处理人看到标题相似或现象接近，就把一张新单并入旧单关闭，结果旧单修的是另一个根因，新问题被掩盖，直到版本发布后才暴露。
规则的目标是让“判重”从个人经验变成可复核的动作。为此，示例采用三条判定口径，并要求组合使用：
- 同一根因：两张缺陷单指向同一段代码逻辑、同一配置错误或同一数据问题。判断依据可以是堆栈信息、日志中的同一异常点、同一段错误提示。
- 同一触发路径：复现步骤的关键环节一致，包括操作入口、前置条件、输入数据范围。步骤表述不同但路径等价，可视为同一路径。
- 同一影响对象：缺陷落在同一模块、同一版本、同一环境组合上。模块相同但版本或环境不同，需要单独判断影响是否一致。
三条口径的组合方式是：三条全部吻合，进入完全重复；根因一致但触发路径或影响对象存在差异，进入部分重复；只有部分线索吻合、尚不能确认根因，进入疑似重复。本文示例中的团队设定、角色名称和字段取值均为演示情景，用于说明规则结构，不代表真实客户案例。
完整示例：一份重复缺陷分级处置规则表
下表是一份可直接照填的示例规则。使用时可保留分级结构和字段列，把角色名称、复查周期和具体条件替换为团队实际约定。表中“示例”指演示情景下的填写方式。
| 分级 | 判定条件（示例） | 处置动作 | 责任角色 | 必填记录字段 |
|---|---|---|---|---|
| 完全重复 | 同一根因、同一触发路径、同一影响对象三项全部吻合；已有缺陷单处于打开或修复中状态 | 将新单合并到原单并关闭新单；在原单补充新单提供的复现信息或日志；通知提单人 | 缺陷处理人判定，模块负责人确认 | 判定人、判定时间、判定依据（日志或堆栈定位）、关联缺陷单号、原单状态 |
| 部分重复 | 根因一致，但触发路径、影响版本或影响环境存在差异；或修复方案可能覆盖多个场景但尚未验证 | 不关闭新单，建立与原单的关联；在新单注明差异点；由模块负责人决定是否并入同一修复批次 | 缺陷处理人提出关联，模块负责人确认关联关系 | 判定人、判定时间、判定依据（差异点说明）、关联缺陷单号、待验证场景 |
| 疑似重复 | 现象或模块相同，但根因尚未定位，或复现信息不足，无法确认三条口径 | 挂起观察，设定复查时点；补充复现步骤、日志或版本信息；到期由责任人复核并转为完全重复、部分重复或独立缺陷 | 提单人补充信息，测试负责人指定复查责任人 | 判定人、判定时间、判定依据（当前已知线索）、关联缺陷单号（可空）、复查时间、复查责任人 |
表中三个分级对应三类动作：合并并关闭、关联保留、挂起观察并设定复查时点。字段列是规则能否被复核的关键，尤其是判定依据和关联缺陷单号，缺少这两项，后续人员无法判断当初为什么这样处理。
逐项解释：示例中每个判定与处置为什么这样设计
为什么用三条口径组合，而不是只看标题相似度。缺陷标题往往由提单人自由填写，“登录失败”“页面报错”这类描述在不同模块、不同版本中都会出现。标题相似只能作为线索，不能作为判定依据。同一根因回答“修的是不是同一处”，同一触发路径回答“用户走的是不是同一条路”，同一影响对象回答“出问题的范围是不是同一块”。三条同时吻合，合并关闭才有把握；缺少任何一条，就需要降级处理。
部分重复为什么选择关联保留，而不是直接合并关闭。部分重复的典型情形是根因相同但影响范围不同，例如同一段空值处理逻辑在列表页和详情页都触发异常。直接关闭新单，会丢失详情页的复现路径和验证要求；保留新单并建立关联，既让修复人看到同一根因，又让测试人员在修复后分别验证两个入口。关联关系还便于在修复批次中判断是否需要补充回归用例。
疑似重复为什么要设复查时点和责任人。疑似重复的本质是信息不足，此时既不满足合并条件，也不适合直接当作独立缺陷排期。挂起观察如果没有时间边界，单据会长期停留在模糊状态。设定复查时点，等于给信息补充设一个截止时间；指定复查责任人，避免“谁都可以看、谁都不处理”。到期复核时，责任人依据补充的日志和复现步骤，把单据转为完全重复、部分重复或独立缺陷，流程重新变得可判定。
判定依据为什么要求写具体证据。“确认重复”“同上”这类结论性描述无法支撑复核。示例要求填写日志片段、堆栈位置、复现步骤差异或版本号，目的是让后来的人能沿着证据重新判断。证据具体，误判更容易被发现和纠正；证据缺失，规则就退化成个人判断。
合并关闭后原单信息如何保留。合并动作应把新单的复现步骤、附件、提单人补充说明转移到原单，或在新单上保留关联单号并注明“已合并至某单”。这样原单承载完整的问题上下文，新单作为入口记录仍然可查。追溯时可以从原单看到所有关联提交，也能从被关闭的新单回到处理主单。
可迁移规律：把这份示例改成自己团队的规则
示例的价值在结构，不在具体取值。可以把规则拆成五段式：判定口径、分级、处置动作、记录字段、复查机制。迁移时逐段替换，而不是整表照搬。
- 判定口径：保留“根因、触发路径、影响对象”三个维度，按产品形态补充维度。例如客户端产品可增加设备与系统版本，服务端产品可增加租户或数据范围。
- 分级：缺陷量小的团队可以只保留完全重复和疑似重复两级，减少判定负担；缺陷量大、多人并行提单的团队可保留三级，并给部分重复增加“影响版本数”等细分条件。
- 处置动作：明确每种分级下谁有权关闭、谁有权建立关联、挂起单据是否占用排期。
- 记录字段：把示例中的字段名替换为缺陷单模板中的实际字段名，确保判定人、判定时间、判定依据、关联单号、复查时间都有落点。
- 复查机制：按缺陷量和迭代节奏设定复查周期。迭代周期短的团队可以按迭代复查，周期长的团队可以按固定天数复查。
角色名称需要替换为团队实际岗位。示例中的“缺陷处理人”在某些团队对应开发负责人，“模块负责人”可能对应技术负责人或特性 owner，“测试负责人”可能对应测试组长。角色可以合并，但每类动作必须有明确责任人。
规则落地时，缺陷单模板要能承载判定字段，状态流转要能表达“已合并”“关联保留”“挂起观察”这些结果。以 ONES Project 为例，其缺陷跟踪管理支持与 TestCase 数据互通、一键提 Bug，并统计缺陷状态分布，缺陷可提交到对应项目或迭代中记录和跟踪修复情况。团队可以把判定人、判定依据、关联单号、复查时间作为缺陷单上的记录项，把合并、关联、挂起作为状态流转中的节点，让规则中的每个动作在单据上留下痕迹。ONES ALM 方案将测试用例、缺陷、版本和发布过程关联到需求链路，出现问题时便于定位影响范围，这与部分重复需要判断影响对象的场景相衔接。具体字段配置和关联类型需按团队实际模板核验后设置。
适用边界：这份示例在什么情况下需要调整
示例规则适用于已有稳定缺陷单模板和状态流转的团队。如果当前缺陷单只有标题和描述，缺少判定人、判定依据、关联单号等字段，应先补齐字段再启用分级规则，否则判定结果无处记录，复核无法进行。
以下情形需要调整判定责任或分级方式：
- 高频并发缺陷：同一时间段大量相似单据涌入时，由一线处理人逐单判定容易积压，可把完全重复的判定权上移到模块负责人，或设置集中判重时段。
- 跨团队共享模块：缺陷涉及多个团队共同维护的模块时，单一处理人难以确认根因归属，判定责任应上移到模块负责人或联合评审。
- 复现环境差异大：测试环境与生产环境表现不一致时，“同一影响对象”的判断需要补充环境对照信息，疑似重复的比例会上升，复查周期应相应缩短。
本文范围限定在重复缺陷的判定与处置规则。单个缺陷的修复进度跟踪、验证关闭流程，以及研发平台的流程系统配置与治理，不在本文展开。规则上线后应定期回看误判情况，例如被合并关闭后又重新打开的单据、复查到期仍无法判定的单据，据此调整判定条件和复查周期。示例本身不提供量化效果承诺，团队应以自身缺陷数据为依据做调整。
常见问题
团队缺陷量不大，还需要分三级吗？
可以简化。缺陷量小、提单人相对固定的团队，保留“完全重复”和“疑似重复”两级通常就够用：三条口径全部吻合的直接合并关闭，线索不足的挂起观察并设复查时点。部分重复这一级主要解决“根因相同但影响范围不同”的场景，当团队经常出现同一逻辑在多个入口触发异常时，再补上这一级更合适。分级减少后，记录字段仍要保留判定依据和关联单号，否则复核时缺少依据。
被合并关闭的缺陷后来又复现了，应该怎么处理？
先判断复现的是原单已修复的问题，还是当初被误判合并的另一处问题。如果是同一根因未修净，重新打开原单并补充新的复现信息；如果复现路径与原单不同，应新建缺陷单并关联原单，注明差异点，同时回看当初的判定依据，确认是否属于误判。这类回看结果可以作为调整判定条件的输入，例如在部分重复的条件中补充影响入口的列举。
疑似重复挂起后一直没人复查怎么办？
挂起观察需要两个约束同时生效：复查时点和复查责任人。只设时点不指定人，单据容易长期停留；只指定人不设时点，复查容易被排期挤后。可以在缺陷单上把复查时间设为必填，并在到期前由测试负责人统一查看挂起清单。到期仍无法判定的，按独立缺陷进入排期，避免因等待信息而无限期搁置。
多个团队共同维护一个模块时，判重由谁负责？
建议把判定责任上移到模块负责人，或由相关团队联合评审。一线处理人通常只熟悉自己负责的部分，难以确认根因归属，容易出现各自合并、重复修复的情况。可以约定：涉及共享模块的疑似重复和部分重复，由模块负责人确认关联关系；完全重复的合并关闭可由处理人执行，但需在判定依据中写明根因定位信息，便于其他团队核对。
规则落地到缺陷单上，需要哪些字段和状态？
字段方面至少需要判定人、判定时间、判定依据、关联缺陷单号；疑似重复另加复查时间和复查责任人。状态方面需要能表达“已合并”“关联保留”“挂起观察”三种结果，并保留从被关闭单据回到主单的入口。以 ONES Project 为例，其缺陷跟踪管理支持与 TestCase 数据互通、一键提 Bug，并统计缺陷状态分布，缺陷可提交到对应项目或迭代中记录和跟踪修复情况；团队可将上述判定信息作为缺陷单记录项，把合并、关联、挂起作为状态流转节点。具体字段配置与关联类型需按团队实际模板核验后设置。
