這時候，真正的問題來了：如何捕捉難以重現的bug？這件事兒對於測試人員來說就這麼難麼？

答案並不那麼樂觀，重現“難以”重現的bug本來就是一件“難以”完成的事情。但“難以”並不是不可能，通過一系列的測試、分析方法，我們是能夠抽絲剝繭把絕大部分隱藏的很深的bug揪出來的，當然有的時候你要考慮投入產出比，但投入產出比不是本篇要考慮的

為什麼不能重現bug？     

最大的原因就是：測試人員對被測物的瞭解還不夠深入。

我曾經做過一段很長時間的收集和統計，那些被稱作過“難以重現”的bug最後都可以分為如下幾類：

• 環境的變更造成了bug難以重現，這裡的環境包括了：基礎軟硬體環境（作業系統、網路、儲存、中介軟體、容器等等），被測物自身發生了某些變更。環境的變更一般是由於多人共用環境造成的，也有少量情況下是系統內部或者時間觸發的變更（這類bug非常難重現）。

• 沒有找到真正引發bug的操作。這些操作往往是一些不怎麼顯而易見的操作，測試人員在不經意間完成，而又忽略了這一操作，以致難於重現bug。

• 沒有找到真正會引發bug的操作序列。很多bug的重現需要滿足多個條件。在滿足多個條件的狀態下，你做了對應的操作，bug才會被觸發。

• Bug必須使用特殊的資料才會出現，測試人員沒有意識到她使用的資料的特殊性。一種比較難搞的情況是：同一組輸入，在不同情況下（不是不同的業務情況）輸入會被轉化成不同的資料。我曾經見到過這麼個例子，程式設計師用系統當前時間作為隨機數的種子來生成id，但是id設定的比較短，一個儲存的操作使用這個id，在一些情況下，發生了衝突，當時做功能測試這種小概率事件耗費了測試人員大量時間也沒有穩定重現，還是在效能測試的階段測試了出來。

• 測試人員由於錯誤操作，出現了誤報（這很常見）。比如，記得自己執行了step3,其實沒有，或者沒有正確執行step卻覺得正確執行了。

怎樣對付這樣的bug呢？

我喜歡James Bach 說的那句話：測試就像CSI。CSI是CriminalScene Investigation 的縮寫，也是我非常喜歡的美國系列劇。

從我來看CSI的精髓在於：仔細觀察，詳細記錄，科學分析，嚴密推理，有序求證，大膽假設，持續不懈，團隊協作和一點兒運氣。找bug其實和CSI探員做犯罪現場調查沒什麼太大區別。得知道，你工作的重要性一點兒不亞於CSI探員。

科學分析：對於黑盒測試人員來說，科學分析意味著你需要有一定的分析策略。我們需要採取一些形式化的方法來完成我們的分析。基於我的統計，缺陷難以重現有很大一部分原因是因為“沒有找到真正引發bug的操作序列“。測試人員不可能像開發人員那樣去跟入到程式碼內部，設定斷點除錯程式，他們主要的測試方式是直接來操縱被測物，並從外部觀察被測物狀態的改變。顯而易見，“狀態轉換圖分析法”是測試人員對付“難以重現bug”的最強有力武器之一。狀態轉化圖能夠幫助測試人員很好的選擇操作路徑，並且知道這麼做有什麼意義。“狀態圖轉化法”絕對是測試人員值得花時間學習和研究的一種方法，你可以走的很深，也可以研究得很遠（可以從MBT的方向進行拓展），限於篇幅，這裡就不展開了。在這裡推薦《探索吧！深入理解探索式軟體測試》這本書，它的第八章對“狀態轉換”做了非常實用的描述。

上文分析的讓bug難於重現的另一種原因是沒有找到“真正引發bug的特殊資料”。

我的常用做法是這樣的：

• 畫出系統互動圖（要真正弄清系統的邊界，這很重要），並識別出每種互動會有什麼樣的輸入、輸出資料和中間資料，識別出這些資料的規約和格式，這樣你就不會對資料有遺漏。

• 考慮資料的等價類、邊界值，對這些輸入進行組合，分析資料之間是否有耦合關係，如果有耦合關係，弄明白關係是什麼，設計違背這些關係的用例，最後採用組合測試工具初步生成測試集，再人工選取最可能出問題的資料集（直覺有時候非常管用）。

大膽假設：有的時候，看似八竿子打不著的東西竟然存在著千絲萬縷的聯絡，而你獲取資訊的過程總是一個由少及多的過程，一開始這些聯絡是無法被識別出來的。通過推理，逐步驗證，你慢慢的識別出了大部分內在聯絡。但有時候這種逐步推進的工作也會有侷限性，工作如果出現了瓶頸（你試遍了你所有的假設，都沒有重現bug），這時候就需要發揮一點兒想象力了，天馬行空這時候從一定程度上又變得有用起來，當然天馬行空也不是無厘頭，還得靠我們所謂的“靈光一閃”，這號稱是潛意識在幫助你。CSI的劇情中不也總是出現這種柳暗花明的橋段麼？

一點兒運氣：說實在的，有的時候重現bug就是靠運氣，你不得不承認這一點。事實上很多美好的事情發生都得依靠運氣，比如中彩票。要記住的一點是，運氣是建立在你不懈努力的基礎上的。如果你一張彩票不買，你肯定什麼也中不了。但如果你堅持買上幾年，中個五塊十塊甚至二百也不是夢。

Let it go：全試過了，連運氣都沒有。你只能放手，回到最上面我說的那兩條了：找開發來幫忙，或者給開發報issue。btw，即使不能重現bug，也應該給開發人員提供更多資訊：如log、dump檔案、監控記錄、螢幕截圖等。做一個負責人的測試人員，把煩惱真實的留給下家，這很重要：）

最後，附上一個實戰思路：

如果你沒有辦法穩定的復現bug，可以通過概率統計的方式將問題反饋。如果10次裡出現一次問題，不足以打動開發人員重視問題，可以通過自動化測試的方式提高執行次數的數量級，如果一千次出現50次~100次。這個問題就足夠引起重視了。在negotiate的時候，這是一種好思路。

3.多讀一些其它書籍，不限於技術書籍。如果想讀的書有利於工作，推薦一些如何做思辨思維的書。《思考的藝術》《六頂思考帽》《你的燈亮著麼》《學會提問》是我喜歡的4本書。

它們會教你怎麼獨立思考，養成提問的習慣，而提問的習慣是我們現在的測試人員最缺乏的一件事情。人們往往拿了被測物就開始忙著寫用例，忙著測試。而不是先探索它、研究它。

當然IT技術也要掌握，如果你的IT技能能夠趕上開發，你發現你做測試的思路會非常的寬廣：）

4.把書籍中的東西跟你的工作對比，把好的東西引入工作（這點是檢驗書本質量的好方法，也是促進你思考，促進你能力提高的好方法）。

6.搞定你所在行業的領域知識：如常見IT技術，常見業務知識，這些知識掌握的越深，你的價值越高。測試技術是內功，但是你能直接為企業帶來價值的最大之處是你對被測物熟悉程度，也就是你的領域知識！！！

7.沒有方向？從你的工作入手，比如，你遇到的最大的難題是什麼？我怎麼解決它？我需要掌握什麼樣的技術解決他？我要推動什麼樣的組織改變來解決它？別人怎麼解決它？有沒有更好的方法？使用後我改進了那些？google一下別人有沒有同樣的問題（回覆wyfq，直接FQ用Google）？嘗試作對比，如果覺得他做得好，嘗試聯絡那個人討論一下。看看對方的進展。嘗試把活兒幹得特別漂亮。你能解決10箇中等問題以後，你的能力會有大幅度提高。 

自動化測試很火熱，我想去學

selenium\appnium很火，我想去學

聽說效能學好了，會很有前途，我想去學

據說，測試掌握了指令碼技能才能很好的發展，我想去學

學Python語言好，還是Java語言好？

OK，如上基本上是多數同學經常問到的問題以及疑惑

老徐觀點：一件事，想清楚目的和本質，你就有答案了；

很多同學，每天都在學習，痛苦的學習，逼迫自己堅持去學，看大家在學什麼，自己也想學，收集了很多很多的資料、視訊去學；

結果：每天都很累，學完還是什麼都不會；

為何？

沒有目標驅動，沒有想過學這些來解決什麼問題，沒想過實際工作中如何把學習的這些內容實踐；當然結果就是，學完第二天就完全忘了！忘了！

正確的學習姿勢是怎樣的？

老徐推崇的是工作中學習、用到再去學習、需要什麼學什麼；

前提：在這之前要打好基礎，否則臨時需要久久不能入門，完全無法切入；

OK，回到開始老徐列出的幾個問題；

很多同學自動化概念都沒搞清楚，自動化能解決什麼問題、什麼情況適合用自動化都沒搞清楚，上來就學qtp等工具，然後說自己會自動化了；

就像，很多同學學效能測試，就是學會如何用LR，重點是很多同學學半天LR還沒學會如何用！

其他一樣，學習一個東西，做一件事，先想清楚這件事的目的是解決什麼問題，它的本質是什麼？

9-從事幾年後，迷茫了？

可以詳細陳述你當前的階段，你的優勢，你的興趣，你掌握的技能；

找老徐聊聊，也許能給你點建議；