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