驗證和確認 (Verification and Validation) o 確保軟體系統符合使用者的需求
目的 o 介紹軟體的驗證(verification)與確認 (validation)，並討論它們之間的差別 o 描述程式檢查行程(program inspections process)及其在V&V中的角色 o 解釋靜態分析(static analysis)作為驗證技術的 原因 o 描述淨室(cleanroom)軟體開發行程
主題 1. 驗證和確認規劃(verification and validation planning) 2. 軟體檢查(software inspection) 3. 自動化靜態分析(automated static analysis) 4. 淨式軟體開發(cleanroom software development)
驗證與確認的比較 o 驗證(verification) n 我們是否正確建構產品(are we building the product “right”) o 軟體應與它的規格相符 o 確認(validation) n 我們是否正確建構對的產品(are we building the “right product”) o 軟體應按照使用者真正的需求執行
V&V行程 o 在一個完整的生命週期行程(life-cycle process)—V & V必須被應用在軟體發展過程 中的每個階段 o 兩個主要目的 n 發現系統中的缺失(defects) n 評估系統是否適用於運作環境(operational situation)
靜態和動態驗證 (Static and Dynamic Verification) o 軟體檢查(software inspections) n 分析靜態系統以發現問題(靜態驗證) n 可用文件和原始碼分析 具(tool-based document and code analysis)來輔助 o 軟體測試 n 執行並觀察產品的行為(動態驗證) n 以測試資料執行系統並觀察其操作行為 (operational behavior)
靜態和動態V&V
軟體測試 o 測試是實作程式的過程，在交付成品給使用 者(end user)，用以找出系統錯誤的方法
可試驗性 (Testability) o可操作性(operability) n簡潔地操作(operate cleanly) o可觀察性(observability) n很快觀察到每個測試案例的結果 o可控制性(controlability) n測試能被自動化及最佳化執行的程度
o 可分解性(decomposability) n 可鎖定目標進行測試(testing can be targeted) o 簡單性(simplicity) n 減少複雜架構和邏輯以簡化測試 o 穩定性(stability) n 在測試中，很少被要求改變 o 可理解性(understandability) n 對設計的可理解程度
程式測試 (Program Testing) o 能揭示錯誤的存在而非不存在錯誤 o 能發現一個或更多錯誤即算是成功的測試 o 是唯一對非功能性(non-functional)需求的確 認技術(validation technique) o 應與靜態驗證(static verification)同時使用， 以提供完整的V&V覆蓋範圍(coverage)
測試類型 o 缺失測試(defect testing) n 設計測試以發現系統缺失 n 成功的缺失測試是能揭露系統中存在的缺失 o 統計測試(statistical testing) n 設計測試以反應使用者輸入的頻率 n 用於可靠度評估(reliability estimation)
V& V 的目標 o 驗證(verification)與確認(validation)應建立軟 體符合其目的的信心 o 此並非意味完全沒有缺失(free of defects) o 而是表示系統必須足夠好到符合它的預期用 途(intended use)，而這些用途的類型(type of use)將決定對於需求的信心程度(degree of confidence)
V & V的信心 o 依系統目的、系統使用者期望(user expectation)和行銷環境(marketing environment)而定 n 軟體功能 o 所需的信賴層次(level of confidence)依據軟體對組織 的重要性而定 n 使用者期望 o 使用者可能對某類軟體有較低的期望 n 行銷環境 o 讓產品及早上市可能比找出程式中的缺失還重要
測試和除錯 (Testing and Debugging) o 缺失測試和除錯是不同的行程 o 驗證(verification)與確認(validation)是找出程 式中存在的缺失 o 除錯(debugging)是找出(locating)錯誤的位置 及修復(repairing)錯誤 o 除錯是先對程式行為(program behavior)建立 假設(formulating a hypothesis)，再測試這些 假設以找出系統錯誤
除錯行程 (Debugging Process)
1. V & V 的規劃 o 為有較好的測試及檢查行程需要謹慎的規劃 o 規劃應在開發過程中及早開始 o 規劃應在靜態驗證(static verification)與測試 (testing)間取得平衡 o 測試規劃是在定義測試行程用到的標準 (define standards for testing process)，而非描 述產品測試(product test)
開發的驗證模型 (V-model of Development)
軟體測試計劃架構 (The Structure of a Software Test Plan) o o o 測試行程(testing process) 需求追蹤(requirement traceability) 測試項目(tested items) 測試排程(testing schedule) 測試記錄程序(test recording procedures) 硬體與軟體需求(hardware and software requirements) o 限制(constraints)
2. 軟體檢查 (Software Inspection) o 包括人員檢視系統的原始呈現(source representation)，以用來發現異常(anomalies) 與缺失(defects) o 不需要系統的執行，所以可在程式實作前進 行 o 可應用於系統的任何呈現(representation)(如 需求、設計、測試資料等) o 是對於發現錯誤很有效(effective)的技術
成功的檢查 (Inspection Success) o 很多不同的缺失可在一次簡單的檢查 (inspection)中被發現 o 在測試時，一個缺失會遮蓋(mask)其他缺失， 故需要執行多次(several executions) o 重複使用領域(reuse domain)及程式語言的 知識(programming knowledge)可讓審查人 員(reviewers)發現常見的錯誤類型
檢查和測試 (Inspections and Testing) o 檢查與測試是互補的，而非對立的驗證技術 o 兩者在驗證與確認行程中都需使用 o 檢查可檢查是否與規格相符(conformance)， 但不能檢查是否與客戶的真正需求相符 o 檢查不能檢查非功能性的特徵，如效能 (performance)、可用性(usability)等
程式檢查 (Program Inspection) o 為文件審查(document review)的正規方法 (formalized approach) o 用來偵測缺失(detect defect)而非更正缺失 (correct defect) o 缺失可能是邏輯錯誤(logical errors)、程式碼 的異常(anomalies in the code)，錯誤的可能 情況(erroneous condition)(如未被宣告的變數 (uninitialized variable))，或是與標準不符(non -compliance with standards)
檢查前的先決條件 (Inspection Pre-condition) o 須有明確的規格(precise specification) o 團隊成員必須熟悉組織的標準(organisation standards) o 須有語法正確的程式碼(syntactically correct code) o 應準備好一份錯誤檢核清單(error checklist) o 經營者須接受檢查(inspection)會在軟體開發 行程中的初期增加成本的事實
檢查行程
檢查程序 o 向檢查團隊(inspection team)報告系統概要 (system overview) o 事先將程式碼和相關文件分給檢查團隊 o 記下檢查的過程與發現的錯誤 o 對發現的錯誤進行修改(modification) o 重新檢查(re-inspection)可能需要或不需要
檢查團隊 (Inspection Teams) o 至少由四位成員組成 o 被檢查之程式的作者(author) o 負責找出錯誤(errors)、疏忽(omissions)及不一致 (inconsistencies)的檢查者(inspector) o 向檢查團隊宣讀程式碼的宣讀者(reader) o 主持會議及記錄所發現錯誤的會議主席 (moderator) o 還可加入抄寫員(scribe)和仲裁長(chief moderator)等其他成員
檢查檢核清單 (Inspection Checklist) o 被用來檢查常見錯誤(common error)的檢核清單 (checklist)可用以主導檢查過程(drive the inspection) o 錯誤檢核清單會依程式語言而定(programming language dependent) o 型態檢查(type checking)的功能越弱，檢核清單 就越龐大 o 例如：初始化(initialization)、常數命名(constant naming)、迴圈終止(loop termination)、陣列界限 (array bounds)等
Inspection Checks
檢查速度 (Inspection Rate) o 每小時檢視(overview)約500行敘述(statement) o 在個人準備時，每小時檢視約125行敘述 (statement) o 每小時檢視 90到 125行敘述(statement) o 檢查(inspection)是成本昂貴的行程(expensive process) o 檢查 500行敘述(statement)約花費 40人時
3. 自動化靜態分析 (Automated Static Analysis) o 靜態分析程式(static analyser)是軟體 具， 用於程式原始檔處理(source text processing) o 它們剖析程式原始檔(parse the program text)， 並試著找出潛在的錯誤條件，並將它們通報 給V&V團隊注意 o 對於檢查(inspection)非常有幫助(effective)， 可輔助但不是取代檢查
靜態分析檢查 (Static Analysis Checks)
靜態分析階段 o 控制流程分析(control flow analysis) n 檢查多個離開(multiple exits)或進入點(entry points)的 迴圈(loop)、找出無法執行到的程式碼(unreachable code)等 o 資料使用分析(data use analysis) n 偵測未被初始化(uninitialized)的變數、被寫入兩次但 中間未被使用的變數(variables written twice without an intervening assignment)、宣告後未被使用的變數 o 介面分析(interface analysis) n 檢查常式(routine)和程序宣告(procedure)它們使用的 一致性
o 資訊流程分析(information flow analysis) n 找出輸出變數(output variables)的相依性 n 並非檢查本身的異常，但強調程式碼檢查或審 查的資訊 o 路徑分析(path analysis) n 找出程式中的路徑(paths through the program)， 並設定在路徑中執行的敘述(statement)，此在 檢查過程(review process)中十分有用
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_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(11) LINT printf returns value which is always ignored 的靜態分析
靜態分析的使用 o 對於鬆散的資料型別(weak typing)的語言，( 如C語言)，會有許多沒被編譯器偵測到的錯 誤，此時靜態分析就相當有用 o 對具有較強資料檢核(strong type checking)能 力(如Java)，可在編譯中偵測出許多錯誤的， 此時靜態分析就不是那麼有效(less costeffective)
4. 淨室軟體開發 (Cleanroom Software Development) o 淨室(cleanroom)這名字源自於半導體製造過 程，其理念是缺失避免(defect avoidance)，而 非缺失移除(defect removal) o 軟體開發過程基於 n 增量型開發(incremental development) n 正規規格(formal specification) n 使用正確參數(correctness argument)的靜態驗證 (static verification) n 決定程式可靠度(program reliability)的統計測試 (statistical testing)
淨室行程 (Cleanroom Process)
淨室行程的特徵 o 使用狀態轉換模型(state-transition model)的正規 規格(formal specification) o 增量型的開發(incremental development) o 結構化程式設計(structured programming) -使用 有限的控制(limited control)和抽象化結構 (abstraction construct) o 使用嚴格檢查(rigorous inspections)的靜態驗證 o 系統的統計測試(statistical testing)
增量型開發
正規規格和檢查 (Formal Specification and Inspections) o 以狀態為基礎的模型(state based model)是一 個系統規格，檢查過程是根據此模型檢核程 式(check the program against this model) o 程式設計方式(programming approach)很清楚 的定義模型與系統間的關係是否一致 (correspondence) o 使用數學論點(mathematical arguments)(不是 證明(proofs))可增加檢查過程中的信心 (confidence)
淨室行程團隊 (Cleanroom Process Teams) o 規格團隊(specification team) n 負責開發和維護系統規格 o 開發團隊(development team) n 負責開發和驗證軟體 n 在此過程中軟體不需要被執行(executed)，甚至 不需要被編譯(compiled)
o 驗證團隊(certification team) n 在軟體開發完成後，負責開發一組統計測試 (statistical test)以測試軟體 n 可靠度成長模型(reliability growth model)用來決 定可靠度何時可被接受
淨室行程評估 o 在IBM交付系統(delivered system)後很少發現 問題(faults)，這結果非常令人印象深刻 o 獨立的評價(independent assessment)顯示淨式 開發行程並不比其它方法昂貴 o 比傳統開發行程的錯誤更少
參考資料 o Ian Sommerville, Software Engineering, 7 th ed. , Addison-Wesley，2004.
Скачать презентацию 驗證和確認 Verification and Validation o 確保軟體系統符合使用者的需求 目的
12dd8a26910234913691001e5a5c976f.ppt