檢驗和有效性驗證課件

檢驗和有效性驗證確保一個軟件系統(tǒng)滿足用戶的需求目標(biāo)軟件檢驗和軟件有效性驗證之間的區(qū)別在程序中發(fā)現(xiàn)缺陷的程序檢查過程及其在檢驗和有效性驗證中的作用靜態(tài)分析方法作為一種檢驗技術(shù)凈室軟件開發(fā)方法內(nèi)容檢驗和有效性驗證規(guī)劃軟件檢查自動靜態(tài)分析凈室軟件開發(fā)方法檢驗:

“我們是否在正確地建立一個產(chǎn)品"軟件應(yīng)該符合它的描述有效性驗證:

“我們是否在建立一個正確的產(chǎn)品"軟件應(yīng)該滿足用戶真正的需要檢驗與有效性驗證是個全生命周期的過程－－檢驗和有效性驗證應(yīng)該應(yīng)用到軟件過程的每個階段有兩個主要目的發(fā)現(xiàn)系統(tǒng)中的缺陷評估系統(tǒng)在實際操作中是否可用檢驗和有效性驗證過程軟件檢查

分析系統(tǒng)的靜態(tài)表述以發(fā)現(xiàn)問題（靜態(tài)檢驗）可能增加基于工具的文檔和代碼分析軟件測試

實際運行和觀察軟件的行為(動態(tài)檢驗)系統(tǒng)實用測試數(shù)據(jù)執(zhí)行，然后觀察其運行的行為靜態(tài)和動態(tài)檢驗靜態(tài)和動態(tài)V&V可以發(fā)現(xiàn)錯誤的存在，不是錯誤的不存在一次成功的測試能夠發(fā)現(xiàn)一個或更多的錯誤對于非功能需求是唯一的驗證手段應(yīng)該和靜態(tài)檢驗聯(lián)合使用以提供全面的檢驗和有效性驗證程序測試缺陷測試設(shè)計測試以發(fā)現(xiàn)系統(tǒng)缺陷成功的測試是發(fā)現(xiàn)系統(tǒng)中缺陷的存在第20章中詳述統(tǒng)計性測試設(shè)計測試以用戶輸入的頻度。用于可靠性估計。第21章中詳述測試的類型V&V目標(biāo)檢驗和有效性驗證的目標(biāo)是要確信軟件符合使用目的這并不意味著程序完全沒有缺陷而是表明系統(tǒng)足以滿足使用要求。使用類型決定了所需的信任程度V&V的信任程度依賴于系統(tǒng)的設(shè)計目標(biāo)、用戶的期望和市場環(huán)境軟件功能系統(tǒng)需要的信任程度取決于該軟件在機構(gòu)中的重要程度用戶期望用戶對某些軟件期望很低市場環(huán)境在市場上推出產(chǎn)品可能比在程序中找出缺陷更加重要缺陷測試和調(diào)試是截然不同的過程檢驗和有效性驗證是一個證明軟件系統(tǒng)中存在缺陷的過程調(diào)試是一個對缺陷定位和修改的過程調(diào)試需要先對程序行為作出假設(shè)，然后對這些假設(shè)進行測試以發(fā)現(xiàn)系統(tǒng)錯誤測試和調(diào)試調(diào)試過程仔細規(guī)劃才能從測試和檢查過程中收獲更多規(guī)劃應(yīng)該從開發(fā)的較早階段開始規(guī)劃應(yīng)該在靜態(tài)檢驗和動態(tài)測試之間均衡考慮測試規(guī)劃是關(guān)于測試過程的標(biāo)準(zhǔn)定義，而不是描述產(chǎn)品測試內(nèi)容V&V規(guī)劃開發(fā)的V字形模型軟件測試計劃的結(jié)構(gòu)測試過程需求跟蹤測試項目測試進度安排測試記錄過程硬件和軟件需求約束軟件檢查相關(guān)人員檢查代碼和文檔，以發(fā)現(xiàn)不規(guī)范和缺陷不要求執(zhí)行系統(tǒng)，所以可在系統(tǒng)實現(xiàn)前使用可應(yīng)用于系統(tǒng)的任何表示形式(需求,設(shè)計,測試數(shù)據(jù)等)發(fā)現(xiàn)錯誤非常有效的方法軟件檢查一次檢查中能發(fā)現(xiàn)許多不同的缺陷。在測試中，一個缺陷可能屏蔽其它缺陷，所以需要多次執(zhí)行由于復(fù)用了領(lǐng)域和程序語言知識，所以評審人員可能見過經(jīng)常出現(xiàn)的錯誤檢查和測試檢查和測試是互相補充的，而不是對立的檢驗技術(shù)兩者都應(yīng)該在檢驗和有效性驗證過程中使用軟件檢查可以檢驗是否和描述一致，但無法檢驗是否和用戶的真正需求一致軟件檢查無法檢驗非功能特征，如性能，可用性等。程序檢查正式規(guī)范的文檔評審過程目的是發(fā)現(xiàn)缺陷(而不是改正缺陷)缺陷可能是邏輯錯誤，可能預(yù)示著錯誤情況的代碼中的不規(guī)范(e.g.沒有初始化的變量)或者不服從標(biāo)準(zhǔn)程序檢查的預(yù)處理對被檢查的代碼有一個精確的描述檢查小組的成員應(yīng)該熟悉機構(gòu)的標(biāo)準(zhǔn)有一個最新的語法正確的代碼版本要準(zhǔn)備一個錯誤檢查的核對清單管理層必須接受檢查將帶來軟件過程早期的費用增加管理層不能將軟件檢查用于員工評價檢查過程檢查的程序檢查團體總體觀察系統(tǒng)代碼代碼和相關(guān)文檔預(yù)先分發(fā)給檢查團隊檢查并發(fā)現(xiàn)錯誤對發(fā)現(xiàn)的錯誤作出修改可能需要也可能不需要重新檢查檢查團隊至少由4人組成所要檢查的代碼的作者檢查者，發(fā)現(xiàn)錯誤、多余內(nèi)容和矛盾的地方讀者，向團隊講解代碼主席/仲裁者，主持會議、記錄發(fā)現(xiàn)的錯誤其他角色，如抄寫員，首席仲裁者檢查清單常見錯誤的清單錯誤清單跟編程語言有關(guān)編程語言的類型檢查越弱，錯誤清單越長舉例：初始化，變量命名，循環(huán)終止，數(shù)組邊界等。程序檢查內(nèi)容缺陷分類檢查內(nèi)容數(shù)據(jù)缺陷所有的程序變量堵在使用前被初始化了嗎所有的常數(shù)都命名了嗎數(shù)組的上邊界應(yīng)該等于數(shù)組長度還是長度減1如果使用字符串，定界符應(yīng)該顯式地指定嗎有緩沖區(qū)溢出的可能性嗎控制缺陷對每一個條件語句，條件是正確的嗎每一個循環(huán)都能終止嗎復(fù)合語句被正確地括起來了嗎對case語句，所有可能的情況都考慮了嗎若每一個case語句都需要跟一個break語句，有遺漏嗎輸入/輸出缺陷所有的輸入變量都使用了嗎所有的輸出變量在輸出前都被賦值了嗎有未料到的輸入引起系統(tǒng)崩潰嗎接口缺陷所有的函數(shù)和方法調(diào)用都使用了正確數(shù)量的參數(shù)嗎形參和實參類型匹配嗎參數(shù)順序都對嗎如果組件訪問共享內(nèi)存，它們都有相同的共享內(nèi)存結(jié)構(gòu)模型嗎存儲管理缺陷如果一個鏈接的結(jié)構(gòu)被修改了，所有的鏈接都得到重新賦值了嗎如果使用了動態(tài)存儲，空間分配正確嗎如果空間不再使用，需要顯式地對空間釋放嗎異常管理缺陷所有可能的錯誤狀態(tài)都已經(jīng)考慮到了嗎檢查的比率總體觀察階段每小時約500行源代碼個別準(zhǔn)備階段每小時約125行源代碼會議檢查每小時約90-125行源代碼檢查是一個昂貴的過程檢查500行的費用約40個人時。自動靜態(tài)分析靜態(tài)分析器是源代碼文本處理的軟件工具分析程序文本以發(fā)現(xiàn)潛在的錯誤情形，提交給V&V團隊對幫助檢查非常有效。是人工檢查的一個補充而不是代替。自動靜態(tài)分析內(nèi)容缺陷分類檢查內(nèi)容數(shù)據(jù)缺陷變量在初始化之前被使用變量被定義但從未使用過變量被賦值兩遍，但中間并未使用過可能的數(shù)組越界未聲明的變量控制缺陷不可到達的代碼無條件循環(huán)輸入/輸出缺陷變量在兩次輸出間沒有賦值過接口缺陷參數(shù)類型不匹配參數(shù)個數(shù)不匹配函數(shù)的結(jié)果沒有用處未調(diào)用過的函數(shù)和子程序存儲管理缺陷未賦值的指針指針參與運算靜態(tài)分析的階段控制流分析.

檢查帶有多個出口或入口的循環(huán)，發(fā)現(xiàn)不可到達的代碼等。數(shù)據(jù)使用分析.

檢出未初始化的變量，一個變量賦值兩次而中間未使用，變量定義后未使用等。接口分析.

檢查過程聲明和使用之間的一致性靜態(tài)分析的階段信息流分析.

確定輸出變量和輸入變量的依賴關(guān)系。不是去發(fā)現(xiàn)異常本身，而是為代碼檢查和評審列出信息流的關(guān)系。路徑分析.

確定程序中的可能路徑以及路徑中執(zhí)行的語句。也是為了評審中的潛在使用。這些階段產(chǎn)生大量的信息。必須小心使用。靜態(tài)分析的使用對于一種弱類型檢查的語言特別有價值，如C語言，許多錯誤無法由編譯器檢測出來對強類型檢查的語言來說性價比不高，如Java，很多錯誤可以在編譯中檢測出來名稱是從半導(dǎo)體生產(chǎn)過程中的“凈室”得來的。其思想是缺陷避免，而不是缺陷移除?；谙铝幸c的軟件開發(fā):增量開發(fā)形式化描述使用正確性論證進行靜態(tài)檢驗用統(tǒng)計性測試以決定程序可靠性凈室軟件開發(fā)凈室過程凈室過程的特征形式化描述，使用狀態(tài)遷移模型增量式開發(fā)結(jié)構(gòu)化編程–使用有限的控制結(jié)構(gòu)和抽象結(jié)構(gòu)靜態(tài)檢驗，使用嚴(yán)格的檢查系統(tǒng)統(tǒng)計性測試增量式開發(fā)形式化描述和檢驗基于狀態(tài)的系統(tǒng)模型，是系統(tǒng)描述和靜態(tài)檢查的基礎(chǔ)模型和系統(tǒng)之間的對應(yīng)關(guān)系清晰數(shù)學(xué)化的論證(不是證明)用來提高軟件檢查的信任程度描述團隊.

負責(zé)開發(fā)和維護系統(tǒng)描述開發(fā)團隊.

負責(zé)對軟件的開發(fā)和檢驗。在這個檢驗過程中軟件是不執(zhí)行的，甚至不編譯。認證團隊.

負責(zé)開發(fā)統(tǒng)計性測試用例集合，在軟件開發(fā)出來后對其進行測試.使用可靠性增長模型來決定何時可靠性是可接受的。凈室過程的團隊IBM公司用凈室開發(fā)的系統(tǒng)在交付后故障很少，給人們留下深刻印象獨立的評估顯示該過程并不比其它方法昂貴比起傳統(tǒng)的開發(fā)過程，錯誤更少要由技術(shù)熟練、有責(zé)任心的軟件工程人員執(zhí)行時才起作用。凈室過程的評估要點檢驗和有效性驗證不是一回事。檢驗