不可复现的bug，如何确定及解决该问题

问题场景：
有一些比较严重的BUG随机发生，难以查找规律的，测试工程师提交上去后，有可能会出现以下三个情形：
1．开发人员试图重现，重现不出，Reject回来；
2．开发人员找不到规律，所以不去解决，问题一直处于Open状态；
3．开发人员因为问题难以解决，所以直接Resolved回来，觉得反正是偶发的，先改成解决状态再说。
 

对开发人员、项目经理和测试工程师来说，正确的处理方法应该是怎样的?

1>bug不能重现的原因

      1.环境的变更造成了bug难以重现，这里的环境包括了：基础软硬件环境（操作系统、网络、存储、中间件、容器等等），被测物自身发生了某些变更。环境的变更一般是由于多人共用环境造成的，也有少量情况下是系统内部或者时间触发的变更（这类bug非常难重现）。

      2.软件的版本：确认发现BUG程序版本和重现的代码是一致的，可通过tag(Clearcase应该叫Label)或者Revision号来标注。

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

      4.bug必须使用特殊的数据才会出现，测试人员没有意识到她使用的数据的特殊性。一种比较难搞的情况是：同一组输入，在不同情况下（不是不同的业务情况）输入会被转化成不同的数据。我曾经见到过这么个例子，程序员用系统当前时间作为随机数的种子来生成id，但是id设置的比较短，一个存储的操作使用这个id，在一些情况下，发生了冲突，当时做功能测试这种小概率事件耗费了测试人员大量时间也没有稳定重现，还是在性能测试的阶段测试了出来。

　　5.测试人员由于错误操作，出现了误报（这很常见）。比如，记得自己执行了step3,其实没有，或者没有正确执行step却觉得正确执行了。

2>如何解决该问题

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

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

    3.人工代码走查：无法重现的代码找对系统最熟悉的开发人员重新Review代码，最好是多人一起查。查代码还找不出来，就要检查操作系统、应用服务器及其环境是否有问题，是否有兼容性问题。

    4.工具静态检查：采用静态检查工具（如pclint,splint等工具）检查代码，消除所有的error与warning。记住：可能出现问题的地方一定出现问题！

    5.换人重新开发相关模块