架设IT人桥梁,呈现有价值东西

如何鉴定软件测试工作的质量?

上一篇 / 下一篇  2011-03-05 01:16:53 / 个人分类:测试之道

现在的用人单位都有一套自己的考评机制,那么测试工作的好坏怎么考评呢?今天我们就来讨论一下这个问题。

1.测试遗漏Bug

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

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

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

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

2.测试工作产能

  测试产能简单来说就是单位时间内,团队或者个人所测试完成的功能的数量。

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

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

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

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

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

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

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

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

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

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


TAG: Web测试 web测试 互联网测试

 

评分:0

我来说两句

日历

« 2023-12-12  
     12
3456789
10111213141516
17181920212223
24252627282930
31      

数据统计

  • 访问量: 16970
  • 日志数: 34
  • 建立时间: 2010-12-06
  • 更新时间: 2011-04-09

RSS订阅

Open Toolbar