編程大師說：“任何一個(gè)程序，無論它多么小，總存在著錯(cuò)誤。”
初學(xué)者不相信大師的話，他問：“如果一個(gè)程序小得只執(zhí)行一個(gè)簡單的功能，那會(huì)怎樣？”
“這樣的一個(gè)程序沒有意義，”大師說，“但如果這樣的程序存在的話，操作系統(tǒng)最后將失效，產(chǎn)生一個(gè)錯(cuò)誤。”
但初學(xué)者不滿足，他問：“如果操作系統(tǒng)不失效，那么會(huì)怎樣？”
“沒有不失效的操作系統(tǒng)，”大師說，“但如果這樣的操作系統(tǒng)存在的話，硬件最后將失效，產(chǎn)生一個(gè)錯(cuò)誤。”
初學(xué)者仍不滿足，再問：“如果硬件不失效，那么會(huì)怎樣？”
大師長嘆一聲道：“沒有不失效的硬件。但如果這樣的硬件存在的話，用戶就會(huì)想讓那個(gè)程序做一件不同的事，這件事也是一個(gè)錯(cuò)誤。”
沒有錯(cuò)誤的程序世間難求。[James 1999]
錯(cuò)誤是一種嚴(yán)重的程序缺陷。測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過改錯(cuò)來把缺陷統(tǒng)統(tǒng)消滅，以期提高軟件的質(zhì)量。但關(guān)于測試與改錯(cuò)實(shí)在沒有什么高明的方法值得大書特書，也不能表現(xiàn)出程序員的聰明才智。相反地，它們帶來了更多的牢騷與痛苦。因此在教學(xué)和開發(fā)實(shí)踐中，測試與改錯(cuò)總是被當(dāng)作萬般無奈的工作踢到角落里。
醫(yī)生可以把他的錯(cuò)誤埋葬在地下了事，但程序員不能。我們必須要學(xué)會(huì)測試與改錯(cuò)，并且把測試與改錯(cuò)工作做好。
7.1 對(duì)測試的理解
測試的道理并不深?yuàn)W，計(jì)算機(jī)專業(yè)人員都應(yīng)該明白。但就是這么簡單的事，計(jì)算機(jī)專業(yè)的博士們也未必都已經(jīng)理解。
有一天，一位比我聰明，編程比我快，學(xué)習(xí)能力比我強(qiáng)的計(jì)算機(jī)專業(yè)博士生恭恭敬敬地請(qǐng)我坐好，并且史無前例地削了蘋果請(qǐng)我吃，為的是向我請(qǐng)教“軟件工程”問題。你必定以為這位仁兄好學(xué)之極。非也，我和他同事三年來從未探討過“軟件工程”問題。只因?yàn)樗魈煲?yīng)聘，參加面試，生怕被人問倒，就央我當(dāng)晚為他惡補(bǔ)一把“軟件工程”。他還特地問我“什么是白盒測試和黑盒測試？應(yīng)該由誰來執(zhí)行？”（有公司曾經(jīng)這樣面試應(yīng)聘者）當(dāng)我解釋完測試的道理時(shí)，他嘆了一口氣說：“這些玩意兒我讀大學(xué)十年來都沒搞過，怎么能講得出道理來。唉，就去碰碰運(yùn)氣吧。”我有“兔死狐悲”的感覺。我們這一群博士生三年來盡干些自欺欺人的事，到畢業(yè)時(shí)學(xué)問既不深也不博。個(gè)個(gè)意志消沉，老氣橫秋。長此以往，總有一天招聘會(huì)的大門前將貼出標(biāo)語“博士與狗不得入內(nèi)”。
以下是關(guān)于測試的幾個(gè)重要觀念。
7.1.1 測試的目的
測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷。
這里缺陷是一種泛稱，它可以指功能的錯(cuò)誤，也可以指性能低下，易用性差等等。測試總是先假設(shè)程序中存在缺陷，再通過執(zhí)行程序來發(fā)現(xiàn)并最終改正缺陷。理解測試的目的是個(gè)很重要的意識(shí)問題。如果說測試的目的是為了說明程序中沒有缺陷，那么測試人員就會(huì)向這個(gè)目標(biāo)靠攏，因而下意識(shí)地選用一些不易暴露錯(cuò)誤的測試示例。這樣的測試是虛假的。
目前高校的科技成果鑒定會(huì)普遍存在類似的虛假現(xiàn)象。我在讀碩士時(shí)就親身經(jīng)歷過這樣的事。我們的項(xiàng)目是研究集成電路制造過程中的成品率問題。當(dāng)時(shí)國內(nèi)大多數(shù)工廠的集成電路成品率只有百分之幾，我編寫的示例程序可以將集成電路的成品率優(yōu)化到98%。示例效果是如此的好，以致一位評(píng)委（某廠的總工程師）不無諷刺地說：“采用你們的成果，我們可要發(fā)大財(cái)了。”這個(gè)項(xiàng)目就輕易地通過了鑒定，并且不久后獲得了電子工業(yè)部科技進(jìn)步二等獎(jiǎng)。這就象在考試時(shí)通過作弊取得了好成績而被表揚(yáng)。我那時(shí)尚且純真，羞愧之余，不禁對(duì)高?？蒲谐晒乃胶驼鎸?shí)性大失所望（現(xiàn)在我已不再失望，因?yàn)楹苌俦Ｍ?br>一個(gè)成功的測試示例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。
測試并不僅是個(gè)技術(shù)問題，更是個(gè)職業(yè)道德問題。
7.1.2 測試的心理要求
測試主要是由人而不是由機(jī)器執(zhí)行，這就不免與心理因素相關(guān)。為了測試的真實(shí)性，對(duì)測試的心理要求是“無情”。這似乎太殘酷了。開發(fā)人員不能很好地測試自己的程序是因?yàn)樽霾坏綗o情。而測試人員如果做到了無情卻會(huì)引起開發(fā)人員的憤怒，遭人白眼。
盡管已經(jīng)明白了測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，但當(dāng)測試人員真的發(fā)現(xiàn)了一堆缺陷時(shí)，卻不可樂顛顛地跑去恭喜那個(gè)倒霉的開發(fā)者，否則會(huì)打架的。
7.1.3 測試的真理
測試只能證明缺陷存在，而不能證明缺陷不存在。
這個(gè)真理告訴我們，對(duì)于一個(gè)復(fù)雜的系統(tǒng)而言，無論采取什么樣的測試手段都不能證明缺陷已經(jīng)不復(fù)存在。“徹底地測試”只是一種理想。在實(shí)踐中，測試要考慮時(shí)間、費(fèi)用等限制，不允許無休止地測試。
7.1.4 測試與質(zhì)量的關(guān)系
測試有助于提高軟件的質(zhì)量，但是提高軟件的質(zhì)量不能依賴于測試。測試與質(zhì)量的關(guān)系很象在考試中“檢查”與“成績”的關(guān)系。
學(xué)習(xí)好的學(xué)生，在考試時(shí)通過認(rèn)真檢查能減少因疏忽而造成的答題錯(cuò)誤，從而“提高”了考試成績（取得他本來就該得的好成績）。
而學(xué)習(xí)差的學(xué)生，他原本就不會(huì)做題目，無論檢查多么細(xì)心，也不能提高成績。
所以說，軟件的高質(zhì)量是設(shè)計(jì)出來的，而不是靠測試修補(bǔ)出來的。
7.2 測試人員的選擇
測試需要開發(fā)人員參與嗎？
測試需要獨(dú)立的測試小組嗎？
測試需要用戶參與嗎？
讓我們先看一看Microsoft公司關(guān)于測試的經(jīng)驗(yàn)教訓(xùn)，再回答上述問題。
7.2.1 Microsoft公司的經(jīng)驗(yàn)教訓(xùn)
在80年代初期，Microsoft公司的許多軟件產(chǎn)品出現(xiàn)了“Bug”。比如，在1981年與IBM PC機(jī)一起推出的BASIC軟件，用戶在用“.1”（或者其他數(shù)字）除以10時(shí)，就會(huì)出錯(cuò)。在FORTRAN軟件中也存在破壞數(shù)據(jù)的“Bug”。由此激起了許多采用Microsoft操作系統(tǒng)的PC廠商的極大不滿，而且很多個(gè)人用戶也紛紛投訴。
Microsoft公司的經(jīng)理們發(fā)覺很有必要引進(jìn)更好的內(nèi)部測試與質(zhì)量控制方法。但是遭到很多程序設(shè)計(jì)師甚至一些高級(jí)經(jīng)理的堅(jiān)決反對(duì)，他們固執(zhí)地認(rèn)為在高校學(xué)生、秘書或者外界合作人士的協(xié)助下，開發(fā)人員可以自己測試產(chǎn)品。在1984年推出Mac機(jī)的Multiplan（電子表格軟件）之前，Microsoft曾特地請(qǐng)Arthur Anderson咨詢公司進(jìn)行測試。但是外界公司一般沒有能力執(zhí)行全面的軟件測試。結(jié)果，一種相當(dāng)厲害的破環(huán)數(shù)據(jù)的“Bug”迫使Microsoft公司為它的２萬多名用戶免費(fèi)提供更新版本，代價(jià)是每個(gè)版本10美元，一共化了20萬美元，可謂損失慘重。
痛定思痛后，Microsoft公司的經(jīng)理們得出一個(gè)結(jié)論：如果再不成立獨(dú)立的測試部門，軟件產(chǎn)品就不可能達(dá)到更高的質(zhì)量標(biāo)準(zhǔn)。IBM和其它有著成功的軟件開發(fā)歷史的公司便是效法的榜樣。但Microsoft公司并不照搬IBM的經(jīng)驗(yàn)，而是有選擇地采用了一些看起來比較先進(jìn)的方法，如獨(dú)立的測試小組，自動(dòng)測試以及為關(guān)鍵性的構(gòu)件進(jìn)行代碼復(fù)查等。Microsoft公司的一位開發(fā)部門主管戴夫·穆爾回憶說：“我們清楚不能再讓開發(fā)部門自己測試了。我們需要有一個(gè)單獨(dú)的小組來設(shè)計(jì)測試，運(yùn)行測試，并把測試信息反饋給開發(fā)部門。這是一個(gè)偉大的轉(zhuǎn)折點(diǎn)。”
但是有了獨(dú)立的測試小組后，并不等于萬事大吉了。自從Microsoft公司在1984年與1986年之間擴(kuò)大了測試小組后，開發(fā)人員開始“變懶”了。他們把代碼扔在一邊等著測試，忘了唯有開發(fā)人員自己才能阻止錯(cuò)誤的發(fā)生、防患于未來。此時(shí)，Microsoft公司歷史上第二次大災(zāi)難降臨了。原定于1986年７月發(fā)行的Mac機(jī)的Word 3.0，千呼萬喚方于1987年2月問世。這套軟件竟然有700多處錯(cuò)誤，有的錯(cuò)誤可以破壞數(shù)據(jù)甚至摧毀程序。一下子就使Microsoft名聲掃地。公司不得不為用戶免費(fèi)提供升級(jí)版本，費(fèi)用超過了100萬美元。[Cusumano 1995]
7.2.2 測試人員的分工
從Microsoft公司的教訓(xùn)中可知，公司內(nèi)部對(duì)產(chǎn)品的測試（稱為α測試），需要開發(fā)人員與獨(dú)立的測試小組共同參與。開發(fā)人員應(yīng)該執(zhí)行“白盒”測試，即測試源程序的邏輯結(jié)構(gòu)以及實(shí)現(xiàn)細(xì)節(jié)（“白盒”是指看得見程序的內(nèi)部結(jié)構(gòu)）。而獨(dú)立測試小組應(yīng)該執(zhí)行“黑盒”測試，即按照規(guī)格說明來測試程序是否符合要求（“黑盒”是指看不見程序的內(nèi)部結(jié)構(gòu)）。比如在測試一個(gè)模塊時(shí)，“白盒”測試方法要對(duì)模塊的所有代碼進(jìn)行單步跟蹤測試。而“黑盒”測試方法只需測試模塊的接口是否符合要求，它關(guān)心程序的外部表現(xiàn)而不是內(nèi)部的實(shí)現(xiàn)細(xì)節(jié)。
小型的軟件公司可能沒有條件設(shè)立獨(dú)立的測試小組，也有可能測試小組人員不多而忙不過來。這時(shí)，可以讓開發(fā)小組的成員相互測試對(duì)方的程序。
這里要強(qiáng)調(diào)的是，α測試不能依賴于開發(fā)人員或者測試小組中的任意一方，必須是雙方共同參與。“白盒測試”必須由開發(fā)者自己執(zhí)行，因?yàn)閯e的測試人員無法了解到程序的內(nèi)部實(shí)現(xiàn)細(xì)節(jié)。而“黑盒測試”必須由獨(dú)立的測試人員執(zhí)行，因?yàn)殚_發(fā)者難以做到客觀、公正。開發(fā)者在測試自己的程序時(shí)存在一些弊?。?br>（1）開發(fā)者對(duì)自己的程序印象深刻，并總以為是正確的（自信是應(yīng)該的）。倘若在設(shè)計(jì)時(shí)就存在理解錯(cuò)誤，或因不良的編程習(xí)慣而流下隱患，那么他本人很難發(fā)現(xiàn)這類錯(cuò)誤。
（2）開發(fā)者對(duì)程序的功能、接口十分熟悉，他自己幾乎不可能因?yàn)槭褂貌划?dāng)而引發(fā)錯(cuò)誤，這與大眾用戶的情況不太相似，所以自己測試程序難以具備典型性。
（3）程序設(shè)計(jì)有如藝術(shù)設(shè)計(jì)，開發(fā)者總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發(fā)者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。即便開發(fā)者非常誠實(shí)，但“珍愛程序”的心理讓他在測試時(shí)[url=http://www.sogou.com/sogoupedia?query=不知不覺]不知不覺[/url]地帶入了虛假成份。
軟件產(chǎn)品正式發(fā)行前，在公司外部邀請(qǐng)一些用戶對(duì)產(chǎn)品進(jìn)行測試，稱為β測試。β測試的涉及面最廣，最能反映用戶的真實(shí)愿望，但花費(fèi)的時(shí)間最長，不好控制。一般地，軟件公司與β測試人員之間有一種互利的協(xié)議。即β測試人員無償?shù)貫檐浖咀鳒y試，定期遞交測試報(bào)告，提出批評(píng)與建議。而軟件公司將向β測試人員免費(fèi)贈(zèng)送或者以很大的優(yōu)惠價(jià)格發(fā)行軟件的正式版本。
7.3 測試的主要內(nèi)容與常用方法
有一次文學(xué)考試，問高爾基是哪國人。一考生樂極而吟：“爾基啊爾基，你若不姓高，我怎知你是中國人。”這是一種瞎猜法。如果這種方法用于軟件測試，人累死也測不出什么結(jié)果來。
不論是對(duì)軟件的模塊還是整個(gè)系統(tǒng)，總有共同的內(nèi)容要測試，如正確性測試，容錯(cuò)性測試，性能與效率測試，易用性測試，文檔測試等。“白盒測試”是指開發(fā)人員從程序內(nèi)部對(duì)上述內(nèi)容進(jìn)行測試，而“黑盒測試”是指獨(dú)立的測試人員從程序外部對(duì)上述內(nèi)容進(jìn)行測試。很多軟件工程教材講述了各種各樣的測試方法并例舉了不少示例[Pressman 1997] [Sommerville 1992] [楊文龍 1997]。本節(jié)簡明地講述常用的測試方法及其道理。
7.3.1 正確性測試
正確性測試又稱功能測試，它檢查軟件的功能是否符合規(guī)格說明。由于正確性是軟件最重要的質(zhì)量因素，所以其測試也最重要。
基本的方法是構(gòu)造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。倘若枚舉空間是無限的，那可慘了，還不如回家種土豆有盼頭。測試人員一定要設(shè)法減少枚舉的次數(shù)，否則沒好日子過。關(guān)鍵在于尋找等價(jià)區(qū)間，因?yàn)樵诘葍r(jià)區(qū)間中，只需用任意值測試一次即可。等價(jià)區(qū)間的概念可表述如下：
記（A, B）是命題f(x) 的一個(gè)等價(jià)區(qū)間，在（A, B）中任意取x1進(jìn)行測試。
如果f (x1) 錯(cuò)誤，那么f (x) 在整個(gè)（A, B）區(qū)間都將出錯(cuò)。
如果f (x1) 正確，那么f (x) 在整個(gè)（A, B）區(qū)間都將正確。
上述測試方法稱為等價(jià)測試，來源于人們的直覺與經(jīng)驗(yàn)，可令測試事半功倍。
還有一種有效的測試方法是邊界值測試。即采用定義域或者等價(jià)區(qū)間的邊界值進(jìn)行測試。因?yàn)槌绦騿T容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯(cuò)。
例如測試的一段程序。憑直覺等價(jià)區(qū)間應(yīng)是（0, 1）和（1, +∞）。可取x=0.5以及x=2.0進(jìn)行等價(jià)測試。再取 x=0以及x=1進(jìn)行邊界值測試。
有一些復(fù)雜的程序，我們難以憑直覺與經(jīng)驗(yàn)找到等價(jià)區(qū)間和邊界值，這時(shí)枚舉測試就相當(dāng)有難度。
在用“白盒測試”方式進(jìn)行正確性測試時(shí)，有個(gè)額外的好處：如果測試發(fā)現(xiàn)了錯(cuò)誤，測試者（開發(fā)人員）馬上就能修改錯(cuò)誤。越早改正錯(cuò)誤，付出的代價(jià)就越低。所以大多數(shù)軟件公司要求程序員在寫完程序時(shí)，馬上執(zhí)行基于單步跟蹤的“白盒測試”。
7.3.2 容錯(cuò)性測試
容錯(cuò)性測試是檢查軟件在異常條件下的行為。容錯(cuò)性好的軟件能確保系統(tǒng)不發(fā)生無法意料的事故。
比較溫柔的容錯(cuò)性測試通常構(gòu)造一些不合理的輸入來引誘軟件出錯(cuò)，例如：
（1）輸入錯(cuò)誤的數(shù)據(jù)類型，如“猴”年“馬”月。
（2）輸入定義域之外的數(shù)值，上海人常說的“十三點(diǎn)”也算一種。
粗暴一些的容錯(cuò)性測試俗稱“大猩猩”測試，除了不能拳打腳踢嘴咬，什么招術(shù)都可以使出來。這里我舉不出例子，因?yàn)槲覜]有對(duì)程序粗暴過，并且這輩子也不打算學(xué)會(huì)粗暴。
7.3.3 性能與效率測試
性能與效率測試主要是測試軟件的運(yùn)行速度和對(duì)資源的利用率。有時(shí)人們關(guān)心測試的“絕對(duì)值”，如數(shù)據(jù)送輸速率是每秒多少比特。有時(shí)人們關(guān)心測試的“相對(duì)值”，如某個(gè)軟件比另一個(gè)軟件快多少倍。
在獲取測試的“絕對(duì)值”時(shí)，我們要充分考慮并記錄運(yùn)行環(huán)境對(duì)測試的影響。例如計(jì)算機(jī)主頻，總線結(jié)構(gòu)和外部設(shè)備都可能影響軟件的運(yùn)行速度；若與多個(gè)計(jì)算機(jī)共享資源，軟件運(yùn)行可能慢得像蝸牛爬行。
在獲取測試的“相對(duì)值”時(shí)，我們要確保被測試的幾個(gè)軟件運(yùn)行于完全一致的環(huán)境中。硬件環(huán)境的一致性比較容易做到（用同一臺(tái)計(jì)算機(jī)即可）。但軟件環(huán)境的因素較多，除了操作系統(tǒng)，程序設(shè)計(jì)語言和編譯系統(tǒng)對(duì)軟件的性能也會(huì)產(chǎn)生較大的影響。如果是比較幾個(gè)算法的性能，就要求編程語言和編譯器也完全一致。
性能與效率測試中很重要的一項(xiàng)是極限測試，因?yàn)楹芏嘬浖到y(tǒng)會(huì)在極限測試中崩潰。例如，連續(xù)不停地向服務(wù)器發(fā)請(qǐng)求，測試服務(wù)器是否會(huì)陷入死鎖狀態(tài)不能自拔；給程序輸入特別大的數(shù)據(jù)，看看它是否吃得消。
7.3.4 易用性測試
易用性測試沒有一個(gè)量化的指標(biāo)，主觀性較強(qiáng)。調(diào)查表明，當(dāng)用戶不理解軟件中的某個(gè)特性時(shí)，大多數(shù)人首先會(huì)向同事、朋友請(qǐng)教。要是再不起作用，就向產(chǎn)品支持部門打電話。只有30%的用戶會(huì)查閱用戶手冊(cè)。[Cusumano 1995]
一般認(rèn)為，如果用戶不翻閱手冊(cè)就能使用軟件，那么表明這個(gè)軟件具有較好的易用性。
7.3.5 文檔測試
文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個(gè)組成部分。
正確性是指不要把軟件的功能和操作寫錯(cuò)，也不允許文檔內(nèi)容前后矛盾。
完備性是指文檔不可以“虎頭蛇尾”，更不許漏掉關(guān)鍵內(nèi)容。有些學(xué)生在證明數(shù)學(xué)題時(shí)，喜歡用“顯然”兩字蒙混過關(guān)。文檔中很多內(nèi)容對(duì)開發(fā)者可能是“顯然”的，但對(duì)用戶而言不見得都是“顯然”的。
文檔不可以寫成散文、詩歌或者偵探、言情小說，要讓大眾用戶看得懂，能理解。
很多程序員能編寫出好程序，卻寫不出清晰的文檔。不要說自己以前語文學(xué)得差，現(xiàn)在已沒救了，找借口不是辦法。沒有人天生就能寫出好程序，都是練出來的。同理，若第一次寫不好文檔，就多寫幾次文檔，慢慢地就會(huì)寫出好文檔來。我上大學(xué)前不會(huì)說普通話，不會(huì)寫作文，現(xiàn)在我極能說會(huì)寫，當(dāng)個(gè)秘書或書記已綽綽有余。
7.4 改 錯(cuò)
在軟件測試時(shí)如果發(fā)現(xiàn)了錯(cuò)誤，必須請(qǐng)程序員改錯(cuò)，否則測試工作就白干了。
改錯(cuò)是個(gè)大悲大喜的過程，一天之內(nèi)可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過上萬個(gè)程序錯(cuò)誤，那么少男少女們不必經(jīng)歷失戀的挫折也能變得成熟起來。
我從大三開始真正接受改錯(cuò)的磨練，已記不清楚多少次汗流浹背、濕透板凳。改不了錯(cuò)誤時(shí)，恨不得撞墻。改了錯(cuò)誤時(shí)，比女孩子朝我笑笑還開心。
在做本科畢業(yè)設(shè)計(jì)時(shí)，一天夜里，一哥們流竄到我的實(shí)驗(yàn)室，哈不攏嘴地對(duì)我嚷嚷：“你知道什么叫茅塞頓開嗎？”
我象白癡似的搖搖頭。
他說：“今天我化了十幾個(gè)小時(shí)沒能干掉一個(gè)錯(cuò)誤，剛才我去了廁所五分鐘，一切都解決了。”
他還用那沒洗過的手拉我，一定要請(qǐng)我吃“肉夾饃”。那得意勁兒仿佛同時(shí)談了兩個(gè)女朋友。
在本節(jié)，我要替程序員們總結(jié)關(guān)于改錯(cuò)的幾點(diǎn)思想方法：
（1）要有勇氣。東北有個(gè)林場工人，工作勤奮，一人能干幾個(gè)人的活。前三十年是伐樹勞模，受到周總理的接見。忽有一天醒悟過來，覺得自己太對(duì)不起森林，決心補(bǔ)救錯(cuò)誤。后三十年成了植樹勞模，受到朱總理的接見。此大勇也。
程序中的錯(cuò)誤只有開發(fā)者自己才能找出并改掉。如果因畏懼而拖延，會(huì)讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對(duì)付錯(cuò)誤。
（2）不可蠻干。都說急中生智，我不信。我認(rèn)為大多數(shù)人著急了就會(huì)蠻干，早把“智”丟到腦后。不僅人如此，動(dòng)物也如此。
我們經(jīng)常看到，蜜蜂或者蒼蠅想從玻璃窗中飛出，它們會(huì)頂著玻璃折騰幾個(gè)小時(shí)，卻不曉得從旁邊輕輕松松地飛走。我原以為蜜蜂和蒼蠅長得太小，視野有限，以致看不見近在咫尺的逃生之窗，所以只好蠻干?？墒怯幸惶煲估铮兄宦槿革w進(jìn)我的房間，它的逃生方式竟然與蜜蜂一模一樣。我用燈光照著那扇打開的窗戶為其引路，并向它打手勢，對(duì)它說話，均無濟(jì)于事。它是到天亮后才飛走的，這一宿我倆都沒息好。
（3）找出錯(cuò)誤的根源。有人問阿凡提：“我肚子痛，應(yīng)該用什么藥？”阿凡提說：“應(yīng)該用眼藥水，因?yàn)槟阊劬Σ缓?，吃了臟東西才肚子痛。”
我們應(yīng)該運(yùn)用歸納、推理等方法盡早確定錯(cuò)誤的根源。
（4）在改錯(cuò)之后一定要馬上進(jìn)行重新測試，以免引入新的錯(cuò)誤。有人在馬路上撿到錢包后得意忘形，不料自己卻被汽車撞倒。改了一個(gè)程序錯(cuò)誤固然是喜事，但要防止樂極生悲。更加嚴(yán)格的要求是：不論原有程序是否絕對(duì)正確，只要對(duì)此程序作過改動(dòng)（哪怕是微不足道的），都要進(jìn)行重新測試。
7.5 小 結(jié)
優(yōu)秀的程序員敢于聲稱自己的代碼沒有錯(cuò)誤，這種自信讓人羨慕不已。一個(gè)錯(cuò)誤自身也許很微小，但是程序存在錯(cuò)誤這件事很嚴(yán)重。能否做好測試與改錯(cuò)工作，思想認(rèn)識(shí)和辦事態(tài)度是最關(guān)鍵的。
程序員應(yīng)該把測試當(dāng)成份內(nèi)之事，不要依賴于外界的“黑盒測試”。“黑盒測試”就象通過提問題來判斷一個(gè)人是否是個(gè)瘋子，但無法知道他為什么成了瘋子。讓程序員對(duì)所有的代碼執(zhí)行單步跟蹤測試聽起來很費(fèi)時(shí)間，但習(xí)慣了你就感覺不到有什么不方便。單步跟蹤測試將使你以后的日子更輕松