软件测试人员绩效的考核详细.doc

→ 文档质量：测试用例进行评审和同行评审发现的缺陷数，或者将此缺陷数除于文档页数算出比率。此指标考察测试人员文档编写的质量如何。 公式：∑缺陷数（评审和同行评审）（个） / ∑测试用例文档页数（页） 参考指标：由于评审是发现的缺陷数是不固定的，因此，这个指标没有可供参考的数值。如果缺陷数大小不能直接用于比较就使用缺陷 / 页方式进行横向对比。

→ 文档有效率：使用测试用例文档进行测试时发现的系统测试缺陷数除于此文档页数。用于考察文档是由有效的指导了测试工作。

公式：∑缺陷数（系统测试）（个） / ∑测试用例文档页数（页） 参考指标：平均 2.18 个缺陷 / 页

注意：如果存在测试人员在测试时创建新文档用于辅助测试时应包含这一部分。

→ 用例有效率：使用测试用例发现的全部缺陷除于测试用例数总和。这一指标是上一指标的补充指标，用于考察用例质量是否较高 公式：∑缺陷数（系统测试）（个） / ∑测试用例数（个）

参考指标：平均 0.59 个缺陷 / 用例，也就是说，每执行两个用例才得到 1 个缺陷，各工程有所不同，可以自己实践一下

→ 评审问题数：是否存在对需求理解、系统架构设计、系统设计等方面引起争议的问题。体现出测试人员发现问题的深入层次，有利于产品质量的提高。 ● 测试执行中工作效率相关指标：

→ 执行效率：利用测试用例文档页数除于此次系统测试执行的时间总和（不包含用例文档编写时间）。补充指标方法是用例的个数除于此次系统测试的时间总和。用于获得工作中测试人员每小时执行测试的速度。

公式：∑测试用例文档页数（页） / ∑执行系统测试的有效时间（小时） ∑测试用例数（个） / ∑执行系统测试的有效时间（小时）

参考指标：平均 0.53 页 / 小时， 1.95 个用例 / 小时。即测试人员每小时执行半页测试用例或者每小时执行 2 个测试用例。通过横向比较，容易知道那位成员的执行效率较高。注意：执行效率高的不代表测试质量也高，甚至执行效率和测试质量成反比，所以后面工作质量的指标会补充这一部分的偏离。实际结果表明，用例执行效率高的成员，其缺陷发现率往往偏低，考核如果不将此纳入进来也可以将其作为测试改进的一项重要数据进行收集。

→ 进度偏离度：检查计划时间和实际时间的进度，方法是计划时间差额减去实际时间差额除于实际工时总和，用于考察测试人员进度情况，监控测试是否按照日程进行，是否满足了工程的进度要求。

公式：∑（计划开始时间 - 实际开始时间）＋∑（计划结束时间 - 实际结束时间） / 总工时

参考指标：15％ 进度偏离是个相对的指标，可能偏离了 20 个工作日，但是对于一个长达半年时间的测试而言偏离天数比上整体测试所需天数不足 15 ％，可能偏离了 3 个工作日，但是对于一个只有 1 星期时间的测试已经超过了整个测试阶段所需天数的 60 ％。

注意：计算时分子分母要保持一致，即开始或结束时间已经去除了非工作日时间，则总工时也要去除非工作日时间。因为制定计划时是根据每个公司的工作日来制定的，也就是说，考虑了非正常工作日的日程。

测试进度也是考核很重要的一步，如果没有进度保证，所有的测试都存在风险，第一种方法是测试人员可以采用自下而上的方式向测试经理报告计划用时，这种方式风险比较少，个人根据自己能力大小确定，但是缺点是存在测试人员虚报可能性。另一种方法是测试经理进行估算后分配工作日程，这时估算是很重要的前提，除了依赖于测试经理的经验外，对评估结果进行同行评审是很客观可取的方法。

→ 缺陷发现率：测试人员各自发现的缺陷数总和除于各自所花费的测试时间总和。由于执行效率不能足够代表测试人员是否认真工作，那么，每小时发现的缺陷数就是重要的考核指标，你的工作可以通过这项指标得到反馈。 公式：∑缺陷数（系统测试）（个） / ∑执行系统测试的有效时间（小时） 参考指标：平均 1.1 个缺陷 / 小时 假使有位测试人员没有达到 1 小时发现 1 个缺陷，那么，除非产品质量高、模块较小，否则，就是他的缺陷发现能

力不如其他测试人员。当然，详细分类中可以根据发现重要缺陷的多少来定义缺陷发现能力。

● 测试执行中工作质量相关指标：

→ 缺陷数：为了更客观度量，考虑到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 3.0 = 9/100， …， ， Version 8.0 = 64/100， Version 8.0 = 81/100

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