.NET單元測試（四）：用例設計

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

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

---

對於單元測試能夠劃分紅哪些環節，你是否是有了本身的認識呢？

按照本身的理解，無論怎樣劃分，都是能夠的。小編根據本身的經驗，將其劃分紅以下幾個環節：

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

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

---

通過一分鐘的思考，相信你有了本身的認識。

針對這個問題，小編並沒能肯定哪個環節更重要，彷佛，須要每一個環節的良好配合才能發揮各個環節的最大做用。

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

作一個練習

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

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

---

若是你以前沒有任何測試經驗，你的用例可能有這麼會包含這麼一些狀況：

等價類劃分

針對這個問題咱們能夠把輸入的狀況按照下面的方式進行分類：

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

經過等價類劃分，能夠迫使咱們分析業務的邊界，明確哪些用例是真實有效的，避免了沒必要要的無效用例。

等價類劃分能夠分爲有效等價類和無效等價類

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

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

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

邊界值分析法

邊界值每每有更多出錯的可能，因此在設計用例時須要對邊界值格外敏感。邊界值分析法就是 對輸入或輸出的邊界值進行測試。一般邊界值分析法是做爲對等價類劃分法的補充。

針對這個練習，至少有這麼些狀況屬於邊界值：

在業務描述時抓住一些關鍵的點能夠幫助咱們識別業務中的邊界值，好比當業務中包含以下這些描述時，每每就須要留意邊界值了：

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

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

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

通過了等價類劃分和邊界值分析，咱們設計出了一些用例，可是對於業務中的 「數字、字母或符號」 還未進行考慮。對於用戶的輸入狀況沒法估計，這就致使可能存在多種組合，針對這種組合，若是憑空想是很容易漏掉的。接下來使用的 斷定表分析 就是爲了解決這種問題。

斷定表

針對這個練習，只考慮輸入的字符的狀況，能夠分紅：字母、數字、英文字符、非英文字符、圖標。咱們須要考慮這些狀況的組合，若是沒有斷定表，是比較頭痛的。

斷定表的定義：斷定表是分析和表達多邏輯條件下執行不一樣操做的狀況的工具。

這裏以斷定表的部分截圖爲例;

經過斷定表，咱們能夠清楚的羅列各類狀況，下降漏掉的可能性。

有時候可能會遇到分類特別多的狀況，這會致使斷定表很是龐大。不必定要把每一個小細節做爲一個項目，能夠以一個維度，一個類別做爲一個分類。進而減小測試用例維護的工做量。

結果

通過上面幾輪方法的透析，咱們能夠獲得以下的用例表格。

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

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

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

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

變量識別

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

舉個栗子

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

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

---

三分鐘事後，你是否是識別到了其中的變量呢？

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

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

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

「 執行全部事件，在執行過程不拋出異常，在所有運行以後若是有異常則拋出全部異常」

錯誤推測

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

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

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

可是經驗是須要積累的，是須要時間的，對於一個新人來說，快速得到經驗是提高的法寶，對於老人來說，把經驗傳遞給新人，幫助新人快速成長，應該是責無旁貸的責任。

因此，老人把經驗都記錄下來對本身和新人都會很是受益。

總結

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

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

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

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