1.1 軟件測試的產生

隨著軟件技術的迅速發展和廣泛深入地應用于人類社會和生活的各個領域，隨著軟件系統的規模和復雜性與日俱增，軟件的生產成本和軟件中存在的缺陷和故障造成的各類損失也在不斷發生，其錯誤產生的概率正在大大增加，甚至有時會帶來災難性的后果。軟件的質量問題已成為所有應用軟件和開發軟件的人們關注的焦點，由于軟件是人腦的高度智能化的具體體現，不同于其他科技與生產領域，因此軟件與生俱來就有可能存在缺陷或故障，并難以根除。如何防止和減少軟件可能存在的問題呢？答案是進行軟件測試。軟件測試是最有效的排除和防止軟件缺陷與故障的手段，通過加強軟件測試來控制質量，通過修正缺陷來提高軟件產品的質量。軟件測試的產生和運用促進了軟件測試的學科理論與技術運用的快速發展，新的軟件測試理論、新的軟件測試策略與方法、新的軟件測試技術在不斷地涌出和創新。軟件測試已成為軟件行業中的專門學科，軟件測試的運用與實踐也在蓬勃發展，軟件企業中的軟件測試專門組織和機構誕生和發展起來，同時伴隨產生的是軟件測試工作的專業化和職業化。

1.1.1 軟件可靠性問題

自計算機軟件產生以來，研究表明，因軟件的錯誤和故障而引發的系統失效、崩潰，產生的錯誤與因計算機硬件故障而引發的系統失效的比例大約是10:1。現代社會對計算機系統的需求迅速增加，而計算機系統的“靈魂”是軟件。人類對計算機的依賴程度越高，對其可靠性的要求也就越高。實驗數據表明，目前在各類計算機中運行的軟件留存的故障密度，對于要求很高的金融系統中的關鍵財務軟件為每千行代碼1～10個缺陷或故障，對于關鍵的各種相關生命系統中的軟件，如醫學計算系統、載人航天等計算系統等，為每千行代碼0.01～1個缺陷或故障。與之相比，其他領域對可靠性要求相對較低的各類軟件系統，其缺陷或故障的存在就更多了。因此，計算機科學家和軟件工程師們一直在不斷努力地改善軟件的這種狀況，而正是由于軟件系統的可靠性大幅度地提高，才使得計算機系統能夠廣泛而深入地應用于人類社會生活的各個方面。

一個可靠的軟件系統應該是正確、完整、一致和健壯的，也是軟件用戶所期望的。IEEE組織將軟件的可靠性定義為：系統在特定環境下，在給定的時間內無故障運行的概率。因此，軟件可靠性是對軟件在設計、開發以及所預定的環境下具有特定能力的置信度的一個度量，它是衡量軟件質量的主要參數。軟件測試是保證軟件質量，提高軟件可靠性的最重要的策略與手段。目前，軟件測試在整個軟件開發周期中所占的比例日益上升，許多軟件開發組織已將軟件開發所耗費的資源的40%用于測試。對于高可靠性的軟件系統，如飛行控制、軍事武器系統、核反應堆控制、金融軟件、生命科學、醫療診斷等，其軟件測試費用是軟件開發其他階段所耗費的費用總和的數倍。

人類從很早就認識到一條規律，即不能僅僅依靠自己來檢查自己的工作或產品，必須由他人來監督和檢查，以保證客觀性。由于軟件產品的“特殊”性質，其可靠性必須依賴于軟件測試這個環節與過程。

1.1.2 軟件缺陷與故障

1.軟件缺陷和故障案例

當今人類的生存和發展已經離不開各種各樣的信息服務，為了獲取這些信息，需要計算機網絡或通信網絡的支撐，這里不僅包含計算機硬件設備，還包括各種功能和用途的計算機軟件，軟件無處不在。然而，軟件是由人編寫開發的，是一種邏輯思維的產品，盡管現在軟件開發當中采取了一系列的有效措施，能不斷地提高軟件產品的質量，但仍然無法完全避免軟件會存在各種各樣的缺陷。

軟件故障或缺陷，依據其可能造成的危害程度不同，分為輕、重等不同級別。通過下面幾例軟件缺陷和故障的案例分析，足以說明軟件缺陷和故障問題造成的嚴重損失和災難。

【案例1】美國迪斯尼公司生產的獅子王游戲軟件bug事件，這是一項典型的軟件兼容性缺陷問題。1994年，該公司發布面向青少年的游戲軟件“獅子王動畫故事書”，銷售異常火爆，使該游戲軟件幾乎成為當年秋季全美青少年必買的游戲軟件產品。但產品售后不久，客戶支持部投訴電話就一直不斷，憤怒的兒童家長和玩不成游戲的孩子們大量投訴該游戲軟件的缺陷，一時間報紙和電視媒體大量報道了這一游戲軟件的各種問題，使該公司的聲譽大損，并為改正軟件缺陷和故障付出了沉重的代價。后經調查證實，造成這一嚴重問題的原因是迪斯尼公司沒有對該游戲軟件在已投入市場上使用的各種PC機型上進行完整的測試，游戲軟件對硬件環境的兼容性沒有得到保障，雖然該游戲軟件在軟件工程師們的機器硬件系統上工作正常，但在大眾群體使用的系統中卻存在不兼容的問題。

【案例2】美國航天局火星極地飛船著陸事故。1999年12月3日，美國航天局的火星極地著陸飛船在試圖登陸火星表面時突然失蹤。負責這一太空發展項目的錯誤修正委員會的專家們觀測到這一幕并分析了事故，確定出現該事故的原因可能是由于某一數據位被意外地更改，造成災難性后果，并得出造成事故的問題應在內部測試時就予以解決的結論。簡要地說，火星極地飛船著陸過程是這樣的：當飛船快要降落火星表面時，它將打開著陸降落傘以減緩飛船下落速度，在飛船距離火星1800m時，飛船將丟棄降落傘，同時點燃著陸推進器（反向推力），控制和穩定飛船的下降速度，同時飛船的三條支撐腳將迅速打開，使其在剩余的高度里緩慢降落到火星表面，在預定地點著陸。然而為節省研制經費，簡化了確定何時關閉著陸推進器的自動裝置，由通常太空船使用的昂貴著陸雷達系統改為在飛船的支撐腳上安裝簡易觸發開關，并在著陸程序中設置一個數據位來控制關閉著陸推進器燃料開關。顯然，飛船支撐腿在沒有著地之前，推進器引擎將一直處于著火工作狀態，支撐腳著地瞬間，觸發開關，程序控制關閉燃料，平穩安全著陸。但遺憾的是，事后分析測試中發現，當飛船的支撐腳打開準備著陸時，機械的震動卻很容易觸發著地觸電開關，導致程序設置了錯誤的數據位，關閉了著陸推進器燃料，也就是說，使得著陸推進器提前停止工作，使著陸飛船加速下墜1800m之后直接沖向了火星表面，飛船撞成碎片。這一事故后果非常嚴重，損失巨大，然而起因卻如此簡單，屬于軟件設計中的缺陷。事實是飛行發射之前，飛船各部位工作過程經過多個小組的測試，其中一個小組測試飛船的支撐腳落地的打開過程，另一個小組測試此后的著陸過程。前一小組沒有注意到著地數據位是否已置位，因為這不屬于他們負責的范圍，而后一小組總是在開始測試之前重置計算機，進行數據的初始化，清除數據位。雙方獨立工作都很好，但從未在一起進行集成（系統）測試，使系統測試中的銜接問題故障隱藏起來，從而導致災難性事故的發生。

【案例3】跨世紀的“千年蟲”問題。這是一個著名的軟件缺陷問題，20世紀末的最后幾年，全球各類計算機硬件系統、軟件系統和應用系統都在為2000年份時間兼容問題及與此年份相關的其他存在安全隱患的“千年蟲問題”付出巨大代價。據不完全統計，1998年初全球開始進行“千年蟲”問題大檢查，僅在金融、保險、軍事、科學、商務等領域花費大量的人力、物力對現有的各種各樣的程序進行檢查、修改和更正，全球耗資高達幾百億美元。

【案例4】愛國者導彈防御系統炸死自家人。美國愛國者導彈系統首次應用于海灣戰爭中，屢建功勛，多次成功攔截飛毛腿導彈。但確實也有幾次在對抗中失利，其中一枚導彈在沙特的多哈戰斗中炸死了28名美軍士兵。事后，分析專家得出結論：災難是愛國者導彈防御系統中一個軟件系統的缺陷所致，一個很小的系統時鐘錯誤積累起來可能延時14個小時，造成跟蹤系統失去準確度。在多哈襲擊戰中，導彈系統的重要時刻被延時100多個小時，造成悲劇。

諸如上述的軟件錯誤或漏洞絕不僅僅是這幾例，類似的報告數不勝數，據美國國家標準和技術協會在2002年公布的一項關于軟件缺陷引起的經濟損失的報告中的數據表明，軟件缺陷造成的美國經濟損失達到595億美元。

全球廣泛使用的多種軟件的缺陷和錯誤經常被用戶披露或曝光，軟件公司不停地發布各種修正版本和軟件補丁的現象已屢見不鮮。

2.軟件缺陷的定義

從上述軟件故障或缺陷實例中可以看到軟件發生錯誤時造成的災難性危害或對用戶的各種損失及影響。那么，這些事件的共同特點有哪些呢？首先，軟件開發過程可能沒有按照預期規則或目標要求進行；其次，軟件雖然都經過測試，但并不能保證完全排除了存在（特別是潛在）的錯誤。對軟件測試而言，其任務就是要采用科學方法和技術手段來發現軟件中所隱藏的錯誤，找出那些不明顯、難以察覺、可能很簡單而細微的錯誤，要到達此目的，是對軟件測試人員的巨大挑戰。

軟件問題，即軟件bug。之所以稱為bug，源于1945年9月美國海軍編程員、編譯器的發明者格雷斯·哈柏（Grace Hopper）在排查“Mark II”計算機死機原因時，發現是第70號繼電器出現故障，而在其中躺著一只被繼電器電死的飛蛾，他將死飛蛾用透明膠布貼在了“事件記錄本”當中，并注明“第一個發線蟲子（bug）的實例”。此后，人們將計算機錯誤戲稱為蟲子（bug），而將排查尋找錯誤的工作稱為Debug。在軟件工程或軟件測試中都被稱為軟件缺陷或軟件故障。在不引起誤解的情況下，不管軟件存在問題的規模和危害是大還是小，由于都會產生軟件使用上的各種障礙，所以將這些問題統稱為軟件缺陷。

對于軟件缺陷的精確定義，通常全球軟件業界普遍認同下列5條規則：

（1）軟件未達到產品說明書中已經標明的功能；

（2）軟件出現了產品說明書中指明不會出現的錯誤；

（3）軟件未達到產品說明書中雖未指出但應當達到的目標；

（4）軟件功能超出了產品說明書中指明的范圍；

（5）測試專業人員認為軟件難以理解、不易使用，或者最終用戶認為該軟件使用效果不良。

為了更好地理解以上描述，這里以日常使用的計算器內的嵌入式軟件來說明上述5條規則。

計算器說明書一般聲稱該計算器將準確無誤進行加、減、乘、除運算。如果測試人員或用戶選定了兩個數值后，隨意按下了“+”號鍵，結果沒有任何反應，根據規則（1），這是一個軟件缺陷；如果得到錯誤答案，根據規則（1），同樣是軟件缺陷。

假如計算器產品說明書指明計算器不會出現崩潰、死鎖或者停止反應，而在用戶隨意按、敲鍵盤后，計算器停止接受輸入或沒有了反應，根據規則（2），這也是一個軟件缺陷。

若在進行測試時，發現除了規定的加、減、乘、除功能之外，還能夠進行求平方根的運算，而這一功能并沒有在說明書的功能中規定，根據規則（3），這也是軟件缺陷。

若在測試過程中發現，因電池沒電而導致計算不正確，但產品說明書未能指出在此情況下應如何處理，根據規則（4），也應算做軟件缺陷。

規則（5）說明了無論測試人員或者是最終用戶，若發現計算器某些地方不好用，例如，按鍵太小、顯示屏在亮光下無法看清等，也應算做軟件缺陷。

3.軟件缺陷的特征

大量的測試理論研究及測試實踐經驗的積累表明，軟件缺陷的特征主要有兩類：第一，軟件系統的思維邏輯性與復雜性等特殊性質決定了其缺陷不易直接從肉眼看到，即“難于看到”；第二，即使在運行與使用當中發現了軟件的缺陷或故障，但不易找到問題發生的原因所在，即“看到了但難于抓得到”。

4.軟件缺陷產生的原因

軟件測試是在軟件投入運行之前，對軟件需求分析、設計規格說明和編碼實現的最終審定。那為什么還會產生軟件缺陷呢？經過軟件測試專家們的研究發現，表現在程序中的故障并不一定是由編碼過程所引起的，大多數的軟件缺陷并非來自編碼過程中的錯誤，從小項目到大項目都基本上證明了這一點。因其軟件缺陷很可能是在系統詳細設計階段、概要設計階段，甚至是在需求分析階段就存在的問題所導致的，即使針對源程序進行測試所發現的故障的根源也可能存在于軟件開發前期的各個階段。大量的事實表明，導致軟件缺陷的最大原因源于軟件產品的設計文檔（各種設計、規劃文件及說明書）。在大多數情況下，軟件產品設計文檔沒有明確、不清楚或者描述不全面，或在軟件開發過程中對需求、產品功能經常更改，或開發小組的人員之間沒有完全進行很好地交流與溝通，沒有很好地組織開發與執行測試流程。因此，制定軟件產品開發計劃非常重要，若產品計劃沒有制定好，軟件缺陷就會潛伏在程序中，軟件運行時出現問題在所難免。

軟件缺陷產生的第二大來源是設計方案，這是實施軟件計劃的關鍵環節。

典型的軟件缺陷產生的原因大致被歸納為以下幾種類型：

（1）軟件需求解釋存在有錯誤或不明確。

（2）用戶需求的定義中存在錯誤。

（3）軟件需求中記錄存在錯誤。

（4）軟件的設計說明中有錯誤。

（5）軟件的編碼中說明有錯誤。

（6）軟件程序代碼存在錯誤。

（7）數據輸入有錯誤。

（8）軟件測試過程中有錯誤。

（9）軟件問題修改得不正確或不徹底。

（10）有時不正確的結果是由于其他的軟件缺陷而引起或產生的。

如圖1.1所示為軟件缺陷產生的原因分布圖，軟件產品設計的文檔說明（如需求等）成為軟件缺陷產生的原因的主要成分。

1.1.3 軟件測試的發展

通常被稱為bug的軟件缺陷是伴隨著軟件出現的，而軟件測試同樣也是伴隨著軟件的出現而出現的，隨著軟件規模的劇增和復雜程度的不斷提升，其bug日益增多且破壞性增強，造成了嚴重的質量事故，使得軟件開發者和使用者“對抗”軟件缺陷的態度日益堅決，不斷對軟件質量提出新要求。由此，隨著軟件的誕生和發展而產生了軟件測試，并越來越得到重視，同時帶動了軟件測試自身發展，表現在理論方面的不斷豐富和技術運用及工程實踐方面的日益成熟。

軟件測試從軟件20世紀60年代被正式建立。1961年，一個簡單的軟件錯誤導致了美國大力神州際導彈的助推器的毀滅，致使美國空軍強制要求在其后的關鍵發射任務中，必須進行獨立的驗證，從而建立了軟件的驗證和確認的方法論，軟件測試就此開始興起。

隨著軟件的發展，軟件測試也隨之不斷發展，軟件測試大致經歷了如圖1.2所示的幾個重要階段。

1.軟件調試

早期軟件的規模較小，復雜程度相對較低，因此軟件驗證及錯誤的排查在開發階段由開發人員在調試時就發現并加以解決，這個階段的軟件測試工作基本等同于調試工作。軟件開發人員對自己的程序進行簡單的測試，該階段處于軟件測試的原始階段。而現在，大部分軟件開發平臺（工具）都集成調試工具，調試已成為軟件開發不可或缺的一部分工作。但軟件調試一般并不能解決軟件的邏輯正確性和軟件的功能、性能問題。

2.獨立的軟件測試

20世紀60年代后，軟件開發者開始意識到僅靠軟件調試是不夠的，并不能完全找到軟件的故障或缺陷，必須建立一個獨立的組織進行軟件測試。這個階段的測試絕大部分是在軟件產品（系統）完成之后進行的，因此測試的力度和時間有限，軟件交付使用后依然有可能存在大量問題。

這個階段還未形成任何軟件測試的方法理論，主要是靠對軟件錯誤的猜測和經驗進行推斷，因此并沒有對軟件測試進行定義，也沒有對軟件測試的真正含義進行深入思考。

3.軟件測試首次定義

1973年，Bill Hetzel給出了軟件測試的第一個定義：“軟件測試就是對程序能夠按預期的要求運行建立起的一種信心”。1983年，他又修改了這個定義，即“軟件測試就是評價一個程序或系統的品質或能力目的的一項活動”。

這個階段對軟件測試形成的認識就是：軟件測試用于驗證軟件（產品）是否能正確工作，并且符合要求。

但同一時期，Glenford J.Myers則將軟件測試認為，軟件測試不應該專注于驗證軟件產品是能工作的，而應該將驗證軟件是不工作的作為測試重點，他提出的軟件測試定義是：“測試是以發現錯誤為目的而運行的程序或系統的執行過程”。

4.軟件測試成為專門學科

20世紀80年代后，軟件產業迅速發展，軟件規模越來越大，復雜程度越來越高，如操作系統、大型商務軟件、航天飛船控制系統、工業控制流程系統等，其軟件開發人員上千人，程序幾十、甚至上千萬行。軟件的質量受到高度重視，軟件測試理論和技術得到快速發展，人們將軟件測試作為重要手段來控制和保障、評價軟件的質量。

1982年在美國北卡羅來納大學召開了首次軟件測試正式會議，軟件測試理論開始發展，出現了多種軟件測試的方法和技術。

1983年，IEEE組織對軟件測試做出如下定義：

（1）使用人工或自動的手段來運行或測量軟件系統的過程，目的是檢驗軟件系統是否滿足規定的要求，并找出與預期結果之間的差異。

（2）軟件測試是一門需要經過設計、開發和維護等完整階段的軟件工程。

從這個階段開始，軟件測試進入新時期，成為一個專門的學科，形成了測試理論、方法和各種測試技術，并開始開發和運用某些測試工具，同時軟件測試被列入軟件工程的范疇，運用于軟件工程實踐。

5.開發與測試的融合

20世紀90年代后，軟件工程發展迅速，形成了各種各樣的軟件開發模式，同時關于軟件質量的研究和實踐技術不斷理論化和工程化，軟件開發得到規范性的要求和約束，軟件開發模式的多樣化也使軟件測試相輔相成，軟件開發與測試出現了融合。以敏捷開發模式為代表的新一代軟件開發模式在國際一流軟件企業開始探索和實施，融入了軟件產品開發的新思想、新模式，如極限編程、測試驅動、角色互換、團隊模式，等等，并贏得很多軟件開發團隊的青睞，獲得了成功，如應用在IBM和微軟公司的多個大型軟件項目開發中。

由此帶來的是對軟件測試的重新思考。軟件測試與軟件開發由相對的獨立特性逐漸開始進行融合，開發人員將承擔起軟件測試的責任，測試人員將更多地參與到測試代碼的開發中去，軟件的開發與測試界限變得模糊起來。如TDD就把測試作為起點和首要任務。（Test-Driven Development，TDD，測試驅動開發。敏捷開發中的一項核心實踐和技術，也是一種設計方法論。TDD原理是在開發功能代碼之前，先編寫單元測試用例代碼，測試代碼確定了需要編寫什么產品代碼。TDD基本思路就是通過測試來推動整個開發的進行，但測試驅動開發并不只是單純的測試工作，而是把需求分析、設計、質量控制量化的過程。）

6.軟件測試的發展趨勢

1）軟件測試領域的變化

軟件測試從建立到現在，經過了20多年的發展，得到了長足的進步，但與軟件開發技術相比，仍處于落后的狀態，發展速度更趕不上軟件開發技術的前進步伐，特別是在軟件產業相對落后的國家和地區。

近20年來，軟件開發得益于計算機硬件的迅速發展、計算機運算速度的提高、開發語言進展、編譯器及工具平臺的發展等因素，因此相比早期軟件的開發，無論開發速度、還是開發效率都有很大的提高。軟件開發從早期的機器語言編碼方式、匯編語言編碼方式，到跨越了結構化編程語言，進入到面向對象程序設計的時代，開發人員的編程能力和調試速度雙重受益。

對于軟件測試，雖然測試工具不斷涌現，自動化測試運用程度在不斷提高，但并沒有出現革命性的變革。軟件測試相當一部分工作仍然需要依賴手工測試。軟件測試方法和理論基本還在沿用20世紀的研究成果。最近十幾年來，軟件測試技術得到了快速發展，主要表現在：出現了眾多新的軟件測試方法和測試工具；軟件測試工具的自動化程度更高；軟件測試的組織結構、測試策略與測試技術將發生一些變化。

著名軟件專家Harry Robinson在2004年預測和認為，軟件測試領域將會發生下列一些變化：

（1）需求工程師、開發工程師將會成為軟件測試團隊成員，他們與測試人員互相幫助。

（2）測試方法日臻完善，bug預防和早期檢查將會成為測試工具的主流。

（3）通過仿真工具模擬正式環境進行測試。

（4）測試用例更新變得容易。

（5）自動化測試由機器將替代人做更多工作。

（6）測試執行和測試開發的界限將變得模糊。

（7）對測試質量的衡量將從計算缺陷數量、測試用例數量轉到需求的覆蓋、代碼的覆蓋方面。

這個預見，在2009年已經部分實現了。例如，軟件模型的研究取得了重大突破，基于模型的軟件測試工具應運而生。

2）基于模型的軟件測試技術

基于模型的軟件測試技術是針對軟件中的一些常見的軟件模型而提出的一種測試技術。

（1）軟件模型分類。

①故障模型：會引起錯誤的常見軟件模型。

②安全漏洞模型：為他人攻擊軟件提供可能。

③差性能模型：軟件動態運行時效率比較低下。

④并發故障模型：多線程編碼。

⑤不良習慣模型：由于編碼的不好習慣造成的一些錯誤。

⑥代碼國際化模型：存在于語言進行國際化的過程中。

⑦誘騙代碼模型：容易引起歧義的、迷惑人的編寫方式。

基于模型的測試機理：首先提出軟件模型，然后通過檢測算法進行檢測，如果檢測算法結果是符合質量要求的，則能夠從軟件中排除該類模型。基于模型的軟件測試工具被研制出來從而可以自動地檢測軟件中的故障，并且在對一些大型商業軟件和開源軟件的測試中發現了大量的以前測試沒有發現的軟件故障和安全隱患。

（2）基于模型的軟件測試技術的優點。

①工具自動化程度高以及測試效率高，檢測所需時間較短。

②基于模型的軟件測試技術往往能發現其他測試技術難以發現的故障。

（3）基于模型的軟件測試技術的缺點。

①誤報問題。通常基于模型的軟件測試技術都屬于靜態分析技術，由于某些故障的確定需要動態的執行信息，因此對于基于靜態分析的工具來說，誤報問題是不可避免的。

②漏報問題。漏報問題主要是由模型定義和模型檢測算法引起的。目前軟件模式沒有一個規范的、統一的和形式化的定義。

③模型多樣性。由于編程過程中，程序員具有較強的個體性，因此軟件模型是多種多樣的。

預計在軟件測試模型、測試方法和測試服務模式方面將可能是軟件測試方法研究與發展的主要內容和方向。