要點

1.為什么你會遇上這些bug？因為它們是你放的。

2.在TDD(測試驅動的開發)中，你會在一個嚴格的反饋循環中，開發測試與生產代碼。

3.TDD可能有助于避免惱人的Zune bug。

4.目標硬件瓶頸有多種形式，你可以在嚴格的TDD反饋循環中，用TDD來避開瓶頸。

5.TDD幫助你確保自己的代碼如期望那樣運行。但如果不是這樣，你該如何建立一個可靠的系統？

6.TDD快速地發現小的和大的邏輯錯誤，防止出現bug，使最終得到較少的bug。

我們的工作方式都是編寫代碼，然后努力讓它運行起來。先建立，然后改錯。測試是以后的事，即寫完代碼后才要做的事。在不可預期的調試工作上，大概要花掉我們一半的時間。在日程表上，調試工作都穿著測試與集成的外衣。它是風險與不確定性的一個來源。修正了一個bug可能會產生另一個bug，有時甚至是一連串的bug。

保持調試的統計有助于預測要花多少時間才能消除bug。你要度量和管理bug。看曲線的拐點，拐點表示了趨勢，告訴你最后修正的bug要比產生的多。拐點表示的是已經做的事，但你永遠不知道是否在代碼的某個陰暗角落還躲藏著其它的致命bug。

可制造性設計的一個方面是確定為什么你會有這些bug。答案很簡單：錯誤是我們放進去的。這就是我們的工作方式。在開發以后的測試時，就會發現問題(圖1和參考文獻1)。我們在開發時會制造錯誤，測試的工作就是找到這些問題。只要仔細地測試，就會發現錯誤。開發后的測試工作意味著必須找到、修復和管理大量的錯誤。

圖1，在開發以后做測試時，會發現缺陷

這種調試居后的編程程序是當今最常見的編程方式。先寫代碼，再調試它。調試居后的編程方式有風險。人都會犯錯誤。你既不能確定bug將在何時現身，也不能確定會花多長時間才能發現它們(圖2)。

圖2，人都會犯錯誤。你無法確定bug何時出現，以及要花多少時間才能找到它們

當發現一個bug的時間(TD)增加時，尋找bug根源的時間(TFIND)也會增加，通常增加得更多。如果從錯誤的引入到發現要花數小時、數天、數周，甚至數月時間，你已忘掉了當時的背景，必須開始做bug大掃蕩。當你在開發周期以外發現缺陷時，就必須管理bug。對于有些bug，發現的時間不會影響修復的時間(TFIX)，但有些代碼的運行也可能依賴于bug，修改這些bug會造成其它bug。

短周期以及主動的測試自動化可節省時間和工作量。這時，你再不需要重復繁重而易錯的手工測試。有了測試自動化，重復測試幾乎不會增加額外工作量。測試自動化快速地探測出副作用，避免了對調試事務的需求。

另一種方案是TDD(測試驅動的開發)，它在一個嚴格反饋的循環中開發出測試代碼與生產代碼(參考文獻2和3)。一個TDD微循環是：編寫一個測試，未編譯時觀察該測試，做編譯且測試失敗，使編譯通過，清除任何多余內容，并重復該過程直至結束。編寫測試代碼與編寫生產代碼是整合的過程。如果犯了一個錯誤，沒有通過新測試，你馬上就可以知道并改正錯誤。測試會告訴你是否通過了新測試卻產生了某個錯誤。在設備測試裝置中加入自動化測試(圖3)，就可以自由地做重復測試。

圖3，測試會告訴你是否通過了新的測試，但卻引入了一個bug。自動測試要插入到一個單元測試裝置中

在TDD反饋回路中做開發與測試時，只能避免一部分bug的出現，但不能完全消除。TDD對設計以及時間的分配方式有著意義深遠的影響。

與后調試的編程模式相反，TDD并不包含追蹤錯誤的風險與不確定性(圖4)。當發現一個錯誤的時間接近于0時，尋找錯誤根源的時間也會趨于0。剛產生的代碼問題通常顯而易見。如果不那么明顯，則開發人員只要簡單地恢復剛做的修改，就可以回到一個可運行的系統。尋找和修改錯誤的時間和產生的時間一樣少，只有當程序員記憶隨時間而模糊，并且有更多的代碼依賴于較早的錯誤時，事件才會變糟。

TDD為錯誤提供了即時的通知，可防止出現很多要被迫追蹤的bug。TDD可防止出現缺陷，而后調試編程會帶來耗時耗力的調試工作。

TDD可能有助于避免惱人的Zunebug。微軟公司的Zune是為了與蘋果公司的iPod競爭。2008年12月31日，Zune變成了“專為一天的程序塊(abrick for a day)”。12月31日是新年前夜，是一個閏年的最后一天，這是30G Zune要經歷的第一個閏年。很多人都將Zune錯誤歸因于時鐘驅動程序中的一個函數。雖然列表1中的代碼并非實際的驅動程序碼，但它有相同的效果。你可以從列表1中Zune的無限循環中找到一些端倪嗎？

圖4，TDD對于設計以及時間的使用有深遠的影響。與調試居后的編程模式比較，TDD

沒有回溯追蹤bug的風險與不確定性

圖5，對快速反饋的需求使TDD微循環離開目標硬件，而原生地運行在開發系統上。一個TDD循環包括雙重目標的風險，但提供了快速TDD反饋回路的好處

很多代碼閱讀專家審查了這個代碼，并得出了可能與您一樣的錯誤結論。閆年的最后一天是該年第366天，而Zune對這種情況的處理是錯誤的。在這一天，該函數永遠不會返回！我編寫了設定年份以及年中天數的代碼，看是否像90%的Zune bug專家預測的那樣，將天數的布爾代碼設定為等于或大于366就能解決問題。代碼放入測試裝置后，我編寫了測試用例(列表2)。和Zune一樣，測試進入了一個無限循環。我采用了經過數千名程序員審核的適當修復方法。出乎我的意料，測試失敗了；設定年份與天數的測試認為日期是2009年1月0日。新年前夜，人們仍會擁有自己的音樂，但Zune仍有個bug。

一次測試就可以防止Zune bug。可你怎么知道要去寫這樣一個測試？只有知道bug在哪里才會寫測試。問題是，你并不知道bug在哪里；它們可以在任何地方。所以，這意味著你必須為所有的部分寫測試，至少是所有可能中斷的地方。難以想象要考慮到所有需要測試的東西。但不必擔心，你不需要針對全年每一天做測試。你只需要一個針對有關天數的測試。

計算機編程很復雜，TDD能夠系統化地讓你的代碼按本意運行起來，并提供能使代碼工作的自動化測試用例。

嵌入設計

當我首次使用TDD時，我認識到，它可能有助于解決一個問題：目標硬件的瓶頸，這是令很多嵌入軟件開發人員頭疼的事情。瓶頸有多種形式，你可以使用TDD，在嚴格的TDD反饋循環期間避免瓶頸的出現。很多嵌入開發工作都已實現了軟硬件的并行開發。如果軟件只能在目標硬件上運行，則可能浪費至少一次的時間。例如，目標硬件可能遲至交付期還不可用，推遲了軟件的測試；硬件可能昂貴且稀少；或者它本身就有問題。目標硬件還可能有長的建立時間或長的上傳時間。大多數嵌入開發團隊都遇到過這些問題，它們會減緩進度，并減少了建立今天復雜系統的反饋。

為避免目標硬件的瓶頸，可以采用“雙重目標”法，即設計自己的生產代碼與測試，使之大部分運行在標準PC上。但雙重目標有自己的風險。開發系統中測試代碼的信任度是建立在交付給目標以前的代碼上。大多數雙重目標風險是源于開發環境與目標環境之間的差異。這些差異包括對語言特性支持的改變量、不同編譯器的bug、運行時庫的差異、文件名差異，以及不同的字長等。由于這些風險，你會發現，在一個環境下能無錯運行的代碼，可能在另一個環境下出現測試錯誤。

不過，執行環境中潛在的差異不應成為阻礙采用雙重目標方法的理由。相反，你可以在實現目標的路途中解決這些障礙。嵌入TDD周期在不犧牲優點的前提下，克服了挑戰。

開發循環

當建立與測試循環只需幾秒時間時，TDD是最有效的。這種方案為大多數程序員排除了在循環中使用目標硬件的情況。快速反饋的需求將TDD微循環與目標分離開，而運行在開發系統上。圖5顯示了一個TDD循環，它包含著雙重目標的風險，提供了快速TDD反饋循環的好處。

表1中所列的各個階段，預計可以在相應的階段發現問題。例如，你會發現每個階段都有助于找到這些問題。第1階段會在你編程時給出快速反饋，確定代碼做你想要做的事。第2階段確保你的代碼是在兩種環境下編譯。第3階段確保代碼在主處理器和目標處理器上的運行相同。評估硬件可能需要比目標更多的存儲器，這樣才能把測試代碼和生產代碼都裝入地址空間。有時候，如果你有一個可靠的目標硬件，它有空間運行對單元的測試，也可以省略掉第3階段。第4階段是在目標硬件上運行測試。在第4階段可以引入一些依賴于硬件的單元測試。第5階段是看你的系統完全整合時，是否如其應該的那樣運行。至少讓第5階段的某些部分自動運行，這是一種好的想法。采用TDD的團隊會發現第1階段中的巨大價值，可能不要實現全部各個階段。

嵌入TDD循環并不能阻止所有問題，不過它應有助于在適當的階段發現大多數剛剛產生的問題。你還應至少每個夜晚手動執行第2至第4階段。連續的集成服務器(如Cruise Control或Jenkins)都可以觀察你的源碼庫，在check-in后開始做建立工作。

TDD有助于確保你的代碼做你想要做的事。如果不是這樣，如何才能建立一個可靠的系統呢？它幫助你讓代碼在最開始時保持正確，它建立一個逐步測試的組件，幫助你維持代碼的運行。你在發現、追蹤和修改bug上要花掉相當多的時間。很多開發人員現在都用TDD來防止這些bug的出現。它基本上改變了你的編程方式。

TDD能快速地發現小的和大的邏輯錯誤，阻止bug的產生，并最終得到較少的bug。較少的bug也意味著較少的調試時間，以及較少的缺陷。當新代碼危及一個約束或一個假設時，測試會告訴你。然后，有良好結構的測試會成為一種形式的可執行文檔。

TDD還讓你放心，這種信心來自于一個帶有完備回歸測試組件的徹底測試代碼。采用TDD的開發人員稱周末不再受干擾，并且睡眠更好。TDD還監控進度，追蹤當前的工作，以及做了多少工作。當代碼變得難以測試時，它還對設計問題提出早期警告。