一、為什麽要使用測試用例

1、理清思路，避免遺漏

如果我們測試的項目大而復雜，我們可以把項目功能細分，根據每一個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。

2、跟蹤測試進展

通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度。

3、歷史參考

在我們所做的項目中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。

4、重復性

我們測試一個系統不是一個人測一遍就算測完的，需要多人反復的進行測試，那麽我們就需要測試用例來規範和指導我們的測試行為。

5、測試確認

在少數高風險的測試中，必須證明確實執行了計劃執行的測試。

二、測試用例-要素

1、用例編號

測試用例的編號有一定的規則，比如系統測試用例的編號這樣定義規則： PROJECT1-ST-001 ，命名規則是項目名稱+測試階段類型（系統測試階段）+編號。定義測試用例編號，便於查找測試用例，便於測試用例的跟蹤。

2、測試標題

對測試用例的描述，測試用例標題應該清楚表達測試用例的用途。比如 “ 測試用戶登錄時輸入錯誤密碼時，軟件的響應情況 ” 。

3、重要級別

定義測試用例的優先級別，可以籠統的分為 四個不同的等級

4、輸入限制

提供測試執行中的各種輸入條件。根據需求中的輸入條件，確定測試用例的輸入。測試用例的輸入對軟件需求當中的輸入有很大的依賴性，如果軟件需求中沒有很好的定義需求的輸入，那麽測試用例設計中會遇到很大的障礙。

5、操作步驟

提供測試執行過程的步驟。對於復雜的測試用例，測試用例的輸入需要分為幾個步驟完成，這部分內容在操作步驟中詳細列出。

6、預期結果

提供測試執行的預期結果，預期結果應該根據軟件需求中的輸出得出。如果在實際測試過程中，得到的實際測試結果與預期結果不符，那麽測試不通過；反之則測試通過。

三、編寫用例參考什麽內容？

當根據客戶的需求整理出項目需求分析文檔時，我們就可以根據需求文檔來編寫測試用例了。

等到項目開發人員把項目開發出來，給我們系統文檔、部署環境、數據庫結構（如果系統牽涉到數據庫的話），我們根據這些文檔來設計測試用例。

我們編寫的測試用例經過評審之後，隨著需求的變更、功能的改進，測試用例也需要更新和變動。

測試執行過程中，應該註意及時更新測試用例。往往在測試執行過程中，才發現遺漏了一些測試用例，這時候應該及時的補充；往往也會發現有些測試用例在具體的執行過程中根本無法操作，這時候應該刪除這部分用例；也會發現若幹個冗余的測試用例完全可以由某一個測試用例替代，那麽刪除冗余的測試用例。

四、黑盒測試用例的設計方法

具體的黑盒測試用例設計方法包括等價類劃分法、邊界值分析法、場景法、錯誤推測法、因果圖法、判定表驅動法、正交試驗設計法、功能圖法等。

這些方法是比較實用的，但采用什麽方法，在使用時自然要針對開發項目的特點對方法加以適當的選擇。

1、等價類劃分法

*在輸入條件規定了取值範圍或值的個數的情況下，則可以確立一個有效等價類和兩個無效等價類。

*在輸入條件規定了輸入值的集合或者規定了“必須如何”的條件的情況下，可確立一個有效等價類和一個無效等價類。

*在輸入條件是一個布爾量的情況下，可確定一個有效等價類和一個無效等價類。

*在規定了輸入數據的一組值（假定n個），並且程序要對每一個輸入值分別處理的情況下，可確立n個有效等價類和一個無效等價類。

*在規定了輸入數據必須遵守的規則的情況下，可確立一個有效等價類（符合規則）和若幹個無效等價類（從不同角度違反規則）。

*在確知已劃分的等價類中各元素在程序處理中的方式不同的情況下，則應再將該等價類進一步的劃分為更小的等價類。

a)確定測試用例:

*為每一個等價類編號。

*設計一個測試用例，使其盡可能多地覆蓋尚未被覆蓋過的合理等價類。重復這步，直到所有合理等價類被測試用例覆蓋。

*設計一個測試用例，使其只覆蓋一個不合理等價類。

b)舉例：

問題： “一個程序讀入3個整數，把這三個數值看作一個三角形的3條邊的長度值。這個程序要打印出信息，說明這個三角形是不等邊的、是等腰的、還是等邊的。”

我們可以設三角形的3條邊分別為A，B，C。如果它們能夠構成三角形的3條邊，必須滿足：

A>0，B>0，C>0，且A+B>C，B+C>A，A+C>B。

如果是等腰的，還要判斷A=B，或B=C，或A=C。

如果是等邊的，則需判斷是否A=B，且B=C，且A=C。

根據以上分析，從而得到下圖列表中的測試用例。

2、邊界值分析法

使用邊界值分析方法設計測試用例時一般與等價類劃分結合起來。但它不是從一個等價類中任選一個例子作為代表，而是將測試邊界情況作為重點目標，選取正好等於、剛剛大於或剛剛小於邊界值的測試數據。

⑴如果輸入條件規定了值的範圍，可以選擇正好等於邊界值的數據作為合理的測試用例，同時還要選擇剛好越過邊界值的數據作為不合理的測試用例。如輸入值的範圍是[1，100]，可取0，1，100，101等值作為測試數據。

⑵如果輸入條件指出了輸入數據的個數，則按最大個數、最小個數、比最小個數少1、比最大個數多1等情況分別設計測試用例。如，一個輸入文件可包括1--255個記錄，則分別設計有1個記錄、255個記錄，以及0個記錄的輸入文件的測試用例。

⑶對每個輸出條件分別按照以上原則⑴或⑵確定輸出值的邊界情況。如，一個學生成績管理系統規定，只能查詢95--98級大學生的各科成績，可以設計測試用例，使得查詢範圍內的某一屆或四屆學生的學生成績，還需設計查詢94級、99級學生成績的測試用例（不合理輸出等價類）。

由於輸出值的邊界不與輸入值的邊界相對應，所以要檢查輸出值的邊界不一定可能，要產生超出輸出值之外的結果也不一定能做到，但必要時還需試一試。

⑷如果程序的規格說明給出的輸入或輸出域是個有序集合（如順序文件、線形表、鏈表等），則應選取集合的第一個元素和最後一個元素作為測試用例。

3、場景法

用例場景用來描述流經用例的路徑，從用例開始到結束遍歷這條路徑上所有基本流和備選流。

按照上圖中每個經過用例的路徑，可以確定以下不同的用例場景：

場景 1 基本流

場景 2 基本流 備選流 1

場景 3 基本流 備選流 1 備選流 2

場景 4 基本流 備選流 3

場景 5 基本流 備選流 3 備選流 1

場景 6 基本流 備選流 3 備選流 1 備選流 2

場景 7 基本流 備選流 4

場景 8 基本流 備選流 3 備選流 4

註：為方便起見，場景 5、6 和 8 只考慮了備選流 3循環執行一次的情況。

4、錯誤推測法

概念：

基於經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法

基本思想：

列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據他們選擇測試用例

5、因果圖法

概念：

因果圖法是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合於檢查程序輸入條件的各種組合情況

基本思想：

等價類劃分法和邊界值分析方法都是著重考慮輸入條件，但沒有考慮輸入條件的各種組合、輸入條件之間的相互制約關系。這樣雖然各種輸入條件可能出錯的情況已經測試到了，但多個輸入條件組合起來可能出錯的情況卻被忽視了。

如果在測試時必須考慮輸入條件的各種組合，則可能的組合數目將是天文數字，因此必須考慮采用一種適合於描述多種條件的組合、相應產生多個動作的形式來進行測試用例的設計，這就需要利用因果圖（邏輯模型）。

6、判定表驅動法

概念：

判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

基本思想：

能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明並避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。

在一些數據處理問題當中，某些操作的實施依賴於多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合於處理這類問題。

7、正交試驗設計法

概念：

依據Galois理論,從大量的（實驗）數據（測試例）中挑選適量的,有代表性的點（例）,從而合理地安排實驗（測試）的一種科學實驗設計方法.類似的方法有:聚類分析方法,因子方法方法等.

基本思想：

利用因果圖來設計測試用例時, 作為輸入條件的原因與輸出結果之間的因果關系,有時很難從軟件需求規格說明中得到。往往因果關系非常龐大,以至於據此因果圖而得到的測試用例數目多的驚人，給軟件測試帶來沈重的負擔，為了有效地,合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。

8、功能圖法

概念：

功能圖由狀態遷移圖和布爾函數組成.狀態遷移圖用狀態和遷移來描述.一個狀態指出數據輸入的位置（或時間）,而遷移則指明狀態的改變.同時要依靠判定表或因果圖表示的邏輯功能.

從功能圖生成測試用例的過程：

1) 生成局部測試用例:在每個狀態中,從因果圖生成局部測試用例.局部測試用例由原因值（輸入數據）組合與對應的結果值（輸出數據或狀態）構成。

2) 測試路徑生成:利用上面的規則（三種）生成從初始狀態到最後狀態的測試路徑。

3) 測試用例合成:合成測試路徑與功能圖中每個狀態中的局部測試用例.結果是初始狀態到最後狀態的一個狀態序列,以及每個狀態中輸入數據與對應輸出數據的組合。

五：測試方法選擇的綜合策略

在實際測試中，往往是綜合使用各種方法才能有效提高測試效率和測試覆蓋度，這就需要認真掌握這些方法的原理，積累更多的測試經驗，以有效提高測試水平，以下是各種測試方法選擇的綜合策略，可在實際應用過程中參考。

*首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率的最有效方法。

*在任何情況下都必須使用邊界值分析方法。經驗表明用這種方法設計出測試用例發現程序錯誤的能力最強。

*對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度。如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

*對於業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

測試用例設計