要點
　　1.為什么你會遇上這些bug？因為它們是你放的。
　　2.在TDD（測試驅(qū)動的開發(fā)）中，你會在一個嚴格的反饋循環(huán)中，開發(fā)測試與生產(chǎn)代碼。
　　3.TDD可能有助于避免惱人的Zune bug。
　　4.目標硬件瓶頸有多種形式，你可以在嚴格的TDD反饋循環(huán)中，用TDD來避開瓶頸。
　　5.TDD幫助你確保自己的代碼如期望那樣運行。但如果不是這樣，你該如何建立一個可靠的系統(tǒng)？
　　6.TDD快速地發(fā)現(xiàn)小的和大的邏輯錯誤，防止出現(xiàn)bug，使最終得到較少的bug。
　　我們的工作方式都是編寫代碼，然后努力讓它運行起來。先建立，然后改錯。測試是以后的事，即寫完代碼后才要做的事。在不可預期的調(diào)試工作上，大概要花掉我們一半的時間。在日程表上，調(diào)試工作都穿著測試與集成的外衣。它是風險與不確定性的一個來源。修正了一個bug可能會產(chǎn)生另一個bug，有時甚至是一連串的bug。
　　保持調(diào)試的統(tǒng)計有助于預測要花多少時間才能消除bug。你要度量和管理bug?？辞€的拐點，拐點表示了趨勢，告訴你最后修正的bug要比產(chǎn)生的多。拐點表示的是已經(jīng)做的事，但你永遠不知道是否在代碼的某個陰暗角落還躲藏著其它的致命bug。
　　可制造性設計的一個方面是確定為什么你會有這些bug。答案很簡單：錯誤是我們放進去的。這就是我們的工作方式。在開發(fā)以后的測試時，就會發(fā)現(xiàn)問題（圖1和參考文獻1）。我們在開發(fā)時會制造錯誤，測試的工作就是找到這些問題。只要仔細地測試，就會發(fā)現(xiàn)錯誤。開發(fā)后的測試工作意味著必須找到、修復和管理大量的錯誤。
　　
　　圖1，在開發(fā)以后做測試時，會發(fā)現(xiàn)缺陷
　　這種調(diào)試居后的編程程序是當今最常見的編程方式。先寫代碼，再調(diào)試它。調(diào)試居后的編程方式有風險。人都會犯錯誤。你既不能確定bug將在何時現(xiàn)身，也不能確定會花多長時間才能發(fā)現(xiàn)它們（圖2）。
　　
　　圖2，人都會犯錯誤。你無法確定bug何時出現(xiàn)，以及要花多少時間才能找到它們
　　當發(fā)現(xiàn)一個bug的時間（TD）增加時，尋找bug根源的時間（TFIND）也會增加，通常增加得更多。如果從錯誤的引入到發(fā)現(xiàn)要花數(shù)小時、數(shù)天、數(shù)周，甚至數(shù)月時間，你已忘掉了當時的背景，必須開始做bug大掃蕩。當你在開發(fā)周期以外發(fā)現(xiàn)缺陷時，就必須管理bug。對于有些bug，發(fā)現(xiàn)的時間不會影響修復的時間（TFIX），但有些代碼的運行也可能依賴于bug，修改這些bug會造成其它bug。
　　短周期以及主動的測試自動化可節(jié)省時間和工作量。這時，你再不需要重復繁重而易錯的手工測試。有了測試自動化，重復測試幾乎不會增加額外工作量。測試自動化快速地探測出副作用，避免了對調(diào)試事務的需求。