慢慢来吧，很难的。没有人带，只能自己摸索，慢慢成长。一步一个脚印！！！

把所有的测试工具都精通一下不就知道那个好了,这个也应该不用花很长时间了

不错不错，谢谢

不错，但是很难执行，对于bug的数量评估和bug的质量是评估工作量太大，还有就是参数值的个数是很难定义，bug的个数与开发提交的产品质量也有关系统，主要是综合因素太多。

下了，顶一个...

什么都是新鲜东东,像一个新生婴儿!

觉得好难啊

这个方法难点不在于技术，而在于管理，比如很多系统崩溃的严重问题谁都会发现，难道谁最先发现就应该算谁的名下吗？

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

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

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

我看不了,为什么呀?

看看有什么可以借鉴的

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

这是什么啊？看看

请问这个在实际中能执行下来吗？？

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

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

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

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

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

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

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

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

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

还道理，但还得根据实际情况而定。而且很多管理上的问题，还得考虑一个执行力的问题。

先收藏