首先，我們先來思考一個問題：單元測試中，哪一個環節更重要？

要回答這個問題，我們先需要了解單元測試到底有哪些環節，讀到這里，請暫停一分鐘，回憶一下我們平時的單元測試實踐（請最小化瀏覽器）。

---

對于單元測試可以劃分成哪些環節，你是不是有了自己的認識呢？

按照自己的理解，不管怎樣劃分，都是可以的。小編根據自己的經驗，將其劃分成如下幾個環節：

• 分析業務
• 設計用例
• 實現用例
• 重構
• 持續集成

接下來，請暫停一分鐘，思考一下這五個環節中，哪一個更重要（請最小化瀏覽器）。

---

經過一分鐘的思考，相信你有了自己的認識。

針對這個問題，小編并沒能確定哪一個環節更重要，似乎，需要每個環節的良好配合才能發揮各個環節的最大作用。

這篇文章要講的內容就是這五個環節中的 設計用例 環節。

做一個練習

請針對下面這個業務設計用例（可以想象成有一個返回true或者false的方法，接受一個字符串，按照定義的規則做檢查）

請暫停三分鐘，盡量思考更多的用例（請最小化瀏覽器）。

---

如果你之前沒有任何測試經驗，你的用例可能有這么會包含這么一些情況：

等價類劃分

針對這個問題我們可以把輸入的情況按照下面的方式進行分類：

這樣分類后，我們發現，在每個類別區間的輸入都具有相同的意義，這就是等價類劃分 。

通過等價類劃分，可以迫使我們分析業務的邊界，明確哪些用例是真實有效的，避免了不必要的無效用例。

等價類劃分可以分為有效等價類和無效等價類

• 有效等價類：是指對于程序的規格說明來說是合理的、有意義的輸入數據構成的集合。
• 無效等價類：無效等價類指對程序的規格說明是不合理的或無意義的輸入數據所構成的集合。

在這個練習中，“6-18個字母，數字或字符” 就是有效等價類，另外兩個區間屬于無效等價類。

在做等價類劃分時，這兩種等價類都是必不可少的。

邊界值分析法

邊界值往往有更多出錯的可能，所以在設計用例時需要對邊界值格外敏感。邊界值分析法就是 對輸入或輸出的邊界值進行測試。通常邊界值分析法是作為對等價類劃分法的補充。

針對這個練習，至少有這么些情況屬于邊界值：

在業務描述時抓住一些關鍵的點可以幫助我們識別業務中的邊界值，比如當業務中包含如下這些描述時，往往就需要留意邊界值了：

• 最XX（最小/大、最快/慢、最高/底.....）
• 超過
• 在內
• 相鄰
• ...

當我們識別到了邊界值，對于越界的用例設計是非常有必要的，這是對程序健壯性的驗證。

• 短了再短/長了再長
• 第一個減1/最后一個加1
• 少了更少/多了更多
• 剛好超過/剛好在內

經過了等價類劃分和邊界值分析，我們設計出了一些用例，但是對于業務中的 “數字、字母或符號” 還未進行考慮。對于用戶的輸入情況無法估計，這就導致可能存在多種組合，針對這種組合，如果憑空想是很容易漏掉的。接下來使用的 判定表分析 就是為了解決這種問題。

判定表

針對這個練習，只考慮輸入的字符的情況，可以分成：字母、數字、英文字符、非英文字符、圖標。我們需要考慮這些情況的組合，如果沒有判定表，是比較頭痛的。

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

這里以判定表的部分截圖為例;

通過判定表，我們可以清楚的羅列各種情況，降低漏掉的可能性。

有時候可能會遇到分類特別多的情況，這會導致判定表非常龐大。不一定要把每個小細節作為一個項目，可以以一個維度，一個類別作為一個分類。進而減少測試用例維護的工作量。

結果

經過上面幾輪方法的透析，我們可以得到如下的用例表格。

這個表格已經包含了這個業務的絕大多數用例情況（畢竟完美的用例套件是不存在的）。

上面介紹的三種方法不是一定要按照剛才介紹的順序來使用，只要能夠在設計用例的時候想到有這些方法，并用這些方法進行分析，基本就可以覆蓋絕大多數情況。

理想是美好的，現實往往比較苦澀。當我們再分析具體業務，嘗試用上面的方法去分析時，有時候并不能很快的找到合適的等價類劃分方法，邊界識別也可能模糊不清，被我們漏掉。

仔細分析上面的三種方法可以發現，其中都包含了一個關鍵的步驟：變量識別。

變量識別

所謂變量識別，就是識別業務中的可變的關鍵點，通過不斷的改變這些關鍵點來構造用例。

舉個栗子

業務描述：針對當前系統用戶，只在第一次調用時，執行委托的方法。

針對此描述，咱們再暫停三分鐘，請思考其中的變量，以及其可變化的情況（請最小化瀏覽器）。

---

三分鐘過后，你是不是識別到了其中的變量呢？

小編識別到了這么些變量;

• 當前系統用戶：如果不是當前系統用戶會怎樣？
• 第一次調用：如果不是第一次調用會怎樣？
• 委托：這個委托是有返回值呢，還是沒返回值？如果委托中拋出了異常會怎樣？

你是不是比小編識別到更多變量呢？做個練習，請針對下面的業務描述識別變量，并設計用例。

“ 執行所有事件，在執行過程不拋出異常，在全部運行之后如果有異常則拋出所有異常”

錯誤推測

除了上面介紹的方法，還有一種基于經驗的用例設計方法：錯誤推測。

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

錯誤猜測大多基于經驗，需要從邊界值分析等其他技術獲得幫助。這種技術猜測特定軟件類型可能發生的錯誤類型，并且設計測試用例查出這些錯誤。 對有經驗的工程師來說，錯誤猜測有時是唯一最有效發現Ｂug的測試設計方法。

但是經驗是需要積累的，是需要時間的，對于一個新人來講，快速獲得經驗是提升的法寶，對于老人來講，把經驗傳遞給新人，幫助新人快速成長，應該是義不容辭的責任。

所以，老人把經驗都記錄下來對自己和新人都會非常受益。

總結

在這邊文章中，我們介紹了如下設計用例的方法：

• 等價類劃分
• 邊界值識別
• 判定表分析
• 變量識別
• 錯誤推測

每種方法都不復雜，也都能幫我們解決問題，如果能夠在每次設計用例的時候想到這些方法，基本用例設計就比較全了。

參考資料：《單元測試的藝術》《軟件測試》《軟件測試的藝術》

轉載于:https://juejin.im/post/5ce55a75e51d4577790c1bf6

總結

以上是生活随笔為你收集整理的.NET单元测试（四）：用例设计的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。