缺陷不可重现的情况有很多种，按照我个人的工作经验和理解可以分为一下几类。
1. 自动化工具执行回归测试发现缺陷，之后单跑一个测试用例不会无法重现
2. 自动化工具执行测试用例发现缺陷，之后手动无法重现问题
...
仔细看了下25楼的12345，针对4和5，我认为：
4 建议使用带有打印信息的版本重新FREE TESTING。
5 a-d的这个步骤，这是必须的。在完成这个步骤后还是无法重现的bug才称为不可重现的bug。 除了以上大家说的：截屏，重复之前操作，记录之外，个人觉得还有一个很好的办法就是查看后台的操作日志，很可能当时后台日志也已经抛错了，那么可以让开发人员帮忙分析日志找出出错原因。 楼上的说的好，可以查看后台记录，或者其他的操作以及系统运行记录，查看是不是机器出错。 看了许多人的回复，说了不少，也分析的很到位，但觉得大部分都偏题了
个人理解，这个题目的本意是针对那些不可重现的BUG，其前提已经指定
很多人都分析了不可重现的原因，也有很多人都在分析说明测试中如何避免这种情况的发生，但真正说到点上，即，发生不可重现BUG时如何处理的人，真的很少
对此，感到非常遗憾，本来是抱着想找到对这么一个人人都会遇到问题的妥善解决道
最后说下个人理解，
不可重现BUG原则之一，不可关闭，起码在最近几个版本之内都不应关闭，最好是一直挂起状态；
原则之二，建立BUG跟踪流程，跟踪的BUG应当包括测试中不可重现的BUG，也可在测试过程不断补入新的需要跟踪的BUG，即使是已经关闭的BUG。类似于版本review吧；
原则之三，任何不可重现的BUG，都需要进行仔细分析，即使当前版本没有时间做这事，回过头来，还是需要进行仔细研究。不可重现的BUG最令人担心的不是BUG本身，而是隐藏在背后的风险，我们很可能只是偶然发现了冰山一角。 1、毫无疑问，第一反应就是抓图，仔细回忆操作步骤以及操作数据，并重复操作，如果系统是基于B/S架构的软件，那么在删除COOKIES、历史记录、脱机文件等信息前后的操作有和区别
2、 既然是不可重现的BUG，那么接下来在操作的过程中从价值上考虑，是否容易重现？严重与否？估量一下有什么潜在的风险？是否值得我们花大量时间让使得它重现？
3、如果有风现存在，就同身边的同事交流探讨可能的原因，再进一步检查软硬件的配置（很有可能与兼容性有关系），并且在多个不同的环境下多次操作
4、可能等到产品发布了还是不能重现的话，入档记录，并跟踪市场及时反馈
[ 本帖最后由 周卫 于 2009-3-22 22:53 编辑 ] 看了一下各位前辈的回答，感觉和题目有点跑题，现在的问题是对于不可重现的缺陷如何处理，重点是处理上，而不是要将不可重现变成重现上
我个人观点：
1、根据记忆力，首先判断不可重现的bug是什么级别的bug，对于级别很低的bug只要记录在案，在一定时期内如果没有发现类似的问题可以忽略过去，如果级别相对较高的bug，可以记录在bug管理系统上，注明问题内容，标注偶发性，并与其他测试小组成员进行沟通
2、与研发进行交流，反馈不可重现的bug描述，在与研发的交流中，看是否能大概确定问题的范围
我大概能想到的就这么多，也请前辈们多多提出其它好的解决方法:lol 对于不可重现的问题：
1.首先，一定要记录下该问题
2.尽量去重现该问题，若不能重现，可以反映给项目组，让项目组来决定该问题的处理方法 对于半年都无法复现的可以Close掉了，没有必要再关注
有些不可会显得缺陷往往是修改了其他bug,顺带修改掉了这个bug 这样的问题,可以添加缺陷库,当确认处理,以后再次出现此问题时,保留现场,待开发人员进行分析 不可重现的bug通常是有操作的随机性及系统的不稳定性造成的，本身来讲属于bug，但很容易被忽视，而在软件投入使用后，形成多种多样的错误，影响非常严重，所以必须重视这类bug的产生。
比较好的做法是：
对bug进行分类统计，记录bug， 分析一段时间bug的分布状态，参照历史数据，确定系统的稳定性。 突然想到一个问题：
对于不可重现的缺陷的处理是主题，但是要是延伸下，如果用例设计的完善，细致的话，是否可以最大程度的避免不可重现问题的产生呢？步骤详细的话，基本上在其中一步出错了的话，之前的动作就全清楚了。
当然我指的是按用例测试的情况，而不是freehand，相信测试出来的BUG大多数应该是通过用例产生的，而不是freehand产生，这样不好跟踪。 尽量重现，否则也要留档备用
