讨论一下大家都是怎么定义错误等级的

白菜叶子

讨论一下大家都是怎么定义错误等级的
我们公司分成
Blocker：引起系统崩溃的
Critical：数据无法连接，数据错误，内存溢出，
Major：功能错误，功能未实现
Normal：不影响正常的工作，如输入一些 异常值，边界值的问题
Minor：界面上的错误
Enhancement：建议

你们是怎么样的，我这样是否合理？

Nio

1、"引起系统崩溃的"和“数据无法连接，数据错误，内存溢出的” 可以归为一类，因为这类问题导制操作系统问题或者软件无法正常运行；

2、“功能错误，功能未实现”和“界面上的错误”从需求的角度讲归为一类, 未能实现需求；

3、"不影响正常的工作，如输入一些 异常值，边界值的问题" 以及界面逻辑问题，可以归为一类；

另“建议”一般不是针对Bug的，所以不必归为错误等级里。通常是通过其它途径来处里测试中所提的建议。

测试中过多的考虑问题的等级是没有太多的意义的，关键是找出问题并使之被修复；修改优先级通常是在修复BUG时要考虑的事，对于测试工作来说，关注的意义不大。

tjj006

Fatal, Serious, Problem, Minor, Enhancement, Issue
基本和你的差不多。

phoenixDT

关注ing

白菜叶子

没人知道还是没人说？

ppent

我们先把issue分为两类：缺陷和建议，再定义缺陷的优先级。
基本上缺陷的定义方面都是大同小异，差异不是很大，具体每个公司的情况不一样。
你上面的定义我觉得也没什么问题。如果你是测试部门的，定义完之后最好和开发部经理确认一下，达成共识后便于推行。

小不点-丫头骗子

我们提的bug的severity有五级，就没有LZ说的Normal级别，其实每个公司定义的bug级别都是差不多的

灵芝草

fatal
major
minor
cosmetic

hadywei

都是这样的阿，我们这里是1、2、3、4、5 级

hadywei

看到一个资料里面这样写到：
缺陷的状态
    1、 初始化：缺陷的初始状态；
    2、 待分配：缺陷等待分配给相关开发人员处理；
    3、 待修正：缺陷等待开发人员修正；
    4、 待验证：开发人员已完成修正，等待测试人员验证；
    5、 待评审：开发人员拒绝修改缺陷，需要评审委员会评审；
    6、 关闭：缺陷已被处理完成。

dionysus

楼上说的是bug状态了吧？
我们公司bug级别也挺简单，大概说一下吧
A类：程序崩溃，无响应或无故退出的
B类：某一功能不可使用且不能找到替代路径，功能错误，计算错误
C类：某一功能不可使用但可以找到替代路径
D类：错别字，界面等
E类：建议类

还有一个优先级别，当未修复的bug到一定数量的时候就开启优先级，指导开发人员修改，有时bug严重级低的优先级不一定低

sanjieyu

可以分为两个部分
Bug的 Priority 和 Severity

在 severity里面,按照 bug的严重程度,每个公司有自己的定义,比如以上各位所说的那些Critical, Serious,Suggestion之类的级别
而在 Priority里面,可以定义何时去修这个bug,是立即需要fix,还是在beta前fix,Release前fix,还是在下一个版本里面fix

表面上面看,Priority 和 Severity的关系是一一对应的,Severity 高,Priority就高
不过实际测试里面,并不是完全这样,还要根据目前所处于的 测试的 Phase来定义

比如在 测试前期,一个普通的UI 上面的bug,可能他的 Severity不高,但是Priority会非常高,这样push Dev最快可以fix这类bug
又比如,发现一个 Crash的 critical bug,但是很难重现,或者说在客户的环境下很难操作到,而且整个project的schedule很紧,那虽然他的 Severity会比较高,是critical,但是Priority一般会选择不高

白菜叶子

10楼说的这个方法挺好的：
还有一个优先级别，当未修复的bug到一定数量的时候就开启优先级，指导开发人员修改，有时bug严重级低的优先级不一定低  

现在我们一直在讨论说bug严重等级高的优先等级高，需要先修改；看来这种想法是错误的，修改的优先等级似乎不一定要根据bug的等级。

白菜叶子

把功能出错且引起其他功能无法使用的bug归类到Critical等级中好呢，还是normal中好呢