经过上次和大家的讨论，我归纳我们的测试效率和以下几点有关：
1. Bug总数，包含数量，等级，其他因素不变的前提下，肯定是bug数越多这位测试人员的效率越高，在统计bug数的时候，可以根据bug等级×相应的基数来计算bug总数。比如，bug数＝V级×1.5＋IV级×1.3＋III级＋II级×0.7＋I级×0.5。
2. 有效Bug所占的比例，即使我们报上去很多bug，但有效的却不多，也不能说明我们效率高，反而，无效的bug会浪费开发和测试相关人员很多时间处理，降低了我们的效率。
3. 发布后的线上故障，现阶段测试相关的故障主要都是因为测试遗漏，有遗漏就说明我们的测试还是效率不高，可以改进。
4. Bug发现的时间点，bug曲线的收敛性，理想的效率高的模式应该是前多后少，慢慢收敛的，如果前期bug非常少，后期却发现大量bug，那我们的前期效率就有问题。
5. TC评审或review时考察TC的数量，速度，质量，颗粒度，对功能点的覆盖，是否有遗漏等等，参加评审人员提出的修改建议，给出打分，评价测试人员TC准备的效率，同时，提出较多修改意见的评审人员的效率也是比较高的。
6. TC评审通过，执行完之后，需要考察执行的速度和质量准确率，同样的用例，有人2天就执行完了，有人却要3天，说明速度不佳；一个case，测试的时候OK，后期却发现其实应该是NG，说明执行不认真，或者理解有问题，这些都是低下的效率，尤其是为了赶进度填写假的结果，严重违背我们诚信的基本价值观。
7. 测试人员造成的二次预发布，将对很多人和整体造成影响，也要计入测试人员的效率中。
文章来源于领测软件测试网 https://www.ltesting.net/