如何用量化数据来激励测试工程师？（转）

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

 51Testing软件测试网?"X
W
JgQUs

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

Bug_value = （P0_Bug_Number × 1.6 + P1_Bug_Number× 1.4 + P2_Bug_Number× 0.7 + P3_Bug_Number×0.3）× Wd × Ws × Wt

其中：P0_Bug_Number：致命的（fatal）缺陷数量  

P1_Bug_Number：严重的（critical）缺陷数量51Testing软件测试网0xh g^XB(~

P2_Bug_Number：一般的（major/normal）缺陷数量51Testing软件测试网%`4m5~Ppv

P3_Bug_Number：次要的（minor）缺陷数量51Testing软件测试网:pC-r*y+d%PA&d7R`
A

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

Ws: 稳定性系数，全新模块，Bug比较多，发现缺陷比较容易；版本越高，越稳定。Ws可以定在0.5 – 1.0， 假如以version 10.0为1.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/10051Testing软件测试网pdfN)V

Wt: 产品类型系数，可根据实际情况和历史数据来判断。Wt也可以和Wd合并为一个系数。