1,268
社区成员
发帖
与我相关
我的任务
分享
...全文
请发表友善的回复…
发表回复
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，出过几次问题，多半是因为用户操作不当，每天做个备份（自动）就行了。
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）。
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
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的流出原因包括混入原因（直接原因）和管理的原因，找到这样的原因后，将这样的原因整理管理，作为以后开发的借鉴或者说对以后开发的管理以及开发（测试）人员的注意事项或者流程进行改进，以达到以后的更高质量的开发
主要不是找责任，主要是找出开发管理上的漏洞
以便以后改正
检讨的目的是找出bug的流出原因包括混入原因（直接原因）和管理的原因，找到这样的原因后，将这样的原因整理管理，作为以后开发的借鉴或者说对以后开发的管理以及开发（测试）人员的注意事项或者流程进行改进，以达到以后的更高质量的开发
主要不是找责任，主要是找出开发管理上的漏洞
以便以后改正
牛牛爸 2004-11-23
- 打赏
- 举报
Bug管理系统，你说的是不是缺陷管理系统，DTS。有必要，绝对有必要。
1：统计
2：追踪
1：统计
2：追踪
aawolf 2004-11-23
- 打赏
- 举报
BUG管理的必要性是勿庸置疑的，有百利而无一害，根本就不需要衡量利害。我在这里就不废话了。
我想起了以前一位项目经理曾说过的关于BUG的一个理论：根据BUG数可以确定产品的成熟度，如果BUG的数量没有到一个水平（标准是按上一个产品的实际BUG数来衡量的），那不能说明产品的BUG少，而是Test Team还没有暴露足够多的问题。
我想这也是另外一个意义吧。
我想起了以前一位项目经理曾说过的关于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出现之后首要的问题是是解决问题，而不是追究谁的责任，虽然这可能影响团体或者个人的奖金等物质东西
同意。。
有些BUG在release之后出现，也不一定是代码的问题，也许和设计，或者技术上的限制有原因
再说，bug出现之后首要的问题是是解决问题，而不是追究谁的责任，虽然这可能影响团体或者个人的奖金等物质东西
同意。。
microyzy 2004-11-09
- 打赏
- 举报
如果版本定型之后bug过多，那一定是开发人员和QA和测试人员有重大责任问题。
我觉得那是测试的问题，如果测试覆盖面不够，那可能是文档的问题（这个不同的公司实际上可能是不同的人来保证覆盖面的）
wuhill(穿山甲)写的很好，学习。
不过
“如果这之后还有bug出现这个团队就要检讨了，QA也要做检讨的。”
有些BUG在release之后出现，也不一定是代码的问题，也许和设计，或者技术上的限制有原因
再说，bug出现之后首要的问题是是解决问题，而不是追究谁的责任，虽然这可能影响团体或者个人的奖金等物质东西
我觉得那是测试的问题，如果测试覆盖面不够，那可能是文档的问题（这个不同的公司实际上可能是不同的人来保证覆盖面的）
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和测试人员有重大责任问题。
一般来说，经过了单元测试和集成测试之后，流出的bug就会很少，但是产生的影响又是特别大。所以需要对这个团队检讨，检讨的目的是找出bug的流出原因包括混入原因（直接原因）和管理的原因，找到这样的原因后，将这样的原因整理管理，作为以后开发的借鉴或者说对以后开发的管理以及开发（测试）人员的注意事项或者流程进行改进，以达到以后的更高质量的开发。
减少bug流出的办法，不是增加工作量，而是良好的管理，和正确的质量控制，有以下几个方面，
1，测试项目的覆盖，对测试项目的确认的覆盖
测试人员要做到对测试项目完全了解，对测试的确认工作要做到有两人以上同时确认。
2，QA对整个从开发到测试知道版本定型的全程跟踪和质量控制
bug的收缩率是指以下两个方面（这个一般QA做的）
1，本阶段实际测出的bug与预期值得比较，（差分）
以及对时间的分布如开始是10bug/周，最后0-1bug/周
2，bug的出现曲线和bug的解决曲线是不是最后平滑的相交
还有，对于每个阶段如果QA通过数据判定不能进行到下一阶段，那只能增加测试项目，直到QA判定通过为止。
如果版本定型之后bug过多，那一定是开发人员和QA和测试人员有重大责任问题。
加载更多回复（15）
