产品的质量依赖于过程的质量, 而过程的质量依赖于企业文化和管理! 欢迎大家来到我的小窝~!

如何用量化数据来激励测试工程师?(转)

上一篇 / 下一篇  2010-12-23 11:44:55 / 个人分类:管理

从度量角度看,量化数据适合团队绩效的考核,而不宜用于个人绩效的考核。但是,有时为了实行一些测试改进方法、实施某些有效的策略,需要设定游戏规则,通过这些规则进行奖励,以促进新的方法、策略的改进。这种奖励,看作是游戏(game)的、临时的奖励,而不是做年终的绩效考核。51Testing软件测试网g7To7}GQ

 

4_i'TKk8Eo D0

对于测试,最容易进行量化的有两个数据:测试用例(test case)和所发现的缺陷(Bug)test case的数量、覆盖程度(功能覆盖率、缺陷覆盖率)等是比较容易量化的,而Bug的度量数据更多x些,如所发现的bug数量、描述不清楚的Bug数量、不是BugBug数量、遗漏的Bug数量(被客户发现——Remedy Tickets、或在下一个版本发现——Late Discovery Bug)等。对于Bug度量的数据,最重要的两项是所发现的bug数量和遗漏的Bug数量,前者是测试效率和设计/代码的 质量度量,后者是测试质量(也包括设计、代码质量,我们坚信质量不是测出来的,而是构建出来的)的度量。遗漏的Bug数量对质量度量的更有效些,但是不能及时获得,必须在产品发布之后才能获得。所以,为了实现测试的效率,有时必须靠“所发现的bug数量”来度量。为了更客观度量,考虑到bug的严重性、技术难度、产品类型、模块稳定性等因素影响,不是用“所发现的bug数量”,而是用“所获得的bug value (缺陷值)”来度量,公式被定义为:51Testing软件测试网7@Tn7K5Ze

 51Testing软件测试网jjTj}

Bug_value = P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3)× Wd × Ws × Wt51Testing软件测试网2I2T3f+f u

 51Testing软件测试网 q8f?w4I

其中:P0_Bug_Number:致命的(fatal)缺陷数量  51Testing软件测试网 v\9e6x2J$v1W

P1_Bug_Number:严重的(critical)缺陷数量

5u k#G;b(W X+?0

P2_Bug_Number:一般的(major/normal)缺陷数量

Wx2}ZVxp0

P3_Bug_Number:次要的(minor)缺陷数量51Testing软件测试网 [,_.W$f1u URri

Wd: 技术难度系数,如Database, Enterprise Server, Java难度系数大,发现Bug不容易,Wd可以定在1.5 – 5.0

a y9oK }%`1fJ0

Ws: 稳定性系数,全新模块,Bug比较多,发现缺陷比较容易;版本越高,越稳定。Ws可以定在0.5 – 1.0 假如以version 10.01.0, Version 1.0 = 1/100, Version 2.0 = 4/10, Version 2.0 = 9/100, …, , Version 8.0 = 64/100, Version 8.0 = 81/100

;Pf4s6x P M r{0

Wt: 产品类型系数,可根据实际情况和历史数据来判断。Wt也可以和Wd合并为一个系数。51Testing软件测试网'YD9L M'Y3q_


TAG:

 

评分:0

我来说两句

显示全部

:loveliness: :handshake :victory: :funk: :time: :kiss: :call: :hug: :lol :'( :Q :L ;P :$ :P :o :@ :D :( :)

日历

« 2020-11-13  
1234567
891011121314
15161718192021
22232425262728
2930     

数据统计

  • 访问量: 31735
  • 日志数: 65
  • 文件数: 1
  • 建立时间: 2010-11-23
  • 更新时间: 2011-10-18

RSS订阅

Open Toolbar