BridgeLi's Blog

作为一个工作两年多的程序猿，可以说每天都在和bug打交道，一方面我们在源源不断的创造bug，另一方面我们又致力于消灭一个又一个被我们创造出来的bug。有人说，话不可绝对，否则就是错了，那么说句话的人有没有意识到他这句话就是绝对的呢？是不是也是错的呢？借用他这句话的意思，那么他说的这句话肯定也是错的，事实上也确实就是错的，因为在软件编程界有一句话：世界上没有bug的系统是不存在的，这句话可以说是绝对的正确的。那么世界上没有bug的系统既然是不存在的，那么这么多系统是怎么被上线又运行良好的呢？这就要从什么是bug，bug的严重程度，优先级说起。
首先要说明的是，老夫是一个程序猿，作为一个软件开发者，对bug的理解肯定没有相关的QA人员理解深刻，所以难免有错误，既然如此老夫为什么又要越俎代庖写下这篇文章呢？因为老夫工作的这两年里，深深地感觉有相当一部分QA，对bug的理解并没有那么的深刻，所以老夫希望能够根据自己工作的经验、自己对bug的理解写出来，以期能够抛砖引玉，希望有识之士给予指点，好了，下面我们就开始从什么是bug说起。

一. 什么是bug

bug，在IT公司里，每天都会听到这个词，那么什么是bug呢？或者说什么不是bug呢？在IT公司里面，有一部分人员是专职的QA，那么是QA说这是bug就是bug的吗？因为他们最喜欢的提bug了，他们的工作也是提出软件中的各种bug，还是程序猿说这不是bug就不是bug了呢？因为程序猿最不喜欢听到的一句话也许就是：某某系统或者功能又出bug了吧。我想肯定都不是，因为如果QA说是bug就是bug的话，因为QA也可能对需求理解的并不充分或者说理解错误；但如果程序猿说不是bug就不是bug的话，那么世界上的所有系统将不会有bug，又何谈世界上没有bug的系统是不存在的呢？下面老夫给出自己的理解：

1. 系统说明书上有而系统上却没有这个功能；
2. 系统有这个功能，但是所表现出来的和软件需求说明书上的不一样；
3. 系统说明书上没有，而系统上却有这个功能；

我想①和②大家都能理解的，就不举例说明了，但③可能有些人不能理解，需求说明书上没有，程序猿会做？当然不是不可能的，例如登陆的时候，需求说明上并没有验证码这一项，而程序猿根据自己的经验，很多系统都有，自作主张加上了，那么是不是一个bug呢？肯定是的，理解了什么是bug之后，我们看看bug的严重程度。

二. bug的严重程度

严重程度的英文是：Severity，一般来说不同公司对bug严重程度的是分级是不同的，但一般是根据系统是否符合产品说明书以及缺陷对于现阶段测试的影响而定义的，这里只给一个一般性的说明，一般来说bug可分一下五级：

1. 紧急（Crash）

一般是：不能执行正常基本流程，或者重要功能没有实现，使系统崩溃或资源严重不足。无法正常更正的问题。
例如：由于程序所引起的死机、非法退出、程序中断、死循发生死锁、数据通讯错误、功能与需求严重不符、异常退出、重要功能未实现等等
需要说明的是：一般紧急问题需要版本立即处理，处理后立即发版本。

2. 非常高（Major）

高一般是：影响其他模块功能不能正常操作，导致一些流程无法进行。
如：小功能没有实现、系统所提供的功能或服务受明显的影响、非法操作数据溢出、一般的数值计算错误
非常高的问题可视情况延迟处理，处理后需发版本，方便后期测试。

3. 高（Minor）

一般是：用户常操作的基本功能没有实现，存在合理的更正办法，用户可进行基本操作。
如：界面错误、格式错误、简单的输入限制未放在前台进行控制、小流程、功能错误
紧急、非常高、高等级的Bug的修改直接影响到产品能否合格的交付。

4. 中（Trivial）

中一般是：操作者使用不方便，但是不影响功能的实现。可改善的功能。数据边界不合理。
如：辅助说明描述不清楚、显示格式不规范、系统处理未优化（性能）、长时间操作未给用户进度提示、提示或页面文字规范、操作时未给用户提示、个别不影响产品理解的错别字、文字排列不整齐等一些小问题、使操作者不方便，操作失误可能导致严重问题出现、浏览器、系统、数据兼容性

5. 低（Nice to Have）

低一般是：易用性和建议性的功能
如：不影响使用的瑕疵、更好的实现方式。
需要说明的是，bug的严重程度一般应由测试人员定级

三. bug的优先级

bug的优先级的英文是：Priority，bug优先级应根据发版需求、公司要求、bug发生率和bug严重程度来划分。主要用于提示研发同事即时修复bug，使版本能按照预期发布，和严重程度一样，也分一下五级：

1. 紧急（Urgent）

立即修复的bug，他阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试

2. 非常高（Very High）

本版本必须修复的bug

3. 高（High）

必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正

4. 中（Medium）

时间允许应该修复的bug或可以暂时存在的bug

5. 低（Low）

可不修复的建议，可以一直存在的问题

四. bug的严重程度和优先级的关系

看了bug的严重程度和优先级之后，我们再说说他们之间的关系？当时我和同事再说这个问题的时候，他们都认为这还用说，bug严重高的优先级也一定高啊！事实是这样的，事实上他们之间并没有关系，严重级别的bug不一定优先级别高；优先级别高的bug也不一定严重级别高。因为优先级别和暂时发版的模块密切相关，但是bug严重程度与暂时发版无关，另外Bug的优先级别和公司要求也有关，如电子商务网站，那么界面优化用户体验对于公司就很重要；虽然界面上的问题并不影响使用，所有严重级别不高，但优先级却非常高；而有些系统只是内部使用，界面优化就不那么重要了；还有一些网站只是数据正确性要求比较高，界面和操作要求不高等等。这些都是严重程度很低，优先级却不一定的例子，最后再给大家说一个windows的记事本的bug，大家可以新建一个记事本在里面输入：“联通”俩字保存退出，再打开看看，这个严重程度够大了吧？但微软却一直并没有修，说明了什么问题？类似的例子还有很多，大家可以自己想想：什么的bug严重级别很高，优先级也很高，什么的bug严重级别很高，优先级却很低，什么样的bug严重程度很低，优先级却很高，什么样的bug严重程度很低，优先级也很低。