摘要：代碼檢查是白盒測試的一種靜態測試方法，是眾多軟件測試方法中發現軟件缺陷最有效的方法之一。本文結合國內外學者在相關領域的研究情況，介紹代碼檢查相關的基本概念、過程和分析方法。
　　關鍵字：白盒測試，代碼檢查，靜態分析，檢查規則
一、 引言
　　按照測試時源代碼是否可見，軟件測試可以分為白盒測試和黑盒測試兩類。
白盒測試（結構測試），即邏輯驅動的測試，是在了解程序內部結構的基礎上，對程序的邏輯結構進行檢查，從中獲取測試數據。白盒測試關注的是測試用例執行的程度或覆蓋程序邏輯結構的程度。白盒測試一般只應用于軟件開發階段。
白盒測試，又可按照是否需要運行程序，進一步細分為了靜態測試和動態測試兩種。通常情況下是按照先靜態后動態測試順序來實施。其中，靜態測試包括代碼檢查、靜態結構分析、代碼質量度量等測試內容。靜態測試既可以由人工進行，充分發揮人的邏輯思維優勢，也可以借助軟件工具自動進行。
　　代碼檢查是一種對程序代碼進行靜態檢查。傳統的代碼檢查是通過人工閱讀代碼的方式，檢查軟件設計的正確性；用人腦模擬程序在計算機中的運行，仔細推敲、校驗和核實程序每一步的執行結果，進而判斷其執行邏輯、控制模型、算法和使用參數與數據的正確性。
　　在實踐中，代碼檢查比動態測試更有效率，能找到更多的缺陷，通常能發現30%～70%的邏輯設計和編碼缺陷。代碼檢查非常耗費時間，而且需要專業知識和經驗的積累。代碼檢查定位在編譯之后和動態測試之前進行，在檢查前，應準備好需求描述文檔、程序設計文檔、程序的源代碼清單、代碼編碼標準和代碼缺陷檢查表等。
代碼檢查可以發現的軟件問題包括：聲明或引用錯誤、函數/方法參數錯誤、語句不可達錯誤、數組越界錯誤、控制流錯誤、界面錯誤和輸入/輸出錯誤等。

　　1、代碼檢查
　　代碼檢查包括桌面檢查、代碼走查和代碼審查等方式，主要檢查代碼和設計的一致性，代碼對標準地遵循、可讀性，代碼邏輯表達的正確性，代碼結構的合理性等方面；發現違背程序編寫標準的問題，程序中不安全、不明確和模糊的部分，找出程序中不可移植部分、違背程序編程風格的問題，包括變量檢查、命名和類型檢查、程序邏輯檢查、程序語法檢查和程序結構檢查等內容。
下面對代碼檢查的三種具體方式進行介紹。
　　桌面檢查
　　是一種傳統的檢查方法，由程序員檢查自己編寫的程序。程序員在程序通過編譯之后對源代碼代碼進行分析、檢驗，并補充相關的文檔，目的是發現程序中的錯誤。
　　代碼走查
　　代碼走查就是針對代碼，在假想的輸入情況下，逐行的瀏覽代碼，走查代碼中潛在的缺陷并記錄結果的過程。
　　代碼走查以小組會議方式進行，每小組3-5人。與代碼審查不同的是，走查要求與會者扮演計算機的角色讓測試用例沿被測程序的邏輯運行，是在模擬動態測試；而代碼審查更多的是靜態測試。
　　代碼審查
　　代碼審查是由一組人通過閱讀、討論和爭議對程序進行靜態分析的過程，以小組會的方式進行。
　　審查小組一般由若干程序員（包括程序代碼的設計者）和代碼檢查人員組成。會前把設計規格說明書、控制流程圖、程序文本以及要求、規范、錯誤檢查清單交給與會者，開會時程序作者朗讀解釋程序，其他人則集中精力，捕捉程序在結構、功能、編碼風格等方面的問題。
　　2、代碼檢查項
　　代碼檢查項即檢查代碼時，指定需要進行檢查的內容。具體如：檢查變量的交叉引用表；檢查標號的交叉引用表；檢查子程序、宏、函數；等價性檢查；標準檢查；風格檢查；選擇、激活路徑；對照程序的規格說明，詳細閱讀代碼，逐字逐句分析；補充文檔。

　　檢查項可以作為依據，用來編制代碼規則、規范和缺陷檢查表等。
　　3、編碼規范
　　編碼規范是程序編寫過程中必須遵循的一套事先約定或者已經制度化、標準化的規則集，一般會詳細的規定代碼的語法規則和語法格式。
　　一個良好的編碼規范能夠帶來許多好處：改善代碼質量；提高開發進度；增進團隊精神。對于軟件開發而言，采用好的編程規范，雖然不能徹底杜絕糟糕的代碼產生。但對于代碼檢查和將來的代碼維護，仍然是意義重大的。
　　4、缺陷檢查表
　　在進行人工代碼檢查時，使用代碼缺陷檢查表作為代碼檢查的參考依據。在軟件測試項目實踐中代碼缺陷檢查表又常被稱作代碼檢查清單。
　　代碼缺陷檢查表中一般包括開發人員容易出錯的地方和在以往的工作中遇到的典型錯誤。對應于不同的編程語言，代碼缺陷檢查表的具體內容將會有所不同。例如：對于C/C++語言代碼缺陷檢查表內容有以下幾部分：文件結構；文件的版式；命名規則；表達式與基本語句；常量；函數設計；內存管理；C++函數的高級特性；類的構造函數、析構函數和賦值函數；類的高級特性；其他的常見問題等。
　　5、代碼檢查規則
　　在代碼檢查中，需要依據被測軟件的特點，選用適當的標準與規范。在使用測試軟件進行自動化代碼檢查或輔助代碼檢查時，測試工具需要內置許多編碼規范。不同編程語言，對應的檢查規范有所不同。針對與C/C++語言的規則有以下幾類規則：通用規則、C++編碼規則、C編碼規則、Meyers-Klaus規則以及自定義規則。使用時，需要根據編程語言和被測程序的特點，選擇適當的規則進行檢查。
　　6、靜態分析
　　靜態分析是不執行程序，而分析程序代碼的過程。源代碼被靜態分析器分析之后，得到的靜態分析結果，通常可以表示成一棵靜態語法樹。其中包含了被測項目源代碼的靜態結構信息：基本代碼成分、程序結構、語句結構、類型和模板等信息。
程序代碼靜態分析的結果能夠給代碼檢查提供幫助。

　　三、 代碼檢查過程
　　傳統的代碼檢查是一種靜態檢查程序的測試方法，通常以團隊的形式來進行。檢查團隊由程序作者，一個負責人，一個記錄員以及一些檢查員組成。首先需要一系列的準備工作，包括參與者的挑選和材料的準備。然后是個人準備階段，每個小組成員各自熟悉材料。個人準備階段后，就是實際的檢查會議。在會議上，檢查小組在假想的輸入下，由程序作者帶領，逐行的瀏覽代碼，評審代碼中潛在的缺陷。檢查小組根據發現缺陷的嚴重程度和類型對其進行分類，并將問題記錄下來供作者修正。會議后是作者的返工，作者匯報每個缺陷，最后確認每個缺陷已經被陳述過了。圖 11為傳統的代碼檢查過程。

　　圖 1  代碼檢查過程示意圖
　　代碼檢查過程中的兩個重要階段“個人準備”和“召開會議”階段有以下注意事項：
　　1、“個人準備”階段：
　　會前準備階段是檢查過程的一個關鍵階段，因為如果檢查者沒有為檢查做好充分的準備，檢查效果會大打折扣。如果有檢查人員沒有做好準備，主審員可取消其代碼檢查資格，甚至取消這次檢查會議。
　　檢查人員要熟悉檢查內容的相關文檔，了解程序背景、設計思想和編程方法，在讀懂、“吃”透代碼的基礎上，查出盡可能多的錯誤。
　　2、“召開會議”階段：
　　參與會議的檢查者應具有一定的專業技能和經驗，缺乏經驗的檢查人員必然缺乏合適的領域知識來深入理解材料；
　　參與會議的檢查者應做充分的個人準備，沒有做充分準備的檢查人員不能在檢查會中做出實質性的貢獻；
　　檢查會議的速度應進行控制，如果試圖在短時間內處理太多的材料，檢查效果也會大打折扣。現在較為常見的代碼檢查速度上的建議為：匯編代碼150行/小時，C語言150行/小時，而對于C++、Java這種面向對象語言，代碼檢查速度可以提高到200-300行/小時。
　　由此可見，代碼檢查適合于采用工具輔助的特性有：文檔處理，個人準備，會議支持，數據收集。
　　文檔處理
　　這是工具可支持的最明顯的領域。傳統的檢查要求分發每份文檔的復印件等，而將紙質的文檔替換成計算機式的文檔，不只是簡單的介質變更，更是提供了一種契機——提高文檔的可用性和表示性的機遇。
　　個人準備
　　首先，自動的缺陷檢測可以用來發現簡單的缺陷。如果簡單問題能被自動發現，檢查員就能專注于更加復雜/困難的缺陷，以及那些不能被自動發現的、潛在的、可能帶來更大影響的問題。另外，自動化工具應該對個人準備階段提供更多的幫助。例如，檢查員可以利用檢查表以及其它支持文檔，并能很容易地交叉引用它們；還有些代碼輔助理解工具，可為檢查員理解程序、了解程序結構提供幫助。
? 會議支持
　　一些成員由于某些原因，可能沒有花費足夠的時間來進行準備，但他們仍然參加會議并試圖掩蓋他們的過失。項目管理人員可以使用計算機監控的個人準備時間信息，來剔除那些沒有做好個人準備的成員，或者督促他們投入更多的努力。
召開會議時，檢查員通常面對的是一堆枯燥的程序代碼，如果在代碼之外再結合一些圖、表等便于分析、理解代碼的信息，相信檢查會議可以進行得更加有序和高效。
　　數據收集
　　代碼檢查一個重要的部分就是度量信息的收集，用來提供反饋以改進檢查過程。度量信息包括會議時間、發現的缺陷、檢查花費的總時間等。根據這些數據，可以來評價每一次代碼審查的質量，進而給出關于代碼審查的改進建議。
通過對檢查過程的部分階段提供計算機支持，代碼檢查可以進行得更加有效。使用計算機來支持檢查過程，可以提高效率，并增加檢查過程的嚴格性。

　　四、 代碼檢查歷史數據
　　代碼檢查中的歷史數據本質是軟件問題（缺陷）。按照不同的代碼檢查角度，存在多種對缺陷分類的方法。對過往發現的軟件問題進行分析，總結出今后對于類似的代碼需要按照某種規則來加以檢查，這種的規則就是檢查清單上的一條清單項，代碼檢查清單就是大量規則的集合。此外，由于軟件問題總是以軟件問題報告為載體形式出現，因此軟件問題報告也被通俗的理解為代碼檢查歷史數據。
　　下面對缺陷分類、代碼檢查清單和軟件問題報告加以研究。
　　1、缺陷分類
　　關于缺陷分類存在以下幾種常見的劃分方式：
　　1）按缺陷出現的區域分類
　　這種分類方式是最常見的缺陷分類方式。按照出現區域將代碼缺陷劃分為變量級、屬性級、函數/方法級和類級缺陷。其中，變量級、屬性級和部分函數/方法級的缺陷，與傳統的面向過程編程中的缺陷分類基本一致；而多數方法級缺陷和類級缺陷，則是針對面向對象技術編程特點提出的。
　　2）按檢測內容分類
　　分為沖突、一致性問題兩種。
　　沖突對應于文獻[1]中的基于確定性“信念”的判定，而一致性問題則對應于基于可能性“信念”的判定。
　　3）按對代碼的危害分類
　　按照對代碼的危害，一般分為浪費時間和空間；語義混淆；暴露封裝性，擴大使用權限；程序一致性問題；程序約束條件問題和空指針問題等。
　　2、代碼檢查清單（Checklist）
　　代碼檢查過程中，代碼檢查人員都會有一份代碼檢查清單。代碼檢查清單是一份為代碼檢查人員準備的缺陷檢查表，檢查表中開列所有可能與代碼有關的缺陷，并注明了檢查的內容、缺陷類型以及嚴重性。檢查清單是檢查代碼的依據，代碼檢查人員根據它來發現并判斷問題。
代碼檢查清單中會逐條列出所有應該檢查的缺陷種類，以及每條缺陷的各種特征，并且根據缺陷的嚴重程度和類型對其進行分類。通常每一條缺陷的特征描述如下：

　　1）缺陷描述：該缺陷的問題描述、舉例說明，以及相應的正確形式；

　　2）缺陷出現的區域：分別為表達式級、語句級、聲明級、模板缺陷、預處理缺陷、類級缺陷以及性能缺陷。表達式級、語句級、聲明級以及預處理的缺陷，主要面向過程程序中的缺陷；模板缺陷、類級缺陷，則是針對面向對象軟件的特點提出的；代碼冗余等歸為性能缺陷；
　　3）缺陷對代碼的危害：代碼中出現某種缺陷將會造成什么樣的影響。
　　例如，檢查表中一條缺陷的特征描述如下：
　　問題描述：指針所指內存釋放后沒有將指針賦為NULL。
　　舉例說明：

　　正確形式：在釋放內存的同時將指針置空。

　　出現區域：語句級。
　　危害：指針被free釋放后其地址并不會自動發生改變（非NULL），p成為了“野”指針，這種情況下再對p進行操作，很容易造成程序崩潰，后果非常嚴重。
而代碼檢查清單正是由若干條這樣的缺陷特征描述構成的。
　　3、軟件問題報告（Software Problem Report）
　　在軟件測試過程中，對于發現的每個軟件問題（缺陷），都要進行記錄該錯誤的特征和再現步驟等信息，以便相關人員分析和處理軟件問題。為了管理測試發現的軟件問題，通常要采用軟件問題報告數據庫，將每一個發現的軟件問題輸入到軟件問題報告數據庫中，軟件問題報告數據庫的每一條記錄稱為一個軟件問題報告。
　　軟件問題報告包括頭信息、簡述、操作步驟和注釋。
　　頭信息包括：被測試軟件名稱、版本號、缺陷或錯誤類型、可重復性、測試平臺、平臺語言、缺陷或錯誤范圍。并要求填寫完整和準確。
　　簡述是對缺陷或錯誤特征的簡單描述，可以使用短語或短句，要求簡練和準確。
　　操作步驟是描述該缺陷或錯誤出現的操作順序，要求完整、簡潔和準確。對命令、系統變量、選項要用大寫字母，對控件名稱等要加雙引號。
　　注釋一般是對缺陷或錯誤的附加描述，一般包括缺陷或錯誤現象的圖像，包括其他建議或注釋文字。
　　軟件問題報告是軟件測試過程中最重要的文檔之一。它記錄了軟件問題發生的環境，軟件問題的再現步驟以及性質的說明，而且還可以跟蹤軟件問題的處理過程和狀態。軟件問題的處理進程從一定角度反映了測試的進程和被測軟件的質量狀況及改善過程。
　　五、 代碼檢查規則管理的研究
　　1、潛在的編碼規則和缺陷代碼模式
　　潛在的編碼規則（Implicit Coding Rules）和缺陷代碼模式（Bug Code Pattern）是Tomoko MATSUMURA在文獻[3,4]中針對代碼檢查實踐，提出的兩個相關的概念。
　　潛在的編碼規則
　　潛在的編碼規則包含以下幾個特征：
　　1）不同于在開發啟動時明確決定的“編碼規范”的規則，這些規則在長期的測試/維護過程中是潛伏的，對這些規則的發現是不可預見的。

　　2）這些規則很少在設計文檔或者特定的文檔中被清楚的描述。他們通常只存在于開發人員、測試/維護人員的記憶中。換言之，是一種尚未系統化的經驗積累和總結的結果。
　　3）不同于使用規范庫的公用規則。對于特定的軟件有其特定的規則，這也意味著對于不同的軟件有不同的潛在的編碼規則。
　　4）由于違反潛在的編碼規則導致的缺陷通常情況下不是那么容易發現的。其中相當多一部分只在特定的罕見的情況下發生，所以在早期要想發現這些問題是很困難的。
　　5）目前，還不存在好的工具或者檢查清單來發現違反潛在的編碼規則的代碼片段，通常的檢查工具（例如PC-Lint、Purify）和通用的檢查清單只能發現常見的問題。
　　6）為了減少違反潛在的編碼規則的現象的發生，而進行重構通常很困難。要重構一個軟件，準確理解代碼是非常必要的，然而，老的系統太復雜，并且沒有精確的文檔和了　　解系統的專業維護人員。總之，重構過期系統的代價很大，需要冒很大的風險。
　　缺陷代碼模式：違反潛在的編碼規則的編碼模式。
　　缺陷代碼模式不是肯定會導致缺陷的發生，一段符合缺陷代碼模式的代碼片段，并不意味著代碼片段一定就有缺陷，缺陷代碼模式只是疑似存在缺陷。另一方面，因為缺陷代碼模式是靜態的，沒有考慮到代碼片段之間的動態關聯。需要代碼檢查人員或者維護人員把符合缺陷代碼模式的代碼片段提出來，并判斷究竟是否存在缺陷。
　　在軟件開發過程中發現和建立缺陷代碼模式有三條主要途徑。其一：在進行代碼檢查過程中，代碼檢查人員發現一個軟件問題的同時，根據對該問題是否具備代表性和通用性等因素的考慮，確定是否建立一個缺陷代碼模式；其二：當軟件失效或者發生問題，檢查對應的代碼部分，發現并確定是否有潛在的編碼規范與之相關；其三：分析現存的代碼規范和積累的大量問題報告，從中提煉出潛在的編碼規則。
　　在文獻[3,4]中還給我們介紹了一個代碼缺陷檢測系統的大致工作流程，如2所示。

　　圖2  缺陷檢測模型系統的代碼檢查流程參考圖

　　2、C++代碼檢查規則類型
　　1）規則層次
　　在代碼檢查工作中常常可以發現這樣的現象：有些規則能在所有的項目中都能發現問題，另一些規則所能發現的問題只存在于某類項目中。
　　根據規則的這個特點，如圖 33中所示，參考文獻[2]中將代碼檢查規則分為兩個層次：
　　公共規則（General checks）：用于檢查在大多數情況都有可能發生的缺陷。
　　項目相關規則（Project specific checks）：用于在項目中檢查可能的缺陷。

　　圖 3  一個典型的代碼檢查規則清單節選圖
　　在項目中積累了大量軟件問題報告歷史數據的支持下，可以從中進一步細化出與項目或開發人員相關的檢查規則。
　　在學習任何一種計算機編程語言時，總是按照基本數據類型－>表達式－>語句－>復雜語句－>函數－>整個程序體(類)的順序逐步學習的。事實上軟件正是按照這樣的順序自下而上逐層組建起來的，代碼缺陷作為軟件編程寫時的一種異常情況，毫不例外也是按照這樣層次的構建而成。在實際測試項目的代碼檢查過程中，我們發現在每個層次上都有可能存在潛在代碼缺陷，要找到引起軟件問題的根源，要求在盡可能低的層次上找到引發缺陷的代碼。正因如此，非常有必要在C++語法的每個層次上都建立相應的檢查元規則。
　　圖4為一個代碼檢查規則體系模型圖[2]，圖中展示了在代碼檢查項目開始前，通過逐級組合各種元規則和規則形成新的檢查規則，最后形成了初始的檢查清單。在項目實踐中，經過對缺陷代碼模式的推導，進而得到擴展的檢查清單。初始檢查清單和擴展檢查清單本質上并沒有什么區別，只是因為形成的時間不同。

　　圖4  代碼檢查規則體系模型圖
　　在檢查代碼時我們有時會想要定義一個帶有否定意義的規則，如“在AA情況下如果沒有BB，則可能存在一個問題”。這類檢查規則采用自然語言描述比較容易，但是要用代碼實現起來往往并不簡單，并且對這類規則的定義和維護也比較麻煩。定義組合規則，是解決這類問題一種變通的方法。
　　下面簡單介紹一下定義組合規則的原理。如圖5中所示定義三個規則，“滿足情況AA”對應規則R1，“滿足在AA情況下出現BB”對應規則R2， 將滿足R1但不滿足R2（即以！符號表示）組合則對應規則R3－“在AA情況下如果沒有BB，則可能存在一個問題”。

　　圖5  組合規則示例圖
　　根據前面討論，本文將代碼檢查的規則分類設計如下：
? 公共規則
　　定義針對函數體（含）以上層次的檢查規則，在這些層次上出現的缺陷問題一般不容易精確到具體的代碼行。
? 關鍵字規則
　　針對每個關鍵字定義的檢查規則。由于關鍵字是C++語法中一種最普通的元素，單獨使用關鍵字規則的意義不大，一般情況需要和語句、表達式規則或者復雜語句規則配合使用。
? 語句/表達式規則
　　針對基本語句類型或基本表達式定義的規則，滿足對應結構的表達式，則可認為符合了相應的表達式規則。語句/表達式規則中可以包含多個關鍵字，在同一語句/表達式規則中包含的關鍵字地位是平等的，與檢查的先后次序無關。
? 復雜語句塊規則
　　針對條件、開關選擇等多分支語句定義的規則，通常由關鍵字、語句/表達式進行組合來定義復雜語句塊，并在定義時可以進行嵌套，在定義復雜語句塊規則加入語句或表達式和復雜語句時需要考慮檢查的先后次序。
? 高級組合規則
　　關鍵字規則、語句/表達式規則和復雜語句塊規則合稱為普通規則。
　　對于難以使用普通規則定義方式定義的復雜語義，需要定義高級組合規則。定義高級組合規則可以使用上面幾種規則作為基本單元，也可以嵌套使用其它組合規則。

　　圖6為一個由下至上、由多個缺陷代碼模式組合形成的組合規則結構圖。其中{}表示某條缺陷代碼模式對應的規則。

　　圖6  組合規則結構圖
　　六、 代碼分析方法
　　1、靜態分析
　　靜態分析主要對源代碼進行詞法分析、語法分析，提取被分析程序的靜態信息，所提取的靜態信息是代碼缺陷檢測的基礎。靜態分析結果主要包括三部分信息：
　　程序定義信息：程序定義信息包含了程序中所有的定義和聲明信息，如類定義、方法和數據成員的定義、方法內局部變量的定義等。
　　程序結構信息：主要指方法內的控制流信息和方法間的調用關系。靜態分析器分析程序的語句分支、分支間的嵌套關系和方法調用，記錄方法的控制流信息和調用信息，構造語法樹。
　　分支內的變量操作：以方法控制流程中的分支為基本單元，記錄每一分支中各語句對各變量施加的操作和操作序列。
　　2、數據流分析
　　數據流分析也是一種靜態代碼檢查方法。它是在不通過計算機運行被測程序的條件下，利用預先進行靜態分析后獲取的信息，檢測對變量的賦值與使用操作中，是否存在不合理情況，即找出被測程序中是否存在變量在使用前未被賦值；變量在兩次賦值之間未被使用；一個變量在被賦值后是否未被使用等異常情況。
數據流分析目前的主要用途大多局限在編譯器的實現和優化技術方面，而在代碼檢查系統中實用的數據流分析技術并不多見，主要集中在某幾種缺陷檢測上，如賦值引用異常檢測以及內存錯誤檢測，使用方式主要是定義數據流操作的符號，使用該符號系統構造數據流表達式（由數據操作符號構成的符號串），再分析該符號串來確定是否存在代碼缺陷。
　　數據流分析包括以下兩個步驟：一是分析程序的所有邏輯路徑；二是對所有邏輯路徑上的所有變量，分析其所有操作序列，然后將得到的操作序列輸入自動機進行分析。因此數據流分析方法不可避免的存在以下缺點：
　　1）信息量多，上面所述的數據流分析方法是一種窮舉法。事實上一個變量在大部分路徑上存在問題的幾率并不高，因此窮舉每個變量的所有操作序列不可避免的要分析很多正確的信息，而且信息量巨大；
　　2）組合爆炸，當程序復雜度增長時，該分析方法的復雜度呈幾何級數增長，并且當這種組合是建立在對所有邏輯路徑、所有變量的窮舉基礎上時，如果不能找到一個非常高效的算法，數據流分析方法將是一個非常低效的方法；
　　3）實用性低，上述兩點導致的數據流分析的實用性降低。
　　為緩解這些的缺點，數據流分析過程有許多改進方法，但實現都具有一定難度。本系統中數據流分析不是重點，采取的策略是盡可能簡化數據流分析的過程，或者在可能的情況下盡量避免數據流分析。