http://www.51testing.com/batch.download.php?aid=12997

这里下载

古人说：熟读唐诗三百首 不会作诗也会吟。很多小孩子，从小就要求背诵唐诗宋词，熟练之后自然而然就会把握住诗词歌赋的韵律。当年我在准备托福GRE考试的时候，新东方的老师也告诉我们，学英语，背课文最有效，新概念1234背下来，达到倒背如流的程度，自然你的英语就没问题了，很多语法词法句法，都根深在你的思想和习惯里了，一张嘴，自然是一口标准的美语。

在我们测试行业，很多新人在刚踏进这个门槛的时候，最迷茫的就是怎么找bug啊，有些bug提上去，被退回来，被人说不是bug，有些bug，自己认为不是bug，别人却说你怎么不提啊，结果造成遗漏，三来二去，刚进来时候的豪情万丈，被打击成垂头气丧了。

那么，作为测试工程师，如何积累对bug的敏感度，以及把握的准确度呢，这个话题，可能不只是新人，很多在这个行业做了很多年的工程师也觉得这是个老大难，在这里，我提一个建议，熟读bug三百条，bug怎找很明了。

今天看了雅虎的QA典型百大missbug总结，才有此感触，的确我们应该形成经验积累的机制，尤其是bug，今年大量新同学加入我们团队，如果他们能在上岗前的培训中都过一遍我们常见典型的bug总结结果，将对他们的质量意识和bug敏感度有很好的提升，如果以后工作中再培训的话，效果就差很多了，和我们bug的发现时机是一个道理，越早发现bug，越早解决，我们所付出的代价就越小。

与其临渊羡鱼，不如退而结网，相关负责人应该落实这种机制，积累一些我们这几年的典型bug，用文档或某种形式形成共享，在新同学们上岗前培训一下，我期望的是每一个新人在正式工作前，至少要熟读百个以上的典型bug，并且最好可以亲自重现或者分析其中的一些。

一句话，
没吃过猪肉，也应该大概见过猪跑；
没提过bug，也应该大概知道bug怎么找。

很粗很粗的初稿，

根据上次我收集以及和大家讨论的意见，费劲脑汁思考如下：

目前我们大部分人为设计执行用例，提交bug的测试工程师，目前对他们的测试效率度量如下，除了这类人，我们还有自动化性能测试工程师，tl，测试项目负责人等其他角色，其他角色的测试效率我们稍后再考虑。

测试效率公式，单位时间（暂定每月）的测试效率=F(x1,x2,x3,y1,y2,z)+浮动分，前部分可以精确计算，后部分为tl主管经理根据事例进行评分，但原则上不得超过前面的20%。

1． Bug的有效率x1=有效bug/所有的bug，可在QC中直接统计出来

2．  有效Bug的加权数量x2= V级×1.5＋IV级×1.3＋III级＋II级×0.7＋I级×0.5, 这里只计算有效bug

3．  线上故障分x3，可以每周得到，并最终指定负责人

4． TC的效率y1, 可通过TC review 和TC评审参照TC checklist进行打分，完全没问题就100分，对遗漏和错误的点进行扣分，我们要出一份打分规则，评分规则要统一，在后期故障中若发现是由于TC遗漏了，负责TC review评分的人本人的效率也要扣分。

5． 有效的测试时间y2，小时为单位，为他本人真正参与到项目小需求的时间，刨去其他不相干的培训，请假等

6． 二次预发布的次数z,和效率成反比

很粗的估计了一个公式：F(x1,x2,x3,y,z)= x1*x2*(1-x3*0.2)*(y1/100)*(y2/140)*(1-z*0.5)

1） 效率很差的例子，某人某月发现200个bug，其中180个有效，x1=0.9，x2= 5×1.5＋25×1.3＋70＋50×0.7＋30×0.5=7.5+32.5+70+35+15=160，他的线上故障个数x3=2，TC的效率y1=80，有效的测试时间y2=120小时，二次预发布的次数z=1，计算结果F(x1,x2,x3,y,z)=x1*x2*(1-x3*0.2)*(y1/100)*(y2/140)*(1-z*0.5),大概为30分

2） 完美的例子，x1=0.95,x2=500,x3=0,y1=95,y2=140,z=0, 计算结果F(x1,x2,x3,y,z),大概为450

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

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

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

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

l  对技术组（性能自动化和环境）测试人员效率的度量因素如下:

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

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

3.        

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

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

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

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

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

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

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

　　曾经在方正研究院担任测试工程师的肖先生分析说，能胜任软件测试工程师的人，至少需要以下几个能力。

　　一、缜密的逻辑思维能力。为应对软件使用者千差万别的使用习惯和软件在使用过程中出现的各种现象，软件测试工程师应具有逆向思维能力，能够以用户角度出发，捕获一切可能性，对细节有不同寻常的关注能力。

　　二、出色的沟通能力。优秀的软件测试工程师，应具备出色的沟通和表达能力。既能和技术开发人员沟通，又能简洁明了地向客户、管理者等这些非技术人员阐述系统在哪方面有缺失。当发现软件有问题时，不仅需要跟开发人员沟通，找到问题出在哪儿，阐述自己挑错的理由，有时候甚至要提出解决方案，直接参与前期需求和代码的修改。

　　三、全面的技术能力。作为软件测试工程师，虽然无须精通各种语言各类技术，但必须全面理解被测软件系统，明白该使用何种工具进行测试。

　　四、耐得住性子。软件测试工作是枯燥的，甚至是重复性的，有时需要花费惊人的时间去分离、识别和分派一个错误，因此需要测试人员能静得下心、耐得住性子，心浮气躁是做不好的。