重复缺陷识别需要三类依据：缺陷自身的复现信息与现象描述、已有缺陷库的检索结果，以及记录中的环境、版本、模块、日志等可核对字段。判定时按“检索—现象比对—条件比对—影响范围比对—给出重复指向”的顺序推进，由分诊人给出结论、模块负责人确认，并保留判定记录。本文给出可执行的步骤表、字段证据清单、角色分工与完成检查表，适用于缺陷受理环节的分诊人员。
要点总览（TL;DR）
- 重复缺陷识别依赖三类依据：缺陷自身的复现信息与现象描述、缺陷库检索结果、环境版本模块与日志等可核对字段，三类缺一类就应降级为疑似重复。
- 判定按“检索—现象比对—条件比对—影响范围比对—给出重复指向”五步推进，前一步的输出作为后一步的输入，任一步明显不一致即停止向重复收敛。
- 提交人负责写清现象与条件，分诊人负责检索与逐项比对，模块负责人负责确认判定；判定记录需写明指向缺陷编号、检索关键词、三项比对结论、判定人与确认人。
- 字段缺失按程度处理：缺复现步骤或实际结果退回补充，缺日志可先比对并标注待复核，缺版本环境确认不到时保留为独立缺陷。
- 判定质量用正反两个方向抽查验证：正向复核已判重复的依据与比对，反向用关键词重新检索检查漏判，不满足项按类型退回对应角色。
重复缺陷识别的核心依据与判定步骤
重复判定的实质是回答一个问题：两条缺陷记录描述的是否为同一现象、由同一触发条件引起、影响同一范围。三类依据分别支撑这三个问题。缺陷自身的复现信息与现象描述回答“发生了什么”；缺陷库检索结果回答“是否已经有人报过”；环境、版本、模块与日志等字段回答“两次出现是否处在可比条件下”。三类依据缺一类，判定就应降级为“疑似重复”，交由模块负责人复核，而不是直接关闭。
判定顺序固定为五步，前一步的输出是后一步的输入。先检索再比对，可以避免分诊人凭印象直接下结论；先比现象再比条件，可以在现象明显不一致时提前终止，节省比对成本。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 检索 | 新缺陷的标题、关键报错文本、模块名、功能入口 | 用标题关键词、报错片段、模块与功能入口在缺陷库中组合检索，必要时放宽到同义词与近义描述 | 候选缺陷列表，通常控制在若干条以内 | 候选列表已生成，且每条候选都记录了命中原因（关键词、模块或报错一致） |
| 2. 现象比对 | 新缺陷的实际结果描述、截图或录屏；候选缺陷的现象描述 | 逐条比对预期结果与实际结果的差异点是否一致 | 现象一致或不一致的结论 | 对每条候选给出“现象一致/不一致”的判断及依据 |
| 3. 条件比对 | 复现步骤、前置数据、操作路径、账号或权限条件 | 核对触发条件是否可对应，包括步骤顺序、输入数据形态、并发或时序条件 | 条件可对应或不可对应的结论 | 关键触发条件逐项核对完毕，差异项已列出 |
| 4. 影响范围比对 | 环境、版本、模块、影响用户或业务范围 | 核对两次出现是否处于同一版本与环境，影响面是否一致或存在包含关系 | 范围一致、部分重叠或不重叠的结论 | 版本与环境字段已核对，范围差异已说明 |
| 5. 给出重复指向 | 前四步的比对结论 | 指定一条已有缺陷作为重复指向对象，写明比对结论与存疑点 | 重复判定记录，含指向缺陷编号 | 记录已填写，指向对象明确，存疑点已标注并进入复核 |
五步中任何一步出现明显不一致，都应停止向“重复”收敛，转为独立缺陷或退回补充信息。部分一致的情形（例如现象一致但版本不同）可以判为疑似重复，在记录中写明差异，由模块负责人决定是否合并跟踪。
判定所需字段与证据清单
依据要落到字段上才能被核对。一条缺陷记录如果缺少复现步骤、实际结果或版本环境，分诊人只能凭标题猜测，重复判定的可靠性会明显下降。下表按用途列出判定所需字段，可作为提交模板与分诊检查的共同基准。
| 用途 | 字段与证据 | 核对要点 |
|---|---|---|
| 定位现象 | 缺陷标题、实际结果描述、预期结果、截图或录屏 | 标题是否包含模块与现象关键词；实际结果是否描述到可观察的具体表现 |
| 复现触发条件 | 复现步骤、前置数据、操作路径、账号或权限条件、复现频率 | 步骤是否可被他人按序执行；必现与偶现是否注明 |
| 确认可比环境 | 产品版本或构建号、部署环境、操作系统与浏览器、设备型号 | 版本号是否精确到构建；环境是否与候选缺陷一致 |
| 定位影响范围 | 所属模块与功能入口、影响用户或业务范围、严重程度 | 模块归属是否与候选缺陷相同或存在包含关系 |
| 辅助证据 | 日志片段、报错堆栈、接口返回、请求标识或时间点 | 日志是否包含可检索的报错关键词；时间点能否与操作对应 |
| 检索线索 | 已有缺陷的标题、关键词、关联记录（需求、用例、历史缺陷） | 候选缺陷的标题关键词是否与新缺陷重合；关联记录是否指向同一功能 |
字段缺失时按缺失程度处理，而不是一律退回。缺少复现步骤或实际结果的，退回提交人补充，因为这两项直接决定现象能否比对；缺少日志的，可先完成检索与现象比对，在判定记录中标注“日志缺失”，结论标注为待复核；缺少版本或环境的，先向提交人确认，确认不到时不得直接关闭为重复，应保留为独立缺陷并注明环境不明。所有缺失项都应写入判定记录，便于后续抽查时区分“证据不足的判定”和“证据齐全的判定”。
检索线索的准备同样影响效率。提交人在提单前用报错关键词做一次自查，分诊人在受理时用模块加关键词再检索一次，两次检索的结果都记入记录，可以减少同一问题被反复受理。
分诊角色分工与判定记录
重复判定涉及三个角色，职责边界清晰才能避免“谁都看过、谁都没定”。提交人负责把现象与条件写清楚，分诊人负责检索与逐项比对，模块负责人负责确认判定并承担合并跟踪的后果。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人 | 按字段清单填写复现步骤、实际与预期结果、环境版本、日志截图；提单前用报错关键词自查是否已有同类记录 | 信息完整的缺陷记录与自查说明 |
| 分诊人 | 执行五步判定，生成候选列表，逐项比对现象、条件与范围，给出重复指向或转出建议 | 比对结论与重复判定记录 |
| 模块负责人 | 复核比对结论，确认或否决重复指向；对疑似重复的差异项作出处理决定 | 确认意见，必要时给出合并或分拆结论 |
确认方式按风险分级。现象、条件、范围三项全部一致的，分诊人给出指向后由模块负责人确认即可关闭；存在任一差异项的，需模块负责人明确写出接受差异的理由，再决定是否按重复处理。复核可以由模块负责人在日常分诊中完成，也可以按周集中复核一批疑似重复记录，两种方式都要求留下确认人和确认时间。
判定记录至少包含以下内容：新缺陷编号、重复指向的缺陷编号、检索时使用的关键词、现象比对结论、条件比对结论、范围比对结论、缺失字段说明、判定人、确认人与判定时间。关闭或转出的记录还应写明处理动作，例如“关闭并关联至原缺陷”“转模块负责人进一步确认”“转为独立缺陷继续跟踪”。记录的作用不只是留痕，下次出现相似问题时，检索可以直接命中这条记录中的关键词与结论。
在工具层面，缺陷记录、检索比对与判定留痕需要有承载位置。ONES Project 支持缺陷跟踪管理，可与 TestCase 数据互通并一键提 Bug，支持将 Bug 提交至对应项目或迭代中记录和跟踪修复情况，也能统计缺陷状态分布。测试环节中，ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。这些能力可以承接缺陷记录与流转；缺陷库的关键词检索、字段自定义范围与重复指向的关联留痕方式，需在选型核验时结合团队实际配置确认。
示例：一条缺陷如何被判定为重复
以下为演示情景，用于说明依据如何组合使用，不对应真实系统数据。
新缺陷记录：标题为“订单列表页筛选后翻页，第二页数据重复显示第一页内容”；实际结果为筛选“待发货”后点击第二页，列表仍显示第一页的订单；预期结果为显示第二页对应的订单；复现步骤为登录测试账号、进入订单列表、选择待发货、点击第二页；环境为测试环境、版本号精确到构建、浏览器为常见桌面浏览器；附有列表接口返回的日志片段，其中分页参数与返回条数不匹配；复现频率为必现。
分诊人先检索，用“订单列表 翻页”“筛选 第二页”“分页参数”三组关键词组合查询，命中两条候选。候选 A 标题为“订单列表筛选后分页错乱”，现象描述为筛选条件下翻页数据不更新，版本为上一构建；候选 B 标题为“订单导出分页重复”，现象为导出文件出现重复行，模块为导出服务。候选 B 的现象与模块均不一致，第一步即排除。
对候选 A 逐项比对：现象上，两者都是筛选后翻页显示错误数据，一致；条件上，候选 A 的复现步骤同样为选择筛选条件后点击第二页，前置数据形态相同，一致；范围上，候选 A 记录在上一构建，新缺陷在当前构建，模块同为订单列表，影响范围一致但版本存在差异。日志方面，候选 A 附有相同的分页参数异常片段，可作为辅助印证。
结论：现象、条件、范围三项一致，版本差异属于同一问题在不同构建上的延续，判定为重复，指向候选 A。记录写法为：“重复指向缺陷编号（候选 A）；检索关键词：订单列表 翻页、筛选 第二页、分页参数；现象一致，条件一致，范围一致，版本由上一构建延续至当前构建；日志分页参数异常一致；判定人：分诊人；确认人：订单模块负责人；处理动作：关闭并关联至候选 A，在原缺陷补充当前构建的复现信息。”
这个例子说明两点：检索关键词要覆盖现象词与报错词，只搜标题容易漏；版本差异不必然否定重复，但必须在记录中写明，由模块负责人确认是否按同一问题跟踪。
完成检查：判定质量如何验证
判定质量不能只看结论对错，还要看依据是否齐全、比对是否逐项完成、记录是否可追溯。下表可作为分诊人自检和负责人抽查的共同清单。
| 检查项 | 核验内容 | 不满足时的处理 |
|---|---|---|
| 依据齐全 | 复现步骤、实际与预期结果、环境版本、模块入口、日志或截图是否具备；缺失项是否在记录中说明 | 退回提交人补充关键字段，或在记录中标注缺失并降级为疑似重复 |
| 比对逐项 | 现象、条件、范围三项是否分别给出结论，而非笼统写“相同” | 退回分诊人补做比对，补齐逐项结论 |
| 指向可追溯 | 是否写明重复指向的缺陷编号、检索关键词、判定人与确认人、判定时间 | 补录记录后再关闭，已关闭的补关联 |
| 差异有交代 | 版本、环境、复现频率等差异是否写明并由确认人给出处理意见 | 由模块负责人补充确认意见，未确认前不按重复关闭 |
| 处理动作明确 | 关闭、关联、转出或转为独立缺陷的动作是否记录 | 补记处理动作，避免记录停留在“已判定”状态 |
抽查分两个方向。正向抽查针对已判重复的缺陷，按一定比例抽取，复核依据是否齐全、三项比对是否逐项完成、指向是否可追溯；反向抽查针对被关闭或被合并的缺陷，用其标题关键词重新检索，检查是否存在本应识别却未被识别的重复，也就是漏判。两个方向的抽查结果都可以按分诊人或模块汇总，用于发现检索习惯或字段填写上的系统性问题。
抽查发现不满足项时，按问题类型退回：字段缺失退回提交人，比对不完整退回分诊人，差异未确认退回模块负责人。退回后补充完成的记录重新进入抽查范围。持续出现同类退回的，应回到字段清单与判定步骤表检查模板是否缺少必要字段，而不是只要求个人更仔细。
常见问题
新缺陷与已有缺陷现象一致但版本不同，还能判为重复吗？
可以判为重复，但需要在记录中写明版本差异，并由模块负责人确认。版本差异常见于同一问题在不同构建上的延续，现象、触发条件、影响范围三项一致时，版本不同不构成否定理由。若版本差异伴随现象或范围的变化，则应判为疑似重复或独立缺陷，由模块负责人决定是否合并跟踪。
提交人提单前自查过，分诊人还需要再检索一次吗？
需要。提交人的自查通常围绕自己遇到的报错关键词，覆盖范围有限；分诊人熟悉模块与历史缺陷，可以用模块名、功能入口、近义描述做组合检索，命中率更高。两次检索的关键词与结果都记入判定记录，既能减少同一问题被反复受理，也方便后续抽查时还原判定过程。
日志缺失时是否必须等提交人补齐才能判定？
不必一律等待。日志属于辅助证据，缺失时可以先用复现步骤、实际结果、环境版本完成检索与现象比对，在判定记录中标注“日志缺失”，结论标注为待复核。缺少复现步骤或实际结果则不同，这两项直接决定现象能否比对，应退回提交人补充后再继续。
重复判定记录需要保存多久，记录里最少写哪些内容？
保存期限按团队的质量追溯要求确定，通常至少覆盖当前版本周期与一次抽查周期。记录最少包含：新缺陷编号、重复指向的缺陷编号、检索关键词、现象比对结论、条件比对结论、范围比对结论、缺失字段说明、判定人、确认人与判定时间，以及关闭、关联或转出的处理动作。记录中的关键词与结论在下次遇到相似问题时可直接复用。
在缺陷管理工具中落地这套判定流程，需要先确认哪些配置？
先确认三件事：缺陷记录能否按需配置环境、版本、模块、复现步骤等字段；缺陷库能否按标题、关键词或相似描述检索；重复指向与判定结论能否在缺陷之间留痕关联。ONES Project 支持缺陷跟踪管理，可与 TestCase 数据互通并一键提 Bug，支持将 Bug 提交至对应项目或迭代中记录和跟踪修复情况，也能统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。缺陷库检索、字段自定义范围与重复指向的关联方式，需在选型核验时结合团队实际配置确认。
