第8章 测试与验证.ppt

1、第8章 測試與驗證,為什麼要做測試與驗證,軟體測試重要性（1/2）,2007 台灣高鐵售票系統上線後當機，系統無法應付突然湧現的購票人潮（no stress testing) 2007 台灣彩卷系統：十億獎金引爆人潮，當機。 2000-2005 巴拿馬國家癌症中心，5個病人接受過迦瑪射線照射死亡，15人引發嚴重併發症。 2003 軟體錯誤造成美國東部及加拿大停電，5000萬人受影響，3人喪生。,軟體測試重要性（2/2）,2000 控制軟體問題，美國海軍飛機墜，4人喪生。 1997 韓國空難，225人喪生（達控制軟體問題） 1995 美國航空在哥比亞撞山159人喪生（導航軟體問題） 1994 華

2、航名古屋空難：自動駕駛軟體(Auto-Pilot)重飛模式和手操作的控制桿之昇降舵相互對抗。,軟體製造流程,概(Idea） 需求分析與規格 (Requirement analysis and specification-100% design) 分析與設計(System analysis and design - QC) 程式實做(Implementation- QC) 製造(Manufacturing - compilation no cost manufacturing) 測試(Testing-QA),軟體測試(1/4),軟體測試有關的名詞 錯誤（error）：錯誤是人所造成的。它的另一個

3、同義詞是失誤（mistake）。人們在撰寫程式時，經常由於思慮不周或不小心，而發生錯誤。 缺陷（fault）：缺陷是錯誤的結果。更準確地說，缺陷是錯誤的外顯，存在於表達之中，瑕疵（defect）是它的同義詞，臭蟲也是。 故障（failure）：當程式執行到缺陷的位置時，故障才會發生。不是所有的缺陷都會表現出故障的行為，故障只發生在可執行的程式碼中。,軟體測試(2/4),事件（incident）：不是所有的故障都有明顯的症狀或可一眼看出。事件是故障所產生的症狀，讓用戶警覺到故障的發生。 測試案例（test case）：每個測試案例都有一個代號與測試目的（說明其程式應有的行為）。 兩者間的關係如圖

4、所示。,驗證與確認之間的關係,軟體測試的應用主要有以下兩種,驗證（verification）：檢驗某個階段的產品發展是否符合其早先的規範，亦即正確地建造產品。 確認（validation）：檢驗某個開發完成的系統是否符合用戶的需求，亦即建造對的產品。,軟體測試(3/4),測試方法的分類 測試對象 黑箱測試（black-box testing）：又稱為功能測試。 白箱測試（white-box testing）：又稱為結構測試。 測試工具 動態測試（dynamic test） 靜態測試（static test）,軟體測試(4/4),測試層級 單元測試（unit test） 整合測試（integra

5、tion test） 系統測試（system test）,動態測試(1/15),外部測試 從外部測試，意味著將軟體系統當作黑箱加以測試，以確認它是否符合系統當初的要求。 黑箱測試主要針對以下類型的缺陷： 功能不對或遺漏。 有瑕疵的程式介面。 資料結構或外部資料存取的缺陷。 初始化和終止條件錯誤等各類型可由行為觀察到的缺陷。 重點在於驗證系統的功能（參考下圖），所以有時又稱為功能測試。,外部測試的資料選取範圍,動態測試(2/15),功能測試的策略： 等類分割（equivalence partition） 其基本假設是程式的輸入值，可被分成若干個等類集合，而每個等類集合所導致的系統行為表現相似。因

6、此，每個集合只需選取一個代表案例來測試，即等同於測試整個集合。,等類分割示意圖,動態測試(3/15),邊界值分析（boundary value analysis） 邊界值分析要求測試案例必須落在等類集合的邊界，所以是一種改善等類分割的測試方法。 不僅注重輸入條件，也要求必須從輸出條件中導出測試案例。,動態測試(4/15),因果圖（cause-effect graph） 因果圖是一種網狀式的邏輯組合圖。其中節點代表物件（或概念），以圓形表示；節點之間的連結，代表物件間的因果關係，以連線表示。連結與連結之間，可以定義邏輯關係，如圖所示。,因果圖表示法,動態測試(5/15),因果圖從需求規範而來，建

7、立方法如下步驟： 研讀系統之功能規範。 標記並編號所有的原因與結果。 將被編號的原因與結果繪製成圖上的結點；原因繪製在左手邊，結果繪製在右手邊。 繪製原因和結果之間的邏輯關係，用適當的連結將相關的節點連接起來。 若有需要，可增加額外的中間結點，來簡化圖的描述。,動態測試(6/15),決策表（decision table） 決策表（如表的範例）係以行的形式描述決策規則，其中條件欄描述各種輸入情況，而作用欄列出系統應執行的活動。 決策表的優點，是可以清楚地將系統的行為以條列方式表達，每一條規則說明了條件與動作（或作用）之間的關係，因此，從測試的角度來看，它是很好的測試案例指引；一條規則至少應指派一

8、個或一個以上的測試個案。 決策表範例，如表所示。,決策表範例,動態測試(7/15),內部測試 內部測試的意涵，是將程式打開深入檢查其內部結構，並藉由程式的執行結果，察看它是否滿足原始功能設計的要求。 對於測試者而言，由於程式的各部分細節可被察看並一覽無遺，因此，我們稱之為白箱測試。 白箱測試並沒有特定的缺陷對象要偵測。其基本精神是要確認程式的每一部分都符合預期，且可以被正確地執行。為了達到這個目的，它會是針對受測軟體內部的路徑、結構和實施細節來設計測試個案。,內部測試之資料選取範圍,動態測試(8/15),白箱測試流程如下： 分析受測軟體（SUT）的程式結構，辨認出其中的敘述（statement

9、s）、分支（branches）、條件（conditions）以及路徑。 根據事先定義之測試準則，產生能讓SUT執行所選取路徑的測試個案，以及期望的結果。 進行測試。 比較實際輸出與期望的輸出。 判斷SUT是否在該測試發揮適當的作用。,動態測試(9/15),控制流測試 敘述涵蓋（statement coverage） 敘述涵蓋的準則，是產生足夠的測試案例，以便程式中的每個敘述，至少能被執行一次。 其基本想法，是除非每個敘述被有效地執行，否則我們無法知道，是否哪一項敘述裡隱藏著缺陷。 敘述涵蓋的缺點是不夠周延。 分支涵蓋（branch coverage） 分支涵蓋的準則，是程式中的每個分支敘述，至

10、少能被一個測試個案執行過。 基本邏輯是除非每個程式的分支都被有效地執行，否則無法判斷是否有缺陷隱藏在某個分支裡。,動態測試(10/15),條件涵蓋（condition coverage） 條件涵蓋是分支涵蓋的延伸。由於分支涵蓋只要求到各分支被執行，而並未考慮到分支的每一個條件是否都被驗證過，因此，就測試的角度來說，還是可能有隱藏的缺陷沒有被偵測到。所以條件涵蓋進一步要求每一個布林運算式中個別的條件，都必須被測試過一次。,動態測試(11/15),路徑涵蓋（path coverage） 雖然條件涵蓋考慮了各種條件的組合，但是範圍僅限於一個分支，並不包含多個分支的組合測試。從測試的角度來看，這樣仍有

11、所不足（如圖）。 要涵蓋程式所有的路徑，在實務上並不可行；折衷的辦法是選取獨立路徑，或依照迴圈複雜度（cyclomatic complexity）的要求加以測試。,分支涵蓋的問題,動態測試(12/15),獨立路徑測試（independence path） 獨立路徑是一條貫穿程式的路徑，其中至少包含一個不含在其它獨立路徑中的新結點。 獨立路徑測試是指程式中所有線性獨立的路徑，都至少被一個測試案例執行過。 迴圈複雜度可用來計算一個程式中獨立路徑的數目。 迴圈複雜度可以當作分支涵蓋的測試案例數量下限。 參閱圖。,圖 迴圈複雜度與分支測試,動態測試(13/15),迴圈複雜度與風險 根據軟體工程學院（S

12、EI）的網站所公布的建議，迴圈複雜度與風險評估之間的關連大致可整理如下圖所示。 迴圈複雜度的限制 迴圈複雜度所衡量的，是控制流的複雜性，而不是資料的複雜性。此外，對於同樣數量的巢狀和非巢狀迴圈，雖然得到同樣的複雜度，但是深層的巢狀結構比非巢狀結構更難以理解。,迴圈複雜度與風險評估之間的關連,動態測試(14/15),資料流測試 一支程式在接受輸入資料後，會進行一連串的計算，直到輸出最後的結果。這些從輸入到輸出的一連串資料變化，即是所謂的資料流（dataflow）（亦即程式中某個資料值，從存入變數到取出使用的過程）。資料流測試就是要驗證這些資料在程式中的運算是否正確。 資料流測試也有許多準則，例如

13、，由簡單到複雜可以分成： 定義涵蓋（all-defs）。 使用涵蓋（all-uses）。 定義使用鏈涵蓋（all-DU-chains）。,動態測試(15/15),衡量測試的品質突變測試 突變測試背後的想法，是創造出一定數量的突變程式，其中的每一支只有很小的改變，然後用原來的測試案例，對這些突變程式一一執行，並檢驗測試結果。 如果在測試過程中，至少存在一個測試案例，能使得某支突變程式產生不正確的結果，則這支突變程式就會被宣告死亡（dead）或被殺死（killed）。 若所有測試案例都執行過了，而某支突變程式仍然活著，就意味著原先的測試案例還不夠周延。 突變測試並不常見，儘管測試過程可以被自動化，

14、但是它會產生數量龐大的突變程式，這使得實行上變得非常困難。,靜態測試(1/7),許多錯誤早在需求分析或設計階段時就已經產生，如果應用動態測試，則必須等到程式完成後才能執行。然而此時才發現錯誤，已經太晚且會增加許多成本。 靜態測試集合相關技能的軟體專家與顧客，透過一種名為複查（review）的會議，共同來檢查軟體開發階段所產生的各種文件。 複查的進行，從非常正式到重點式查核，可分為： 夥伴檢查法（buddy checking）。 演練（walkthrough）。 流通式複查（review by circulation）。 審查（inspection）。,靜態測試(2/7),審查法 審查的典型流程

15、通常分為五個階段： 計畫（planning）概述（overview）：負責開發產品的人必須準備一份產品概述文件（如規格設計程式碼計畫），整理後分給每個與會人員。 準備（preparation）：成員開始瞭解文件的細節，並記錄相關疑點。,靜態測試(3/7),審查（inspection）：依據錯誤檢查表，逐項審查文件，列出找到的缺陷類型。依照重要性順序將錯誤條列記錄下來（在此，先不要修正這些錯誤，以便集中精力在發現錯誤上），最後由主持人整理成一份報告。 重新修正（rework）：解決所發現的問題與缺陷。 追蹤（follow-up）：主持人必須確定每一個問題皆已經被解決。,靜態測試(4/7),審查法

16、的關鍵成功因素，包括下列幾項： 避免自我主義與人格特質的衝突。 議題的分離並避免偏離會議主題。 注意檢查列表的重要性。 審查小組的訓練。 管理階層的支持。 審查法的優點包括： 大量的缺陷在軟體開始測試之前就已經被發現（設計與程式碼審查）。 程式設計師的生產力愈高，花在模組測試上的時間就愈少。,靜態測試(5/7),審查過的產品被找出的缺陷較少。 缺陷在早期被發現可以節省相當大的成本。 審查法也有缺點，即無法檢查產品與顧客真正需求的一致性，也不能檢視非功能性的特徵，如效能、可用性等。 演練法 演練是一種模擬測試的方法，藉由一組選定的任務（或測試案例），演練在該產品（或文件）執行時的情形，以驗證並評

17、估其功能。所以演練法通常會有軟體品管人員參與會議。會議中也可以討論有關缺陷的修正、軟體的架構等問題。,靜態測試(6/7),演練法雖然無標準的進行形式（如下圖），但是至少應在與會前，先將演練所需材料事先發布下去。內容應包含： 使用者描述：包括用戶對電腦的使用經驗，以及任何系統設計者所做的假設。 系統描述：包括系統的操作，以及效能的描述。 任務描述：從使用者的觀點所完成的任務。 動作順序描述：系統所呈現的畫面，以及要完成某任務所需進行的動作。,表8.4 審查法與演練法的比較,靜態測試(7/7),自動化分析 靜態測試除了利用專家同儕的複核之外，亦可利用自動化工具來協助進行分析。 靜態分析器（stat

18、ic analyzer）就是這樣的工具，可用於分析原始程式碼，透過解析程式的內容，找出可能發生、潛在的錯誤情境，以提醒品管人員或工程師注意。,測試的實施(1/12),軟體測試計畫 測試計畫可以是另外一份獨立的文件（如圖），也可以在專案計畫書中，增加一個章節加以說明（何者較佳，取決於測試的工作量與複雜度）。 軟體測試是一個需要正視的議題。根據一般報告，在軟體專案中，測試所消耗的資源，並不少於軟體開發所用的。唯有適當地計劃，才能讓軟體測試有限的資源，發揮最大的效益。,圖 ANSI/IEEE 829-1983軟體測試文件大綱,測試的實施(2/12),一份測試計畫或者測試文件集，應該包含以下項目： 資

19、源分配計畫，明確指出任務的分類、概略的人力與資源的分配。 測試平台描述，包括軟硬體環境，以及構成測試平台所有相關項目。 測試個案（個別測試）或者測試組套（相關測試案例的集合）的高階設計。 詳細的測試案例描述清單。 描述受測軟體與其它需要互動的應用程式間之關係。 任何其它關於發展與執行測試有關的事項。,測試的實施(3/12),測試計畫書可分為三種： 單一測試計畫書（Single Test Plan, STP） 主測試計畫書（Master Test Plan, MTP） 詳細測試計畫書（Detail Test Plan, DTP） 測試與開發活動之間的關係為何？流程要如何安排？下圖可以說明軟體測試

20、與軟體開發之間的關係，就是所謂的V模型。本圖的用意是要顯示不同階段的開發活動所對應的測試項目，如此測試計畫就可以和軟體開發計畫順利地整合在一起。,圖 軟體測試的V模型,測試的實施(4/12),單元測試 單元測試的目的，就在於及早發現錯誤，將後者所造成的缺陷侷限在一個小範圍裡，透過測試加以去除。如此可以節省除錯的精力，避免在整合後的大系統中尋找某個模組內的微小缺陷。 單元測試的對象，是軟體系統中最基本的單元，通常稱作模組（對應到物件導向程式裡的方法或函數）。其目的是驗證模組的邏輯功能、內部程式碼結構，以及邊界條件等，是否與規格或設計所預期的一致（如圖）。,單元測試示意圖,測試的實施(5/12),

21、整合測試 整合測試又稱為組裝或集成測試，是單元測試的擴大與延伸。最簡單的形式，是將兩個經過測試的單元（或模組）組合起來，測試它們之間的介面通訊，以驗證其相容性與運算正確性。 其目的是找出因為介面錯誤，或誤用介面所造成的缺陷。這對於今日普遍使用的對物件導向開發尤其重要，因為物件的方法是根據介面來定義的。,測試的實施(6/12),至於如何整合的問題，可能的選擇有： 由上向下整合測試（top-down integration testing）：從高位階的系統元件開始，逐層向下整合，直到整個系統被包含進來。（如圖） 優點是可以確認架構的有效性，有助於提早發現架構上的缺陷。其次是系統展示，在系統開發早期

22、就可以做有限度的系統展示，及早獲得用戶的回饋。此外，測試核心的程式碼經過不斷地測試，可以增進系統的可靠性。 缺點是成本較高，殘根程式碼是額外的程式，要另外撰寫可能相當困難而且費功夫，測試執行亦較為費時，並且很難獲得適當的輸入資料。,由上向下整合測試,測試的實施(7/12),由下向上整合測試（bottom-up integration testing）：從已完成的低階模組或元件，逐層向上整合，直到整個系統被包含進來。 由下向上整合測試的優缺點，剛好與由上向下整合的方法相反。就實作而言，前者較容易實施，但是其缺點是要等到整合的後期，才可能看到系統展示，此時若發現功能上的瑕疵，或用戶的回饋不如預期，

23、將會對專案造成很大的困擾。,測試的實施(8/12),混合測試法：如三明治測試（sandwich testing）、核心測試法與脈絡測試法（thread testing）等。 三明治法係結合以上兩種測試策略，從頂層與底層模組向中間整合。 核心測試法係從系統中間向兩端發展，先對核心元件進行整成測試，再依照重要性將外圍元件逐個加入到核心系統中。 脈絡測試則是依照軟體執行的脈絡，以一串模組為單位加以測試。,測試的實施(9/12),一次全部整合一起測試。 若是小型系統，實務上也有可能採用大霹靂的辦法，跳過整合測試的步驟，等到所有元件完成後，一次整合起來進行測試。 高階測試（high order testing） 是指針對完工後的系統進行測試，最主要的有兩種： 系統測試（或稱為Alpha測試（Alpha test） 是發展者在開發環境中，針對即將交付的系統所做的最後測試。,測試的實施(10/12),系統測試的主要內容包括： 功能測試：測試系統的功能是否正確，主要依據是需求規範，如產品需求規格書。 強健性測試（robust test）：測試系統在異常情況下能否正常運行的能力，其中有兩層含意：一是容錯能力，二是恢復能力。 效能測試（performance test）：測試系