一个台湾的经典PPT课件（繁体字）.ppt

驗證與確認 保證軟體系統符合使用者的需求 本章目的 介紹軟體的驗證與確認(VV)，並討論它們之間的差異 描述程式檢查(program inspections)程序，及其在VV中擔任的角色 解釋靜態分析(static analysis)作為驗證技術的原因 描述淨室(Cleanroom)軟體開發程序 本章內容 驗證與確認規劃 軟體檢查 自動化靜態分析 淨室軟體開發 驗證與確認的比較 驗證(Verification):  我們是否正確的開發了產品？ 軟體應該與規格相符 確認(Validation): 我們是否開發了對的產品？ 軟體應該執行使用者真實的需求 VV程序 是一完整的生命週期程序 - V V 必須應用在軟體發展過程中的各個段. 有兩個主要目的 發現系統中的缺失(defect) 評估在作業環境中 系統是否適用 靜態與動態驗證 軟體檢查( Software inspections) 與分析靜態系統的表示方式來發現問題有關(靜態驗證) 可使用文件和原始碼的分析工具來輔助 軟體測試( Software testing) 與實作完成的軟體並檢視其輸出行為有關(動態驗證) 提供測試資料實作系統，並檢視其操作過程是否按照預期的行為執行 靜態與動態VV 程式測試 能夠揭示錯誤存在而非不存在 能夠發現一個或一個以上的錯誤便是成功的測試 這是對非功能性需求唯一的確認技術 應該與靜態驗證合併使用以擴大 VV的涵蓋範圍 測試的類別 缺失測試 (Defect testing) 設計測試案例找出系統缺失 . 成功的缺失測試是能揭露出系統中的缺失. 將在第20章中將介紹這一類測試 統計測試 (Statistical testing) 設計測試案例反映使用者的輸入頻率. 用於可靠度預估(reliability estimation). 將在第21章中將介紹這一類測試 VV的目標 驗證與確認應該建立軟體系統「符合其目的」的信心 這不表示系統必須完全沒有錯誤 而是表示系統必須好到足以符合它的用途,而這些用途的類別將決定對於需求面的信心程度 VV信賴程度 依系統目的、系統使用者期望以及系統目前的行銷環境而定 軟體功能 所需的信賴程度根據軟體對組織的重要性而定。 使用者期望 許多使用者對他們使用的某類軟體普遍抱持較低的期望 行銷環境 讓產品及早上市可能比找出程式中的缺失還重要 測試與除錯 缺失測試和除錯是不同的處理程序 驗證與確認著重於讓程式的缺失得以浮現 除錯著重於找出缺失並加以改正 除錯需要先界定出與程式執行行為有關的假設，再分別測試這些假設以找出系統錯誤 除錯程序 VV規劃 謹慎地規劃才能得到更多的測試及檢查 規劃應在開發過程的初期開始 規劃工作應該在靜態驗證與測試之間取得平衡 測試規劃與建立測試程序的標準有關，而非著重於描述產品如何測試 開發的驗證模式 軟體測試計畫結構 測試程序 需求追蹤 測試項目 測試時程 測試記錄程序 硬體與軟體需求 限制 軟體檢查 包括人員檢視系統的原始表述，以助於發現異常與缺失 不需要執行系統，故可在程式實作前進行 可應用於系統的任何表述(如：需求規格、細部設計、測試資料、...等) 是發現錯誤的很有效技術 檢查所以成功的原因 許多不同的缺失可在一次的檢查過程中被查出。在測試時，一個缺失會導致其他缺失，故需要執行多回 再使用應用領域及程式語言的知識，故審查人員可能會看到時常發生的錯誤類型 檢查與測試 檢查與測試是相輔相成而非對立的驗證技術 可一起在驗證與確認作業中使用 檢查可以檢核是否與規格相符，但不能確認是否與客戶的真正需求相符 檢查不可以檢核非功能性的特性，例如：執行效能、可使用性、...等 程式檢查 以正式的程序審查文件 目的明確在缺失偵測(DETECTION)而非更正 這些缺失可能是邏輯錯誤、程式碼中可能引發錯誤的異常行為，或是與組織或專案的標準不符 程式檢查之前的先備條件 一個可供檢查的明確程式碼規格 熟悉組織所訂標準的檢查小組的成員 一份語法正確的程式碼版本可用 先準備好一份錯誤檢核清單 管理者必須能接受程式檢查會增加軟體開發的期初成本 管理者必須不將程式檢查中的表現來考評員工 檢查程序 檢查程序 向檢查小組說明系統概要 事先將程式碼和相關規格分發給檢查小組 記錄下檢查時間與發現的錯誤 進行更新以修復發現的錯誤 可視需要決定是否重新檢查程式碼 檢查小組 至少由四個成員組成 被檢查之程式的設計者 負責尋找錯誤、疏忽及不一致的檢查者 向檢查小組解述程式碼內容的讀者 主持檢查會議及記錄所發現錯誤的仲裁者 還可加入書記及仲裁長等成員 檢查的檢核清單 建立常犯錯誤的檢核清單做為檢查的主要項目 錯誤檢核清單的內容會隨著程式語言的不同而有所改變 程式語言中