1 / 42

驗證與確認

驗證與確認. 保證軟體 系統 符合 使用者 的需求. 本章目的. 介紹軟體的驗證與確認 (V&V) ，並討論它們之間的差異 描述程式檢查 (program inspections) 程序，及其在 V&V 中擔任的角色 解釋靜態分析 (static analysis) 作為驗證技術的原因 描述淨室 (Cleanroom) 軟體開發程序. 本章內容. 驗證與確認規劃 軟體檢查 自動化靜態分析 淨室軟體開發. 驗證與確認的比較. 驗證 (Verification): " 我們是否正確的開發了產品？ " 軟體應該與規格相符

gisela-little
Download Presentation

驗證與確認

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 驗證與確認 • 保證軟體系統符合使用者的需求

  2. 本章目的 • 介紹軟體的驗證與確認(V&V)，並討論它們之間的差異 • 描述程式檢查(program inspections)程序，及其在V&V中擔任的角色 • 解釋靜態分析(static analysis)作為驗證技術的原因 • 描述淨室(Cleanroom)軟體開發程序

  3. 本章內容 • 驗證與確認規劃 • 軟體檢查 • 自動化靜態分析 • 淨室軟體開發

  4. 驗證與確認的比較 • 驗證(Verification): "我們是否正確的開發了產品？" • 軟體應該與規格相符 • 確認(Validation): "我們是否開發了對的產品？" • 軟體應該執行使用者真實的需求

  5. V&V程序 • 是一完整的生命週期程序 - V & V 必須應用在軟體發展過程中的各個段. • 有兩個主要目的 • 發現系統中的缺失(defect) • 評估在作業環境中 系統是否適用

  6. 靜態與動態驗證 • 軟體檢查(Software inspections)與分析靜態系統的表示方式來發現問題有關(靜態驗證) • 可使用文件和原始碼的分析工具來輔助 • 軟體測試(Software testing)與實作完成的軟體並檢視其輸出行為有關(動態驗證) • 提供測試資料實作系統，並檢視其操作過程是否按照預期的行為執行

  7. 靜態與動態V&V

  8. 程式測試 • 能夠揭示錯誤存在而非不存在 • 能夠發現一個或一個以上的錯誤便是成功的測試 • 這是對非功能性需求唯一的確認技術 • 應該與靜態驗證合併使用以擴大 V&V的涵蓋範圍

  9. 測試的類別 • 缺失測試 (Defect testing) • 設計測試案例找出系統缺失 . • 成功的缺失測試是能揭露出系統中的缺失. • 將在第20章中將介紹這一類測試 • 統計測試 (Statistical testing) • 設計測試案例反映使用者的輸入頻率. • 用於可靠度預估(reliability estimation). • 將在第21章中將介紹這一類測試

  10. V&V的目標 • 驗證與確認應該建立軟體系統「符合其目的」的信心 • 這不表示系統必須完全沒有錯誤 • 而是表示系統必須好到足以符合它的用途,而這些用途的類別將決定對於需求面的信心程度

  11. V&V信賴程度 • 依系統目的、系統使用者期望以及系統目前的行銷環境而定 • 軟體功能 • 所需的信賴程度根據軟體對組織的重要性而定。 • 使用者期望 • 許多使用者對他們使用的某類軟體普遍抱持較低的期望 • 行銷環境 • 讓產品及早上市可能比找出程式中的缺失還重要

  12. 測試與除錯 • 缺失測試和除錯是不同的處理程序 • 驗證與確認著重於讓程式的缺失得以浮現 • 除錯著重於找出缺失並加以改正 • 除錯需要先界定出與程式執行行為有關的假設，再分別測試這些假設以找出系統錯誤

  13. 除錯程序

  14. V&V規劃 • 謹慎地規劃才能得到更多的測試及檢查 • 規劃應在開發過程的初期開始 • 規劃工作應該在靜態驗證與測試之間取得平衡 • 測試規劃與建立測試程序的標準有關，而非著重於描述產品如何測試

  15. 開發的驗證模式

  16. 軟體測試計畫結構 • 測試程序 • 需求追蹤 • 測試項目 • 測試時程 • 測試記錄程序 • 硬體與軟體需求 • 限制

  17. 軟體檢查 • 包括人員檢視系統的原始表述，以助於發現異常與缺失 • 不需要執行系統，故可在程式實作前進行 • 可應用於系統的任何表述(如：需求規格、細部設計、測試資料、...等) • 是發現錯誤的很有效技術

  18. 檢查所以成功的原因 • 許多不同的缺失可在一次的檢查過程中被查出。在測試時，一個缺失會導致其他缺失，故需要執行多回 • 再使用應用領域及程式語言的知識，故審查人員可能會看到時常發生的錯誤類型

  19. 檢查與測試 • 檢查與測試是相輔相成而非對立的驗證技術 • 可一起在驗證與確認作業中使用 • 檢查可以檢核是否與規格相符，但不能確認是否與客戶的真正需求相符 • 檢查不可以檢核非功能性的特性，例如：執行效能、可使用性、...等

  20. 程式檢查 • 以正式的程序審查文件 • 目的明確在缺失偵測(DETECTION)而非更正 • 這些缺失可能是邏輯錯誤、程式碼中可能引發錯誤的異常行為，或是與組織或專案的標準不符

  21. 程式檢查之前的先備條件 • 一個可供檢查的明確程式碼規格 • 熟悉組織所訂標準的檢查小組的成員 • 一份語法正確的程式碼版本可用 • 先準備好一份錯誤檢核清單 • 管理者必須能接受程式檢查會增加軟體開發的期初成本 • 管理者必須不將程式檢查中的表現來考評員工

  22. 檢查程序

  23. 檢查程序 • 向檢查小組說明系統概要 • 事先將程式碼和相關規格分發給檢查小組 • 記錄下檢查時間與發現的錯誤 • 進行更新以修復發現的錯誤 • 可視需要決定是否重新檢查程式碼

  24. 檢查小組 • 至少由四個成員組成 • 被檢查之程式的設計者 • 負責尋找錯誤、疏忽及不一致的檢查者 • 向檢查小組解述程式碼內容的讀者 • 主持檢查會議及記錄所發現錯誤的仲裁者 • 還可加入書記及仲裁長等成員

  25. 檢查的檢核清單 • 建立常犯錯誤的檢核清單做為檢查的主要項目 • 錯誤檢核清單的內容會隨著程式語言的不同而有所改變 • 程式語言中有關資料型態的檢查能力越弱，檢核清單就越長 • 例如:變數初始化、常數命名、迴圈終止、陣列範圍、...等

  26. 檢查的檢核內容

  27. 檢查速率 • 在概觀階段，每小時可檢視約500行的原始程式碼 • 在個人預備階段，每小時可檢視約125行的原始程式碼 • 在開會討論階段，每小時可檢視90到125行的原始程式碼 • 因此，檢查是件成本昂貴的工作 • 檢查500行原始程式碼的成本約40人/時，等於2800英鎊

  28. 自動化靜態分析 • 靜態分析程式屬於軟體工具，用於處理程式原始檔 • 它們剖析程式原始檔，並試圖找出潛在的錯誤，將其通報給V&V小組注意 • 與程式檢查搭配使用效果最好，可輔助但非在取代程式檢查

  29. 靜態分析的檢查內容

  30. 靜態分析的階段 • 控制流程分析(Control flow analysis)找出有許多跳離或進入點的迴圈、無法被執行到的程式碼、...等 • 資料使用分析(Data use analysis)找出未初始化即被使用的變數、被指派兩次但其間未被使用的變數、宣告後未使用的變數、...等 • 介面分析(Interface analysis)檢核常式(routine)與程序(procedure)在宣告和使用時的一致性

  31. 靜態分析的階段 • 資訊流程分析(Information flow analysis)找出輸出變數的相依性。將所用到的變數值其變動過程詳盡列出，供程式碼檢查或審查時使用 • 路徑分析(Path analysis)找出程式中所有可能路徑，並列出路徑中會被執行到的敘述。基本上這在檢核的過程中是很有用的 • 資訊流程分析和路徑分析會產生非常多的資訊，要謹慎應用

  32. 138% more lint_ex.c #include <stdio.h> printarray (Anarray) int Anarray; { printf(“%d”,Anarray); } main () { int Anarray[5]; int i; char c; printarray (Anarray, i, c); printarray (Anarray) ; } 139% cc lint_ex.c 140% lint lint_ex.c lint_ex.c(10): warning: c may be used before set lint_ex.c(10): warning: i may be used before set printarray: variable # of args. lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(10) printarray, arg. 1 used inconsistently lint_ex.c(4) :: lint_ex.c(11) printf returns value which is always ignored LINT的靜態分析

  33. 靜態分析的使用 • 使用鬆散的資料型別語言(如C)時，靜態分析程式可以偵測出許多編譯程式無法找出的錯誤 • 對像Java 這類型的語言來說，編譯時會檢核所有變數類別，故可偵測出許多錯誤，使用靜態分析可能不符成本效益

  34. 淨室軟體開發 • 「淨室」 (cleanroom)這名稱是源自於半導體製造設備，其主要理念是缺失避免，而非缺失移除 • 軟體開發程序的基礎: • 增量開發(incremental development) • 正式規格(formal specification) • 始用正確參數的靜態驗證( Static verification using correctness arguments) • 決定程式可靠度的統計測試(Statistical testing to determine program reliability)

  35. 淨室程序

  36. 淨室程序的特性 • 使用狀態轉變模型(state-transition model)的正式規格 • 增量開發 • 結構化程式設計-只允許使用有限的控制敘述和抽象化結構 • 使用嚴格檢查的靜態驗證 • 系統的統計測試(將於第21章介紹這個主題).

  37. 增量開發

  38. 正式規格和檢查 • 以狀態為基礎的模型是一系統規格及檢查程序，用於檢核程式與本模型 • 程式設計的方式很清楚，以致模型與系統之間的關係是清晰的 • 使用數學論點(不是證明)可增加檢查程序中的性賴度

  39. 淨室程序小組 • 規格小組(specificationteam)負責開發及維護系統的規格 • 開發小組(development team) 負責開發及驗證軟體。但在本過程中不需要執行甚至編譯軟體 • 檢定小組(certification team) 負責開發一套統計測試案例，在軟體開發完成後執行該軟體。可靠度成長模型可用來於決定可靠度何時可被接受

  40. 淨室程序評估 • 在IBM以淨室方式開發出的交付系統較少發生故障，這結果令人難忘 • 客觀評論指出，以淨室方式開發的成本與傳統方式開發比較起來，不會太貴 • 與傳統開發程序比較起來錯誤較少 • 將淨室方法轉移到工程師技術不甚熟練，且動機不強烈的組織，仍然是個挑戰

  41. 重點整理 • 驗證與確認是不同的兩件事。驗證是在確定程式與其規格相符：確認是在確定程式是否能夠滿足客戶的需要 • 測試計畫應該作為測試程序的指引 • 靜態驗證技術包含檢查及分析程式原始碼，並且找出錯誤

  42. 重點整理 • 程式檢查對尋找程式錯誤非常有效 • 程式碼由一小組檢核，以找出軟體錯誤 • 靜態分析工具可以發現一些異常情形，有助於找出程式碼的的錯誤 • 淨室開發程序包括增量開發、靜態驗證，以及統計測試

More Related