Bug 跟踪矩阵怎么用：把状态、角色与交付物对齐

Bug 列表里显示已解决，测试复测却没通过；开发说代码已经提交，产品以为可以发布。问题往往不在工具，而在状态、角色和交付物没有对齐。Bug 跟踪矩阵把这三件事放在同一张表里：每个状态由谁主责、要留下什么、达到什么条件才能进入下一步。 对中大型研发团队来说，这张表能减少反复确认和无效等待。

一、先明确矩阵的边界

Bug 跟踪矩阵是团队的管理工具，不是某个标准规定的固定模板。它的作用不是多画一张图，而是让 Bug 在流转时有一份可检查的记录。

矩阵有三个维度：状态、角色、交付物。状态回答现在走到哪一步；角色回答这一步谁主责；交付物回答这一步留下了什么。三者放在一起，团队就不容易在已解决和已关闭之间产生分歧。

没有交付物的状态，只是一个标签。 比如开发把 Bug 标成已解决，却没有修复版本、自测说明和影响范围，测试就无法判断该验证什么，产品也无法判断能不能发布。

二、把状态拆成可执行的节点

状态不要混在一起。建议先保留六个主状态：提交、确认、处理中、已解决待验证、已验证、已关闭。每个状态最好只对应一个主责角色，其他角色写配合。

交付物就是这一步需要留下的记录或结果；完成标准就是进入下一状态前需要满足的条件，最后一个状态是关闭记录完整、可追溯。

提交人由测试、开发、产品/项目、发布/运维中的任一角色担任，不单独算第五类角色；谁提交，谁负责把信息补全。下面的表把六个状态、主责、配合角色、交付物和完成标准放在一起。

这张表的关键在最后两列。完成标准不满足，就不要进入下一状态。

测试报告和发布说明通常是测试单或版本级交付物，不要求每个 Bug 单独产出。产品负责需求边界和验收标准，项目负责排期和风险；团队可以把两者合并为一个配合角色，但责任要写清。

已验证和已关闭分开，是为了区分测试确认和记录归档。已验证表示测试确认修复有效；已关闭表示关闭记录已经归档，不等于版本已经发布。

已验证后，测试补齐关闭原因；修复类 Bug 补充根因与预防项，测试负责人确认记录完整，状态转为已关闭。版本是否发布，仍由发布前检查单独判断。如果团队流程较简单，也可以把两者合并。

异常分支单独处理：

• 确认阶段发现不是 Bug、重复或无法复现：由开发给出证据，产品确认，测试关闭并标注原因。
• 确认或处理中决定延期/降级：由产品/项目记录风险接受人和新时间。
• 已解决待验证阶段验证失败：测试写清失败证据，状态回到处理中。

异常分支不混进主流程，矩阵才能保持清晰。

三、四步搭出第一版

第一步，选状态。只保留六个主状态，把同义状态合并。如果两个状态经常同时出现，说明它们可能是一个状态。

第二步，定主责。每个状态设一个主责，主责随状态转移。比如开发确认可复现后，主责转到开发；开发解决后，主责转回测试。如果一件事出现两个主责，通常是状态没有拆清。

第三步，写交付物和完成标准。完成标准要让第三个人也能检查。看版本、看记录、看结论，三项都能对上，才算满足。

第四步，做历史回放。抽 10 个已关闭 Bug，按新表走一遍，看哪些状态找不到责任人，哪些交付物实际不存在。如果多数 Bug 走不通，先改问题最多的那一处，不要急着全员推广。

四、一个 Bug 怎么走完

以支付回调重复扣款为例。测试提交时写清订单号、回调日志、复现步骤和影响范围；开发确认是回调接口没有正确处理重复请求，导致同一笔回调被重复处理，给出修复版本和影响分析；测试用原订单号和并发回调场景回归，记录验证结论；产品确认退款规则；发布前由测试和发布负责人检查关闭记录与发布说明。

整个过程不靠群里追问，而是按每个状态留下的记录推进。每个状态最好都留下能被第三个人检查的记录。 记录不全，状态就不应该继续推进。

五、在禅道里落地

矩阵不能只放在文档里。团队用禅道时，可以把矩阵映射到 Bug 流程。禅道的 Bug 流程包含提交、确认、解决、验证关闭和激活等动作。矩阵状态用于管理，工具里的状态用于系统流转，两者用映射表对应，不要求逐字一致。

1. 状态映射

矩阵里的已解决待验证，通常对应禅道的已解决状态；已关闭对应禅道的已关闭状态。已验证是检查点，工具里不一定有独立状态，可以用验证记录加关闭动作承载。

提交、确认、处理中通常都落在禅道的激活状态，通过确认动作、指派记录和看板列区分；如果团队需要更细的过程，用字段或看板列承载，不必强行新增系统状态。多产品线共用状态和交付物，角色和字段按产品线扩展。状态名尽量统一，跨项目汇总才有意义。

把影响版本、严重程度、优先级、所属模块设为常用字段，用权限控制谁能关闭、谁能激活。

这张三栏图适合在启动会上讲清状态、角色和交付物的关系，避免一开始就陷入字段配置。

2. 版本与测试单

已解决要关联修复版本，验证要挂在测试单下。这样修了没有、测了没有、能不能发，能在同一条链上回答。

禅道官方的最简使用流程把版本、测试单和测试报告串在一起；发布前可以把未关闭的高优先级 Bug 作为准入条件。具体字段和流程以团队当前版本配置为准。

这条链的重点不是箭头，而是每个节点都能追溯到一份记录。

3. 看板指标

看板至少看四个指标，并写清计算方式：

• 重新激活率 = 本期重新激活次数 ÷ 本期解决 Bug 数，按同一统计周期看趋势，不用于精确考核。
• 平均处理时长 = 提交到关闭的平均值；为避免极端值影响，可同时参考中位数。
• 一次验证通过率 = 首次验证通过数 ÷ 首次验证总数。
• 线上逃逸数 = 发布后发现的、由本次变更引入的 Bug 数，关联版本和环境。

指标按团队和版本拆分，按周看趋势。指标要写清计算方式，否则无法判断流程是否真的改善。

四项指标不需要每天盯，按周看趋势、按版本看异常即可。

六、固定节奏与失效信号

矩阵要进入日常动作，否则很快会回到群里催。

每天站会前，各产品线测试负责人或测试接口人看提交和待验证队列，超时的 Bug 在站会上点名。每周质量例会检查三类异常：长期停在处理中、反复激活、已关闭但缺少验证记录。每个版本发布前，测试和发布负责人做发布前检查：高优先级 Bug 是否清零，延期是否有风险接受人，测试报告是否覆盖本次变更。

出现以下信号，说明矩阵该改：状态名越来越多，大家开始自建表格；Bug 关闭很快但线上问题反复；重新激活率持续上升；延期 Bug 没有风险接受人。

修正时先删状态，再并角色，最后补交付物。不要一上来加字段和报表。

七、常见问题

1. 测试和开发对严重程度判断不一致，听谁的？

先按影响范围和发生频率定严重程度，再结合版本节奏定优先级。双方意见不一致时，由产品、开发、测试一起确认，把结论写进 Bug 单。严重程度不等于优先级，前者看影响，后者看先做谁。

2. 线上发现的 Bug 要不要补录？

建议补录，并关联发布版本和环境。否则线上逃逸数、回归覆盖和版本质量都会被低估。补录可以简化字段，但复现步骤、影响范围和责任版本不能省。

3. 矩阵要不要直接挂绩效？

不建议直接挂个人绩效。否则容易隐藏 Bug、拖延状态，或者挑容易的 Bug 关闭。更稳妥的做法是看团队趋势和过程改进，把指标用于发现问题，而不是排名。

4. 老项目的历史 Bug 怎么迁进新矩阵？

先做一张旧状态到新状态的映射表，保留原状态字段，选一个产品线并行一个迭代。确认新表能走通后，再逐步切换，不要一次性改完所有项目。

Bug 跟踪矩阵不解决所有质量问题，但能减少状态不清、责任不明和验证缺失。先用一张六状态、四类角色的表跑一个版本，再决定是否扩展。