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

默默巫

你在测试过程中对于不可重现的缺陷如何处理？请大家畅所欲言！

如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	wangjingying	当当购物卡50元	25#
二等奖	mr.bee	300论坛积分	17#
	search_happy		38#
三等奖	angelna	100论坛积分	4#
	havards		8#
	zm_027		10#

相关文章：

关于缺陷的优先级和严重级别

测试缺陷分析务实篇

软件缺陷的分类与管理

更多内容请点击＞＞＞

yhfeifei

这对于测试来说是很常见的事情，如果处理不当，很容易造成产品质量事故：

1.当发现不能重现bug时，立即回忆当前经过什么操作，并马上做出记录。【这时候如果有比较深入了解系统，可能会找出原因，所以这里强调下，多思考问题的重要性】
2.在自己仍然不能重现此bug时，和身边同事（测试同事和软件开发同事）沟通下问题可能出现的原因。【和同事空闲时沟通此类bug其实是会很开心的一件事情】若还是不行，将此bug提交至缺陷管理软件（如bugfree上），将之前做的记录写上，并注明bug为偶发性问题，测试负责人及质量负责人跟踪此bug。
3.产品进入到发布之前的一段时间，回归测试时，针对不能重现的问题进行全面扫除，如再不能重现，入档，并跟踪市场反馈。

UU1983

我还以为是从黑盒呢早知道不来掺和了让大家见笑

ladyjanice

尽量重现，否则也要留档备用

havards

突然想到一个问题：
对于不可重现的缺陷的处理是主题，但是要是延伸下，如果用例设计的完善，细致的话，是否可以最大程度的避免不可重现问题的产生呢？步骤详细的话，基本上在其中一步出错了的话，之前的动作就全清楚了。
当然我指的是按用例测试的情况，而不是freehand，相信测试出来的BUG大多数应该是通过用例产生的，而不是freehand产生，这样不好跟踪。

hero1796

不可重现的bug通常是有操作的随机性及系统的不稳定性造成的，本身来讲属于bug，但很容易被忽视，而在软件投入使用后，形成多种多样的错误，影响非常严重，所以必须重视这类bug的产生。
比较好的做法是：

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

keevinl

这样的问题,可以添加缺陷库,当确认处理,以后再次出现此问题时,保留现场,待开发人员进行分析

jerrygu625

对于半年都无法复现的可以Close掉了，没有必要再关注
有些不可会显得缺陷往往是修改了其他bug,顺带修改掉了这个bug

nakin

对于不可重现的问题：

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

mumurain

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

周卫

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

[ 本帖最后由 周卫 于 2009-3-22 22:53 编辑 ]

coolkisses

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

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

achong252159676

楼上的说的好，可以查看后台记录，或者其他的操作以及系统运行记录，查看是不是机器出错。

dannachen

除了以上大家说的：截屏，重复之前操作，记录之外，个人觉得还有一个很好的办法就是查看后台的操作日志，很可能当时后台日志也已经抛错了，那么可以让开发人员帮忙分析日志找出出错原因。

black_tulip

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

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

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

black_tulip

原帖由 orange_10 于 2009-3-19 17:06 发表
OK，如果你认同以上的观点，并且重现是有必要的，就继续花力气去重现，待测代码是确定的，重现所要花费的工作量也就是覆盖率的问题了，只要你每个分支，路径都覆盖（当然这里还要考虑测试环境，测试数据和一些常量的），BUG一定可以被重现。当然不只白盒适用，黑盒也同样如此

请考虑多线程这个概念。当然，我不否认“一定”，只是最好给这个“一定”加上个期限。

black_tulip

原帖由 UU1983 于 2009-3-18 16:25 发表
对于不可重现的缺陷的处理方法
1找出不可重现的原因
俗话说无风不起浪，有因必有果，既然曾经有过这样的结果肯定是有原因的，好多测试人员都把不可重现的缺陷置之不理，这些测试人员中不乏经验较多的老测试人，因为他们觉得既然不可重现何必要找呢，其实这样的想法是错误的，如果经常出现这样的问题难道你还真的置之不理吗，量变达到质变
那我们如何下手呢，有心之人可发现不可重现无非是一下几种原因
1)开发人员改的过程中出现的
由于程序的不完全，就会出现怪异的现象，这个很常见
程序的不稳定造成的，由于程序的健壮性差一会这样一会那样，也会出现
网络延迟，这也是其中的一个原因
浏览器问题，有些程序不支持多浏览器每种浏览器表现都不一样
操作系统也是原因之一
2 找到原因，记录下来进行备案，以便以后的遇到相似情况进行相应的处理
3完善的规章制度
很多时候开发人员不管测试人员是否把这个测试完毕就乱改程序，及时你找到他，他就会说我还没时间呢我不改怎么办，所以完善的制度是必然的这也是开发人员和测试人员避免冲突的好办法

唉。

都经常出现了还不可重现啊。

有心之人发现的导致不可重现BUG的原因：

程序不完全，不完全能跑吗？
程序不稳定，如果程序都不稳定了，问题是会经常出现了，复现不难。
网络延迟，这是很容易复现的。
浏览器表现不一，这是很可复现的。
操作系统？唉，不可复现BUG的原因还是交给开发人员去分析吧。测试员就不要乱琢磨了。

完善制度是立足之根本，不是用来解决不可复现问题的。

search_happy

我觉得对于一个不可重现的bug:
a.首先应该看看这个bug的severity,若是这个bug造成影响很严重,系统crash,或是软件crash了,在这种情况下,我的处理方法跟大家都差不多;
1.先回忆操作steps,做个20次边上,没碰到的话,记下了,在之后的build上做测试时.用心留意下,做相同的steps后,会不会在出现.若是一直都没出现过,就不管了.
2.就是问问跟你一块测试的同事,看看他们有没有遇到,把你操作的steps告诉他们,看他们可能遇到.
3.找类似的测试环境,包括你用的配置,用的软件,操作环境等等,在做相同的steps,大概20次边上,若没遇到的话,就不管了,

b.若是这个bug severity很低,在用户可接受的范围内,建议你别管了,不比浪费太多的时间在这方面,利用这段时间去找其他你没cover到的测试吧,提高整体效率.

navy2008

我比较赞同楼上几位说的，当出现异常时，首先想到的是截图，把这个图给截下来，其次，把刚才具体的操作步骤回忆记下来，然后，再次按着这个步骤来操作一遍，如果不能重现，那在提交BUG时，要注明，可能再次操作时不能重现。
另外，也要试一下和这个异常相关的其他的操作，看会出现什么样的现象，也把这些问题一并提交上去。
这样可能有助于开发人员确定问题

davids

是不是应该叫不易于重现的缺陷比较准确一些啊~~
一般对于这样的缺陷，我是这样处理的：
1.对出现缺陷的情况进行截图，保留错误的信息；
2.仔细回忆刚刚造成这样缺陷的所做的操作并把开发人员叫到一起，尝试着重现这样的缺陷；
3.如果仍不能重现的话，仍需要将缺陷提到缺陷管理系统中，毕竟这个缺陷出现过，记录缺陷的详细信息，可适当将此缺陷的优先级降低；

szflone521

我是还没入行的新人，学习学习。顶你们的肺