第6章 檢查代碼
一、靜態白盒測試：檢查設計和代碼
靜態白盒測試是在不執行軟件的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時稱爲結構化分析。進行靜態白盒測試的首要原因是儘早發現軟件缺陷，以找出動態黑盒測試難以發現或隔離的軟件缺陷。進行靜態白盒測試的另外一個好處是，爲黑盒測試員在接受軟件進行測試時設計和應用測試用例提供思路。
二、正式審查
正式審查就是進行靜態白盒測試的過程。
正式審查有4個基本要素：
1、 確定問題。審查的目的是找出軟件的問題——不僅是出錯的項目，還包括遺漏項目。
2、 遵守規則。審查要遵守一套固定的規則，規則可能設定要審查的代碼量，花費多少時間，哪些內容要做評價等。
3、 準備。每一個參與者都爲審查做準備，並儘自己的力量。在審查過程中找出的問題大部分是在準備期間發現的，而不是實際審查期間。
4、 編寫報告。審查小組必須做出審查結果的書面總結報告，並使報告便於開發小組的成員使用。
進行正式審查要按照已經建立起來的過程執行。如果審查正確地進行，就可以證明這是早期發現軟件缺陷的好方法。
除了發現問題，堅持正式審查還有一些間接效果：
1、 交流。正式報告中未包含的信息得以交流。
2、 質量。程序員的代碼經過逐個功能、逐行代碼仔細複查，常常會使程序員變得更加仔細。
3、 小組同志化。如果審查正確進行，就會建立軟件測試員和程序員對雙方技藝的相互尊重，並且更好地瞭解相互的工作及需求。
4、 解決方案。儘管是否討論解決方案取決於審查的規則，但是解決方案應該用於處理嚴重問題。在審查的範圍之外討論解決方案也許更有效。
正式審查的三種類型：
1、 同事審查
召集小組成員進行初次正式審查最簡單的方法是通過同事審查的方式。同事審查常常僅在編寫代碼或設計體系結構的程序員，以及充當審查者的其他一兩個程序員和測試員之間進行。
2、 走查
走查是比同事審查更正規化的下一步。走查中編寫代碼的程序員像5人小組或其他的程序員和測試員組成的小組做正式表述。審查人員應該在審查之前接到軟件拷貝，以便檢查並編寫備註和問題，在審查過程中提問。審查人員之中至少有一位資深程序員是很重要的。
3、 檢驗
檢驗是最正式的審查類型，具有高度組織化，要求每一個參與者都接受訓練。檢驗與同事審查和走查的不同之處在於表述代碼的人不是原來的程序員。這就迫使他學習和了解要表述的材料，從而有可能在檢驗會議上提出不同的看法和解釋。
其餘的參與者稱爲檢驗員，其職責是從不同的角度，例如用戶、測試員或者產品支持人員的角度審查代碼。這有助於從不同視角來審查產品，通常可以指出不同的軟件缺陷。檢查員甚至要擔負着倒過來審查代碼的責任確保材料的徹底和完整。
三、編碼標準和規範
堅持標準和規範的三個重要的原因：
1、 可靠性。事實證明按照某種標準或規範編寫的代碼比不這樣做的代碼更加可靠和安全。
2、 可讀性/維護性。符合設備標準和規範的代碼易於閱讀、理解和維護。
3、 移植性。代碼經常需要在不同的硬件中運行，或者使用不同的編譯器編譯。如果代碼符合設備標準，遷移到另一個平臺就會輕而易舉，甚至完全沒有障礙。
標準由4個主要部分組成：
1、 標題。描述標準包含的主題。
2、 標準（或者規範）。描述標準或規範內容，解釋哪些允許哪些不允許。
3、 解釋說明。給出標準背後的原因，以使程序員理解這爲什麼這樣作是好的編程習慣。
4、 示例。給出如何使用標準的簡單程序示例。這不是必需的。
四、通用代碼審查清單
1、數據引用錯誤
數據引用錯誤是指使用未經正確聲明和初始化的變量、常量、數組、字符串或記錄而導致的軟件缺陷。
2、 數據聲明錯誤
數據聲明缺陷產生的原因是不正確地聲明或使用變量和常量。
3、 計算錯誤
計算或者運算錯誤實質上是糟糕的數學問題。計算無法得到預期結果。
4、 比較錯誤
小於、大於、等於、不等於、真、假。比較和判斷錯誤很可能是由於邊界條件問題。
5、 控制流程錯誤
控制流程錯誤的原因是編程語言中循環等控制結構未按預期方式工作。它們通常由計算或者比較錯誤直接或間接造成。
6、 子程序參數錯誤
子程序參數錯誤的來源是軟件子程序不正確地傳遞數據。
7、 輸入/輸出錯誤
輸入/輸出錯誤包括文件讀取、接受鍵盤或者鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。
8、 其他檢查
這個壓軸清單定義了一些不適合放在其他類別的條目。如：軟件是否使用其他外語；軟件是否要移植到其他編譯器和CPU，是否具有這樣做的許可；是否考慮了兼容性；程序編譯是否產生“警告”或者“提示”信息等。
五、小結
檢查代碼（靜態白盒測試）被證實是早期發現軟件缺陷最有效的方法。雖然這是一項需要大量準備工作纔能有成效的任務，但是許多研究表明花費的時間與得到的好處相比是值得的。
一、靜態白盒測試：檢查設計和代碼
靜態白盒測試是在不執行軟件的條件下有條理地仔細審查軟件設計、體系結構和代碼，從而找出軟件缺陷的過程，有時稱爲結構化分析。進行靜態白盒測試的首要原因是儘早發現軟件缺陷，以找出動態黑盒測試難以發現或隔離的軟件缺陷。進行靜態白盒測試的另外一個好處是，爲黑盒測試員在接受軟件進行測試時設計和應用測試用例提供思路。
二、正式審查
正式審查就是進行靜態白盒測試的過程。
正式審查有4個基本要素：
1、 確定問題。審查的目的是找出軟件的問題——不僅是出錯的項目，還包括遺漏項目。
2、 遵守規則。審查要遵守一套固定的規則，規則可能設定要審查的代碼量，花費多少時間，哪些內容要做評價等。
3、 準備。每一個參與者都爲審查做準備，並儘自己的力量。在審查過程中找出的問題大部分是在準備期間發現的，而不是實際審查期間。
4、 編寫報告。審查小組必須做出審查結果的書面總結報告，並使報告便於開發小組的成員使用。
進行正式審查要按照已經建立起來的過程執行。如果審查正確地進行，就可以證明這是早期發現軟件缺陷的好方法。
除了發現問題，堅持正式審查還有一些間接效果：
1、 交流。正式報告中未包含的信息得以交流。
2、 質量。程序員的代碼經過逐個功能、逐行代碼仔細複查，常常會使程序員變得更加仔細。
3、 小組同志化。如果審查正確進行，就會建立軟件測試員和程序員對雙方技藝的相互尊重，並且更好地瞭解相互的工作及需求。
4、 解決方案。儘管是否討論解決方案取決於審查的規則，但是解決方案應該用於處理嚴重問題。在審查的範圍之外討論解決方案也許更有效。
正式審查的三種類型：
1、 同事審查
召集小組成員進行初次正式審查最簡單的方法是通過同事審查的方式。同事審查常常僅在編寫代碼或設計體系結構的程序員，以及充當審查者的其他一兩個程序員和測試員之間進行。
2、 走查
走查是比同事審查更正規化的下一步。走查中編寫代碼的程序員像5人小組或其他的程序員和測試員組成的小組做正式表述。審查人員應該在審查之前接到軟件拷貝，以便檢查並編寫備註和問題，在審查過程中提問。審查人員之中至少有一位資深程序員是很重要的。
3、 檢驗
檢驗是最正式的審查類型，具有高度組織化，要求每一個參與者都接受訓練。檢驗與同事審查和走查的不同之處在於表述代碼的人不是原來的程序員。這就迫使他學習和了解要表述的材料，從而有可能在檢驗會議上提出不同的看法和解釋。
其餘的參與者稱爲檢驗員，其職責是從不同的角度，例如用戶、測試員或者產品支持人員的角度審查代碼。這有助於從不同視角來審查產品，通常可以指出不同的軟件缺陷。檢查員甚至要擔負着倒過來審查代碼的責任確保材料的徹底和完整。
三、編碼標準和規範
堅持標準和規範的三個重要的原因：
1、 可靠性。事實證明按照某種標準或規範編寫的代碼比不這樣做的代碼更加可靠和安全。
2、 可讀性/維護性。符合設備標準和規範的代碼易於閱讀、理解和維護。
3、 移植性。代碼經常需要在不同的硬件中運行，或者使用不同的編譯器編譯。如果代碼符合設備標準，遷移到另一個平臺就會輕而易舉，甚至完全沒有障礙。
標準由4個主要部分組成：
1、 標題。描述標準包含的主題。
2、 標準（或者規範）。描述標準或規範內容，解釋哪些允許哪些不允許。
3、 解釋說明。給出標準背後的原因，以使程序員理解這爲什麼這樣作是好的編程習慣。
4、 示例。給出如何使用標準的簡單程序示例。這不是必需的。
四、通用代碼審查清單
1、數據引用錯誤
數據引用錯誤是指使用未經正確聲明和初始化的變量、常量、數組、字符串或記錄而導致的軟件缺陷。
2、 數據聲明錯誤
數據聲明缺陷產生的原因是不正確地聲明或使用變量和常量。
3、 計算錯誤
計算或者運算錯誤實質上是糟糕的數學問題。計算無法得到預期結果。
4、 比較錯誤
小於、大於、等於、不等於、真、假。比較和判斷錯誤很可能是由於邊界條件問題。
5、 控制流程錯誤
控制流程錯誤的原因是編程語言中循環等控制結構未按預期方式工作。它們通常由計算或者比較錯誤直接或間接造成。
6、 子程序參數錯誤
子程序參數錯誤的來源是軟件子程序不正確地傳遞數據。
7、 輸入/輸出錯誤
輸入/輸出錯誤包括文件讀取、接受鍵盤或者鼠標輸入以及向打印機或者屏幕等輸出設備寫入錯誤。
8、 其他檢查
這個壓軸清單定義了一些不適合放在其他類別的條目。如：軟件是否使用其他外語；軟件是否要移植到其他編譯器和CPU，是否具有這樣做的許可；是否考慮了兼容性；程序編譯是否產生“警告”或者“提示”信息等。
五、小結
檢查代碼（靜態白盒測試）被證實是早期發現軟件缺陷最有效的方法。雖然這是一項需要大量準備工作纔能有成效的任務，但是許多研究表明花費的時間與得到的好處相比是值得的。
?
第7章 帶上X光眼鏡測試軟件
一、動態白盒測試
動態白盒測試是指利用查看代碼功能和實現方式得到的信息來確定哪些需要測試、哪些不要測試、如何開展測試。動態白盒測試的另一個常用名稱是結構化測試，因爲軟件測試員可以查看並使用代碼的內部結構，從而設計和執行測試。
動態白盒測試不僅僅是查看代碼的運行情況，還包括直接測試和控制軟件。動態白盒測試包括以下4個部分：
1、 直接測試底層函數、過程、子程序和庫。
2、 以完整程序的方式從頂層測試軟件，但是根據對軟件運行的瞭解調整測試用例。
3、 從軟件獲得讀取變量和狀態信息的訪問權，以便確定測試與預期結果是否相符，同時，強制軟件以正常測試難以實現的方式運行。
4、 估算執行測試時“命中”的代碼量和具體代碼，然後調整測試，去掉多餘的測試用例，補充遺漏的用例。
二、動態白盒測試和調試
這兩項技術表面上很相似，因爲它們都包括處理軟件缺陷和查看代碼的過程，但是它們的目標大不相同。動態白盒測試的目標是尋找軟件缺陷，調試的目標是修復缺陷。
軟件測試員應該把問題縮減爲能夠演示軟件缺陷的最簡化測試用例。如果是白盒測試，甚至還要包括那些值得懷疑的代碼行信息。進行調試的程序員從這裏繼續，判斷到底是什麼導致軟件缺陷，並設法修復。
三、分段測試
從測試的角度看，產生高額費用有如下兩個原因：
a. 難以，有時甚至不可能找出導致問題的原因。
b. 某些軟件缺陷掩蓋了其他軟件缺陷。
1、 單元測試和集成測試
在底層進行的測試稱爲單元測試或者模塊測試。單元經過測試，底層軟件缺陷被找出並修復之後，就集成在一起，對模塊的組合進行集成測試。這個不斷增加的測試過程繼續進行，加入越來越多的軟件片段，直至整個產品（至少是產品的主要部分）在稱爲系統測試的過程中一起測試。
這種遞增測試有兩條途徑：自底向上和自頂向下。
（1） 自底向上
自底向上測試中，要編寫測試驅動模塊，測試驅動模塊以和將來真正模塊同樣的方式掛接，向處於測試的模塊發送測試用例數據，接受返回結果，驗證結果是否正確。採取這種方式，可以對整個軟件進行非常全面的測試，爲它提供全部類型和數量的數據，甚至高層難以發送的數據。
（2） 自頂向下
自頂向下測試有點像小規模的大爆炸測試，先測試高層的軟件，然後測試它們下一層的。
2、 單元測試示例
書中以測試一個把ASCII字符轉換爲整數值的常用函數爲例，說明單元測試的步驟：
（1） 分析該模塊屬於程序中的底層模塊，可以由高層模塊調用，但是自己不能調用其他模塊。合理的做法是編寫一個測試驅動以獨立於程序其他部分的形式測驗該模塊。
（2） 分析說明書，確定應該採用的黑盒測試用例，然後運用等價類劃分技術減少測試用例集合。
（3） 研究代碼看函數是如何實現的，利用模塊的白盒知識增減測試用例。
注意：在進行白盒子測試之前，一定要根據說明書建立黑盒測試用例。用這種方式可以真正測試模塊的功能和作用。如果先從模塊的白盒角度建立測試用例，檢查代碼，就會偏向於以模塊工作方式建立測試用例。程序員或許誤解了說明，於是測試用例就會不對。雖然測試用例精確完整地測試了模塊，但是可能不準確，因爲沒有測試預期的操作。
四、數據覆蓋
像黑盒測試那樣把軟件代碼分成數據和狀態（或者程序流程）。從同樣的角度看軟件，可以相當容易地把得到的白盒信息映射到已經寫完的黑盒測試用例上。
1、 數據流
數據流覆蓋主要是指在軟件中完全跟蹤一批數據。
通過黑盒測試，只能知道變量開始和結束的值。通過動態白盒測試，還可以在程序運行期間檢查變量的中間值。根據觀察結果就可以決定更改某些測試用例，保證變量取得感興趣的、甚至具有風險的中間值。
2、 次邊界
如果進行白盒測試，就需要仔細檢查代碼，找到次邊界條件，並建立能測試它們的測試用例。詢問編寫代碼的程序員是否知道這些條件，並對內部數據表給予特別的注意，因爲這裏聚集了大量次邊界條件。
3、 公式和等式
公式和等式通常深藏於代碼中，從外部看，其形式和影響不是非常明顯。撇開代碼中的公式和等式，查看它們使用的變量，在程序正常輸入和輸出之外，爲其建立測試用例和等價劃分。
4、 錯誤強制
錯誤強制是在調試器中測試的程序，可以強制改變變量的值，藉此執行其他方式難以實現的測試用例。
在使用錯誤強制時，小心不要設置現實世界中不可能出現的情況。如果仔細選擇了錯誤強制情況，並和程序員一起反覆檢查以確認它們是合法的，錯誤強制就是一個有效的工具。
五、代碼覆蓋
與黑盒測試一樣，測試數據只是一半工作。爲了全面地覆蓋，還必須測試程序的狀態以及程序流程，必須設法進入和退出每一個模塊，執行每一行代碼，進入軟件每一條邏輯和決策分支。這種類型的測試叫做代碼覆蓋測試。
書中介紹代碼覆蓋的兩種形式：
（1） 最簡單的形式是利用編譯環境的調試器通過單步執行程序查看代碼。其適用於小程序或單獨模塊。
（2） 對於大多數程序進行代碼覆蓋測試要用到稱爲代碼覆蓋率分析器的專用工具。其掛接在正在測試的軟件中，當執行測試用例時在後臺執行。每當執行一個函數、一行代碼或一個邏輯決策分支時，分析器就記錄相應的信息。從中可以獲得指示軟件哪些部分被執行，哪些部分未被執行的統計結果。
1、 程序語句和代碼行覆蓋
代碼覆蓋最直接的形式稱爲語句覆蓋或代碼行覆蓋。如果在測試軟件的同時監視語句覆蓋，目標就是保證程序中每一條語句最少執行一次。
注意：即使全部語句都被執行了，但是不能說走遍了軟件的所有路徑。
2、 分支覆蓋
試圖覆蓋軟件中的所有路徑稱爲路徑覆蓋。路徑測試最簡單的形式稱爲分支覆蓋測試。
書中以舉例的方式，講述了分支覆蓋，但沒有給出其具體定義，以下是我在網上找到的定義：
分支覆蓋又稱爲判定覆蓋，它要求設計足夠多的測試用例，使得程序中每個判定至少有一次爲真值，有一次爲假值，即：程序中的每個分支至少執行一次。每個判斷的取真、取假至少執行一次。
3、 條件覆蓋
以下是網上找到的定義：
條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次爲真值，有一次爲假值。
書中例子舉的還是很好的，比較容易理解。
在底層進行的測試稱爲單元測試或者模塊測試。單元經過測試，底層軟件缺陷被找出並修復之後，就集成在一起，對模塊的組合進行集成測試。這個不斷增加的測試過程繼續進行，加入越來越多的軟件片段，直至整個產品（至少是產品的主要部分）在稱爲系統測試的過程中一起測試。
這種遞增測試有兩條途徑：自底向上和自頂向下。
（1） 自底向上
自底向上測試中，要編寫測試驅動模塊，測試驅動模塊以和將來真正模塊同樣的方式掛接，向處於測試的模塊發送測試用例數據，接受返回結果，驗證結果是否正確。採取這種方式，可以對整個軟件進行非常全面的測試，爲它提供全部類型和數量的數據，甚至高層難以發送的數據。
（2） 自頂向下
自頂向下測試有點像小規模的大爆炸測試，先測試高層的軟件，然後測試它們下一層的。
2、 單元測試示例
書中以測試一個把ASCII字符轉換爲整數值的常用函數爲例，說明單元測試的步驟：
（1） 分析該模塊屬於程序中的底層模塊，可以由高層模塊調用，但是自己不能調用其他模塊。合理的做法是編寫一個測試驅動以獨立於程序其他部分的形式測驗該模塊。
（2） 分析說明書，確定應該採用的黑盒測試用例，然後運用等價類劃分技術減少測試用例集合。
（3） 研究代碼看函數是如何實現的，利用模塊的白盒知識增減測試用例。
注意：在進行白盒子測試之前，一定要根據說明書建立黑盒測試用例。用這種方式可以真正測試模塊的功能和作用。如果先從模塊的白盒角度建立測試用例，檢查代碼，就會偏向於以模塊工作方式建立測試用例。程序員或許誤解了說明，於是測試用例就會不對。雖然測試用例精確完整地測試了模塊，但是可能不準確，因爲沒有測試預期的操作。
四、數據覆蓋
像黑盒測試那樣把軟件代碼分成數據和狀態（或者程序流程）。從同樣的角度看軟件，可以相當容易地把得到的白盒信息映射到已經寫完的黑盒測試用例上。
1、 數據流
數據流覆蓋主要是指在軟件中完全跟蹤一批數據。
通過黑盒測試，只能知道變量開始和結束的值。通過動態白盒測試，還可以在程序運行期間檢查變量的中間值。根據觀察結果就可以決定更改某些測試用例，保證變量取得感興趣的、甚至具有風險的中間值。
2、 次邊界
如果進行白盒測試，就需要仔細檢查代碼，找到次邊界條件，並建立能測試它們的測試用例。詢問編寫代碼的程序員是否知道這些條件，並對內部數據表給予特別的注意，因爲這裏聚集了大量次邊界條件。
3、 公式和等式
公式和等式通常深藏於代碼中，從外部看，其形式和影響不是非常明顯。撇開代碼中的公式和等式，查看它們使用的變量，在程序正常輸入和輸出之外，爲其建立測試用例和等價劃分。
4、 錯誤強制
錯誤強制是在調試器中測試的程序，可以強制改變變量的值，藉此執行其他方式難以實現的測試用例。
在使用錯誤強制時，小心不要設置現實世界中不可能出現的情況。如果仔細選擇了錯誤強制情況，並和程序員一起反覆檢查以確認它們是合法的，錯誤強制就是一個有效的工具。
五、代碼覆蓋
與黑盒測試一樣，測試數據只是一半工作。爲了全面地覆蓋，還必須測試程序的狀態以及程序流程，必須設法進入和退出每一個模塊，執行每一行代碼，進入軟件每一條邏輯和決策分支。這種類型的測試叫做代碼覆蓋測試。
書中介紹代碼覆蓋的兩種形式：
（1） 最簡單的形式是利用編譯環境的調試器通過單步執行程序查看代碼。其適用於小程序或單獨模塊。
（2） 對於大多數程序進行代碼覆蓋測試要用到稱爲代碼覆蓋率分析器的專用工具。其掛接在正在測試的軟件中，當執行測試用例時在後臺執行。每當執行一個函數、一行代碼或一個邏輯決策分支時，分析器就記錄相應的信息。從中可以獲得指示軟件哪些部分被執行，哪些部分未被執行的統計結果。
1、 程序語句和代碼行覆蓋
代碼覆蓋最直接的形式稱爲語句覆蓋或代碼行覆蓋。如果在測試軟件的同時監視語句覆蓋，目標就是保證程序中每一條語句最少執行一次。
注意：即使全部語句都被執行了，但是不能說走遍了軟件的所有路徑。
2、 分支覆蓋
試圖覆蓋軟件中的所有路徑稱爲路徑覆蓋。路徑測試最簡單的形式稱爲分支覆蓋測試。
書中以舉例的方式，講述了分支覆蓋，但沒有給出其具體定義，以下是我在網上找到的定義：
分支覆蓋又稱爲判定覆蓋，它要求設計足夠多的測試用例，使得程序中每個判定至少有一次爲真值，有一次爲假值，即：程序中的每個分支至少執行一次。每個判斷的取真、取假至少執行一次。
3、 條件覆蓋
以下是網上找到的定義：
條件覆蓋要求設計足夠多的測試用例，使得判定中的每個條件獲得各種可能的結果，即每個條件至少有一次爲真值，有一次爲假值。
書中例子舉的還是很好的，比較容易理解。
在動態分析技術中,最重要的技術是路徑和分支測試。下面介紹的是書中沒有說到的覆蓋測試方法：
（1）判定/條件覆蓋：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。
（2）條件組合覆蓋：要求設計足夠多的測試用例，使得每個判定中條件結果的所有可能組合至少出現一次。
（3）路徑覆蓋：設計足夠的測試用例，覆蓋程序中所有可能的路徑。
（1）判定/條件覆蓋：設計足夠多的測試用例，使得判定中每個條件的所有可能結果至少出現一次，每個判定本身所有可能結果也至少出現一次。
（2）條件組合覆蓋：要求設計足夠多的測試用例，使得每個判定中條件結果的所有可能組合至少出現一次。
（3）路徑覆蓋：設計足夠的測試用例，覆蓋程序中所有可能的路徑。
六、小結
以上第4-7章是本書的第二部分，講述了軟件測試的基礎：
1、 靜態黑盒測試是指檢查產品說明書，並在軟件編寫之前找出問題。
2、 動態黑盒測試是指在不瞭解軟件如何工作的前提下進行測試。
3、 靜態白盒測試是指通過正式審查和檢驗檢查代碼的細節。
4、 動態白盒測試是指在看到軟件的工作方式時，根據獲得的信息對軟件進行測試。
以上第4-7章是本書的第二部分，講述了軟件測試的基礎：
1、 靜態黑盒測試是指檢查產品說明書，並在軟件編寫之前找出問題。
2、 動態黑盒測試是指在不瞭解軟件如何工作的前提下進行測試。
3、 靜態白盒測試是指通過正式審查和檢驗檢查代碼的細節。
4、 動態白盒測試是指在看到軟件的工作方式時，根據獲得的信息對軟件進行測試。