測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求。
測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。
隨著中國軟件業的日益壯大和逐步走向成熟，軟件測試也在不斷發展。從最初的由軟件編程人員兼職測試到軟件公司組建獨立專職測試部門。測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。
要使最終用戶對軟件感到滿意,最有力的舉措就是對最終用戶的期望加以明確闡述，以便對這些期望進行核實并確認其有效性。測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式并由不同的測試員來實施。例如，執行軟件以便驗證它的功能和性能，這項操作可能由某個測試員采用自動測試技術來實現；計算機系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。
既然可能無法（或不必負責）核實所有的需求，那么是否能為測試挑選最適合或最關鍵的需求則關系到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。
確定測試用例之所以很重要，原因有以下幾方面。
測試用例構成了設計和制定測試過程的基礎。 測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 測試設計和開發的類型以及所需的資源主要都受控于測試用例。 測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：
·一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； ·另一個測試用例反映某個無法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
前段時間公司進行有關測試的培訓，集成測試，性能測試，壓力測試說了很多。由于本人還處于Coder階段，只是對單元測試有了些了解。寫下來怕以后自己忘記了。都是些自己的看法，不一定準確，歡迎高手指教。
一、 單元測試的概念
單元通俗的說就是指一個實現簡單功能的函數。單元測試就是只用一組特定的輸入(測試用例)測試函數是否功能正常，并且返回了正確的輸出。
測試的覆蓋種類
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;
代碼：
| 1 int Test(int i_count, int i_flag) 2 { 3 int i_temp = 0; 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_flag=0，或者是i_flag<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=0;假如開發人員一不小心寫錯了，變成了int i_temp=1;根據程序導出的預期結果就會是一個錯誤的值，但是單元測試不出來問題。
那單元測試就失去了意義。
有人也許會問這么簡單的函數就有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都可以。
接下來根據測試結果編寫測試報告，測試人，時間，結果，用例，是否通過，格式網上一大把，每個公司的格式也不一樣就不說了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
