軟件工程思想7
第七章 測試與改錯 編程大師說：“任何一個程序，無論它多么小，總存在著錯誤。” 初學(xué)者不相信大師的話，他問：“如果一個程序小得只執(zhí)行一個簡單的功能，那會怎樣 ？” “這樣的一個程序沒有意義，”大師說，“但如果這樣的程序存在的話，操作系統(tǒng)最后將 失效，產(chǎn)生一個錯誤?！?但初學(xué)者不滿足，他問：“如果操作系統(tǒng)不失效，那么會怎樣？” “沒有不失效的操作系統(tǒng)，”大師說，“但如果這樣的操作系統(tǒng)存在的話，硬件最后將失 效，產(chǎn)生一個錯誤?！?初學(xué)者仍不滿足，再問：“如果硬件不失效，那么會怎樣？” 大師長嘆一聲道：“沒有不失效的硬件。但如果這樣的硬件存在的話，用戶就會想讓那 個程序做一件不同的事，這件事也是一個錯誤?！?沒有錯誤的程序世間難求。[James 1999] 錯誤是一種嚴重的程序缺陷。測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，并期望通過改 錯來把缺陷統(tǒng)統(tǒng)消滅，以期提高軟件的質(zhì)量。但關(guān)于測試與改錯實在沒有什么高明的方 法值得大書特書，也不能表現(xiàn)出程序員的聰明才智。相反地，它們帶來了更多的牢騷與 痛苦。因此在教學(xué)和開發(fā)實踐中，測試與改錯總是被當作萬般無奈的工作踢到角落里。 醫(yī)生可以把他的錯誤埋葬在地下了事，但程序員不能。我們必須要學(xué)會測試與改錯， 并且把測試與改錯工作做好。 7.1 對測試的理解 測試的道理并不深奧，計算機專業(yè)人員都應(yīng)該明白。但就是這么簡單的事，計算機專業(yè) 的博士們也未必都已經(jīng)理解。 有一天，一位比我聰明，編程比我快，學(xué)習(xí)能力比我強的計算機專業(yè)博士生恭恭敬敬地 請我坐好，并且史無前例地削了蘋果請我吃，為的是向我請教“軟件工程”問題。你必定 以為這位仁兄好學(xué)之極。非也，我和他同事三年來從未探討過“軟件工程”問題。只因為 他明天要去應(yīng)聘，參加面試，生怕被人問倒，就央我當晚為他惡補一把“軟件工程”。他 還特地問我“什么是白盒測試和黑盒測試？應(yīng)該由誰來執(zhí)行？”（有公司曾經(jīng)這樣面試應(yīng) 聘者）當我解釋完測試的道理時，他嘆了一口氣說：“這些玩意兒我讀大學(xué)十年來都沒搞 過，怎么能講得出道理來。唉，就去碰碰運氣吧?！蔽矣小巴盟篮钡母杏X。我們這一群 博士生三年來盡干些自欺欺人的事，到畢業(yè)時學(xué)問既不深也不博。個個意志消沉，老氣 橫秋。長此以往，總有一天招聘會的大門前將貼出標語“博士與狗不得入內(nèi)”。 以下是關(guān)于測試的幾個重要觀念。 7.1.1 測試的目的 測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷。 這里缺陷是一種泛稱，它可以指功能的錯誤，也可以指性能低下，易用性差等等。測試 總是先假設(shè)程序中存在缺陷，再通過執(zhí)行程序來發(fā)現(xiàn)并最終改正缺陷。理解測試的目的 是個很重要的意識問題。如果說測試的目的是為了說明程序中沒有缺陷，那么測試人員 就會向這個目標靠攏，因而下意識地選用一些不易暴露錯誤的測試示例。這樣的測試是 虛假的。 目前高校的科技成果鑒定會普遍存在類似的虛假現(xiàn)象。我在讀碩士時就親身經(jīng)歷過這 樣的事。我們的項目是研究集成電路制造過程中的成品率問題。當時國內(nèi)大多數(shù)工廠的 集成電路成品率只有百分之幾，我編寫的示例程序可以將集成電路的成品率優(yōu)化到98%。 示例效果是如此的好，以致一位評委（某廠的總工程師）不無諷刺地說：“采用你們的成 果，我們可要發(fā)大財了?！边@個項目就輕易地通過了鑒定，并且不久后獲得了電子工業(yè)部 科技進步二等獎。這就象在考試時通過作弊取得了好成績而被表揚。我那時尚且純真， 羞愧之余，不禁對高校科研成果的水平和真實性大失所望（現(xiàn)在我已不再失望，因為很 少抱希望）。 一個成功的測試示例在于發(fā)現(xiàn)了至今尚未發(fā)現(xiàn)的缺陷。 測試并不僅是個技術(shù)問題，更是個職業(yè)道德問題。 7.1.2 測試的心理要求 測試主要是由人而不是由機器執(zhí)行，這就不免與心理因素相關(guān)。為了測試的真實性， 對測試的心理要求是“無情”。這似乎太殘酷了。開發(fā)人員不能很好地測試自己的程序是 因為做不到無情。而測試人員如果做到了無情卻會引起開發(fā)人員的憤怒，遭人白眼。 盡管已經(jīng)明白了測試的目的是為了發(fā)現(xiàn)盡可能多的缺陷，但當測試人員真的發(fā)現(xiàn)了一 堆缺陷時，卻不可樂顛顛地跑去恭喜那個倒霉的開發(fā)者，否則會打架的。 7.1.3 測試的真理 測試只能證明缺陷存在，而不能證明缺陷不存在。 這個真理告訴我們，對于一個復(fù)雜的系統(tǒng)而言，無論采取什么樣的測試手段都不能證 明缺陷已經(jīng)不復(fù)存在。“徹底地測試”只是一種理想。在實踐中，測試要考慮時間、費用 等限制，不允許無休止地測試。 7.1.4 測試與質(zhì)量的關(guān)系 測試有助于提高軟件的質(zhì)量，但是提高軟件的質(zhì)量不能依賴于測試。測試與質(zhì)量的關(guān) 系很象在考試中“檢查”與“成績”的關(guān)系。 學(xué)習(xí)好的學(xué)生，在考試時通過認真檢查能減少因疏忽而造成的答題錯誤，從而“提高” 了考試成績（取得他本來就該得的好成績）。 而學(xué)習(xí)差的學(xué)生，他原本就不會做題目，無論檢查多么細心，也不能提高成績。 所以說，軟件的高質(zhì)量是設(shè)計出來的，而不是靠測試修補出來的。 7.2 測試人員的選擇 測試需要開發(fā)人員參與嗎？ 測試需要獨立的測試小組嗎？ 測試需要用戶參與嗎？ 讓我們先看一看Microsoft公司關(guān)于測試的經(jīng)驗教訓(xùn)，再回答上述問題。 7.2.1 Microsoft公司的經(jīng)驗教訓(xùn) 在80年代初期，Microsoft公司的許多軟件產(chǎn)品出現(xiàn)了“Bug”。比如，在1981年與IBM PC機一起推出的BASIC軟件，用戶在用“.1”（或者其他數(shù)字）除以10時，就會出錯。在 FORTRAN軟件中也存在破壞數(shù)據(jù)的“Bug”。由此激起了許多采用Microsoft操作系統(tǒng)的PC廠 商的極大不滿，而且很多個人用戶也紛紛投訴。 Microsoft公司的經(jīng)理們發(fā)覺很有必要引進更好的內(nèi)部測試與質(zhì)量控制方法。但是遭 到很多程序設(shè)計師甚至一些高級經(jīng)理的堅決反對，他們固執(zhí)地認為在高校學(xué)生、秘書或 者外界合作人士的協(xié)助下，開發(fā)人員可以自己測試產(chǎn)品。在1984年推出Mac機的Multipl an（電子表格軟件）之前，Microsoft曾特地請Arthur Anderson咨詢公司進行測試。但是外界公司一般沒有能力執(zhí)行全面的軟件測試。結(jié)果， 一種相當厲害的破環(huán)數(shù)據(jù)的“Bug”迫使Microsoft公司為它的２萬多名用戶免費提供更新 版本，代價是每個版本10美元，一共化了20萬美元，可謂損失慘重。 痛定思痛后，Microsoft公司的經(jīng)理們得出一個結(jié)論：如果再不成立獨立的測試部門 ，軟件產(chǎn)品就不可能達到更高的質(zhì)量標準。IBM和其它有著成功的軟件開發(fā)歷史的公司便 是效法的榜樣。但Microsoft公司并不照搬IBM的經(jīng)驗，而是有選擇地采用了一些看起來 比較先進的方法，如獨立的測試小組，自動測試以及為關(guān)鍵性的構(gòu)件進行代碼復(fù)查等。 Microsoft公司的一位開發(fā)部門主管戴夫·穆爾回憶說：“我們清楚不能再讓開發(fā)部門自己 測試了。我們需要有一個單獨的小組來設(shè)計測試，運行測試，并把測試信息反饋給開發(fā) 部門。這是一個偉大的轉(zhuǎn)折點。” 但是有了獨立的測試小組后，并不等于萬事大吉了。自從Microsoft公司在1984年與 1986年之間擴大了測試小組后，開發(fā)人員開始“變懶”了。他們把代碼扔在一邊等著測試 ，忘了唯有開發(fā)人員自己才能阻止錯誤的發(fā)生、防患于未來。此時，Microsoft公司歷史 上第二次大災(zāi)難降臨了。原定于1986年７月發(fā)行的Mac機的Word 3.0，千呼萬喚方于1987年2月問世。這套軟件竟然有700多處錯誤，有的錯誤可以破壞數(shù) 據(jù)甚至摧毀程序。一下子就使Microsoft名聲掃地。公司不得不為用戶免費提供升級版本 ，費用超過了100萬美元。[Cusumano 1995] 7.2.2 測試人員的分工 從Microsoft公司的教訓(xùn)中可知，公司內(nèi)部對產(chǎn)品的測試（稱為α測試），需要開發(fā)人 員與獨立的測試小組共同參與。開發(fā)人員應(yīng)該執(zhí)行“白盒”測試，即測試源程序的邏輯結(jié) 構(gòu)以及實現(xiàn)細節(jié)（“白盒”是指看得見程序的內(nèi)部結(jié)構(gòu)）。而獨立測試小組應(yīng)該執(zhí)行“黑盒 ”測試，即按照規(guī)格說明來測試程序是否符合要求（“黑盒”是指看不見程序的內(nèi)部結(jié)構(gòu)） 。比如在測試一個模塊時，“白盒”測試方法要對模塊的所有代碼進行單步跟蹤測試。而 “黑盒”測試方法只需測試模塊的接口是否符合要求，它關(guān)心程序的外部表現(xiàn)而不是內(nèi)部 的實現(xiàn)細節(jié)。 小型的軟件公司可能沒有條件設(shè)立獨立的測試小組，也有可能測試小組人員不多而忙 不過來。這時，可以讓開發(fā)小組的成員相互測試對方的程序。 這里要強調(diào)的是，α測試不能依賴于開發(fā)人員或者測試小組中的任意一方，必須是雙 方共同參與?！鞍缀袦y試”必須由開發(fā)者自己執(zhí)行，因為別的測試人員無法了解到程序的 內(nèi)部實現(xiàn)細節(jié)。而“黑盒測試”必須由獨立的測試人員執(zhí)行，因為開發(fā)者難以做到客觀、 公正。開發(fā)者在測試自己的程序時存在一些弊?。?（1）開發(fā)者對自己的程序印象深刻，并總以為是正確的（自信是應(yīng)該的）。倘若在設(shè)計 時就存在理解錯誤，或因不良的編程習(xí)慣而流下隱患，那么他本人很難發(fā)現(xiàn)這類錯誤。 （2）開發(fā)者對程序的功能、接口十分熟悉，他自己幾乎不可能因為使用不當而引發(fā)錯誤 ，這與大眾用戶的情況不太相似，所以自己測試程序難以具備典型性。 （3）程序設(shè)計有如藝術(shù)設(shè)計，開發(fā)者總是喜歡欣賞程序的成功之處，而不愿看到失敗之 處。讓開發(fā)者去做“蓄意破壞”的測試，就象殺自己的孩子一樣難以接受。即便開發(fā)者非 常誠實，但“珍愛程序”的心理讓他在測試時不知不覺地帶入了虛假成份。 軟件產(chǎn)品正式發(fā)行前，在公司外部邀請一些用戶對產(chǎn)品進行測試，稱為β測試。β測試 的涉及面最廣，最能反映用戶的真實愿望，但花費的時間最長，不好控制。一般地，軟 件公司與β測試人員之間有一種互利的協(xié)議。即β測試人員無償?shù)貫檐浖咀鳒y試，定 期遞交測試報告，提出批評與建議。而軟件公司將向β測試人員免費贈送或者以很大的優(yōu) 惠價格發(fā)行軟件的正式版本。 7.3 測試的主要內(nèi)容與常用方法 有一次文學(xué)考試，問高爾基是哪國人。一考生樂極而吟：“爾基啊爾基，你若不姓高 ，我怎知你是中國人?！边@是一種瞎猜法。如果這種方法用于軟件測試，人累死也測不出 什么結(jié)果來。 不論是對軟件的模塊還是整個系統(tǒng)，總有共同的內(nèi)容要測試，如正確性測試，容錯性 測試，性能與效率測試，易用性測試，文檔測試等?！鞍缀袦y試”是指開發(fā)人員從程序內(nèi) 部對上述內(nèi)容進行測試，而“黑盒測試”是指獨立的測試人員從程序外部對上述內(nèi)容進行 測試。很多軟件工程教材講述了各種各樣的測試方法并例舉了不少示例[Pressman 1997] [Sommerville 1992] [楊文龍 1997]。本節(jié)簡明地講述常用的測試方法及其道理。 7.3.1 正確性測試 正確性測試又稱功能測試，它檢查軟件的功能是否符合規(guī)格說明。由于正確性是軟件 最重要的質(zhì)量因素，所以其測試也最重要。 基本的方法是構(gòu)造一些合理輸入，檢查是否得到期望的輸出。這是一種枚舉方法。倘 若枚舉空間是無限的，那可慘了，還不如回家種土豆有盼頭。測試人員一定要設(shè)法減少 枚舉的次數(shù)，否則沒好日子過。關(guān)鍵在于尋找等價區(qū)間，因為在等價區(qū)間中，只需用任 意值測試一次即可。等價區(qū)間的概念可表述如下： 記（A, B）是命題f(x) 的一個等價區(qū)間，在（A, B）中任意取x1進行測試。 如果f (x1) 錯誤，那么f (x) 在整個（A, B）區(qū)間都將出錯。 如果f (x1) 正確，那么f (x) 在整個（A, B）區(qū)間都將正確。 上述測試方法稱為等價測試，來源于人們的直覺與經(jīng)驗，可令測試事半功倍。 還有一種有效的測試方法是邊界值測試。即采用定義域或者等價區(qū)間的邊界值進行測 試。因為程序員容易疏忽邊界情況，程序也“喜歡”在邊界值處出錯。 例如測試[pic]的一段程序。憑直覺等價區(qū)間應(yīng)是（0, 1）和（1, +∞）。可取x=0.5以及x=2.0進行等價測試。再取 x=0以及x=1進行邊界值測試。 有一些復(fù)雜的程序，我們難以憑直覺與經(jīng)驗找到等價區(qū)間和邊界值，這時枚舉測試就 相當有難度。 在用“白盒測試”方式進行正確性測試時，有個額外的好處：如果測試發(fā)現(xiàn)了錯誤，測 試者（開發(fā)人員）馬上就能修改錯誤。越早改正錯誤，付出的代價就越低。所以大多數(shù) 軟件公司要求程序員在寫完程序時，馬上執(zhí)行基于單步跟蹤的“白盒測試”。 7.3.2 容錯性測試 容錯性測試是檢查軟件在異常條件下的行為。容錯性好的軟件能確保系統(tǒng)不發(fā)生無法 意料的事故。 比較溫柔的容錯性測試通常構(gòu)造一些不合理的輸入來引誘軟件出錯，例如： （1）輸入錯誤的數(shù)據(jù)類型，如“猴”年“馬”月。 （2）輸入定義域之外的數(shù)值，上海人常說的“十三點”也算一種。 粗暴一些的容錯性測試俗稱“大猩猩”測試，除了不能拳打腳踢嘴咬，什么招術(shù)都可以 使出來。這里我舉不出例子，因為我沒有對程序粗暴過，并且這輩子也不打算學(xué)會粗暴 。 7.3.3 性能與效率測試 性能與效率測試主要是測...
軟件工程思想7