Bug 跟踪管理系统常见问题：重复提交、状态卡住与漏测复盘

一套 Bug 跟踪管理系统是否好用，通常不看功能数量，而看三件事能否做到：同一个问题不被反复开单，Bug 不在中间状态长期停留，线上暴露的问题能回到用例和发布检查。

这三件事分别对应重复提交、状态卡住和漏测复盘，也都在考验同一套规则：提交信息是否足够判断，状态是否绑定责任人，复盘结论是否写回流程。

一、先看系统能否支撑三件事

很多团队把问题归因于执行不到位，换一套工具后仍然重复出现。更常见的原因是系统只记录了结果，没有把判断规则放进字段和流程：字段不全，重复无法识别；状态没有责任人，流转靠催；复盘没有关联数据，只能凭印象。

1. 三类问题共用一个判断框架

判断时先问三个问题：提交信息是否足够判断，状态是否绑定责任人，复盘结论是否写回用例和发布检查。重复提交对应第一个问题，状态卡住对应第二个，漏测复盘对应第三个。先看当前最影响交付的是哪一类，再决定先改哪一段。

2. 一套系统通常要看五项能力

如果正在选型或评估现有系统，可以先看五项能力：

• 必填字段和提交模板，保证影响版本、复现步骤、实际结果和期望结果可比较。
• 相似 Bug 搜索和重复关联，支持按模块、关键词、版本查找，并保留主 Bug 与子记录的关系。
• 状态权限和通知，让每个状态有负责人和下一动作。
• 需求、用例、Bug、版本的关联，复盘时能回到原需求、原用例和发布版本。
• 按版本、模块、发现环节统计，能看趋势，而不是只看总数。

这五项分别对应三件事：字段和查重主要解决重复提交，状态和通知主要解决状态卡住，关联和统计主要支撑漏测复盘。

这五项不追求一次配齐。先保证提交、查重、责任人和版本关联，再补统计和自动化。

二、重复提交：先看症状，再确认根本原因

重复提交常见的原因不是测试人员不认真，而是提交前缺少统一判断。标题只写页面报错，模块、版本、环境留空，开发只能追问；同类问题换个人提交，又变成一张新单。

重复判断要分两个阶段：提交阶段先看可观察的信息，分诊或修复阶段再确认根本原因。把根本原因提前到提交环节，测试人员很难执行，也容易把不同问题误合并。

1. 提交阶段先做三项检查

提交人先按模块、关键词、影响版本搜索已有记录，再确认三件事：症状是否一致，触发路径是否一致，发生版本和模块是否一致。三项都吻合时，先关联已有记录，在描述里补充新环境、新用户或新影响范围；无法确认时，写明待确认，不要急着标记重复。

Bug 标题建议写成场景、操作和异常现象，正文保留影响版本、复现步骤、实际结果、期望结果、环境和必要日志。提交 Bug 时至少保留这些信息，后来的人才有条件判断是否重复。提交入口见提交 Bug。

2. 分诊后再确认是否重复，并保留影响

分诊或修复阶段，由开发确认根本原因。确认同一原因后，在禅道中把解决方案选为 重复 Bug，并填写主 Bug 编号，让两条记录保持可追溯。不建议直接删除子记录。 不同用户、不同环境、不同影响范围都是判断风险的材料；删除后，团队会误以为问题只出现过一次。

如果根本原因不同，即使症状相似，也应保留独立记录并互相关联。比如支付页和订单页都提示超时，一个由接口限流触发，一个由数据库锁等待触发；症状相同、根本原因不同，就属于这种情况。

每周回看重复率，重点看哪类问题反复被不同人提交，而不是只盯数字。重复问题收敛后，更值得关注的是状态是否又开始堆积。

三、状态卡住：先看停在哪个节点

状态卡住常被归因于开发不配合或测试不跟进，实际原因通常更具体：某一步没有明确的下一位责任人，或者完成了动作却没有通知。Bug 跟踪管理系统里的常见主线是提交、确认、解决、验证、关闭；系统状态通常分为激活、已解决、已关闭三类。具体流转可参考Bug 管理流程。

1. 四类高频阻塞点

先按阻塞点定位，不要一上来就催所有人。分诊负责人通常由测试负责人或质量负责人担任，负责判断问题归属和优先级。下表把常见信号和第一步动作对应起来。

表格的关键不是增加状态，而是让每个阻塞点都有下一位责任人和可观察的完成标准。

2. 让状态重新流动的最小规则

先给三个节点定规则：新记录当天分诊，已解决记录在约定时限内验证，关闭后复现附上原版本和新版本。时限可以按团队节奏设定，例如两个工作日。规则最好写进团队约定，不靠群里提醒。Bug 解决后通常回到提交者或指定验证人名下，由测试负责人确认验证人。

长期挂起的低优先级记录，设固定盘点日。超过约定周期仍不处理的，要么给出延期理由和新的时间点，要么关闭并说明不再跟进。需要避免的是状态显示已解决，实际没有人验证；报表看起来干净，风险仍在。 状态恢复流动后，线上仍可能有问题未被发现，复盘方式决定它会不会再次发生。

四、漏测复盘：先确认是不是逃逸

线上问题出现后，最容易开的会是把测试人员叫来问为什么没测到。这种问法只能得到防御性回答。逃逸 Bug 通常指本应在测试阶段发现、却没有被发现，后来在线上或客户验收中暴露的 Bug。复盘要找的是流程缺口，不是找一个承担后果的人。

复盘前先确认两件事：这是不是逃逸 Bug；它是在哪个版本、哪个环境、哪个环节暴露的。环境配置、数据问题、需求变更和程序 Bug 要分开，否则所有线上问题都会被算成漏测。

1. 复盘只回答四个问题

• 哪个环节本应发现：需求评审、开发自测、测试执行、回归测试还是发布前检查。
• 为何没有覆盖：需求边界、用例、环境、数据，还是回归范围没有跟上变更。
• 补什么用例或检查：用例、自动化检查、评审清单、监控告警或发布前检查。
• 谁验证有效：负责人、时间点、成功信号。

四个问题要落到记录上。测试用例可以关联需求；部分系统还允许 Bug 记录来源用例。测试报告会根据测试任务单（测试单）的数据范围生成，包含测试范围、测试轮次、关联用例、遗留 Bug 和报表。复盘时把线上 Bug 反向关联到原需求、原用例和原版本，才能判断是漏测、误判还是环境差异。如果找不到原用例，这本身就是复盘结论，说明测试覆盖存在缺口。

2. 用趋势判断改进，不用单一数字追人

Bug 逃逸率可以作为观察指标，常见口径是测试阶段之后发现的 Bug 数除以测试阶段发现的 Bug 数与之后发现的 Bug 数之和。不同团队可能按生产环境、客户验收或发布后固定窗口统计，先统一口径再比较。这个数字适合看趋势，不适合直接考核个人。

更细的看法是按严重程度、模块和发现环节拆开。如果系统支持在发布信息中查看逃逸 Bug，并按发现环节、注入环节（Bug 在哪个环节引入）统计，可以直接用这些数据；没有这些能力时，用 Bug 报表、模块和版本字段做替代分析。

每月挑选少量高影响逃逸 Bug 重点分析。复盘结论要写成可检查的动作：新增哪条用例，谁负责，什么版本前完成，下次用什么信号验证。没有责任人和时间的加强测试，很可能再次出现。 三类问题分别修完，还需要一套共同的落地顺序。

五、把三类问题放进同一套规则

重复提交、状态卡住、漏测复盘并不是三套独立制度。它们共同依赖四个动作：提交时留下可判断的信息，分诊时明确下一位责任人，修复后验证原场景和相邻场景，复盘后把结论回写到用例、字段或发布检查。缺任何一环，其他环节的效果都会受影响。

1. 谁对流程负责

规则需要有明确负责人。测试负责人通常适合负责分诊和复盘组织，开发负责人负责修复排期和版本说明，项目经理负责跨角色争议和发布节奏。三方职责写清楚，状态才不会在交接处停住。

2. 30 天落地顺序

第一周统一 Bug 标题和必填字段，确定重复 Bug 的关联规则。第二周给状态节点补责任人和时限，先处理未指派和待验证两个阻塞点。第三周挑选少量线上逃逸 Bug 做复盘，产出可执行的用例或发布检查改动。第四周回看三个指标：重复率、复开率（修复后再次被激活的比例）、逃逸率，确认改动是否减少了返工。

这套顺序适合已有基本 Bug 流程、希望把规则固定下来的团队。尚未建立流程的团队，先补字段、责任人和版本关联，再谈统计。

工具只是承载规则。以禅道为例，需求、用例、任务和 Bug 可以放在同一条流程里，Bug 能回到需求与来源用例，测试报告能回到测试单和版本。即使换一套工具，也可以用模块字段、标签、报表和发布记录实现同样的关联；先把规则定下来，再决定用什么工具承载。

一套 Bug 跟踪管理系统的价值，最终体现在三个可观察的变化：同类问题不再反复开单，状态不再长期停在中间，线上问题能反向推动用例和发布检查更新。把这三件事固定成规则，系统才真正开始工作。

六、常见问题

1. 测试和开发对 Bug 优先级争执不下，怎么定？

把严重程度和优先级分开。严重程度看影响范围、数据风险和业务中断；优先级看当前版本的修复顺序。测试负责人给出影响判断，产品或项目负责人确认业务优先级，争议结论记录在 Bug 里。

2. Bug 数量下降，能说明质量变好吗？

不能单独说明。Bug 总数会受到合并重复、统计范围和集中关闭的影响。更有参考价值的是复开率、逃逸率和关闭前的验证完整度；三个指标一起看，才能判断问题是减少了，还是被转移了。

3. 漏测复盘要不要拉上产品经理？

要。需求边界、验收标准不清导致的逃逸，单靠测试和开发很难判断。复盘由测试负责人组织，开发说明修复和版本，产品确认需求口径；三方不到齐，容易把需求问题误判成测试遗漏。

4. 系统字段是不是越多越规范？

不是。字段越多不等于越规范。 必填字段只保留影响判断和复现所需的项。字段过多会降低提交质量，团队可能绕过系统，回到群里沟通。先固定版本、模块、复现步骤、实际结果和期望结果，再按需增加。

参考资料

• Bug 管理流程（官方资料），https://www.zentao.net/blog/zentao-bug-management-81583.html
• 提交 Bug（官方文档），https://www.zentao.net/book/zentaopms/529.html
• 测试用例（官方文档），https://www.zentao.net/book/zentaopms/527.html
• 测试报告（官方文档），https://www.zentao.net/book/zentaopms/testreport-1723.html
• 使用手册（官方文档），https://www.zentao.net/book/zentaopms/c5.html