該樓層疑似違規已被系統折疊 隐藏此樓檢視此樓
在我們日常測試活動中，經常會發現一些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。如果需要跟蹤它，那麼在它又出現後一定要立刻對當時的環境進行截圖，如錯誤資訊、界面、日志等。這樣也利于開發人員定位、分析它，進而準确、快速地修複它。如果條件允許，測試人員應立即保護現有環境，并邀請相關的開發人員和系統分析人員一起研讨産生此問題的原因和解決方法。