51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 5848|回复: 11
打印 上一主题 下一主题

[原创] 请教大家,对于偶然出现或没有规律性的BUG,怎么测试这个BUG已修复了呢?

[复制链接]
  • TA的每日心情
    慵懒
    2015-4-8 15:35
  • 签到天数: 17 天

    连续签到: 1 天

    [LV.4]测试营长

    跳转到指定楼层
    1#
    发表于 2010-9-14 17:34:43 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
    请教大家,对于偶然出现或没有规律性的BUG,怎么测试这个BUG已修复了呢?
    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    该用户从未签到

    2#
    发表于 2010-9-14 20:35:35 | 只看该作者
    1、让开发写清楚什么原因导致bug,怎么解决的
    2、bug做长期验证,不急于关闭
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-4-8 15:35
  • 签到天数: 17 天

    连续签到: 1 天

    [LV.4]测试营长

    3#
     楼主| 发表于 2010-9-14 22:38:37 | 只看该作者
    这倒是个好办法,我试着跟我们主管提下意见!谢谢了
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-4-8 15:35
  • 签到天数: 17 天

    连续签到: 1 天

    [LV.4]测试营长

    4#
     楼主| 发表于 2010-9-14 23:05:28 | 只看该作者

    回复 2# 的帖子

    但是这样可能会引起开发的不满,我们公司开发的人少,平时也很忙,有些BUG可能他们也不知道是怎么产生的。派给他们的任务是要由我来测试看是否修复完成的,对他们的奖金有影响,有点麻烦。有没有测试方面的方法或技巧?

    [ 本帖最后由 微笑流淌 于 2010-9-14 23:16 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    5#
    发表于 2010-9-14 23:41:50 | 只看该作者

    回复 4# 的帖子

    俺只知道这样了……这种偶现或者没有规律的只能长期跟踪,在这之前可以跟开发,项目经理以及其他相关领导有个约定,比如几个版本没有出现,可以关闭,但是关闭的时候要说清楚,如果以后还有的话,需再次打开……
         定位清楚原因虽然对开发来说可能很烦,但是一个优秀的开发人员肯定可以理解的,因为这本身就是对其的一个总结提高过程,再说,这种bug数量不会多
        可以试试看……
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-4-8 15:35
  • 签到天数: 17 天

    连续签到: 1 天

    [LV.4]测试营长

    6#
     楼主| 发表于 2010-9-15 08:24:32 | 只看该作者

    回复 5# 的帖子

    多谢你啦!那我试试看吧!
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    7#
    发表于 2010-9-15 09:09:41 | 只看该作者
    对,可以约定一个规则,如果在连续几个版本这个bug都没有重现的话,可以设置为关闭
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    8#
    发表于 2010-9-15 09:26:13 | 只看该作者
    昨天看到luming的一个帖子,说其实很少有偶发性的bug,没有规律更多时候还是我们没有找到其规律。
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    开心
    2021-6-9 14:08
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    9#
    发表于 2010-9-15 09:27:57 | 只看该作者
    偶然性不可重现BUG怎么处理?zz


    一、一定要提交!!

    1.  记得有这么个缺陷,以后再遇到的时候可能就会了解发生的原因。
    2.  尽力去查找出错的原因,比如有什么特别的操作,或者一些操作环境等。
    3.  程序员对程序比测试人员熟悉的多,也许你提交了,即使无法重新,程序员也会了解问题所在。
    4.  无法重现的问题再次出现后,可以直接叫程序员来看看问题。
    5.  对于测试人员来说,没有操作错误这条.既然遇到,就是问题。即使真的操作错了,也要推到程序员那里,既然测试人员犯错误,用户也可能会犯同样的错误。错误发生的时候,Tester最大。


    二、程序不是测试人员写的,出问题也不是测试人员的原因。

    至于无法重现,可能的原因很多,因为测试人员看到的只是程序的外部,无法深入程序内部,所以把责任推给测试人员是不对的。

    测试人员的任务只是尽力重现问题,而不是必须重现!!


    三、下次再遇到的时候,拉他们来看就可以了。

    因为问题如果无论如何无法重现,程序员确实也没有什么好的解决方法。

    而且此类问题即使程序员说修改了,测试员也没有好的方法去验证是不是。 : )


    四、你可以告诉程序员,测试过程是没有错误的。

    测试人员只是检查程序中可能存在的问题,虽然测试人员使用一定的手段方法努力去覆盖所有的情况,但这些都是理论的推测。在实际中,可能因为人员、环境、配置等种种原因出现各种各样的问题,在测试人员这里发现问题是公司内部的事情,程序发到外面可就是公司的形象问题了。

    需要让程序员理解,测试人员是帮助他们的,不是害他们的。

    客户那里发现问题比测试员发现问题结果要严重的多。


    五、测试部门是独立与开发部门的呀,真的打交道,也是经理对经理。

    在我们这里,工作上面的事情,和程序员相互只能商议解决,并没有谁高谁低。

    问题无法重现,也要提出,程序员那里可以回复无法再现。问题放在那里,等到再次出现的时候,就立刻叫程序员过来查看。

    实在没有再次出现,最后可以写到报告中,说出现了什么现象,但无法再现(比较严重的问题才如此处理,小问题经理之间商量商量可能就算了)。

    至于测试人员必须重现bug,你杀了我好了,我每次测试项目都有无法重现的问题,很多我能找到大概的原因,有些根本无法重现(仅仅出现一次)。

    这种事情是无法避免的,并不能说测试人员无法重现问题,就是工作不到位(哼,程序有bug,是否可以说程序员工作不到位的呀)。


    六、测试部门要独立,最好不受开发的制约。其实真正要重视,就应该有否决的权利。

    我们公司就是项目承包,要拿最后的项目尾款,就要测试部签字通过,这样就避免了很多的问题。

    其实只要自己尽到心就可以了,管别人怎么说呢。


    七、我们使用的状态有:

    程序员处理的状态(由测试员提交的Action):等待处理的,再次出现的。

    测试员处理的状态(由程序员提交的Action):已经修改的,暂不修改的,系统限制的,使用错误的,无法再现的。测试员可以修改记录。

    经理处理的状态(由测试员提交Action):管理员处理的。经理还可以删除记录。

    按照比较标准的说法,其实对于缺陷还应该有“等待确认的”、“已经确认的”和“重复提交的”的状态,我们为了省事,统一使用了“等待处理的”。

    最后结项的时候,缺陷的状态对我们来说有两种,“已经关闭的”(由测试员或经理确认)和“暂不修改的”(比如下一个版本处理等)。

    呵呵,状态多,有些烦琐,特别是程序员很多的时候都不清楚应该回复什么状态,但我个人觉得对测试人员来说,这些状态比较清晰明了,容易处理。



    八、一个叫doer_ljy(可战)的网友回复了一些内容,我个人认为不很妥当,就回复了一些内容,绿颜色的是doer_ljy(可战)的内容:


    关于“无法重现”我看是有这么个问题存在。

    首先如果你在测试之前有严格的测试计划,就很难出现“无法重现”这种现象。“无法重现”的意思是不知道怎么操作才能再次看见这个BUG。那么这个BUG多半是“计划外”的。

    不清楚你是否是测试人员。“计划外”这个词,对测试员来说应该不存在。测试用例的粒度一直是个在讨论中的问题,测试人员很难有时间和精力写出包含内容、数据、步骤等等全部操作一切的测试用例(说白了,只要一个长手识字的人,按照测试单做,就能发现所有的问题,呵呵,有软件蓝领的感觉了)。即使真的有,意义也不大,测试很多的时候,是发散性的思维,带点创造性,想事先考虑完全,很难。所以更多时候,是在测试过程中逐步对用例等进行完善,所以说“计划外”最好不要提。

    说说我现在测试的一个项目,有一个业务,首先查询出人员,有个“全选”按钮,“全选”后,再用鼠标一个一个取消选择,这个时候进行业务办理的时候,就会提示“没有选择人员”,至今为止一切都正常,但是这个时候再次点选人员进行业务处理,仍然会提示“没有选择人员”,这就是一个缺陷了。这个问题我想一般人都不会在测试用例中考虑到吧,因为发生的条件很苛刻:不用“全选”按钮的时候不会发生;全选后点击“取消全选”按钮再办理业务不会发生;全选全消后,先点击人员再办理业务也不会发生。

    其次,成熟的测试人员及时无法再现BUG,也能准确的描述出BUG发生之前几个步骤的操作方法,测试用例情况。这些对开发人员分析BUG原因很重要。所谓的BUG发现环境。

    呵呵,看来我不是成熟的测试人员。手工测试,比较熟练的时候,和打字可以说差不多,应该进行到哪里,心中是有数的,但让我完全从头到尾的重复,不容易呀。写测试缺陷报告单的时候,也只是说明操作步骤和发生的现象。其实无法重现的问题,既然说“无法重现”,也就是测试人员已经对这个现象进行了多次的验证,一般从程序外部来说,测试人员的操作比程序员要熟练的。

    最后,我不同意测试人员不假思索把发现的“问题”直接推给编码人员的做法。毕竟是大家合作,目标是一致的。测试人员总是处在BUG发生的第一现场,应该帮助分析出现问题的原因。确认是不是自己的此时Miss.


    测试人员提交任何一个问题,都会经过反复的验证,如果容易重现,早就提出来了。绝对不是在推脱责任,还是那句话,对程序的结构,做的人当然比不做的人要清楚。另外,除非程序员询问,否则我不会给程序员提出修改分析和建议!!测试人员的任务是发现问题,解决问题是程序员的事情。这么做可能会影响程序员思考问题的思路;而且测试人员做的多了,程序员不但不感激,可能反而会反感(好像程序员对测试人员有好印象的不多)。

    再说两个我这两天遇到的问题。第一个就是我们的程序有一个锁定数据的功能。锁定后,在其它的业务,此数据将不能再使用。我当时发现这个功能无效,而且经过了几次的验证都不行,我当然就提出了。但是程序员那里说此功能好使,我再验证的时候,就没有问题了,这个问题当时可以重现(但是我不可能遇到问题就拉程序员来看吧),后来却没有了,只能放在那里,最后关闭掉。第二个就是在一个界面中,录入有顺序要求,必须先选择一个ListBox(必填)再进行Edit的录入,但一次操作我没有选择 ListBox就录入的Edit,也正常保存了。后来无论我怎么操作此问题都没有出现(不够成熟呀),我就放弃了,也没有提交记录(为了避免麻烦)。

    测试人员的时间是有限的,进度给的都很少,一般连用例都没有时间写,还要去花很多时间验证“无法重现”的问题?反正10分钟如果试验不出来,我就会放弃。严重的就提交,不影响的就当不知道。

    下面是其它一些人的观点:

    doublefalse(散诸怀抱):如果不能重现的bug确实比较麻烦,但最好在测试过程中注意干净环境、正确的操作、相同的数据源,只要真的有问题,一定能否复现的。呵呵,多试试!!!我们以前一直有客户反映入库的数据经常有无关数据,但在家里测试没有问题,后来才发现是汉字编码错位,这样同样的字,错位后就变成另外的东西了。

    liuxiaoyuzhou(蟀哥):遇到过同样的问题!主要是记住BUG出现的环境!测试的时候这是关键!在我们这里不能从现的BUG,是测试人员的工作不到位!我们这里程序员比测试人员说话有力度!郁闷呀!

    ericzhangali(另一个空间):首先一定要提交bug;其次不要企图RD一定去解这个bug;某些时候还得关闭这个bug。如果RD认为是测试错误,(不明白什么叫测试错误,是不是说他从测时要告诉你千万不要怎么怎么做,否则后果自负啊,)那也没什么办法,如果沟通解决不了,爱咋认为就咋认为吧。

    darkcat_c(错了重来):没有bug是不可以重现的,bug本事是建立在标准的规程上所出现的异常,如果你按test case步骤做的话不太可能出现此类bug。作为测试人员一定要具备良好的记忆能力,一旦出现一些不知如何产生的bug,至少你要知道刚才你大致进行了那些操作。良好的分析能力,尽管你只是测试,但你应该全面的了解程序的架构,和一些重要的内部细节,不然你这个测试就是不合格的。定位bug是开发的事情,而重现一个bug是测试的本职工作,不要把所有的事情推给开发,不然你的确比开发要低一等。(编者按:这种话,不愿意去辩驳,标准开发人员的看法,也许应该让他们也来做做测试)

    liyan_1014(雁子):我觉得应该是这么处理:

    1、一定提交bug,必须由负责bug的tester详细描述测试操作步骤,bug发生的症状,并将bug发生的具体环境也描述清楚;这样对于再次重现也有一定的参考性。

    2、测试和开发之间是需要良好沟通的,如果得到的回复是操作错误,那么请开发人员解释,为什么会允许存在操作错误,一般来说,对于错误控制,开发那边应该能很好的把握。

    3、沟通方面是需要方式的,开发人员对于自己完成的程序有一种满足感,一般来说是不允许别人来破坏他的这种感觉,如果沟通的时候尽可能是一种建议的形式,让开发人员自己指出自己的程序缺陷,这样对于开发人员来说是可以接受。

    以上仅是个人工作中的经验,呵呵~~~~

    原帖地址:http://bbs.51testing.com/viewthr ... p%3Bfilter%3Ddigest
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    10#
    发表于 2010-9-15 10:47:45 | 只看该作者
    看概率.. 最迟的话3个版本后关闭...
    回复 支持 反对

    使用道具 举报

  • TA的每日心情
    慵懒
    2015-4-8 15:35
  • 签到天数: 17 天

    连续签到: 1 天

    [LV.4]测试营长

    11#
     楼主| 发表于 2010-9-15 21:22:18 | 只看该作者
    多谢大家
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    12#
    发表于 2010-9-15 23:00:37 | 只看该作者

    回复 8# 的帖子

    是问题总会出现的,需要时间,对测试的技术要求也比较高……
    成本、质量、进度又开始打架了……
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-11-16 14:03 , Processed in 0.074551 second(s), 28 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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