軟件質(zhì)量保證與測試檢查代碼課件

第六章檢查代碼xxx《軟件質(zhì)量保證與測試》1第六章檢查代碼xxx《軟件質(zhì)量保證與測試》1本章重點靜態(tài)白盒測試的好處各種類型的靜態(tài)白盒測試綜述編碼規(guī)范和標準如何從整體審查代碼錯處2本章重點靜態(tài)白盒測試的好處2§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試——檢查代碼，在不執(zhí)行的條件下有條理地仔細審查軟件設(shè)計、體系結(jié)構(gòu)和代碼，從而找出軟件缺陷的過程，有時稱為結(jié)構(gòu)分析。如果具有編程經(jīng)驗，即使只有一點點，就可以對軟件的體系結(jié)構(gòu)和代碼進行測試。白盒測試沒有黑盒測試通用。如果測試軍隊、金融、工業(yè)自動化、醫(yī)藥類軟件，或者有幸在組織嚴格的開發(fā)模式下工作，在代碼級別驗證產(chǎn)品就是例行公事。如果在測試軟件的安全問題，需要白盒測試。3§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試——檢查§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)測試（人工測試）：不運行程序進行測試——即檢查和審閱。靜態(tài)黑盒測試——檢查產(chǎn)品說明書。4§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)測試（人工測試）§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼進行靜態(tài)白盒測試的好處是盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以發(fā)現(xiàn)或隔離的軟件缺陷。進行靜態(tài)白盒測試的另一個好處是為黑盒測試程序員設(shè)計和應(yīng)用測試用例提供思路。通過聽審查評論，可以確定有問題或者容易產(chǎn)生軟件缺陷的特征范圍。5§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼進行靜態(tài)白盒測試的好§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼開發(fā)小組中，負責靜態(tài)白盒測試的人員不是固定的。在某些小組里面，程序員是組織和執(zhí)行審查的人員。軟件測試人員作為獨立的觀察者。還有一些小組，軟件測試人員是任務(wù)的執(zhí)行人，編寫代碼的程序員和其他同事幫助審查。6§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼開發(fā)小組中，負責靜態(tài)§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試方法的正規(guī)性、精確性不如基于計算機測試但并不妨礙測試取得成功，可以提高測試的功效錯誤發(fā)現(xiàn)得越早，改正錯誤成本越低。更容易定位以及發(fā)現(xiàn)由該錯誤引發(fā)的其他缺陷（如連鎖錯誤或類似錯誤）降低調(diào)試成本通常會有效地查找出30％－70％的邏輯設(shè)計和編碼錯誤7§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試方法的正§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試一般面臨的情況是不能善始善終現(xiàn)狀：許多小組錯誤的認為靜態(tài)白盒測試耗時太多，費用太高，沒有產(chǎn)出。人們認為程序員的任務(wù)就是編寫代碼，而任何破壞代碼編寫效率的事情都會減緩開發(fā)過程。這些想法都不對，在后期發(fā)現(xiàn)軟件缺陷的費用要昂貴很多。還好這些情況正在改變。8§6.1靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試一般面臨§6.2正式審查正式審查就是進行靜態(tài)白盒測試的過程正式審查的含義很廣，從兩個程序員之間的簡單交談，到軟件設(shè)計和代碼的詳細、嚴格檢查均屬于此過程。四個基本要素：確定問題：審查的目的是找出軟件的問題。找出錯誤、遺漏，對事不對人。遵守規(guī)則：設(shè)立并嚴格執(zhí)行準備：了解自己的責任和義務(wù)編寫報告：做出審查結(jié)果的書面總結(jié)9§6.2正式審查正式審查就是進行靜態(tài)白盒測試的過程9§6.2正式審查正式審查要嚴格按照已經(jīng)建立起來的過程執(zhí)行。太隨意會讓參與者感覺是在浪費時間。正式審查可以在早期發(fā)現(xiàn)一些重大缺陷，一些小的缺陷可能留在后面的測試工作中。10§6.2正式審查正式審查要嚴格按照已經(jīng)建立起來的過程執(zhí)行§6.2正式審查堅持正式審查還有一些間接效果：交流：正式報告中沒包含的信息得以交流。例如，黑盒測試程序員洞察問題所在。年輕程序員可以學習新技術(shù)。管理員更加理解項目進度。質(zhì)量：程序員的代碼經(jīng)過逐個功能、逐個代碼仔細復(fù)查，常常會使程序員變得更加仔細。小組同志化：如果審查正確進行，就會建立軟件測試員和程序員對雙方技藝的相互尊重，并且更好地了解互相的工作及需求。解決方案：在審查之外討論解決方案也較有效。11§6.2正式審查堅持正式審查還有一些間接效果：11§6.2正式審查一般至少應(yīng)有4人一人負責協(xié)調(diào)：分發(fā)材料、安排進程、確保錯誤隨后得到改正被測試程序的編碼人員程序的設(shè)計人員一名測試專家12§6.2正式審查一般至少應(yīng)有4人12§6.2正式審查實施過程：協(xié)調(diào)人在代碼檢查前幾天分發(fā)程序清單和設(shè)計規(guī)范編碼人員講述程序的邏輯結(jié)構(gòu)，其他人員提問題并判斷是否存在錯誤(對照常見的編碼錯誤列表)注意力集中在發(fā)現(xiàn)錯誤而非糾正錯誤上（非調(diào)試）會議結(jié)束后，程序員會得到一份已發(fā)現(xiàn)錯誤的清單13§6.2正式審查實施過程：13§6.2正式審查其他審查方式：同事審查：伙伴審查（你看看我的，我看看你的）。走查：將代碼給其他小組。檢查：正式的審查。14§6.2正式審查其他審查方式：14§6.3編碼標準和規(guī)范有三個重要的原因要堅持標準或者規(guī)范：可靠性：更加可靠和安全可讀性/維護性：代碼更容易閱讀、理解和維護移植性：有助于在不同的硬件中運行15§6.3編碼標準和規(guī)范有三個重要的原因要堅持標準或者規(guī)范§6.3編碼標準和規(guī)范標準：必須遵守的規(guī)則規(guī)范：建議的最佳做法既有一些國際、國內(nèi)通用的標準及規(guī)范，也有一些公司內(nèi)部的規(guī)定。雖然編程是藝術(shù)，但是標新立異未必是藝術(shù)指望怪異著裝體現(xiàn)自己藝術(shù)家氣質(zhì)的，往往是不入流的“藝術(shù)家”。16§6.3編碼標準和規(guī)范標準：必須遵守的規(guī)則16§6.3編碼標準和規(guī)范如何獲取標準：通過公共機構(gòu)美國國家標準學會（ANSI）。國際工程學會（IEC）。國際標準化組織（ISO）。信息技術(shù)標準國家委員會（NCITS）。美國計算機協(xié)會（ACM）。電子電氣工程學會（IEEE）。17§6.3編碼標準和規(guī)范如何獲取標準：通過公共機構(gòu)17§6.4通用代碼審查清單應(yīng)該審查哪些內(nèi)容？18§6.4通用代碼審查清單應(yīng)該審查哪些內(nèi)容？18§6.4.1數(shù)據(jù)引用錯誤變量使用前是否賦值或初始化？數(shù)據(jù)類型是否匹配？數(shù)組下標的范圍和類型：遺漏、越界等通過指針引用的內(nèi)存單元是否存在（虛調(diào)用）？如函數(shù)返回局部變量的指針會產(chǎn)生虛調(diào)用錯誤。被引用的變量或內(nèi)存的屬性是否與預(yù)期的一致？如A類型的指針或引用指向的是非A類型對象。19§6.4.1數(shù)據(jù)引用錯誤變量使用前是否賦值或初始化？19§6.4.2數(shù)據(jù)聲明錯誤是否所有變量都已聲明？默認的屬性（默認值）是否正確？變量的初始化是否正確？變量的初始化是否與其存儲空間的類型一致？是否每個變量都有正確的長度、類型和存儲類別？是否存在相似名稱的變量？20§6.4.2數(shù)據(jù)聲明錯誤是否所有變量都已聲明？20§6.4.3計算錯誤是否存在非算術(shù)變量之間的運算？是否存在混合模式的運算？（int與float類型）是否存在不同字長變量之間的運算？目標變量長度是否小于所賦值的大?。浚ň葥p失或越界錯誤）中間結(jié)果是否上溢或下溢？是否存在除0錯誤？操作符的優(yōu)先順序是否正確？整數(shù)除法是否正確？（精度問題）21§6.4.3計算錯誤是否存在非算術(shù)變量之間的運算？21§6.4.4比較錯誤是否有不同類型數(shù)據(jù)的比較運算？是否有混合模式或不同長度數(shù)據(jù)的比較運算？比較運算符是否正確？布爾表達式（與、或、非）是否正確？比較運算符是否與布爾表達式相混合？是否存在浮點數(shù)的比較？優(yōu)先順序是否正確？22§6.4.4比較錯誤是否有不同類型數(shù)據(jù)的比較運算？22§6.4.5控制流程錯誤是否所有循環(huán)都能終止？（循環(huán)結(jié)束條件是否能滿足，遞歸的終止條件是否能滿足。）是否存在由于入口條件不滿足而跳過循環(huán)體？（do-while循環(huán)）是否存在僅差一個的循環(huán)錯誤？如for(inti=0;i<=10;i++){}程序結(jié)構(gòu)中括號是否匹配、if,else是否匹配、do,while是否匹配、try,catch是否匹配等。23§6.4.5控制流程錯誤是否所有循環(huán)都能終止？（循環(huán)結(jié)束§6.4.6子程序參數(shù)錯誤形參和實參的數(shù)量是否相等？形參的屬性是否與實參的屬性相匹配？形參的屬性是否與實參的順序相匹配？形參的單位是否和實參匹配？（屬邏輯錯誤）是否改變了某個僅作為輸入值的形參？全局變量的定義是否一致？24§6.4.6子程序參數(shù)錯誤形參和實參的數(shù)量是否相等？24§6.4.7輸入/輸出錯誤文件屬性是否正確？打開文件的語句是否正確？緩沖區(qū)、內(nèi)存大小是否足夠來保留程序?qū)⒆x取的文件？文件在使用前是否打開？文件在使用后是否關(guān)閉了？文件結(jié)束條件是否本正確處理？是否處理了IO錯誤？打印或輸出的文本信息中是否存在拼寫或語法錯誤？即輸出結(jié)果正確性。25§6.4.7輸入/輸出錯誤文件屬性是否正確？25§6.4.8其他檢查是否存在未引用過的變量？每個變量的屬性和賦予的默認值是否一致？編譯通過的程序是否存在“警告”或“提示”信息？程序或模塊是否對輸入的合法性進行了檢查？程序是否遺漏了某個功能？26§6.4.8其他檢查是否存在未引用過的變量？26本章小結(jié)檢查代碼——靜態(tài)白盒測試——被證實是早期發(fā)現(xiàn)軟件缺陷最有效的方法。這是一項需要大量準備工作才能有成效的任務(wù)。許多研究表明，花費時間在靜態(tài)白盒測試上面與得到的好處相比是值得的。靜態(tài)白盒測試正在收到重視，在某些開發(fā)過程中，沒有靜態(tài)白盒測試，項目就無法得到可靠的軟件。27本章小結(jié)檢查代碼——靜態(tài)白盒測試——被證實是早期發(fā)現(xiàn)軟件缺陷2828作業(yè)請回答以下