我们公司正在组建测试部门，对于如何考核测试人员，如何制定考核标准

天地一剑

不知道有没有什么可供参考的

yrhch1

个人建议态度和工作量分开加权：例如工作量60%+工作态度40%
工作量=编写文档+执行测试用例+缺陷报告（可以分两种，一个是在通过测试用例或在测试用例的基础上发现的，编写用例的和执行的同时加权，一人一半；一种是完全不通过测试用例，即个人经验或者灵感迸发找到的，运气也算，这类的可以算作附加值）-用户发现的缺陷（这里指该缺陷有需求但没有编写测试用例的，有测试用例但未发现的，归谁管扣谁，至于无需求无测试用例的具体看吧，要是太隐形也不好找，不是吗？）
工作态度（这个算活动的吧，毕竟涉及到人就容易竞争，组长控制吧）=组员互评+开发组评+组长评

天地一剑

怎么没有人回答

billrub

之前已经有好几个论题都讨论了这个焦点，可以查找一下看一下。

hxf

这个考核标准是很难制定的。我个人认为，应该最后对发布到客户以后，客户对那个模块发现了多少bug来作为对某个测试人员的奖惩。

TestTip

在一个测试人员发现的bug中，有效的bug占的比重也是考核中重要的标准之一。
供参考。







－－－－－－－－－－－－－－
《我在微软做软件测试》在我的个人网站www.TestTip.com

sense

有效BUG的评价标准也很难定，本人也觉得从客户那里返回的BUG来考核测试人员比较好，但是周期太长了，考核起来也不方便，现在也觉得自己公司的考核不是很好，但暂时没想到好的

tessss

搜索

木木妹

这些是我原来用的一些资料，我做的那份，因为换工作再加上家里机器出问题维修给丢了，你看看这些资料对你有用嘛
测试计划合格率（计划的合理性、可执行性）
2、测试用例数以及合格率
3、测试报告质量
4、测试发现的缺陷比率（不是绝对的缺陷数目）
5、漏测问题数（没有被测试到的问题流出去，是影响测试绩效的，但不是很合理，因为有些是黑盒很难测试到的，尤其是分析系统，不是业务系统）
6、测试总结质量以及测试技能提升情况
7、其他（就看主管对你的看法了，比如工作态度啊之类的）
公司施行基于Bug数量的考核（Bug数量占到了个人考核绩效得分的70%），引起了大家不同程度的争议。
     首先，把Bug数量做为考核测试人员水平的杠杆是否合适？什么是软件测试：为了发现程序的错误而执行程序的过程。那么，选择Bug数量去考核无疑是正确的，这点我非常赞同。并不是因为在公司统计公布的测试人员测试出的Bug数量中，我的名字名列前茅就支持这样的政策，实则是有如下原因：
     1、测试出的Bug数量反应了一个人一段时期之内的工作量，一个Bug耗费的工作量围绕着Bug的生命周期主要集中在如下几个方面：发现、交流确认、回归验证、关闭Bug；自然，越多的Bug需要处理，那么工作量越大，一个人的工作量越大，考核得分高也是应该的；
     2、测试出的Bug数量多，从一个侧面反应了一个人的测试水平。为什么同样的质量水平的产品，有的人测试出的Bug数量多，有的人少呢？实则是因为对于需求、设计的理解水平的高低决定了测试人员测试的功能点的覆盖程度不一、深入程度不一。经验老道的测试人员能够统筹全局，找到整个系统的测试重点，然后再逐步深入，挖掘细节问题，直到数据方面的测试，这样的情况下，测试不仅仅是黑盒测试，而是趋于黑白盒之间的灰盒测试，那么自然发现的Bug也就越多了。
     3、Bug数量越多，也反应了一个人工作效率的高低，这点就不多说了。
     那么为什么又存在那么多的争议呢，分析了一下，有如下原因：
     1、职责不分，不管管理人员、自动化测试人员、产品测试人员、项目测试人员都实行一刀切的政策，全部按照Bug数量这个硬指标去执行，自然不大合适；
     2、Bug的数量有了，但是质量如何还是值得商榷；为了追求高的Bug数量，有的人甚至抄袭其他人的测试结果，这样造成众多的重复问题；另外一个问题就是出现很多不是错误的Bug，这些不是错误的Bug不仅仅反应了测试人员的业务能力不高，另外也白白的占用了开发人员的工作量；
     3、再一点，因为追求Bug数量，对于复杂的系统，测试大多都浮于表面，很难深入的测试到数据层面；毕竟一个复杂的数据测试可能要耗费上几天的功夫，但是有这几天的功夫，不如去发现更多的肤浅的问题；对于有责任心的测试人员当然不会这样，可是对于一味迎合考评的人员来说，无疑是个捷径；但是对于系统的质量来讲并没有什么好处；
     所以说考核很难做到绝对的公平，当然如果能在考核的时候，考虑到一些细节的问题，如何使考核政策更加完善才是我们追求的目标.

dujun

下来看看

maxhoo8003

1 搭建一个好的测试环境：比如TD8.0测试管理工具有效管理，追踪缺陷。
2 测试人员的态度：良好的沟通能力是最主要的。缺陷出现了如何和开发人员交流是占测试工作80%
3  能力了解主流的编程语言
4 发现缺陷能力和如何定义缺陷的级别

yuandjing

我之前发过类似的帖子，楼主可以搜一下

jack060828

有一定的道理，接来看看，有机会也提供些资料，

板砖

你是经理可以随便评,有不服的就给他穿小鞋.

zcx2270

我觉得应该多问些关于如何测试一个产品的问题，观察他在测试过程中整体的测试思路，从而决定考核是否通过。毕竟测试最重要的还是想法。

archonwang

感谢。有时间交流下。

dannytest

TD这东西真不错 ,但是不大适合小公司用,还不如用一些开元的 JIRA就不错  我们公司一直在用

hwgjx123

太谢谢了，我正发愁呢！

小草

希望物有所值啊，很多东西其实大家一起研究借鉴，会有一个不错的结果

Nio

原帖由 hxf 于 2005-10-13 17:34 发表
这个考核标准是很难制定的。我个人认为，应该最后对发布到客户以后，客户对那个模块发现了多少bug来作为对某个测试人员的奖惩。

这种说法，我见一次就批判一次！！！
原因？还需要多讲么？总得来讲，出现这种情况，首当其冲的是测试管理上出现了严重问题！！客户发现了测试中没有发现的问题，有可能是测试计划、测试用例中本来就有遗漏，不分青红皂白的拿测试人员开刀，这是一种极不负责任的表现！也是在推卸个人责任！

木木妹

这位说的很有道理，用TD8.0管理更实惠。这个工具的高级使用会让你的管理更加轻松。建议对工作态度做为考核的一部分，不仅仅考核工作效率。个人认为这是一个团队能不断引进新技术新思想的动力。