軟件測試概述

第1章軟件測試概述1本章概述軟件測試的發(fā)展歷史軟件測試技術的分類方法、測試標準、測試原則軟件測試與軟件開發(fā)的關系2目錄1.1軟件測試背景

1.2軟件測試的基本理論

1.3軟件測試與軟件開發(fā)31.1軟件測試背景軟件的質量就是軟件的生命，為了保證軟件的質量，人們在長期的開發(fā)過程中積累了許多經驗并形成了許多行之有效的方法。但是借助這些方法，我們只能盡量減少軟件中的錯誤和不足，卻不能完全避免所有的錯誤。軟件測試是最有效的排除和防止軟件缺陷與故障的手段，并由此促進了軟件測試理論與技術實踐的快速發(fā)展。新的測試理論、測試方法、測試技術手段在不斷涌出，軟件測試機構和組織也在迅速產生和發(fā)展，由此軟件測試技術職業(yè)也同步完善和健全起來。41.1.1軟件缺陷

⒈軟件錯誤案例研究⑴迪斯尼的獅子王游戲軟件缺陷－⑵愛國者導彈防御系統(tǒng)缺陷－⑶千年蟲問題－⑷美國航天局火星登陸探測器缺陷－⑸金山詞霸缺陷－⑹英特爾奔騰浮點除法缺陷－51.1.1軟件缺陷⒉軟件缺陷的定義⑴對于軟件存在的各種問題可稱為軟件缺陷或軟件故障(bug)⑵計算機系統(tǒng)或者程序中存在的任何一種破壞正常運行能力的問題、錯誤，或者隱藏的功能缺陷、瑕疵⑶對于軟件缺陷的準確定義，通常有以下5條描述：①軟件未實現(xiàn)產品說明書要求的功能。②軟件出現(xiàn)了產品說明書指明不會出現(xiàn)的錯誤。③軟件超出實現(xiàn)了產品說明書提到的功能。④軟件實現(xiàn)了產品說明書雖未明確指出但應該實現(xiàn)的目標。⑤軟件難以理解，不易使用，運行緩慢或者終端用戶認為不好。6例如：計算器說明有使用。計算器的產品說明書聲稱它能夠準確無誤地進行加、減、乘、除運算。當你拿到計算器后，按下（＋）鍵，結果什么反應也沒有，這是一個缺陷。假如得到錯誤答案，這同樣是一個缺陷。若產品說明書聲稱計算器永遠不會崩潰、鎖死或者停止反應。當你任意敲鍵盤，計算器停止接受輸入，這是一個缺陷。若用計算器進行測試，發(fā)現(xiàn)除了加、減、乘、除之外它還可以求平方根，說明書中從沒提到這一功能，這是軟件缺陷。若在測試計算器時，會發(fā)現(xiàn)電池沒電會導致計算不正確，但產品說明書未指出這個問題。這是個缺陷。如“＝”鍵布置的位置使其極其不好按；或在明亮光下顯示屏難以看清。這些都是缺陷。1.1.1軟件缺陷—①軟件未實現(xiàn)產品說明書要求的功能—②軟件出現(xiàn)了產品說明書指明不會出現(xiàn)的錯誤—③軟件超出實現(xiàn)了產品說明書提到的功能—④軟件實現(xiàn)了產品說明書雖未明確指出但應該實現(xiàn)的目標—⑤軟件難以理解，不易使用，運行緩慢或者終端用戶認為不好71.1.1軟件缺陷⒊軟件缺陷的原因軟件缺陷的產生，首先是不可避免的。造成軟件缺陷的原因，歸納如下：(1)技術問題算法錯誤。語法錯誤。計算和精度問題。系統(tǒng)結構不合理，造成系統(tǒng)性能問題。接口參數不匹配出現(xiàn)問題。81.1.1軟件缺陷⒉團隊工作系統(tǒng)分析時對客戶的需求不是十分清楚，或者和用戶的溝通存在一些困難。不同階段的開發(fā)人員相互理解不一致，軟件設計對需求分析結果的理解偏差，編程人員對系統(tǒng)設計規(guī)格說明書中某些內容重視不夠，或存在著誤解。設計或編程上的一些假定或依賴性，沒有得到充分的溝通。91.1.1軟件缺陷⒊軟件本身文檔錯誤、內容不正確或拼寫錯誤。數據考慮不周全引起強度或負載問題。對邊界考慮不夠周全，漏掉某幾個邊界條件造成的錯誤。對一些實時應用系統(tǒng)，保證精確的時間同步，否則容易引起時間上不協(xié)調、不一致性帶來的問題。沒有考慮系統(tǒng)崩潰后在系統(tǒng)安全性、可靠性的隱患。硬件或系統(tǒng)軟件上存在的錯誤。軟件開發(fā)標準或過程上的錯誤。101.1.1軟件缺陷⒋軟件缺陷的組成我們知道軟件缺陷是由很多原因造成的，如果把它們按需求分析結果——規(guī)格說明書，系統(tǒng)設計結果，編程的代碼等歸類起來，比較后發(fā)現(xiàn)，結果規(guī)格說明書是軟件缺陷出現(xiàn)最多的地方，如圖1-1。111.1.1軟件缺陷軟件產品規(guī)格說明書為什么是軟件缺陷存在最多的地方，主要原因有以下幾種。用戶一般是非計算機專業(yè)人員，軟件開發(fā)人員和用戶的溝通存在較大困難，對要開發(fā)的產品功能理解不一致。由于軟件產品還沒有設計、開發(fā)、完全靠想象去描述系統(tǒng)的實現(xiàn)結果，所以有些特性還不夠清晰。需求變化的不一致性。用戶的需求總是在不斷變化的，這些變化如果沒有在產品規(guī)格說明書中得到正確的描述，容易引起前后文，上下文的矛盾。對規(guī)格說明書不夠重視，在規(guī)格說明書的設計和寫作上投入的人力，時間不足。沒有在整個開發(fā)隊伍中進行充分溝通，有時只有設計師或項目經理得到比較多的信息。121.1.1軟件缺陷⒌軟件缺陷的修復費用軟件不僅僅是表面上的那些東西——通常要靠有計劃、有條理的開發(fā)過程來實現(xiàn)。從開始到計劃、編程、測試，到公開使用的過程中，都有可能發(fā)現(xiàn)軟件缺陷。費用指數級地增長——也就是說，隨著時間的推移，費用呈十倍地增長。當早期編寫產品說明書時發(fā)現(xiàn)并修復缺陷，費用只要1美元甚至更少。同樣的缺陷如果直到軟件編寫完成開始測試時才發(fā)現(xiàn)，費用可能要10～100美元。如果是客戶發(fā)現(xiàn)的，費用可能達到數千甚至數百萬美元。131.1.2軟件測試技術的發(fā)展歷史和現(xiàn)狀⒈軟件測試技術的發(fā)展歷史隨著計算機的誕生——在軟件行業(yè)發(fā)展初期就已經開始實施軟件測試，但只有是一種類似調試的測試。20世紀50年代后期到20世紀60年代，測試的重點也逐步轉入到使用高級語言編寫的軟件系統(tǒng)中來。這一時期軟件測試的理論和方法發(fā)展比較緩慢。20世紀70年代以后，隨著軟件開發(fā)技術的成熟和完善，很多測試理論和測試方法應運而生，逐漸形成了一套完整的體系，培養(yǎng)和造就了一批批出色的測試人才。如今在整個軟件開發(fā)過程中，測試已經不再只是基于程序代碼進行的活動，而是一個基于整個軟件生命周期的質量控制活動，貫穿于軟件開發(fā)的各個階段。141.1.2軟件測試技術的發(fā)展歷史和現(xiàn)狀⒉軟件測試的現(xiàn)狀在我國，軟件測試可能算不上一個真正的產業(yè)，軟件開發(fā)企業(yè)對軟件測試認識淡薄，軟件測試人員與軟件開發(fā)人員往往比例失調，而在發(fā)達國家和地區(qū)軟件測試已經成了一個產業(yè)，微軟的開發(fā)工程師與測試工程師的比例是1：2，國內一般公司是6：1。與一些發(fā)達國家相比，國內測試工作還存在一定的差距。主要體現(xiàn)在測試意識以及測試理論的研究，大型測試工具軟件的開發(fā)以及從業(yè)人員數量等方面。但是，我們在軟件測試實現(xiàn)方面并不比國外差，國際上優(yōu)秀的測試工具，我們基本都有，這些工具所體現(xiàn)的思想我們也有深刻的理解，很多大型系統(tǒng)在國內都得到了很好的測試。151.2軟件測試的基本理論1.2.1軟件測試定義和目標⒈軟件測試的定義軟件測試是為了發(fā)現(xiàn)程序中的錯誤而執(zhí)行程序的過程。具體說，它是根據軟件開發(fā)各階段的規(guī)格說明和程序的內部結構而精心設計出一批測試用例，并利用測試用例來運行程序，以發(fā)現(xiàn)程序錯誤的過程。⒉軟件測試的目標⑴測試是程序的執(zhí)行過程，目的在于發(fā)現(xiàn)錯誤，不能證明程序的正確性，僅限于處理有限種的情況。⑵檢查系統(tǒng)是否滿足需求，這也是測試的期望目標。⑶一個好的測試用例在于發(fā)現(xiàn)還未曾發(fā)現(xiàn)的錯誤；成功的測試是發(fā)現(xiàn)了錯誤的測試。161.2.2軟件測試標準⒈軟件測試的目標在于揭示錯誤。測試人員要始終站在用戶的角度去看問題，系統(tǒng)中最嚴重的錯誤的是那些導致程序無法滿足用戶需求的錯誤。⒉軟件測試必須基于“質量第一”的思想去開展各項工作。⒊事先定義好產品的質量標準。只有建立了質量標準，才能根據測試的結果，對產品的質量進行分析和評估。⒋軟件項目一啟動，軟件測試也就開始，而不是等程序寫完，才開始進行測試。⒌測試用例是設計出來的，不是寫出來的，所以要根據測試的目的，采用相應的方法去設計測試用例，從而提高測試的效率，更多的發(fā)現(xiàn)錯誤，提高程序的可靠性。⒍對發(fā)現(xiàn)錯誤較多的程序段，應進行更深入的測試。171.2.3軟件測試原則－1⒈應當把盡早地和不斷地進行軟件測試作為軟件開發(fā)者的座右銘。堅持在軟件開發(fā)的各個階段的技術評審，這樣才能在開發(fā)過程中盡早發(fā)現(xiàn)和預防錯誤，把出現(xiàn)的錯誤克服在早期，杜絕某些隱患，提高軟件質量。⒉測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。如果對測試輸入數據沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。⒊程序員應避免檢查自己的程序。如果由別人來測試程序員編寫的程序，可能會更客觀，更有效，并更容易取得成功。⒋在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。181.2.3軟件測試原則－2⒌充分注意測試中的群集現(xiàn)象。測試時不要以為找到了幾個錯誤問題就已解決，不需繼續(xù)測試了。應當對錯誤群集的程序段進行重點測試，以提高測試投資的效益。⒍嚴格執(zhí)行測試計劃，排除測試的隨意性。對于測試計劃，要明確規(guī)定，不要隨意解釋。⒎應當對每一個測試結果做全面檢查。這是一條最明顯的原則，但常常被忽視。必須對預期的輸出結果明確定義，對實測的結果仔細分析檢查，抓住關鍵，暴露錯誤。⒏妥善保存測試計劃，測試用例，出錯統(tǒng)計和最終分析報告，為維護提供方便。191.2.4軟件測試分類－1⒈從是否需要執(zhí)行被測軟件的角度分類靜態(tài)測試（StaticTesting）和動態(tài)測試(DynamicTesting)靜態(tài)測試就是通過對被測程序的靜態(tài)審查，發(fā)現(xiàn)代碼中潛在的錯誤。它一般用人工方式脫機完成，故亦稱人工測試或代碼評審（CodeReview）;也可借助于靜態(tài)分析器在機器上以自動方式進行檢查，但不要求程序本身在機器上運行。按照評審的不同組織形式，代碼評審又可分為代碼會審，走查以及辦公桌檢查，同行評分4種。對某個具體的程序，通常只使用一種評審方式。動態(tài)測試：動態(tài)測試的對象必須是能夠由計算機真正運行的被測試的程序。它分為黑盒測試和白盒測試，也是我們下面將要介紹的內容。20靜態(tài)測試－1靜態(tài)方法的主要特征是在用計算機測試源程序時，計算機并不真正運行被測試的程序，只對被測試程序進行特性分析。靜態(tài)測試包括代碼檢查、靜態(tài)結構分析、代碼質量度量等。靜態(tài)測試可以完成的工作如下：(1)可以發(fā)現(xiàn)如下的程序缺陷：錯用了局部變量和全局變量；不匹配的參數；未定義的變量；不適當的循環(huán)嵌套或分支嵌套；無終止的死循環(huán)；不允許的遞歸；調用不存在的子程序；遺漏了標號或代碼。21靜態(tài)測試－2(2)找出如下問題的根源：未使用過的變量；不會執(zhí)行到的代碼；從未引用過的標號；潛在的死循環(huán)。(3)提供程序缺陷的如下間接信息：標識符的使用方式；過程的調用層次；所用變量和常量的交叉應用表；是否違背編碼規(guī)則。(4)為進一步查錯做準備。(5)選擇測試用例。實踐表明：靜態(tài)測試可發(fā)現(xiàn)大約1/3－2/3的邏輯設計和編碼錯誤。22動態(tài)測試動態(tài)測試是真正運行被測程序，在執(zhí)行過程中，通過輸入有效的測試用例，對其輸入與輸出的對應關系進行分析，以達到檢測的目的。動態(tài)測試方法的基本步驟：⑴選取定義域有效值，或定義域外無效值；⑵對已選取值決定預期的結果；⑶用選取值執(zhí)行程序；⑷執(zhí)行結果與預期的結果相比，不吻合程序有錯。231.2.4軟件測試分類－2⒉從軟件測試用例設計方法的角度分類黑盒測試（Black-BoxTesting）和白盒測試（White-BoxTesting）24黑盒測試黑盒測試（Black-boxTesting）又稱為功能測試、數據驅動測試和基于規(guī)格說明的測試。是一種從用戶觀點出發(fā)的測試。黑盒測試的基本觀點是：任何程序都可以看作是從輸入定義域映射到輸出值域的函數過程，被測程序被認為是一個打不開的黑盒子，黑盒中的內容（實現(xiàn)過程）完全不知道，只明確要做到什么。黑盒測試作為軟件功能的測試手段，是重要的測試方法。它主要根據規(guī)格說明設計測試用例，并不涉及程序內部結構和內部特性，只依靠被測程序輸入和輸出之間的關系或程序的功能設計測試用例。黑盒測試的具體技術方法主要包括：邊界值分析法、等價類劃分法、比較測試法、決策表法、因果圖法等。25白盒測試白盒測試（White-boxTesting）也稱作結構測試或邏輯驅動測試，它是知道產品內部工作過程，可通過測試來檢測產品內部動作是否按照規(guī)格說明書的規(guī)定正常進行。按照程序內部的結構測試程序，檢驗程序中的每條通路是否都有能按預定要求正確工作，而不顧它的功能。白盒測試的主要方法有：邏輯覆蓋、基本路徑測試等，主要用于軟件驗證。通常的程序邏輯覆蓋有：語句覆蓋；判斷覆蓋；條件覆蓋；判斷/條件覆蓋；條件組合覆蓋；路徑覆蓋。26黑盒測試與白盒測試黑盒測試白盒測試優(yōu)點①適用于各個測試階段；②從產品功能角度進行測試；③容易入手生成測試數據。①可構成測試數據使特定程序部分得到測試；②有一定充分性度量手段；③可獲較多工具支持。缺點①某些代碼得不到測試；②如果規(guī)則說明有誤，無法發(fā)現(xiàn)；③不易進行充分行測試。①不易生成測試數據；②無法對未實現(xiàn)規(guī)格說明的部分進行測試；③工作量大，通常只用于單元測試，有應用局限性。性質一種確認技術，目的是確認“設計的系統(tǒng)是否正確”。一種驗證技術，目的是驗證“系統(tǒng)的設計是否正確”。271.2.4軟件測試分類－3⒊從軟件測試的策略和過程的角度分類單元測試（UnitTesting），集成測試（IntegrationTesting）,確認測試（ValidationTesting）,系統(tǒng)測試（SystemTesting）和驗收測試（VerificationTesting）單元測試是針對每個單元的測試，是軟件測試的最小單位。它確保每個模塊能正常工作。單元測試多數使用白盒測試，用以發(fā)現(xiàn)內部錯誤。集成測試是對已測試過的模塊進行組裝，進行集成測試的目的主要在于檢驗與軟件設計相關的程序結構問題。集成測試一般通過黑盒測試方法來完成。確認測試是檢驗所開發(fā)的軟件能否滿足所有功能和性能需求的最后手段，通常采用黑盒測試方法。系統(tǒng)測試的主要任務是檢測被測軟件與系統(tǒng)的其他部分的協(xié)調性。驗收測試是軟件產品質量的最后一關。這一環(huán)節(jié)，測試主要從用戶的角度著手，其參與者主要是用戶和少量的程序開發(fā)人員。281.3軟件測試與軟件開發(fā)⒈測試與軟件開發(fā)各階段的關系軟件開發(fā)過程是一個自頂向下，逐步細化的過程，首先在軟件計劃階段定義了軟件的作用域，然后進行軟件需求分析，建立軟件的數據域、功能和性能需求、約束和一些有效性準則。接著進入軟件開發(fā)，首先是軟件設計，然后再把設計用某種程序設計語言轉換成程序代碼。測試過程則是依相反的順序安排的自底向上，逐步集成的過程，低一級測試為上一級測試準備條件。291.3軟件測試與軟件開發(fā)⒉測試與開發(fā)模型軟件測試不僅僅是執(zhí)行測試，而是一個包含很多復雜活動的過程，并且這些過程應該貫穿于整個軟件開發(fā)過程。在軟件開發(fā)過程中，應該什么時候進行測試，如何更好地把軟件開發(fā)和測試活動集成到一起？其實這也是軟件測試工作人員必須考慮的問題，因為只有這樣，才能提高軟件測試工作的效率，提高軟件產品的質量，最大限度地降低軟件開發(fā)與測試的成本，減少重復勞動。如圖1-4所示，即為軟件測試與開發(fā)的完整流程。30小結本章從軟件缺陷實例為出發(fā)點介紹了軟件測試背景和測試發(fā)展的歷程，以及它在國內的發(fā)展狀況。隨著軟件開發(fā)過程和開發(fā)技術的不斷改進，軟件測試理論和方法也在不斷完善，測試工具也在蓬勃發(fā)展。軟件測試是軟件質量保證的手段，本章講述了軟件測試的定義，并以最少的時間和人力找出軟件中潛在的各種錯誤和缺陷作為測試目標，闡述了軟件測試執(zhí)行的標準和軟件測試的原則。從不同角度，對軟件測試進行了分類：從是否需要執(zhí)行被測軟件的角度可分為靜態(tài)測試和動態(tài)測試；從軟件測試用例設計方法的角度可分為黑盒測試和白盒測試；從軟件測試的策略和過程的角度又可分為單元測試、集成測試、確認測試、系統(tǒng)測試、驗收測試。最后介紹了軟件開發(fā)與軟件測試的相輔相成的關系。31⑴迪斯尼的獅子王游戲軟件缺陷1994年秋天，迪斯尼公司發(fā)布了第一個面向兒童的多媒體光盤游戲——獅子王動畫故事書（TheLionKingAnimatedStorybook）。盡管已經有許多其他公司在兒童游戲市場上運作多年，但是這次是迪斯尼公司首次進軍這個市場，所以進行了大量促銷宣傳。結果，銷售額非?？捎^，該游戲成為孩子們那年節(jié)假日的“必買游戲”。然而后來卻飛來橫禍。12月26日，圣誕節(jié)的后一天，迪斯尼公司的客戶支持電話開始響個不停。很快，電話支持技術員們就淹沒在來自于憤怒的家長并伴隨著玩不成游戲的孩子們哭叫的電話之中。報紙和電視新聞進行了大量的報道。后來證實，迪斯尼公司未能對市面上投入使用的許多不同類型的PC機型進行廣泛的測試。軟件在極少數系統(tǒng)中工作正?！?例如在迪斯尼程序員用來開發(fā)游戲的系統(tǒng)中——但在大多數公眾使用的系統(tǒng)中卻不能運行。32⑵愛國者導彈防御系統(tǒng)缺陷愛國者導彈防御系統(tǒng)是里根總統(tǒng)提出的戰(zhàn)略防御計劃（即星球大戰(zhàn)計劃）的縮略版本，它首次應用在海灣戰(zhàn)爭中對抗伊拉克飛毛腿導彈的防御戰(zhàn)中。盡管對系統(tǒng)贊譽的報道不絕于耳，但是它確實在對抗幾枚導彈中失利，包括一次在沙特阿拉伯的多哈擊斃了28名美國士兵。分析發(fā)現(xiàn)癥結在于一個軟件缺陷，系統(tǒng)時鐘的一個很小的計時錯誤積累起來到14小時后，跟蹤系統(tǒng)不再準確。在多哈的這次襲擊中，系統(tǒng)已經運行了100多個小時。33⑶千年蟲問題20世紀70年代早期的某個時間，某位程序員正在為本公司設計開發(fā)工資系統(tǒng)。他使用的計算機存儲空間很小，迫使他盡量節(jié)省每一個字節(jié)。他將自己的程序壓縮得比其他任何人都緊湊。使用的其中一個方法是把4位數年份，例如1973年，縮減為2位數，73。因為工資系統(tǒng)相當信賴于日期的處理，所以需要節(jié)省大量的存儲空間。他簡單的認為只有在到達2000年，那時他的程序開始計算00或01這樣的年份時問題才會產生。雖然他知道會出這樣的問題，但是他認定在25年之內程序肯定會升級或替換，而且眼前的任務比現(xiàn)在計劃遙不可及的未來更加重要。然而這一天畢竟到來了。1995年他的程序仍然在使用，而他退休了，誰也不會想到如何深入到程序中檢查2000年兼容問題，更不用說去修改了。估計全球各地更換或升級類似的前者程序以解決潛在的2000問題的費用已經達數千億美元。34⑷美國航天局火星登陸探測器缺陷1999年12月3日，美國航天局的火星極地登陸者號探測器試圖在火星表面著陸時失蹤。一個故障評估委員會調查了故障，認定出現(xiàn)故障的原因極可能是一個數據位被意外置位。最令人警醒的問題是為什么沒有在內部測試時發(fā)現(xiàn)呢。從理論上看，著陸的計劃是這樣的：當探測器向火星表面降落時，它將打開降落傘減緩探測器的下降速度。降落傘打開幾秒鐘后，探測器的三條腿將迅速撐開，并鎖定位置，準備著陸。當探測器離地面1800米時，它將丟棄降落傘，點燃著陸推進器，緩緩地降落到地面。美國航天局為了省錢，簡化了確定何時關閉著陸推進器的裝置。為了替代其他太空船上使用的貴重雷達，他們在探測器的腳部裝了一個廉價的觸點開關，在計算機中設置一個數據位來控制觸點開關關閉燃料。很簡單，探測器的發(fā)動機需要一直點火工作，直到腳“著地”為止。遺憾的是，故障評估委員會在測試中發(fā)現(xiàn)，許多情況下，當探測器的腳迅速撐開準備著陸時，機械震動也會觸發(fā)著陸觸點開關，設置致命的錯誤數據位。設想探測器開始著陸時，計算機極有可能關閉著陸推進器，這樣火星極地登陸者號探測器飛船下墜1800米之后沖向地面，撞成碎片。結果是災難性的，但背后的原因卻很簡單。登陸探測器經過了多個小組測試。其中一個小組測試飛船的腳折疊過程，另一個小組測試此后的著陸過程。前一個小組不去注意著地數據是否置位——這不是他們負責的范圍；后一個小組總是在開始復位之前復位計算機，清除數據位。雙方獨立工作都做得很好，但合在一起就