這十年來我做過小的嵌入式系統(tǒng)，大的電信系統(tǒng)以及基于web的系統(tǒng)。使用過C ++，Ruby，Java和Python等。這篇文章中的經(jīng)驗教訓(xùn)旨在幫助減少編碼，測試和調(diào)試三個階段的bug。

下面這些都是我經(jīng)歷過的會導(dǎo)致難點bug的問題：

1.事件順序。在處理事件時，提出下列問題會很有成效：事件可以以不同的順序到達嗎？如果我們沒有接收到此事件會怎么樣？如果此事件接連發(fā)生兩次會怎么樣？哪怕通常不會發(fā)生，但系統(tǒng)（或交互系統(tǒng)）其他部分的bug可能會導(dǎo)致事件發(fā)生呢。

2.過早。這是第一點“事件順序”的一個特例，但它確實會引起一些棘手的bug，因此我把它單獨拎出來說明。例如，如果信令消息在配置和啟動程序完成之前就被過早接收，那么可能就會有很多奇怪的行為發(fā)生。另一個例子：連接在被放進空閑列表之前就被標(biāo)記為down。在調(diào)試這類問題時，我們總是假定在空閑列表中的時候連接被設(shè)置為down（但當(dāng)時為什么不把它放到列表外面呢？）。這是我們思考的不足，沒有考慮到有時候事情會過早發(fā)生。

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

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

5.Else。有一些bug是因為沒有正確考慮到如果條件為false時會發(fā)生什么而引起的。幾乎在所有的情況下，都應(yīng)該有一個else部分來應(yīng)對每一條if語句。此外，如果你在if語句的分支中設(shè)置變量，那么或許你在另一個分支中也要設(shè)置。與此種情況相關(guān)的是標(biāo)記被設(shè)置的情況。只添加用于設(shè)置的標(biāo)記的條件不難，但是很容易忘了添加當(dāng)標(biāo)記應(yīng)該再次重置時的條件。留下一個永遠設(shè)置的標(biāo)志可能會導(dǎo)致之后接連不斷的bug。

6.改變假設(shè)。許多一開始最難預(yù)防的bug是因為改變了假設(shè)所造成的。例如，在開始時，可能每天只有一個客戶事件。于是很多代碼是在這樣的假設(shè)下寫下的。但是后來，設(shè)計改變了，允許每天有多個客戶事件了。發(fā)生這種情況時，很難改變新設(shè)計影響到的所有情況。找到關(guān)于改變的所有顯式依賴關(guān)系不難，難的是要找到所有隱性依賴于舊的設(shè)計的情況。例如，可能會有獲取給定某一天所有客戶事件的代碼。其中的隱含假設(shè)是結(jié)果集永遠不會超過客戶的數(shù)量。關(guān)于這方面的問題我也沒有很好的策略方法，如果各位有的話，還請不吝賜教。

7.日志記錄。可視化程序做什么至關(guān)重要，特別是當(dāng)邏輯很復(fù)雜的時候。確保補充足夠多的（但不要太多）日志記錄，這樣你就可以說明為什么程序要這么做。如果一切正常，那也沒關(guān)系，但要是有問題發(fā)生，你會很慶幸自己添加了這些日志。

測試

作為一個開發(fā)人員，直到要測試了我才會去處理功能。至少，這意味著每一行新的或改變了的代碼行至少已經(jīng)被執(zhí)行過一次。此外，單元測試和功能測試都很不錯，但還不夠。新的功能也必須進行測試，并在類似于產(chǎn)品的環(huán)境中探索。只有這樣，我才能說我完成了一個功能。下面是我經(jīng)歷過的bug所教會我的關(guān)于測試的一些重要的經(jīng)驗教訓(xùn)：

1.零和null。如果可行的話，確保總是用零和null來測試。對于字符串，這意味著要測試長度為零的字符串以及字符串為null兩種情況。又如：測試TCP連接的斷開，要在發(fā)送數(shù)據(jù)給它發(fā)送之前。不使用這些組合方法測試是導(dǎo)致bug出現(xiàn)的首位原因。

2.添加和刪除。通常，新的功能包括能夠添加新的配置到系統(tǒng)中——例如，一個用于手機號碼轉(zhuǎn)換的新的配置文件。測試它能否添加新的配置文件是很自然的。但是，我發(fā)現(xiàn)我們很容易忘記去測試刪除配置文件是不是同樣ok。

3.錯誤處理。處理錯誤的代碼往往是難以測試的。最好有能檢查錯誤處理代碼的自動測試，但有時這是不可能的。我有時會使用的一招是臨時修改代碼，使得錯誤處理代碼運行起來。要做到這一點最簡單的方法是反轉(zhuǎn)if語句——例如，從if error_count > 0改成error_count == 0。另一個例子是拼錯數(shù)據(jù)庫列名，從而導(dǎo)致期望的錯誤處理代碼運行。

4.隨機輸入。通常，揭露bug測試的一種測試方法是使用隨機輸入。例如，H.323協(xié)議的ASN.1解碼使用二進制數(shù)據(jù)操作。通過發(fā)送隨機字節(jié)去解碼，我們發(fā)現(xiàn)了解碼器中的幾個bug。另一個例子是用測試呼叫來生成腳本，此時呼叫持續(xù)時間，接聽延遲，第一方掛斷等等都是隨機生成的。這些測試腳本會暴露許多bug，特別是一起發(fā)生的事件會產(chǎn)生并攏干擾。

5.檢查不應(yīng)該發(fā)生的動作。通常測試包括檢查期望動作是不是發(fā)生了。但我們很容易忽視相反的情況——忘記檢查不應(yīng)該發(fā)生的動作是不是的確沒有發(fā)生。

6.擁有工具。我創(chuàng)建了自己的小工具，以使得測試更加簡單。例如，當(dāng)我用VoIP SIP協(xié)議工作時，我寫了一個能夠用正是我想要的標(biāo)題和值回復(fù)的小腳本。這個工具使得測試很多邊界情況變得容易起來。另一個例子是可以進行API調(diào)用的一個命令行工具。通過啟動逐漸添加所需小功能，我得到了一些非常有用的工具。自己寫工具的好處是，我得到的正是我想要的。

在測試中發(fā)現(xiàn)所有的bug，那絕對是不可能的。有一個案例中，我更改了數(shù)字相關(guān)性的處理，數(shù)字由兩個部分組成：路由地址前綴（通常是不變的），以及從000到999動態(tài)分配的數(shù)字。問題在于當(dāng)找到相關(guān)性時，動態(tài)分配的數(shù)字的第一個數(shù)字會在呈現(xiàn)在表格中之前遭到誤刪。也就是說637變成了37。這意味著，到100之前它都是可以工作的，因此，前面100個電話是正常的，但是接下來的900個都是失敗。所以，除非我在重新啟動之前能夠測試超過100次（事實是我沒有），否則我在測試時就不會發(fā)現(xiàn)這個問題。

調(diào)試

1.討論。幫助我最多的調(diào)試技術(shù)是與同事討論問題。通常情況下，只是和同事說明問題，就會讓我意識到問題的癥結(jié)。此外，即使他們不是很熟悉有問題的代碼，他們也往往能提出一些好點子。與同事討論在處理最難的bug時特別有效。

2.密切關(guān)注。通常，如果調(diào)試問題花了很長時間，往往是因為我做了錯誤的假設(shè)。例如，我認為問題發(fā)生在某一方法中，但事實卻是它甚至從來沒有到達那個方法。或者，被拋出的異常不是我以為的那個。或者，我認為軟件的最新版本上正在運行，但其實是一個舊版本。因此，一定要核實細節(jié)，而不是假設(shè)。人們更容易看到自己希望看到的東西，而不是事實。

3.最近的變化。當(dāng)曾經(jīng)可以正常工作的東西停止工作，那么這通常是因為最近改變的東西所導(dǎo)致的。在一個案例中，最近的改變只是日志記錄，但是日志中的錯誤卻導(dǎo)致了一個更大的問題。為了更容易找到這種回歸，承認不同的提交會導(dǎo)致不同的變化，以及清楚說明這些更改會有所裨益。

4.相信用戶。有時，當(dāng)用戶報告問題的時候，我的本能反應(yīng)是，“這是不可能的。一定是他們做錯了什么事”。但我學(xué)會了不再用這種方式去回應(yīng)。更多的時間，事實往往證明，他們所報告的的確是實際發(fā)生的情況。因此，這些天，我開始接受他們所報告的內(nèi)容的表明價值。當(dāng)然，我依然會仔細檢查一切是否被正確地設(shè)置等等。我見過很多這樣的情況，讓我明白，因為不尋常的配置或意料之外的用法而導(dǎo)致不可思議的事情的發(fā)生，而我默認的假設(shè)是，他們是正確的，程序是錯誤的。

5.測試修復(fù)。如果bug修復(fù)已準(zhǔn)備就緒，那就必須進行測試。首先在修復(fù)前運行代碼，并觀察該bug。然后應(yīng)用修復(fù)并重復(fù)測試案例。到此為止錯誤行為應(yīng)消失。遵循這些步驟可以確保它確實是一個bug，并且此次修復(fù)的確可以解決這個問題。簡單而有必要。

其他觀察結(jié)果

現(xiàn)在工作于C++時所遇到的幾類bug已經(jīng)完全消失，像堆棧溢出，內(nèi)存損壞，字符串問題和某種形式的內(nèi)存泄漏。

其他問題，如循環(huán)錯誤和邊界情況，我看到的要少得多。但是，這并不意味著那里沒有bug。如果大家有什么有用的預(yù)防和發(fā)現(xiàn)bug的技術(shù)方法，歡迎留言。

作為過來人，最后還想說幾句心靈雞湯：

1、分享第一條經(jīng)驗：“學(xué)歷代表過去、能力代表現(xiàn)在、學(xué)習(xí)力代表未來。”

2、一定要確定自己的發(fā)展方向，并為此目的制定可行的計劃。

3、軟件開發(fā)團隊中，技術(shù)不是萬能的，但沒有技術(shù)是萬萬不能的！

4、詳細制定自己軟件開發(fā)專業(yè)知識學(xué)習(xí)計劃，并注意及時修正和調(diào)整(軟件開發(fā)技術(shù)變化實在太快)。

5、書籍是人類進步的階梯，對軟件開發(fā)人員尤其如此。

6、不要僅局限于對某項技術(shù)的表面使用上，哪怕你只是偶爾用一、二次。

7、在一種語言上編程，但別為其束縛了思想。“代碼大全”中說：“深入一門語言編程，不要浮于表面”。

8、養(yǎng)成總結(jié)與反思的習(xí)慣，并有意識地提煉日常工作成果，形成自己的個人源碼庫、解決某類問題的通用系統(tǒng)體系結(jié)構(gòu)、甚至進化為框架。

9、理論與實踐并重，內(nèi)外雙修。

10、心態(tài)有多開放，視野就有多開闊。

11、盡量參加開源項目的開發(fā)、或者與朋友共同研制一些自己的產(chǎn)品，千萬不要因為沒有錢賺而不做。

12、書到用時方恨少，不要將自己的知識面僅僅局限于技術(shù)方面。

總結(jié)與反思：

（a）不要去做技術(shù)上的高手，除非你的目標(biāo)如此。

（b）提高軟件知識和技術(shù)只是問題的表面，本質(zhì)是要提高自己認識問題、分析問題、解決問題的思想高度。軟件專業(yè)知識的很多方法和原理，可以很容易地延伸、應(yīng)用到生活的其它方面。

（c）在能勝任工作的基礎(chǔ)上，立即去涉獵其它領(lǐng)域的專業(yè)知識，豐富自己的知識體系、提高自己的綜合素質(zhì)，尤其是那些目標(biāo)不在技術(shù)方面的朋友。

責(zé)任編輯：lq