bug分级管理制度
致命级:造成系统崩溃,死机,并且不能通过其他方法功能杀手锏功能失效
导致客户利益巨大损失的失效
严重级:基本重要功能无法正常实现
操作安全方面存在的漏洞
系统缺少必要的负载限制导致大容量系统失效
一般级:查询数据时数据显示错误
告警信息不全面、不准确
次要功能失效
提示级:界面不友好,操作不方便
缺少必要的缺省信息
错误提示不直观
Sample Text
不错,这个正是我需要的
呵呵,你的帖子我顶了,有空加我QQ151903076 BUG分级管理的确是测试过程是否规范的衡量标志之一,不过除了分严重性,还应该对其优先级进行量化,这样才更利于管理与跟踪。 我们公司把它分成A,B,C,D4类撒! 不一样,我们只分三种,严重、一般、轻微。不过状态有10多种。 补充下问题处理的优先级(priority)1. 立刻修改完成(fix immediately)
2.下一个阶段前必须修改完成 (fix before next stage)
3.产品推出前必须修改完成 (fix before release)
4.如果时间允许在进行修改 (fix if availabe)
5.下一个版本再进行修改 (fix in next version) 分级和状态对于bug很重要!看各个公司的实际情况! 确实看每个公司的实际情况.每报一个bug都要考虑它的严重级别和优先级别.另外我们公司对于不同项目的定义有区别.对于不同的测试阶段,级别的定义也有区别.但是总体思路差不多.大家呢? BUG分类除了要考虑严重程度还要考虑紧急程度。
我觉得LZ在严重程度方面分得很好,建议在紧急程度方面分为紧急、一般
所以在处理BUG时的顺序可以为:
致命(因为一般致命的均可归为紧急)、严重+紧急、一般+紧急、严重+一般、一般+紧急、一般+一般、提示+紧急、提示+一般。
欢迎探讨 我们公司分为:建议,一般,严重,非常严重 Business Logic
Urgent
High
Medium
Low 我想请问楼上各位一个问题:
假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理?? 原帖由 Leon 于 2006-4-21 14:11 发表
我想请问楼上各位一个问题:
假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理??
我曾经和别人讨论过如何处理无法重新的缺陷。你可以参考一下。
http://blog.csdn.net/pyp/archive/2005/03/24/328941.aspx 谢谢斑竹,我的意思是,出现频率也应该作为一个重要因素,在缺陷管理分级中予以考虑。
:) 原帖由 Leon 于 2006-4-21 14:56 发表
谢谢斑竹,我的意思是,出现频率也应该作为一个重要因素,在缺陷管理分级中予以考虑。
:)
这个我的处理方法是在使用的过程中,有一个“可重现性”字段专门进行处理,分类为:总能、经常、间隙、不能、不知道。 不同的缺陷管理工具有不同的定义,不同的公司也有不同的定义,主要还是大家要理解,和在使用它们的时候合理把握尺度. 原帖由 Leon 于 2006-4-21 14:11 发表
我想请问楼上各位一个问题:
假如发现了一个“严重级”的问题,但是重现频率低至1/100000,这样的缺陷你们怎么处理??
先想办法重现这个bug, 如果release前不能重现它,那就延期处理。 分四级 比较流行。 支持一下,我们是严重、一般、微弱 建议模仿TD的吧~~
页:
[1]