发现bug越多,产品的最终质量越好还是差?

加国无忧 51.CA 2011年7月24日 18:11 来源:新职学院 [ 加大字体缩小字体 ]
主题论点分析:本次辩论论题对bug的具体数量包括bug多会使这个产品的测试覆盖率到底是高还是低?。
  正方:发现bug越多,产品的最终质量越好
  论点1:项目提交测试时,bug数基本是一个固定的值,那么如果测试过程中发现的bug越多,遗漏的bug也就越少。那相应的质量越好。
  论点2:从心理角度上说,当提交测试or前期发现问题越多的情况后,测试人员从心理上会对该项目or日常要求的很严格,需求的挖掘也会更透彻,那么测试覆盖率会有所提高,则质量会相应的更好。
  论点3:从某种意义上说,发现的bug数越多,相应的测试覆盖率也会越高。
  论点4:测试的目的是发现bug,当两个不同的人同测一个项目时,若一个发现bug多,一人发现bug少,那么老大在看报告时,也会更加信任那个提的bug数多的人,更相信他的质量更好。
  论点5:用例只是项目重点关注的测试点,在项目过程中,但不同的人执行用例时,会产生不同的效果,并且在项目过程中也会根据经验来发现一些问题,所以这时发现bug越多,一定程度上说明测试经验多,那测试后的产品质量越好。
  论点6:根据逆反原理,假设一个bug都没有的项目,是否就说明该项目质量一定就很好呢?显然是不正确的,很大程度上说明这个测试团队的测试经验已经测试能力体现不到位。
  论点7:前期发现的问题也是bug,那么在前期发现的越多,也就越能把控项目的质量,所以发现的bug数越多,质量越好
==========================华丽丽的分割线2=========================
  反方:发现bug越多,产品的最终质量越差
  论点1:项目提交测试or用例结束时,测试的覆盖率也就是一定的了,于是发现的bug数越多,那说明在一定测试用例的情况下,其未发现的bug数量也越多,质量也就越差。
  论点2:开发人员能力参差不齐,当发现某模块bug数越多,修改的bug越多,则引入新的bug就会越多,(非官方统计:修改3bug,就会引入1bug)那么这些新的bug发现的难度要比修改前发现bug要大的多。那其隐藏未发现的bug数量就越多,那么相应的模块质量也就越差。
  论点3:对于那个心理平衡,测试人员发现很多bug后,心里觉得bug已经发现的差不多了,质量也就差不多了,其实自我心态好,不同等于质量的保证,只是一种心理平衡罢了。
  论点4:根据80/20原则可以得到,bug越多,说明80%bug是出现在那20%的模块中,那另外80%的模块未发现很多bug,这就说明一个产品的80%的模块有隐藏的bug数,当然没有质量保证,这时可说明整个产品的最终质量是很差的。
  论点5:论Bug分严重级别,P1级别的bug一般都比较少,但若p1级别很多,那能说明质量是好的么?显然是不对的,说明还有更多隐藏的P1bug,那对于一个产品中还有很多隐藏的P1bug,我们只能说明这个产品的最终质量是越差。
  论点6:需求挖掘一致的情况下,bug越多,关联耦合也就越差,这里有数据证明,某个项目的某几个模块在测试阶段发现了大量的bug,上线后发现的bug大部分也是来自于这几个模块。
  论点7:发现的bug越多,回归的时间也就多了,那么花费在验证bug上的时间也就多了,我们假设测试时间一定的情况下,这时没时间去关注新bug是否产生,就对其他80%的模块的覆盖率就会很低,这时如果发现bug很少,那么会有更多的测试idea去提高我们其他模块的测试覆盖率,对于发现bug很多,其针对以后隐藏的bug就会更难发现,就像产品本身有免疫功能一样,当发现的bug达到一定程度,会经过相当长时间未发现bug,所以而遗漏了更多的bug。这时只能说明该产品最终质量越差。
论点8:既然拿到待测产品时,就已知道bug数,那为何不测完全部的bug,而让bug遗留至线上呢?所以说明bug数会根据fix bug的变化而变化,这样发现的bug越来,不能说明未发现的bug数越多。
  论点9:代码整体之间存在耦合性,回归时专注于验证,却无法验证是否产生新缺陷。
==========================华丽丽的分割线3=====================
  官方观点:发现bug多少与产品最终质量并无直接关系
  这里需要考虑的bug是在什么阶段产出的,这里一般来说是测试执行阶段,还有一个考虑就是产品的最终的质量是怎么来考核的,什么样的产品该到了发布的时间点。还有这个是针对一个产品的,还是多个产品的比较,是一个开发团队还是多个开发团队,是一个测试团队还是多个测试团队的组合呢。很明显这里有很多的前提条件。
  论点1:这里说的是,一个测试团队发现的bug越多,其实并不是件好事,对于测试团队来说,最大的贡献就是预防了多少bug,(微软目前考核很重要的一个KPI就是这个)而不是在测试阶段发现了多少bug。这里的根据就是测试执行阶段发现bugfix bug的代价要比产品送测之前要花的代价要大的多。
  论点2:对于老大来说,看到测试报告,一个项目的发现的bug的多少,并不能影响老大强烈的认为这个项目的质量好坏。这里站着测试人员高度的责任心的基础上,项目需要发布,在有限的时间内,测试团队尽了最大的努力去发现bug(测试执行阶段),去保证质量。这里我们也要考虑项目启动和设计阶段,测试团队对于bug的预防和文档的评审都是尽最大的努力去减少在测试执行阶段发现的bug。这里我们测试团队需要的就是做出自己最大的努力去发现bug,一定程度上去减少bug。这时老大是特别信任测试团队的,认为这个产品的质量达到一定的程度,符合发布的条件。
  论点3:一个项目、一个日常、一个部门,几乎所有的地方都需要团队合作,特别是测试团队和开发团队的合作,那么对于一个产品出现的bug数越多,可能的因素也会越多,提出风险是有必要的,希望测试团队更多的关注测试覆盖率,而不是bug数达到了自己的预估,或自我认为这个bug数已经很多,自我的认为这个产品的质量已经不错了。希望测试团队提高自己的测试覆盖率,变化测试方法去克服产品的免疫功能。这些都是提高产品最终质量的一些途径。

  呵呵,其实归根结底,我们主要是要在责任心上去考虑,要求自己尽最大能力去预防bug,去发现bug当测试团队每个人都认真的去做了,那我们的质量还需要看这些具体的数据吗,也就没有这个话题的争论了。。。最后希望我们公司的测试团队都拥有这样的一份态度来保证产品的质量。

了解更多QA详细信息欢迎致电416-644-1998,或浏览网站www.NewJob123.com

来源:51Testing软件测试网采编

相关专题 »

    更多相关文章 »

    • 无忧资讯刊载此文不代表同意其说法或描述,仅为提供更多信息,也不构成任何投资或其他建议
    • 欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理
    • 凡用户自行发布的信息的合法性及真实性由发布者负责,与 51.CA 及其运营公司无关