51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

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

[讨论] 一个面试题:如果让你去考核软件测试人员的KPI,你该如何去考核?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2012-8-10 16:40:11 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
BUG的数量去考核呢,显然不够,大家都说说有哪些考核指标?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

推荐
发表于 2012-8-11 13:09:19 | 只看该作者
测试案例编写数,测试案例质量(覆盖BUG率),发现BUG数;当然最重要的是上线质量,所负责模块有无生产遗漏BUG。另外就是日常工作的表现,偏行政管理类的。潜水许久,第一次回帖,紧张一米
回复 支持 1 反对 0

使用道具 举报

  • TA的每日心情
    奋斗
    2022-5-8 19:23
  • 签到天数: 137 天

    连续签到: 1 天

    [LV.7]测试师长

    2#
    发表于 2012-8-10 17:44:17 | 只看该作者
    测试人员的考核得从多方面来,只是从BUG数肯定是不行的
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    3#
    发表于 2012-8-11 12:50:16 | 只看该作者
    编写文档的能力、质量等
    平常表现
    。。。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2012-8-11 13:14:18 | 只看该作者
    持续改进类项目,已经上线3年,测试人员换了一波接一波,生产上总会反馈一些系统内隐藏许久的历史遗留问题,对于这种现象该如何规避?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    6#
    发表于 2012-8-13 13:53:52 | 只看该作者
    测试人员的bug数量是一个方面,还要对报的bug数量进行具体的分享,修复率、严重程度、bug描述等,测试用例的执行程度,和开发人员的沟通!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2012-8-13 14:26:21 | 只看该作者
    对于测试过程的改进建议。
    测试报告中的测试结果分析能力。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    8#
    发表于 2012-8-13 15:46:59 | 只看该作者
    发现有效BUG数,是否遗漏重大严重的BUG;测试计划、测试用例、测试报告的文档编辑能力;对测试需求是否理解全面、透彻;与开发人员之间的沟通,是否能积极和开发人员沟通,保证BUG修改高效率。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-5-22 10:32
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2012-8-13 16:51:44 | 只看该作者
    同意前面所说,对于测试人员的KPI考核,bug数量只是一个小部分,bug质量、沟通能力、对缺陷的敏感程度、测试流程的理解和改进、测试文档的编写,以及测试结果的分析等等,这些都是考核测试人员的指标
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2012-8-13 17:48:46 | 只看该作者
    漏测率,bug有效性,bug的fix比例,测试效率(时间、进度、质量),态度,沟通的主动性和有效性
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    11#
    发表于 2012-8-13 17:49:51 | 只看该作者
    用例的覆盖率,用例的执行率,测试报告的含金量
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2012-8-13 17:49:58 | 只看该作者
    这些足以。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    13#
    发表于 2012-8-17 14:29:22 | 只看该作者
    以上说的都漏掉了最重要的:重要的是产品整体质量、性能、可用性的提高,应该从单元测试、集成测试、系统测试、验收测试各个阶段分析bug的数量和严重程度进行分析对比,当然是单元测试发现的bug越多越好,越到后期发现的bug就越少,bug的严重程度相对也降低,当然系统测试报告同行评审也重要
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    郁闷
    2016-6-2 16:41
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    14#
    发表于 2012-8-20 13:44:41 | 只看该作者
    测试用例的覆盖率、上线后的bug反馈、测试产出的质量等方面去考虑
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    15#
    发表于 2012-8-20 15:28:46 | 只看该作者
    我们是客户直接考核的,所以,产品上线后的质量很重要,其次还有沟通啊,文档的编写能力,感觉这个人能力怎么样等等,BUG的数量貌似不是很重要的~仅供参考啦
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    16#
    发表于 2012-8-21 11:58:54 | 只看该作者
    BUG数量(对BUG严重等级进行加权*数量),测试用例覆盖率(执行测试用例发现的BUG数量/发现的BUG总数),发现BUG的效率(每小时平均发现BUG的数量),缺陷的逃逸率(客户发现的BUG/BUG总数),开发人员的评价(沟通方面)等等
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2015-12-15 23:23
  • 签到天数: 2 天

    连续签到: 1 天

    [LV.1]测试小兵

    17#
    发表于 2016-1-5 10:08:40 | 只看该作者
    质量和效率并重,提升产品的整体质量,建立一套有效的质量评估体系
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-22 02:35 , Processed in 0.075922 second(s), 25 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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