摘要：本文描述了軟件代碼審查的作用、代碼審查內容、代碼審查過程，并列舉一些常見代碼審查問題。
關鍵詞：軟件測試；代碼審查；
一、引言
軟件測試常用方法可分為動態(tài)測試和靜態(tài)測試，只有動態(tài)測試和靜態(tài)測試有效結合，才能更好的完成軟件測試工作。代碼審查是軟件靜態(tài)測試中常用的軟件測試方法之一，代碼審查時，只要測試人員方法得當、足夠細心，往往能夠產生意想不到的效果。
二、代碼審查的作用
代碼審查是在不執(zhí)行軟件的條件下有條理的仔細審查軟件代碼，從而找出軟件缺陷的過程。
代碼審查可以找出動態(tài)測試難以發(fā)現(xiàn)或隔離的軟件缺陷。在開發(fā)過程初期讓測試人員集中精力進行軟件代碼審查非常有價值：可以提高代碼質量；在項目的早期發(fā)現(xiàn)缺陷，將損失降至最低；促進團隊溝通、促進知識共享、共同提高。
代碼審查還可以為動態(tài)測試時設計和執(zhí)行測試用例提供思路。通過代碼審查，可以確定有問題或者容易產生軟件缺陷的特性范圍。
三、代碼審查的過程
代碼審查過程可分為：代碼審查策劃階段、代碼審查實施階段以及代碼審查總結階段。
（一）代碼審查策劃階段
1、項目負責人分配代碼審查任務；
2、確定代碼審查策略：依據(jù)軟件開發(fā)文檔，確定軟件關鍵模塊，作為代碼審查重點；將復雜度高的模塊也作為代碼審查的重點；
3、項目負責人確定代碼審查單，審查內容一般可包括：
（1）可追溯性：
――代碼是否遵循詳細設計？
――代碼是否與需求一致？
（2）邏輯：
――表示優(yōu)先級的括號用法是否正確？
――代碼是否依賴賦值順序？
――“if…else”和“switch”使用是否正確清晰？
――循環(huán)能否結束？
――復合語句是否正確地被花括號括起來？
――case語句是否所有可能出現(xiàn)的情況均已考慮？
――“goto”是否使用？
（3）數(shù)據(jù)：
――變量在使用前是否已初始化？
――變量的聲明是否按組劃分為外部的和內部的？
――除最明顯的聲明外，是否所有聲明都有注釋？
――每個命名是否僅用于一個用途？
――常量名是否都大寫？
――常量是否都是通過“#define”定義的？
――用于多個文件中的常量是否在一個頭文件中定義？
――頭文件中是否存在可執(zhí)行的代碼？
――定義為指針的變量是否作為指針使用（而不是作為整數(shù)）？
――指針是否初始化？
――釋放內存后是否將指針立即設置為NULL（或0）？
――傳遞指針到另一個函數(shù)的代碼是否首先檢查了指針的有效性？
――通過指針寫入動態(tài)分配內存的代碼是否首先檢查了指針的有效性？
――宏的命名是否都大寫？
――數(shù)組是否越界？
（4）接口：
――在所有的函數(shù)及過程調用中，參數(shù)的個數(shù)都正確嗎？
――形參與實參類型匹配嗎？
――參數(shù)順序正確嗎？
――如果訪問共享內存，是否具有相同的共享內存結構模式？
（5）文檔：
――軟件文檔是否與代碼一致？
（6）注釋：
――注釋與代碼是否一致？
――用于理解代碼的注釋是否提供了必要的信息？
――是否對數(shù)組和變量的作用進行了描述？
（7）異常處理：
――是否所有可能的錯誤都已加以考慮？
（8）內存：
――在向動態(tài)分配的內存寫入之前是否檢查了內存申請是否成功？
――若采用動態(tài)分配內存，內存空間分配是否正確？
――當內存空間不再需要時，是否被明確的釋放？
（9）其它：
――是否檢查了函數(shù)調用返回值？
――所有的輸入變量都用到了嗎？
――所有的輸出變量在輸出前都已賦值了嗎？
4、確定代碼審查進度安排，項目負責人負責安排代碼審查的進度。
（二）代碼審查實施階段
1、代碼講解：軟件開發(fā)人員詳細向測試人員講解如何以及為何這樣實現(xiàn)，測試人員提出問題和建議。通過代碼講解，測試人員對被審查的軟件有了一個全面的認識，為后續(xù)代碼審查打下良好的基礎。
2、靜態(tài)分析：一般采用靜態(tài)分析工具進行，主要分析軟件的代碼規(guī)模、模塊數(shù)、模塊調用關系、扇入、扇出、圈復雜度、注釋率等軟件質量度量元。靜態(tài)分析在代碼審查時應優(yōu)先進行，有利于軟件測試人員在后續(xù)代碼審查時對軟件建立宏觀上認識，在審查中容易做到有的放矢，更易于發(fā)現(xiàn)軟件代碼中的缺陷。
3、規(guī)則檢查：采用靜態(tài)分析工具對源程序進行編碼規(guī)則檢查，對于工具報出的問題再由人工進行進一步的分析以確認軟件問題，是一種比較有效的方法。
4、正式代碼審查：代碼審查可分兩步進行：獨立審查和會議審查。根據(jù)情況，這兩步可以反復進行多次。
（1）獨立審查：測試人員根據(jù)項目負責人的工作分配，獨自對自己負責的軟件模塊進行代碼審查。測試人員根據(jù)代碼審查單，對相關代碼進行閱讀、理解和分析后，記錄發(fā)現(xiàn)的錯誤和疑問。
（2）會議審查：項目負責人主持召開會議，測試人員和開發(fā)人員參加；測試人員就獨立審查發(fā)現(xiàn)的問題和疑問與開發(fā)人員溝通，并討論形成一致意見；對發(fā)現(xiàn)的問題匯總，填寫軟件問題報告單，提交開發(fā)人員處理。
5、更改確認：開發(fā)人員對問題進行處理，代碼審查人員對軟件的處理情況進行確認，驗證更改的正確性，并防止出現(xiàn)新的問題。
（三）代碼審查總結階段
代碼審查工作結束后，項目負責人總結代碼審查結果；編寫測試報告，對軟件代碼質量進行評估，給出合理建議。
把代碼審查提出的所有問題、亮點及最終結論詳細的記錄下來，供其他軟件項目代碼審查借鑒。必要時，可建立常見軟件代碼缺陷數(shù)據(jù)庫，為軟件代碼審查人員培訓和執(zhí)行代碼審查提供數(shù)據(jù)支持，也可以為軟件編碼規(guī)則制定規(guī)范提供實踐依據(jù)。
四、代碼審查中的常見問題
如果軟件測試人員熟悉常見的軟件代碼審查問題，對代碼審查效率是很有幫助的。筆者根據(jù)自己的應驗，列舉部分常見軟件代碼審查問題如下（僅供參考）：
（1）浮點數(shù)相等比較：可能造成程序未按設計的路徑執(zhí)行；
（2）因設計原因導致某些代碼不能執(zhí)行：如邏輯表達式永遠為真（或假）造成某分支不能執(zhí)行、代碼前面有return語句、某模塊從未被調用等；
（3）switch語句沒有break語句（有意如此設計時除外）；
（4）數(shù)組越界使用：數(shù)組越界容易發(fā)生在數(shù)組下標是計算得到的情況下，而且審查時很難發(fā)現(xiàn)這種代碼缺陷，應加以重視；
（5）變量未初始化就使用或者是條件賦值就使用；
（6）程序中存在未使用的多余變量；
（7）復合邏輯表達式沒有使用括號造成運算順序錯誤；
（8）有返回值的函數(shù)中return沒有帶返回值；
（9）邏輯判別的表達式不是邏輯表達式；
（10）動態(tài)分配的內存沒有及時釋放：忘記寫內存釋放代碼或由于其它邏輯缺陷導致內存釋放代碼未得到執(zhí)行；
（11）沒有對緩沖區(qū)溢出進行必要的防護；
（12）訪問空指針，即指針未初始化就使用；
（13）指針指向的內存釋放后，未將指針置為NULL：其它函數(shù)訪問該指針時，判斷指針不為空，當作有效指針使用，會造成內存訪問錯誤；
（14）注釋說明與程序代碼實現(xiàn)不一致，甚至相反；
（15）循環(huán)存在不能跳出的可能，程序中沒有相應的保護機制。
五、結束語
軟件代碼審查是重要的軟件測試方法之一，軟件測試單位應建立完善的代碼審查規(guī)程，規(guī)范代碼審查過程。代碼審查人員應善于使用軟件靜態(tài)分析工具，善于總結代碼審查經驗。軟件代碼審查工作做得扎實，可以發(fā)現(xiàn)很多軟件編碼隱含的缺陷，提高軟件的可靠性，為后續(xù)的動態(tài)測試打下良好的基礎。
原文地址：http://www.xzbu.com/8/view-1683607.htm