6 代碼檢查、走查與評審

1、代碼檢查、走查與評審靜態(tài)的白盒測試1靜態(tài)測試和動態(tài)測試靜態(tài)測試（人工測試）不運行程序進行測試，即檢查和審閱靜態(tài)黑盒測試檢查產品說明書靜態(tài)白盒測試檢查代碼，在不執(zhí)行的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時稱為結構分析。動態(tài)測試（基于計算機的測試）運行和使用軟件以發(fā)現錯誤，即通常意義上的測試2人工測試人工測試方法的正規(guī)性、精確性不如基于計算機測試，但并不妨礙測試取得成功，相反可以提高測試的功效和可靠性錯誤發(fā)現得越早，改正錯誤成本越低，正確改正錯誤可能性越大程序員在開始基于計算機的測試時要經歷一個心理上的轉變，改正早期發(fā)現的錯誤比改正后期計算機執(zhí)行發(fā)現的錯誤時失

2、誤更少更容易定位以及發(fā)現由該錯誤引發(fā)的其他缺陷（如連鎖錯誤或類似錯誤）降低調試成本通常會有效地查找出3070的邏輯設計和編碼錯誤3代碼檢查負責靜態(tài)測試的人員不是固定的。在某些小組中，程序員就是組織和審查的人員，軟件測試員被要求作為獨立的觀察者。還有一些小組，軟件測試員是該任務的執(zhí)行人，要求編寫代碼的程序員和其他同時幫助審查。采用何種方式取決于開發(fā)小組的自身狀況。4代碼檢查靜態(tài)白盒測試一般面臨的情況是不能善始善終，因為小組會認為太好使，費用太高，沒有產出。原因是人們認為程序員的任務就是編寫代碼，而任何破壞代碼編寫效率的事情都會減緩開發(fā)過程。5代碼檢查四個基本要素確定問題. 遵守規(guī)則. 準備. 編

3、寫報告. 6代碼檢查實施過程協調人在代碼檢查前幾天分發(fā)程序清單和設計規(guī)范編碼人員講述程序的邏輯結構，其他人員提問題并判斷是否存在錯誤(對照歷來常見的編碼錯誤列表)注意力集中在發(fā)現錯誤而非糾正錯誤上（非調試）會議結束后，程序員會得到一份已發(fā)現錯誤的清單代碼檢查的其他作用程序員會得到編程風格、算法選擇及編程技術等方面的反饋信息其他參與者也可以同樣受益7代碼檢查人員組成（4人）一人負責協調：分發(fā)材料、安排進程、確保錯誤隨后得到改正被測試程序的編碼人員程序的設計人員和一名測試專家實施過程協調人在代碼檢查前幾天分發(fā)程序清單和設計規(guī)范編碼人員講述程序的邏輯結構，其他人員提問題并判斷是否存在錯誤對照歷來常見

4、的編碼錯誤列表分析程序注意力集中在發(fā)現錯誤而非糾正錯誤上（非調試）會議結束后，程序員會得到一份已發(fā)現錯誤的清單8代碼檢查的錯誤列表1.數據引用錯誤變量使用前是否賦值或初始化？容易引起變量使用錯誤，特別是對于指針或引用變量。在java中要求變量在使用前必須初始化。數組下標的范圍和類型是否存在下標越界錯誤，下表類型是否為整型。通過指針引用的內存單元是否存在（虛調用）？如在函數返回局部變量的指針或引用時會產生虛調用錯誤。被引用的變量或內存的屬性是否與編譯器預期的一致？如A類型的指針或引用是否指向的是非A類型對象。9代碼檢查的錯誤列表（cont）2.數據聲明錯誤是否所有變量都已聲明？絕大多數編程語言要

5、求變量先定義后使用，可保證變量使用的安全性。默認的屬性（默認值）是否正確？變量的初始化是否正確？變量的初始化是否與其存儲空間的類型一致？是否每個變量都有正確的長度、類型和存儲類別？是否存在相似名稱的變量？103.運算錯誤是否存在非算術變量之間的運算？是否存在混合模式的運算？（ int與float類型）是否存在不同字長變量之間的運算？（int與long類型）目標變量大小是否小于所賦值的大?。浚ň葥p失或越界錯誤）中間結果是否上溢或下溢？是否存在除0錯誤？操作符的優(yōu)先順序是否正確？整數除法是否正確？（精度問題，如2*（i/2）=i）代碼檢查的錯誤列表（cont）11代碼檢查的錯誤列表（cont）i

6、nt x = 1;int y = 2;float z = 0;z = x/y;System.out.println (z = z);OUTPUT:z = 012代碼檢查的錯誤列表（cont）4.比較錯誤是否有不同類型數據的比較運算？（如日期與數字）是否有混合模式或不同長度數據的比較運算？比較運算符是否正確？（如至多、至少，不小于）布爾表達式（與、或、非）是否正確？比較運算符是否與布爾表達式相混合？（如2iz)）135.控制流程錯誤是否所有循環(huán)都能終止？（循環(huán)結束條件是否能滿足以及遞歸的終止條件是否能滿足。）是否存在由于入口條件不滿足而跳過循環(huán)體？（do-while循環(huán)）是否存在僅差一個的循環(huán)錯

7、誤？（如for(int i=0;i=10;i+)）程序結構中括號是否匹配、if,else是否匹配、do,while是否匹配、try,catch是否匹配等。代碼檢查的錯誤列表（cont）14代碼檢查的錯誤列表（cont）for (i=x ; i=z; i+) .while (NOTFOUND) .15代碼檢查的錯誤列表（cont）6.接口錯誤形參和實參的數量是否相等？形參的屬性是否與實參的屬性相匹配？形參的屬性是否與實參的順序相匹配？形參的單位是否和實參匹配？（屬邏輯錯誤）是否改變了某個僅作為輸入值的形參？（C+中的const關鍵字）全局變量的定義是否一致？167.輸入輸出錯誤文件屬性是否正確？

8、打開文件的語句是否正確？緩沖區(qū)、內存大小是否足夠來保留程序將讀取的文件？文件在使用前是否打開？文件在使用后是否關閉了？文件結束條件是否本正確處理？是否處理了IO錯誤？打印或輸出的文本信息中是否存在拼寫或語法錯誤？即輸出結果正確性。代碼檢查的錯誤列表（cont）17代碼檢查的錯誤列表（cont）8.其他檢查是否存在未引用過的變量？每個變量的屬性和賦予的默認值是否一致？編譯通過的程序是否存在“警告”或“提示”信息？程序或模塊是否對輸入的合法性進行了檢查？（如第一章中三角形例）程序是否遺漏了某個功能？18代碼走查代碼走查和代碼檢查類似，都是以小組為單位進行代碼閱讀，是一系列規(guī)程和錯誤檢查技術的集合。二者的過程大致相同，不同之處在于規(guī)程稍微不同走查會議期間，每個測試用例都在人們腦中推演，即把測試的數據沿著程序的邏輯結構走一遍，記錄程序的狀態(tài)供監(jiān)視，很多錯誤是在向程序員提問的過程中發(fā)現的。其他與代碼檢查相同的地方參與者所持的態(tài)度同樣非常關鍵代碼走查也會帶來同樣的附帶作用19桌面檢查桌面檢查是人工查找錯誤的一種古老的方法桌面檢查可視為由單人進行的代碼檢查或代碼走查由一個人閱讀程序，對照錯誤列表檢查程序，對程序推演的過程。桌面檢查的缺點桌面檢查的效率低是一個完全沒有約束的過程違