51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 8555|回复: 13
打印 上一主题 下一主题

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

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2007-2-1 17:51:27 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
0测试积点
讨论一下大家都是怎么定义错误等级的
我们公司分成
Blocker:引起系统崩溃的
Critical:数据无法连接,数据错误,内存溢出,
Major:功能错误,功能未实现
Normal:不影响正常的工作,如输入一些 异常值,边界值的问题
Minor:界面上的错误
Enhancement:建议

你们是怎么样的,我这样是否合理?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

2#
发表于 2007-2-1 17:51:28 | 只看该作者
1、"引起系统崩溃的"和“数据无法连接,数据错误,内存溢出的” 可以归为一类,因为这类问题导制操作系统问题或者软件无法正常运行;

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

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

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

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

使用道具 举报

该用户从未签到

3#
发表于 2007-2-1 18:30:58 | 只看该作者
Fatal, Serious, Problem, Minor, Enhancement, Issue
基本和你的差不多。
回复

使用道具 举报

该用户从未签到

4#
发表于 2007-2-2 12:23:16 | 只看该作者
关注ing
回复

使用道具 举报

该用户从未签到

5#
 楼主| 发表于 2007-2-3 15:48:21 | 只看该作者
没人知道还是没人说?
回复

使用道具 举报

该用户从未签到

6#
发表于 2007-2-5 11:40:19 | 只看该作者
我们先把issue分为两类:缺陷和建议,再定义缺陷的优先级。
基本上缺陷的定义方面都是大同小异,差异不是很大,具体每个公司的情况不一样。
你上面的定义我觉得也没什么问题。如果你是测试部门的,定义完之后最好和开发部经理确认一下,达成共识后便于推行。
回复

使用道具 举报

该用户从未签到

7#
发表于 2007-2-5 14:11:24 | 只看该作者
我们提的bug的severity有五级,就没有LZ说的Normal级别,其实每个公司定义的bug级别都是差不多的
回复

使用道具 举报

该用户从未签到

8#
发表于 2007-2-5 14:33:02 | 只看该作者
fatal
major
minor
cosmetic
回复

使用道具 举报

该用户从未签到

9#
发表于 2007-2-5 17:17:03 | 只看该作者
都是这样的阿,我们这里是1、2、3、4、5 级
回复

使用道具 举报

该用户从未签到

10#
发表于 2007-2-6 16:53:49 | 只看该作者
看到一个资料里面这样写到:
缺陷的状态
    1、 初始化:缺陷的初始状态;
    2、 待分配:缺陷等待分配给相关开发人员处理;
    3、 待修正:缺陷等待开发人员修正;
    4、 待验证:开发人员已完成修正,等待测试人员验证;
    5、 待评审:开发人员拒绝修改缺陷,需要评审委员会评审;
    6、 关闭:缺陷已被处理完成。
回复

使用道具 举报

该用户从未签到

11#
发表于 2007-2-6 22:32:07 | 只看该作者
楼上说的是bug状态了吧?
我们公司bug级别也挺简单,大概说一下吧
A类:程序崩溃,无响应或无故退出的
B类:某一功能不可使用且不能找到替代路径,功能错误,计算错误
C类:某一功能不可使用但可以找到替代路径
D类:错别字,界面等
E类:建议类

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

使用道具 举报

该用户从未签到

12#
发表于 2007-2-7 14:02:44 | 只看该作者
可以分为两个部分
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一般会选择不高
回复

使用道具 举报

该用户从未签到

13#
 楼主| 发表于 2007-2-8 10:33:53 | 只看该作者
10楼说的这个方法挺好的:
还有一个优先级别,当未修复的bug到一定数量的时候就开启优先级,指导开发人员修改,有时bug严重级低的优先级不一定低  

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

使用道具 举报

该用户从未签到

14#
 楼主| 发表于 2007-2-8 10:47:25 | 只看该作者
把功能出错且引起其他功能无法使用的bug归类到Critical等级中好呢,还是normal中好呢
回复

使用道具 举报

本版积分规则

关闭

站长推荐上一条 /1 下一条

小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

GMT+8, 2024-11-15 01:30 , Processed in 0.080587 second(s), 25 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

快速回复 返回顶部 返回列表