测试与验证.pptVIP

為什麼要做測試與驗證 軟體測試重要性（1/2） 2007 台灣高鐵售票系統上線後當機連連，系統無法應付突然湧現的購票人潮（no stress testing 2007 台灣彩卷系統：十億獎金引爆人潮，當機連連。 2000-2005 巴拿馬國家癌症中心，5個病人接受過量迦瑪射線照射死亡，15人引發嚴重併發症。 2003 軟體錯誤造成美國東北部及加拿大停電，5000萬人受影響，3人喪生。 軟體測試重要性（2/2） 2000 控制軟體問題，美國海軍飛機墜落，4人喪生。 1997 韓國空難，225人喪生（雷達控制軟體問題） 1995 美國航空在哥倫比亞撞山159人喪生（導航軟體問題） 1994 華航名古屋空難：自動駕駛軟體 Auto-Pilot 重飛模式和手操作的控制桿之昇降舵相互對抗。 軟體製造流程 概念 Idea） 需求分析與規格 Requirement analysis and specification-100% design 分析與設計 System analysis and design - QC 程式實做 Implementation- QC 製造 Manufacturing - compilation – no cost manufacturing 測試 Testing-QA 軟體測試的應用主要有以下兩種 驗證（verification）：檢驗某個階段的產品發展是否符合其早先的規範，亦即正確地建造產品。 確認（validation）：檢驗某個開發完成的系統是否符合用戶的需求，亦即建造對的產品。 迴圈複雜度與風險評估之間的關連 動態測試 14/15 資料流測試 一支程式在接受輸入資料後，會進行一連串的計算，直到輸出最後的結果。這些從輸入到輸出的一連串資料變化，即是所謂的資料流（dataflow）（亦即程式中某個資料值，從「存入」變數到取出「使用」的過程）。資料流測試就是要驗證這些資料在程式中的運算是否正確。 資料流測試也有許多準則，例如，由簡單到複雜可以分成： 定義涵蓋（all-defs）。 使用涵蓋（all-uses）。 定義－使用鏈涵蓋（all-DU-chains）。 動態測試 15/15 衡量測試的品質——突變測試 突變測試背後的想法，是創造出一定數量的突變程式，其中的每一支只有很小的改變，然後用原來的測試案例，對這些突變程式一一執行，並檢驗測試結果。 如果在測試過程中，至少存在一個測試案例，能使得某支突變程式產生不正確的結果，則這支突變程式就會被宣告死亡（dead）或被殺死（killed）。 若所有測試案例都執行過了，而某支突變程式仍然活著，就意味著原先的測試案例還不夠周延。 突變測試並不常見，儘管測試過程可以被自動化，但是它會產生數量龐大的突變程式，這使得實行上變得非常困難。 靜態測試 1/7 許多錯誤早在需求分析或設計階段時就已經產生，如果應用動態測試，則必須等到程式完成後才能執行。然而此時才發現錯誤，已經太晚且會增加許多成本。 靜態測試集合相關技能的軟體專家與顧客，透過一種名為複查（review）的會議，共同來檢查軟體開發階段所產生的各種文件。 複查的進行，從非常正式到重點式查核，可分為： 夥伴檢查法（buddy checking）。 演練（walkthrough）。 流通式複查（review by circulation）。 審查（inspection）。 靜態測試 2/7 審查法 審查的典型流程通常分為五個階段： 計畫（planning）／概述（overview）：負責開發產品的人必須準備一份產品概述文件（如規格／設計／程式碼／計畫），整理後分給每個與會人員。 準備（preparation）：成員開始瞭解文件的細節，並記錄相關疑點。 靜態測試 3/7 審查（inspection）：依據錯誤檢查表，逐項審查文件，列出找到的缺陷類型。依照重要性順序將錯誤條列記錄下來（在此，先不要修正這些錯誤，以便集中精力在發現錯誤上），最後由主持人整理成一份報告。 重新修正（rework）：解決所發現的問題與缺陷。 追蹤（follow-up）：主持人必須確定每一個問題皆已經被解決。 靜態測試 4/7 審查法的關鍵成功因素，包括下列幾項： 避免自我主義與人格特質的衝突。 議題的分離並避免偏離會議主題。 注意檢查列表的重要性。 審查小組的訓練。 管理階層的支持。 審查法的優點包括： 大量的缺陷在軟體開始測試之前就已經被發現（設計與程式碼審查）。 程式設計師的生產力愈高，花在模組測試上的時間就愈少。 靜態測試 5/7 審查過的產品被找出的缺陷較少。 缺陷在早期被發現可以節省相當大的成本。 審查法也有缺點，即無法檢查產品與顧客真正需求的一致性，也不能檢視非功能性的特徵，如效能、可用性等。 演練法 演