軟體測試用例編寫（含思路）

測試用例編寫是軟體測試的基本技能；也有很多人認為測試用例是軟體測試的核心；軟體測試中最重要的是設計和生成有效的測試用例；測試用例是測試工作的指導，是軟體測試的必須遵守的準則。

在這裡我們不討論以上的各種觀點，但是綜上所述，大家可以看出，測試用例編寫這項軟技能非常重要且是測試人的必備技能，相信很多人沒有質疑。

下面我們介紹下測試用例編寫。
我們將用例編寫分為黑盒用例編寫和白盒用例編寫兩大類。

在這裡插入圖片描述

標題總體編寫思路：
黑盒測試用例（優先）+白盒測試用例（補充）=完整測試用例

總體編寫策略：
對於測試用例編寫來說，常用的四種方法基本就夠用了，等價類、邊界值、正交實驗法、錯誤推斷法，輔以場景測試法、需求/設計轉換法、探索式測試思想，可以應付絕大多數產品的測試。個別的產品還需要在某一點細化和擴充，需要就事論事。

使用各種編寫方法的綜合設計策略；

1)在任何情況下都必須使用邊界值分析方法，經驗表明用這種方法設計出測試用例發現程式錯誤的能力最強。
2)必要時用等價類劃分方法補充一些測試用例，尤其注意無效等價類情況。
3)如果程式的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法（或判定表法、正交試驗法）。
4)用錯誤推測法再追加一些測試用例，主要是利用測試經驗。
5)對照程式邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例；參照白盒用例編寫。
6)對程式的應用場景進行研究和思考，增加不同場景下的測試用例；使用者場景測試必須重視，很大一部分程式錯誤就是因為測試場景與使用者真實場景的差異性帶來的。
7)對業務和程式有更深的理解之後，可以充分發揮發散思維和探索式想法；大家不要誤解探索式測試就是漫無目的的測試，其實探索式測試有非常詳細的測試指導思路。
第一部分：黑盒用例編寫
常見的方法如下：

（1）等價類

（2）邊界值

（3）因果圖

（4）判定表驅動法

（5）正交實驗法

（6）功能圖法

（7）場景實驗法

（8）錯誤推斷法

（9）需求轉化

（10）設計文件

（11）探索式測試

1、黑盒-等價類
等價類：選取少數有代表性的資料，這一類資料等價於這一類的其它值；找出最小的子集，可以發現最多的錯誤；

兩大特性：必須設計的用例；涵蓋了大部分情況；

兩類情況：有效等價類；無效等價類；

轉化為測試用例

1、按照輸入條件、有效等價類、無效等價類建立等價類列表，列出所有的等價類；

2、為每一個等價類固定一個編號；

3、設計一個測試用例，使其覆蓋一個或多個有效的等價類；

4、設計一個或更多的測試用例以覆蓋剩餘的有效等價類；

使用場景：輸入條件（取值範圍/值個數；必須值集合；布林值；一組處理值；必須遵守的規則；再細分更小等價類；）

等價類舉例：

以三角形測試為例：輸入3個整數做為三角形的三個邊，通過程式判定三角形的型別。

在這裡插入圖片描述

2、黑盒-邊界值
邊界值：所謂邊界條件，是指輸入和輸出等價類中那些恰好處於邊界、超過邊界、或在邊界以下的狀態 ；

兩個特徵：選擇一個或多個元素，以便等價類的每一個邊界都經過了測試；與僅僅關注輸入條件不同，還需要考慮結果空間（輸出等價類）設計測試用例；

邊界條件可能非常微妙，因此把他們確定下來煞費心思；

使用場景：輸入+輸出都需要考慮（值的範圍；值個數；有序集合；內部資料結構；分析規格說明；）

邊界值舉例：

以三角形測試為例：輸入3個整數做為三角形的三個邊，1<a、b、c<10,通過程式判定三角形的型別；

在這裡插入圖片描述

3、黑盒-因果圖
因果圖：輸入條件的組合進行分析。用一個系統的方法選擇出高效的測試用例集；

分析思路：

1、分析規格說明描述，確定原因和結果，並賦予識別符號；

2、分析規格說明語義，找出原因與原因之間，原因與結果之間關係，畫出因果圖；

3、有些原因與原因之間，原因與結果之間組合不會出現，用記號表明約束或限制條件；

4、因果圖轉換為判定表；

5、判定表的每一列作為依據，設計測試用例；

使用場景：必須考慮輸入條件的各種組合（一種適合於描述多種條件的組合、相應產生多個動作的形式來進行設計）；

4、黑盒-判定表
判定表：分析和表達多邏輯條件下執行不同操作的情況的工具 ；略過因果圖的繪製，直接列出所有組合進行篩選；

分析思路：判定表通常有四個部分組成：條件樁、動作樁、條件項、動作項；

判定表的建立步驟：（根據軟體規格說明）

確定規則個數；列出所有條件樁和動作樁；填入條件項；填入動作項，得到初始判定表；簡化合並相似規則；

==使用場景：控制類和遊戲。優點是能把複雜的問題按各種可能的情況一一列舉出來，簡明而易於理解，也可避免遺漏。缺點是不能表達重複執行的動作，例如迴圈結構。

5、黑盒-正交試驗法
正交實驗法：利用因果圖來設計測試用例時, 輸入原因與輸出結果之間的因果關係,有時很難從軟體需求規格說明中得到；往往因果關係非常龐大,以至於測試用例數目巨大，為了有效地、合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。

分析思路：

（1）提取功能說明,構造因子–狀態表 ；

（2）加權篩選,生成因素分析表 ；

（3）利用正交表構造測試資料集 ；

使用場景：必須考慮輸入條件的各種組合（從大量的資料中挑取適量、有代表性的點，合理有效的測試）；

6、黑盒-場景實驗法
場景實驗法：軟體幾乎都是由事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果形成事件流；生動的描繪出事件觸發時的情景，有利於設計用例，同時測試用例也更容易的得到理解和執行。

分析思路：

每條路徑都反映了基本流和備選流；基本流是最簡單的路徑；備選流自基本流開始，會有特定條件下加入並執行，可能有多種情況；

使用場景（0代表基本流）：0；0+1；0+1+2；0+3；0+3+1；0+3+1+2；0+4；0+3+4；…

在這裡插入圖片描述

7、錯誤推斷法
錯誤推斷法：基於經驗和直覺推測程式中所有可能存在的各種錯誤,從而有針對性的設計測試用例的方法；更多的與使用者的使用習慣及測試程式中的常見問題為主。

分析思路：

（1）列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況，根據這些情況選擇測試用例；

（2）注意積累與分享；

使用場景：任何測試、任何情景下都會用到的方法。

有常用的測試用例集，可以參照。

舉例：數字輸入驗證，分別輸入數字(正數、負數、零值、單精度、雙精度)、字串、空白值、空值、臨界數值；不合法的輸入，系統給出必要的判斷提示資訊；

8、黑盒-需求轉換法
需求轉換法：根據需求，執行需求分析，並編寫測試用例。

分析思路：

（1）將需求轉換為思維導圖；

（2）仔細推敲每一個字的含義；

（3）與使用者的使用場景和目的結合；

（4）嚴格設計每一個用例；

（5）可以建立一種模型，進行需求轉換；

使用場景：任何測試、任何情景下都會用到的方法。

注意：需求的變更帶來的影響；需求理解偏差帶來的影響；需求含糊不清帶來的影響等；

9、黑盒-設計文件
設計文件：參照設計文件，可以理解軟體系統內部設計流程及處理機制，對比寫好的測試用例，可以在對應功能及模組處新增；

分析思路：

（1）仔細閱讀設計文件；

（2）與相關人員溝通實現機制；

（3）結合測試用例編寫方法，對比之前寫好的用例；

使用場景：任何測試、任何情景下都會用到的方法。

注意：設計文件的編寫正確性；設計文件的理解偏差；

10、黑盒-探索式測試法
探索式測試法：無限創意的測試點，永無止境的探索測試；我們要在測試的最前沿發揮洞察力、技術及應變措施，找出產品的缺陷；

分析思路：

區域性探索式測試；全域性探索式測試；混合探索式測試；

使用場景：任何測試、任何情景下都會用到的方法。像漫遊一樣，自由地尋找軟體中的缺陷，軟體測試的未來必然有探索式測試。

第二部分：白盒用例編寫

在這裡插入圖片描述

基本思路：
第一步需要繪製流程圖；

第二步根據路徑分析法確定測試用例；

第三步使用等價類/邊界值的方法確定測試用例的資料

第四步根據實際情況補充（如預設流程、特殊流程等）

基本策略：
1、語句覆蓋準則基本上沒啥用，比較強的邏輯覆蓋準則是判定覆蓋或者條件覆蓋；通常判定覆蓋可以滿足語句覆蓋；語句覆蓋<判定覆蓋<條件覆蓋；

2、迴圈覆蓋來說，完全的路徑測試並不符合實際；

.