對很多測試人員（尤其是對新手來說）在工作過程中最不愿遇到的一件事情就是：在測試過

程中發(fā)現(xiàn)了一個問題，覺得是?bug，再試的時候又正常了。

碰到這樣的事情，職業(yè)素養(yǎng)和測試人員長期養(yǎng)成的死磕的習性會讓她們覺得不能放過這個

bug，但是重現(xiàn)這樣的?bug?有時候需要花費大量的時間，有的時候還有一些盲目性（因為黑

盒測試的緣故，很多內部狀態(tài)是不可見的，因此無法獲取有效的信息來做跟蹤），效率較為

低下。

在實際工作中，時間和進度擺在那里，在經歷了多次痛苦的失敗嘗試之后，測試人員的處理

方法一般會有如下幾種：

????????1.向開發(fā)人員尋求幫助來重現(xiàn)?bug；

????????2.當做一個?issue?報給開發(fā)人員。

可是這樣的做法存在如下問題：

????????1.開發(fā)人員責任心不夠強，不愿意花太多精力去求證這件事情，常見的回復就是：在我這兒

沒事兒啊，我也重現(xiàn)不了，bug?關了吧。結果隨后在生產系統(tǒng)上，bug?又開始隨機出現(xiàn)了。

????????2.就跟測試人員不擅長編碼和調試一樣，開發(fā)人員并不擅長找出?bug。經過一番嘗試以后，

他們也找不出什么問題來，常見的回復同第一條是一樣的。bug?上線后又出現(xiàn)的宿命也是一

樣的。

這時候，真正的問題來了：如何捕捉難以重現(xiàn)的?bug？這件事兒對于測試人員來說就這么難

么？

????????答案并不那么樂觀，重現(xiàn)“難以”重現(xiàn)的?bug?本來就是一件“難以”完成的事情。但“難以”并不

是不可能，通過一系列的測試、分析方法，我們是能夠抽絲剝繭把絕大部分隱藏的很深的

bug?揪出來的，當然有的時候你要考慮投入產出比，但投入產出比不是本篇要考慮的，本篇

只講一些我積累的經驗。

為什么不能重現(xiàn) bug？

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

我曾經做過一段很長時間的收集和統(tǒng)計，那些被稱作過“難以重現(xiàn)”的?bug?最后都可以分為如

下幾類：

????????1.環(huán)境的變更造成了?bug?難以重現(xiàn)，這里的環(huán)境包括了：基礎軟硬件環(huán)境（操作系統(tǒng)、網絡、

存儲、中間件、容器等等），被測物自身發(fā)生了某些變更。環(huán)境的變更一般是由于多人共用

環(huán)境造成的，也有少量情況下是系統(tǒng)內部或者時間觸發(fā)的變更（這類?bug?非常難重現(xiàn)）。

????????2.沒有找到真正引發(fā)?bug?的操作。這些操作往往是一些不怎么顯而易見的操作，測試人員在

不經意間完成，而又忽略了這一操作，以致難于重現(xiàn)?bug。

????????3.沒有找到真正會引發(fā)?bug?的操作序列。很多?bug?的重現(xiàn)需要滿足多個條件。在滿足多個條

件的狀態(tài)下，你做了對應的操作，bug?才會被觸發(fā)。

????????4.Bug?必須使用特殊的數(shù)據才會出現(xiàn)，測試人員沒有意識到她使用的數(shù)據的特殊性。一種比

較難搞的情況是：同一組輸入，在不同情況下（不是不同的業(yè)務情況）輸入會被轉化成不同

的數(shù)據。我曾經見到過這么個例子，程序員用系統(tǒng)當前時間作為隨機數(shù)的種子來生成?id，但

是?id?設置的比較短，一個存儲的操作使用這個?id，在一些情況下，發(fā)生了沖突，當時做功

能測試這種小概率事件耗費了測試人員大量時間也沒有穩(wěn)定重現(xiàn)，還是在性能測試的階段測

試了出來。

????????5.測試人員由于錯誤操作，出現(xiàn)了誤報（這很常見）。比如，記得自己執(zhí)行了?step3,其實沒

有，或者沒有正確執(zhí)行?step?卻覺得正確執(zhí)行了。

怎樣對付這樣的 bug 呢？

我喜歡?James Bach?說的那句話：測試就像?CSI。CSI?是?CriminalScene Investigation?的縮寫，

也是我非常喜歡的美國系列劇。

從我來看?CSI?的精髓在于：仔細觀察，詳細記錄，科學分析，嚴密推理，有序求證，大膽

假設，持續(xù)不懈，團隊協(xié)作和一點兒運氣。找?bug?其實和?CSI?探員做犯罪現(xiàn)場調查沒什么

太大區(qū)別。得知道，你工作的重要性一點兒不亞于?CSI?探員。

仔細觀察

第一件事情就是要觀察，觀察你所做的一切操作和一切相關的系統(tǒng)反饋。在一開始，觀察的

重要性要遠遠大于思考，通過觀察你獲得蛛絲馬跡，這些蛛絲馬跡是你進行思考和假設的關

鍵輸入。例如，我在一次測試的過程中，發(fā)現(xiàn)做某種操作的時候會相當慢，極少數(shù)情況下還

報錯過一兩次，當詢問了開發(fā)人員后得知這個操作的后臺實現(xiàn)步驟是：先查看數(shù)據是否在緩

存中，如果不在，則從遠端服務器請求數(shù)據。我抓住少數(shù)情況下會報錯的這一現(xiàn)象，仔細觀

察它的出錯信息后猜測報錯并不是因為網絡連接不穩(wěn)定引起的，而是由于遠端服務接口實現(xiàn)

有問題引起的，后來重新設計了測試用例，果然找到了問題所在。如果不仔細觀察出錯信息，

就會聽信開發(fā)人員認為這是網絡不穩(wěn)定引發(fā)的正常?issue?而錯過這個?bug。

詳細記錄

詳細記錄你的操作步驟及返回結果非常有助于回朔問題，也有助于后續(xù)分析。準備一個?word

文檔，和截圖工具有時候非常必要。另外，在觀察的時候，你不僅要注意被測物的最終返回，

還需要觀察過程中的一些中間狀態(tài)，往往這些中間狀態(tài)提供的信息才是解開問題的關鍵。這

些中間狀態(tài)一般會被記錄在?log?文件中，因此知道你的被測物是如何記?log?的，log?被記錄

在哪里非常重要。log?給了你另外一個看系統(tǒng)的角度。log?是有級別的，如果級別可以動態(tài)

調整，在找比較難找的?bug?時，可以將?log?記錄的級別調至最低（DEBUG?級）讓它們記錄

更多內容。利用系統(tǒng)的錯誤轉儲文件（比如?linux?的?core dump?文件，windows?下也有相應

的記錄轉儲文件的方式）分析也是個不錯的辦法（需要較高技術能力），但一般建議測試人

員把這些轉儲文件交給更專業(yè)的開發(fā)人員來分析。

除了?Log，如果能有監(jiān)控信息，也要查看他們。比如系統(tǒng)提供的監(jiān)控平臺，監(jiān)控日志；應用

自己的監(jiān)控平臺、監(jiān)控日志（如果有的話）；采用一些外部技術手段截取一些中間狀態(tài)信息，

如使用?sniffer?抓取通訊包，使用?Fiddler?截獲?HTTP?報文內容；給運行程序插樁來查看內存，

堆棧，線程，函數(shù)被調用情況等情況，如?Jprofile，gpertool?等等。

科學分析

對于黑盒測試人員來說，科學分析意味著你需要有一定的分析策略。我們需要采取一些形式

化的方法來完成我們的分析?；谖业慕y(tǒng)計，缺陷難以重現(xiàn)有很大一部分原因是因為“沒有

找到真正引發(fā)?bug?的操作序列“。測試人員不可能像開發(fā)人員那樣去跟入到代碼內部，設置

斷點調試程序，他們主要的測試方式是直接來操縱被測物，并從外部觀察被測物狀態(tài)的改變。

顯而易見，“狀態(tài)轉換圖分析法”是測試人員對付“難以重現(xiàn)?bug”的最強有力武器之一。狀態(tài)

轉化圖能夠幫助測試人員很好的選擇操作路徑，并且知道這么做有什么意義?！盃顟B(tài)圖轉化

法”絕對是測試人員值得花時間學習和研究的一種方法，你可以走的很深，也可以研究得很

遠（可以從?MBT?的方向進行拓展），限于篇幅，這里就不展開了。在這里推薦《探索吧！

深入理解探索式軟件測試》這本書，它的第八章對“狀態(tài)轉換”做了非常實用的描述。

上文分析的讓?bug?難于重現(xiàn)的另一種原因是沒有找到“真正引發(fā)?bug?的特殊數(shù)據”。

我的常用做法是這樣的：

1.畫出系統(tǒng)交互圖（要真正弄清系統(tǒng)的邊界，這很重要），并識別出每種交互會有什么樣的

輸入、輸出數(shù)據和中間數(shù)據，識別出這些數(shù)據的規(guī)約和格式，這樣你就不會對數(shù)據有遺漏。

2.考慮數(shù)據的等價類、邊界值，對這些輸入進行組合，分析數(shù)據之間是否有耦合關系，如果

有耦合關系，弄明白關系是什么，設計違背這些關系的用例，最后采用組合測試工具初步生

成測試集，再人工選取最可能出問題的數(shù)據集（直覺有時候非常管用）。

嚴密推理

天馬行空對測試人員很重要，但是當你試圖重現(xiàn)一個?bug?的時候，這并不是一個非常好的方

法。抓住了蛛絲馬跡，你就要推理是為什么產生了這種蛛絲馬跡。限于工作性質，測試人員

更多的會從：業(yè)務完整性、數(shù)據完整性、業(yè)務正確性、數(shù)據正確性等方面考慮問題。但是，

如果測試人員對被測物的?IT?架構有比較深入了解的話，推理的范圍會擴大到技術實現(xiàn)層面，

如：多線程可能引發(fā)的問題，網絡引發(fā)的問題，excepiton?處理不當引發(fā)的問題，全局事務

設計不當引發(fā)的問題，內存泄漏引發(fā)的問題，數(shù)據庫表設計不合規(guī)引發(fā)的問題等等等等，這

些會讓你的分析推理能力如虎添翼。當然，如果限于條件，測試人員不具備這類能力，則應

該在適當?shù)臅r候請求開發(fā)人員協(xié)助。

有序求證

這里只有一點需要注意。那就是，在求證的過程中不要打散彈槍，按照你的推理一步一步的

來，一個個推理的來驗證，一次只引入一處修改。這樣才能讓你的捕蟲網編制的足夠細密。

大膽假設

有的時候，看似八竿子打不著的東西竟然存在著千絲萬縷的聯(lián)系，而你獲取信息的過程總是

一個由少及多的過程，一開始這些聯(lián)系是無法被識別出來的。通過推理，逐步驗證，你慢慢

的識別出了大部分內在聯(lián)系。但有時候這種逐步推進的工作也會有局限性，工作如果出現(xiàn)了

瓶頸（你試遍了你所有的假設，都沒有重現(xiàn)?bug），這時候就需要發(fā)揮一點兒想象力了，天

馬行空這時候從一定程度上又變得有用起來，當然天馬行空也不是無厘頭，還得靠我們所謂

的“靈光一閃”，這號稱是潛意識在幫助你。CSI?的劇情中不也總是出現(xiàn)這種柳暗花明的橋段

么？

堅持不懈

話不多說，有的時候你差的就是那么一點兒點兒耐心。

團隊協(xié)作

很多情況下，重現(xiàn)?bug?不是一個人能搞定的。我們需要測試環(huán)境?ready，測試數(shù)據?ready，各

種監(jiān)控、分析工具?ready，各種不同的視角開拓思路、加深對被測試物的認識。這是?team

work！！！獨行俠有時候很管用，但是終究有極限。這就是為什么?CSI?是一票人在做而不

是一兩個人在做。

一點兒運氣

說實在的，有的時候重現(xiàn)?bug?就是靠運氣，你不得不承認這一點。事實上很多美好的事情發(fā)

生都得依靠運氣，比如中彩票。要記住的一點是，運氣是建立在你不懈努力的基礎上的。如

果你一張彩票不買，你肯定什么也中不了。但如果你堅持買上幾年，中個五塊十塊甚至二百

也不是夢。

Let it go

全試過了，連運氣都沒有。你只能放手，回到最上面我說的那兩條了：找開發(fā)來幫忙，或者

給開發(fā)報?issue。btw，即使不能重現(xiàn)?bug，也應該給開發(fā)人員提供更多信息：如?log、dump

文件、監(jiān)控記錄、屏幕截圖等。做一個負責人的測試人員，把煩惱真實的留給下家，這很重

要：）

其實上面的大段論述是站在測試人員角度上來看的。我也寫很多代碼，作為一個開發(fā)人員（哈

哈）我查錯的方式一般是：

1.先能穩(wěn)定的復現(xiàn)錯誤。（這一步最難）

2.設樁，打印出一些中間狀態(tài)來分析，看到那一塊兒錯了。

3.摘除不相干的代碼，慢慢迭代，定位錯誤。

4.如果發(fā)現(xiàn)調用第三方依賴跟你想的不一樣，先讀文檔，然后再測試第三方依賴。有問題再

想辦法。

5.良好的程序設計和單元測試覆蓋度才是不二法門，會讓你的調試變得簡化的太多。。。用

過都說好：）

6.測試工作的確增強了我排錯的能力。coding?的同學都嘗試做幾個月測試吧。會有相當大的

好處。