1、 7 / 7第七章 測試與改錯編程大師說：“任何一個程序，無論它多么小，總存在著錯誤。”初學者不相信大師的話，他問：“如果一個程序小得只執行一個簡單的功能，那會怎樣？”“這樣的一個程序沒有意義，”大師說，“但如果這樣的程序存在的話，操作系統最后將失效，產生一個錯誤。”但初學者不滿足，他問：“如果操作系統不失效，那么會怎樣？”“沒有不失效的操作系統，”大師說，“但如果這樣的操作系統存在的話，硬件最后將失效，產生一個錯誤。”初學者仍不滿足，再問：“如果硬件不失效，那么會怎樣？”大師長嘆一聲道：“沒有不失效的硬件。但如果這樣的硬件存在的話，用戶就會想讓那個程序做一件不同的事，這件事也是一個錯誤。”沒

2、有錯誤的程序世間難求。James 1999錯誤是一種嚴重的程序缺陷。測試的目的是為了發現盡可能多的缺陷，并期望通過改錯來把缺陷統統消滅，以期提高軟件的質量。但關于測試與改錯實在沒有什么高明的方法值得大書特書，也不能表現出程序員的聰明才智。相反地，它們帶來了更多的牢騷與痛苦。因此在教學和開發實踐中，測試與改錯總是被當作萬般無奈的工作踢到角落里。醫生可以把他的錯誤埋葬在地下了事，但程序員不能。我們必須要學會測試與改錯，并且把測試與改錯工作做好。7.1對測試的理解測試的道理并不深奧，計算機專業人員都應該明白。但就是這么簡單的事，計算機專業的博士們也未必都已經理解。 有一天，一位比我聰明，編程比我快，

3、學習能力比我強的計算機專業博士生恭恭敬敬地請我坐好，并且史無前例地削了蘋果請我吃，為的是向我請教“軟件工程”問題。你必定以為這位仁兄好學之極。非也，我和他同事三年來從未探討過“軟件工程”問題。只因為他明天要去應聘，參加面試，生怕被人問倒，就央我當晚為他惡補一把“軟件工程”。他還特地問我“什么是白盒測試和黑盒測試？應該由誰來執行？”（有公司曾經這樣面試應聘者）當我解釋完測試的道理時，他嘆了一口氣說：“這些玩意兒我讀大學十年來都沒搞過，怎么能講得出道理來。唉，就去碰碰運氣吧。”我有“兔死狐悲”的感覺。我們這一群博士生三年來盡干些自欺欺人的事，到畢業時學問既不深也不博。個個意志消沉，老氣橫秋。長此以

4、往，總有一天招聘會的大門前將貼出標語“博士與狗不得入”。 以下是關于測試的幾個重要觀念。7.1.1 測試的目的 測試的目的是為了發現盡可能多的缺陷。 這里缺陷是一種泛稱，它可以指功能的錯誤，也可以指性能低下，易用性差等等。測試總是先假設程序中存在缺陷，再通過執行程序來發現并最終改正缺陷。理解測試的目的是個很重要的意識問題。如果說測試的目的是為了說明程序中沒有缺陷，那么測試人員就會向這個目標靠攏，因而下意識地選用一些不易暴露錯誤的測試示例。這樣的測試是虛假的。目前高校的科技成果鑒定會普遍存在類似的虛假現象。我在讀碩士時就親身經歷過這樣的事。我們的項目是研究集成電路制造過程中的成品率問題。當時國大

5、多數工廠的集成電路成品率只有百分之幾，我編寫的示例程序可以將集成電路的成品率優化到98%。示例效果是如此的好，以致一位評委（某廠的總工程師）不無諷刺地說：“采用你們的成果，我們可要發大財了。”這個項目就輕易地通過了鑒定，并且不久后獲得了電子工業部科技進步二等獎。這就象在考試時通過作弊取得了好成績而被表揚。我那時尚且純真，羞愧之余，不禁對高校科研成果的水平和真實性大失所望（現在我已不再失望，因為很少抱希望）。一個成功的測試示例在于發現了至今尚未發現的缺陷。測試并不僅是個技術問題，更是個職業道德問題。7.1.2測試的心理要求測試主要是由人而不是由機器執行，這就不免與心理因素相關。為了測試的真實性，

6、對測試的心理要“無情”。這似乎太殘酷了。開發人員不能很好地測試自己的程序是因為做不到無情。而測試人員如果做到了無情卻會引起開發人員的憤怒，遭人白眼。盡管已經明白了測試的目的是為了發現盡可能多的缺陷，但當測試人員真的發現了一堆缺陷時，卻不可樂顛顛地跑去恭喜那個倒霉的開發者，否則會打架的。7.1.3測試的真理測試只能證明缺陷存在，而不能證明缺陷不存在。這個真理告訴我們，對于一個復雜的系統而言，無論采取什么樣的測試手段都不能證明缺陷已經不復存在。“徹底地測試”只是一種理想。在實踐中，測試要考慮時間、費用等限制，不允許無休止地測試。7.1.4測試與質量的關系測試有助于提高軟件的質量，但是提高軟件的質量

7、不能依賴于測試。測試與質量的關系很象在考試中“檢查”與“成績”的關系。學習好的學生，在考試時通過認真檢查能減少因疏忽而造成的答題錯誤，從而“提高”了考試成績（取得他本來就該得的好成績）。而學習差的學生，他原本就不會做題目，無論檢查多么細心，也不能提高成績。所以說，軟件的高質量是設計出來的，而不是靠測試修補出來的。7.2測試人員的選擇測試需要開發人員參與嗎？測試需要獨立的測試小組嗎？測試需要用戶參與嗎？讓我們先看一看Microsoft公司關于測試的經驗教訓，再回答上述問題。7.2.1 Microsoft公司的經驗教訓在80年代初期，Microsoft公司的許多軟件產品出現了“Bug”。比如，在1

8、981年與IBM PC機一起推出的BASIC軟件，用戶在用“.1”（或者其他數字）除以10時，就會出錯。在FORTRAN軟件中也存在破壞數據的“Bug”。由此激起了許多采用Microsoft操作系統的PC廠商的極大不滿，而且很多個人用戶也紛紛投訴。Microsoft公司的經理們發覺很有必要引進更好的部測試與質量控制方法。但是遭到很多程序設計師甚至一些高級經理的堅決反對，他們固執地認為在高校學生、秘書或者外界合作人士的協助下，開發人員可以自己測試產品。在1984年推出Mac機的Multiplan（電子表格軟件）之前，Microsoft曾特地請Arthur Anderson咨詢公司進行測試。但是外

9、界公司一般沒有能力執行全面的軟件測試。結果，一種相當厲害的破環數據的“Bug”迫使Microsoft公司為它的萬多名用戶免費提供更新版本，代價是每個版本10美元，一共化了20萬美元，可謂損失慘重。痛定思痛后，Microsoft公司的經理們得出一個結論：如果再不成立獨立的測試部門，軟件產品就不可能達到更高的質量標準。IBM和其它有著成功的軟件開發歷史的公司便是效法的榜樣。但Microsoft公司并不照搬IBM的經驗，而是有選擇地采用了一些看起來比較先進的方法，如獨立的測試小組，自動測試以與為關鍵性的構件進行代碼復查等。Microsoft公司的一位開發部門主管戴夫穆爾回憶說：“我們清楚不能再讓開發

10、部門自己測試了。我們需要有一個單獨的小組來設計測試，運行測試，并把測試信息反饋給開發部門。這是一個偉大的轉折點。”但是有了獨立的測試小組后，并不等于萬事大吉了。自從Microsoft公司在1984年與1986年之間擴大了測試小組后，開發人員開始“變懶”了。他們把代碼扔在一邊等著測試，忘了唯有開發人員自己才能阻止錯誤的發生、防患于未來。此時，Microsoft公司歷史上第二次大災難降臨了。原定于1986年月發行的Mac機的Word3.0，千呼萬喚方于1987年2月問世。這套軟件竟然有700多處錯誤，有的錯誤可以破壞數據甚至摧毀程序。一下子就使Microsoft名聲掃地。公司不得不為用戶免費提供升

11、級版本，費用超過了100萬美元。Cusumano 19957.2.2 測試人員的分工從Microsoft公司的教訓中可知，公司部對產品的測試（稱為測試），需要開發人員與獨立的測試小組共同參與。開發人員應該執行“白盒”測試，即測試源程序的邏輯結構以與實現細節（“白盒”是指看得見程序的部結構）。而獨立測試小組應該執行“黑盒”測試，即按照規格說明來測試程序是否符合要求（“黑盒”是指看不見程序的部結構）。比如在測試一個模塊時，“白盒”測試方法要對模塊的所有代碼進行單步跟蹤測試。而“黑盒”測試方法只需測試模塊的接口是否符合要求，它關心程序的外部表現而不是部的實現細節。小型的軟件公司可能沒有條件設立獨立的

12、測試小組，也有可能測試小組人員不多而忙不過來。這時，可以讓開發小組的成員相互測試對方的程序。這里要強調的是，測試不能依賴于開發人員或者測試小組中的任意一方，必須是雙方共同參與。“白盒測試”必須由開發者自己執行，因為別的測試人員無法了解到程序的部實現細節。而“黑盒測試”必須由獨立的測試人員執行，因為開發者難以做到客觀、公正。開發者在測試自己的程序時存在一些弊病：（1）開發者對自己的程序印象深刻，并總以為是正確的（自信是應該的）。倘若在設計時就存在理解錯誤，或因不良的編程習慣而流下隱患，那么他本人很難發現這類錯誤。（2）開發者對程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發錯誤，這與

13、大眾用戶的情況不太相似，所以自己測試程序難以具備典型性。（3）程序設計有如藝術設計，開發者總是喜歡欣賞程序的成功之處，而不愿看到失敗之處。讓開發者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。即便開發者非常誠實，但“珍愛程序”的心理讓他在測試時不知不覺地帶入了虛假成份。軟件產品正式發行前，在公司外部邀請一些用戶對產品進行測試，稱為測試。測試的涉與面最廣，最能反映用戶的真實愿望，但花費的時間最長，不好控制。一般地，軟件公司與測試人員之間有一種互利的協議。即測試人員無償地為軟件公司作測試，定期遞交測試報告，提出批評與建議。而軟件公司將向測試人員免費贈送或者以很大的優惠價格發行軟件的正式版本

14、。7.3測試的主要容與常用方法有一次文學考試，問高爾基是哪國人。一考生樂極而吟：“爾基啊爾基，你若不姓高，我怎知你是中國人。”這是一種瞎猜法。如果這種方法用于軟件測試，人累死也測不出什么結果來。不論是對軟件的模塊還是整個系統，總有共同的容要測試，如正確性測試，容錯性測試，性能與效率測試，易用性測試，文檔測試等。“白盒測試”是指開發人員從程序部對上述容進行測試，而“黑盒測試”是指獨立的測試人員從程序外部對上述容進行測試。很多軟件工程教材講述了各種各樣的測試方法并例舉了不少示例Pressman 1997Sommerville 1992 文龍 1997。本節簡明地講述常用的測試方法與其道理。7.3.

15、1正確性測試正確性測試又稱功能測試，它檢查軟件的功能是否符合規格說明。由于正確性是軟件最重要的質量因素，所以其測試也最重要。基本的方法是構造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。倘若枚舉空間是無限的，那可慘了，還不如回家種土豆有盼頭。測試人員一定要設法減少枚舉的次數，否則沒好日子過。關鍵在于尋找等價區間，因為在等價區間中，只需用任意值測試一次即可。等價區間的概念可表述如下：記（A, B）是命題f(x) 的一個等價區間，在（A, B）中任意取x1進行測試。如果f (x1) 錯誤，那么f (x) 在整個（A, B）區間都將出錯。如果f (x1) 正確，那么f (x) 在整個（A,

16、 B）區間都將正確。上述測試方法稱為等價測試，來源于人們的直覺與經驗，可令測試事半功倍。還有一種有效的測試方法是邊界值測試。即采用定義域或者等價區間的邊界值進行測試。因為程序員容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯。例如測試的一段程序。憑直覺等價區間應是（0, 1）和（1, +）。可取x=0.5以與x=2.0進行等價測試。再取 x=0以與x=1進行邊界值測試。有一些復雜的程序，我們難以憑直覺與經驗找到等價區間和邊界值，這時枚舉測試就相當有難度。在用“白盒測試”方式進行正確性測試時，有個額外的好處：如果測試發現了錯誤，測試者（開發人員）馬上就能修改錯誤。越早改正錯誤，付出的代價就越低。所

17、以大多數軟件公司要求程序員在寫完程序時，馬上執行基于單步跟蹤的“白盒測試”。7.3.2容錯性測試容錯性測試是檢查軟件在異常條件下的行為。容錯性好的軟件能確保系統不發生無法意料的事故。比較溫柔的容錯性測試通常構造一些不合理的輸入來引誘軟件出錯，例如：（1）輸入錯誤的數據類型，如“猴”年“馬”月。（2）輸入定義域之外的數值，人常說的“十三點”也算一種。粗暴一些的容錯性測試俗稱“大猩猩”測試，除了不能拳打腳踢嘴咬，什么招術都可以使出來。這里我舉不出例子，因為我沒有對程序粗暴過，并且這輩子也不打算學會粗暴。7.3.3性能與效率測試性能與效率測試主要是測試軟件的運行速度和對資源的利用率。有時人們關心測試

18、的“絕對值”，如數據送輸速率是每秒多少比特。有時人們關心測試的“相對值”，如某個軟件比另一個軟件快多少倍。在獲取測試的“絕對值”時，我們要充分考慮并記錄運行環境對測試的影響。例如計算機主頻，總線結構和外部設備都可能影響軟件的運行速度；若與多個計算機共享資源，軟件運行可能慢得像蝸牛爬行。在獲取測試的“相對值”時，我們要確保被測試的幾個軟件運行于完全一致的環境中。硬件環境的一致性比較容易做到（用同一臺計算機即可）。但軟件環境的因素較多，除了操作系統，程序設計語言和編譯系統對軟件的性能也會產生較大的影響。如果是比較幾個算法的性能，就要求編程語言和編譯器也完全一致。性能與效率測試中很重要的一項是極限測

19、試，因為很多軟件系統會在極限測試中崩潰。例如，連續不停地向服務器發請求，測試服務器是否會陷入死鎖狀態不能自拔；給程序輸入特別大的數據，看看它是否吃得消。7.3.4易用性測試易用性測試沒有一個量化的指標，主觀性較強。調查表明，當用戶不理解軟件中的某個特性時，大多數人首先會向同事、朋友請教。要是再不起作用，就向產品支持部門打。只有30%的用戶會查閱用戶手冊。Cusumano 1995一般認為，如果用戶不翻閱手冊就能使用軟件，那么表明這個軟件具有較好的易用性。7.3.5文檔測試文檔測試主要檢查文檔的正確性、完備性和可理解性。好多人甚至不知道文檔是軟件的一個組成部分。正確性是指不要把軟件的功能和操作寫

20、錯，也不允許文檔容前后矛盾。完備性是指文檔不可以“虎頭蛇尾”，更不許漏掉關鍵容。有些學生在證明數學題時，喜歡用“顯然”兩字蒙混過關。文檔中很多容對開發者可能是“顯然”的，但對用戶而言不見得都是“顯然”的。文檔不可以寫成散文、詩歌或者偵探、言情小說，要讓大眾用戶看得懂，能理解。很多程序員能編寫出好程序，卻寫不出清晰的文檔。不要說自己以前語文學得差，現在已沒救了，找借口不是辦法。沒有人天生就能寫出好程序，都是練出來的。同理，若第一次寫不好文檔，就多寫幾次文檔，慢慢地就會寫出好文檔來。我上大學前不會說普通話，不會寫作文，現在我極能說會寫，當個秘書或書記已綽綽有余。7.4 改錯在軟件測試時如果發現了錯

21、誤，必須請程序員改錯，否則測試工作就白干了。改錯是個大悲大喜的過程，一天之可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過上萬個程序錯誤，那么少男少女們不必經歷失戀的挫折也能變得成熟起來。我從大三開始真正接受改錯的磨練，已記不清楚多少次汗流浹背、濕透板凳。改不了錯誤時，恨不得撞墻。改了錯誤時，比女孩子朝我笑笑還開心。在做本科畢業設計時，一天夜里，一哥們流竄到我的實驗室，哈不攏嘴地對我嚷嚷：“你知道什么叫茅塞頓開嗎？”我象白癡似的搖搖頭。他說：“今天我化了十幾個小時沒能干掉一個錯誤，剛才我去了廁所五分鐘，一切都解決了。”他還用那沒洗過的手拉我，一定要請我吃“肉夾饃”。那得意勁兒仿佛同時談了

22、兩個女朋友。在本節，我要替程序員們總結關于改錯的幾點思想方法：（1）要有勇氣。東北有個林場工人，工作勤奮，一人能干幾個人的活。前三十年是伐樹勞模，受到周總理的接見。忽有一天醒悟過來，覺得自己太對不起森林，決心補救錯誤。后三十年成了植樹勞模，受到朱總理的接見。此大勇也。程序中的錯誤只有開發者自己才能找出并改掉。如果因畏懼而拖延，會讓你終日心情不定，食無味，睡不香。所以長痛不如短痛，要集中精力對付錯誤。（2）不可蠻干。都說急中生智，我不信。我認為大多數人著急了就會蠻干，早把“智”丟到腦后。不僅人如此，動物也如此。 我們經常看到，蜜蜂或者蒼蠅想從玻璃窗中飛出，它們會頂著玻璃折騰幾個小時，卻不曉得從旁邊輕輕松松地飛走。我原以為蜜蜂和蒼蠅