对于不可重现的缺陷如何处理？（09-3-16）（获奖名单已公布）
你在测试过程中对于不可重现的缺陷如何处理？请大家畅所欲言！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
获奖名单奖项获奖名单奖励答案链接一等奖wangjingying当当购物卡50元25#二等奖mr.bee300论坛积分17#search_happy38#三等奖angelna100论坛积分
4#havards8#zm_02710#
http://bbs.51testing.com/attachments/month_0811/20081125_650d7dccd46be6244f27oXDjE0HoDhyX.gif
相关文章：
关于缺陷的优先级和严重级别
测试缺陷分析务实篇
软件缺陷的分类与管理
更多内容请点击＞＞＞ 这对于测试来说是很常见的事情，如果处理不当，很容易造成产品质量事故：
1.当发现不能重现bug时，立即回忆当前经过什么操作，并马上做出记录。【这时候如果有比较深入了解系统，可能会找出原因，所以这里强调下，多思考问题的重要性】
2.在自己仍然不能重现此bug时，和身边同事（测试同事和软件开发同事）沟通下问题可能出现的原因。【和同事空闲时沟通此类bug其实是会很开心的一件事情】若还是不行，将此bug提交至缺陷管理软件（如bugfree上），将之前做的记录写上，并注明bug为偶发性问题，测试负责人及质量负责人跟踪此bug。
3.产品进入到发布之前的一段时间，回归测试时，针对不能重现的问题进行全面扫除，如再不能重现，入档，并跟踪市场反馈。 我对于这个问题，就是再次按着上次的步骤再试几次，如果再也不出现就只能暂时搁置，等待下次的出现~！ 1、重复操作，看能否重现；
2、不能重现的问题也要记录下来，以备后用； 1、可以先记录问题，详细的描述下来，如果有机会，可以抓图
2、检查一切可能存在的问题，因为只有有这个BUG，一定是可以重现的，尽力的模仿当时的操作，比如点鼠标的速度，刷新速度，还有数据的填写
3、可以检查一下配置，是否自己的机子上安了什么时候软件哪些导致这个问题的出现
4、如果所有的方法都试过了，还是不能实现，哪么可以把它放到配置管理中，让它置为遗留状态，并且提交缺陷报告
5、也可以发一份邮件件给开发人员，让他帮你分析一下 对于所有出现的bug最好截图保存并及时和开发人员沟通
当发现bug不能再次重现时应及时补充相关问题出现的场景并提交至bug清单，反馈给开发协助其找出问题所在 首先，不可重现的缺陷是非常严重的，虽然测试只在测试时出现了一次，以后有可能就再也没出现，但是不能保证该缺陷在用户手里就不出现，对于不可重现的缺陷，要看其严重性。要是非常严重，就要时时关注此问题。一般式将该缺陷的所有输入值重现筛选出来，就一定保证能重复该缺陷的。 人为重现BUG性价比低并且收效甚微：
1.作为一个测试人员，作为一个人，出现不可重现BUG的缺陷是不可避免的，因为我们不是录音机或者摄像机，不可能把之前做过的工作或者步骤都记的一清二楚。
2.如果每出现一个BUG，都去人为的重现BUG，如果此BUG严重性非常高的话，这样或许还有点性价比，但是如果严重性不高，还花费1个上午或者1天来重现一个BUG，太不合算。
所以，我想到了自动化测试。
虽然具体的步骤记不清，但是大概的步骤应该都知道，毕竟是自己发现的BUG，把这些编译成脚本，借助自动化测试工具，使其自动执行编写的步骤。
这里就需要一个数据，就是执行的次数，自动执行100次或者1000次，相信这个数据拿给领导看，也比较有说服力。
再者，我们得结合我们国内的软件开发方式，就我所知，国外的一些测试比较规范，发展比较好的公司，1个beta可能只做一次完整的测试。
而我们国内的就算比较厉害的软件公司，1个beta可能都需要好几个版本来支持，当然了这里面可能是由于版本控制的原因，这里暂且不提。就算这个build里没有重现出这个BUG，下个build遇到可以再报嘛，不发beta还不都一样。 我觉得作为一个测试人员，一旦发现有bug，第一反应就应该截图，并且把操作步骤记录清楚！
因为有些bug很难重现，所以在验证它是否能重现之前一定要做好相关记录。
如果当时没有记录，而缺陷又不能重现，那就和开发人员好好沟通沟通，看能否发现具体问题！ 1. 严格按用例执行
2. 如果是作随机测试时，把测试步骤的点进行速记
3. 偶发BUG一般都是严重的，保留现场，让开发人员一起分析留下的现场
4. 最好的做法：要求开发打开调试信息
5. 即使一时没有重现，一定也要做好记录，以便日后“偶遇” 1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常； 1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常； 1.先把问题记录下来，排查出可能出问题的功能点或者范围；
2.找到大致功能范围，查看代码部分，看是否有逻辑问题；
3.查看此功能相关的数据库存取情况是否有异常； 1.如果是自己偶然发现的问题，而且自己也不能重现的话，也要记录下来，那么自己尽量要回想一下出现这个问题时，自己的操作步骤，测试版本，以及测试环境情况是什么，这些都要描述清楚。
2.这类问题要通知开发人员进行了解，圈定范围，在适当的时候进行跟踪修改。
3.如果开发人员也无法定位出原因，那么就暂时搁置，但是不要删除，在后续测试版本中，对于这类问题也要重点跟踪测试，一旦出现，要马上保留现场，及时联系开发人员进行检查。
我来说两句
对于不可重现的缺陷的处理方法1找出不可重现的原因
俗话说无风不起浪，有因必有果，既然曾经有过这样的结果肯定是有原因的，好多测试人员都把不可重现的缺陷置之不理，这些测试人员中不乏经验较多的老测试人，因为他们觉得既然不可重现何必要找呢，其实这样的想法是错误的，如果经常出现这样的问题难道你还真的置之不理吗，量变达到质变
那我们如何下手呢，有心之人可发现不可重现无非是一下几种原因
1)开发人员改的过程中出现的
由于程序的不完全，就会出现怪异的现象，这个很常见
程序的不稳定造成的，由于程序的健壮性差一会这样一会那样，也会出现
网络延迟，这也是其中的一个原因
浏览器问题，有些程序不支持多浏览器每种浏览器表现都不一样
操作系统也是原因之一
2 找到原因，记录下来进行备案，以便以后的遇到相似情况进行相应的处理
3完善的规章制度
很多时候开发人员不管测试人员是否把这个测试完毕就乱改程序，及时你找到他，他就会说我还没时间呢我不改怎么办，所以完善的制度是必然的这也是开发人员和测试人员避免冲突的好办法 既然题目已经说了是“不可重现”，3楼的1；4楼的1，2，3；5楼的1就没必要再提了。除非是怀疑出题人的智商。人家说不可重现了，你说你再用我的方法试试。
7楼说不可重现的缺陷是非常严重的。不同意。缺陷的严重与否与其是否容易复现没有什么关系。
9楼，往往不可重现的bug多是一些意外状况的发生，意外发生前，没人会去记录。
11楼的版主回答带有其所从业的行业特征。
没什么新鲜的观点，基本上大家都认为必须记录下来，以备再次出现时参考。个人的经验，没必要太在意这种偶发的几乎不能再次复现的bug。在用户那里再次出现的概率也非常低，花费精力去研究它不合算。
我相信所有研发人员都会非常“痛恨”一个“敬业”的测试人员天天跑来跟他讨论不可重现的缺陷“可能出现的原因”。
[ 本帖最后由 black_tulip 于 2009-3-18 16:57 编辑 ] 1.尽可能的描述清楚该缺陷的重现方式，尽可可能的提供系统信息，包括相关可能的设置；
2.在缺陷管理针对不可重现的缺陷增加一个字段，方便他人查看，若再出现了不可重现的缺陷，可以通过该字段过滤查看，确认是否之前已经在被其他测试人员发现过，如果是已经发现过的，可以在原描述基础上继续补充；
3.对这些不可重现的缺陷进行过期作废的处理方式，这个可以根据测试周期进行安排，对于过期的缺陷不予以理会。 我也同意对于"不可重现"的bug不必太在意！
因为危害性严重的Bug必然是可以重现的！
对于"不可重现”的Bug,我顶多会
1）自己重复多次
2）请其他测试人员重复
3）检查系统的Log，看有没有Exception出现。因为有的时候即使无法再现出错的场景，
系统也可能会产生一些Exception, 好的系统还会记录下来。 3.对这些不可重现的缺陷进行过期作废的处理方式，这个可以根据测试周期进行安排，对于过期的缺陷不予以理会。
完全赞同bee先生的这句。 相信很多测试人员都遇到过不能重现的问题.既然不能重现,那接下来就是个原则态度问题:对不能重现的问题,既不能说没问题,因为问题的确发生过;又不能在这个问题上死钻牛角尖,浪费大量时间精力.
对于不可重现问题,做法通常有以下三步:
1,提交BUG相关现象描述
2,说明该BUG为不能重现
3,对该BUG不做关闭处理
