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

由于软件测试工作需要每个成员都需要有高度的责任感、全身心投入，我们就必须通过良好的管理方法和一系列激励措施，使测试团队保持高昂的士气和高度的责任感。在我写的《软件测试方法和技术》第12章介绍了许多有效的方法，在这里主要想详细讨论具体的量化方法。
 

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

对于测试，最容易进行量化的有两个数据：测试用例(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 (缺陷值)”来度量，公式被定义为：

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）缺陷数量

P2_Bug_Number：一般的（major/normal）缺陷数量

P3_Bug_Number：次要的（minor）缺陷数量

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/100

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

原文转自：http://www.ltesting.net