关于测试效率的度量

        关于测试效率的度量  软件测试　

   　我的理解，效率不等于速度，效率=速度+质量+进度。

　　经过上次和大家的讨论，我归纳我们的测试效率和以下几点有关：

　　对业务组测试人员效率的度量因素如下：

　　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. 测试人员造成的二次预发布，将对很多人和整体造成影响，也要计入测试人员的效率中。

　　对技术组(性能自动化和环境)测试人员效率的度量因素如下：

　　1. 自动化测试的引入和使用是否合理，不是每个项目都适合做自动化的，自动化并不能保证效率的提高，用5个小时开发的自动化脚本来替代3个小时的手工测试并不合算，自动化测试需要评审，按照项目的大小不同，必要的情况下才引入自动化测试;

　　2. 自动化测试，特别是性能测试结束之后，我们要分析部分测试结果，测试结果的分析水平，也可以作为衡量测试效率的一个指标。

　　对测试项目负责人的效率的度量因素如下：

　　1. 测试是否提早介入项目，例如FRD阶段就介入，越早介入，越有利于测试，使测试人员更加熟悉整个项目，使问题早暴露，提高整体效率。

　　2. 开发提交测试的时候，标准是否合理，把关是否严格，如果开发的质量不行，坚决要退回，不然会影响我们测试的效率和进度。

　　3. 测试计划阶段，评价测试计划的合理性，包括任务细化，细化的程度是否合理，任务顺序，资源安排，任务分配合理，风险预估等等

　　4. 项目结束后，评价项目进行阶段中负责人的跟进情况，特殊情况处理，风险触发之后的处理，资源协调，信息收集，共享，沟通，配合等等

　　需要做到以上，我们必须用量化的方法得到很多数据才能度量我们的测试效率，我期望的效果是测试部门内部成员的工作业绩数据化，例如，每天给每个测试工程师分配的任务非常具体，测试负责人随时关注他们的进展情况，完成的百分比，并不断督促他们，每天报告总体状态和紧急情况。并且，把每个人每天或每周的工作成果(发现bug的数量和工作的质量，效率)数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就主动加油赶工，形成一种良好的测试氛围。每周周例会的时候，对表现突出的给予表扬，对每次都比较差的下属，单独谈心，问问具体原因，改进他们的效率，多给他们一些帮助，这样有利于你们的小组的整体进步。

　　测试效率作为新的KPI，将在09年慢慢落实，上面很多的数据现在还没有具体量化，我们会通过技术委员会或者架构组SQA帮我们取得相关量化的数据，慢慢充实改进我们的测试效率度量方法，大家先看一下上面的内容，可能有遗漏，如果有更好的想法或建议，请随时尽早提出给我。

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