1、第六章 檢查代碼主講人：主講人： 李巍李巍軟件質(zhì)量保證與測試本章重點(diǎn)靜態(tài)白盒測試的好處各種類型的靜態(tài)白盒測試綜述編碼規(guī)范和標(biāo)準(zhǔn)如何從整體審查代碼錯處26.1 靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試檢查代碼，在不執(zhí)行的條件下有條理地仔細(xì)審查軟件設(shè)計、體系結(jié)構(gòu)和代碼，從而找出軟件缺陷的過程，有時稱為結(jié)構(gòu)分析。如果具有編程經(jīng)驗(yàn)，即使只有一點(diǎn)點(diǎn)，就可以對軟件的體系結(jié)構(gòu)和代碼進(jìn)行測試。白盒測試沒有黑盒測試通用。如果測試軍隊(duì)、金融、工業(yè)自動化、醫(yī)藥類軟件，或者有幸在組織嚴(yán)格的開發(fā)模式下工作，在代碼級別驗(yàn)證產(chǎn)品就是例行公事。如果在測試軟件的安全問題，需要白盒測試。36.1 靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)

2、測試（人工測試）：不運(yùn)行程序進(jìn)行測試即檢查和審閱。靜態(tài)黑盒測試檢查產(chǎn)品說明書。46.1 靜態(tài)白盒測試：檢查設(shè)計和代碼進(jìn)行靜態(tài)白盒測試的好處是盡早發(fā)現(xiàn)軟件缺陷，以找出動態(tài)黑盒測試難以發(fā)現(xiàn)或隔離的軟件缺陷。進(jìn)行靜態(tài)白盒測試的另一個好處是為黑盒測試程序員設(shè)計和應(yīng)用測試用例提供思路。 通過聽審查評論，可以確定有問題或者容易產(chǎn)生軟件缺陷的特征范圍。56.1 靜態(tài)白盒測試：檢查設(shè)計和代碼開發(fā)小組中，負(fù)責(zé)靜態(tài)白盒測試的人員不是固定的。 在某些小組里面，程序員是組織和執(zhí)行審查的人員。軟件測試人員作為獨(dú)立的觀察者。 還有一些小組，軟件測試人員是任務(wù)的執(zhí)行人，編寫代碼的程序員和其他同事幫助審查。66.1 靜態(tài)白盒

3、測試：檢查設(shè)計和代碼靜態(tài)白盒測試方法的正規(guī)性、精確性不如基于計算機(jī)測試但并不妨礙測試取得成功，可以提高測試的功效錯誤發(fā)現(xiàn)得越早，改正錯誤成本越低。 更容易定位以及發(fā)現(xiàn)由該錯誤引發(fā)的其他缺陷（如連鎖錯誤或類似錯誤）降低調(diào)試成本 通常會有效地查找出3070的邏輯設(shè)計和編碼錯誤76.1 靜態(tài)白盒測試：檢查設(shè)計和代碼靜態(tài)白盒測試一般面臨的情況是不能善始善終現(xiàn)狀：許多小組錯誤的認(rèn)為靜態(tài)白盒測試耗時太多，費(fèi)用太高，沒有產(chǎn)出。人們認(rèn)為程序員的任務(wù)就是編寫代碼，而任何破壞代碼編寫效率的事情都會減緩開發(fā)過程。這些想法都不對，在后期發(fā)現(xiàn)軟件缺陷的費(fèi)用要昂貴很多。還好這些情況正在改變。86.2 正式審查正式審查就是

4、進(jìn)行靜態(tài)白盒測試的過程 正式審查的含義很廣，從兩個程序員之間的簡單交談，到軟件設(shè)計和代碼的詳細(xì)、嚴(yán)格檢查均屬于此過程。四個基本要素： 確定問題：審查的目的是找出軟件的問題。找出錯誤、遺漏，對事不對人 。 遵守規(guī)則：設(shè)立并嚴(yán)格執(zhí)行 準(zhǔn)備：了解自己的責(zé)任和義務(wù) 編寫報告：做出審查結(jié)果的書面總結(jié)96.2 正式審查正式審查要嚴(yán)格按照已經(jīng)建立起來的過程執(zhí)行。 太隨意會讓參與者感覺是在浪費(fèi)時間。正式審查可以在早期發(fā)現(xiàn)一些重大缺陷，一些小的缺陷可能留在后面的測試工作中。106.2 正式審查堅(jiān)持正式審查還有一些間接效果： 交流：正式報告中沒包含的信息得以交流。 例如，黑盒測試程序員洞察問題所在。 年輕程序員可

5、以學(xué)習(xí)新技術(shù)。 管理員更加理解項(xiàng)目進(jìn)度。 質(zhì)量：程序員的代碼經(jīng)過逐個功能、逐個代碼仔細(xì)復(fù)查，常常會使程序員變得更加仔細(xì)。 小組同志化：如果審查正確進(jìn)行，就會建立軟件測試員和程序員對雙方技藝的相互尊重，并且更好地了解互相的工作及需求。 解決方案：在審查之外討論解決方案也較有效。116.2 正式審查一般至少應(yīng)有 4 人一人負(fù)責(zé)協(xié)調(diào)：分發(fā)材料、安排進(jìn)程、確保錯誤隨后得到改正被測試程序的編碼人員程序的設(shè)計人員一名測試專家126.2 正式審查實(shí)施過程： 協(xié)調(diào)人在代碼檢查前幾天分發(fā)程序清單和設(shè)計規(guī)范 編碼人員講述程序的邏輯結(jié)構(gòu)，其他人員提問題并判斷是否存在錯誤(對照常見的編碼錯誤列表) 注意力集中在發(fā)現(xiàn)錯

6、誤而非糾正錯誤上（非調(diào)試） 會議結(jié)束后，程序員會得到一份已發(fā)現(xiàn)錯誤的清單136.2 正式審查其他審查方式： 同事審查：伙伴審查（你看看我的，我看看你的）。 走查：將代碼給其他小組。 檢查：正式的審查。146.3 編碼標(biāo)準(zhǔn)和規(guī)范有三個重要的原因要堅(jiān)持標(biāo)準(zhǔn)或者規(guī)范： 可靠性：更加可靠和安全 可讀性/維護(hù)性：代碼更容易閱讀、理解和維護(hù) 移植性：有助于在不同的硬件中運(yùn)行156.3 編碼標(biāo)準(zhǔn)和規(guī)范標(biāo)準(zhǔn)：必須遵守的規(guī)則規(guī)范：建議的最佳做法既有一些國際、國內(nèi)通用的標(biāo)準(zhǔn)及規(guī)范，也有一些公司內(nèi)部的規(guī)定。雖然編程是藝術(shù)，但是標(biāo)新立異未必是藝術(shù)指望怪異著裝體現(xiàn)自己藝術(shù)家氣質(zhì)的，往往是不入流的“藝術(shù)家”。166.3

7、編碼標(biāo)準(zhǔn)和規(guī)范如何獲取標(biāo)準(zhǔn)：通過公共機(jī)構(gòu) 美國國家標(biāo)準(zhǔn)學(xué)會（ANSI）。 國際工程學(xué)會（IEC）。 國際標(biāo)準(zhǔn)化組織（ISO）。 信息技術(shù)標(biāo)準(zhǔn)國家委員會（NCITS）。 美國計算機(jī)協(xié)會（ACM）。 電子電氣工程學(xué)會（IEEE）。176.4 通用代碼審查清單應(yīng)該審查哪些內(nèi)容？186.4.1 數(shù)據(jù)引用錯誤變量使用前是否賦值或初始化？數(shù)據(jù)類型是否匹配？數(shù)組下標(biāo)的范圍和類型：遺漏、越界等通過指針引用的內(nèi)存單元是否存在（虛調(diào)用）？ 如函數(shù)返回局部變量的指針會產(chǎn)生虛調(diào)用錯誤。被引用的變量或內(nèi)存的屬性是否與預(yù)期的一致？ 如A類型的指針或引用指向的是非A類型對象。196.4.2 數(shù)據(jù)聲明錯誤是否所有變量都已聲明

8、？默認(rèn)的屬性（默認(rèn)值）是否正確？變量的初始化是否正確？變量的初始化是否與其存儲空間的類型一致？是否每個變量都有正確的長度、類型和存儲類別？是否存在相似名稱的變量？206.4.3 計算錯誤是否存在非算術(shù)變量之間的運(yùn)算？是否存在混合模式的運(yùn)算？（ int與float類型）是否存在不同字長變量之間的運(yùn)算？目標(biāo)變量長度是否小于所賦值的大??？（精度損失或越界錯誤）中間結(jié)果是否上溢或下溢？是否存在除0錯誤？操作符的優(yōu)先順序是否正確？整數(shù)除法是否正確？（精度問題）216.4.4 比較錯誤是否有不同類型數(shù)據(jù)的比較運(yùn)算？是否有混合模式或不同長度數(shù)據(jù)的比較運(yùn)算？比較運(yùn)算符是否正確？布爾表達(dá)式（與、或、非）是否正確

9、？比較運(yùn)算符是否與布爾表達(dá)式相混合？是否存在浮點(diǎn)數(shù)的比較？優(yōu)先順序是否正確？226.4.5 控制流程錯誤是否所有循環(huán)都能終止？（循環(huán)結(jié)束條件是否能滿足，遞歸的終止條件是否能滿足。）是否存在由于入口條件不滿足而跳過循環(huán)體？（do-while循環(huán)）是否存在僅差一個的循環(huán)錯誤？ 如for ( int i=0; i=10; i+) 程序結(jié)構(gòu)中括號是否匹配、if,else是否匹配、do,while是否匹配、try,catch是否匹配等。236.4.6 子程序參數(shù)錯誤形參和實(shí)參的數(shù)量是否相等？形參的屬性是否與實(shí)參的屬性相匹配？形參的屬性是否與實(shí)參的順序相匹配？形參的單位是否和實(shí)參匹配？（屬邏輯錯誤）是否改

10、變了某個僅作為輸入值的形參？全局變量的定義是否一致？246.4.7 輸入/輸出錯誤文件屬性是否正確？打開文件的語句是否正確？緩沖區(qū)、內(nèi)存大小是否足夠來保留程序?qū)⒆x取的文件？文件在使用前是否打開？文件在使用后是否關(guān)閉了？文件結(jié)束條件是否本正確處理？是否處理了IO錯誤？打印或輸出的文本信息中是否存在拼寫或語法錯誤？即輸出結(jié)果正確性。256.4.8 其他檢查是否存在未引用過的變量？每個變量的屬性和賦予的默認(rèn)值是否一致？編譯通過的程序是否存在“警告”或“提示”信息？程序或模塊是否對輸入的合法性進(jìn)行了檢查？程序是否遺漏了某個功能？26本章小結(jié)檢查代碼靜態(tài)白盒測試被證實(shí)是早期發(fā)現(xiàn)軟件缺陷最有效的方法。這是一項(xiàng)需要大量準(zhǔn)備工作才能有成效的任務(wù)。許多研究表明，花費(fèi)時間在靜態(tài)白盒測試上面與得到的好處相比是值得的。靜態(tài)白盒測試正在收到重視，在某些開發(fā)過程中，沒有靜態(tài)白盒測試，項(xiàng)目就無法得到可靠的軟件。27作業(yè)請回答以下問題：1. 說出白盒測試的幾個好處？2. 判斷題：靜態(tài)白盒測試可以找出遺漏之處和問題。3.