51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 7107|回复: 19
打印 上一主题 下一主题

[原创] bug分级管理制度

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2005-5-11 17:37:27 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
致命级:造成系统崩溃,死机,并且不能通过其他方法功能
    杀手锏功能失效
    导致客户利益巨大损失的失效
严重级:基本重要功能无法正常实现
    操作安全方面存在的漏洞
    系统缺少必要的负载限制导致大容量系统失效
一般级:查询数据时数据显示错误
    告警信息不全面、不准确
    次要功能失效
提示级:界面不友好,操作不方便
    缺少必要的缺省信息
    错误提示不直观
   
[font=黑体]Sample Text[/font]
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2005-12-7 21:47:12 | 只看该作者

不错,这个正是我需要的

呵呵,你的帖子我顶了,有空加我QQ151903076
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2005-12-8 09:31:18 | 只看该作者
BUG分级管理的确是测试过程是否规范的衡量标志之一,不过除了分严重性,还应该对其优先级进行量化,这样才更利于管理与跟踪。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2005-12-8 14:59:31 | 只看该作者
我们公司把它分成A,B,C,D4类撒!
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2005-12-20 13:19:36 | 只看该作者
不一样,我们只分三种,严重、一般、轻微。不过状态有10多种。
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-2-6 14:07:10 | 只看该作者
补充下问题处理的优先级(priority)
1. 立刻修改完成  (fix immediately)
2.下一个阶段前必须修改完成 (fix before next stage)
3.产品推出前必须修改完成 (fix before release)
4.如果时间允许在进行修改 (fix if availabe)
5.下一个版本再进行修改 (fix in next version)
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-3-16 15:36:25 | 只看该作者
分级和状态对于bug很重要!看各个公司的实际情况!
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-3-18 23:08:18 | 只看该作者
确实看每个公司的实际情况.每报一个bug都要考虑它的严重级别和优先级别.另外我们公司对于不同项目的定义有区别.对于不同的测试阶段,级别的定义也有区别.但是总体思路差不多.大家呢?
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2015-3-4 14:15
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2006-3-29 00:00:59 | 只看该作者
    BUG分类除了要考虑严重程度还要考虑紧急程度。
    我觉得LZ在严重程度方面分得很好,建议在紧急程度方面分为紧急、一般
    所以在处理BUG时的顺序可以为:
    致命(因为一般致命的均可归为紧急)、严重+紧急、一般+紧急、严重+一般、一般+紧急、一般+一般、提示+紧急、提示+一般。
    欢迎探讨
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2006-4-15 14:23:06 | 只看该作者
    我们公司分为:建议,一般,严重,非常严重
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2016-6-12 12:47
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    11#
    发表于 2006-4-15 22:12:21 | 只看该作者
    Business Logic
    Urgent
    High
    Medium
    Low
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2006-4-21 14:11:36 | 只看该作者
    我想请问楼上各位一个问题:
    假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理??
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 11:43
  • 签到天数: 3650 天

    连续签到: 102 天

    [LV.Master]测试大本营

    13#
    发表于 2006-4-21 14:24:33 | 只看该作者
    原帖由 Leon 于 2006-4-21 14:11 发表
    我想请问楼上各位一个问题:
    假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理??


    我曾经和别人讨论过如何处理无法重新的缺陷。你可以参考一下。
    http://blog.csdn.net/pyp/archive/2005/03/24/328941.aspx
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2006-4-21 14:56:52 | 只看该作者
    谢谢斑竹,我的意思是,出现频率也应该作为一个重要因素,在缺陷管理分级中予以考虑。
    :)
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 11:43
  • 签到天数: 3650 天

    连续签到: 102 天

    [LV.Master]测试大本营

    15#
    发表于 2006-4-21 15:21:09 | 只看该作者
    原帖由 Leon 于 2006-4-21 14:56 发表
    谢谢斑竹,我的意思是,出现频率也应该作为一个重要因素,在缺陷管理分级中予以考虑。
    :)

    这个我的处理方法是在使用的过程中,有一个“可重现性”字段专门进行处理,分类为:总能、经常、间隙、不能、不知道。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2006-4-22 01:35:22 | 只看该作者
    不同的缺陷管理工具有不同的定义,不同的公司也有不同的定义,主要还是大家要理解,和在使用它们的时候合理把握尺度.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2006-4-24 13:42:33 | 只看该作者
    原帖由 Leon 于 2006-4-21 14:11 发表
    我想请问楼上各位一个问题:
    假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理??


    先想办法重现这个bug, 如果release前不能重现它,那就延期处理。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    18#
    发表于 2007-10-23 00:15:03 | 只看该作者
    分四级 比较流行。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    19#
    发表于 2007-10-23 00:34:14 | 只看该作者
    支持一下,我们是严重、一般、微弱
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    20#
    发表于 2007-10-23 13:41:08 | 只看该作者
    建议模仿TD的吧~~
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-24 05:30 , Processed in 0.080461 second(s), 26 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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