大家都如何做测试缺陷分析工作的?
大家都如何做测试缺陷分析工作的?有经验的朋友介绍一下经验了,谢谢啦!!给你看张截图,应该对你有所帮助! 还有人有好的建议吗? 缺陷管理的目的是控制软件bug的增长,在不同版本控制在1个稳定的数值内,当达到1个稳定的bug增长和修复率是缺陷管理的成功标准。可以借助缺陷管理工具中的甘比图。这个是比较简单办法。
1.风险控制
风险控制首先需要做到记录下高发的bug功能点,对上个版本未修复的bug进行记录。
风险对比管理:定1个标杆,比如 v1.1版本的内容就拿v1.0版本做参照物。bug增长,当同类型bug反复出现就需要引起关注。 :P :) 不知道楼主想知道测试中的缺陷分析还是测试结束后的缺陷分析,在我公司有一个“过BUG”的过程,就是测试员和开发聚在一起对提交的BUG进行沟通和交流,尽量让两方解决达成一致。 :victory: :call: 回复 9# ruirui。
电话的效果不如当面沟通的好 2#截图说的就已经非常全面了,至少我是这么认为的. 本帖最后由 chenxubest 于 2011-7-29 21:27 编辑
我对二楼不满意,没一点专点水准,空谈 看看这里,这才是叫度量
(原创)(三)作为测试负责人测试过程监控中关注的度量数据
http://blog.sina.com.cn/s/blog_6fbdee570100p71k.html
共分为三个系列
导读我们将从,测试人员,开发人员,项目及过程管理,三个角度来分析
另外再付两个分析
BUG龄期的分析探讨
http://blog.sina.com.cn/s/blog_6fbdee570100rrhv.html
(原创)测试趋势6曲线解读
http://blog.sina.com.cn/s/blog_6fbdee570100rkgq.html 回复 7# 千里
赞一个。。。以前我们也是一样的 回复 13# joykao
这种办法的好处就是让一些存在分歧的BUG早一点得到沟通和解决 回复 14# 千里
agree withyou 华为也是采用这样的方式 我赞同二楼crazy715 和七楼千里的观点,在我自己实际的测试工作中,每一份测试报告中都要求系统未关闭BUG的缺陷状态和缺陷严重性的数量统计,例如:系统未关闭BUG总计:103个,其中New:27个,Open:10个,Fixed:13个,FixLater:10个,Reopen:25个,Question:18个;其中Urgent:19个,High:46个,Medium:21个,Low:17个。
一般情况下,测试组会组织一次BUG讨论会议,专门针对Question和Reopen的问题进行讨论,最终确定这些BUG的处理方式。 Test Leader 、team member、开发某个模块的负责人 在一起,每天下午开个会,大家对提的每一个defect进行分析,看这个defect是由于什么原因造成的,或者这个defect 是不是真的defect。对于High 和Critical 的defect 需要开发人员马上解决 那这个是针对新项目的还是运维类项目? 正在做这方面,公司的bug填写的不规范,统计起来比较头疼。
页:
[1]