缺陷管理：说一说bug的状态和解决方案

        经历过几家创业公司，发现大部分测试和开发人员，包括项目经理，对于bug状态与解决方案竟然傻傻分不清楚，导致bug管理与统计上的混乱，即使费尽了我的三寸不烂之舌与团队成员解释，也不见得真正有几个人能理解，或者即使理解了，也认识不到区分这两个概念的重要性。于是索性将这个问题做个整理写下来，好好的探讨一下，希望对这些基本概念有所普及。

        现在大部分测试人员只关心学习高大尚的自动化测试，性能测试技术，却对一些基本概念的理解却是模糊不清，甚是让我感到担忧，希望本文对于入行测试的初学者，以及已经走在成长路上的测试人员有所帮助，也希望看到此文的开发，产品经理，项目经理也能提高一下认识，以做到更好的对bug进行管理。

笔者亲身经历例子：

公司在teambiton中进行bug管理，bug的状态有：

• 待处理，
• 处理中，
• 已解决，
• 已拒绝，
• 暂不修复，
• 无法重现，
• 数据问题，
• 关闭，
• 重新打开

乍一看没什么问题，是吧？可你细品一下呢？

典型的状态与解决方案不分，混为一谈。

我先针对性的提几个问题：

• 已拒绝，暂不修复，无法重理等的问题要不要关闭？
• 关闭后如何知道那些问题是修复过的？那些是没有修复或不需要修复而关闭的？即如何统计bug的修复率（修复率=修复的bug/bug总数）
• 如何统计所有未修复的bug中，重复，无法重现的等无效bug的数量和占比？即bug的有效率（关于什么是有效的bug，估计也有很多同学概念也不是很清楚，也会引起很大的争议，可能还要另开文章来讲）
• 如果开发将bug解为已拒绝，拒绝的原因是什么？如何对拒绝的原因进行分类？

        在当时的情况下，唯一的办法就是只有修复并验证过的bug可以关闭，其他的bug保持状态不变（因为一旦关闭了，就不知道其当时的解决方案了，但也不能做到有效控制，有些bug没有修，因为各种原因被闭了，并且关bug时的描述有限，跟本无从判断到底有没有修复，追根溯源非常困难）。结果就是长期下来积累了大量的未关闭的bug，这些bug有哪些已经过期不能重现了？哪些可以关了？哪些还需要后续跟进？处于混乱状态。

        这令我非常惊讶，一开始我还以为是个例，在经历过几家公司后，我发现或多或少都存在类似的bug管理上的问题。包括做项目管理工具的teambition的，在bug管理的流程的设计上，上本身就没有做到正确的示范和引导。Jira在这方面就做的很好，状态和解决方案字段的默认设置已经区分的很明显了，无奈的是仍然有很多人企图更改Jira的默认设置并重新将解决方案放到状态字段中，当然他们的用词叫做改进，优化。

        我在微软（外包）工作时从来没有遇到过这种情况，微软工作流程已经非常成熟，以至于在我看来bug状态和解决方案的设计是bug管理系统的基础配置，也是软件工程师应该知道最基本的流程知识，根本不需要单独拿出来讨论。国内软件公司的实际的情况还是让我感到震惊和困惑，各种自动化工具搞的风生水起，一些不到百人的小公司都不输甚至超越国外大厂，但这种基础概念不清的问题还是广泛存在的，不仅导致高企的管理成本，而且极大的影响质量的管理和控制，所以确实有必要好好的梳理梳理，说道说道了。

先说办法，很简单，设计两个字段，区分状态与解决方案就好了。

声明：这并不是我的原创，Jira和微软就是这么做的，我只不过是搬运工而已。

bug的生命周期其实只有三种状态：

1. 打开（open），
2. 已解决（resolved），
3. 关闭（closed）

注意：这里将重新打开（reopen）也算做打开，reopen并不是一个状态，而是一个动作，bug被reopen后，就又变成了open状态。

注意：已解决（resolved）不等于已修复（fixed）

bug的解决方案可以是多种多样，常用的如下：

• 已修复（fixed）
• 不予修复（won't fix）
• 推迟处理（postpone）
• 无法重理（not repro）
• 重复（duplicate）
• 设计如此（by design）
• 外部原因（external）
• 其他（other，如数据原因，环境原因，配置原因等）

另外，发现网友suixhcud对bug解决方案的解释特别有意思，而且十分贴切，给个链接： 禅道BUG解决方案的各种说辞_suixhcud的博客-CSDN博客

注意：已解决和关闭的bug有且必须有解决方案，打开的bug是不应该有解决方案的（因为还没有解决，哪儿来的解决方案？）

流程控制：

• 当状态变为已解决和关闭时，解决方案为必填字段，否则不能改变状态。
• 当状态变为打开或重新打开时，清空解决方案字段

很遗憾，teambition没有提供这样的流程控制，也没有地方可以设置这样的流程控制，而jira默认的bug流程控制就是如此。

好了，这么做，我们看一下问题是不是解决了呢？

例如，有同学会问：没有有了已拒绝，暂不修复的状态，开发同学处理bug时，遇到不好解决的，需要以后再修怎么办？测试误报无法重现怎么办？

答：状态改为“已解决”，解决方案选“推迟处理”，“无法重现”。

        这里面让开发同学感到比较别扭的时，我明明没有解决这个问题，为毛让我选“已解决”？所以这就是我在上面提到的注意点了，即已解决不等于已修复。因为在中文表达中，解决了也有修复了的意思，我们日常所说的已解决，通常为“已经修复”的意思。举个反面例子：说一个开发跟项目经理说这一天他解决了10个bug，项目经理会觉得不错哦，小伙辛苦了，但是一看10个bug中有9个bug给的解决方案都是“不予修复”，实际上只修复了一个问题。想必项目经理内心应该会飘过几只。。。，项目经理应该会说，以后这种情况不要跟我说你解决了10个bug，实事求是，解决了1个就说1个。我的建议在汇报工作时，应该区分使用“修复”和“解决”二字，做到有效沟通，避免歧义（如，我今天解决了10个bug，其中修复了1个，另外9个我认为不是bug，不需要修）。有同学会说，原来你的解决方案就是玩文字游戏啊。我想强调的是这并不是文字游戏，因为在团队协作中，沟通是非常重要的，采用bug管理工具对bug进行管理，也是沟通的一种手段（要不每天都解释一遍已修复和没修复的bug，绝对的混乱和没有效率啊）。

强调：正确的区分“已解决”和“已修复”，是理解状态与解决方案区别的关键。

“已解决”只是状态，并不代表“已修复”。选择其他的方案，也可以视为对问题的“解决”。广义上说只要有“解决方案”，就是“已解决”。其实，resolved应用到bug处理流程上时，翻译为“已处理”更贴切，更不容易产生歧义，就是说这个bug已经处理过了，至于如何处理的，可以去看解决方案字段。已处理肯定不会等同于已修复，选择“不予修复”也代表处理(resolve)过了，至少说明这个bug被看过了，并且做出了处理意见。这就是我们想要的，我们希望resolved（“已解决”或叫“已处理”）这个状态，能代表“这个bug已经被人处理过了，处理人已经给出了“解决方案”这个含义。

状态和解决方案各司其职，状态清晰了，妈妈再也不用担心小明的bug统计问题了。

比如，统计所有未修复就关闭的bug，只要查询解决方案不等于“已修复”，且状态是“关闭”的bug就可以了。再比如，统计所有开发已经做出了响应，但是测试还没有处理的bug怎么办？筛选出所有“已解决”的bug就可以了，首先所有已解决的bug一定是开发响应过，选择了解决方案的，而测试处理过的要么就是关闭了，要么就是重新打开，所有仍处于已解决状态的，一定是待测试处理的。通过上面两个例子，是不是将原来头疼的问题，很简单就解决了呢？

最后总结下解决方案和状态的区别

状态

• 状态记录bug当前处于某个阶段
• 状态是相对临时的，是会随着bug的处理过程和而变化的
• 状态最终趋向关闭
• 适合做项目的进行中分析，不适合做事后统计分析（如未解决的bug数量，已关闭的bug数量等）

状态用在项目进行过程中，为项目的进度提供统计支持，统计结果是实时变动的。由于其最终的值都是关闭，故不适合做项目结束后的统计分析。

解决方案

• 解决方案记录对一个bug的处理决定（可是是修复，也可以是拒绝修复）
• 解决方案的填写只发生在bug的状态由“打开”变为“已解决”时，一般由开发人员填写
• 当产品，项目经理，测试，开发等人员对解决方案存在争议时，需要开会讨论并形成最终决定
• 解决方案是相对永久性的，形成决议后不再变化
• 适合做事后统计分析（如bug的修复率，未修复bug数量，无效bug数量等）

注：关于统计bug的有效性，例如，可以将已修复，不予修复，推迟处理的bug视为有效bug，无法重现，重复，设计如此，外部原因等可以统计为无效bug，基本就是这么划分的，如果对有效bug和无效bug的范围有争议，可以由质量部门和项目组共同决定。这是基础的标准，一旦定决定了，就不要乱改了。