谈谈Bug的生命周期和Bug状态变更原则

前言

在软件产品研发中，Bug既是测试工作最为重要的产出，也是开发人员修复问题的直接输入，更是产品质量改进的主要抓手。

在前文【测试大家谈 - 提Bug与提好Bug】中，我们从测试人员的角度，分析了在提交Bug时应如何帮助团队更高效地去进行质量改进。

但除了Bug提交环节，在我们工作中，Bug从发现到被修复，会经历一个完整的生命周期，对应到我们提交的问题单，会呈现不同的状态。而Bug在这些不同状态间的迁移，其实反映了团队围绕Bug的协作沟通过程。实际工作中，因为Bug认定或状态设定上产生的分歧屡见不鲜，特别是在很多将Bug作为重要KPI数据的团队，测试和开发之间因为Bug产生激烈争论，时有发生。比如：

• 开发和测试对Bug认定有分歧，测试觉得是Bug，开发觉得不是问题，怎么处理？
• Bug归属产生分歧，是前端问题还是后端问题？
• Bug无法复现，应不应该关闭？
• …等等

本文，我们就来详细梳理一下，Bug的完整生命周期，以及它在不同阶段的状态处理原则。

Bug的生命周期及不同状态

Bug并不是凭空产生，是在测试过程中暴露出来的质量问题，从被发现到完成修复并确认无误，会经历一个过程，这个过程就是Bug的生命周期。在软件研发过程中，针对这个生命周期的管理，通常会由Bug管理系统（常用的比如Jira、禅道、Bugfree、HP QC等）来跟踪和同步每个Bug的状态，并在开发和测试人员之间起到协作桥梁的作用。

Bug生命周期的主要过程大致如下：

已提交（Open）

Open 状态，是Bug被发现以后的初始状态。通常由发现Bug的测试人员录入Bug管理系统，形成问题单，此时Bug的状态处于 Open 状态，也表示该Bug待处理。

另外，如果有已关闭的历史Bug，后来发现其实并未解决，也可以重新将Bug激活，此时Bug也会处于 Open 状态。

在该状态下，提交Bug的测试人员应该指定处理Bug的开发人员进行下一步处理，通常会根据Bug的现象，直接指定到能修复Bug的开发这里。不过一般Bug管理系统，也会设置默认处理人，对于Open 状态的Bug&#x