51Testing软件测试论坛

标题: 我们公司正在组建测试部门，对于如何考核测试人员，如何制定考核标准 [打印本页]

作者: 天地一剑 时间: 2004-12-24 13:50
标题: 我们公司正在组建测试部门，对于如何考核测试人员，如何制定考核标准
不知道有没有什么可供参考的

作者: 天地一剑 时间: 2005-1-11 12:23
怎么没有人回答

作者: billrub 时间: 2005-1-12 12:18
之前已经有好几个论题都讨论了这个焦点，可以查找一下看一下。

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

作者: TestTip 时间: 2005-10-19 08:46
在一个测试人员发现的bug中，有效的bug占的比重也是考核中重要的标准之一。
供参考。

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

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

作者: tessss 时间: 2007-10-20 23:19
搜索

作者: 木木妹 时间: 2007-12-16 22:54
标题: 我有一些资料
这些是我原来用的一些资料，我做的那份，因为换工作再加上家里机器出问题维修给丢了，你看看这些资料对你有用嘛
测试计划合格率（计划的合理性、可执行性）
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 时间: 2007-12-19 10:53
下来看看

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

作者: yuandjing 时间: 2007-12-19 13:15
我之前发过类似的帖子，楼主可以搜一下

作者: jack060828 时间: 2007-12-21 09:55
标题: 有一定的道理，接来看看，有机会也提供些资料。谢谢楼上的兄弟
有一定的道理，接来看看，有机会也提供些资料，

作者: 板砖 时间: 2007-12-21 10:00
你是经理可以随便评,有不服的就给他穿小鞋.

作者: zcx2270 时间: 2007-12-26 23:31
标题: 测试考核
我觉得应该多问些关于如何测试一个产品的问题，观察他在测试过程中整体的测试思路，从而决定考核是否通过。毕竟测试最重要的还是想法。

作者: archonwang 时间: 2008-1-4 16:16
标题: 回复 8# 的帖子
感谢。有时间交流下。

作者: dannytest 时间: 2008-1-6 17:07
TD这东西真不错 ,但是不大适合小公司用,还不如用一些开元的 JIRA就不错我们公司一直在用

作者: hwgjx123 时间: 2008-1-18 13:41
标题: 3KS
太谢谢了，我正发愁呢！

作者: 小草 时间: 2008-1-21 09:56
希望物有所值啊，很多东西其实大家一起研究借鉴，会有一个不错的结果

作者: Nio 时间: 2008-1-21 12:26

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

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

作者: 木木妹 时间: 2008-1-30 11:55
标题: 回复 10# 的帖子
这位说的很有道理，用TD8.0管理更实惠。这个工具的高级使用会让你的管理更加轻松。建议对工作态度做为考核的一部分，不仅仅考核工作效率。个人认为这是一个团队能不断引进新技术新思想的动力。

作者: log_1 时间: 2008-2-4 14:45
也不能完全按照BUG的数量来衡量一个测试人员的工作效率，众所周知，开发人员能力水平各不相同，反映到测试人员那就会出现有的发现BUG数量多，有的少了，这样很容易打消测试人员工作的积极性，我觉得应该从个人的工作态度上，提交的报告的质量上，对缺陷的理解和与开发人员的沟通上来衡量要好些。

作者: aniu_86 时间: 2008-4-29 17:56
下载下来看了

作者: luoj_2005 时间: 2008-6-4 15:21
测试人员的考核，确实是个难题。
这两天我在论坛上搜了一下，也是众说纷纭。。。。没有一定大家一致认可并可行的标准。

作者: archonwang 时间: 2008-6-5 10:08
我做了一份，鉴于指标的差异，把部分内容处理掉了。希望对大家有帮助。

如果你有什么建议或意见，请和我联系。谢谢。

[ 本帖最后由 archonwang 于 2008-6-5 11:36 编辑 ]

作者: archonwang 时间: 2008-6-5 11:33
上传附件，拿来卖点M。

解锁密码：qazwsxedcrfv

作者: wang006 时间: 2008-7-11 10:17
多谢分享，先下来看看！！

作者: 三只熊 时间: 2008-7-12 09:16
太感谢了，我正需要这东西，谢谢！

作者: 三只熊 时间: 2008-7-12 09:18
谢谢！

作者: tester0002 时间: 2008-8-6 11:31
最烦的就是这样的下载还要付费的，尤其是版主提供的东西还需要付费，你都已经是斑竹了，还要收费，收那么多钱干吗

作者: Tesherlock 时间: 2008-8-12 21:13
支持楼上的

知识经验要GX，这样中国软件业才能发展，才能长江后浪推前浪。。。

作者: 牵着蚂蚁散步 时间: 2008-8-19 15:13
需要付费

作者: mildshark 时间: 2008-8-19 15:34
那确实，版主还收费啊，用来干嘛啊？钱多了影响了走路速度啊！

作者: ruanyongjie 时间: 2008-8-19 15:43
标题: 还收什么费呢,我下下来转发
还收什么费呢,我下下来转发

作者: 成长的小咪 时间: 2008-8-21 22:53
我觉得还是结合BUG的数量和质量来考量更加科学一些~

作者: xiaodnilin 时间: 2008-9-1 17:56
多谢共享了.

作者: 冰清 时间: 2008-9-2 11:02
希望花钱的东西物有所值！

作者: blinkday 时间: 2008-9-4 15:40
考核方向无外乎三大项：
1、工作态度
2、测试执行能力
3、文档编写能力

关键是如何考核2、3

作者: elpoper 时间: 2008-10-10 15:09
不是吧！！！？？？
提供下载收费的东西，竟然还有密码保护？？？？
什么意思啊~？

作者: geral123 时间: 2008-10-10 15:13
晕密码是什么啊？？？？？？

作者: 87117899 时间: 2009-1-16 22:41
买了7点，值了

作者: 乐飞扬 时间: 2009-2-11 14:27
非常感谢木木妹提供的支持，学习中。

作者: a_lzf 时间: 2009-2-16 16:17
我也不知道要那么多分有什么用，感谢上面免费共享的兄弟

作者: philosophy 时间: 2009-2-17 11:20
浏览浏览

作者: jenvee 时间: 2009-2-17 18:20
标题: 回复 1# 的帖子
你们公司在西安吗？
我可以实习下吗？
测友报到

作者: jump_fish 时间: 2009-4-17 09:48
谢谢分享

作者: wang006 时间: 2009-5-22 23:22
贵族法则

作者: microsys 时间: 2009-8-10 15:24
谢谢几位的分享

作者: yychenyuan 时间: 2010-3-23 10:15
谢谢各位分享，学习了~

作者: lanytang 时间: 2010-4-3 15:41
希望物有所值

作者: hijack007 时间: 2010-4-7 09:36
标题: 回复 8# 的帖子
这东西还要钱啊

作者: zyszys001 时间: 2010-4-7 15:01
bug数量来衡量很不科学，对于一个测试熟练人员来说，要把一个bug分解成多个bug是很容易的事，我们公司就出现过太小儿科了。指标有多少就能给出多少。这项基本都是满分。

作者: 我们的爱 时间: 2010-5-4 16:14
标题: 回复 21# 的帖子
这几点目前是我们考核的重点，但我还是希望能够更客观一些，考核能够量化是我觉得比较理想的，不过真的不容易做到量化

作者: ymyfox 时间: 2010-5-6 10:07

难题啊！！尤其是对于分工的测试部门，有的同事只跑用例，有的同事又写又跑，就更难

作者: fish00 时间: 2010-9-28 23:05
我自己之前也做了一份考核标准，不过有些地方没有25#的详细，学习了

作者: ben.gao 时间: 2010-10-8 14:06
谢谢资料不错。

作者: testjhb 时间: 2010-10-11 16:43
回复 1# 天地一剑

你可以参考一些资料然后自己写，我就是这么做的。没有固定的标准

作者: msnshow 时间: 2010-10-11 22:14
目前没有哪家公司有比较好的对测试人员工作考核的标准

作者: xiyufenfei 时间: 2010-10-15 15:28
下了看看了不错的

作者: feigoliu 时间: 2010-10-19 11:20
笨蛋了，下了付费的

作者: crazymartin 时间: 2010-10-19 11:22
这种东西太难去评定了。

作者: 圣西罗 时间: 2010-10-19 12:41
主要还是看发现bug的质量和数量
还有就是产品发布后出现的BUG量
还有就是测试规范流程是否落到实处等等
当然还有测试自身的能力
是混饭吃还是自身能力在不断提高
很多评定一般测试经理都会做出报告的

作者: angel_tianyq 时间: 2010-11-22 11:41
为什么要钱呢？如果这个钱能换来一包方便面，我完全赞成要钱。但是这个又不是真的钱，为什么还这么麻烦哪呢？

作者: liqinsenden 时间: 2011-1-7 09:18
回复 34# ruanyongjie

好人啊，我看到你着的时候后悔下了前面的

作者: Yr-Test 时间: 2011-1-7 22:23
这个问题太难.无论怎么做都或多或少有不公平的地方

作者: lagula800 时间: 2011-1-11 15:43
好像很不错

作者: polly12052000 时间: 2011-1-13 09:20
我也觉得公司的考核制度有待完善。

作者: 长天一笑 时间: 2011-1-23 11:05
回复 4# hxf

你这个方法很不合适只能算辅助标准，怎能以bug的多少来定呢？

作者: ericzhou2009 时间: 2011-1-26 10:17
下来看看

作者: violabai 时间: 2011-4-8 13:59
下来看看

作者: yaoerling 时间: 2011-4-11 12:06
先下了，一会儿好好看看，谢谢

作者: y_test 时间: 2011-4-12 12:38
建立一个完成测试体系，根据具体的要求去规定，对软件熟悉程度，对BUG理解的深度等等

作者: ff411 时间: 2011-4-14 11:39
希望物有所值啊，很多东西其实大家一起研究借鉴，会有一个不错的结果

作者: caihongmei 时间: 2011-4-19 22:16
考核标准不能按照BUG数量

作者: 479898729 时间: 2011-4-20 11:45
收藏了，回点血...

作者: senciya 时间: 2011-5-26 17:08
刚才领导要求出个测试人员的绩效考核标准，希望帖子的内容有用。

作者: shttang 时间: 2011-6-21 17:06
谢谢，收藏了

作者: shttang 时间: 2011-6-21 17:12
谢谢，收藏了

作者: 酸酸咸咸 时间: 2011-8-1 15:36
哎，为啥先下了付费的，才看到不要钱的。。。

作者: 酸酸咸咸 时间: 2011-8-1 15:37
肉疼啊

作者: wacos3gnss 时间: 2011-8-1 16:23
自己认为，测试工作还是技术工作，他的考核很难量化。

因为项目不同，质量不一样，发现的问题也不相同。

关键是什么人去测试，是很关键的元素。而人的认识，有很多不能量化的元素。

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

作者: gaichifanle 时间: 2011-8-14 15:32
说的不错，下来看看哈

作者: gshb 时间: 2011-8-25 16:29
先买了希望有用值

作者: jlayoo 时间: 2011-8-29 15:42
本帖最后由 jlayoo 于 2011-8-29 15:49 编辑

新组建的测试部门与开发部门其实就形成了一对矛盾关系，技术上的考核都比较简单，缺陷率，通过率什么都是easy的，我觉得关键是要理顺部门和部门之间的职责利益关系，我来那几个我们目前发现的问题大家一起讨论：
1、A开发部门开发了1.0版本，测试部门测试后，用户改了一个需求，版本改为1.1，这事测试部门介入么？如何介入
2、开发部门为了提高效率，1个月内就开发了**系统，但是相应的需求、设计、操作手册都没有，而且留给测试部门测试的时间只有1周（事情在成熟的中国软件公司也经常发生），该怎么做。
3、测试出来的bug，测试部门跟踪bug是如何引入的么？做不做类似PDCA的质量工作，做了，测试部门又要向老板加人，老板想NND你们天天要我加人还没出成果。不做吧，今天测出一个Bug，明天换一个项目，还是这个类型的Bug，测试工作就没有成就感，两难。
4、测试出来的Bug,开发部门不认怎么办，不可能大事小事都找老板
5、上线后，用户发现了bug，算谁的责任
6、上线后，用户发现了bug，老板把测试主管骂了一通，后来调查，上线的版本和被测得版本不一样，是不是觉得很冤枉？
。。。。还有很多很多

作者: 51minmin 时间: 2011-8-30 11:51
..

作者: cojy 时间: 2011-9-1 17:35
受益非浅

作者: yinbing.2009 时间: 2011-9-5 22:31
学习了。。。

作者: icebelle 时间: 2014-8-4 15:16
密码是多少啊？晕

作者: auto_tester 时间: 2014-8-18 11:50
up

作者: htyu 时间: 2014-9-8 22:04
谢谢ruanyongjie分享

作者: Miss_love 时间: 2014-9-9 07:22
1.肯定要介入
2.多沟通，说明时间短存在的风险。
3.bug管理工具
4.根据需求
5.首要责任是测试。

作者: l554050110 时间: 2015-3-25 13:45
回帖拿分

作者: wxjshuyi 时间: 2015-4-9 14:20
很难有一个确切的标准去衡量

作者: samjohty 时间: 2015-8-12 09:48
购买了，希望有用

作者: Hannaa 时间: 2015-9-24 16:16
觉得模板不错，值得参考。谢谢楼主天地一剑以及ruanyongjie。

作者: nancy870918 时间: 2015-12-15 10:58
学习

作者: nancy870918 时间: 2015-12-15 11:13
谢谢分享哇

作者: apple101 时间: 2016-2-19 14:09
学习下

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)