51Testing软件测试论坛

标题: 请问Bug曲线是怎么会事？ [打印本页]

作者: ytmallen 时间: 2005-7-21 13:59
标题: 请问Bug曲线是怎么会事？
Bug曲线具体是如何定义的？

是怎么制作出来的？

意义是什么？

它能反映出那些问题？（也就是该怎么观察Bug曲线？以发现其中蕴涵的信息）

作者: kai_top 时间: 2005-7-21 16:07
偶是这样认为的：
从测试开始，bug被不断发现，那么这些bug与测试的日期等都有对应的关系，可以通过bug管理工具进行绘图，绘好就很容易看出bug随测试时间的变化趋势，不同的绘图方式，还能体现出什么类型的、什么级别，那个功能，谁负责的部份，由于什么原因等bug的趋势情况，这样就可以有针对性的加强那个部分，比如：bug图随着项目的逐步稳定，显示开发员A模块中的bug不断增加，没有任何递减的趋势，而其它相关开发员的模块bug不断下降，这时就要研究一下A开发员的工作了，是什么原因造成的，还是个人编码习惯等问题喽。。又比如：通过整体bug走势，可以一定程度上预测产品会达标的大概日期，因为bug曲线终归要近似趋零或达到可允许的范围（严重级别与个数）
－在TD中可以绘制bug图附件中(有两幅刚截的参考图)
－在testtrack中也可以.（我只发现表格形式的)

作者: wzb521 时间: 2005-7-22 08:50
严格来说，一个项目过程中的BUG走向应该是符合一定规律的，但由于我们外部条件和内部条件的因素，导致我们的曲线与书上所介绍的曲线有很大差异。

作者: Nio 时间: 2005-7-22 09:30
大家应该更加注重的是这个曲线有何实际意义，对于测试、开发、以及成本等有何影响，就目前的测试的环境来看，研究这个曲线意义不大。测试人员可能还管不了那许多，还有即使有权力干涉开发人员的工作，但这也不能说明什么问题，反而招来非议，程序的编写主观性与客观性都存在，从这个曲线中不能反应任何关于开发人员的问题。对开发人员的评价自有另外的方法。而这个曲线的不正常，也可能与测试人员有关，很难保证所有测试人员一直都能保持一个正常的发挥其测试能力。

一句话：这个曲线中看不中用！最多只能直观的说明某阶段发现了多少BUG。其它什么都说明不了。

作者: ytmallen 时间: 2005-7-22 12:52
看来大家对这个bug曲线的概念还是有点争议，在其实用意义和和方法以及其使

用价值上的分歧更是比较大，这对我这个新手来说就如当头一棒。

请问有没有比较权威一点的说法？

作者: B2CPC 时间: 2005-7-23 00:59
我是这么看的,
BUG曲线纵轴是Bug数,而横轴根据你自己的定义,可以产生好多种类的曲线图,你可以将横轴定义为时间,或定义为人力资源,或定义为用例数等等,根据横轴定义的不同可以产生好多Bug曲线图.就看你怎么定义,怎么发明了.当然,你的定义肯定对你以后的度量工作产生积极的意义,那你的"发明"也真正有意义和作用

作者: wzb521 时间: 2005-7-23 12:53
如果你们的测试部门绝对独立，过程绝对严格，那这个曲线很能反映情况，否则。。。

作者: 小子不信邪 时间: 2005-7-24 09:23
建议你学一下《软件工程》，就知道是什么东西了。

作者: kpxl 时间: 2005-7-25 12:22
Bug 的曲线有很多种，就拿ClearQuest中来说，你可以根据自己的需要进行定制
一般我用的比较多的有下面几种：
新Bug的产生曲线：主要看每天新增bug的情况，理想情况应该是开始的时候不是很多，然后很快达到高峰，急剧减少，但是中间会有小的波动，这样的曲线是比较理想的
系统中总的Bug曲线：这个是去掉解决完的bug的图，理想的情况和尚一个差不多，只是减少的会慢一点，波动也会大一些
Bug的修复趋势：这个土我一般拿系统中的新增Bug，当天Close的bug放在一起看

当然还有其它很多的图，我们会根据需要进行设定。

作者: archonwang 时间: 2005-7-25 21:08
to kpxl:
不知道您那里一天的BUG产量几何？数据量小的话可能并不是很准确的。我这里一般都是每周处理一次。在BUG修复方面，发现修复比率应该维持在怎样的一个水平上比较理想？具体的考核方面应该怎样计算？谢谢，不吝赐教。

作者: kpxl 时间: 2005-7-26 09:16
其实我的意思就是大家不要拘泥于别人的形式，要根据自己的情况来做。
我们这里每天一个项目大概每个人能报到7-10个bug,算是挺多了。
CQ的功能很强大，可以定制各种反应软件不同指标的表格或者曲线。至于说到如何考核的问题，也是不能依葫芦画瓢。不同的公司，不同的系统架构，不同的企业文化，对考核的指标都会有不同的看法。
Bug的修复率本身这个指标在不同的时期，我想期望值应该不同。而且这些指标并不能反映项目的好坏，就像我们公司现在实行SQA一样，稽核没有抓住实质的东西，没有细致的曲分析，相当于是为了稽核而稽核，就失去了意义了。每次老总问他们，这个项目的异常点这么多，是不是这个项目就是做的不好？他们总是回答不出。
我建议你可以拿以前做的一个较好的项目，统计一下它的各项指标，然后可以把这些作为一个参考值，在后面的项目中发现这个指标不合理就及时调整。

尽信书则不如无书，很多软件测试的专业资料上的指标是一种很理想的指标，或者是很成熟的公司，体制下的指标，我们如果生搬硬套，会很痛苦。

作者: wxq8102 时间: 2006-8-1 17:28
在CMM4中,我们知道过程能力可概括为可预测的,那么怎么预测呢?实际就是通过曲线拟合,即
Bug曲线,横坐标是累计测试人.时/kloc,纵坐标是累计defect/kloc.通过曲线拟合分析,可以收集度量数据,根据度量数据得到预测模型,根据预测模型预测未来项目.反映自身流程的能力.预测过程和产品质量,保证软件产品具有可预测的高质量.

作者: terrylight 时间: 2006-8-9 21:39
bug曲线应该就是一种度量的手段，它可以让我们预测到bug数量的一个大概，有助于我们提高软件质量和测试效率

作者: walker_lai 时间: 2006-8-26 16:27
标题: up 下
up 下

作者: accp9898 时间: 2007-4-23 09:12
thank you!

作者: yuyanshe 时间: 2007-5-9 11:21
根据实际情况吧，在国内，测试还附属于开发的情况下。。。。

作者: zhanglijun33 时间: 2007-7-6 18:26
sdlkfj3

作者: zhanglijun33 时间: 2007-7-6 18:26
我是个新手,刚开始做测试

作者: roble 时间: 2007-7-24 19:59
ding

作者: swjtu2009 时间: 2007-7-24 21:48
偶也是生手的，刚接触软件测试的！

作者: 119139107 时间: 2007-7-25 09:40
新手
学习中。。。。。

作者: ccly918 时间: 2007-7-25 10:18
标题: 学习
即将踏入测试行业, 对于很多东西还需要不断的学习
今天又了解了BUG曲线的概念,sdlkfj3 谢谢各位前辈的教导

作者: zzytion 时间: 2007-7-27 16:24
其实BUG图是针对自己本TEMA得一个技术水准和实施效果得衡量,没什么特殊得标准得吧!!只是内部得一些分析数据!!

作者: tianming08 时间: 2007-7-30 12:45
学习中，印个脚印！！

作者: ivyhuan 时间: 2008-1-2 17:39
真的是好东西，踩一下

作者: pangda 时间: 2008-11-3 16:16
[font=宋体][size=2]个人感觉BUG曲线一个新的软件从发布测试版，测试人员开始测试bug逐步增加在达到第一个顶峰时逐步减少。随着测试人员深入了解软件BUG量会随着时间逐步增加达到第二个高峰。如此反复发现的BUG会逐步减少。根据这个量来做一个XY轴的图，显示出来的应该就是BUG曲线。[/size][/font]

作者: yllff 时间: 2008-11-4 09:47
还是新手，学习中

作者: guhang 时间: 2008-11-17 16:02
我也是新手，希望在这里获得测试的入门知识

作者: 326451028 时间: 2008-11-17 19:25
不清楚

作者: 118UU3 时间: 2008-11-19 16:56
路过····

作者: zhanghuaxiaomi 时间: 2008-12-20 09:20
标题: 谢谢
好好看新手，我也是！

作者: medoraemon 时间: 2008-12-25 16:23
关于bug曲线问题理解上应该不难，无非就是用bug曲线的递归来表明软件的成熟度，是否可发布的一个参考罢了。

作者: Whiz~~endless 时间: 2008-12-25 16:52
同意二楼的说法

作者: gaha 时间: 2009-11-8 12:25
根据版本迭代，Bug曲线会有变化，初期上升，随着第一阶段的修改，数量减少，然后通过回归之前的bug，会再次出现攀升，另外如果有功能调整，也会有上升趋势，到后期Bug种类级别有所缓解，新bug的发现很少，原bug被解决的质量很高，根据实际情况，就要考虑代码冻结了。

对产品或项目质量的分析，bug曲线占很大一部分理由。

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)