51Testing软件测试论坛

标题: 缺陷率&软件质量通过标准&测试通过标准 [打印本页]

作者: B2CPC 时间: 2005-7-18 22:52
标题: 缺陷率&软件质量通过标准&测试通过标准
通过一些用例,或测出了许多bug,或没有.从一定的角度上来说,没测出bug也不一定是坏事.因为可能说明代码中的缺陷率不高了(也许是质量较好的软件).或者也可以说测出了许多bug的是好事,因为这样不是发现了许多bug了吗??说明用例设计不错.
但是这篇代码中的bug到底有多少?缺陷率是多少?如上所说根据缺陷率的高低是很难取定,到底是高了,还是低了.大家都来说说看

另:软件通过标准和测试通过指标是不一样的.这是个很容易犯的误区(偶也刚明了).简而言之,测试通过标准的评价对象是测试活动;软件通过标准的评价对象当然是软件质量了.因此在测试通过标准中请勿把软件质量的好坏考虑其中.而主要考虑用例的执行情况.

[ Last edited by B2CPC on 2005-7-30 at 21:38 ]

作者: archonwang 时间: 2005-7-19 22:16
有各种算法，如千行代码错误率；BUG/代码行计算等等。缺陷率越低越好，但是由于存在客户提供的缺陷，所以这部分内容必须计入在内。

作者: kpxl 时间: 2005-7-20 14:27
楼上的回答可能不能解决楼主的疑问。
不过如果真的想回答“这篇代码中的bug到底有多少?缺陷率是多少?”这样的问题，我想是没有办法的，因为如果能回答出来就知道有多少Bug了，那样就知道还有多少Bug没有发现。
其实目前说的Bug率仅指目前发现的Bug的一个指标，有经验的人不是根据Bug率来判断一个软件的好还是坏，而是根据Bug的曲线，正常情况（没有刻意的去做假），Bug曲线能够很大程度上反映产品的成熟度。

作者: B2CPC 时间: 2005-7-20 20:14
恩,被KPXL斑竹一语点破，多谢指点。也感谢archonwang斑竹的指教。
顺便问一下，千行代码错误率应该指的是遗留在代码中还未发现的BUG吧？？？既然是没有发现的BUG，谈何千行代码错误率呢？大虾们继续说说

作者: kpxl 时间: 2005-7-21 08:23
千行代码Bug率还有其他种种的Bug指标，一般都是指一个软件被测试结束后，测试人员认为质量比较稳定，可以Release了，这时提交的一个指标，指从开始测试到测试结束后，一共发现的Bug数（去掉因为测试人员的误解，错报的Bug），除以总的代码行数（这个也是有争议，因为如果对于一个新系统，这个指标没有疑问，如果对于一个在老系统上的修改，那到底是用所有的代码行数来算还是只算本次修改？），这个指标在一定程度上能反映系统的稳定程度和开发人员的水平。

作者: B2CPC 时间: 2005-7-21 11:37
恩,这回彻底明了,非常感谢

作者: archonwang 时间: 2005-7-24 11:18
标题: 如有错漏，不吝指正。
to kpxl：
多谢执教！
实际上，对于千行代码错误率也是一个比较混沌的概念。就如同您的看法一样，从统计的角度来看，新系统是可适用，但是老系统的统计就有很大的浮动空间，通常也是不准确的，只有获取相应的趋势曲线才能推断出当前系统质量的整体状态。

[ Last edited by archonwang on 2005-7-24 at 11:23 ]

作者: Nio 时间: 2005-7-25 10:02
通过“千行代码错误率”来评价系统的质量？
任何评价都有其依据，这一评价的依据是什么呢？
错误率高意味着质量好还是错误率低意味着质量好呢？
代码受主观的人为因素影响很大，在没有对开发过程、测试过程等相关生产过程进行质量控制时，这一参数没有任何意义。既使对生产过程进行了质控，这一参数所能说明的实际问题也非常有限。找错误往往由测试人员承担，提到人，就不难想到人的主观性，以及不一致性。不同模块的开发和测试，往往由不同的人完成，这就有了不同的错误率。而实际的开发与测试远比我所讲的要复杂的多，其不定的因素就更多！想依靠这一参数说明质量的问题，实际操作上存在很多不定因素。就目前大部分软件公司的状况来看，考察这一参数，没有什么实际意义，这也就失去了现在研究讨论的价值。

作者: bjtest2005 时间: 2005-7-25 11:17
我们公司把“千行代码错误率”作为衡量开发人员工作绩效的一个参考指标

作者: archonwang 时间: 2005-7-25 21:16
目前准备实施这类考核。这类考核在国外的一些软件企业中实行，具备有一定的现实意义。Nio所说的关于主观性在这类考核中应该影响不大，问题关键在于标准（开发规范等）的定义与相关规范（比如设计文档、规范文档等）的制定与遵守。另外，我不认为测试人员只是在找错误，这样的测试对整体质量改善本身没有太大的好处，可能最理想的情况是：将该死的错误在开发一开始就“扼杀”在摇篮里！－－扯远了。

作者: wzb521 时间: 2005-7-26 09:52
我认为：人的因素是最大的，人的素质、态度、责任感，都大大影响着软件质量。软件质量也不是一个环节所能控制的。测试人员确实不是在找错误，而应该是确认、验证，附加价值应该是找到了很多缺陷。

前阶段跟我公司开发人员聊天时：

他说了几句话：

一、他的职责：1、完成编码2、输入正确数据、用户录入正确、操作正确时基本功能没问题（也就是所谓的在调试时，录入了正确数据出来正确的结果）。
二、如果他都做对了，要测试人员做什么？
三、你们测试出来的，在我这里不能发现或者不能重复出现的就不改，反之则改。
四、软件质量问题，那是测试部和工程部的事情，我只负责开发。

面对这样的回答，我深感悲哀，更加无可奈何。。。

庆幸的是他8月份就离开公司了，这是我难得在一个人走后还觉得比较快乐的时候。

作者: Nio 时间: 2005-7-26 09:56
其实问题正如archonwang所说“问题关键在于标准（开发规范等）的定义与相关规范（比如设计文档、规范文档等）的制定与遵守”，如果这些问题能够在实际操作中行的通，就不必去想什么理想情况了。问题是实际情况如何，任何想法如果脱离了实际，将变成空谈。在开发与测试没有形成规模，没有达到书本上所说的标准前，我们更应该从现实出发。

作者: takiro 时间: 2005-7-26 13:05
对于wzb521的那段话，真是感同身受啊！

作者: B2CPC 时间: 2005-7-29 12:06
每个公司应该都有自己的对软件质量的评估标准,达到了此类标准合格的软件才能发布上市,缺陷率应该是重要的一个.不过也不仅仅是它一个.即使bug/kloc很低(可能模块比较简单或是code严谨的牛人,出现的bug当然会很少).考虑测试设计\执行的充分性,用例密度以及覆盖率等方面工作都到位的话,测试完全可以说是通过了!!但软件质量还需开发人员对测出的Bug确认和修改后,质量才能真正得到保证.
因此深刻体会到狭义的讲:测试就是发现错误.我把测试人员比作军队中的侦察兵!!!打胜仗(好的软件质量)还是靠战斗部队(开发人员) 去争取的.企业要做大,做成航母级的,就更要自己有的各种不同类型的部队配合.往往这样的特别部队(如侦察部队)装备是最好的. 美国军队配置是明证.Microsoft中测试和开发的待遇和比例也是明证.
除非中国的企业都不愿不想做航母,甘心做一个小帆板.不然我们这些侦察兵还是大有用武之地的.

[ Last edited by B2CPC on 2005-7-30 at 22:03 ]

作者: wzb521 时间: 2005-7-29 13:11
我不介意测试出很多问题，我只介意他不承认错误。

作者: 多姿多彩 时间: 2005-7-29 13:20
.......................................................

作者: archonwang 时间: 2005-7-30 16:14
标题: 以下个人观点，若有错漏，不吝指正！
一、他的职责：1、完成编码2、输入正确数据、用户录入正确、操作正确时基本功能没问题（也就是所谓的在调试时，录入了正确数据出来正确的结果）。
开发人员的职责是什么？完成了编码就可以“三不管”了么？
仅仅满足了输入正确数据、用户录入正确、操作正确时基本功能没问题的软件就属于合格产品了么？这位开发人员是如何理解质量的？出不出Bug只是一种状态，但是问题在于他忽视了除了功能之外的一切。这显然是错误的，毫不夸张地说，按照这个标准开发出来的软件充其量只能称之为系统原型，而不可能是产品。

二、如果他都做对了，要测试人员做什么？
晕～～优秀的开发人员见过很多，狂妄的开发人员也见得不少，但是没有见过敢自称自己所开发软件不存在缺陷的。按照以往的经验，即使在测试用例预期错误完备的情况下，开发人员也很难开发出不存在缺陷的软件－－更何况预期错误不可能100%进行覆盖。从他这句话的回答上，个人认为他对于软件开发整体过程的理解偏重于开发（可能他是一名项目的开发人员），实际上整个代码编写过程只占了软件工程的30％~45％，其余的时间被安置在需求挖掘、测试等过程。

三、你们测试出来的，在我这里不能发现或者不能重复出现的就不改，反之则改。
显然，软件项目过程中应该不存在配置管理内容或是配置管理处于较小的份额；其对配置管理部分的工作基本属于无视。如果按照该想法，如果说出现了问题，那么就是测试者的机器不符合其基本配置环境，再讲极端一点，就是说如果客户出现了同样的问题，则该问题最好的解决方案就是把开发人员的机器重新Ghost一个过去－－难以想像？！

四、软件质量问题，那是测试部和工程部的事情，我只负责开发。
绝对错误的观念，软件质量问题的根源就是设计和开发；设计缺陷可能开发人员无法控制，但是开发中存在的缺陷却是开发可以控制的内容！该开发人员对于软件质量本身的理解实在令人遗憾。

作者: B2CPC 时间: 2005-8-1 22:44
千行代码缺陷率作为唯一的标准当然挺牵强.不过作为一个参考点确实是不错的.把它作为纵轴,再将其他的参数(大家可以想想有哪些作为横轴参数)作横轴,是一种非常好的Bug曲线,对衡量软件质量及判断测试是否通过非常有帮助.当然,大量的度量数据还是要靠一个个项目经验的积累啊.希望不久的将来可以真正用这些理论来帮助实践,而不是只是空谈而已.

作者: muyitudou 时间: 2010-6-25 16:26
有一个缺陷率计算公式ddp，我今天笔试的时候见到的

作者: mymarvell 时间: 2010-6-29 22:25
标题: 回复 1# 的帖子
比较成熟的公司都会有一个专门的bug tracking list.
通过图表的方式去记录各个阶段的Bug数量状态潜在风险等等，对软件质量进行监控

作者: 千里 时间: 2010-7-3 13:16
17#很强大

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