軟件測試培訓第25天
場景法設計測試用例
在面向對象的軟件開發中,事件觸發機制是編程中經常遇到的。
(一)場景法原理
現在的軟件幾乎都是用事件觸發來控制流程的。像GUI軟件、遊戲等。事件觸發時的情景形成了場景,而同一事件不同的觸發順序和處理結果就形成了事件流。這種在軟件設計方面的思想可以引入到軟件測試中,可以生動地描繪出事件觸發時的情景,有利於設計測試用例,同時使測試用例更容易理解和執行。
在測試一個軟件的時候,在場景法中,測試流程是軟件功能按照正確的事件流實現的一條正確流程,那麽我們把這個稱為該軟件的基本流;而凡是出現故障或缺陷的過程,就用備選流加以標註,這樣的話,備選流就可以是從基本流來的,或是由備選流中引出的。所以在進行圖示的時候,就會發現每個事件流的顏色是不同的。
下面是場景法的基本設計步驟:
- 根據說明,描述出程序的基本流及各項備選流
- 根據基本流和各項備選流生成不同的場景
- 對每一個場景生成相應的測試用例
- 對生成的所有測試用例重新復審,去掉多余的測試用例,測試用例確定後,對每一個測試用例確定測試數據值
(二)場景法例子
1、在線購物系統
我們都在當當網或china-pub華章網上書店都訂購過書籍,整個訂購過程為:用戶登錄到網站後,進行書籍的選擇,當選好自己心儀的書籍後進行訂購,這時把所需圖書放進購物車,等進行結帳的時候,用戶需要登錄自己註冊的帳號,登錄成功後,進行結帳並生成訂單,整個購物過程結束。
那麽我們通過以上的描述,從中確定哪是基本流,哪些是備選流:
基本流 |
用戶登錄到網站,書籍的選擇,進行訂購,把所需圖書放進購物車,等進行結帳的時候,登錄自己的帳號,登錄成功後,生成訂單 |
備選流1 |
帳號不存在 |
備選流2 |
帳號錯誤 |
備選流3 |
密碼錯誤 |
備選流4 |
無選購書籍 |
備選流x |
退出系統 |
根據基本流和備選流來確定場景:
場景1-購物成功 |
基本流 |
|
場景2-帳號不存在 |
基本流 |
備選流1 |
場景3-帳號錯誤 |
基本流 |
備選流2 |
場景4-密碼錯誤 |
基本流 |
備選流3 |
場景5- |
基本流 |
備選流4 |
我們來設計用例
對於每一個場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。
下面顯示了一種通用格式,其中各行代表各個測試用例,而各列則代表測試用例的信息。
本例中,對於每個測試用例,存在一個測試用例ID、條件(或說明)、測試用例中涉及的所有數據元素(作為輸入或已經存在於數據庫中)以及預期結果。
通過從確定執行用例場景所需的數據元素入手構建矩陣。然後,對於每個場景,至少要確定包含執行場景所需的適當條件的測試用例。例如,在下面的矩陣中,V(有效)用於表明這個條件必須是 VALID(有效的)才可執行基本流,而 I(無效)用於表明這種條件下將激活所需備選流。下表中使用的“n/a”(不適用)表明這個條件不適用於測試用例。
測試用例ID |
場景/條件 |
帳號 |
密碼 |
選購書籍 |
預期結果 |
1 |
場景1:購物成功 |
V |
V |
V |
成功購物 |
2 |
場景2:帳號不存在 |
I |
n/a |
n/a |
提示帳號不存在 |
3 |
場景3:帳號錯誤 |
I |
V |
n/a |
提示帳號錯誤,返回基本流步驟2 |
4 |
場景4:密碼錯誤 |
V |
I |
n/a |
提示密碼錯誤,返回基本流步驟3 |
5 |
場景5:無選購書籍 |
V |
V |
I |
提示選購書籍,返回基本流步驟5 |
我們看到以上表中,是把每個場景成立的條件進行了分析,基本上已經明確了測試用例的數量,現在只要把真實數據填充上,那麽整個測試用例就完成了。
測試用例ID |
場景/條件 |
帳號 |
密碼 |
選購書籍 |
預期結果 |
1 |
場景1:購物成功 |
xu |
123456 |
《書》 |
成功購物 |
2 |
場景2:帳號不存在 |
zhang |
n/a |
n/a |
提示帳號不存在 |
3 |
場景3:帳號錯誤 |
zhou |
123456 |
n/a |
提示帳號錯誤,返回基本流步驟2 |
4 |
場景4:密碼錯誤 |
xu |
123$%^ |
n/a |
提示密碼錯誤,返回基本流步驟3 |
5 |
場景5:無選購書籍 |
xu |
123456 |
空 |
提示選購書籍,返回基本流步驟5 |
軟件測試培訓第25天