既然选择远方,便只顾风雨兼程……

Bug之七——优先级

上一篇 / 下一篇  2009-02-03 12:41:12 / 个人分类:BUG系列

        Bug的优先级是bug管理过程中必须考虑的问题。对于优先级的划分,不同的软件公司有自身的一套制度,因此笔者介绍的也仅仅是自己比较喜欢的一种方式。

Lr9B m? L`0

 

v:m b$wm w%[[b}z0

        为了便于bug的提交和管理,也为了方便于与开发人员进行交流,笔者倾向于在项目中将bug划分为三个等级,而不是网络上流传的五等级版本甚至七等级版本(在成熟的软件组织中,使用更细的bug等级划分有利于bug分类,质量评审等工作的顺利进行)。这三个优先级分别即优先级1(严重的),优先级2(比较严重的)和优先级3(一般的)。

!|^!Ct$H h+~Y0

 

(Mn }'Im2i}0

        笔者划分bug等级的指导思想很简单,严重影响测试执行的bug是最严重的,即优先级1bug,除此之外所有导致应用程序崩溃掉的bug也列入到优先级1中;其他功能性bug列入比较严重的bug的队伍,即优先级2;界面上的bug列为一般的,即优先级3

iv'P~,Q1F2~L0

 

.Acm#~_bk)xb)}0

        作者在实践过程中推行的就是这种bug分级制度。这种分级制度看起来过于主观,而不像网络上流传的各个bug优先级划分的版本中,将每个优先级的bug的表现都一五一十列出来,如下是笔者以前使用到一个bug优先级划分文档中列出的优先级1bug特征:51Testing软件测试网 ^D(p.f B^

a)        应用程序某个模块功能未实现(包括整个模块不能运行)

A-YF@^ GAR@0

b)        用户的信息被破坏或者丢失51Testing软件测试网,xla,_ ~uZ%` S-]

c)        可重现的不可避免的崩溃,死锁

\Zr pg0

d)        功能和性能急剧衰退

p1M-~$K _ CH!f&Tu0

e)        严重的内存泄漏51Testing软件测试网s)u(~|&V{gf

f)         导致功能无法正常使用的UI设计(UI响应迟缓)51Testing软件测试网I.mj$iSt

g)        其他51Testing软件测试网K\P"o8PHQ\

 51Testing软件测试网SLmZi-ciO

的确,这些bug优先级划分很明确,让人一目了然并且觉得很有道理,可是拿到实际中一用,麻烦开始来了。因为某些描述仍然不够详细,含混不清的描述诸如“功能和性能急剧衰退”,碰到这种描述,不同的人会有不同的理解,而不同的理解必然会带来各种各样的问题。因此,笔者在实践中逐渐摒弃了这种做法(当然,笔者并不排除将来可能还是会回到一些比较正规的管理方法上来,但是目前这种“标准”方法并不适合笔者所在的公司~),并开始逐步推广笔者自己刚才提到的粗放式bug优先级划分方法。

6r D3LP6s7C0

 

NR`#uU0Z~w0

        对于该划分方法,笔者还需要进一步的说明。笔者刚才提到的“严重影响测试执行的bug”其实也是指系统的基本功能或者核心功能,比如新建编辑删除功能中,对于同样是信息为保存到数据库——即新建后记录未添加到数据库,编辑后记录未更新,删除后数据仍然存在于数据库中——这时候笔者仅仅将新建功能的该bug置于优先级1中,编辑删除bug则置于优先级2中。这种方法与很多正统的方法很不一致,因为在很多划分方法中“信息未保存”都是优先级1bug。但是笔者自认为这样做是有理由的:当新建功能发生该类型bug而编辑删除功能正常时,编辑删除功能仍然无法测试或者实现(因为没有数据啊),这在客户的江渡看来会直接视为新建编辑删除功能均未实现。新建功能正常而编辑或者删除功能失效,则不会影响到其他功能的使用(当仅编辑功能失效的时候,新建和删除功能并不会受到影响),测试人员仍然进行新建删除功能的功能测试,客户依然可以使用新建和删除功能。51Testing软件测试网&J7m;J|#P9v

 51Testing软件测试网`usuw$W4\0\G`

        当然,笔者使用上面的划分方式还有其他的原因——基于bug管理和测试开发工作的顺利推进。读者可能会注意到,使用上面的bug划分方式会减少优先级1bug的数量,笔者这样做是因为笔者在bug管理中推介的方式是优先级1bug不允许推迟到下一个工作日修改。试想,如果优先级1bug的数量如果过多自然会导致这种管理方式推行的极大阻力——没有哪个开发人员会喜欢让自己一整天的时间花费在修复bug上。当我们提交的优先级1bug都是非常紧急的,会影响到开发或者测试的进度的话,开发人员就自知理亏不得不去修复这些bug了,这就保证了即使到了项目很急迫的时间,我们项目的主体功能还是稳定可用的,并有效遏制了严重bug的生存期。51Testing软件测试网&Q ^ R+h5x%g

 51Testing软件测试网f A$sI PWi#V_ KJ

        对于优先级2与优先级3的划分点,只是笔者个人看法,因为笔者目前所经历的项目都是功能性为主,因此对于UI相关的要求相对较低,因此笔者采取了这种粗放的方式(将UI相关bug归纳为优先级3,其他的非UI的非优先级1bug全部塞到优先级2的集装箱中~)。

s/{&T Qe0

51Testing软件测试网#W_HQ K

d'Q/k,Q KK%P9jrq0

   PS:感谢下面一位同仁的回复,优先级1类的bug还应该包括功能严重不符合产品说明书这种类型的bug。
} |8KC1C*H7x0

3h YXO|8S H A"p0

 

#g:G%J0WxH!yD0

        以上为个人观点,如有意见建议或者交流需要,请联系unique.wuchaodong@hotmail.com

Fs}?0]_x0

TAG: Bug BUG系列

Aaron的测试生活小说 引用 删除 UniqueStudioWCD   /   2009-02-03 16:50:25
恩,这个我赞成。由于我在项目中很少遇到这种情况,所以把这种情况给遗漏了~
仗剑天涯 引用 删除 莫冲   /   2009-02-03 16:35:45
我觉得最严重的BUG是功能完全不符合需求。
 

评分:0

我来说两句

Open Toolbar