章六 檢查代碼

章六 檢查代碼

軟體測試不僅僅限于白産品說明書和程式當做黑盒子來對待，如果具有程式設計經驗，即使隻有一點，也可以對軟體的體系結構和代碼進行測試。

在某些行業中，此類驗證不如黑盒測試通用。然而，如果測試軍隊、金融、工業自動化、醫藥類軟體，或者有幸在組織嚴格的開發模式下工作，在代碼的級别驗證産品就是例行公事。

如果在測試軟體的安全問題，那麼這是必須進行的。

一、靜态白盒測試：檢查設計和代碼

靜态測試是指測試非運作部分——檢驗和審查。

白盒（或者稱為透明盒）測試是指通路代碼，能夠檢視和審查。

靜态白盒測試是在不執行軟體的條件下有條理的仔細審查軟體設計、體系結構和代碼、進而找出軟體缺陷的過程，有時稱為結構化分析。

（1）進行靜态白盒測試的首要原因是盡早發現軟體缺陷，以找出動态黑盒測試難以發現或隔離的軟體缺陷。在開發初期讓測試小組集中精力進行軟體設計的審查非常有價值。

（2）進行靜态白盒測試的另外一個好處是，為黑盒測試員在接受軟體進行測試時設計和應用測試用例提供思路。

對于靜态白盒測試最不幸的就是常常不能善始善終。許多小組錯誤地認為這樣耗時太多，費用太高，沒有産出。

二、正式審查

1、正式審查（formal review）：就是進行靜态白盒測試的過程，正式審查的含義很廣，從兩個程式員之間的簡單交談，到軟體設計和代碼的明細、嚴格檢查均屬于此過程。

2、正式審查有4個基本步驟：

（1）确定問題。

審查的目的是找出軟體的問題——不僅是出錯的項目，還包括遺漏項目。

全部的批評應該直指代碼或設計，而不是其設計實作者。

（2）遵守規則。

審查要遵守一套固定的規則，規則可能設定要審查的代碼量（通常有數百行），花費多少時間（數小時），哪些内容要做評價等。

（3）準備。

每一個參與者都為審查做準備，并盡自己的力量。根據審查的類型，參與者可能扮演不同的角色。

（4）編寫報告。

審查小組必須做出審查結果的書面總結報告，并使報告便于開發小組的成員使用。

進行正式審查要按照已經建立起來的過程執行。随意“聚在一起進行代碼審查”是不夠的，實際上還會造成危害。

如果過程随意，就會遺漏軟體缺陷，參與者很可能感覺這樣做是在浪費時間。

如果審查正确地進行，就可以證明這是早期發現軟體缺陷的好方法。

3、除了發現問題，堅持正式審查還有一些間接效果：

（1）交流

正式報告中未包含的資訊得以交流。

（2）品質

程式員的代碼經過逐個功能、逐行代碼仔細複查，常常會使程式員變得更加仔細。

（3）小組同志化

如果審查正确進行，就會建立軟體測試員和程式員對雙方技藝的互相尊重，并且更好地了解互相的工作及需求。

（4）解決方案

盡管是否讨論解決方案取決于審查的規則，但是解決方案應該用于處理嚴重問題。

4、同僚審查

召集小組成員進行初次正式審查最簡單的方法是通過同僚審查的方式，這是要求最低的正式方法，有時稱為夥伴審查。

同僚審查常常僅在編寫代碼或設計體系結構的程式員，以及充當審查者的其它一兩個程式員和測試員之間進行。

5、走查

走查（Walkthrough）是比同僚審查更正規化的下一步。

走查中編寫代碼的程式員向5人小組或者其它程式員和測試員組成的小組做正式陳述。

審查人員應該在審查之前接到軟體拷貝，以便檢查并編寫備注和問題，在審查過程中提問。

審查人員之中至少有一位資深程式員是很重要的。

6、檢驗

檢驗（inspections）是最正式的審查類型，具有高度組織化，要求每一個參與者都接受訓練。

檢驗和同僚審查和走查的不同之處在于表述代碼的人——表述者（presenter）或者宣讀者（reader）——不是原來的程式員。

其餘的參與者稱為檢驗員（inspector），其職責是從不同的角度審查代碼。

有些檢驗員還同時被委任為會議協調員（moderator）和會議記錄員（recorder），以保證檢驗過程遵守規則及審查有效進行。

三、編碼标準和規範

在正式審查中，檢驗員查找代碼中的問題和缺漏，這些是典型的言行不一的軟體缺陷，最佳方式是通過仔細代碼分析發現。

标準是建立起來、經過修補和必須遵守的規則——做什麼和不做什麼。

規範是建議最佳做法、推薦更好的方式。

标準沒有例外情況。

有三個重要的原因要堅持标準或規範：

（1）可靠性

事實證明按照某種标準或規範編寫的代碼比不這樣做的代碼更加可靠和安全。

（2）可讀性/維護性

符合裝置标準和規範的代碼易于閱讀、了解和維護。

（3）移植性

代碼經常需要在不同的硬體中運作，或者使用不同的編譯器編譯。

1、程式設計标準和規範示例

标準由四個主要部分組成：

（1）标題：描述标準包含的主題；

（2）标準（或者規範）：描述标準或規範内容，解釋哪些允許哪些不允許；

（3）解釋說明：給出标準背後的原因；

（4）示例；給出如何使用标準的簡單程式示例。

2、風格

有标準，有規範，然後就有風格。從軟體品質和測試的角度看，風格不是問題。

風格是代碼的外表和感覺。

風格的差異不是軟體缺陷。

3、擷取标準

可從以下獲得計算機的标準：

四、通用代碼審查清單

這些清單将代碼與标準或規範比較，確定代碼符合項目的設計要求。

1、資料引用錯誤：是指未經正确聲明和初始化的變量、常量、數組、字元串或記錄而導緻的軟體缺陷。

注意：資料引用錯誤是緩沖區溢出的主要原因——一個造成許多軟體安全問題的缺陷。

2、資料聲明錯誤：其産生的原因是不正确地聲明或使用變量和常量。

3、計算錯誤：實質上是糟糕的數學問題。

4、比較錯誤

小于、大于、等于、不等于、真、假。比較和判斷錯誤很可能是由于邊界條件問題。

5、控制流程錯誤

控制流程錯誤的原因是程式設計語言中循環等控制結構未按預期方式工作，它們通常由計算或者比較錯誤直接或間接造成。

6、子程式參數錯誤

來源是軟體子程式不正确的傳遞資料。

7、輸入/輸出錯誤

包括檔案讀取、接受鍵盤或者滑鼠輸入以及向列印機或者螢幕等輸出裝置寫入錯誤。

8、其它檢查

軟體的擴充字元？編碼？是否移植？相容性？警告/提示資訊？

五、小結

檢查代碼——靜态白盒測試——被證明是早期發現軟體缺陷最有效的方法。

現在有很多能自動執行大量靜态白盒測試工作的商業軟體，即靜态分析程式。

該程式讀入程式的源檔案，并根據公開标準和自定義規範進行檢查。

編譯器也提高了能力，如果啟用所有等級的錯誤檢查，它将捕捉到前面通用代碼審查清單列出的許多問題，有些編譯器甚至不允許使用具有安全問題的函數。