51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

12
返回列表 发新帖
楼主: lsekfe
打印 上一主题 下一主题

如何弱化因不同测试人员测试而引发的BUG率上涨的现象?(12-07-02)(获奖名单已公布)

[复制链接]

该用户从未签到

21#
发表于 2012-6-26 11:35:02 | 只看该作者
现在公司测试的就我们两个,一般就是一个人测完之后,由开发修复,复测,之后再由另一个测试人员进行测试
回复 支持 反对

使用道具 举报

  • TA的每日心情
    无聊
    2022-12-8 17:51
  • 签到天数: 256 天

    连续签到: 1 天

    [LV.8]测试军长

    22#
    发表于 2012-6-26 13:24:15 | 只看该作者
    当测试关联模块发现bug时,我们会先和测试人员沟通,是否已经提交该bug,或者查看下bug管理系统,如果还没记录,就记录到bug管理系统。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-1-27 17:05
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    23#
    发表于 2012-6-26 17:05:51 | 只看该作者
    个人感觉从以下几个方面着手:
    1:测试人员技术水平,不同人员设计用例,可能不同,比如等价类划分,不同人可能划分不同的区间,但最终结果都覆盖了需求,测试结果应该是相同的,除非,设计用例不够完全。所以人员技术培训应该为一个方面
    2:测试人员职能划分问题,不同人员负责不同模块,还是不同人员都负责相同模块,不同模块可能出现类似问题,但是也应该为一条新bug,如果不同人员负责相同模块,他们发现相同BUG的概率就会提高很多。
    3:测试内部评审,评审很重要,不同测试人员、部门在某个版本完成后会对用例进行评审,这个时候是修正用例的好时机,当发现设计的用例类似,发现相同问题的用例就可以剔除掉,精简用例,另外一个方面从不同人员考虑,设计者的用例不足,这个时候也可以进行完善,有效减少bug重复率
    4:测试计划,测试管理者,在进行测试人员分配时候,是否分配合理,包括单独模块和公共模块的划分。
    5:测试管理工具的使用 QC
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    奋斗
    2015-1-27 17:05
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    24#
    发表于 2012-6-26 17:06:01 | 只看该作者
    个人感觉从以下几个方面着手:
    1:测试人员技术水平,不同人员设计用例,可能不同,比如等价类划分,不同人可能划分不同的区间,但最终结果都覆盖了需求,测试结果应该是相同的,除非,设计用例不够完全。所以人员技术培训应该为一个方面
    2:测试人员职能划分问题,不同人员负责不同模块,还是不同人员都负责相同模块,不同模块可能出现类似问题,但是也应该为一条新bug,如果不同人员负责相同模块,他们发现相同BUG的概率就会提高很多。
    3:测试内部评审,评审很重要,不同测试人员、部门在某个版本完成后会对用例进行评审,这个时候是修正用例的好时机,当发现设计的用例类似,发现相同问题的用例就可以剔除掉,精简用例,另外一个方面从不同人员考虑,设计者的用例不足,这个时候也可以进行完善,有效减少bug重复率
    4:测试计划,测试管理者,在进行测试人员分配时候,是否分配合理,包括单独模块和公共模块的划分。
    5:测试管理工具的使用 QC
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    25#
    发表于 2012-6-27 12:46:22 | 只看该作者
    回复 9# Snowbing


        灰常赞同你的观点。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    26#
    发表于 2012-6-27 21:11:54 | 只看该作者
    回复 15# livexmm


         是说无论几个测试都可重复用一个测试用例  并且保证用例是及时更新成的意思吗?
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    27#
    发表于 2012-6-27 21:14:01 | 只看该作者
    从三方面着手吧。
    1、测试用例,是否做到定期更新和评审;
    2、测试计划和管理,是否在前期进行充分的计划 ...
    Lyangmeng 发表于 2012-6-25 14:25



        简单明了啦
    回复 支持 反对

    使用道具 举报

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

    连续签到: 1 天

    [LV.7]测试师长

    28#
    发表于 2012-6-27 22:13:54 | 只看该作者
    标准化测试方法、有完善的测试用例就能减少对人的依赖
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    29#
    发表于 2012-6-28 09:37:58 | 只看该作者
    如果不是BUG本身的原因,就要从不同的测试角度去看待类型相近或者几乎相同的BUG
    使用
    关键词
    等价类划分等方法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    30#
    发表于 2012-6-28 16:27:48 | 只看该作者
    详尽的测试评估标准
    人力允许的情况下,可指派不同人力执行相同测试,对比结果
    以此督促测试人员有危机感,提升自身能力,对问题的敏感度 (非常规手段)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    31#
    发表于 2012-6-28 16:27:55 | 只看该作者
    详尽的测试评估标准
    人力允许的情况下,可指派不同人力执行相同测试,对比结果
    以此督促测试人员有危机感,提升自身能力,对问题的敏感度 (非常规手段)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    32#
    发表于 2012-6-28 16:28:03 | 只看该作者
    详尽的测试评估标准
    人力允许的情况下,可指派不同人力执行相同测试,对比结果
    以此督促测试人员有危机感,提升自身能力,对问题的敏感度 (非常规手段)
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    33#
    发表于 2012-6-29 13:49:20 | 只看该作者
    不同测试人员测试导致bug率上涨,原因有下面几个:1. bug误报:由于测试人员对于业务,环境等的不熟悉,误报了由于配置不当而引发的问题。
    这类问题尤其出现在新员工,实习生身上,因为对于业务不熟悉,配置不熟悉,引发了bug率上涨;

    2. bug重复提交:的确是bug,但是由于测试交叉模块,测试人员比较多,版本比较多等等,就会出现同一个bug在不同阶段由不同人重复提交,从而引发bug率上涨;

    3. bug被发现:的确是bug,但是由于种种原因,测试人员在当前才发现了这些bug,从而引发bug率上涨,这个是最不能被接受的原因;

    针对这些原因,解决方法其实有很多:
    1. 通过培训,让测试人员尽快掌握业务熟悉环境,会大大避免bug误报的情况,当然测试人员自己要有意识自觉自发的去学习掌握业务,提高自身素养;
    2. bug重复提交,一般都是在交叉模块测试时发现或者时间久了大家对于老bug记忆不清。测试人员自身在提交bug的时候应该有意识地去bug库进行关键字查找,如果已经被提交,就应该在老bug上添加备注以说明该bug在当前版本仍旧被发现;

    3. 如果是第3个原因导致bug率上涨,这个问题就比较严重了,特别是在项目后期突然爆发了很多bug,不管是开发还是测试,大家都是无法接受的。要解决这个问题,除了测试人员要有良好的专业素质和技术外,时间的充裕程度也很重要,要让测试有充分的时间进行测试;

    总而言之,不管是第一类还是第二类,其实都可以通过cancel bug的方法进行避免,就算由于误报或重复提交了bug,都可以在bug库中cancel掉这些无效bug,这样bug率不会受到影响,最怕的是第三类情况,不管是通过定期的交叉测试,充分测试还是测试人员提高自身专业技能,一定要避免第三类情况发生。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    34#
    发表于 2012-6-29 14:44:51 | 只看该作者
    新手,学习,飘过。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    35#
    发表于 2012-6-29 20:51:13 | 只看该作者
    1、个人觉得每个人负责单独模块比较好,但是交叉模块最好2个人都测测,因为交叉模块将2个模块都涉及到了,但是2个模块关注的功能应该是各有偏重
    2、提交bug时将模块划分好,如果提交的是公共模块的bug,可以在提交bug前线review下另一个童鞋已经提交的bug
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    36#
    发表于 2012-7-2 11:13:47 | 只看该作者
    回复 1# lsekfe


    1、测试用例反应测试工程师的思维活动,是脑力劳动的价值体现---不同的人会产生不一样的思维路线 ,这个是能力大小的分水岭
    2、执行测试是简单的重复劳动,相同的路线产生不一样的效果,这个取决于个人工作素养即职业道德
    调和二者之间的关系,尽可能的降低bug率的上涨
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    37#
    发表于 2012-7-2 14:03:32 | 只看该作者
    个人认为避免人员测试开发自动化作业,另外Bug建立daily review,相同的bug可减少。测试案例的定义也很重要,明确各个人员的区块,整合区块由一人负责(一个广度看;一个深度看);通过每天会议做bug确认;让Leader主持会议。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    38#
    发表于 2012-7-4 16:21:53 | 只看该作者
    {:4_83:}学习咯
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    39#
    发表于 2012-8-16 17:43:06 | 只看该作者
    观点一、bug率=bug数/代码行数
    观点二、bug率=bug数/功能点数??
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    40#
    发表于 2012-8-16 17:44:28 | 只看该作者
    观点一、bug率=bug数/代码行数
    观点二、bug率=bug数/功能点数??
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-18 08:22 , Processed in 0.080117 second(s), 22 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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