51Testing软件测试论坛

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

QQ登录

只需一步,快速开始

微信登录,快人一步

123
返回列表 发新帖
楼主: 默默巫
打印 上一主题 下一主题

对于不可重现的缺陷如何处理?(09-3-16)(获奖名单已公布)

[复制链接]

该用户从未签到

41#
发表于 2009-3-20 22:32:57 | 只看该作者
原帖由 wangjingying 于 2009-3-19 15:18 发表
缺陷不可重现的情况有很多种,按照我个人的工作经验和理解可以分为一下几类。
1. 自动化工具执行回归测试发现缺陷,之后单跑一个测试用例不会无法重现
2. 自动化工具执行测试用例发现缺陷,之后手动无法重现问题
...


仔细看了下25楼的12345,针对4和5,我认为:

4 建议使用带有打印信息的版本重新FREE TESTING。
5 a-d的这个步骤,这是必须的。在完成这个步骤后还是无法重现的bug才称为不可重现的bug。
回复 支持 反对

使用道具 举报

该用户从未签到

42#
发表于 2009-3-20 23:06:08 | 只看该作者
除了以上大家说的:截屏,重复之前操作,记录之外,个人觉得还有一个很好的办法就是查看后台的操作日志,很可能当时后台日志也已经抛错了,那么可以让开发人员帮忙分析日志找出出错原因。
回复 支持 反对

使用道具 举报

该用户从未签到

43#
发表于 2009-3-21 15:15:13 | 只看该作者
楼上的说的好,可以查看后台记录,或者其他的操作以及系统运行记录,查看是不是机器出错。
回复 支持 反对

使用道具 举报

  • TA的每日心情
    开心
    2014-12-8 13:22
  • 签到天数: 1 天

    连续签到: 1 天

    [LV.1]测试小兵

    44#
    发表于 2009-3-22 14:42:23 | 只看该作者
    看了许多人的回复,说了不少,也分析的很到位,但觉得大部分都偏题了
    个人理解,这个题目的本意是针对那些不可重现的BUG,其前提已经指定
    很多人都分析了不可重现的原因,也有很多人都在分析说明测试中如何避免这种情况的发生,但真正说到点上,即,发生不可重现BUG时如何处理的人,真的很少
    对此,感到非常遗憾,本来是抱着想找到对这么一个人人都会遇到问题的妥善解决道

    最后说下个人理解,
    不可重现BUG原则之一,不可关闭,起码在最近几个版本之内都不应关闭,最好是一直挂起状态;
    原则之二,建立BUG跟踪流程,跟踪的BUG应当包括测试中不可重现的BUG,也可在测试过程不断补入新的需要跟踪的BUG,即使是已经关闭的BUG。类似于版本review吧;
    原则之三,任何不可重现的BUG,都需要进行仔细分析,即使当前版本没有时间做这事,回过头来,还是需要进行仔细研究。不可重现的BUG最令人担心的不是BUG本身,而是隐藏在背后的风险,我们很可能只是偶然发现了冰山一角。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    45#
    发表于 2009-3-22 22:49:17 | 只看该作者
    1、毫无疑问,第一反应就是抓图,仔细回忆操作步骤以及操作数据,并重复操作,如果系统是基于B/S架构的软件,那么在删除COOKIES、历史记录、脱机文件等信息前后的操作有和区别
    2、 既然是不可重现的BUG,那么接下来在操作的过程中从价值上考虑,是否容易重现?严重与否?估量一下有什么潜在的风险?是否值得我们花大量时间让使得它重现?
    3、如果有风现存在,就同身边的同事交流探讨可能的原因,再进一步检查软硬件的配置(很有可能与兼容性有关系),并且在多个不同的环境下多次操作
    4、可能等到产品发布了还是不能重现的话,入档记录,并跟踪市场及时反馈

    [ 本帖最后由 周卫 于 2009-3-22 22:53 编辑 ]
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    46#
    发表于 2009-3-23 10:05:29 | 只看该作者
    看了一下各位前辈的回答,感觉和题目有点跑题,现在的问题是对于不可重现的缺陷如何处理,重点是处理上,而不是要将不可重现变成重现上
    我个人观点:
    1、根据记忆力,首先判断不可重现的bug是什么级别的bug,对于级别很低的bug只要记录在案,在一定时期内如果没有发现类似的问题可以忽略过去,如果级别相对较高的bug,可以记录在bug管理系统上,注明问题内容,标注偶发性,并与其他测试小组成员进行沟通
    2、与研发进行交流,反馈不可重现的bug描述,在与研发的交流中,看是否能大概确定问题的范围
    我大概能想到的就这么多,也请前辈们多多提出其它好的解决方法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    47#
    发表于 2009-3-23 13:54:33 | 只看该作者
    对于不可重现的问题:

    1.首先,一定要记录下该问题
    2.尽量去重现该问题,若不能重现,可以反映给项目组,让项目组来决定该问题的处理方法
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    48#
    发表于 2009-3-23 15:19:09 | 只看该作者
    对于半年都无法复现的可以Close掉了,没有必要再关注
    有些不可会显得缺陷往往是修改了其他bug,顺带修改掉了这个bug
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    49#
    发表于 2009-3-23 16:48:37 | 只看该作者
    这样的问题,可以添加缺陷库,当确认处理,以后再次出现此问题时,保留现场,待开发人员进行分析
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    50#
    发表于 2009-3-23 17:04:41 | 只看该作者
    不可重现的bug通常是有操作的随机性及系统的不稳定性造成的,本身来讲属于bug,但很容易被忽视,而在软件投入使用后,形成多种多样的错误,影响非常严重,所以必须重视这类bug的产生。
    比较好的做法是:

    对bug进行分类统计,记录bug, 分析一段时间bug的分布状态,参照历史数据,确定系统的稳定性。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    51#
    发表于 2009-3-25 17:15:39 | 只看该作者
    突然想到一个问题:
    对于不可重现的缺陷的处理是主题,但是要是延伸下,如果用例设计的完善,细致的话,是否可以最大程度的避免不可重现问题的产生呢?步骤详细的话,基本上在其中一步出错了的话,之前的动作就全清楚了。
    当然我指的是按用例测试的情况,而不是freehand,相信测试出来的BUG大多数应该是通过用例产生的,而不是freehand产生,这样不好跟踪。
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    52#
    发表于 2009-3-26 17:16:39 | 只看该作者
    尽量重现,否则也要留档备用
    回复 支持 反对

    使用道具 举报

    该用户从未签到

    53#
    发表于 2009-3-28 16:37:05 | 只看该作者

    25楼的说的都是百盒

    我还以为是从黑盒呢早知道不来掺和了让大家见笑
    回复 支持 反对

    使用道具 举报

    本版积分规则

    关闭

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

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

    GMT+8, 2024-5-4 07:10 , Processed in 0.072705 second(s), 21 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

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