51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 9500|回复: 15
打印 上一主题 下一主题

测试的绩效管理方法之一(转贴)

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2004-11-21 01:32:26 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
测试的绩效管理方法之一(转贴)

岗位测评——测试工程师

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

一   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%。




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

除测试任务外,有长期非测试任务的人员可相应上升一个级别。
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏

该用户从未签到

2#
发表于 2004-11-21 11:23:42 | 只看该作者

不错啊~~我收藏了

回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2004-11-21 12:56:00 | 只看该作者

个人认为这样不是很合理

不是子系统测试的多就表示技能高
回复 支持 反对

使用道具 举报

  • TA的每日心情
    奋斗
    2018-2-28 18:04
  • 签到天数: 40 天

    连续签到: 1 天

    [LV.5]测试团长

    4#
    发表于 2004-11-21 16:47:53 | 只看该作者
    可以这么认为,绩效这个东西放在这里占的比重比较合适,我单位里绩效要达到40%
    感觉上就和外面做业务的没有仁任何差别。

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

    使用道具 举报

    该用户从未签到

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

    以上三个因素的加权平均才能更有效的评价测试人员的绩效!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2005-5-18 13:13:05 | 只看该作者
    Originally posted by orange1997orang at 2004-11-27 10:31 AM:
    评价标准:
    1、bug数量:
    同一个项目组内,提交bug数量的多少是衡量测试人员工作效率的一方面;另一个衡量指标是每人日提交的bug数。
    2、bug严重程度:
    Bug的严重程度是衡量bug的质量的一个重要因素,好的bu ...



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

    使用道具 举报

    该用户从未签到

    7#
    发表于 2005-5-18 15:11:34 | 只看该作者
    我知道面试的时候该怎么说了,哈哈,顶了
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2006-8-27 17:04:17 | 只看该作者
    不太合理的说
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2016-11-9 09:38
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2007-10-16 10:33:30 | 只看该作者
    有收获··
    回复 支持 反对

    使用道具 举报

    该用户从未签到

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


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

    使用道具 举报

    该用户从未签到

    11#
    发表于 2007-10-25 12:44:43 | 只看该作者
    原帖由 bossy 于 2007-10-25 11:57 发表


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



    可以取一个权值
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2008-1-14 21:16:01 | 只看该作者
    呵呵,挺有意思的!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2011-11-4 10:56:12 | 只看该作者
    mark
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2011-11-4 10:56:21 | 只看该作者
    mark1
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2011-11-4 10:56:38 | 只看该作者
    mark2
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2011-11-30 20:11:39 | 只看该作者
    测试的绩效考核是件挺头疼的事情
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-27 14:05 , Processed in 0.073979 second(s), 27 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表