51Testing软件测试论坛

标题: 测试的绩效管理方法之一（转贴） [打印本页]

作者: pcl2004_27 时间: 2004-11-21 01:32
标题: 测试的绩效管理方法之一（转贴）
测试的绩效管理方法之一（转贴）

岗位测评——测试工程师

级别
   总额基本工资岗位技能绩效

一 4500  3600    1000 2600 900
二 4200 3400    1000 2400 800
三 3900 3200    1000 2200 700
四 3700 3000    1000 2000 700
五 3300 2700    1000 1700 600
六 3000 2500    1000 1500 500

技能标准（按ERP系统中的子系统分）
一级：
独立测试过20个以上子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

二级：
独立测试过15-19个子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

三级：
  独立测试过10-14个子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

四级：
独立测试过5-9个子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

五级：
独立测试过3-4个子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

六级：
独立测试过2个以下子系统。经实施人员反馈或实施现场反馈，单个系统或同等工作量下，差错率低于10%。

每级的要求有一项不符合要求，则降为下一级。

除测试任务外，有长期非测试任务的人员可相应上升一个级别。

作者: hongtang 时间: 2004-11-21 11:23
标题: 不错啊~~我收藏了

作者: 云层 时间: 2004-11-21 12:56
标题: 个人认为这样不是很合理
不是子系统测试的多就表示技能高

作者: archonwang 时间: 2004-11-21 16:47
可以这么认为，绩效这个东西放在这里占的比重比较合适，我单位里绩效要达到40％
感觉上就和外面做业务的没有仁任何差别。

作为测试执行来讲，1000的岗位工资算不上高，但也不低。一般来说的话，从事测试工作时间越长，测试接触范围越广则基本工资相对越高。

作者: orange1997orang 时间: 2004-11-27 10:31
评价标准：
1、bug数量：
同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。
2、bug严重程度：
Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应该是极端严重的，对系统造成极大危害的。
3、bug价值：
Bug的双方面评判，对于bug的价值开发人员在另外一个角度上进行评判

以上三个因素的加权平均才能更有效的评价测试人员的绩效！

作者: oscar_wang0721 时间: 2005-5-18 13:13

Originally posted by orange1997orang at 2004-11-27 10:31 AM:
评价标准：
1、bug数量：
同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。
2、bug严重程度：
Bug的严重程度是衡量bug的质量的一个重要因素，好的bu ...

我觉得这个说得很对，对测试工程师来说，主要是Bug数量和质量，当然，质量包括严重程度等问题;)

作者: zys3497 时间: 2005-5-18 15:11
我知道面试的时候该怎么说了，哈哈，顶了

作者: walker_lai 时间: 2006-8-27 17:04
不太合理的说

作者: mtang008 时间: 2007-10-16 10:33
有收获··

作者: bossy 时间: 2007-10-25 11:57

原帖由 orange1997orang 于 2004-11-27 10:31 发表
评价标准：
1、bug数量：
同一个项目组内，提交bug数量的多少是衡量测试人员工作效率的一方面；另一个衡量指标是每人日提交的bug数。
2、bug严重程度：
Bug的严重程度是衡量bug的质量的一个重要因素，好的bug应 ...

这绝对不能作为绩效的评价,原因是:如果一个小组里,一个测试人员所责负测试的功能模块是已经被优化过的话,那么他再怎样努力,所找到的BUG也比较少,而另一个测试人员如果所测试的功能模块是没有优化过的话,那即使他不用用心去测试,也会找到BUG,所以会形成相方不平衡.而如果对两个测试人员或多个测试人员对同一个功能模块一起进行测试而来比较BUG数量的话,那找到的缺陷会出现冗余,而且浪费时间.所以,用BUG的数量来评价绩效是不可行的.

作者: Johnny521 时间: 2007-10-25 12:44

原帖由 bossy 于 2007-10-25 11:57 发表

这绝对不能作为绩效的评价,原因是:如果一个小组里,一个测试人员所责负测试的功能模块是已经被优化过的话,那么他再怎样努力,所找到的BUG也比较少,而另一个测试人员如果所测试的功能模块是没有优化过的话,那即使他 ...

可以取一个权值

作者: mydreams 时间: 2008-1-14 21:16
呵呵，挺有意思的！

作者: jackdymo 时间: 2011-11-4 10:56
mark

作者: jackdymo 时间: 2011-11-4 10:56
mark1

作者: jackdymo 时间: 2011-11-4 10:56
mark2

作者: 愚人 时间: 2011-11-30 20:11
测试的绩效考核是件挺头疼的事情

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