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