如何設計單元測試用例
一、 單元測試的概念
單元通俗的說就是指一個實現簡單功能的函數。單元測試就是只用一組特定的輸入(測試用例)測試函數是否功能正常，並且返回了正確的輸出。
測試的覆蓋種類
1.語句覆蓋：語句覆蓋就是設計若幹個測試用例，運行被測試程序，使得每一條可執行語句至少執行一次。
2.判定覆蓋（也叫分支覆蓋）：設計若幹個測試用例，運行所測程序，使程序中每個判斷的取真分支和取假分支至少執行一次。
3.條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次。
4.判定——條件覆蓋：設計足夠的測試用例，運行所測程序，使程序中每個判斷的每個條件的每個可能取值至少執行一次，並且每個可能的判斷結果也至少執行一次。
5.條件組合測試：設計足夠的測試用例，運行所測程序，使程序中每個判斷的所有條件取值組合至少執行一次。
6.路徑測試：設計足夠的測試用例，運行所測程序，要覆蓋程序中所有可能的路徑。
用例的設計方案主要的有下面幾種：條件測試，基本路徑測試，循環測試。通過上面的方法可以實現測試用例對程序的邏輯覆蓋，和路徑覆蓋。
二、開始測試前的準備
在開始測試時，要先聲明一下，無論你設計多少測試用例，無論你的測試方案多麽完美，都不可能完全100%的發現所有BUG，我們所需要做的是用最少的資源，做最多測試檢查，尋找一個平衡點保證程序的正確性。窮舉測試是不可能的。 所以現在進行單元測試我選用的是現在一般用的比較多的基本路徑測試法。
三、開始測試
基本路徑測試法：設計出的測試用例要保證每一個基本獨立路徑至少要執行一次。
函數說明 ：當i_flag=0；返回 i_count+100
當i_flag=1；返回 i_count *10
否則 返回 i_count *20
輸入參數：int i_count ，
int i_flag
輸出參數： int i_return;
代碼：
2 {
3 int i_temp = 1;
4 while (i_count>0)
5 {
6 if (0 == i_flag)
7 {
8 i_temp = i_count + 100;
9 break;
10 }
11 else
12 {
13 if (1 == i_flag)
14 {
15 i_temp = i_temp * 10;
16 }
17 else
18 {
19 i_temp = i_temp * 20;
20 }
21 }
22 i_count--;
23 }
24 return i_temp;
25 }
1.畫出程序控制流程圖
圖例：
事例程序流程圖：
圈中的數字代表的是語句的行號，也許有人問為什麽選4,6,13,8......作為結點，第2行，第3行為什麽不是結點，因為選擇結點是有規律的。讓我們看程序中；第2行，第3行是按順序執行下來的。直到第4行才出現了循環操作。而2，3行沒有什麽判斷，選擇等分支操作，所以我們把2，3，4全部合並成一個結點。其他的也是照這個規則合並，然後就有了上面的流程圖。
2.計算圈復雜度
有了圖以後我們要知道到底我們有寫多少個測試用例，才能滿足基本路徑測試。
這裏有有了一個新概念——圈復雜度
圈復雜度是一種為程序邏輯復雜性提供定量測試的軟件度量。將該度量用於計算程序的基本獨立路徑數目。為確保所有語句至少執行一次的測試數量的上界。
公式圈復雜度V（G）=E-N+2，E是流圖中邊的數量，N是流圖中結點的數量。
公式圈復雜度V（G）=P+1 ，P是流圖G中判定結點的數量。
通俗的說圈負責度就是判斷單元是不是復雜，是不是好測試的標準。一般來說如果圈復雜度如果大於20就表示這個單元的可測試性不好，太復雜（也許有人覺得無所謂，但是如果你們公司實行了CMMI5的話，對這個是有規定的）。
從圖中我們可以看到，
V（G）=10條邊-8結點+2=4
V（G）=3個判定結點+1=4
上圖的圈復雜圖是4。這個結果對我們來說有什麽意義呢？它表示我們只要最多4個測試用例就可以達到基本路徑覆蓋。
3.導出程序基本路徑。
現在我們知道了起碼要寫4個測試用例，但是怎麽設計這4個測試用例？
導出程序基本路徑，根據程序基本路徑設計測試用例子。
程序基本路徑：基本獨立路徑就是從程序的開始結點到結束可以選擇任何的路徑遍歷，但是每條路徑至少應該包含一條已定義路徑不曾用到的邊。（看起來不好理解，讓我們看例子）。
讓我們看上面的流程圖：從結點4到24有幾條路徑呢？
1 B（4，24）
2 C，E，J（4，6，8，24）
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
還有嗎？？
5 C，D，C，I，A，C，E，J（4，6，13，19，22，4，6，8，24）算嗎？
不算，為什麽？因為上面的4條路徑已經包括了所有的邊。第5條路徑已經不包含沒有用過的邊了。所有的路徑都遍歷過了。
好了，現在我們有了4條基本獨立路徑根據獨立路徑我們可以設計測試用例。
1 B（4，24）
輸入數據：i_count=0，或者是i_count<0的某一個值。
預期結果：i_temp=0.
2 C，E，J（4，6，8，24）
輸入數據： i_count =1;i_flag=0
預期結果：i_temp=101.
3 C，D，F，H，A，B（4，6，13，15，22，4，24）
輸入數據： i_count =1;i_flag=1
預期結果：i_temp=10.
4 C，D，G，I，A，B（4，6，13，19，22，4，24）
輸入數據： i_count =1;i_flag=2
預期結果：i_temp=20.
這裏的輸入數據是由路徑和程序推論出來的。而要註意的是預期結果是從函數說明中導出，不能根據程序結構中導出。
為什麽這麽說？
讓我們看程序中的第3行。
int i_temp=1;假如開發人員一不小心寫錯了，變成了int i_temp=0;根據程序導出的預期結果就會是一個錯誤的值，但是單元測試不出來問題。
那單元測試就失去了意義。
有人也許會問這麽簡單的函數就有4個測試用例，如果還復雜一些的怎麽辦？上面的測試用例還可以簡化嗎？答案是可以。
我們來看 路徑 1 B（4，24）和 4 C，D，G，I，A，B（4，6，13，19，22，4，24），路徑1是路徑4的真子集， 所以1是可以不必要的。上圖的圈復雜度是4。這個結果對我們來說有什麽意義呢？它表示我們只要最多4個測試用例就可以達到基本路徑覆蓋。所以說圈復雜度標示是最多的測試用例個數，不是一定要4個測試用例才可以。不過有一點要申明的是測試用例越簡化代表你的測試越少，這樣程序的安全性就越低了。
四、完成測試
接下來根據測試用例使用工具測試NUNIT，VS2005都可以。
接下來根據測試結果編寫測試報告，測試人，時間，結果，用例，是否通過，格式網上一大把，每個公司的格式也不一樣就不說了。
如何設計單元測試用例