17楼讲的比较详细，很不错
个人认为，提高效率的同时，还要加上人员淘汰标准：A） 心态不好的人（有明显性格缺陷的人）
B） 工作中耍小聪明的人（将自己的工作推给别人）
C） 不能脚踏实地的人（总是夸夸其谈的人）
D） 隐瞒、欺骗直接领导的人
E） 工作不努力，而且影响其它人员的人
F） 对自己没有清醒认识的
两方面督促比较好。
虽然“爱吃鱼的月亮”讲的挺好，但我还是要说两句
其实个人的效率，“爱吃鱼的月亮”讲的挺好，我觉得是不是也要衡量一下团队的效率，个人效率再高，团队效率不高的话，也不行呀！！ “根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率”，这种方法是很片面的。它的优点是便于统计和分析，缺点是只通过一个方面考核了测试效率等，漏掉了很多其他因素。那么该如何衡量测试人员的测试效率呢，以下给出一些效率计算的建议：
1、测试设计
测试设计的效率应通过三方面衡量。第一，要通过 测试用例数/测试功能点，考核测试设计的覆盖度；第二，要通过 测试用例的条数/编写时间，考核编写效率；第三，测试设计评审时发现的缺陷比例，即 测试用例缺陷数/负责的被评审测试用例总数，比率高则测试设计质量高。
2、测试执行
测试执行效率至少也应通过以下几个方面衡量，这里只提及比较容易执行的考核方法。
第一，缺陷数。
考核缺陷数不应仅仅是缺陷个数，我们在测试执行过程所提的缺陷都是分等级的，这里以ABCD四个等级为例，A可定义为影响系统运行或影响核心模块测试的缺陷，B可定义为影响模块或子模块测试的缺陷和核心功能的缺陷，C可定义为一般功能缺陷，D可定义为建议类缺陷等。那么，我们在统计缺陷数的时候，应根据缺陷等级×相应的基数来计算缺陷总数。比如，缺陷数＝A×1.5＋B×1.3＋C＋D×0.8，这样我们缺陷数就避免了因缺陷数相同而缺陷重要度不同的争议。
第二，测试质量。
测试质量可以通过交叉测试和bug收敛度来考核。项目测试组，可根据测试计划适当的安排交叉测试，通过交叉测试的缺陷来衡量原模块测试人的测试质量。再通过每轮测试的bug数，按模块来衡量bug收敛度，收敛度高，则可侧面判断测试人员的认真程度和效率。如果没有交叉测试，则收敛度低为效率差；如果没有交叉测试，则收敛度低为该模块原测试人员的效率差，而交叉测试人员的效率高。
第三，缺陷分析。
测试中难免会有重复bug和无效bug，根据 有效缺陷数/缺陷总数 来衡量有效bug的比率，这里的缺陷均是ABCD类核算后的数量，比率高者，相对测试质量较高。
第四，客户反馈缺陷。
一般黑盒测试难免会有测试遗漏，根据客户要求和项目大小，一般遗漏缺陷不允许大于2个C类，D类不限。那么我们根据客户反馈的缺陷，分析bug的严重程度，可以侧面体现测试人员的测试质量。
第五，缺陷定位和可读性。
查看缺陷描述和问题定位。如果一个测试人员只会通过页面将现象表达出来，而无法定位这种现象是有什么引起的，或者无法定位该缺陷到底错在何处，那么可以判定测试人员只是做了简单的表面测试，并没有对所发现问题进行分析定位。比如，一般系统都会有报表，那么当测试人员发现报表数据不对时，应明确定位该类报表现在统计的是哪些数据，而正确的结果应该统计哪些数据，不是仅仅一句报表数据错误就over了。
可读性一般都不会有问题，每个测试部都会有缺陷提交的统一规范，正确表达出来还是没问题的。
第六，性能测试。
如果做性能测试，可仔细查看性能测试报告，有没有把客户关注的性能问题，很直观明确的分析，并得出结果反应在报告中。
如何提高测试效率呢？以下给出一些可执行建议。
第一，测试负责人与开发负责人共同对项目进度进行商讨分析，作出合理的测试计划，并在测试执行过程中严格按照测试计划的进度和测试策略进行测试。
第二，测试人员尽早的进入需求理解阶段，充分理解需求文档。
第三，必要时做跟进测试，提高需求理解深度，可间接提高测试执行的效率；跟进测试，即系统测试之前的草稿版测试，需要与开发方沟通，让其协助来执行。跟进测试的目的不是发现bug，而是熟悉系统环境，助于需求理解和测试设计。
第四，尽量避免失败的接收测试。一次版本无法接收，会浪费很多人力和时间，还会影响测试人员的测试热情。
第五，任务分配合理化。测试负责人应根据项目组成员的经验和能力能个人因素，合理的分配测试任务，并将测试任务的模块和时间详细化，这样有助于提高整个项目的测试效率。
第六，测试工作从某种角度看，会很容易掺杂个人主观意见，测试质量也受测试人员的责任感的因素影响，所以，培养良好的测试风格，提高测试人员的责任感，也能间接提高项目的测试效率。
刚更改了几个错别字，见谅。
[ 本帖最后由 sunyh 于 2008-7-28 09:31 编辑 ] 俺来回答一下问题！
首先这个问题其实比较小，问的是“根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率”。而不是说根据系统测试发现的缺陷数量来衡量测试人员的工作效率。
按照我的理解，在系统测试的过程中，主要的工作就是执行已经设计好的测试用例，对被测系统进行测试。目的是在这个阶段尽早地发现尽可能多的defect。所以根据发现缺陷数来衡量测试人员的系统测试效率看起来是一个比较有效而且看起来比较公平的方法。
但是以下的因素会导致这个标准变得不公平，不公平的制度有怎么能追求整体的高效呢？
[*]通常来说，编写测试用例的人不会执行自己的测试用例（这是我在两个美国公司的经验），而大家都知道，决定能否发现系统问题的是测试用例，而不是执行测试用例的人，所以这是一个缺点。[*]一个产品通常有多个开发人员共同开发而成，由于开发人员自身水平的参差不齐以及各个应用模块的难度不一，所以有可能导致某些模块的defect会特别的多，如果其中一个测试员捡到了这个“宝”，那么对其他测试员来说是不公平的。[*]数量只是测试效率的一个方面，另一个方面是质量，如果一个测试员总是能发现界面上的错误而且也只能发现界面上的错误，那么我相信他的测试效率是比那些总能发现一些藏在系统深处的危险的defect的同事要低。[*]如果一味追求数量，那么会导致每个测试员都疯狂地报defect report。这样会导致一连串不好的后果：a. 会有很多重复的defect出现在list里面，降低了测试组在公司的威望。b.测试组内的关系恶化。如果非要用这个指标来衡量测试效率，那么可以从以下方式来改进：
[*]不单只使用发现缺陷数来衡量，而且要加如：a.有效缺陷百分比（避免乱报缺陷）；b.验证缺陷百分比（鼓励大家找严重的缺陷）；c.评估缺陷报告的质量（不能省时间就只写一两句话）[*]单位时间内执行的测试用例数量（这里的用例数是按照一般平均复杂的用例来计算）[*]对测试用例的改造、更新（通常系统做出来以后都会跟原来的需求有所不同）个人认为单单就 系统测试效率 和 测试执行效率 来说，发现缺陷的数量是可以用作衡量指标之一的~如果有其他的一些补充就会比较完善。通常单一的指标都不是很合理的:lol :kiss: :kiss: :kiss:
:) 先来个例子：一个鞋厂的验货员，他的工作是检验一天有多少鞋是合格的。那么衡量他的效率的方法是什么呢？是以他发现了有多少鞋不合格为衡量标准？
不是，而是以他每天检验了多少鞋为标准。有多少鞋不合格不是验货员决定的，而是车间工人决定的。软件的质量好坏不是测试人员决定的，而是开发人
员，测试人员只是验证它的质量。
题目：一套有500个功能点的软件，一个测试人员一天验证了100个功能点，发现了4个BUG，另一个测试人员一天验证了50个功能点，发现了10个BUG，那么，谁的效率高呢？
答：可能大家会说是第二个，其实不然。第一个测试人员的效率才是高的，因为他一天完成了100个功能点的验证。
不管测试人员的用例设计的多么多么好，最终目的是他用用例完成了多功能点的验证工作。
再一题目：A测试人员设计了一套优秀的用例，每个用例能测到5个功能点，B测试人员的用例一次只能测1个功能点。
A一天执行了10个测试用例，测了10*5：50个功能点，B一天执行了100个测试用例，测了100个功能点。
那么，谁的效率高呢？
答案我就不说了，大家都知道。
所以，判断一个测试人员的效率高低，不是他设计的用例多么优秀，也不是他一天执行了多少用例，更不是他发现了多少BUG，而是他一天完成了多少功能点的验证。
如何提高效率：
回归测试的时候用自动化（不用解释了）
公司有良好的标准及管理规范（无规矩不成方圆，没规矩更提不了“速”）
加班（呵呵，最烂的方法）
设计优秀的测试用例（每个都能测5个功能的用例执行100次，哈哈，效率大大的提升啊）
沟通（如果完成测试之后，突然发现和项目经理的意见不一样，那你就准备重测吧，呵呵）
......
......
......
参考的因素太多，举不完，但最终目的是在更短的时间里完成更多的验证，任何能达到这一目的的方法都可考虑。
－－－－－－－－－－－－－－－－－－－－－－
我们需要可统计的客观数据，以下的观点很有参考价值，但不适宜做为衡量标准。
A） 心态不好的人（有明显性格缺陷的人）
B） 工作中耍小聪明的人（将自己的工作推给别人）
C） 不能脚踏实地的人（总是夸夸其谈的人）
D） 隐瞒、欺骗直接领导的人
E） 工作不努力，而且影响其它人员的人
F） 对自己没有清醒认识的
这些都很难统计，太主观了，每个人的评价标准都不一样。
比如：D） 隐瞒、欺骗直接领导的人，你怎么知道他在欺骗领导？他告诉你的？那你没告诉领导是不是也算欺骗领导了？
呵呵，当然这只是举例子，就事论事。
[ 本帖最后由 allanhtt 于 2008-7-28 08:45 编辑 ]
大家看看我的回答
本以为这个问题已经结了，既然还没结，那我就来回答一下。。我的答案地址：http://www.51testing.com/?1592/action_viewspace_itemid_88965.html
敬请光临，谢谢~~~~~~
如何衡量测试效率
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>根据系统测试发现缺陷数来衡量测试人员的系统测试效率，测试执行效率，该衡量方法是否合理，有哪些优、缺点？
如果以该指标来衡量测试效率，那应该从何处着手提高测试效率呢？
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
以系统测试发现缺陷的数量来衡量测试人员的系统测试效率，就好像拿开发人员的代码行数衡量开发人员的开发效率一样，无法客观有效的反映测试人员的工作质量和工作效率。
优点：以BUG数量为基础，有一个明确而清晰的度量标准
缺点：欠缺力度和有效尺度，不能真正反映当前系统的质量状况
>>原因：
1）一个点型的例子，主业务流程和非主业务流程中的一个C类BUG，或是主业务流程中C类BUG和非主业务流程中的A类BUG，或是经常出现的BUG和偶尔出现的BUG。
（对主业务流程的解释：需求提出的，包括明确的或是隐式的，反之则为非主业务流程。可以按此区分问题的优先级）
2）开发质量：测试一个高质量的程序和测试一个低质量程序所发现的BUG的数量肯定不一样
>>引出问题：
1）这两种类型的BUG是否有可比性，是否可以说同时发现的两种C类BUG的测试人员的工作效率就一样高呢？或是发现非主业务流程中A类BUG的测试人员的测试效率要比发现主业务流程中C类BUG的测试效率高呢？或是发现经常出现的BUG的测试效率就高过发现偶尔出现BUG的效率就高呢？
2）对于不同开发质量的程序，以BUG数量做评价标准，谁碰到了开发质量不高的程序，那他的测试效率一定高（如果他是个合格的测试的话 ：））
>>Root Cause：二者没有直接的可比性，需要一个中间变量：权重
1）BUG的权重
2）开发人员的能力
解决方案：
1）针对BUG按照实际的需求进行权重划分（主流程按1.0，非主流程按<1.0，具体的划分方式需要参考以前的测试标准得出一个合理的度量数据）
2）针对BUG对系统的影响程度进行权得划分（系统崩溃：1.5，严重：1.0，一般：0.8等等进行划分）
3）针对开发人员能力，取开发人员的平均开发能力，以此为标准确定BUG发现的权重。大于开发能力的，其BUG的权重就应当>1.0，反之则应<1.0。
4）针对每一个测试版本做相应统计，进行曲线比较，如果是上窜下跳，而且没有理由，测试效率是高是低一目了然
5）加强测试过程控制，必免不合格测试版本的出现，否则得出来的再高的测试效率也是没有价值的。
注：
1）所有的权重评估数据都是在前期数据基础之上进行的，也就是说需要设定一个基础的度量值，随着整体开发和测试的质量的提高，或是整体系统的开发难度和业务熟悉度的变化，这个值是动态变化的。
2）有时也会将测试人员的经验和测试水平加权做评估，个人认为意义不大，因为不同类型的测试人员发现问题的类型，方法和敏感度不尽相同。建议此指标只做为参考。
[ 本帖最后由 rolei 于 2008-7-28 13:45 编辑 ]
强烈要求小鱼版主颁奖后，讨论其它的题目
版主，你办事效率太低了，每次更新文档也很慢，都不及51Testing版主积极，希望以后多向51tesing版主学习。唉，2周都讨论一个问题，太没有劲了，干脆改成两周一问算了。晕倒！！！ 看得我头都痛了!!:Q 个人觉得根据项目发布后的质量来衡量测试效率:lol
谢谢夸奖
原帖由 pepper 于 2008-7-24 15:46 发表 http://bbs.51testing.com/images/common/back.gif非常赞同17楼的观点，写的很详细也很具体，但是我认为是不是还要加一个“测试进度的S曲线”作为测试效率的一个指标？
谢谢夸奖！！！
冠军太牛啦
值得我们测试新人学习学习！！！ 如果控制好Bug Report的质量和Bug等级评判,单单从Bug数量来考察效率,我觉得足矣 在有比较规范化的情况下,还比较好衡量测试效率,在什么都不规范的情况下实在是太难了回复 17# 的帖子
支持
页:
1
[2]
