培训服务 | PMP认证 | PgMP认证 设为首页 收藏本站 关于我们 联系我们
怎样才能说明软件测试工作做的好?
发布者:佚名 来源:泽众软件测试网 点击: 发表日期:2015-03-30

  最近我们确定了一系列考评开发工作质量的指标,比如初级Bug率,Bug关闭时间等等,不知不觉开发团队的压力大了很多,因此有开发人员来问:怎么都是考评开发的啊,测试工作的好坏怎么考评呢?今天我们就来讨论一下这个问题。

  1.测试遗漏Bug数

  这是绝大多数测试团队都会使用的重要指标,淘宝测试也在用。用这个指标的目的也非常明确:经过测试团队的验证,就应该把软件中的大部分Bug都找出来。如果我们测完了,产品也发布了,结果又出现了一些既严重,又明显的Bug,那无论如何都说不过去了。

  测试遗漏Bug可以分为“故障”和“普通Bug”两类,故障最好是一个都别有,普通Bug么,一般都会有一些,但数量也不能超过一个上限,具体的数字可以根据产品的特点,团队的现状,讨论后决定。

  问题:虽然我遗漏的Bug比他多一点,但是我每个月测试的功能比他多多了,做的多就错的多啊,这样公平么?

  这样肯定不公平。所以只考评遗漏Bug数,是很片面的,这里必须引入另一个指标,与遗漏Bug来制衡,这个指标就叫做:

  2.测试工作产能

  测试产能简单来说就是单位时间内,团队或者个人所测试完成的功能的数量。在最近的季度总结会上,我们统计了一下各个测试团队完成的项目和日常(淘宝术语,相当于微型的项目)的数量,以此来分析产能的高低。

  问题:有的项目做半年,有的只做一个月,日常也有大小之分,这样统计出来,不太靠谱吧?

  确实不靠谱,只统计到项目、日常的个数,太不精确了。我们必须要找到一个科学的“一般等价物”,用来标识一个项目或者日常的规模。值得庆幸的是,软件工程学科里已经有了一个标准的模型以及算法,它叫做:

  功能点!

  有了功能点计算的标准,我们再根据互联网软件的特点做一些调整,就能拿出一个解决方案,对每个项目和日常的功能点进行计算,比如A项目500个功能点,B日常20个功能点。有了这些数字,很多信息就一目了然了。我们其实没必要对测试用例数、Bug数做度量,因为我们比的不是谁的用例写的多,谁的Bug提的多,而是比谁测得又快又好。把每个项目的用例都写得近乎标准和完美,产能反而会下降。

  问题:开发只修改了一个功能点,但是我必须测试很多用例才能保证功能没问题,这样算,那我的产能不是很低了,这样公平么?

  这个问题我们先不回答,并且要反问这样一个问题:开发改了一个地方,我们是不是真的有必要把上面的功能全部回归测试一遍呢?汽车换了一个轮子,有必要把发动机也拆开测试一下么?

  这里有一个观点要澄清一下,测试人员不仅要熟悉需求业务,也要对产品的程序结构有所了解。这样一旦开发人员修改了程序的某个功能,我们测试就可以分析出来,哪些功能被影响了,需要重点测试;而没有被影响的部分,少测或者不测。

  如果开发修改的是底层的代码,那么用单元测试就可以很好的覆盖,web应用层只需要测试关键的功能点即可。如果web应用层也有自动化脚本可以覆盖,那就更爽了。这也就是淘宝测试正在推行的“珠联璧合”的精髓所在。(珠联璧合:一种多种测试策略混合的测试模型)。

  所以,在珠联璧合的模式下,我们不是比谁写的脚本多,也不是比谁写的脚本快,比的是,谁能灵活运用各种脚本,让验证功能点的速度达到极致。因此,只要我们能把珠联璧合运用自如,上面那个问题也就自然消失了。

  还有一个重点需要指出,测试环境的稳定性,对于测试产能来说非常重要。测试环境要是三天两头挂,大把的时间用来等待和调试,产能是根本上不去的。每个团队的manager都要想办法保证环境稳定。

  说了这么多,我们可以推理出这样一个结论,如果一个测试团队的产能很高,并且遗漏的Bug也很少,那我们就可以肯定,这个测试团队做的很出色。因为这两个指标,几乎体现了优秀团队的所有品质:无间的合作、流畅的沟通、综合的技术、强烈的责任感等等,只要其中一环出了问题,团队成绩都会出现明显的下降。

发 表 评 论 相 关 信 息
姓名: 邮箱:
内容:
全部评论
  • 中途接手软件项目的软件测试工作
  • 在软件测试工作中的自我提升
  • 软件测试工作量评估的故事
  • 软件测试工作中的基础知识
  • 软件测试工作真的很简单无技术难度吗
  • 如何更好地处理软件测试工作
  • 共创国际项目管理顾问旗下网站:中国研发管理网 | 项目管理者联盟 | 中国工程管理网
    Copyright © 2005-2014 ChinaRDM.COM 研发管理网 All rights reserved. 京ICP证060517号