软件测试人员的绩效考核如何开展.docVIP

软件测试人员的绩效考核如何开展？ 发布时间: 2009-6-30 14:32 ?? 作者: 阿七 ?? 来源: 51Testing论坛 字体:? 小? 中? 大? | 上一篇 下一篇 | 打印? | 我要投稿? | 推荐标签： 测试管理 　项目组内部互评表 　　一、　　完成工作量情况 　　A、　　季度内在整个测试组中完成的工作量最高； 　　B、　　季度内在整个测试组中完成的工作量较高（处于中间水平之上）； 　　C、　　季度内在整个测试组中完成的工作量一般（处于中间水平）； 　　D、　　季度内在整个测试组中完成工作量较低（处于中间水平之下）； 　　E、　　季度内在整个测试组中完成工作量最低。 　　二、　　测试过程质量 　　A、　　测试过程质量令人放心, 基本能全部测出一般情况下的Bug外，还能测出隐藏很深的Bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的； 　　B、　　测试过程质量较好, 基本能全部测出一般情况下的Bug，隐藏很深的Bug偶尔能测出，在整个测试组内来说，处于中间水平之上； 　　C、　　测试过程质量一般，能测出大部分一般情况下的Bug，但总觉得欠火候，在整个测试组内来说，处于中间水平； 　　D、　　测试过程质量较差,有些一般情况下的Bug都不能够测出来，或者总是那下某个功能点，在整个测试组内说，处于中间水平之下； 　　E、　　测试过程质量极差, 有些明显的Bug都不能够测试出来，在整个测试组内来说，相对是最差的。 　　说明： 　　指提交功能测试开始到项目最终发布的测试过程质量。有些人测试过程质量很好，总体上能够把基本问题全部揪出来，而且还能够揪出一些隐藏很深的问题（当然，我们不能指望揪出所有的问题）。而且还有很重要的一点，这些人能够很早的把问题发现，而不是等到快最后来发现（不是说快最后的时候发现问题不提）。其实，作为一个开发人员，还是很欢迎测试揪出问题来的，但缺很厌烦快到最后了，才把它揪出来，心里总会想，为什么不早发现呢。而有些人测试过程质量就很差，很多很基本的Bug都测不出来，而且还丢三落四的。搞得最后都提心吊胆的发布系统。 　　其实，测试过程质量，虽然表现在整个开始测试到最终发布的过程，但实际上与前期准备工作还是很有关系的，就像系统实现过程质量与需求和分析设计的质量很有关系一样。测试准备工作做得好，测试用例想的很周到，编写得很全面，而且能够按照测试用例认真逐个执行，再加上实际测试过程的一些功底，测试过程质量就会明显的好。 　　本文出自51Testing软件测试网，感谢会员阿七在每周一问（09-03-02）中的精彩回答。　　/forum-157-1.html 　　三、　　测试用例编写质量 　　A、　　测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的； 　　B、　　测试用例编写质量较好，编写的内容虽然有些时候通不过，但明显看出，是经过认真思考了的，在整个测试组内来说，处于中间水平之上； 　　C、　　测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平； 　　D、　　测试用例编写质量较差，其内问题较多，且需要描述的好多方面，都没有提及。不过经过讨论后，修改的质量很好，在整个项目组内来说，处于中间水平之下； 　　E、　　测试用例编写质量很差，文档只是涉及到了梗概，很多细节都没描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去。在整个测试组内来说，是相对最差的。 　　说明： 　　指测试用例提交评审的质量。有些人写文档前想的很周全，文档也写得很仔细，提交出来的文档基本上一遍就可以通过。而有些人写的文档，提交出来讨论，一遍未通过，讨论完了改，改了再讨论，而且很多细节也没有写出来，搞得负责审核的人，最后没办法，就直接改。因为叫当事人改，还不如审核人自己改来得省心。当然，测试用例的编写质量，在测试过程中会反映出来。 项目组自评表 评价指标 典型行为或事件举例（参照标准） 自评得分 自评说明 上级评分 上级说明 最终得分 严格认真 （1分）由于不严格不认真，导致工作出现了疏漏，且没有及时补救； （2分）工作出现了问题，但能够积极补救，不推卸责任； （3分）按本岗位工作要求做，没有出现工作疏漏； （4分）发现他人的工作疏漏，告知对方，并协助其补救； （5分）严格认真地履行岗位职责，发现隐患，并预先采取措施，避免问题的发生。 ? ? ? ? ? 主动高效 （1分）被动执行上级安排的工作，遇到困难被动等待，对工作中的问题视而不见； （2分）反应工作中的困难和问题，但没有改进建议；——至少没有主动去思考问题， （3分）主动调动各方面资源，以达成目标； （4分