《一个台湾的经典PPT课件（繁体字） .ppt》由会员分享，可在线阅读，更多相关《一个台湾的经典PPT课件（繁体字） .ppt（42页珍藏版）》请在三一文库上搜索。
1、驗證與確認,保證軟體系統符合使用者的需求,本章目的,介紹軟體的驗證與確認(V&V)，並討論它們之間的差異 描述程式檢查(program inspections)程序，及其在V&V中擔任的角色 解釋靜態分析(static analysis)作為驗證技術的原因 描述淨室(Cleanroom)軟體開發程序,本章內容,驗證與確認規劃 軟體檢查 自動化靜態分析 淨室軟體開發,驗證(Verification): “我們是否正確的開發了產品？“ 軟體應該與規格相符 確認(Validation): “我們是否開發了對的產品？“ 軟體應該執行使用者真實的需求,驗證與確認的比較,是一完整的生命週期程序 - V &
2、 V 必須應用在軟體發展過程中的各個段. 有兩個主要目的 發現系統中的缺失(defect) 評估在作業環境中 系統是否適用,V&V程序,軟體檢查( Software inspections) 與分析靜態系統的表示方式來發現問題有關(靜態驗證) 可使用文件和原始碼的分析工具來輔助 軟體測試( Software testing) 與實作完成的軟體並檢視其輸出行為有關(動態驗證) 提供測試資料實作系統，並檢視其操作過程是否按照預期的行為執行,靜態與動態驗證,靜態與動態V&V,能夠揭示錯誤存在而非不存在 能夠發現一個或一個以上的錯誤便是成功的測試 這是對非功能性需求唯一的確認技術 應該與靜態驗證合併使
3、用以擴大 V&V的涵蓋範圍,程式測試,缺失測試 (Defect testing) 設計測試案例找出系統缺失 . 成功的缺失測試是能揭露出系統中的缺失. 將在第20章中將介紹這一類測試 統計測試 (Statistical testing) 設計測試案例反映使用者的輸入頻率. 用於可靠度預估(reliability estimation). 將在第21章中將介紹這一類測試,測試的類別,V&V的目標,驗證與確認應該建立軟體系統符合其目的的信心 這不表示系統必須完全沒有錯誤 而是表示系統必須好到足以符合它的用途,而這些用途的類別將決定對於需求面的信心程度,V&V信賴程度,依系統目的、系統使用者期望以及
4、系統目前的行銷環境而定 軟體功能 所需的信賴程度根據軟體對組織的重要性而定。 使用者期望 許多使用者對他們使用的某類軟體普遍抱持較低的期望 行銷環境 讓產品及早上市可能比找出程式中的缺失還重要,缺失測試和除錯是不同的處理程序 驗證與確認著重於讓程式的缺失得以浮現 除錯著重於找出缺失並加以改正 除錯需要先界定出與程式執行行為有關的假設，再分別測試這些假設以找出系統錯誤,測試與除錯,除錯程序,謹慎地規劃才能得到更多的測試及檢查 規劃應在開發過程的初期開始 規劃工作應該在靜態驗證與測試之間取得平衡 測試規劃與建立測試程序的標準有關，而非著重於描述產品如何測試,V&V規劃,開發的驗證模式,軟體測試計畫
5、結構,測試程序 需求追蹤 測試項目 測試時程 測試記錄程序 硬體與軟體需求 限制,軟體檢查,包括人員檢視系統的原始表述，以助於發現異常與缺失 不需要執行系統，故可在程式實作前進行 可應用於系統的任何表述(如：需求規格、細部設計、測試資料、.等) 是發現錯誤的很有效技術,檢查所以成功的原因,許多不同的缺失可在一次的檢查過程中被查出。在測試時，一個缺失會導致其他缺失，故需要執行多回 再使用應用領域及程式語言的知識，故審查人員可能會看到時常發生的錯誤類型,檢查與測試,檢查與測試是相輔相成而非對立的驗證技術 可一起在驗證與確認作業中使用 檢查可以檢核是否與規格相符，但不能確認是否與客戶的真正需求相符
6、檢查不可以檢核非功能性的特性，例如：執行效能、可使用性、.等,程式檢查,以正式的程序審查文件 目的明確在缺失偵測(DETECTION)而非更正 這些缺失可能是邏輯錯誤、程式碼中可能引發錯誤的異常行為，或是與組織或專案的標準不符,程式檢查之前的先備條件,一個可供檢查的明確程式碼規格 熟悉組織所訂標準的檢查小組的成員 一份語法正確的程式碼版本可用 先準備好一份錯誤檢核清單 管理者必須能接受程式檢查會增加軟體開發的期初成本 管理者必須不將程式檢查中的表現來考評員工,檢查程序,檢查程序,向檢查小組說明系統概要 事先將程式碼和相關規格分發給檢查小組 記錄下檢查時間與發現的錯誤 進行更新以修復發現的錯誤
7、可視需要決定是否重新檢查程式碼,檢查小組,至少由四個成員組成 被檢查之程式的設計者 負責尋找錯誤、疏忽及不一致的檢查者 向檢查小組解述程式碼內容的讀者 主持檢查會議及記錄所發現錯誤的仲裁者 還可加入書記及仲裁長等成員,檢查的檢核清單,建立常犯錯誤的檢核清單做為檢查的主要項目 錯誤檢核清單的內容會隨著程式語言的不同而有所改變 程式語言中有關資料型態的檢查能力越弱，檢核清單就越長 例如:變數初始化、常數命名、迴圈終止、陣列範圍、.等,檢查的檢核內容,檢查速率,在概觀階段，每小時可檢視約500行的原始程式碼 在個人預備階段，每小時可檢視約125行的原始程式碼 在開會討論階段，每小時可檢視90到125
8、行的原始程式碼 因此，檢查是件成本昂貴的工作 檢查500行原始程式碼的成本約40人/時，等於 2800英鎊,自動化靜態分析,靜態分析程式屬於軟體工具，用於處理程式原始檔 它們剖析程式原始檔，並試圖找出潛在的錯誤，將其通報給V&V小組注意 與程式檢查搭配使用效果最好，可輔助但非在取代程式檢查,靜態分析的檢查內容,靜態分析的階段,控制流程分析 (Control flow analysis) 找出有許多跳離或進入點的迴圈、無法被執行到的程式碼、.等 資料使用分析 (Data use analysis) 找出未初始化即被使用的變數、被指派兩次但其間未被使用的變數、宣告後未使用的變數、.等 介面分析 (
9、Interface analysis) 檢核常式(routine)與程序(procedure)在宣告和使用時的一致性,靜態分析的階段,資訊流程分析 (Information flow analysis) 找出輸出變數的相依性。將所用到的變數值其變動過程詳盡列出，供程式碼檢查或審查時使用 路徑分析 (Path analysis) 找出程式中所有可能路徑，並列出路徑中會被執行到的敘述。基本上這在檢核的過程中是很有用的 資訊流程分析和路徑分析會產生非常多的資訊，要謹慎應用,LINT的靜態分析,138% more lint_ex.c #include printarray (Anarray) int
10、Anarray; printf(“%d”,Anarray); main () int Anarray5; 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)
11、: 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,靜態分析的使用,使用鬆散的資料型別語言(如C)時，靜態分析程式可以偵測出許多編譯程式無法找出的錯誤 對像Java 這類型的語言來說，編譯時會檢核所有變數類別，故可偵測出許多錯誤，使用靜態分析可能不符成本效益
12、,淨室 (cleanroom)這名稱是源自於半導體製造設備，其主要理念是缺失避免，而非缺失移除 軟體開發程序的基礎: 增量開發(incremental development) 正式規格(formal specification) 始用正確參數的靜態驗證( Static verification using correctness arguments) 決定程式可靠度的統計測試(Statistical testing to determine program reliability),淨室軟體開發,淨室程序,淨室程序的特性,使用狀態轉變模型(state-transition model)的正式
13、規格 增量開發 結構化程式設計-只允許使用有限的控制敘述和抽象化結構 使用嚴格檢查的靜態驗證 系統的統計測試(將於第21章介紹這個主題).,增量開發,正式規格和檢查,以狀態為基礎的模型是一系統規格及檢查程序，用於檢核程式與本模型 程式設計的方式很清楚，以致模型與系統之間的關係是清晰的 使用數學論點(不是證明)可增加檢查程序中的性賴度,規格小組(specification team) 負責開發及維護系統的規格 開發小組(development team) 負責開發及驗證軟體。但在本過程中不需要執行甚至編譯軟體 檢定小組(certification team) 負責開發一套統計測試案例，在軟體開發
14、完成後執行該軟體。可靠度成長模型可用來於決定可靠度何時可被接受,淨室程序小組,在IBM以淨室方式開發出的交付系統較少發生故障，這結果令人難忘 客觀評論指出，以淨室方式開發的成本與傳統方式開發比較起來，不會太貴 與傳統開發程序比較起來錯誤較少 將淨室方法轉移到工程師技術不甚熟練，且動機不強烈的組織，仍然是個挑戰,淨室程序評估,重點整理,驗證與確認是不同的兩件事。驗證是在確定程式與其規格相符：確認是在確定程式是否能夠滿足客戶的需要 測試計畫應該作為測試程序的指引 靜態驗證技術包含檢查及分析程式原始碼，並且找出錯誤,重點整理,程式檢查對尋找程式錯誤非常有效 程式碼由一小組檢核，以找出軟體錯誤 靜態分析工具可以發現一些異常情形，有助於找出程式碼的的錯誤 淨室開發程序包括增量開發、靜態驗證，以及統計測試,