51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 1113|回复: 15
打印 上一主题 下一主题

对于20次只出现一次的bug是否应该提交?

[复制链接]

该用户从未签到

跳转到指定楼层
1#
发表于 2006-7-26 17:40:15 | 只看该作者 回帖奖励 |正序浏览 |阅读模式
对于20次只出现一次的bug是否应该提交?
如果出现机率更小,是否应该提交bug?
分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
收藏收藏
回复

使用道具 举报

该用户从未签到

16#
发表于 2006-9-6 10:08:52 | 只看该作者

submit

这样的bug更应该提
回复 支持 反对

使用道具 举报

该用户从未签到

15#
 楼主| 发表于 2006-8-17 09:50:10 | 只看该作者
做外包测试的时候就比较麻烦了(交流通信效率低啊),一个不可重现的bug,往往会被那边的开发人员否认掉
回复 支持 反对

使用道具 举报

该用户从未签到

14#
发表于 2006-8-16 20:09:45 | 只看该作者
看了一遍,朦朦胧胧
回复 支持 反对

使用道具 举报

该用户从未签到

13#
发表于 2006-8-8 10:25:02 | 只看该作者

源自skinapi的个人blog

要想复现不可复现的Bug,需要先提到一个概念就是ET(Exploring Test),也就是探索式测试,这种测试方法是由James Bach首先提出来的,在所掌握的被测对象的信息不是很充分的情况下,这是一种很有效的测试方法,如果大家感兴趣,我再整理一篇ET的文章出来。
    在给大家阐述如何复现不可复现的Bug的思路之前,先说说为什么要复现这些不可复现的Bug(废话两句^_^)。对于整个项目或者产品而言,如果这些不可复现的Bug是很严重的Bug,比如导致系统崩溃等,如果不能及时、准确的定位和解决,最终发布出来的软件到达用户手中后,一旦出现势必会影响软件已经公司在用户心中的形象,严重的会“迫使”用户选择竞争对手的产品,这些显然都是公司所不愿看到的。而对于测试人员而言,出现了这些不可复现的Bug,实际上是一次很好的锻炼和提高机会,如果只是提交缺陷报告将这个大皮球踢给开发人员,不仅丧失了一次提高测试水平的机会,还有可能破坏和开发人员之间的关系。
    废话完了,进入正题。当出现不可复现的Bug时,大家可以从以下五个方面来进行考虑:
1、被测对象的版本信息
    我测试的到底是哪个版本,这主要是有两个作用:一是确认我测试的是正式的软件版本,如果不是就先记录下该问题,然后选择正式的版本进行测试(开发人员基于尝试的一次非正规的修改可能会导致不可复现的Bug);二是可以和其它版本进行对比,如果其它的版本没有类似的问题,就可以去对比这两个版本之间的区别。
2、环境
    这里的环境是指出现不可复现的Bug时所对应的测试环境等,比如测试所用的计算机,如果出现不可复现的Bug,那我换一台机器是不是还会出现类似的问题,也就是说通过环境的改变来进一步搜集不可复现Bug的相关信息。
3、模式
    这里的模式是指我对这个Bug如何出现的一个理解,先给这个Bug设定一个模式,比如是不是数据库通信中断,然后再进行测试,收集更多的信息去修改和完善这个模式,这样不断进行,最终直到Bug能完全复现为止,这个时候只要使用这个模式就可以复现出Bug了。
4、人
     这里提到的人有两个含义:一是测试是由人来进行的,人的操作、人的思维方式会有不同,通过分析这些信息也有可能找到这些不可复现的Bug的蛛丝马迹;二是想复现不可复现的Bug,往往需要多个人之间的相互协作,比如测试人员、开发人员等,通过大家的沟通和协作就能更容易去复现了。
5、测试工具
    通过一些debug工具或者log工具等搜集内存等信息,根据这些信息来进行分析,找出不同信息之间的共同点,比如某一块内存始终都会被改写等,通过这种方式来去复现Bug。
    上面的五个方面都是和ET的思想紧密相关的,通过不断的测试和不断的信息收集和分析,逐步的把模糊的、不确定的测试变成清晰的、确定的测试,这样就能复现那些不能复现的Bug了。考虑信息时可以从以上五个方面来进行考虑。
回复 支持 反对

使用道具 举报

该用户从未签到

12#
发表于 2006-7-28 01:51:46 | 只看该作者
说的好,要让开发人员知道:测试并不是他们想象中的那样简单。也是技术含量很高的工作,我们也有能力去重现或定位错误。
回复 支持 反对

使用道具 举报

该用户从未签到

11#
发表于 2006-7-27 20:17:30 | 只看该作者
对啊,,不可以重现的就自己去找重现的条件!
然后反应该开发。
回复 支持 反对

使用道具 举报

该用户从未签到

10#
发表于 2006-7-27 18:15:32 | 只看该作者
尝试着自己去定位一个不可重现的BUG或概率重现的BUG,成功后告诉开发人员这样的也是BUGsdlkfj2
回复 支持 反对

使用道具 举报

该用户从未签到

9#
发表于 2006-7-27 17:20:21 | 只看该作者
我们这里是无视的 ,开发的只接受可重现的,而且要他们认为是BUG的
回复 支持 反对

使用道具 举报

该用户从未签到

8#
发表于 2006-7-27 13:43:38 | 只看该作者
只要确认不是由于测试工程师误操作或其他软件如病毒干扰,那么不管是否能重现,都要提交缺陷报告,这和概率无关。如果不能重现,那么需要在报告上注明不能重现,如果概率重现,那么注明重现的概率。


原帖由 wxq8102 于 2006-7-26 22:23 发表
应该提交吧,这个机率还是比较大的,如果机率更小,几乎不能重现的一些缺陷,第一:要判断是不是其它程序导致的错误,可能是病毒导致的.第二:对于一些资源类的错误,如:句柄错误等,是比较难以重现的,需要通过技术手段进行 ...
回复 支持 反对

使用道具 举报

该用户从未签到

7#
发表于 2006-7-27 10:59:25 | 只看该作者

1/20啊

厉害啊,这样的问题也难逃法眼啊,佩服啊,提交啊
回复 支持 反对

使用道具 举报

该用户从未签到

6#
发表于 2006-7-26 22:23:21 | 只看该作者
应该提交吧,这个机率还是比较大的,如果机率更小,几乎不能重现的一些缺陷,第一:要判断是不是其它程序导致的错误,可能是病毒导致的.第二:对于一些资源类的错误,如:句柄错误等,是比较难以重现的,需要通过技术手段进行监控或对其进行限定资源.第三:对其设时限,假如设为二个月,如还没有重现,则放弃.
回复 支持 反对

使用道具 举报

该用户从未签到

5#
发表于 2006-7-26 21:56:37 | 只看该作者
这个概率还是算蛮高的,应该提交,同意楼上兄弟们的意见。
回复 支持 反对

使用道具 举报

该用户从未签到

4#
发表于 2006-7-26 19:04:22 | 只看该作者
提交啊~
回复 支持 反对

使用道具 举报

该用户从未签到

3#
发表于 2006-7-26 18:26:36 | 只看该作者
原帖由 Tender 于 2006-7-26 18:10 发表
应该提交。
并且在提交的同时保留现成环境,以便开发人员来进行定位。


同意,肯定要提交的啊~~~
回复 支持 反对

使用道具 举报

该用户从未签到

2#
发表于 2006-7-26 18:10:25 | 只看该作者
应该提交。
并且在提交的同时保留现成环境,以便开发人员来进行定位。
回复 支持 反对

使用道具 举报

本版积分规则

关闭

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

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

GMT+8, 2024-11-25 06:52 , Processed in 0.075258 second(s), 24 queries .

Powered by Discuz! X3.2

© 2001-2024 Comsenz Inc.

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