我們到底該如何進行黑盒測試：用例設計篇

該到了這個老生長談的話題了。多少人看不起的用例，多少人不會寫的用例，多少人覺得無聊的手工測試。記得之前一個朋友說， 測試用例是一個測試人員非常重要的技能之一 ，十分贊同。

試想如果手工測試發現不了問題，那麼基於測試用例轉換的自動化測試，又怎麼能幫我們發現更多的問題呢？雖然自動化測試的定義更多的是幫助我們迴歸並且驗證核心功能是否受到影響。

總而言之，測試用例是測試工作的核心，是測試活動開展的重要依賴，是基線測試覆蓋的重要支撐。

先回顧下上篇文章最後結尾處的一些內容：

「總之，測試有3種分析

基於需求的分析

基於使用者的分析

基於風險的分析

測試也有2種設計

基於狀態的設計

基於資料的設計」

這次，我們就把測試的2種設計，好好的講一講。

說起用例，大家不陌生的一定是測試用例的設計方法。等價類、邊界值、因果圖、判定表、狀態遷移圖、場景法、正交等等。。。（這裏我們就暫時先忽略錯誤推測法及其他的設計方法吧，相比錯誤推測法，我更建議探索性測試，一定比錯誤推測、即興測試來的更好，也更有跡可循。）

我們仔細分析下，首先，

結論一：

A，等價類和邊界值，做為常用的組合，經常出現在資料設計型別上，比如登入、註冊、表單、資訊獲取等等

B，因果圖和判定表，常用於簡單情況下的結果驗證，更適用於不復雜的場景，或者許可權、或者1個操作影響多個結果的時候

C，狀態遷移圖、場景法，更多的適合於一連串操作或者較複雜的場景結合、或者有多種狀態之前切換且可能無序的時候，比如說賬號的狀態有正常、禁用、凍結、廢棄等，那麼每一種狀態之間的轉換，就極其適合狀態遷移圖，而經典的ATM機取錢的例子，就很好的解釋了場景法是如何使用的。在於使用者從開頭到結尾，有多種可能，多種路徑時的設計

D，正交法，大家用的較少，因為設計出來的用例很多，大部分適合於因素和水平不多的時候，那麼當多的時候怎麼辦呢？首先，可以使用正交表用例生成器（這裏大家可以自行百度下進行下載），完成後，按照 單失效模式和雙失效模式進行用例的優化（原文出自2011年，51testing上作者的分享， http://www.51testing.com/html/22/n-235122.html ，如何有效減少測試用例數目 ）。當然，正交其實我們也可以認為是資料驅動的。

所以我們進一步歸納下：

結論二：

場景法、狀態遷移圖、因果圖、判定表則為基於狀態的設計（有人會寫成基於場景的設計，大致一樣），更多的應用到測試用例設計過程中，是測試用例基於面的覆蓋，基於使用者可能的覆蓋，影響了用例的廣度。同時，基於使用者重點場景的驗證，也是UI層最優先應該覆蓋的地方。

等價類、邊界值、正交表則為基於資料的設計，更多的應用到測試用例設計過程中，是測試用例基於面覆蓋之後，基於點的設計，影響了用例的深度。同時這部分用例可能數量較多、而優先順序較低，所以，這部分是API介面層最好覆蓋的地方。

總結起來如下圖

接下來，我們回顧下到底什麼是測試用例，這裏引用一句話：

「A test case is a set of conditions or variables under which a tester will determine whether a system under test satisfies requirements and works correctly.」

關鍵詞：

條件、資料、滿足要求、正常工作

這應該算是非常正確的測試用例的解釋了，同時我在補充一句吧，測試用例是控制、度量測試行為的重要產物。

另外，再給大家一些建議，是如何更好的劃分用例的優先順序的。

大部分公司會採用3級或者4級的用例，貌似更多的是4級，這裏我們用4級來舉個例子，同時常規的用例佔比大致如此：

Smoking Test(S)：冒煙級別用例，大概佔用例的10%~15%，是最核心的功能

Hign Lever Test(H)：高優先順序的用例，大概佔用例的25%~30%，同時，包含Smoking Test

Regression Test(R)：迴歸測試用例，大概佔用例的50%左右，同時，向上包含前2種用例

Function Test(F)：功能用例，100%，全部用例。

建議用例級別的劃分標準和設計方法對應關係 ：

場景法：

基本流為S級別用例

備選流按照操作頻率為H或者R

狀態遷移圖：

正向狀態或者核心狀態為S級別

其餘為H或者R

因果圖和判定表：

如果不涉及核心功能或者重要場景，則按照H、R處理

等價類：

有效為S或者H

無效為R、F

邊界值：

中間為R、兩邊為F（這裏應該和很多人想的不一樣了，因為級別已經比較低了）

正交表：

單失效模式為H，雙失效為R，其餘為F（當然很多時候其餘可能不會寫入測試用例中）

這樣子的話，測試用例的設計和級別就出來了。他就已經構成一個立體式的測試用例了。有的人會發現還少了測試資料，這個測試用例的重要組成部分，是條件或者結果中重要的內容。我們也一併說下吧

測試資料大致有3種設計方法：

A，如果被測物為更新版本，則表示之前已經有實際資料產生，則通過實際資料的挖掘進而設計測試資料

B，如果被測物為新產品，同時又有很多競品可以參考，則通過競品的分析，目標使用者，使用者行為，使用者量的分析進行設計

C，如果被測物為新產品，而又沒有可借鑑的同類產品進行分析，則就得完全通過需求、使用者可能的場景進行分析，同時考慮上線後一段時間的目標進而得出綜合的設計

其實有2點可以判斷測試用例是否足夠好（這裏我們假定測試用例沒有明顯的遺漏缺失）

A，是否可以讓新人不用看產品文件，就能輕鬆理解執行並能有很好的覆蓋

B，是否有冗餘

最後，可以提供一個用例管理思路

上圖是一個程式碼分支管理的圖例，沒錯，其實用例的版本管理可以像程式碼分支管理一樣，不過沒有那麼複雜，他有幾個原則

1，可以針對新功能設計用例，從而對新功能進行深度的測試，但是在系統測試前，用例需要合併到整體內容中並且優化為一份完整的系統用例

PS：如果僅針對新功能設計用例，他的比例不一定嚴格按照我們剛纔說的比例，但合併完成的用例，一定遵循正常的用例級別的比例

2，可以有多個版本， hotfix版本、私有云版本， 但一定會有當前最新系統的版本。

感謝大家能看到這裏，把這麼無聊的內容看完，到這裏，黑盒測試也就差不多了吧，後續幾篇文章，我們一起聊聊介面測試，當然網上的資料已經夠多了，我並不會比其他人說的更多，說得更好，但也算是我這個系列繼續往下走吧，這樣回過頭來，發現自己的體系很健全，讀者也能在一個地方找到不同的東西，應該蠻不錯的。

最後，給大家share一個我認為的測試覆蓋的公式： 測試覆蓋 = 測試方法 + 測試資料 + 測試執行 + 測試範圍

其中的測試執行，考慮到了人為的因素，所以他不一定等於我們圈定的測試範圍。而測試範圍，又隨著階段的推進、環境的變更會越來越少，這個時候則尤其擔心修復引發的問題。