bug已經成為程序員工作中的一部分，作為從事嵌入式軟件開發已有六年的我，經手的bug也不少了。先說說自己對于bug的心態變化吧，剛開始工作的時候，自己還是很喜歡bug的。那時，自己是負責維護別人的代碼，如果發現了bug，說明自己工作有成績；后來，自己開始碼代碼，這個時候測試人員告訴我有bug，自己就有些心煩，尤其是當領導知道了這個bug以后，就會感到很大壓力；再后來，經手的bug變多了，也變得淡定多了，而且還逐漸建立自己分析bug的工具箱和分析流程；現在，經過幾年的工作，積累了一些經驗，開始在設計和編碼階段，就盡量考慮周全，以減少bug的產生。

下面就說說自己分析bug的一些心得：

1. 建立一套分析bug用的工具箱

正所謂，“工欲善其事，必先利其器”，分析bug有一套得心應手的工具很重要。我的工具箱里就有：網絡抓包工具（用來分析網絡相關問題的），讀取、解析日志的工具、獲取設備運行狀態的工具，另外，還配有解壓工具、UltraEditor等等小程序的安裝程序（因為有些測試用的電腦上沒有安裝這些軟件）。我將這些工具放到一個文件中，并將其放在U盤中，一旦測試人員告知有bug存在，我就揣著U盤過去。這個“竅門”的來歷緣于自己一段痛苦的經歷，自己有段時間膝蓋疼，特別討厭爬樓梯，但是當時測試人員在開發人員的樓下，因此，常因為測試人員的電腦上沒有自己想要的工具，自己不得已只能爬上爬下地用U盤拷貝工具。痛苦之下，就想出了上面的那個辦法，呵呵。

2. 建立一套分析bug的流程或步驟

bug產生后，測試人員告訴開發人員的都是現象，而開發人員要根據測試人員的現象描述去推測。我同事說，查bug就像是在“查案”，一層一層抽絲剝繭地在分析“案情”，不能放過任何蛛絲馬跡。分析bug有的時候就好比在黑暗中行走一樣，常常覺得完全無從下手。經過幾次痛苦經歷后，我逐漸建立一套分析bug的流程或步驟：

1. 獲取當前測試的版本信息；讓測試人員通過版本檢測工具讀取當前測試的版本信息，然后截圖。此舉，可立即確定是否由于版本不正確導致的問題；

2. 讀取設備的運行日志；讓測試人員讀取設備的操作日志和運行日志，交由開發人員解析；

3. 通過設備運行監控工具，獲取設備當前的運行狀態，然后截圖；

4. 通過抓包工具，抓包并且將結果交由開發人員解析；（可選，只針對網絡相關的問題）

5. 將獲得的所有信息，放到一個文件夾中，以bug現象和測試人員姓名命名該文件夾；

這樣的步驟或流程一個最大的好處就是，不會遺漏可用的信息。因此，除非是那種一眼就能定位原因的bug以外，對于所有bug我基本上都會按照上述去做的，其實其目的也很簡單，在還不清楚問題具體情況的狀況下，先盡可能地獲得系統的可以獲得的所有信息，這些信息會為后續分析提供了可參考的信息。這樣做只是麻煩一些，但是絕對沒有壞處。曾經就有幾個很難復現的bug，就是由于缺少對應的日志信息，給我們分析問題原因帶來了極大的麻煩。當時，對于沒有及時獲取更多的信息，非常之懊悔。

將所有信息都放到一個文件夾中，是一個非常好的習慣，這樣所有與之相關的信息就非常好找，更不會出現混亂。另外，上述步驟中，我通常都會要截圖，一方面是自己不太相信測試人員的口述，另外一方面留下足夠的證據，因為有的時候真是口說無憑啊。

3. 針對不同類型的bug，適當區別對待

開發人員有時候可能同時在分析好幾個bug，這就要對這些bug分輕重緩急了。我通常將bug按照復現難度分優先級。越容易復現的bug優先級越低，即使該bug的嚴重等級很高。因為能復現的bug，只要花時間總能夠分析出原因的，但是很難復現的bug就難說了。其實，bug分析和解決有50%取決于該bug能否復現。因此，每當測試人員告訴一個新bug時，我收集了所有信息，并且分析以后有個初步結論以后，我才會讓測試人員破壞環境，讓他復現一下（復現bug可能會導致現象消失，但是不去復現也沒什么可做的了，畢竟所有的信息都收集完了）。如果這個bug很難復現的話，那么我會先推掉其他事情，專心分析這個bug，否則拖得時間越久，越難找到原因。

生命不息，bug不止。面對bug，我們須保持良好的心態，因為它們畢竟已經成為我們工作生活的一部分了，以積極良好的心態面對它們的時候，我們也許就能找到比較好的方法解決它們了，^_^

【后記】

對于模塊很多，功能比較復雜的產品，一旦發生bug，一般很難確定bug的原因。這個時候除了盡可能地收集現場信息以外，還一個分析方法。這個方法很簡單：首先列出會產生這個bug的所有原因，無論列出的原因聽起來，多么不可能，也要列出來，然后逐個去驗證和排除，可以先從可能性最大或者最容易驗證（或排除）的入手。這個方法背后的邏輯是：

1. 面對一個很復雜的bug的時候，我們實際上面對的是一團漆黑，面對的是巨大的不確定性；

2. 人在面對不確定性的時候，會本能地焦慮和慌張；

3. “列出會產生bug的所有原因”，實際上是給我們提供了一個“落腳點”，讓我們在面對不確定性的時候，覺得有事情可做，覺得有“可以入手”的地方，這樣我們在心理上就不會那么焦慮和慌張了；

4. “無論列出的原因聽起來，多么不可能，也要列出來”，目的是不去限制大家的思維，讓大家可以自由地思考和分析；

5. “逐個去驗證和排除每個原因”，目的是盡可能地縮小問題原因的范圍；

6. “先從可能性最大或者最容易驗證或排除的入手”，這一點符合人類的行為習慣——先易后難。

這個方法不能百分之百地保證能夠找到bug的原因，但是它給分析bug提供了一個方向，指引我們的思維和行為，為解決bug提供了一個“落腳點”。本人用這個方法幫助公司解決很多棘手的bug，卻發現了一個有趣的現象：產生bug的最終原因通常不是最開始列出來的那些，^_^。

這個方法的靈感來自于美劇《豪斯醫生》。豪斯醫生在面對每一個疑難雜癥的時候，都會集合助手，一一列出任何可能的病因，然后逐個驗證和排除。而且我發現的那個現象，這個美劇中也有，就是最終的病因通常不是他們最開始列出來的，這也許是編劇故意制造的戲劇化效果吧，哈哈。

【參考文獻】：

1.?美劇《豪斯醫生》