如何看待那些不能重现的bug？

　　在我们日常测试活动中，经常会发现一些bug，但是这些bug可能就是昙花一现，再也无法（或者很难）重现出来，内心灰常崩溃。那到底有哪些方面可能会导致这类的缺陷发生呢？

我以自己工作中所遇到的给出一些自己的总结，当然如有补充请自行添加。

一．环境问题

这个问题导致的缺陷无法重现的情况还是比较多的，测试和开发环境的不一致可能导致开发那边缺陷无法重现，还有实际运行环境和我们测试的环境不一致。如（硬件的配置，软件的配置，网络因素），当然极少数是系统内部问题或者时间触发的（这类bug重现非常困难）

二．操作问题

很多时候我们在执行测试用例的时候会不经意间做了一些其他操作，这种不经意间完成，而又忽略了这一操作，以至于很难重现。

还有一种是没有找到正确的引发bug的操作顺序，因为很多bug需要满足多个条件。在满足这些条件下再去做某些操作，才能够被触发。

三．特殊数据

有些bug需要使用特殊数据才会出现，并且往往我们测试人员没有意识到自己用的数据的特殊性，导致后面很难去重现。

四．内存泄露或锁

有一些系统只有经过长时间运行才会暴露出bug，这个问题也很难重现。需要经过长时间的测试才能确认以及特殊情况下数据锁的问题，导致的一些bug都很难重现

遇到这种问题，我们应该如何做呢？

（1）提交（不要因为没重现出来，可能是自己眼花而不提）

把不可重现的BUG记录下来，以后再遇到的时候可能就会了解发生的原因。同时尽力去查找出错的原因，比如有什么特别的操作，或者一些操作环境等。而且程序员对程序比测试人员熟悉的多，因为测试人员看到的只是程序的外部，无法深入程序内部，也许你提交了，即使无法重新，程序员也会了解问题所在。无法重现的问题再次出现后，也可以直接叫程序员来看看问题。

但是针对一些比较严重的、随机发生无法重现的bug，测试人员提交上去后，有可能会出现以下三个情形：a．开发人员试图重现，重现不出，Reject回来；b．开发人员找不到规律，所以不去解决，问题一直处于Open状态；c．开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。

（2）尽量详细的描述缺陷

尽可能的详细记录BUG产生的相关信息；如重现频率，发生情况并有截图，操作步骤，软件的版本，发生错误时的各种变量、内存、存储器等存储的数据内容，软件出错时的软硬件环境等。

（3）由开发人员进行人工代码走查和工具静态检查

无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。或者采用静态检查工具（如pclint,splint等工具）检查代码，消除所有的error与warning。

（4）受限于浏览器的需要检查浏览器版本和浏览器配置

对于浏览器设置不正确引起的BUG，设置好浏览器选项，就能使BUG重现。

　　总之，在遇到某些严重的、却又无法重现的Bug，应积极回忆BUG的症状和所有的环境因素，一丝一毫的细节都不要错过。并与开发人员、DBA、系统设计人员、项目经理等一起分析那些环境因素，根据以往的经验分析影响此Bug重现的重要因素，并在相同的环境上安装同样的系统进行测试，以验证所做的猜测。而对于某些无法重现、但严重程度不是很高的Bug，可以暂时只作记录、而不必花费大量的人力和物力去分析。如果下次又出现了，那么根据发生的频率再去分析是否需要跟踪此Bug。如果需要跟踪它，那么在它又出现后一定要立刻对当时的环境进行截图，如错误信息、界面、日志等。这样也利于开发人员定位、分析它，从而准确、快速地修复它。如果条件允许，测试人员应立即保护现有环境，并邀请相关的开发人员和系统分析人员一起研讨产生此问题的原因和解决方法。