51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 6790|回复: 16
打印 上一主题 下一主题

[原创] 如何进行BUG的绩效考核?

[复制链接]
  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    跳转到指定楼层
    1#
    发表于 2007-4-4 14:42:31 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    大家好,小弟碰到难题,老大要求对各个研发组进行排名,其中有种排名方法是用BUG进行考核,大概意思是通过BUG的趋势,反映出个研发组在项目实施过程中的工作质量。他仅给出了方向,但没有给出具体办法,需要我写出具体的考核方法。

      目前我们是用TestDirector进行bug的管理,当中也有一些字段可以利用,但我现在没有一个比较好的思路。望大家踊跃发言,帮忙考虑一下,谢谢大家。
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

  • TA的每日心情
    慵懒
    昨天 11:43
  • 签到天数: 3650 天

    连续签到: 102 天

    [LV.Master]测试大本营

    2#
    发表于 2007-4-4 15:01:57 | 只看该作者
    这个东西不好弄。很容易出问题。
    大概想到的一些思路。

    必须规定好缺陷的严重性,最好有一个专人对严重性进行设定。
    每个缺陷都需要确认是否是真正的缺陷。
    不同的严重性进行一定的加权,还有对项目最后剩余的不修改的缺陷,引入加权。
    最后把这些加权数和总缺陷数进行比较,得出质量系数。
    可以通过不同的加权在各个项目组平衡一下。
    引入缺陷处理时间的曲线,可以督促开发尽快处理缺陷。

    呵呵,实行后,恐怕提出很多缺陷的人会被开发bs了,开发也会尽可能的开脱自己的责任。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2007-4-4 17:52:44 | 只看该作者
    楼上提出的思路不错,只怕搞得测试和开发的关系越来越紧张...呵呵
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2015-6-16 14:29
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    4#
     楼主| 发表于 2007-4-5 14:24:00 | 只看该作者
    领导要做这样的工作,也没办法。只好把相关的刑事权限给相关的项目经理了。测试人员不能直接与研发人员打交道。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2007-6-7 10:59:58 | 只看该作者
    我也有同样的问题,不知LZ是如何做的,可否提供一点方法,思路.
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2007-6-14 09:08:22 | 只看该作者
     其实这样做对测试人员也有一点点好处就是,研发人员人提交测试之前,会加强自测.呵呵
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2007-6-14 17:34:19 | 只看该作者

    反对!错误的多少不能直接反映一个开发或测试的好坏的。

    试想一个初级开发,工作仅仅是为代码写注释,那他千行代码出错率为零。这和一个写底层或者写接口技术的高级程序员千行代码出错率为30或40相比,有可比性吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2007-7-30 16:00:47 | 只看该作者
    自己测试可以测试逻辑错误。不过自己测试花的时间和得到的效果不能成比例的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    9#
    发表于 2007-7-31 19:59:00 | 只看该作者
    其实软件缺陷评估的方法相对比较多,从简单的缺陷计数到严格的统计建模,基于缺陷分析的产品质量评估方法主要有以下几种:
    缺陷密度——软件缺陷在规模上的分布
    缺陷率——缺陷在时间上的分布
    整体缺陷清除率
    阶段性缺陷清除率
    缺陷趋势、预期缺陷发现率
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2007-7-31 20:10:48 | 只看该作者

    回复 #1 森林一木 的帖子

    其实软件缺陷评估的方法相对比较多,从简单的缺陷计数到严格的统计建模,基于缺陷分析的产品质量评估方法主要有以下几种:
    缺陷密度——软件缺陷在规模上的分布
    缺陷率——缺陷在时间上的分布
    整体缺陷清除率
    阶段性缺陷清除率
    缺陷趋势、预期缺陷发现率
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2007-8-1 21:52:24 | 只看该作者
    这样的考核不完整啊sdlkfj3
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2007-9-19 10:12:33 | 只看该作者

    测试人员如何进行绩效考核

    发表一下我的看法:我们公司使用辅助测试系统mantis进行BUG的记录(指派、新增、已回归等),所以我们的考核表是:
    1、质量考核部分我们设定的是:新增bug数和已回归bug数,以此计算分值,凡高于既定值加分,凡低于既定值减分;
    2、工作态度(考勤、纪律)
    3、计划管理(有无制订计划、计划是否执行,执行结果如何)
    4、附加部分(在计划之外所做出的贡献)

    附加部分是在总分值之外的分数

    以上只是我的一点小经验,供参考

    评分

    参与人数 1综合技术指数 +5 收起 理由
    luming + 5

    查看全部评分

    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2007-9-20 09:28:04 | 只看该作者
    测试人员与开放人员的关系,很难和谐
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    14#
    发表于 2007-9-30 21:27:39 | 只看该作者
    必须规定好缺陷的严重性,最好有一个专人对严重性进行设定。
    每个缺陷都需要确认是否是真正的缺陷。
    不同的严重性进行一定的加权,还有对项目最后剩余的不修改的缺陷,引入加权。
    最后把这些加权数和总缺陷数进行比较,得出质量系数。
    可以通过不同的加权在各个项目组平衡一下。
    引入缺陷处理时间的曲线,可以督促开发尽快处理缺陷。
    一定要是对事不对人的做法,否则很容易出问题
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2007-10-5 04:17:21 | 只看该作者
    看成果吗~
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2007-10-8 23:28:51 | 只看该作者
    原帖由 闻欣 于 2007-9-30 21:27 发表
    必须规定好缺陷的严重性,最好有一个专人对严重性进行设定。
    每个缺陷都需要确认是否是真正的缺陷。
    不同的严重性进行一定的加权,还有对项目最后剩余的不修改的缺陷,引入加权。
    最后把这些加权数和总缺陷数进行 ...

    想法很好,但是过于复杂,甚至偏学术。有很多地方都会不好操作。
    1.确认每个缺陷真的是缺陷-这里就不好做,有的时候defect和enhancement是很难区分的
    2.严重性加权-加权系数如何划分?如果一个大型产品的不同开发组,就很难办。假设某一个开发组A都是开发核心业务逻辑,另一个开发组B都是界面,那A组的系数永远比B高,相应出了问题受“鞭挞”的概率也一定高,这对A组是不公平的
    3.缺陷处理时间曲线也受很多客观因素干扰,不是developer接到一个defect马上就会处理的,因为他也有开发任务,而且不同priority的缺陷是不一样的,这里也得计算进去。
    总之,这是一个很复杂的问题。我觉得它可以作为一个工程硕士的论文题目,比如《利用加权法进行bug绩效考评》什么的哈哈
    这是个好题目
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    17#
    发表于 2007-10-9 13:51:10 | 只看该作者
    根据BUG数据来统计工作质量,最终的结果就是大家都流于形式,应付而已。
    所以在制定绩效考核的时候除了需要将BUG当做一个指标来实施以外,还需要考虑如:工作质量,工作效率,工作态度等问题。
    将这些指标进行一个合理的加权值,这样看起来就公平很多了。
    看你们公司项目的规模了,都是些大项目而且时间跨度都很长的话还是别这么做了,小项目用BUG统计比较合适。
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-24 04:49 , Processed in 0.085182 second(s), 29 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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