單元測試細節(2)

　　不可覆蓋的語句或條件，一般屬于冗余代碼，建議刪除。不可覆蓋的分支或路徑，則在邏輯結構圖中打上刪除標識，這種刪除不會影響代碼。

　　有讀者會問，如果幾百上千條路徑，要一條一條識別它能不能覆蓋，那可能嗎?這種擔心是不必要的。只要按照語句覆蓋、條件覆蓋、分支覆蓋、路徑覆蓋的順 序來完成邏輯覆蓋，工作量通常都很小，原因是可確認的不可覆蓋的路徑會自動剔除。例如，如果一條分支不可覆蓋，那么所有“經過”這條分支的路徑也肯定不可 覆蓋，把一條分支刪除了，所有“經過”該分支的路徑都會自動刪除，所以，在完成語句、條件、分支覆蓋后(包括把不可覆蓋的分支刪除)，路徑數量就不會是龐 大的了，未覆蓋路徑則更少。

　　對于復雜的程序，還可以在邏輯結構圖中屏蔽一些安全的分支結構。有一些代碼形成的分支結構，對其后的程序的邏輯并無影響。例如：

　　void Find(CString& str, char ch, int start=0, int end=-1)

　　{

　　if(end == -1)

　　end = str.GetLength();

　　......

　　}

　　上列的if結構形成的分支結構只用于處理缺省值參數，對后面的代碼邏輯無影響，因此是安全的。在邏輯結構圖中，與一個復雜的分支結構并列的一個或多個簡單 的分支結構，通常都是安全的，可以在邏輯結構圖中查看各個分支結構對應的代碼以判斷該分支結構是否安全。安全的分支結構可以屏蔽，以便把注意力集中到值得 關注的部分。屏蔽安全的分支結構也會使路徑的數量大幅度減少。前面所說的人民幣小寫轉大小的程序，在刪除了不可覆蓋分支，屏蔽了安全的分支結構后，路徑只 剩下不到十條，與等價類的數量是接近的。

　　邊界測試

　　在測試用例部分已經說過，設計測試用例時要考慮邊界輸入和非法輸入，這里統稱為特殊輸入，程序員在編寫代碼時也要考慮特殊輸入，要為特殊輸入編寫處理代 碼。在實際工作中，程序員沒有考慮到某些特殊輸入是很常見的，這也是程序錯誤的一個重要來源。不幸的是，如果編寫代碼和建立測試用例時都沒有考慮這些輸 入，那么白盒覆蓋也不能自動發現，因為白盒覆蓋是以代碼為基礎的，如果相應的代碼根本不存在，白盒覆蓋當然不會告訴用戶“某某代碼未覆蓋”。

　　特殊輸入通常與數據類型有關，例如，如果一個參數是指針，空指針就是一個特殊輸入，對于一個整數類型，最大值、最小值、0、1、-1都可以算是特殊輸 入;另一方面，當輸入特殊數據時，如果程序未作合適的處理，運行結果常常是產生異常。根據這兩個條件，如果預先為各個數據類型定義特殊值，然后由測試工具 自動生成測試用例，使用這些特殊值或其組合作為輸入數據進行測試，通?？梢园l現“未處理特殊輸入”而產生的程序錯誤，這就是邊界測試。

　　如果在邊界測試中發現了處理某些特殊輸入的代碼缺失，應補充這些代碼，并完成白盒覆蓋。

　　為了進一步說明測試完整性，舉個例子：假如一個函數，大概有十個等價類，但這個數字并不是顯式的，測試人員比較容易想到的，可能只有五個，自己畫一下邏輯 結構圖，做一些代碼分析，也許又可以找到二三個，是不是齊全了呢?很難衡量。使用VU，設計測試用例的過程大體是這樣的：用戶為容易想到的五個等價類建立 測試用例，根據語句、條件、分支覆蓋，在測試用例設計器的幫助下，找到另兩個等價類，根據路徑覆蓋，又揪出了兩個很隱秘的等價類，實現了100%語句、條 件、分支、路徑覆蓋，最后，邊界測試又發現了一個意料之外的等價類。當然，這些數字只是一個示意，實現某某覆蓋的目的，并不在于覆蓋率，而在于盡可能找出 所有等價類。

　　如果針對代碼單元的測試完成了100%語句、條件、分支、路徑覆蓋，并且執行了邊界測試，雖然仍然不能證明所有的等價類都測試到了，但可以肯定的說， 已經達到了很高的測試完整性，局部代碼中仍然含有錯誤的可能性很小，當然，設計上的錯誤除外，這不屬于單元測試的范疇。

　　回歸測試

　　在修改了代碼后，可以使用回歸測試，對選定的任何類或整個工程執行測試，以檢測修改是否破壞了現有代碼的功能。一般來說，修改了私有函數，要運行整個類的測試，修改了公有或保護函數，則要運行整個工程的測試。

原文轉自：http://www.kjueaiud.com