大家来讨论一下bug管理的必要性吧!!百分送上

seven 2004-11-02 10:47:10
准备在项目内使用bug管理工具,可组内有人都怕会带上额外的工作量,该如何说服大家呢?
谢谢
...全文
1079 点赞 收藏 35
写回复
35 条回复
切换为时间正序
当前发帖距今超过3年,不再开放新的回复
发表回复
seven 2004-12-03
新的问题:我们公司测试部现在在用的 clear quest..测试部测完后要求我们自己上去看,可也不能每一个小时上去看一次吧。。如果让测试部总是电话通知好象也不太好。谁知道有什么好的即时通知方法?
回复
futuredreams 2004-12-02
Clear Quest now.
回复
woody420 2004-12-01
BUG管理很必要,大家都用些什么工具啊.
回复
michelle1982 2004-12-01
我这儿用Test Director,比较容易上手,很简单,
bugzilla是在linux下的。
CQ,rational的东西个人总是觉得比较其他同类产品复杂。
我现在也维护我们这的TD,出过几次问题,多半是因为用户操作不当,每天做个备份(自动)就行了。
回复
futuredreams 2004-11-29
这个...没有bug管理,如何处理优先解决的问题跟严重程度?本人根据实践总结了一些经验,跟大家交流下:
1. Bug分类:
致命:系统崩溃或挂起等导致系统不能继续运行;
严重:使系统不稳定、或破坏数据、或产生错误结果,而且是常规操作中经常发生或非常规操作中不可避免的主要问题;
一般:系统性能或响应时间变慢、产生错误的中间结果但不影响最终结果等影响有限的问题,如:显示不正确但输出正确;
轻微:界面拼写错误或用户使用不方便等小问题或需要完善的问题;

A类:严重错误,包括以下各种错误
1.由于程序所引起的死机,非法退出
2.死循环
3.数据库发生死锁
4.数据库设计未达到第三范式的要求或需求规格说明的格式水平
5.功能错误
6.与数据库连接错误
7.数据通讯错误
B类:较严重错误,包括以下各种错误
1.程序错误
2.因错误操作迫使程序中断
3.程序接口错误
4.数据库的表、业务规则、缺省值未加完整性等约束条件
C类:一般性错误,包括以下各种错误
1.操作界面错误(包括数据窗口内列名定义、含义是否一致)
2.打印内容、格式错误
3.简单的输入限制未放在前台进行控制
4.删除操作未给出提示
5.数据库表中有过多的空字段
D类:较小错误,包括以下各种错误
1.界面不规范
2.辅助说明描述不清楚
3.输入输出不规范
4.长操作未给用户提示
5.提示窗口文字未采用行业术语
6.可输入区域和只读区域没有明显的区分标志
2. Bug分优先级:
1级:尽快修正;
2级:每个里程碑结束前必须修正;
3级:如果时间允许就修正;
3. Bug状态:
激活:测试人员发现bug,并记录在测试报告中,等待开发人员修改;
等待:bug正在被程序员修改并提交,等待测试人员进行测试;
关闭:bug通过测试,被处理完毕(或其他原因无须处理此bug)。
回复
Rose2000 2004-11-29
恩,最近公司培训过 Test Director 和Vantive,因为没有实际用过,所以只能提这两个名词给大家,仅供参考。
回复
Jarod 2004-11-28
目前交流行的BUG Tracking System有TestTrack、ClearQuest、Bugzilla……


请问大家用的是那个?
回复
flying_duck 2004-11-26
同志们来买我的问题跟踪系统吧,现在已经很成熟了,每个用户25块钱,绝对便宜,免费试用60天的。呵呵。不光可以管理BUG,还可以管理其他任意类型的问题,可自定义字段和流程的。
http://www.lealsoft.com/urtracker
回复
1man 2004-11-25
bug管理是必须的,工具就看你自己了,专门的bug管理也行,excel也能用,口述或者用笔写都是能接受的
回复
vc_hking 2004-11-23
clearquest也可以呀!
回复
wuhill 2004-11-23
回复人: microyzy(毛毛叉) seven(波波)

检讨的目的是找出bug的流出原因包括混入原因(直接原因)和管理的原因,找到这样的原因后,将这样的原因整理管理,作为以后开发的借鉴或者说对以后开发的管理以及开发(测试)人员的注意事项或者流程进行改进,以达到以后的更高质量的开发

主要不是找责任,主要是找出开发管理上的漏洞
以便以后改正
回复
牛牛爸 2004-11-23
Bug管理系统,你说的是不是缺陷管理系统,DTS。有必要,绝对有必要。
1:统计
2:追踪
回复
aawolf 2004-11-23
BUG管理的必要性是勿庸置疑的,有百利而无一害,根本就不需要衡量利害。我在这里就不废话了。

我想起了以前一位项目经理曾说过的关于BUG的一个理论:根据BUG数可以确定产品的成熟度,如果BUG的数量没有到一个水平(标准是按上一个产品的实际BUG数来衡量的),那不能说明产品的BUG少,而是Test Team还没有暴露足够多的问题。

我想这也是另外一个意义吧。
回复
seven 2004-11-22
不有一些开源的东西吗?bugziller.
回复
greenery 2004-11-22
正在自己写一个简单的BUG管理。。。
回复
greenery 2004-11-09
有好的BUG管理工具推荐一下吗?
各位说的真好。
回复
seven 2004-11-09
回复人: microyzy(毛毛叉)
有些BUG在release之后出现,也不一定是代码的问题,也许和设计,或者技术上的限制有原因
再说,bug出现之后首要的问题是是解决问题,而不是追究谁的责任,虽然这可能影响团体或者个人的奖金等物质东西

同意。。
回复
microyzy 2004-11-09
如果版本定型之后bug过多,那一定是开发人员和QA和测试人员有重大责任问题。
我觉得那是测试的问题,如果测试覆盖面不够,那可能是文档的问题(这个不同的公司实际上可能是不同的人来保证覆盖面的)

wuhill(穿山甲)写的很好,学习。
不过
“如果这之后还有bug出现这个团队就要检讨了,QA也要做检讨的。”
有些BUG在release之后出现,也不一定是代码的问题,也许和设计,或者技术上的限制有原因
再说,bug出现之后首要的问题是是解决问题,而不是追究谁的责任,虽然这可能影响团体或者个人的奖金等物质东西
回复
yuex201 2004-11-06
回: wuhill(穿山甲)
谢谢,你讲的很细,很好。
多多向你学习。
回复
wuhill 2004-11-06
回:yuex201(望月)
一般来说,经过了单元测试和集成测试之后,流出的bug就会很少,但是产生的影响又是特别大。所以需要对这个团队检讨,检讨的目的是找出bug的流出原因包括混入原因(直接原因)和管理的原因,找到这样的原因后,将这样的原因整理管理,作为以后开发的借鉴或者说对以后开发的管理以及开发(测试)人员的注意事项或者流程进行改进,以达到以后的更高质量的开发。

减少bug流出的办法,不是增加工作量,而是良好的管理,和正确的质量控制,有以下几个方面,
1,测试项目的覆盖,对测试项目的确认的覆盖
测试人员要做到对测试项目完全了解,对测试的确认工作要做到有两人以上同时确认。
2,QA对整个从开发到测试知道版本定型的全程跟踪和质量控制

bug的收缩率是指以下两个方面(这个一般QA做的)
1,本阶段实际测出的bug与预期值得比较,(差分)
以及对时间的分布如开始是10bug/周,最后0-1bug/周
2,bug的出现曲线和bug的解决曲线是不是最后平滑的相交

还有,对于每个阶段如果QA通过数据判定不能进行到下一阶段,那只能增加测试项目,直到QA判定通过为止。

如果版本定型之后bug过多,那一定是开发人员和QA和测试人员有重大责任问题。
回复
发动态
发帖子
研发管理
创建于2007-08-27

1181

社区成员

软件工程/管理 管理版
申请成为版主
社区公告
暂无公告