13 年的 Bug 調試經驗總結 【轉載】

在《Learning From Your Bugs》一文中，我寫了關於我是如何追蹤我所遇到的一些最有趣的bug。最近，我回顧了我全部的194個條目（從13歲開始），看看有什麼經驗教訓是我能夠學習的。下面是我總結的最重要的經驗教訓，包括編碼，測試和調試三個方面。

 

編碼

下面這些都是我經歷過的會致使難點bug的問題：

1.事件順序。在處理事件時，提出下列問題會頗有成效：事件能夠以不一樣的順序到達嗎？若是咱們沒有接收到此事件會怎麼樣？若是此事件接連發生兩次會怎麼樣？哪怕一般不會發生，但系統（或交互系統）其餘部分的bug可能會致使事件發生呢。

2.過早。這是第一點「事件順序」的一個特例，但它確實會引發一些棘手的bug，所以我把它單獨拎出來講明。例如，若是信令消息在配置和啓動程序完成以前就被過早接收，那麼可能就會有不少奇怪的行爲發生。另外一個例子：鏈接在被放進空閒列表以前就被標記爲down。在調試這類問題時，咱們老是假定在空閒列表中的時候鏈接被設置爲down（但當時爲何不把它放到列表外面呢？）。這是咱們思考的不足，沒有考慮到有時候事情會過早發生。

 

3.悄無聲息的故障。一些最難跟蹤的bug有部分是由那些靜靜失敗並擴展而不是拋出錯誤的代碼所致使的。例如，沒有檢查代碼卻返回錯誤的系統調用（如bind）。又如：解析代碼在它遇到錯誤元素的時候只是返回而非拋出錯誤。在錯誤狀態中持續了一段時間的調用，會使調試變得更難。最好一旦檢測到故障就返回錯誤。

4.If。有若干條件的if語句，if (a 或 b) ，特別是當有連接的時候， if (x) else if (y)，都給我引起了不少bug。即便if語句在概念上很簡單，但當有多個條件要跟蹤的時候依然很容易出錯。這些天，我嘗試重寫代碼使之更簡單，以免處理複雜的if語句。

5.Else。有一些bug是由於沒有正確考慮到若是條件爲false時會發生什麼而引發的。幾乎在全部的狀況下，都應該有一個else部分來應對每一條if語句。此外，若是你在if語句的分支中設置變量，那麼或許你在另外一個分支中也要設置。與此種狀況相關的是標記被設置的狀況。只添加用於設置的標記的條件不難，可是很容易忘了添加當標記應該再次重置時的條件。留下一個永遠設置的標誌可能會致使以後接連不斷的bug。

6.改變假設。許多一開始最難預防的bug是由於改變了假設所形成的。例如，在開始時，可能天天只有一個客戶事件。因而不少代碼是在這樣的假設下寫下的。可是後來，設計改變了，容許天天有多個客戶事件了。發生這種狀況時，很難改變新設計影響到的全部狀況。找到關於改變的全部顯式依賴關係不難，難的是要找到全部隱性依賴於舊的設計的狀況。例如，可能會有獲取給定某一天全部客戶事件的代碼。其中的隱含假設是結果集永遠不會超過客戶的數量。關於這方面的問題我也沒有很好的策略方法，若是各位有的話，還請不吝賜教。

7.日誌記錄。可視化程序作什麼相當重要，特別是當邏輯很複雜的時候。確保補充足夠多的（但不要太多）日誌記錄，這樣你就能夠說明爲何程序要這麼作。若是一切正常，那也不要緊，但要是有問題發生，你會很慶幸本身添加了這些日誌。

測試

做爲一個開發人員，直到要測試了我纔會去處理功能。至少，這意味着每一行新的或改變了的代碼行至少已經被執行過一次。此外，單元測試和功能測試都很不錯，但還不夠。新的功能也必須進行測試，並在相似於產品的環境中探索。只有這樣，我才能說我完成了一個功能。下面是我經歷過的bug所教會個人關於測試的一些重要的經驗教訓：

8.零和null。若是可行的話，確保老是用零和null來測試。對於字符串，這意味着要測試長度爲零的字符串以及字符串爲null兩種狀況。又如：測試TCP鏈接的斷開，要在發送數據給它發送以前。不使用這些組合方法測試是致使bug出現的首位緣由。

9.添加和刪除。一般，新的功能包括可以添加新的配置到系統中——例如，一個用於手機號碼轉換的新的配置文件。測試它可否添加新的配置文件是很天然的。可是，我發現咱們很容易忘記去測試刪除配置文件是否是一樣ok。

10.錯誤處理。處理錯誤的代碼每每是難以測試的。最好有能檢查錯誤處理代碼的自動測試，但有時這是不可能的。我有時會使用的一招是臨時修改代碼，使得錯誤處理代碼運行起來。要作到這一點最簡單的方法是反轉if語句——例如，從if error_count > 0改爲error_count == 0。另外一個例子是拼錯數據庫列名，從而致使指望的錯誤處理代碼運行。

11.隨機輸入。一般，揭露bug測試的一種測試方法是使用隨機輸入。例如，H.323協議的ASN.1解碼使用二進制數據操做。經過發送隨機字節去解碼，咱們發現瞭解碼器中的幾個bug。另外一個例子是用測試呼叫來生成腳本，此時呼叫持續時間，接聽延遲，第一方掛斷等等都是隨機生成的。這些測試腳本會暴露許多bug，特別是一塊兒發生的事件會產生併攏干擾。

12.檢查不該該發生的動做。一般測試包括檢查指望動做是否是發生了。但咱們很容易忽視相反的狀況——忘記檢查不該該發生的動做是否是的確沒有發生。

13.擁有工具。我建立了本身的小工具，以使得測試更加簡單。例如，當我用VoIP SIP協議工做時，我寫了一個可以用正是我想要的標題和值回覆的小腳本。這個工具使得測試不少邊界狀況變得容易起來。另外一個例子是能夠進行API調用的一個命令行工具。經過啓動逐漸添加所需小功能，我獲得了一些很是有用的工具。本身寫工具的好處是，我獲得的正是我想要的。

 

在測試中發現全部的bug，那絕對是不可能的。有一個案例中，我更改了數字相關性的處理，數字由兩個部分組成：路由地址前綴（一般是不變的），以及從000到999動態分配的數字。問題在於當找到相關性時，動態分配的數字的第一個數字會在呈如今表格中以前遭到誤刪。也就是說637變成了37。這意味着，到100以前它都是能夠工做的，所以，前面100個電話是正常的，可是接下來的900個都是失敗。因此，除非我在從新啓動以前可以測試超過100次（事實是我沒有），不然我在測試時就不會發現這個問題。

調試

14.討論。幫助我最多的調試技術是與同事討論問題。一般狀況下，只是和同事說明問題，就會讓我意識到問題的癥結。此外，即便他們不是很熟悉有問題的代碼，他們也每每能提出一些好點子。與同事討論在處理最難的bug時特別有效。

15.密切關注。一般，若是調試問題花了很長時間，每每是由於我作了錯誤的假設。例如，我認爲問題發生在某一方法中，但事實倒是它甚至歷來沒有到達那個方法。或者，被拋出的異常不是我覺得的那個。或者，我認爲軟件的最新版本上正在運行，但實際上是一箇舊版本。所以，必定要覈實細節，而不是假設。人們更容易看到本身但願看到的東西，而不是事實。

16.最近的變化。當曾經能夠正常工做的東西中止工做，那麼這一般是由於最近改變的東西所致使的。在一個案例中，最近的改變只是日誌記錄，可是日誌中的錯誤卻致使了一個更大的問題。爲了更容易找到這種迴歸，認可不一樣的提交會致使不一樣的變化，以及清楚說明這些更改會有所裨益。

17.相信用戶。有時，當用戶報告問題的時候，個人本能反應是，「這是不可能的。必定是他們作錯了什麼事」。但我學會了再也不用這種方式去迴應。更多的時間，事實每每證實，他們所報告的的確是實際發生的狀況。所以，這些天，我開始接受他們所報告的內容的代表價值。固然，我依然會仔細檢查一切是否被正確地設置等等。我見過不少這樣的狀況，讓我明白，由於不尋常的配置或意料以外的用法而致使難以想象的事情的發生，而我默認的假設是，他們是正確的，程序是錯誤的。

18.測試修復。若是bug修復已準備就緒，那就必須進行測試。首先在修復前運行代碼，並觀察該bug。而後應用修復並重複測試案例。到此爲止錯誤行爲應消失。遵循這些步驟能夠確保它確實是一個bug，而且這次修復的確能夠解決這個問題。簡單而有必要。

其餘觀察結果

在這13年來我一直在跟蹤我所遇到的最棘手的bug，不少事情由此而改變。我工做太小的嵌入式系統，大的電信系統以及基於web的系統。我使用過C ++，Ruby，Java和Python。在工做於C++時所遇到的幾類bug已經徹底消失，像堆棧溢出，內存損壞，字符串問題和某種形式的內存泄漏。

其餘問題，如循環錯誤和邊界狀況，我看到的要少得多。可是，這並不意味着那裏沒有bug。這篇文章中的經驗教訓旨在幫助減小編碼，測試和調試三個階段的bug。若是你們有什麼有用的預防和發現bug的技術方法，歡迎不

譯文連接：http://www.codeceo.com/article/13-years-bug.html
英文原文：Lessons From 13 Years of Bugs
翻譯做者：碼農網 – 小峯