一.方法簡介
現在的軟件幾乎都是用事件觸發來控制流程的,事件觸發時的情景便形成了場景,而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入到軟件測試中,可以比較生動地描繪出事件觸發時的情景,有利於測試設計者設計測試用例,同時使測試用例更容易理解和執行。
基本流和備選流:如下圖所示,圖中經過用例的每條路徑都用基本流和備選流來表示,直黑線表示基本流,是經過用例的最簡單的路徑。備選流用不同的色彩表示,一個備選流可能從基本流開始,在某個特定條件下執行,然後重新加入基本流中(如備選流1和3);也可能起源於另一個備選流(如備選流2),或者終止用例而不再重新加入到某個流(如備選流2和4)。
二.實戰演習
1. 例子描述
下圖所示是ATM例子的流程示意圖。
2.場景設計:下表所示是生成的場景。
表3-8 場景設計
場景1——成功提款 |
基本流 |
|
場景2——ATM內沒有現金 |
基本流 |
備選流2 |
場景3——ATM內現金不足 |
基本流 |
備選流3 |
場景4——PIN有誤(還有輸入機會) |
基本流 |
備選流4 |
場景5——PIN有誤(不再有輸入機會) |
基本流 |
備選流4 |
場景6——賬戶不存在/賬戶類型有誤 |
基本流 |
備選流5 |
場景7——賬戶餘額不足 |
基本流 |
備選流6 |
注:爲方便起見,備選流3和6(場景3和7)內的循環以及循環組合未納入上表。
3.用例設計
對於這7個場景中的每一個場景都需要確定測試用例。
可以採用矩陣或決策表來確定和管理測試用例。下面顯示了一種通用格式,其中各行代表各個測試用例,而各列則代表測試用例的信息。本示例中,對於每個測試用例,存在一個測試用例ID、條件(或說明)、測試用例中涉及的所有數據元素(作爲輸入或已經存在於數據庫中)以及預期結果。
表3-9 測試用例表
TC(測試用例)ID號 |
場景/條件 |
PIN |
賬號 |
輸入(或選擇)的金額 |
賬面金額 |
ATM內的金額 |
預期結果 |
CW1 |
場景1:成功提款 |
V |
V |
V |
V |
V |
成功提款 |
CW2 |
場景2:ATM內沒有現金 |
V |
V |
V |
V |
I |
提款選項不可用,用例結束 |
CW3 |
場景3:ATM內現金不足 |
V |
V |
V |
V |
I |
警告消息,返回基本流步驟6,輸入金額 |
CW4 |
場景4:PIN有誤(還有不止一次輸入機會) |
I
|
V |
n/a |
V |
V |
警告消息,返回基本流步驟 4,輸入 PIN |
CW5 |
場景4:PIN有誤(還有一次輸入機會) |
I |
V |
n/a |
V |
V |
警告消息,返回基本流步驟 4,輸入 PIN |
CW6 |
場景4:PIN有誤(不再有輸入機會) |
I |
V |
n/a |
V |
V |
警告消息,卡予保留,用例結束 |
4.數據設計
一旦確定了所有的測試用例,則應對這些用例進行復審和驗證以確保其準確且適度,並取消多餘或等效的測試用例。
測試用例一經認可,就可以確定實際數據值(在測試用例實施矩陣中)並且設定測試數據,如表3-10所示。
表3-10 測試用例表
TC(測試用例)ID號 |
場景/條件 |
PIN |
賬號 |
輸入(或選擇)的金額(元) |
賬面 |
ATM內的金額(元) |
預期結果 |
CW1 |
場景1:成功提款 |
4987 |
809-498 |
50.00 |
500.0 |
2 000 |
成功提款。賬戶餘額被更新爲450.00 |
CW2 |
場景2:ATM內沒有現金 |
4987 |
809-498 |
100.00 |
500.0 |
0.00 |
提款選項不可用,用例結束 |
CW3 |
場景3:ATM內現金不足 |
4987 |
809-498 |
100.00 |
500.0 |
70.00 |
警告消息,返回基本流步驟6,輸入金額 |
CW4 |
場景4:PIN有誤(還有不止一次輸入機會) |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息,返回基本流步驟4,輸入PIN |
CW5 |
場景4:PIN有誤(還有一次輸入機會) |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息,返回基本流步驟4,輸入PIN |
CW6 |
場景4:PIN有誤(不再有輸入機會) |
4978 |
809-498 |
n/a |
500.00 |
2 000 |
警告消息,卡予保留,用例結束 |
http://coderarea.net/html/chengxuceshi/ceshijishu/yongliceshi/2009/0215/39900.html