关闭

如何衡量测试效率

359人阅读 评论(0) 收藏 举报
分类:

以系统测试发现缺陷的数量来衡量测试人员的系统测试效率,就好像拿开发人员的代码行数衡量开发人员的开发效率一样,无法客观有效的反映测试人员的工作质量和工作效率。

优点:以BUG数量为基础,有一个明确而清晰的度量标准
缺点:欠缺力度和有效尺度,不能真正反映当前系统的质量状况

>>原因:
1)一个点型的例子,主业务流程和非主业务流程中的一个C类BUG,或是主业务流程中C类BUG和非主业务流程中的A类BUG,或是经常出现的BUG和偶尔出现的BUG。
(对主业务流程的解释:需求提出的,包括明确的或是隐式的,反之则为非主业务流程。可以按此区分问题的优先级)
2)开发质量:测试一个高质量的程序和测试一个低质量程序所发现的BUG的数量肯定不一样

>>引出问题:
1)这两种类型的BUG是否有可比性,是否可以说同时发现的两种C类BUG的测试人员的工作效率就一样高呢?或是发现非主业务流程中A类BUG的测试人员的测试效率要比发现主业务流程中C类BUG的测试效率高呢?或是发现经常出现的BUG的测试效率就高过发现偶尔出现BUG的效率就高呢?
2)对于不同开发质量的程序,以BUG数量做评价标准,谁碰到了开发质量不高的程序,那他的测试效率一定高(如果他是个合格的测试的话 :))

>>Root Cause:二者没有直接的可比性,需要一个中间变量:权重
1)BUG的权重
2)开发人员的能力

解决方案:
1)针对BUG按照实际的需求进行权重划分(主流程按1.0,非主流程按<1.0,具体的划分方式需要参考以前的测试标准得出一个合理的度量数据)
2)针对BUG对系统的影响程度进行权得划分(系统崩溃:1.5,严重:1.0,一般:0.8等等进行划分)
3)针对开发人员能力,取开发人员的平均开发能力,以此为标准确定BUG发现的权重。大于开发能力的,其BUG的权重就应当>1.0,反之则应<1.0。
4)针对每一个测试版本做相应统计,进行曲线比较,如果是上窜下跳,而且没有理由,测试效率是高是低一目了然
5)加强测试过程控制,必免不合格测试版本的出现,否则得出来的再高的测试效率也是没有价值的。

注:
1)所有的权重评估数据都是在前期数据基础之上进行的,也就是说需要设定一个基础的度量值,随着整体开发和测试的质量的提高,或是整体系统的开发难度和业务熟悉度的变化,这个值是动态变化的。
2)有时也会将测试人员的经验和测试水平加权做评估,个人认为意义不大,因为不同类型的测试人员发现问题的类型,方法和敏感度不尽相同。建议此指标只做为参考。

0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:25847次
    • 积分:1003
    • 等级:
    • 排名:千里之外
    • 原创:127篇
    • 转载:18篇
    • 译文:0篇
    • 评论:2条
    文章分类
    最新评论