問題場景：
有一些比較嚴重的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.換人重新開發相關模塊