关于测试工作考核

前段时间一直在考虑怎样量化测试工作的效率和质量，也实验性的列出了十几个考核指标，比如bug发现效率，有效bug率，发现bug严重等级质量，测试用例产生效率，测试用例执行率，测试用例有效率，编写文档效率，编写文档质量等等，但是在实际应用的过程中遇到了很多问题，有很多指标是不能体现的，这里就絮叨几个应用和没有应用的量化指标：

        编写文档的质量体现的公式是：评审中发现的问题个数/编写文档的页数。可是在测试的评审工作做得不是很完善的前提下，问题个数的统计是很难量化的，我也试着采用其他办法，例如测试人员编写的文档是经过我审核的，那么我发现的问题就以bug的形式管理起来，这样在考核的时候就有数据即可以参考，但是这样的过程一是没有过程监督不是很规范，问题的纪录不全面，有时候图方便就直接跟负责这个文档的测试人员说哪里需要改进，没有进行问题纪录；二是个人的精力有限，有时候忙起来就草草看了一下，这样对其他仔细看过的文档的数据就没有可比性；另外关于文档页数这个指标个人认为也不是很准确，很多文档都不是页数与时间成正比的，根项目复杂程度和类似项目有没有做过有很大关系，所以与此关联的编写文档效率的指标也没有应用。

        测试用例的编写效率的公式是：测试用例个数/编写测试用例的有效时间。这里编写的测试用例个数有的测试用例是从通用用例里直接导过来的，这和其他重新编写的分开在统计上就很麻烦，另外根据个人分配的项目模块的复杂程度测试用例的编写效率也有不同体现。虽然这个指标已经在实际统计中应用，但是也有相应的测试人员提出过疑义。

        无效bug率的公式为：无效bug数/发现bug总数。目前我一般是一个月统计一次相关考核指标，但是目前的缺陷跟踪工作做得不好，有很多bug在开发那边不能及时响应，这就造成了我统计的时候发现的bug总数有大半开发人员还没来得及看，那么无效bug数当然也就不准确了。

        还有bug的严重程度的划分，因为有的bug级别高并不等于很难发现，所以这就造成了有些测试人员刻意的去追求那种很容易发现但是bug级别又很高的bug，这就有点偏离考核本身的目的。

        以上絮叨这么多的根本原因还是我们的开发过程和测试过程均不是很完善，但我还是把已经统计的一些指标拿出来看一下，结果不能体现出全部，也没有拿它与绩效挂钩，但是有时候从结果还是能分析出一些东西来的~~~~

2006年11月（10.27～12.1）发现bug工作情况 服务器严重程度姓名1 姓名2 姓名3 合计 71 1 0 6 0 1 0 6 13 80 6 1 6 71 2 2 51 2 22 4 38 111 80 49 20 34 71 3 3 102 1 19 1 53 174 80 99 18 52 71 4 0 20 1 14 0 22 56 80 20 13 22 71 5 0 0 0 0 0 0 0 80 0 0 0 　总计 179 　 56 　 119 　 354 　工时 68 　 13 　 39 　 120 　　姓名1 　姓名2 　姓名3 　平均值 　效率 2.63 　 4.31 　 3.05 　 2.95 　质量 0.51 　 0.76 　 0.57 　 0.61 　分数 5.1 　 5.9 　 5.7 　 5.6 　　　　　　　　　 效率=∑缺陷数（个）/ ∑执行系统测试的有效时间（小时）
质量=1级*0.3+2级*0.2+3级*0.2+4级*0.1+5级*0 / ∑执行系统测试的有效时间（小时）

2006年11月（10.27～12.1）设计、执行用例工作情况 任务类别姓名1 姓名2 姓名3 平均值 设计个数 0 85 115 100.00 设计工时 0 30.5 32.5 31.5 bug数 0 51 72 61.5 设计效率 0.00 2.79 3.54 3.16 设计质量 0.00 0.60 0.63 0.61 设计分数 0.00 2.86 3.09 2.98 　　　　　 执行个数 87 0 99 93 执行工时 31 0 35 33 bug数 56 0 111 83.5 执行效率 2.81 0.00 2.83 2.82 执行质量 0.64 0.00 1.12 0.88 执行分数 2.99 0.00 3.95 3.47 分数 2.95 2.86 3.52 3.11 　　　　　 设计效率=∑测试用例数（个）/ ∑编写测试用例有效时间（小时）
执行效率=∑测试用例数（个）/ ∑执行系统测试的有效时间（小时）
设计质量=∑缺陷数（系统测试）（个）/ ∑设计测试用例数（个）
执行质量=∑缺陷数（系统测试）（个）/ ∑执行测试用例数（个）

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