测试人员如何给予合理的考核呢？

很老的帖子了，2005年的，在csdn上的讨论，想看讨论的在http://topic.csdn.net/t/20050224/19/3804392.html，下面的只是我自己的看法。

        csdn论坛上，有人问如何考核测试人员，我回了几个帖子，下面就是我回帖的内容，可以代表我对此事的一些看法。
         一： 测试人员的工作评价比较的难办，因为测试人员没有具体的工作产品产出。
        测试人员一般做的也就是测试用例的编写和测试缺陷的提交。而这些可以说都不是看技术，而且看职业道德。所以我更多的认为，测试人员最重要的是责任心，是想 做测试而不是开发什么的。一个测试人员提出1个问题或提出10个，对软件最终的质量影响可能并不像大家想的那么严重。 如果真的要考核，只能从工作产品考核，提交的缺陷不可能做为考核的目标，因为分配的模块、测试人员的视角、开发人员的技术差异等都可能会造成相当大的振 荡。所以通常都是从测试用例的角度来进行评价。 这样可以换个角度来说关于测试用例。
        测试用例可以说是最变幻莫测的东西，因为至今没有一个严格的标准和理论来阐示测试用例的编写（记住，是测试用例， 不是别的什么）。而且测试是软件工程收尾的工作，很难有大的时间和精力去编写详细的测试用例，但简略的用例根本用不上，只能提供一个大概的思路。并不合适考核的条件和标准。 所以真的想考核，可以，把你们单位的各种关系理顺，完全按照软件工程的方式一点一点的来（RUP，CMM等都可以，因为里面的工作都很容易度量），如果不是按照这样，凭空的说考核测试人员，还不如经理直接拍脑门决定好了。
         二： 上面说的多，但中心只有一个：想考核，就必须有一个可以比较的标准，所以首先要想好自己的公司是否存在这么一个东西。如果没有，还是不要考核好了。 用bug数考核测试人员，就像用代码行数考核程序员一样可笑。
        三： 现在别说测试人员，就是程序员又有几个公司可以做到让大家都满意的考核？
         测试应该可以说都是在摸着石头过河，有理论，但实际很难做。 所以我一再强调测试人员的责任心，因为测试工作本身几乎无法度量，就像你写的，做一个小时和做8个小时从工作成果上并不能很好的体现出来。 为什么没几个愿意做测试，因为测试即幸苦又无聊，工资也比较少，成果还总被忽视。 其实谁做的多少、好坏，大家心里都有杆秤，只要在奖惩的时候，经理能做到一碗水端平，即使没有实际的比较标准，大家也不会过多的说什么。 管理对的是人，不是机器，不要妄图制定一个完美的标准，即使有，还会有人不服气的。 只要心中无愧，做什么随便让别人去说好了。
        四： 前两天才看到有人在讨论测试用例写的时机，觉得很有道理。
        如果按照标准的软件流程，测试人员可以参与到需求、设计阶段，测试用例当然比较的容易写。 但现在更多的情况，是程序开发完毕了，才交给测试人员，这样如果写用例，一是时间的问题，二是对程序不一定熟悉。所以说真的，写测试用例有些不和适宜。 而最常见的是测试完毕后补测试用例（嗯，怎么和程序员一样了，鄙视自己和大家，哈哈），这样一般都是为了应付上面和客户用的，只能说是一个总结，因为问题都找出来了，自然容易按照问题写用例，可以比较的完美。 所以我建议写测试思路，特别是有多业务流程的时候，这样做不容易遗漏。
         至于那种白痴照着做都可以发现问题的测试用例，反正我们是没有这个时间和精力，而且很多的时候，觉得测试都是一门艺术（再鄙视自己一次），发现问题更多是直觉（也许是错误的操作），这些都是用例无法表达的。 如果真要写，可以写一个简单的，随着测试的展开，对程序的熟悉认识再逐渐的补充。这样测试的差不多了，用例也基本写好了。 测试用例其实最难掌握的就是一个度，写到多详细，而这一般和测试时间呈线性关系。