第七章 測試與改錯

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

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

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

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

5、工廠的集成電路成品率只有百分之幾，我編寫的示例程序可以將集成電路的成品率優(yōu)化到98%。示例效果是如此的好，以致一位評委（某廠的總工程師）不無諷刺地說：“采用你們的成果，我們可要發(fā)大財了?！边@個項目就輕易地通過了鑒定，并且不久后獲得了電子工業(yè)部科技進步二等獎。這就象在考試時通過作弊取得了好成績而被表揚。我那時尚且純真，羞愧之余，不禁對高?？蒲谐晒乃胶驼鎸嵭源笫ìF(xiàn)在我已不再失望，因為很少抱希望）。一個成功的測試示例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。測試并不僅是個技術問題，更是個職業(yè)道德問題。7.1.2 測試的心理要求測試主要是由人而不是由機器執(zhí)行，這就不免與心理因素相關。為了測試的真實性，對

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

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

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

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

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

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

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

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

14、價格發(fā)行軟件的正式版本。7.3 測試的主要內(nèi)容與常用方法有一次文學考試，問高爾基是哪國人。一考生樂極而吟：“爾基啊爾基，你若不姓高，我怎知你是中國人?！边@是一種瞎猜法。如果這種方法用于軟件測試，人累死也測不出什么結果來。不論是對軟件的模塊還是整個系統(tǒng)，總有共同的內(nèi)容要測試，如正確性測試，容錯性測試，性能與效率測試，易用性測試，文檔測試等?！鞍缀袦y試”是指開發(fā)人員從程序內(nèi)部對上述內(nèi)容進行測試，而“黑盒測試”是指獨立的測試人員從程序外部對上述內(nèi)容進行測試。很多軟件工程教材講述了各種各樣的測試方法并例舉了不少示例Pressman 1997 Sommerville 1992 楊文龍 1997。本節(jié)簡明

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

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

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

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

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

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

21、當個秘書或書記已綽綽有余。7.4 改 錯在軟件測試時如果發(fā)現(xiàn)了錯誤，必須請程序員改錯，否則測試工作就白干了。改錯是個大悲大喜的過程，一天之內(nèi)可以讓人在悲傷的低谷和喜悅的顛峰之間跌蕩起伏。如果改過上萬個程序錯誤，那么少男少女們不必經(jīng)歷失戀的挫折也能變得成熟起來。我從大三開始真正接受改錯的磨練，已記不清楚多少次汗流浹背、濕透板凳。改不了錯誤時，恨不得撞墻。改了錯誤時，比女孩子朝我笑笑還開心。在做本科畢業(yè)設計時，一天夜里，一哥們流竄到我的實驗室，哈不攏嘴地對我嚷嚷：“你知道什么叫茅塞頓開嗎？” 我象白癡似的搖搖頭。他說：“今天我化了十幾個小時沒能干掉一個錯誤，剛才我去了廁所五分鐘，一切都解決了?！彼?/p>

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