如何衡量测试效率，如何提高测试效率？（08-07-19）（获奖名单已公布）
根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率，该衡量方法是否合理，有哪些优、缺点？如果以该指标来衡量测试效率，那应该从何处着手提高测试效率呢？
感谢会员Cassiel提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至7月28日17：00分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在本周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖爱吃鱼的月亮当当购物卡50元17＃二等奖deanaa300论坛积分13＃sunyh23＃三等奖maguschen100论坛积分
24＃godn_198126＃rolei27＃ 根据系统测试发现缺陷数来衡量测试人员的测试效率，测试执行效率，我个人认为衡量方法不合理。我的观点是如果考虑缺陷数和测试人员或者开发人员挂钩，都不太合理。
首先，如果和开发人员挂钩，会进一步加深测试部门和开发部门的矛盾。
其次，如果只和测试人员挂钩，缺陷数本身就是不可控的，以缺陷数为标准，这个标准很不好把握。
优点：
我认为这个衡量方法的优点就是很直观在数量上体现工作量。（但是我个人认为这个说法也是很不有说服力，因为测试的工作和开发人员联系非常紧密。）
如果一定要以该指标来衡量测试效率，应该以BUG的收缩率的标准来提高测试效率，即每一轮发现的BUG和回归的BUG的比例应该是逐步提高的标准来提高效率。 新人关注 系统测试发现缺陷数来衡量测试人员的系统测试效率,这显然不合理，如果一个测试只光发现bug但是却不进行跟踪，哪么发现和修复的bug谁处理？
如果一个测试人员只会发现界面bug，及时很多，哪么也能说他效率高吗？
单方面的测试都不是效率高的表现。
我想做测试还是应该了解测试生命周期来走，合理的测试流程，设计合理的test case，及早的发现bug，不仅仅是系统测试阶段的。还有需求阶段，单元测试，集成测试，以及维护阶段，并且了解bug的优先级别来。
而且我发现能对bug进行准确定位，并且马上分析bug是非常重要的。
如果适当的话，引进自动化测试工具是必要的。
开个篇，希望会有更好的回答。 个人认为“根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率，该衡量方法是否合理，有哪些优、缺点？”是不合理的。
对于一个系统在开发后Bug的多少不是我们测试人员控制的了的，大多是开发人员导致的，有的也可能是分析工程师在分析过程中就搞错了。对于一个经验丰富的开发人员可能发生Bug的几率很低，尤其是一些业务上bug。而对于一个开发新手来说，由于对业务及开发方面的经验比较欠缺，所以发生bug的几率要远比有经验的人多的多。
同是一个测试人员同不同经验的开发人员合作，发现缺陷得数量却相差很多，你能说这个测试人员测试效率高还是低？
个人认为根据软件开发周期内对软件缺陷的解决程度和软件质量跟踪中爆发的缺陷来判断一个测试人员的测试效率可能比较合理一些。
[ 本帖最后由 云竹宝贝 于 2008-7-21 18:10 编辑 ] 这一直是个问题。如何全面的衡量一个测试部门.乃至测试人员的工作成绩.在一般的公司很难做到。
提倡先稳定bug级别的概念.
然后以bug数量和级别按必须计算。
并根据不同项目来算.
优缺点我就不说了。.大家都清楚。并不合理.
结论:如何让更高的领导不认为bug数量才是唯一的衡量。.那才是最重要的。.. 我觉得也不应该以发现Bug数来衡量测试效率。
测试贯穿于生命周期的各个阶段，
软件质量问题越晚发现，修复Bug的代价越高，
并且缺陷存在放大的趋势，如果需求阶段漏掉一个错误，改错误可能会引起n个的设计错误。
不同阶段它们n值的不同。根据前人经验表明，从概要设计到详细设计的错误放大系数大约为1.5，从详细设计到编码设计阶段的错误放大系数大约为3。
所以，衡量测试的效率应该是尽早发现“高质量”的Bug数为基准。
那么提高测试效率就是尽早的发现尽可能多的Bug。
当然也有人说过用自动化工具，作为自动化工具只是作为帮助你发现软件的Bug。自动化工具作为测试工具，它只能使你的测试更规范，局部或全部的代替人工进行测试；它只是辅助我们的测试工作，自动化我们的测试过程。而真正的要发现更多的Bug是要靠你来完成。当然我也很赞同自动化工具，它也是提高测试效率的一个手段。因为借助自动化工具可以比人工进行同样的测试工作要节省了更多的时间，人力和金钱。 不合理，我们测试的主要目的是为了发现更多的bug，但是测试只能找出程序中的错误，不能证明程序中没有错误，所以错误的发现是不确定的，也存在一个运气可言，测试人员勤奋的测试，有时候也并不一定查到几个bug，所以用bug数来计算测试效率不科学 我想楼主最想知道的是怎么提高测试效率，这也是我最近一直在想的问题。
我觉得测试的工作可以划分几个点：
1. 测试需求的分析，列出测试目的
2. 测试用例的设计
3.测试工具的设计和开发
4. 测试的执行
我不认为缺陷数是衡量测试效率的高低，但我认为这是咱们测试的价值体现。
我想测试效率是不是这样去划分：（bugs+测试工具设计+测试用例设计） / （项目开发的时间+项目的复杂度+开发人员的水平）
这里的测试工具的指：如果那些测试用例可以用你工具运行几下修改些参数就可以测试完，那不用说你的效率肯定是高的。
测试用例设计：花少量的测试用例覆盖率达到最优
分母就不用解释了。
难点在于这些东西怎么去量化去可控制，让领导知道你干了又多又好。。。 根据ＢＵＧ数去衡量测试人员测试的效益我觉得不合理，不是说一个好的测试工程师是发现迄今为止没有人发现的ＢＵＧ吗？如果只是根据数量去衡量，而那些缺陷都是些字体方面数字方面以及常人能发现的ＢＵＧ数，而一个人发现了所有人都未发现的ＢＵＧ．但是发现的数目相对很少，那么能说他的效益不高不是一个好的测试工程师吗？我觉得怎样去衡量不仅关注缺陷的个数，也得关注缺陷的质量，跑的ＣＡＳＥ数等多方面去衡量 关于衡量测试效率的问题...
一是利用客观数据，比如每天跑多少case，每天报多少bug，编写case的速度数量及质量...这些都体现一个测试人员的素质，基本上测试经理都通过这些基本方法观察团队成员的工作。
有了数据就有了比较，你跑得case比人家快，报得bug比人家多，确实能令人感到些许自豪感。:lol
但是就像楼上几位说的确实有漏洞导致衡量方法不是很全面很合理，不过目前这还是评估一个测试人员效率的主要手段。
第二就是加入主观评判。我们经理就经常说要多报bug而且要报好bug...好bug意味着什么？首先是bug report的质量，bug的信息描述得很准确，很简洁很清楚，有时甚至要求测试人员很准确的找到导致bug的根本原因，要求你对项目很深的理解。
有时项目进度很紧张，所以在这种时间敏感的条件下更要求要写great bug report。
另外有时需要你很快的了解项目，很快的阅读test plan，test spec，并能够很快地写出test case尽可能多地覆盖spec~嗯简而言之就是学习、领悟及创新创造的能力。:loveliness:
关于提高效率...
管理好测试数据，可能你会参与到多个项目中，每个项目又有区别，甚至每次测试都有区别，一大堆的测试准备数据，测试文档，甚至与测试相关的其他信息，比如邮件，聊天记录等等。这就要求你将日常工作中的分类、记录以及有效的存放管理，以便用时很快的找到。
团队协作，有时你苦想三天的问题其实早就有人知道怎么解决了~结果你没提出来，白白浪费时间。:L
还有就是也不能什么问题都拿来问，容易让人觉得很傻很天真，而且有时也会打断别人的思路，影响别人的效率，所以还是自己先找找答案吧先。有一公司老总跟我说他们公司新来一女员工，什么都问，什么都得教，最后教完了还是什么都不会，有一次吃饭的时候甚至还问他是用勺还是用筷子吃...:L :L
有时要求你对team里的其他成员有基本的了解，谁负责哪方面工作，相关的测试文档以前是谁写的等等，保证出现问题能够很快的找到责任人、原因及解决办法。
令我最记忆犹新的一次，在一个团队里，有一天开发人员突然站起来吼了一句，谁把数据库删了~:L 然后全场鸦雀无声，最后也不知道谁删的，还好有个几天前的备份数据库，否则大家可能整整一天都可以歇着了。不过还是造成了一定损失。
最后就是利用工具，有时在一些手工测试很浪费时间人力及成本的地方，比如回归测试，那么自动化工具或框架对项目的贡献度是很高的。而且有时必须引入一些工具，所以一些bug管理工具，case管理工具，项目管理工具，性能测试工具，功能自动化工具便应运而生。
提高工作效率的问题就变成高效使用工具的能力了，这里就要求更快的学习以及操作熟练度。
粗略算一下，假如1个人1天跑40个case，一个模块有100个case，有30个模块。那么需要这个人跑75天...要是项目再分成多个阶段，每个阶段都要回归测试并加入新的测试，那么...写到这里我突然猜测这会不会是现在软件测试这么火并且各个公司都狂招测试人员的一个因素呢？:o
利用自动化，我想不光是提高效率的问题，更是一种测试思路的改变。
但是切忌自动化如果在build版本变化很快的情况下并不适用，也许等你录制完操作，编写好脚本，build就变了，结果你还没测呢...;P
[ 本帖最后由 dabeixiong 于 2008-7-22 10:01 编辑 ] 根据楼上几位朋友的分析，我发现我的回答有些不全面，衡量测试效率，还需要比较合理的测试方法，要考虑到测试的覆盖率（覆盖率越高越好），及时的缺陷跟踪，以及配置管理等等
当然还有楼上说的跑的Case数，我只记得去提高软件的质量，和尽早避免后期繁杂的测试工作，却忽略了测试工作的加快，:P 谢谢提醒 说说我的观点。不同产品的质量，同一产品不同模块的质量，都会有差距；不同产品之间，模块与模块之间，不同测试阶段之间，测试难度也是不同的。所以如果仅仅从发现bug数量来衡量测试执行的效率，显然会有失偏颇。
现在很多公司都会采用一些测试管理或者bug跟踪工具。通过这些工具我们也能够很容易的得到诸如每人发现bug数等等的数据。但是数据本身是没有意义的，正如上面提到的，简单的用发现bug数量来衡量测试效率是有失偏颇的。我们手里有足够多的数据，这是我们做分析评价的第一步。但是更重要的是怎么样用好这些数据，怎么样让这些数据成为有价值的报表，这才是我们应该关注和思考的。
首先，我们需要保证数据的真实性。比如说，我们会对每个bug的严重程度进行分类，但是如果由于大家分类的标准不统一导致这一项数据不准确，那么即使接下来有很好的分析模型来分析这些数据，我们最终拿到的报表也是不能真实反应测试工作的状态的。对于这个问题，我们应该对每一项数据有明确的定义，然后通过案例分析的方式在整个测试团队中统一标准，同时定期的随机抽查bug数据的质量，尽可能地保证数据本身的准确性和真实性。
其次，当我们有了真实的数据之后，我们就需要建立模型，对数据进行分析。这是整个评价过程中最重要的一环，也是要求最高的一环。我们需要明确我们关注的是什么。比如说，我们关注整个测试周期各阶段的情况，我们可能就会去获取每个阶段我们发现了多少个bug，这些bug有多少是应该在前面的测试环节就被发现的等等。或者我们关注的是模块与模块之间的横向比较，可能我们就会关心各个模块在各个阶段的bug比例，不同的严重程度下各个模块的bug数和bug比例。又或者我们关注在测试人员身上，那么除了每个人发现bug的数量，我们还会关心发现bug的严重程度，bug遗漏的比例等等。
最后，我们需要定义一些辅助数据来平衡数据本身的一些差异。比如说，我们在得到每个测试人员发现bug数量的数据之后，需要考虑他所在的测试阶段和模块的一些特点，可能系统测试发现bug的难度比功能测试高，或者财务模块bug发现难度比较大，那么我们就应该相应的给这些测试阶段和测试模块更高的权重系数，来反应它们之间的差异性。
当我们做完上面的事情之后，我们就完成了初始化的工作，接下来我们需要做得是调整和改进。通过一段时间的使用和观察，可能我会发现有些数据本身的定义有一些问题，或者一些模型忽略了影响很大的因素，再或者我发现权重系数有问题，那么我们可以对上面的系统进行改进和调整。
在软件开发和测试的过程中，没有一套一成不变的方法和系统，能一直准确的反应这个过程。我们可以做的，就是接受变化，跟上变化，从而尽可能地用变化的思路和方法来反应项目的状态。 根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率，该衡量方法是否合理，有哪些优、缺点？
如果以该指标来衡量测试效率，那应该从何处着手提高测试效率呢？
对于第一个问题，做测试的人员都会回答不合理，但其实每个考核并不是只有一个指标，只是某个指标占考核分里的权重不一样，个人觉得还是能体现出测试人员的部分工作的，但需要更好的结合别的考核指标。对于这个考核指标的优点是直观体现了测试人员的成果，采集数据比较方便、容易；缺点是比较片面，不能体现测试人员的实际差异，测试的覆盖率等，单凭这一个就指标就考核那就是考核体制不健全，对于缺陷的质量有重大的影响，所以应对测试人员的提交的缺陷由测试负责人或组长、经理等角色进行REVIEW，再分析缺陷的严重程序，对严重、较大级别的陷缺数量、所占比例也放入考核指标中。
提高测试效率的方法：
1、系统负责制，某一系统或模块的测试工作责任到人，这样测试人员对系统有全面的了解，也会有深度。为避免测试盲区，安排测试人员间交互测试，每个人的从不同视角、观注点、认知、理解等方面去发现问题。不管是谁发现的BUG，都由系统负责人进行确认，这样扩展系统负责人的视角，学会从别人测试的角度去看问题。从这里也可以生出一个衡量指标，系统负责人发现的BUG与他人发现的BUG比。这是从项目组内部来看，从外部来看是就是用户与项目组内发现某系统的BUG，这里要求组内人员充分发挥团队合作精神，一起努力减少外部缺陷比例，个人认为这是衡量测试人员的一个重要指标。
2、测试用例，从需求、设计等文档里产生用例，在测试的过程中也在不断的增加测试用例，以测养测，不断提高测试用例的覆盖率，将测试用例与发现的BUG进行关联，计算测试用例发现BUG的比例，也可以是一个考核指标
3、BUG REVIEW，提高BUG的质量，让BUG的定位更准确，也避免重复提交BUG，或由于测试环境不正确引起的BUG传递
4、缺陷数据分析，不断总结、分析缺陷，不断与项目经理进行沟通，提高开发质量，事先就避免一些简单、界面规范等错误进入缺陷管理的流程，把时间更多的花在重要的功能测试上，来提高测试的效率
5、开发或引入测试工具，自动测试化测试不一定是好的，也有可能会起到反作用，浪费了大量的人力、物力、时间却没有效果也是常有的事，所以要根据项目情况、测试人员情况进行合理的分析，找到适合自己项目的测试工具、测试方法。
其他的学习一下，好的再引入测试工作中。
[ 本帖最后由 sense 于 2008-7-23 11:24 编辑 ] 从几个层面考虑
1、测试技能
2、测试需求的提取能力；
3、测试用例的设计能力；
4、提交的bug的质量与数量；
通过量化管理来衡量和提高测试效率
首先关于测试效率的衡量需要结合测试过程以及软件度量部分关于测试活动的度量来考虑。因为没有度量就没有管理。一。从测试过程来划分我们可以把测试活动分为以下几个阶段：
1、测试计划阶段，计划阶段效率的衡量可以是编写测试计划相关文档的的效率，比如计划页数/人时或计划页数/人天，比如7页/人天。当然具体这个数值是多还是少可以通过度量整个公司的生产效率，在IBM等公司会有一个PCB（Personal Capability Baseline）个人能力基线，公司有公司的，组织有组织的，个人有个人的。通过个人的横向比较和公司与部门、部门与个人的纵向比较来看是否需要来提高效率。下面几个阶段的也类似。
2、测试的需求分析阶段，测试需求分析阶段效率的衡量可以是测试方案的页数/人时或页数/人天来衡量。
3、测试设计阶段，这个阶段主要以测试用例的设计效率，比如个数/人天来衡量。
4、测试执行阶段，这个阶段可以以测试用例的执行效率以及发现BUG的效率，比如执行用例数/人天，发现BUG数（按严重级别加权）/人天。
5、测试评估，这个阶段可以按测试报告的编写效率来衡量，比如测试报告页数/人天或人时。
另外就是穿插在这些阶段的相关的管理和度量以及评审活动，即便是评审也可以量化来管理。
对于如何衡量测试效率，如何提高测试效率谈谈自己的看法
如何衡量测试效率？个人认为可以从软件测试的活动中的以下指标综合考评，去评估衡量测试效率，每项指标都高，自然能够说明一些问题：
1.发现缺陷的质量：
同一个项目组内，我们一般运用测试管理工具TD, 按优先级和严重等级，把每个人的缺陷做成柱状图和饼图，放到一个文档中，邮件发给大家，让组内成员了解自己的工作情况和其他人的工作情况。同时也让开发人员，对每个测试人员的工作，做出评估，供绩效考核时参考。特别是发现非常隐蔽缺陷的测试人员，一定要重赏。
2. 测试的有效性：
一般来说，递交Bug的有效性，体现了测试员是否能够正确理解系统，并发现问题，是否能够发现有效的问题。很多时候，测试人员没有弄准确需求，或者是没搞清楚设计，一旦出现异常，就提交Bug。不是和前面的缺陷相同，重复递交相同类型的缺陷，就是递交无效的Bug，导致后来很多缺陷，都被项目评审时拒绝，既耽误了时间，效率自然不高。
3.测试组员交叉测试，发现漏测问题数量：
经常是这样，一个测试人员测试结束，修复了全部的缺陷。这个时候，测试的模块和测试人员交叉一下，再测试，很有可能又发现很多问题。这样我们可以对测试发现问题数量，进行统计。这样做，就迫使测试人员认真执行每一轮测试，每次测试都不敢懈怠。
4.遗漏到客户缺陷的比例：
一旦版本测试通过，发布给客户以后，客户要对发布的版本进行验收测试。同样会发现一些问题，我们也会对测试过程中发现的Bug分配到每个模块和具体的人。但是，如果缺陷在测试环境中不能重现，只能在实际工作环境中出现，则不属于遗漏给客户的Bug，不计入漏测统计里面。有时候，客户系统在使用中也会发现缺陷，我们同样做好记录。
5.递交的缺陷数量：
在同一个项目组内，每天递交的Bug数量，每周递交的Bug数量，每个版本测试结束，总共递交的Bug数量。最终测试结束，算出每个人递交有效缺陷的百分比。
6.执行用例的数量：
同一天，每个测试人员，执行用例的数量。但是一定要去除那些不能够测试的功能模块，或者是被阻塞的模块，这些一定要考虑到。否则大家意见就大了呢！
7.编写测试文档的速度和质量：
每次编写测试用例时，大家都要编写部分模块的测试用例，我们也可以通过单位时间内编写case的数量、速度和质量，来区分每个人的效率，我觉得也是一种好方法。
8.评审发现问题的效率：
在组织部门内部的case评审时，同一个测试文档的评审，如果提出的修改建议比较多，并且很有参考价值。这样的测试人员，效率应该比较高，得考虑考虑加薪，呵呵。
9.测试工具使用的熟练程度：
当然，一个测试人员，对测试工具的熟练程度越高，使用技巧越强，一般来说，测试的效率就越高。按常理来说，每个人不可能了解全部的自动化测试工具，我们只对常用的测试工具进行考核就可以了，还算人性化吧。并且后面懂得较多的同事，给组内成员集体培训，使大家迅速掌握测试工具的基本使用，这才是我们的真正目的。
10.测试结果的分析水平：
对自动化的测试工具来说，特别是性能测试结束之后，我们要分析部分测试结果，如果你都不熟悉测试工具的分析，何谈效率呢？所以测试结果的分析水平，也可以作为衡量测试效率的一个指标。
如何提高测试效率？
1.首先要有一个合理的详细的测试计划：
没有详细的测试计划，测试部的每个成员都在那儿盲无目的测试，何谈提高测试效率？当然测试计划也不能够太细，太细了，编写测试计划同样浪费时间，做到时可而止。最好是测试任务尽量能细化到测试的功能和测试的case这个级别去监控进度，较为理想。
2.测试尽早介入项目详细了解项目的业务需求，做好测试的前期准备：
目前来说，可能大家都有类似的感受，接触到的大多数的项目，都是测试周期比较短，开发人员耽误了时间，为了不拖延项目进度，留给测试人员做测试的时间都非常紧张。如果项目测试的前期了解业务需求、了解产品属性和准备测试数据不充分，往往测试效率很低，测试时间变长，测试效率急剧下降。
3.对测试项目前景充满信心，调整最佳心态，保持愉悦的工作心情：
一般来说，如果大家认为测试的项目没什么发展前景，当然测试也不会很卖命，测试效率不用说。如果某个测试人员碰到什么不顺心的事，当天的工作效率肯定比平常低。所以，要保证测试效率，测试负责人要察言观色，及时找不开心的下属谈心，了解并帮忙消除部分员工的不良情绪，让员工有更好的心情投入到测试工作中去。
4.提高测试接受的标准，减少测试版本送测次数：
大部分公司的开发人员都有一种惰性，一旦公司成了测试部，他们自己测试时，都不会那么认真，以为有了测试人员，就自己就解放了。很多时候都是调试编译通过，实际上开发人员没有做完整的自测，就拿到测试部进行测试。如果测试部门有严格的测试接受标准，一旦发现有重大问题，立即拒绝测试，送回开发人员修改。可以减少很多次反复测试，重复测试，明显提高了测试效率。
5.测试负责人认真做好测试文档的评审：
测试经理一定要认真做好测试用例的评审，尽量使用较少的测试用例，发现较多的Bug，无疑是最佳提高效率的一种方式。很多时候，经验较少的测试人员在设计测试用例的时候，写了很多的测试用例，测试时几乎没有发现缺陷。还有一种：比如说等价类的测试，只要具备代表性就可以了，如果写了很多测试用例，执行了半天，臃肿的测试用例，未发现任何问题，也很不值。这些主要是靠测试用例评审的时候，测试Leader去把握了。尽量做到在满足需求的情况下，精简测试用例数量，提高测试覆盖率。很多时候，测试人员写好用例就自己测试,根本没人评审,有些地方理解有偏差,测试点没测试到,导致发给客户版本被退回，给公司也会带来巨大经济损失。
6.加强项目组成员的相互沟通工作和项目信息收集工作：
测试工作是一项沟通要求比较高的工作，一般需要同项目经理、产品经理、开发人员、业务人员、客户沟通。很多时候，由于测试介入较晚，测试时间短，测试初期测试人员了解需求不及开发人员，为了迅速熟悉需求，需要项目组成员之间相互培训和沟通。
测试人员为了利于测试工作，平时也需要主动和开发团队沟通项目的进度、项目存在的问题、项目的需求变更等等情况。与团队成员沟通得越充分、对项目的信息收集和把握得越及时、越准确，我们的测试工作才可能做得越顺利，才可能提高测试效率。
7.积极配合开发人员工作，努力赢得开发人员的尊重和支持：
作为测试人员，我们绝不能消极等待或一味埋怨开发人员的不理解和不重视。我们首先需要正视自己、改进自己，通过自身的不断努力让开发人员，真正体会到测试的价值。同时，也需要理解并配合开发人员的工作。只有这样，才能赢得开发人员的支持。互相配合、互相促进，项目成员之间形成良性循环，彼此感情加深了、配合默契了、工作效率和工作质量也就自然提高了。
8.按照项目的大小不同，必要的情况下引入自动化测试工具：
是否引入自动化的测试工具，主要取决于测试的时间长短和测试的轮次。一般来说，测试周期较长、版本升级平凡和回归测试次数较多的项目，引用测试工具可以提高测试效率。如果测试周期较短，本来测试周期只有两三个月，开发测试脚步就要花费大量时间，引入自动化测试工具，用的次数较少，结果得不丧失，劳民伤财，呵呵！
9.测试部门内部成员的工作业绩数据化：
具体的做法如下：每天给每个人分配的任务非常具体，并且随时关注他们的进展情况，完成百分比，不断督促他们。并且，把每个人每天的工作成果（发现缺陷的数量和工作的质量）数据化，通过邮件的形式发给组内的成员，让大家有个比较。大家都有自尊心，看到自己落后，后面就加油赶工，形成一种良好的测试氛围。每周周例会的时候，对表现突出的给予表扬，对每次都比较差的下属，单独谈心，问问具体原因。
10.提高测试人员的专业技能和工作能力：
由于测试技术的不断成熟和完善，许多的新技术陈出不穷，作为测试人员需要不断提高自己的专业技能和工作技能。不断的给自己充电，补充测试理论知识，让自己工作技能力去弥补专业技能的不足。这样，你的工作同样可以做到最棒，效率自然很高。一段时间过去，回过头来一看，自己确实进步不少，没有虚度光阴呀！
只是我个人的想法，希望同行批评指正！！
个人建议
非常赞同17楼的观点，写的很详细也很具体，但是我认为是不是还要加一个“测试进度的S曲线”作为测试效率的一个指标？ lz能否先解释下测试效率指的是什么和个人绩效有关系么？
还是指的在某种统一的前提下所花费的时间长短？
那前提到底是什么？需求xx%覆盖？
不理解这个题目 个人认为不管是对测试人员还是开发人员或者其他什么人员做考核，都要关注的一点就是工作态度，如果能力再强，工作态度不好，做事情三心二意，想干就干，不想干就混日头的话，那这样的人有再高的技能也是徒劳
不能单凭BUG的数量来对开发或测试人员进行考核，应该综合各个方面全盘调控，如果什么事情都量化的话，那这个公司离玩完就不远了，试想想，公司有两个人，一个人工作努力认真提的问题也很多质量也很高，另一个人工作不是很认真，看到人家工作量比较高了就赶紧提几个页面上的或者文字性的问题来充数，一点业务逻辑或其他需要考虑的东西都不考虑，到最后两个人的量化指标是一样的，那这样努力工作的人肯定会心理不平衡，到最好大家都在混日子了。
量化只能消磨大家的斗志、工作的热情和积极性，考核还是要从各个方面处着手，做到公平公正公开
页:
[1]
2
