Bug跟踪管理系统初学者指南：Bug生命周期完整走一遍

测试提了 Bug，开发说没收到；开发说改完了，测试验证不通过；验证通过了，下个版本同样的问题又冒出来。

这类情况的原因往往不在人，而在状态和责任边界没有定清楚：谁在什么状态下做什么，满足什么条件才能把状态往下推，谁有权把它打回。Bug 生命周期就是把这些问题固定下来的那条路径。下面按状态顺序完整走一遍，每个环节给出动作、成功信号和常见卡点，最后说明怎么把流程固化到 Bug 跟踪管理系统里。

一、Bug 跟踪管理系统是什么，解决什么问题

一个 Bug 从被发现到被关闭，要经过多个状态、多个角色和多次信息交接。Bug 跟踪管理系统就是承载这条路径的信息系统。

1. 它要记录的两类信息

一类是 Bug 本身的信息：重现步骤、影响版本、严重程度、优先级，以及它关联的需求与用例。另一类是状态的每一次流转：谁改的、什么时间改的、依据是什么。两类信息缺一不可，只有问题信息而没有流转记录，就查不到处理过程；只有流转记录而没有问题信息，责任清楚，却说不清问题到底是什么。

2. 它与表格工具、协作看板的边界

表格能存信息，存不下条件和责任。状态推进需要权限约束、必填字段校验和完整的历史记录，还要能按版本、模块、时间做汇总，这些用表格很难稳定做到。

通用协作看板擅长把任务摆到一张板上，但 Bug 的管理对象是偏差：实际结果与预期结果不一致，通常要求能复现、能追溯引入版本、修复后能验证。可复现和可验证这两个要求，直接决定了系统里要设计哪些字段和状态。

对同时管理需求、用例和发布的人来说，Bug 不是孤立记录。用例执行失败可以直接转成 Bug，Bug 解决后要在对应版本上验证，需求变更时要回看有哪些历史问题。禅道把需求池、需求、用例、任务、Bug、代码、反馈、工单列为八个核心概念，Bug 与测试管理、需求管理位于同一套数据中，闭环推进不需要跨系统复制信息。

二、Bug 生命周期总览：主干五步与流转规则

Bug 生命周期指一个 Bug 从被创建到被关闭所经过的完整状态路径。不同团队的状态命名并不统一，有的把确认和指派拆成两步，有的合并为一步，但主干是稳定的：新建、确认与指派、解决、验证、关闭。验证不通过就退回处理环节，形成重开循环。

1. 主干五步与责任归属

下表按主干顺序列出每个状态要产出的东西。

开发解决时会一并指派回测试，记录随即进入待验证范围，中间不需要额外的确认动作。这张表说的是每个状态该产出什么，不是一张审批清单。具体的判断标准在后面的提交、确认与验证三节展开。

2. 两条容易走偏的流转规则

状态推进要有依据，不能只点按钮；重开是设计内的路径，不是异常情况。异常分支的处理规则放在第七章。

三、提交环节：写出一份能被复现的 Bug 单

提交环节的目标是让接收人在不追问的情况下把问题复现出来。

1. 必填字段与标题写法

字段上，这几项缺一不可：所属产品与模块、影响版本、Bug 标题、重现步骤、实际结果、预期结果、严重程度、优先级、当前指派。

标题写现象加触发条件，不写主观判断。例如订单详情页在旧版内核浏览器下金额显示为科学计数法，就比金额显示错误更容易被定位；而登录页打不开这类只描述感受的标题，会让接收人先来问你一遍。

2. 重现步骤与环境信息

重现步骤按最小可复现路径写，一步一个动作，带上前提数据。写完自己照着走一遍，确认能稳定复现；如果只是偶现，就在步骤里写清出现频率和尝试次数。

环境信息单独列：版本号、环境类型、浏览器与版本、账号角色、涉及的数据状态。很多被标为无法重现的 Bug，追到根上都是环境差异。

附件用来说明问题，不是替代描述。截图圈出异常位置，日志和报错信息直接贴文本，避免只放一张全屏截图让人自己找。

3. 提交时最常见的三类问题

一单塞进多个问题，修复进度无法跟踪；只写期望结果不写实际结果，接收人判断不了偏差；把截图当步骤，接收人只能靠猜。提交完成的成功信号很直接：状态进入待确认或已指派，责任人清楚，信息完整到别人能独立复现。

四、确认与解决：开发侧怎么把状态往下推

1. 确认环节判断什么

Bug 指派到开发后，第一件事是确认，不是直接改代码。确认要回答两个问题：问题是否真实存在，是否属于当前版本要处理的范围。判断依据不是标题，而是重现步骤和影响版本，先在自己的环境按步骤走一遍；复现不了就先对齐环境差异，再决定走哪个分支。

2. 解决时必须补齐的三项信息

推进到已解决状态时，要同时填写三样东西：解决方案、解决版本，以及指派回测试（即下一处理人）。解决方案决定这个 Bug 以什么理由收口，解决版本决定测试在哪个版本上验证。少填任何一项，测试都会卡在不知道验证什么这一步。

常见的流程断点是跳过确认直接解决。表面上省了时间，实际上把风险留到了验证环节。问题如果没有被确认过，测试无法区分已经修复和从来没有存在过。

五、验证与关闭：不通过就重开

1. 有效验证包含三件事

在修复版本上按原重现步骤走一遍，确认问题不再出现；回归与该功能相关的其他路径，确认修复没有引入新问题；检查同一模块下是否有同类问题需要一并处理。

2. 不通过时怎么重开

验证通过，测试把状态改为已关闭，并记录验证版本。验证不通过，就把状态重新激活（退回处理环节），同时补齐证据：在哪个版本、用哪组步骤、看到了什么现象。只写一句还是不行，会让下一轮修复重新开始猜。

关闭只是状态变化，记录通常仍保留在版本、模块和需求的关联里，后续版本再次出现时回到处理环节，历史过程完整可查。把重开当作正常路径，团队才不会为了数据好看而回避重开。重开比例本身就是有价值的质量信号。

六、严重程度和优先级：先分清，再排序

1. 两者的区别

严重程度描述影响，回答这个 Bug 有多严重；优先级描述顺序，回答什么时候修。同一个 Bug 可以严重程度高而优先级低，例如只在少数旧版浏览器上触发的崩溃，影响面有限，可以排到后面；也可以严重程度低而优先级高，例如对外页面上的错别字，影响不大但当天就要改。

2. 定级参考

实际定级时，严重程度看影响范围，优先级看版本目标、客户影响和修复成本，两者的判断标准不同，定级的人也可能不是同一个。优先级通常在产品或项目层面的评审会上确定，不由提交人单方面填写。下表给出常见的严重程度分级与响应方式。

这张表的作用是统一口径：同一个现象由不同人定级，定级结果应当大致一致。口径不统一，跨团队汇总出来的数据就没有可比性。

3. 定级失真的常见原因

最常见的用法错误是所有人都往最高等级填。当所有 Bug 都被定为致命或严重，排序就失效了，最后变成谁催得急谁先修。可以约定一条规则：致命与严重等级的占比超过某个比例时，由评审会复核定级。

七、异常分支怎么收口：重复、无法重现、不予解决与延期

1. 异常分支的收口规则

不是每个 Bug 都会一路走到关闭。处理过程中会出现各种结论，每一种都要有明确的确认人和收口动作，否则问题会在角色交接中消失。

下表把常见的异常结论、含义、确认人和收口动作放在一起对照。

这张表里延期处理不等于关闭：它确认了问题存在，只是晚些修。若把它当作关闭处理，后续排期时就容易漏掉这条记录。

2. 谁有权决定不修复

不修复类的结论由产品负责人或项目负责人确认，而不是处理人单方面决定。这不是流程繁琐，而是避免问题在角色交接中消失。支持这类管理的系统，通常都能在后台自定义解决方案选项与状态流转条件，让流程贴合团队既有规范。

八、谁来推动流程走完：四类角色的边界与节奏

1. 四类角色各自关注什么

测试关心问题是否可复现、是否闭环，负责保证 Bug 单完整并在验证时给出证据；开发关心问题是否真实存在、是否属于当前范围，负责在解决时写清解决方案与版本；产品负责人关心要不要修、先修哪个，负责定级、评审以及设计如此、不予解决这类结论的确认；项目经理或研发负责人关心整体节奏与质量趋势，负责让流程被遵守、让卡点被暴露。

2. 用固定节奏和指标代替争论

冲突点很具体：测试希望严重问题优先，开发正在赶迭代内的需求，产品要平衡客户承诺与版本节奏，项目经理要保住里程碑。这些冲突靠声音大小解决不了，需要有固定的评审节点，例如每日同步高危 Bug，每个迭代过一遍未解决的 Bug 池。

用数据代替争论更有效。可以持续观察未关闭 Bug 的趋势、平均修复时长、重开比例、Bug 在版本上的分布、在模块上的集中度。重开比例上升，通常说明修复方式或验证方式出了问题，而不是测试要求太严。这类数据可以在禅道的效能分析与统计报表中按周查看。

九、把流程固化进系统：Bug 跟踪管理系统的落地要点

1. 系统要满足的四项能力

规则只写在文档里，很难长期执行。一套能承载 Bug 生命周期的系统，至少要满足四件事：字段和状态可配置，能与用例、需求、版本关联，有权限与操作记录，能出统计报表。

下面四个场景分别对应这四项能力，可以用来判断系统够不够用：一个 Bug 影响两个版本，能不能同时标注；验证不通过，能不能回到处理环节并保留完整历史；这个 Bug 是从哪条用例发现的，能不能追溯；某个模块的 Bug 是否在集中上升，能不能按周看到趋势。

禅道的质量管理模块把 Bug 与用例、测试单、版本放在同一条链路里，指派、解决、验证、关闭的流转与解决方案记录留在同一套数据中，也可以通过项目管理与工作流、权限配置适配不同团队的处理规范。部署层面支持私有化，也提供面向信创环境的适配方案，涉及具体平台与版本时，以禅道官方渠道的说明为准。

2. 落地顺序

按四步走，顺序颠倒容易返工：

1. 统一字段。先把影响版本、模块、严重程度、优先级、重现步骤设为必填，其余字段后置。

2. 统一状态与分支规则。明确主干五个状态，以及每种处理结论的确认人。

3. 打通关联。把用例、需求、版本与 Bug 关联起来，让闭环有数据可查。

4. 建立节奏。确定评审频率和要看的指标，把数据用在改进上，而不是汇报上。

3. 链路断开的自查信号

有人口头通知 Bug，系统里查不到记录；Bug 长期停在待确认状态，没有明确责任人；已关闭的 Bug 再次出现，却找不到原记录；统计报表与团队的实际感受差距很大，说明字段填写过于随意；版本发布前，没有人能说清当前未关闭的致命与严重 Bug 有多少条。出现这些情况，都要回头检查前面的步骤。

十、常见问题

1. Bug 提了但开发不认可，来回拉扯怎么办

分歧多半出在判定标准不一致。把预期结果和验收口径写进 Bug 记录，验证时以记录为准；如果产品设计本身不明确，拉产品负责人当场确认，并把结论补回到需求或用例里，避免同一个分歧反复出现。

2. 频繁迭代的小版本，Bug 也要走完整流程吗

流程可以简化，动作不能省。评审环节可以合并，记录粒度可以放宽，但验证和关闭这两个动作要保留，省略验证直接关闭，等于把风险推到线上。

3. 用 Bug 数量考核测试人员，合适吗

不合适。数量容易通过少提、晚提、合并提交来改变，指标会失真。更稳妥的观察方式是关闭率、重开比例和高危问题的处理时长，而且这类数据适合用来评估流程，不适合用于个人考核。

4. 提 Bug 会不会影响和开发的关系

把讨论对象从人换成记录，这类顾虑会少很多。Bug 单描述的是可复现的现象和偏差，不写谁的责任；定级和优先级交给评审节点决定，不在提交人与处理人之间私下争。

5. 历史遗留的 Bug 太多，能不能直接清理

不建议直接删除。可以按状态归档：确认不再复现或已转需求的关闭归档，仍然存在的重新定级并纳入排期。批量删除会切断版本与用例的关联，后续追溯就没有依据，这也说明 Bug 跟踪管理系统里的状态与字段需要定期校准。