51Testing软件测试论坛

标题: 测试人员绩效评价方法----仅供参考 [打印本页]

作者: szxutao 时间: 2004-10-8 17:33
标题: 测试人员绩效评价方法----仅供参考
测试人员绩效评价方法

[ 本帖最后由 songfun 于 2007-1-9 14:30 编辑 ]

作者: su~ 时间: 2004-10-11 10:34
标题: 谢谢！
路漫漫其修远兮~

作者: lanxincao 时间: 2004-10-13 09:26
吾将上下而求索~~~~~~
测试新手，也没什么人指导，自己慢慢摸索！:p

作者: piao_lingcao 时间: 2004-10-13 09:58
我也一样，只能自己摸索，也不知何时能摸出个头，想找个bug管理工具也难，一会看见某人说这个，一会看见某人说那个，也不知道到底哪个比较好，唉，谁能介绍一个比较好的bug管理工具啊？

作者: szxutao 时间: 2004-10-13 17:17
晕，bug管理工具用sawin啊

作者: ayong401 时间: 2004-10-14 13:58
收藏先!

作者: alian 时间: 2004-10-14 16:53
标题: 绩效评价很难哦

作者: yang 时间: 2004-10-14 17:46
真的不错。可以参考你的缺陷类型定义用到我的工作中了。多谢。

作者: yang 时间: 2004-10-14 17:49

Originally posted by piao_lingcao at 2004-10-13 09:58 AM:
我也一样，只能自己摸索，也不知何时能摸出个头，想找个bug管理工具也难，一会看见某人说这个，一会看见某人说那个，也不知道到底哪个比较好，唉，谁能介绍一个比较好的bug管理工具啊？

免费的用Bugzilla，据说网上可以Down到。当然MI的测试管理工具真的很强，如果有资金可以考虑。个人之见，仅供参考。

作者: zzx_xzz 时间: 2004-10-20 10:16
bug管理工具用td比较好

作者: sunflowers 时间: 2004-11-3 14:16
呵呵，鼓励一下！

作者: saxifrage 时间: 2004-11-3 21:49
标题: 下载了，得下班了，明天一定看。
谢了。

作者: tempuser 时间: 2004-11-19 10:54
好难做到

作者: shanjiyong 时间: 2004-11-25 15:49
慢慢来把

作者: ee鱼 时间: 2004-12-3 13:25
怎么要解压密码？

作者: 天地一剑 时间: 2004-12-24 14:17
还没来得及看

作者: modika 时间: 2004-12-29 23:52
标题: 原帖
原帖 http://blog.csdn.net/testwin/archive/2004/09/02/92980.aspx

www.testwin.cn

作者: baitest 时间: 2005-1-19 20:58
标题: 慢慢适应吧！

作者: 依伊卜舍 时间: 2005-2-18 10:02
一步一个脚印

作者: ougl2004 时间: 2005-3-23 10:51
慢慢来吧，很难的。没有人带，只能自己摸索，慢慢成长。一步一个脚印！！！

作者: 柔柔 时间: 2005-4-8 10:35
把所有的测试工具都精通一下不就知道那个好了,这个也应该不用花很长时间了

作者: vicky_w 时间: 2005-6-27 09:19
不错不错，谢谢

作者: 自得其乐 时间: 2005-6-30 10:13
不错，但是很难执行，对于bug的数量评估和bug的质量是评估工作量太大，还有就是参数值的个数是很难定义，bug的个数与开发提交的产品质量也有关系统，主要是综合因素太多。

作者: 大妮 时间: 2005-8-17 20:12
下了，顶一个...

作者: zig_cui 时间: 2005-10-14 11:30
标题: 国产软件业,任重而道远呀!
什么都是新鲜东东,像一个新生婴儿!

作者: ysmsy 时间: 2006-2-20 12:10
觉得好难啊

作者: 九月属金 时间: 2006-3-16 12:03
这个方法难点不在于技术，而在于管理，比如很多系统崩溃的严重问题谁都会发现，难道谁最先发现就应该算谁的名下吗？

另外，测试的技术跟测出的问题的严重性有时候并不成线性关系，程序一运行就崩溃，这个问题严重吧，但只要是个人就能测出来，就不能以此来给这个测试多加分。

有些大项目，或者是要求很高的项目，例如金融，医疗，航空等等，因为测试时间比较长，到后期能发现的问题越来越少，往往几天才能发现一个bug，不能就此判断测试人员的水平有问题。

所以个人认为还是要结合本公司的实际情况来判断。

作者: shooting 时间: 2006-3-24 10:40
我看不了,为什么呀?

作者: liufu-23 时间: 2006-3-30 10:32
看看有什么可以借鉴的

作者: mstiunicon 时间: 2006-4-12 13:20
标题: 纯粹是胡扯！
如果按照提交的缺陷的数量和质量来考核一个测试人员，必然使开发人员和测试人员的对立更加激烈。测试和开发有着同样目的，就是把一个项目做好，如果按照楼主的考核办法，测试人员就只能拼命提缺陷，不管是否得当。本来开发人员就认为测试人员是来给他的工作来找错的，不会太配合。到最后，测试人员是得到好得绩效了，项目却没有一个成功的。

作者: 天生我才 时间: 2006-4-20 16:21
这是什么啊？看看

作者: informix_hhb 时间: 2006-5-22 13:24
请问这个在实际中能执行下来吗？？

作者: 槛外人 时间: 2006-6-12 15:28
标题: 不同意这样的考核办法.
现在的公司中，测试人员主要还是为项目服务，而不是作为第三方对软件质量进行评估。
这种情况下，应该把测试人员的考核跟项目绑在一起。大家有一个共同的目标，把项目做好。
否则测试人员一味的找bug，找出了很多bug，但是项目最后却是失败了。

作者: szxutao 时间: 2006-6-21 10:30
不要回避数量与质量这个两个指标，楼上说的是有道理的，试问测试人员他本身就是不用来保证项目是否成功的！他对质量负责。能找出很多bug的项目失败的可能性就大，难道为了项目成功而不找出可以找出的bug，让项目所谓的成功，那么今后你认为麻烦的事情是项目成功了呢，还是失败了？

作者: szxutao 时间: 2006-6-21 10:34
不要去回避 bug的数量与质量，试问如果一个能找出很多bug，并且这些bug都是有质量的话，那你是否认为他很优秀，至少这是两个很容易判断的标准吧！测试人员和开发人员的矛盾，不在与测试人员找出太多的bug，而在于对问题的认识和管理。正如大家所说的，测试和开发都是为了保证项目的质量，都是对事不对人的，所以矛盾的产生都是心理问题，思维问题，在我的公司如果那个开发者想不通这个道理而一味潜入这样的误区，那是要拜的，开发人员要有这样一个心态，测试人员的bug是帮组我进步与提高的：）

作者: 槛外人 时间: 2006-6-24 11:13
不用bug的数量来考核，不是说测试人员就不去积极的找bug。这2者是不能等同的。
在一个项目中，bug的数量受到很多因素影响的，包括开发人员的能力和责任心等。
在很多因素都无法量化的时候，你凭什么可以用bug的数量来考核测试人员。
测试管理说到底也是艺术，而不是简单的量化考核。如果什么事情都可以简单衡量的化，任何人都可以做领导了。

对测试人员的考核最大的目的是如何激励他们更好的做好工作，并能随着公司的发展而不断的发展。如果偏离了这个方向，考核是没有任何意义的。

而且如果一味的追求bug 的数量，非常容易造成测试和开发之间的矛盾。这是一个不可回避的问题。

测试人员存在的意义是什么，是为了帮助研发成功，从而实现自己的家者。脱离开这个东西，一切都是空谈a

作者: ytcaicai 时间: 2006-7-20 20:33
标题: 个人看法
九月属金 ,mstiunicon ,槛外人 ,szxutao ,这四个位朋友的说法,我认为都有一定的道理,测试人员的测试效率及质量要进行考核,但是,要结合项目本身的实际情况,如要考虑测试所处的阶段;也要考虑这种考核不能影响项目团队的融洽性,以及项目成员间的配合效率,还有就要考虑测试人员发现的缺陷所需要的技术含量等等.

但总体感觉楼主的测试人员绩效评价方法写的还是很好的,可以作为参考.

作者: 粉色的小猪 时间: 2006-8-4 15:24
还道理，但还得根据实际情况而定。而且很多管理上的问题，还得考虑一个执行力的问题。

作者: zhou610103 时间: 2006-8-7 12:12
标题: 先收藏
先收藏

作者: rlyxx2915 时间: 2006-8-10 18:10
为什么我的附件就是下不了
谁能告诉我附件要多少分数才能下载啊

作者: liliy 时间: 2006-8-16 05:16
没资格评论还。先看看。

作者: nicholas.hl 时间: 2006-8-18 11:43
和测试有关的东西都该知道

作者: lemon_hawk 时间: 2006-8-30 17:18
路在何方

作者: hhup2000 时间: 2006-9-6 13:05
楼主的这份的测试人员绩效考评以bug的数量和质量为评估主要标准，的确可以在一定程度上反映测试人员的工作情况。

但是长期使用会有产生一定的负面影响。比如，假设我是一名测试人员，在项目初期，我发现需求中存在一个业务层面的问题，而且清楚这个将来一定会成为一个比较严重的bug。那么，我是不是应该在这时向项目组反映这个问题呢？？按照楼主的考评标准，我这时反映问题对自己基本毫无好处。这个评估设计文档的时候也会发现（比如transaction完整性，性能等问题）

单从考评文档来看，主要问题是把测试工作列在开发之后，宗所周知，测试应该从项目开始就介入，通过对需求文档、开发设计文档的评估，为开发人员，需求人员，项目经理提供服务。那么对测试人员的评估就决不局限于bug的数量和质量上面。

另外，测试人员report bug的能力也是十分关键，不仅要清楚明白，而且正确定位bug的影响范围。只有你的report正确，项目经理才能正确决定是否有必要fix bug。

作者: 快乐逍遥 时间: 2006-9-8 10:40
藏着先,稍后再学习~~`

作者: randyhe 时间: 2006-9-10 01:30
测试管理说到底也是艺术，而不是简单的量化考核。如果什么事情都可以简单衡量的化，任何人都可以做领导了。

事实上，我们确实需要一个量化。只是比较难而已。

如果觉得bug的数量来考核测试人员不妥的话，那我们就应该想更加妥当的方法。

毕竟这是需要个过程的。

作者: qingcheng1010 时间: 2006-10-14 18:38
仅仅可以参考，衡量的范围还是很全面的。

作者: alice_106 时间: 2006-10-19 16:02
写的不错,不过就我所知目前大部分单位仍是人为主观进行绩效评估的! 如按以上方法来执行估计还是比较有难度的哦!
新手上路---以上是自己的浅见,以后还望大家多多指点!!!

作者: tom_zhang 时间: 2006-12-12 11:26
赞成#39 楼的看法！

作者: renhaiyong 时间: 2007-1-9 16:08
收藏!

作者: magicmen 时间: 2007-1-22 17:43
哎，难啊，最好就是找到一个问题能奖励多少钱，那就舒服了

作者: skynothing 时间: 2007-3-8 16:13
呵呵，测试新手，可以通过这个来测试自己是否合格
我试试先

作者: davids 时间: 2007-4-3 14:49
这篇文档还是有一定的参考性的~
目前还有一个问题就是对测试用例的评判怎么样才有一个比较好的标准,因为大多数情况下可能没有太多的时间来写测试用例~

作者: fox-inv 时间: 2007-4-19 17:14
标题: 回复 #4 piao_lingcao 的帖子
bug管理工具你只需要会一个就OK了！其他的工具是相通的

作者: lsy325 时间: 2007-4-20 09:29
一直就想不明白,测试人员的绩效应怎样评价.
用BUG的数量与严重程序来评价总觉得问题太大.
A和B两个测试员,A的水平好一些,在安排工作时会先安排B做功能的一般性测试,之后再由A接手去做可靠性、容错性这样的测试.
这样去查看每天提交的BUG,B一直都比A提交的多的多,B提交的严重级别的BUG也不会比A的少呀,测试组几个人,每个人的工作不同,怎样去评价每个人的绩效?

作者: lswatchly 时间: 2007-4-21 17:07
呵呵讨论的不错我暂时站反方

作者: yuanxinyi16rain 时间: 2007-4-24 09:17
标题: 回复 #1 szxutao 的帖子
OK

作者: ffhhj 时间: 2007-4-24 11:01
标题: 你的考核方法
大侠,感觉的你的考核方法是拍脑袋出来的,考核起来不容易.能不能量化一点呢.
另外,我们产品/项目的最终目的是满足客户需求,我们其实可以把这方面也考虑到考核方法里去:已发布软件(已经测试)出现重大问题、已发布软件重现之前发现的错误。

作者: 任道远 时间: 2007-4-28 17:44
sdlkfj2

作者: xiaomi1229 时间: 2007-5-11 09:25
标题: 回复 #1 szxutao 的帖子
ddddddddddddddddddddddddddddddddddddddddddddd

作者: wodesen 时间: 2007-5-12 16:11
考核，害怕啊。。

作者: smchaopiao 时间: 2007-5-22 13:48
看了，才知道

作者: gs0521 时间: 2007-5-30 09:18
标题: en
down load

作者: 期待流星 时间: 2007-5-30 09:41
标题: 不错
支持一下

作者: kellow 时间: 2007-6-4 09:50
呵呵,看过大家的谈论,感觉收益非浅
本人认为:
测试人员的评估如同研发人员的评估都是很难加以评测的,但很多公司实际的做法就是以BUG数量的多少来评估测试人员,其实如此做法对于另外以前偏向于测试工具开发的测试人员就不怎么公平了.

作者: yiyi820106 时间: 2007-6-4 15:50
值得深思...

作者: 13421399613 时间: 2007-6-4 17:32
标题: 谢谢
非常的谢谢。

作者: lansechuiyan 时间: 2007-6-5 10:40
标题: 回复 #35 mstiunicon 的帖子
你说的有道理，但是测试本身就是为了使产品更好，如果为了和开发搞好关系而忽视产品的问题，岂不是本末倒置？
到上市那天产品还是有问题的，到时候让客户发现了这些问题，开发再加班加点的升级。你说是对大家好呢还是对大家不好。

作者: lansechuiyan 时间: 2007-6-5 10:45
标题: 回复 #1 szxutao 的帖子
基本指标都出现了，但是有一个问题，就是等级不明显，要是加薪或者升职的话就没有说服力了，毕竟这个表只能表现阶段性的东西，累计就比较麻烦了，不知道楼主有没有更好的方式来解决这一问题！

作者: coletan 时间: 2007-6-6 20:02
支持支持啊

作者: toyfrog 时间: 2007-6-7 13:57
可以借鉴,但要做到有点困难.

作者: dearduck 时间: 2007-6-14 18:15
好东西顶起来撒

作者: glla 时间: 2007-6-15 15:22
我觉得，这个还是有点形式主义了。。
缺陷数，除了和测试人员有关外，还和软件本身有关，不能因为测出BUG的多少来衡量绩效，这毕竟不是生产东西。。
还有一些标准，也很不好评，容易加入主观的因素。比如说，别人的自学钻研能力，这个外人该怎么评？有些东西，你学到不一定马上就会用到，马上显现出它的价值。别人是看不到的。但你不能因此就说他的自学钻研能力不好吧。。。

不过总的来说，还是不错的，比较传统，想的也比较全面，就是具体的实现估计会流于形式。

作者: hoho35 时间: 2007-6-15 16:00
路过兮~~~~~~~~~~~下载看看

作者: zhangchongke 时间: 2007-6-23 21:34
how much experience i need to collect before i could download?

作者: rachel504 时间: 2007-6-23 23:59
下载了好好学习一下

作者: Iolia 时间: 2007-6-24 14:46
标题: 回复 #1 szxutao 的帖子
不同的公司，不同的方式，但是核心内容都差不多的，支持！！！

作者: 博一笑 时间: 2007-6-25 13:41
测试人员的绩效还是比较困难的

作者: vczq 时间: 2007-6-25 15:54
真的不错。可以参考你的缺陷类型定义用到我的工作中了。多谢。

作者: merry3450 时间: 2007-6-28 17:22
标题: 回复 #1 szxutao 的帖子
thank

作者: cyyi 时间: 2007-6-29 10:55
收藏，用户看

作者: jy00274486 时间: 2007-6-29 17:02
记录下我下了

作者: lzj2022 时间: 2007-7-2 16:54
标题: 支持！
正好需要．

作者: whoisangle 时间: 2007-7-3 09:13
谢谢。

作者: ustssk 时间: 2007-7-3 16:12
下载学习中

作者: glyw168 时间: 2007-7-4 09:29
根据公司的实际情况可以，借鉴一部分！

作者: lzj2022 时间: 2007-7-4 09:36
标题: 顶！
正好要用，参考一下！

作者: superzjn 时间: 2007-7-5 14:24
看看怎么样多谢分享

作者: konglingzhen 时间: 2007-7-9 09:57
公司不对测试人员的工作进行评价,自己做就可以了...
而且没有对模块进行划分,工作一起做，功一起领.....我这样也是sdlkfj8

作者: menggaixing 时间: 2007-7-9 17:07
我也一样，只能自己摸索，也不知何时能摸出个头，想找个bug管理工具也难，一会看见某人说这个，一会看见某人说那个，也不知道到底哪个比较好，唉，谁能介绍一个比较好的bug管理工具啊？

作者: helentesting 时间: 2007-7-20 09:28
科学的绩效管理要想做好还真是难，路漫漫.......

作者: bula 时间: 2007-8-1 10:02
谢谢,可是我看不到内容

作者: sandy_jdd 时间: 2007-8-2 13:25
要学的东西真多啊

作者: yiss 时间: 2007-8-3 20:34
标题: 既然下载了，就说几句意见
BUG数目很难作为考核指标，因为BUG可大可小，可以将一个大的BUG分成若干个小BUG，呵呵，既然BUG内容无法有明确的标准，那数量不能作为考核指标，最多只能参考，我们公司曾经试图以BUG数来考核，结果有平时不大填单的人一周内下了几十张BUG单。
BUG质量同时不能作为考核指标，因为质量很难界定，所谓重大不重大，各人看法不同，总不能成立一个专家组来评审吧？
而且各软件模块的质量是不一样的，万一你不幸遇到一个开发的大牛人，没有什么大的问题，那你的考核岂不是很惨，那岂不是大家都要挑低手写的程序来测试。
随便说几句吧，不多写了。

作者: wslo888 时间: 2007-8-6 17:23
还没有走到这一步，但是想提前看看。谢谢

作者: stomry 时间: 2007-8-7 13:11
借鉴借鉴

作者: namibob 时间: 2007-8-8 10:53
谢谢，慢慢学习了

作者: bo流倜傥 时间: 2007-8-9 09:56
正有用！

作者: she_1 时间: 2007-8-10 11:22
看到了，我正需要这样的考核开发人员和测试人员的文档，楼主或者各个兄弟姐妹们还有没有可以借鉴的文档啊sdlkfj2
先谢谢了sdlkfj5

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)