測試用例編寫是軟體測試的基本技能;也有很多人認為測試用例是軟體測試的核心;軟體測試中最重要的是設計和生成有效的測試用例;測試用例是測試工作的指導,是軟體測試的必須遵守的準則。
在這裡我們不討論以上的各種觀點,但是綜上所述,大家可以看出,測試用例編寫這項軟技能非常重要且是測試人的必備技能,相信很多人沒有質疑。
下面我們介紹下測試用例編寫。
我們將用例編寫分為黑盒用例編寫和白盒用例編寫兩大類。
黑箱測試用例(優先)+白盒測試用例(補充)=完整測試用例
對於測試用例編寫來說,常用的四種方法基本就夠用了,等價類、邊界值、正交實驗法、錯誤推斷法,輔以場景測試法、需求/設計轉換法、探索式測試思想,可以應付絕大多數產品的測試。個別的產品還需要在某一點細化和擴充,需要就事論事。
使用各種編寫方法的綜合設計策略;
常見的方法如下:
(1)等價類
(2)邊界值
(3)因果圖
(4)判定表驅動法
(5)正交實驗法
(6)功能圖法
(7)場景實驗法
(8)錯誤推斷法
(9)需求轉化
(10)設計檔案
(11)探索式測試
等價類:選取少數有代表性的資料,這一類資料等價於這一類的其它值;找出最小的子集,可以發現最多的錯誤;
兩大特性:必須設計的用例;涵蓋了大部分情況;
兩類情況:有效等價類;無效等價類;
轉化為測試用例
1、按照輸入條件、有效等價類、無效等價類建立等價類列表,列出所有的等價類;
2、為每一個等價類固定一個編號;
3、設計一個測試用例,使其覆蓋一個或多個有效的等價類;
4、設計一個或更多的測試用例以覆蓋剩餘的有效等價類;
使用場景:輸入條件(取值範圍/值個數;必須值集合;布林值;一組處理值;必須遵守的規則;再細分更小等價類;)
等價類舉例:
以三角形測試為例:輸入3個整數做為三角形的三個邊,通過程式判定三角形的型別。
邊界值:所謂邊界條件,是指輸入和輸出等價類中那些恰好處於邊界、超過邊界、或在邊界以下的狀態 ;
兩個特徵:選擇一個或多個元素,以便等價類的每一個邊界都經過了測試;與僅僅關注輸入條件不同,還需要考慮結果空間(輸出等價類)設計測試用例;
邊界條件可能非常微妙,因此把他們確定下來煞費心思;
使用場景:輸入+輸出都需要考慮(值的範圍;值個數;有序集合;內部資料結構;分析規格說明;)
邊界值舉例:
以三角形測試為例:輸入3個整數做為三角形的三個邊,1<a、b、c<10,通過程式判定三角形的型別;
因果圖:輸入條件的組合進行分析。用一個系統的方法選擇出高效的測試用例集;
分析思路:
1、分析規格說明描述,確定原因和結果,並賦予識別符號;
2、分析規格說明語意,找出原因與原因之間,原因與結果之間關係,畫出因果圖;
3、有些原因與原因之間,原因與結果之間組合不會出現,用記號表明約束或限制條件;
4、因果圖轉換為判定表;
5、判定表的每一列作為依據,設計測試用例;
使用場景:必須考慮輸入條件的各種組合(一種適合於描述多種條件的組合、相應產生多個動作的形式來進行設計);
判定表:分析和表達多邏輯條件下執行不同操作的情況的工具 ;略過因果圖的繪製,直接列出所有組合進行篩選;
分析思路:判定表通常有四個部分組成:條件樁、動作樁、條件項、動作項;
判定表的建立步驟:(根據軟體規格說明)
確定規則個數;列出所有條件樁和動作樁;填入條件項;填入動作項,得到初始判定表;簡化合並相似規則;
==使用場景:控制類和遊戲。優點是能把複雜的問題按各種可能的情況一一列舉出來,簡明而易於理解,也可避免遺漏。缺點是不能表達重複執行的動作,例如迴圈結構。
正交實驗法:利用因果圖來設計測試用例時, 輸入原因與輸出結果之間的因果關係,有時很難從軟體需求規格說明中得到;往往因果關係非常龐大,以至於測試用例數目巨大,為了有效地、合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。
分析思路:
(1)提取功能說明,構造因子–狀態表 ;
(2)加權篩選,生成因素分析表 ;
(3)利用正交表構造測試資料集 ;
使用場景:必須考慮輸入條件的各種組合(從大量的資料中挑取適量、有代表性的點,合理有效的測試);
場景實驗法:軟體幾乎都是由事件觸發來控制流程的,事件觸發時的情景便形成了場景,而同一事件不同的觸發順序和處理結果形成事件流;生動的描繪出事件觸發時的情景,有利於設計用例,同時測試用例也更容易的得到理解和執行。
分析思路:
每條路徑都反映了基本流和備選流;基本流是最簡單的路徑;備選流自基本流開始,會有特定條件下加入並執行,可能有多種情況;
使用場景(0代表基本流):0;0+1;0+1+2;0+3;0+3+1;0+3+1+2;0+4;0+3+4;…
錯誤推斷法:基於經驗和直覺推測程式中所有可能存在的各種錯誤,從而有針對性的設計測試用例的方法;更多的與使用者的使用習慣及測試程式中的常見問題為主。
分析思路:
(1)列舉出程式中所有可能有的錯誤和容易發生錯誤的特殊情況,根據這些情況選擇測試用例;
(2)注意積累與分享;
使用場景:任何測試、任何情景下都會用到的方法。
有常用的測試用例集,可以參照。
舉例:數位輸入驗證,分別輸入數位(正數、負數、零值、單精度、雙精度)、字串、空白值、空值、臨界數值;不合法的輸入,系統給出必要的判斷提示資訊;
需求轉換法:根據需求,執行需求分析,並編寫測試用例。
分析思路:
(1)將需求轉換為思維導圖;
(2)仔細推敲每一個字的含義;
(3)與使用者的使用場景和目的結合;
(4)嚴格設計每一個用例;
(5)可以建立一種模型,進行需求轉換;
使用場景:任何測試、任何情景下都會用到的方法。
注意:需求的變更帶來的影響;需求理解偏差帶來的影響;需求含糊不清帶來的影響等;
設計檔案:參照設計檔案,可以理解軟體系統內部設計流程及處理機制,對比寫好的測試用例,可以在對應功能及模組處新增;
分析思路:
(1)仔細閱讀設計檔案;
(2)與相關人員溝通實現機制;
(3)結合測試用例編寫方法,對比之前寫好的用例;
使用場景:任何測試、任何情景下都會用到的方法。
注意:設計檔案的編寫正確性;設計檔案的理解偏差;
探索式測試法:無限創意的測試點,永無止境的探索測試;我們要在測試的最前沿發揮洞察力、技術及應變措施,找出產品的缺陷;
分析思路:
區域性探索式測試;全域性探索式測試;混合探索式測試;
使用場景:任何測試、任何情景下都會用到的方法。像漫遊一樣,自由地尋找軟體中的缺陷,軟體測試的未來必然有探索式測試。
第一步需要繪製流程圖;
第二步根據路徑分析法確定測試用例;
第三步使用等價類/邊界值的方法確定測試用例的資料
第四步根據實際情況補充(如預設流程、特殊流程等)
1、語句覆蓋準則基本上沒啥用,比較強的邏輯覆蓋準則是判定覆蓋或者條件覆蓋;通常判定覆蓋可以滿足語句覆蓋;語句覆蓋<判定覆蓋<條件覆蓋;
2、迴圈覆蓋來說,完全的路徑測試並不符合實際;