好早以前的哦，都04年了，怎么着也该发展修正一下吧，让BUG成为主要评价标准好像太片面了，容易脱离实际，毕竟有些人是专门做设计，而不做执行的

就是不同意

应该以客户满意度，反馈数量，项目工作量，难度，对团队贡献等综合考虑。

一杆子打死，项目维护谁作？　能力多少和尽力多少有必然联系吗？　让所有能力在考核上下功夫，不在项目上下功夫，呵呵，泄菜

按照我的想法，以团队为考核，如果项目作的不好，小头头拿来问罪。小头头都知道作风，有人绩效很好很差，还没有离职或者出事，他就会先想办法。一级一级，绩效为上，团队建设为中，和客户关系，企业内部关系为基础，胸怀理想为路标，执行力为基础。

呵呵，理想主义分子本人一个

谢谢楼主的方案，很有参考价值啊

谢谢楼主，学习一下

收藏,顶!

这个文档对我来说有很多启发，但是，也有一个很明显的问题：

第一，没有目录
第二，用bug数量衡量测试人员，本身就是存在争议的方法。如果可以单纯的通过bug数量衡量测试人员，那质量差的项目里面的测试人员会比质量好的项目中的测试人员获得的评价要高吧？
第三，lz的文档里面有定性判断的项目，不能量化，所以实施起来很困难。
第四，缺少对测试人员对测试工作控制能力的评价，毕竟测试执行的工作，只是测试工作的一部分。用部分工作去评价整个人，还是值得商榷的事情。

先自評，再通過測試人員對工作的控製能力

谢谢呀，，正需要这个吧

下载了，谢谢

我觉得大家可以集思广益，每人说一点，我们的考评标准就出来了，楼主真的很辛苦，总结了这么长的一份考核文档，我们大家慢慢把他更好的优化不是很好吗

参考一下。

不错,收藏了,谢谢提供

考评不容易做好，我在现在公司半年多了，什么考评都是变化得很快，简直是在练我们的适应能力~~~

挺有用的文档，谢谢了！

先收藏，好好看下去

我现在什么工具都还没用过

为什么我不能下载呢？

找个半天,终于找到我需要的了,谢谢啊.

嗯，珍藏了，这几天狂攻测试相关

文档已破坏，根本就看不了嘛