ddddddddddddddddddddddddddddddddddddddddddddd

考核，害怕啊。。

看了，才知道

down load

支持一下

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

值得深思...

非常的谢谢。

你说的有道理，但是测试本身就是为了使产品更好，如果为了和开发搞好关系而忽视产品的问题，岂不是本末倒置？
到上市那天产品还是有问题的，到时候让客户发现了这些问题，开发再加班加点的升级。你说是对大家好呢还是对大家不好。

基本指标都出现了，但是有一个问题，就是等级不明显，要是加薪或者升职的话就没有说服力了，毕竟这个表只能表现阶段性的东西，累计就比较麻烦了，不知道楼主有没有更好的方式来解决这一问题！

支持支持啊

可以借鉴,但要做到有点困难.

好东西  顶起来撒

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

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

路过兮~~~~~~~~~~~下载看看

how much experience i need to collect before i could download?

下载了  好好学习一下

不同的公司，不同的方式，但是核心内容都差不多的，支持！！！

测试人员的绩效还是比较困难的

真的不错。可以参考你的缺陷类型定义用到我的工作中了。多谢。