个人认为可以从软件测试的活动中的以下指标综合考评，去评估衡量测试效率，每项指标都高，自然能够说明一些问题：
1.发现缺陷的质量：
同一个项目组内，我们一般运用测试管理工具TD，按优先级和严重等级，把每个人的缺陷做成柱状图和饼图，放到一个文档中，邮件发给大家，让组内成员了解自己的工作情况和其他人的工作情况。同时也让开发人员，对每个测试人员的工作，做出评估，供绩效考核时参考。特别是发现非常隐蔽缺陷的测试人员，一定要重赏。
2. 测试的有效性：
一般来说，递交Bug的有效性，体现了测试员是否能够正确理解系统，并发现问题，是否能够发现有效的问题。很多时候，测试人员没有弄准确需求，或者是没搞清楚设计，一旦出现异常，就提交Bug.不是和前面的缺陷相同，重复递交相同类型的缺陷，就是递交无效的Bug，导致后来很多缺陷，都被项目评审时拒绝，既耽误了时间，效率自然不高。
3.测试组员交叉测试，发现漏测问题数量：
经常是这样，一个测试人员测试结束，修复了全部的缺陷。这个时候，测试的模块和测试人员交叉一下，再测试，很有可能又发现很多问题。这样我们可以对测试发现问题数量，进行统计。这样做，就迫使测试人员认真执行每一轮测试，每次测试都不敢懈怠。
4.遗漏到客户缺陷的比例：
一旦版本测试通过，发布给客户以后，客户要对发布的版本进行验收测试。同样会发现一些问题，我们也会对测试过程中发现的Bug分配到每个模块和具体的人。但是，如果缺陷在测试环境中不能重现，只能在实际工作环境中出现，则不属于遗漏给客户的Bug，不计入漏测统计里面。有时候，客户系统在使用中也会发现缺陷，我们同样做好记录。
5.递交的缺陷数量：
在同一个项目组内，每天递交的Bug数量，每周递交的Bug数量，每个版本测试结束，总共递交的Bug数量。最终测试结束，算出每个人递交有效缺陷的百分比。
6.执行用例的数量：【Allen】个人认为不可取，因为不同的测试用例的efforts也会不一样，前期准备，背景知识了解和获取都不一样等等
同一天，每个测试人员，执行用例的数量。但是一定要去除那些不能够测试的功能模块，或者是被阻塞的模块，这些一定要考虑到。否则大家意见就大了呢！
7.编写测试文档的速度和质量：
每次编写测试用例时，大家都要编写部分模块的测试用例，我们也可以通过单位时间内编写case的数量、速度和质量，来区分每个人的效率，我觉得也是一种好方法。
8.评审发现问题的效率：【Allen】要提出有价值的评审意见才行，不能为了评审而评审
在组织部门内部的case评审时，同一个测试文档的评审，如果提出的修改建议比较多，并且很有参考价值。这样的测试人员，效率应该比较高，得考虑考虑加薪，呵呵。
9.测试工具使用的熟练程度：
当然，一个测试人员，对测试工具的熟练程度越高，使用技巧越强，一般来说，测试的效率就越高。按常理来说，每个人不可能了解全部的自动化测试工具，我们只对常用的测试工具进行考核就可以了，还算人性化吧。并且后面懂得较多的同事，给组内成员集体培训，使大家迅速掌握测试工具的基本使用，这才是我们的真正目的。
10.测试结果的分析水平：【Allen】这个很重要，分析水平的好坏可以看出一个人测试水平的高低和对产品需求理解
对自动化的测试工具来说，特别是性能测试结束之后，我们要分析部分测试结果，如果你都不熟悉测试工具的分析，何谈效率呢？所以测试结果的分析水平，也可以作为衡量测试效率的一个指标。
转自：http://blog.csdn.net/fenfangnaicha/article/details/4404796