重复缺陷处理规则要解决的是判定标准不统一、处置动作随意、争议无人复核的问题。一份可执行的规则通常包含四段机制：判定口径、角色分工、处置动作、复核维护，并且要落到缺陷单的必填字段和状态流转上。下面按制定顺序展开，给出字段清单、职责表、处置示例和上线检查项。
要点总览（TL;DR）
- 重复缺陷处理规则由四段机制组成：判定口径、角色分工、处置动作、复核维护，四段都要落到缺陷单字段和状态上才能执行。
- 判定口径按“同一根因、同一触发路径、同一影响对象”组合比对，顺序先根因再触发路径最后影响对象，根因未确认时先标记疑似重复并关联候选主缺陷。
- 提交人补全复现信息，缺陷管理员或测试负责人初判并执行处置，开发负责人确认根因；初判和根因确认各设一个工作日的时限，超时升级到测试或项目负责人。
- 处置分合并、关联、关闭三类：合并要保留原单信息并双向记录单号，关联用于根因待确认或同根因不同版本，以重复为由关闭必须填写判定人与依据。
- 规则上线前逐项检查字段必填、角色到人、状态可流转、示例跑通、复核责任落实，上线后用重复率和误判率验证并调整口径。
重复缺陷规则先定哪四件事
制定规则时，先把四段机制各自的输入、动作和输出写清楚，再补充细节。四段机制缺任何一段，规则都会在执行中走样：只定判定标准，没人负责判定，缺陷会积压在待处理状态；定了处置动作，没有复核机制，误判无法纠正。
| 环节 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 判定口径 | 新提交缺陷的根因描述、复现步骤、影响版本与影响对象 | 按“同一根因、同一触发路径、同一影响对象”组合比对已有缺陷 | 判定结论：重复或非重复，附比对依据 | 缺陷单中判定字段填写完整，结论可追溯 |
| 角色分工 | 缺陷单、判定责任人名单 | 提交人补充信息，缺陷管理员或测试负责人判定，开发负责人确认根因 | 判定人与确认人记录在单 | 每个待判定缺陷都有明确责任人，且在时限内完成 |
| 处置动作 | 判定结论与主缺陷编号 | 按情形执行合并、关联或关闭 | 主缺陷与被处置缺陷的关联记录、状态变更 | 处置后原单可查，主缺陷信息完整 |
| 复核维护 | 争议记录、重复率与误判率统计 | 复核争议结论，定期回看判定口径 | 复核记录、规则修订版本 | 争议有结论，规则变更已通知并生效 |
四段机制的先后关系是：判定口径决定“判什么”，角色分工决定“谁来判”，处置动作决定“判完怎么办”，复核维护决定“判错了怎么改”。制定时建议按这个顺序推进，每段完成后再进入下一段，避免口径未定就分配职责。
判定口径怎么写才可执行
判定口径要写成缺陷单上能填写的字段和固定的比对顺序，避免停留在“看起来像重复”的主观印象。核心判断是三个要素同时成立：同一根因、同一触发路径、同一影响对象。三者中任一不同，通常不判为重复，而是按关联处理或保留独立单。
判定要素与比对顺序
比对顺序建议先根因、再触发路径、最后影响对象。根因是判断重复的主要依据，现象相似但根因不同的缺陷，修复方式不同，合并后容易漏修。先比对根因可以避免被相同的报错文案误导。
- 根因：缺陷背后的代码或配置问题，例如同一处空值判断缺失、同一接口参数校验遗漏。
- 触发路径：从入口到出错的操作步骤，步骤序列一致或可归并为同一路径。
- 影响对象：受影响的页面、接口、数据类型或用户群体。
- 复现步骤：作为佐证字段，用于确认触发路径一致，不单独作为判重依据。
缺陷单中承载判定依据的必填字段
判定依据要落到字段上，才能被检查、被复核。建议在缺陷单中设置以下字段，并在判定环节设为必填：
| 字段 | 填写要求 | 用途 |
|---|---|---|
| 根因描述 | 一句话说明问题出在哪个模块或逻辑 | 判重的主要比对项 |
| 复现步骤 | 按顺序列出可重复执行的操作 | 确认触发路径一致 |
| 影响版本 | 填写发现问题的版本或分支 | 区分同根因不同版本的处置方式 |
| 影响对象 | 页面、接口或数据类型 | 判断影响范围是否一致 |
| 疑似重复单号 | 判定人填写的比对对象 | 留下比对痕迹，便于复核 |
| 判定结论与依据 | 重复或非重复，附一句比对说明 | 支撑后续处置与争议复核 |
易混淆情形的处理
两类情形最容易判错，规则中应单独写明处理方式。第一类是相似现象不同根因：两个缺陷报错文案相同，但一个来自前端校验、一个来自后端接口，应保留独立单，通过关联字段建立关系，待根因确认后再决定是否合并。第二类是同一根因不同版本：同一问题在主版本和补丁分支都出现，通常以主版本缺陷为主缺陷，其他版本缺陷关联到主缺陷并注明版本，修复时同步验证。
根因尚未确认时，不要急于判重。可以先标记为“疑似重复”，关联到候选主缺陷，由开发负责人确认根因后再转为合并或恢复独立单。这样既避免重复排查，也避免误合并导致漏修。
角色分工与处置动作
角色分工要明确到具体岗位，并给每个环节设定时限。常见分工是：提交人负责把复现步骤和影响范围填写完整；缺陷管理员或测试负责人负责初判和处置执行；开发负责人负责确认根因，尤其在疑似重复和争议情形中给出技术判断。
| 角色 | 职责 | 时限建议 |
|---|---|---|
| 提交人 | 填写复现步骤、影响版本、影响对象；收到处置通知后确认信息无误 | 提交时完成 |
| 缺陷管理员或测试负责人 | 初判是否疑似重复，填写疑似重复单号与判定依据，执行合并、关联或关闭 | 提交后一个工作日内完成初判 |
| 开发负责人 | 确认根因，对疑似重复和争议给出技术结论 | 收到确认请求后一个工作日内回复 |
三类处置动作的状态与字段要求
判定为重复后，按确认程度选择处置动作，三类动作对应的状态和字段不同：
| 处置动作 | 适用情形 | 字段要求 | 状态处理 |
|---|---|---|---|
| 合并 | 根因、触发路径、影响对象均已确认一致 | 填写主缺陷编号，保留原单的复现信息与提交人 | 原单转为已合并或已关闭，并在主缺陷中记录被合并单号 |
| 关联 | 现象相似但根因待确认，或同根因不同版本 | 填写关联单号与关联原因 | 原单保持独立状态，继续跟踪 |
| 关闭 | 确认重复且无需保留独立跟踪 | 记录判定人、判定依据、主缺陷编号 | 关闭原因选择重复，原单可查 |
合并时要注意保留原单信息：提交人、复现步骤和环境信息都应可查，否则后续验证时缺少上下文。以重复为由关闭时，关闭原因和判定依据必须填写，这是争议复核的基础。
超时升级路径
缺陷停留在待判定状态超过时限时，应自动或手动升级：先提醒判定责任人，仍未处理则升级到测试负责人或项目负责人。升级路径要写进规则，并明确升级后由谁做最终判定，避免缺陷长期悬置。
这些字段和状态需要在研发管理工具中承载。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，也支持缺陷关联至迭代，便于把判定字段、处置状态和关联关系放在同一张缺陷单上执行与追溯。
一个重复缺陷的完整处置示例
以下为演示情景，用于说明字段填写与状态流转，不代表真实项目数据。
提交信息：测试人员在订单列表页筛选“待发货”时，页面提示“查询失败”。提交人填写复现步骤为“进入订单列表—选择待发货—点击查询”，影响版本为当前迭代版本，影响对象为订单列表页，根因描述暂填“查询接口返回异常”。
初判：缺陷管理员检索已有缺陷，发现三天前有一条缺陷同样在订单列表查询时报错，根因描述为“查询参数未做空值处理”，影响对象相同。管理员在疑似重复单号中填入该缺陷编号，判定结论填“疑似重复”，状态置为待确认。
根因确认：开发负责人核对两条缺陷的复现步骤和接口日志，确认均由同一处参数校验缺失引起，触发路径一致，回复确认重复。管理员将判定结论改为“重复”，判定依据填写“同一根因：查询参数空值未处理；触发路径与影响对象一致”。
合并操作：管理员把新缺陷合并到主缺陷，在新缺陷中填写主缺陷编号，在主缺陷中记录被合并单号，新缺陷状态转为已合并。主缺陷保留两条复现信息，修复后一次验证覆盖两个入口。
通知与跟踪：系统通知提交人处置结果，提交人确认信息无误。主缺陷随迭代继续跟踪修复进度，验证通过后关闭。这个示例体现的规则要点是：先填疑似重复单号再确认根因、判定依据写到字段、合并后保留原单信息、处置结果通知提交人。
争议复核与规则维护
判定出现分歧时，需要有明确的复核入口。常见触发条件包括：提交人对重复判定有异议、开发负责人认为根因不同、合并后发现修复未覆盖原场景。复核人建议由测试负责人与开发负责人共同担任，涉及跨团队时增加项目负责人。
复核结论要记录在缺陷单上，写明维持原处置或修正处置的理由。若复核认定不构成重复，应恢复原单为独立状态，并从主缺陷中移除关联记录，保证两边信息一致。
规则定期回看
规则不是一次写完就固定不变。建议每个版本周期或每季度回看一次，参与角色包括测试负责人、缺陷管理员和开发负责人代表。回看时重点看两个指标：重复率，即判定为重复的缺陷占全部缺陷的比例；误判率，即复核中被推翻的重复判定占重复判定的比例。重复率异常偏高，可能说明判定口径过宽；误判率偏高，说明根因比对环节不够严格，需要收紧判定要素或加强根因确认。
规则变更后要通知相关角色并说明生效时间，变更内容同步更新到缺陷单字段说明和判定指引中。新规则生效前的在途缺陷，按原规则处理完毕或明确切换节点，避免同一批缺陷适用两套口径。
规则上线前的完成检查
规则写完后，逐项核对以下检查项，全部通过再上线：
- 判定字段是否已在缺陷单中设为必填，包括根因描述、复现步骤、影响版本、影响对象、疑似重复单号、判定结论与依据。
- 角色与时限是否明确到具体岗位或人员，初判、根因确认、超时升级各有责任人和时间要求。
- 合并、关联、关闭三类处置动作的状态流转是否可执行，关闭原因中是否有“重复”选项，合并后原单是否仍可查。
- 是否用一条真实或模拟缺陷完整跑通一次处置流程，字段填写、状态变更、通知提交人均无阻断。
- 争议复核的触发条件、复核人和记录方式是否落实，定期回看的周期与参与角色是否确定。
- 规则文档是否已通知到提交人、测试负责人和开发负责人，生效时间是否明确。
检查中发现字段缺失或状态无法流转，应先调整缺陷单配置再上线。规则上线后，用第一个版本的重复率和误判率验证执行效果，再决定是否调整判定口径。
常见问题
根因一时确认不了，缺陷该判重复还是先放着？
两种做法都不合适。可以先标记为“疑似重复”，在缺陷单中填写候选主缺陷编号，状态置为待确认，由开发负责人核对日志或代码后给出根因结论，再转为合并或恢复独立单。这样既避免两条缺陷被重复排查，也避免在根因不明时误合并导致漏修。规则中要把“疑似重复”作为一个明确状态写进去，并规定确认时限，否则缺陷会长期停在待确认。
同一问题在主版本和补丁分支都出现，算一条还是两条重复缺陷？
通常保留主版本缺陷作为主缺陷，其他版本的缺陷关联到主缺陷并注明影响版本，修复时同步验证各分支。这种情况属于同一根因不同版本，处置动作选关联而不是合并，因为各分支的修复和验证需要分别跟踪。规则中应写明以哪个版本为主缺陷的判断依据，例如以主干或当前迭代版本为主，避免不同人选择不同主单。
合并后提交人找不到自己提的缺陷，怎么处理？
合并时原单应保留可查，提交人、复现步骤和环境信息都不能丢，主缺陷中要记录被合并单号。如果工具里合并后原单不可见，提交人会重复提交同一问题，规则就失去意义。上线检查时应实际走一遍合并流程，确认原单仍能检索到、能跳转到主缺陷，并且系统会通知提交人处置结果。
重复率多高算异常，需要收紧判定口径？
没有通用阈值，要看团队自身的基线。建议先统计两三个版本的重复率和误判率，形成自己的参考区间，再设定观察线。重复率明显高于基线，往往说明判定口径过宽，把相似现象当成了重复；误判率偏高则说明根因比对不严。调整时优先收紧判定要素和根因确认环节，不要直接改指标目标。
规则上线后，在途的旧缺陷按哪套口径处理？
规则变更时要明确切换节点：可以规定生效前已进入处置流程的缺陷按原规则处理完毕，生效后新提交的缺陷按新规则执行；也可以指定一个日期统一切换，并对在途缺陷做一次清理。关键是同一批缺陷不能同时适用两套口径，否则复核时无法判断依据。变更通知中要写清生效时间和在途缺陷的处理方式。
