測試用例設計在測試當中是經常會用到的，測試用例設計簡單的來說，就是一個文檔，描述輸入、動作、或者時間和一個期望的結果，其目的是確定應用程序的某個特性是否正常的工作。測試用例設計的方法是有很多的，比如等價類與邊界值、場景法、正交排列驅動法以及因果圖等，下面就讓我們來詳細的了解一下吧。

一、等價類與邊界值

等價類：等價類劃分法是把所有可能輸入的數據，有無效等價類和有效等價類（即正確輸入和非法輸入），即程序的輸入域劃分策劃國內若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。方法是一種重要的、常用的黑盒測試用例設計方法。

邊界值：邊界值分析法就是對輸入或輸出的邊界值進行測試的一種黑盒測試方法。通常邊界值分析法是作為對等價類劃分法的補充，這種情況下，其測試用例來自等價類的邊界。

與等價類區別：

邊界值分析不是從某等價類中隨便挑一個作為代表，而是使這個等價類的每個邊界都要作為測試條件。

邊界值分析不僅考慮輸入條件，還要考慮輸出空間產生的測試情況。

二、場景法

定義：通過運用場景來對系統的功能點或業務流程的描述，從而提高測試效果的一種方法。用例場景來測試需求是指模擬特定場景邊界發生的事情，通過事件來觸發某個動作的發生，觀察事件的最終結果，從而用來發現需求中存在的問題。

基本流：是經過用例的最簡單的路徑（無任何差錯，程序從開始直接執行到結束）

備選流：一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中，也可以起源于另一個備選流，或終止用例，不在加入到基本流中；（各種錯誤情況）

三、正交排列驅動法

定義：在界面中有多個控件，控件之間有多種組合關系，如果組合的數量巨大（一般超過20種），沒有必要將所有組合都測試，可以通過正交排列法將組合中最優，最少的組合進行測試。

正交表公式：

Ln（m^k）·L（line）行

n:表示正交表的行數

提示：正交表確定后，n值是固定的，不需要測試人員計算

m：表示正交表中數據的最大值

測試時：m表示每個控件的取值個數

K:表示正交表的列數

測試時：k表示參與組合的控件的個數

與判定表驅動法的區別：正交表一般用于組合較多的場合（一般>20種），判定表一般用于組合較少的情況

四、因果圖

1.定義：是一種利用圖解法分析輸入的各種組合情況，從而設計測試用例的方法，它適合于檢查程序輸入條件的各種組合情況。

2.因果圖法產生的背景：

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

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

3.因果圖介紹

1）4種符號分別表示了規格說明中向4種因果關系。

2）因果圖中使用了簡單的邏輯符號，以直線聯接左右結點。左結點表示輸入狀態（或稱原因），右結點表示輸出狀態（或稱結果）。

3）Ci表示原因，通常置于圖的左部；ei表示結果，通常在圖的右部。Ci和ei均可取值0或1，0表示某狀態不出現，1表示某狀態出現。

4.因果圖概念

1）關系

恒等：若ci是1，則ei也是1；否則ei為0。

非：若ci是1，則ei是0；否則ei是1。

或：若c1或c2或c3是1，則ei是1；否則ei為0。“或”可有任意個輸入。

與：若c1和c2都是1，則ei為1；否則ei為0。“與”也可有任意個輸入。

2）約束

輸入狀態相互之間還可能存在某些依賴關系，稱為約束。例如，某些輸入條件本身不可能同時出現。輸出狀態之間也往往存在約束。在因果圖中，用特定的符號標明這些約束。

A.輸入條件的約束有4類。

B.輸出條件約束類型。

5.采用因果圖法設計測試用例的步驟：

1）分析軟件規格說明描述中，那些是原因（即輸入條件或輸入條件的等價類），那些是結果（即輸出條件），并給每個原因和結果賦予一個標識符。

2）分析軟件規格說明描述中的語義，找出原因與結果之間，原因與原因之間對應的關系，根據這些關系，畫出因果圖。

3）由于語法或環境限制，有些原因與原因之間，原因與結果之間的組合情況不可能出現，為表明這些特殊情況，在因果圖上用一些記號表明約束或限制條件。

4）把因果圖轉換為判定表。

5）把判定表的每一列拿出來作為依據，設計測試用例。

五、判定表

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

判定表的優點

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

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

判定表通常由四個部分組成如下圖所示：

1、條件樁（ConditionStub）：列出了問題得所有條件。通常認為列出的條件的次序無關緊要。

2、動作樁（ActionStub）：列出了問題規定可能采取的操作。這些操作的排列順序沒有約束。

3、條件項（ConditionEntry）：列出針對它左列條件的取值。在所有可能情況下的真假值。

4、動作項（ActionEntry）：列出在條件項的各種取值情況下應該采取的動作。

六、錯誤推測法

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

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

測試用例設計方法總共有六種方法，現在大家應該有所了解了，希望今天小編的介紹可以解決大家的疑問。最后小編再給大家介紹一款測試用例設計工具，TestCenter (測試管理工具)，是面向測試流程的測試生命周期管理工具,它支持手工編寫測試用例、用例附件批量導入；支持執行中的測試用例管理；保證測試用例的質量，實現測試用例的標準化，降低了測試用例對個人的依賴。

推薦閱讀：

在系統軟件當中，原來經常會出現這些bug

bug記錄里通常包括哪些內容？

有哪些缺陷管理工具是測試人員比較常用的?

如何進行測試用例管理？測試用例管理的要點

軟件測試bug管理之bug常見分類及相關屬性

測試場景和測試用例區別是什么？如何做到測試場景不遺漏？