项目组内部互评表

　　一、　　完成工作量情况

　　A、　　季度内在整个测试组中完成的工作量最高；

　　B、　　季度内在整个测试组中完成的工作量较高（处于中间水平之上）；

　　C、　　季度内在整个测试组中完成的工作量一般（处于中间水平）；

　　D、　　季度内在整个测试组中完成工作量较低（处于中间水平之下）；

　　E、　　季度内在整个测试组中完成工作量最低。

　　二、　　测试过程质量

　　A、　　测试过程质量令人放心, 基本能全部测出一般情况下的Bug外，还能测出隐藏很深的Bug，项目交给他进行测试把关很放心，在整个测试组来说，相对是最好的；

　　B、　　测试过程质量较好, 基本能全部测出一般情况下的Bug，隐藏很深的Bug偶尔能测出，在整个测试组内来说，处于中间水平之上；

　　C、　　测试过程质量一般，能测出大部分一般情况下的Bug，但总觉得欠火候，在整个测试组内来说，处于中间水平；

　　D、　　测试过程质量较差,有些一般情况下的Bug都不能够测出来，或者总是那下某个功能点，在整个测试组内说，处于中间水平之下；

　　E、　　测试过程质量极差, 有些明显的Bug都不能够测试出来，在整个测试组内来说，相对是最差的。

　　说明：

　　指提交功能测试开始到项目最终发布的测试过程质量。有些人测试过程质量很好，总体上能够把基本问题全部揪出来，而且还能够揪出一些隐藏很深的问题（当然，我们不能指望揪出所有的问题）。而且还有很重要的一点，这些人能够很早的把问题发现，而不是等到快最后来发现（不是说快最后的时候发现问题不提）。其实，作为一个开发人员，还是很欢迎测试揪出问题来的，但缺很厌烦快到最后了，才把它揪出来，心里总会想，为什么不早发现呢。而有些人测试过程质量就很差，很多很基本的Bug都测不出来，而且还丢三落四的。搞得最后都提心吊胆的发布系统。

　　其实，测试过程质量，虽然表现在整个开始测试到最终发布的过程，但实际上与前期准备工作还是很有关系的，就像系统实现过程质量与需求和分析设计的质量很有关系一样。测试准备工作做得好，测试用例想的很周到，编写得很全面，而且能够按照测试用例认真逐个执行，再加上实际测试过程的一些功底，测试过程质量就会明显的好。

　　本文出自51Testing软件测试网，感谢会员阿七在每周一问（09-03-02）中的精彩回答。
　　http://bbs.51testing.com/forum-157-1.html

　　三、　　测试用例编写质量

　　A、　　测试用例编写质量很好，编写的内容除少量细节外，一般一次可通过，在整个测试组来说，相对是最好的；

　　B、　　测试用例编写质量较好，编写的内容虽然有些时候通不过，但明显看出，是经过认真思考了的，在整个测试组内来说，处于中间水平之上；

　　C、　　测试用例编写质量一般，虽然由于能力有限，存在比较多的问题，但文档需要描述的各个方面都已经想到了，在整个项目组内来说，处于中间水平；

　　D、　　测试用例编写质量较差，其内问题较多，且需要描述的好多方面，都没有提及。不过经过讨论后，修改的质量很好，在整个项目组内来说，处于中间水平之下；

　　E、　　测试用例编写质量很差，文档只是涉及到了梗概，很多细节都没描述到，讨论后修改的结果也不理想，要修改多次，或者因为别的原因，没有达到要求还是放过去。在整个测试组内来说，是相对最差的。

　　说明：

　　指测试用例提交评审的质量。有些人写文档前想的很周全，文档也写得很仔细，提交出来的文档基本上一遍就可以通过。而有些人写的文档，提交出来讨论，一遍未通过，讨论完了改，改了再讨论，而且很多细节也没有写出来，搞得负责审核的人，最后没办法，就直接改。因为叫当事人改，还不如审核人自己改来得省心。当然，测试用例的编写质量，在测试过程中会反映出来。