測試用例設計————場景分析法
定義
分析軟件應用的場景,從用戶的角度出發,從場景的角度來設計測試用例,是一種面向用戶的測試用例設計方法。
優點:實用性強,有效,設計出來的用例有價值
缺點:可能使用的場景不一定能對時間系列進行全面的分析,設計出來的用例不完整。
場景分析是通過描述經用例路徑來確定的過程,這個流程經過要從用例開始到結束遍歷其中所有基本流:直黑線表示基本流,是最基本、最簡單的路徑;(軟件功能按照正確的事件流實現的一條正確流程無任何錯誤,程序從開始直到結束)。
遵循上圖中每個經過用例的可能路徑,可以確定不同的用例場景。從基本流開始,再將基本流和備選流結合起來,可以確定以下用例場景:
場景1 | 基本流 | |||
---|---|---|---|---|
場景2 | 基本流 | 備選流1 | ||
場景3 | 基本流 | 備選流1 | 備選流2 | |
場景4 | 基本流 | 備選流3 | ||
場景5 | 基本流 | 備選流3 | 備選流1 | |
場景6 | 基本流 | 備選流3 | 備選流1 | 備選流2 |
場景7 | 基本流 | 備選流4 | ||
場景8 | 基本流 | 備選流3 | 備選流4 |
注:為方便起見,場景 5、6 和 8 只描述了備選流 3 指示的循環執行一次的情況。
用場景分析法設計測試用例的步驟:
1.根據說明,畫出流程圖,確定基本流和備選流;
2.根據基本流和各項備選流確定場景;
3.對每一個場景生成測試用例;
4.對生成的所有測試用例重新復審,去掉多余的測試用例,測試用例確定后,對每一個測試用例確定測試數據值。
用例場景示例
用戶登錄到網站后,進行書籍的選擇,當選好自己心儀的書籍后進行訂購,這時把所需圖書放進購物車,等進行結帳的時候,用戶需要登錄自己注冊的帳號,登錄成功后,進行付款交易,交易成功后,生成訂購單,整個購物過程結束。
第一步:畫出流程圖,確定基本流和備選流;
基本流:登錄在線網站→選擇課程/方案,放入購物車→登錄賬號→付款→生成訂單
備選流1:用戶不存在→注冊用戶
備選流2:密碼不正確
備選流3:賬戶余額不足→充值
備選流 4 :賬戶無金額→充值
第二步:根據基本流和各項備選流確定場景;
場景1(成功購物):基本流;
場景2(賬戶不存在):基本流 備選流1
場景3(賬戶密碼錯誤):基本流 備選流2
場景4(賬戶余額不足):基本流 備選流3
場景 5(賬戶無金額):基本流 備選流4
第三步:對每一個場景生成測試用例;
用例編號 | 場景描述 | 步驟描述 | 輸入 | 預期結果 |
---|---|---|---|---|
1 | 場景1:成功購物 | 登錄HB | ||
2 | 選擇方案/視頻,放入購物車 | |||
3 | 登錄賬號 | |||
4 | 付款 | |||
5 | 生成訂單 | 成功購物 | ||
場景2:賬戶不存在 | 登錄HB | |||
選擇方案/視頻,放入購物車 | ||||
登錄賬號 | ||||
賬號不存在,注冊用戶 | 提示賬號不存在,返回基本流程步驟4 | |||
登錄賬號 | ||||
付款 | ||||
生成訂單 | ||||
場景3:賬戶密碼錯誤 | 登錄HB | |||
選擇方案/視頻,放入購物車 | ||||
登錄賬號 | ||||
密碼錯誤,重新輸入登錄 | 提示賬號密碼錯誤,返回基本流步驟4 | |||
付款 | ||||
生成訂單 | ||||
場景4:賬戶余額不足 | 登錄HB | |||
選擇方案/視頻,放入購物車 | ||||
登錄賬號 | ||||
付款 | ||||
余額不足,充值 | 提示賬號余額不足,請充值;返回基本流步驟5 | |||
付款 | ||||
生成訂單 | ||||
場景5:賬戶無金額 | 登錄HB | |||
選擇方案/視頻,放入購物車 | ||||
登錄賬號 | ||||
付款 | ||||
賬號無金額,充值 | 提示賬號無余額,請充值;返回基本流步驟5 | |||
付款 | ||||
生成訂單 |
第四步:對生成的所有測試用例重新復審,補充測試數據值
用例編號 | 場景描述 | 步驟描述 | 輸入 | 預期結果 |
---|---|---|---|---|
1 | 場景1:成功購物 | 登錄HB | ||
2 | 選擇方案/視頻,放入購物車 | 總價:80元人民幣 | ||
3 | 登錄賬號 | 賬號:張三,密碼:123456 | ||
4 | 付款 | 賬號余額:200元 | ||
5 | 生成訂單 | 成功購物 | ||
場景2:賬戶不存在 | 登錄HB | |||
選擇方案/視頻,放入購物車 | 總價:80元人民幣 | |||
登錄賬號 | 賬號:李四1,密碼:123456 | |||
賬號不存在,注冊用戶 | 提示賬號不存在,返回基本流程步驟4 | |||
登錄賬號 | ||||
付款 | 賬號余額:200元 | |||
生成訂單 | ||||
場景3:賬戶密碼錯誤 | 登錄HB | |||
選擇方案/視頻,放入購物車 | 總價:80元人民幣 | |||
登錄賬號 | 賬號:張三,密碼:12345 | |||
密碼錯誤,重新輸入登錄 | 提示賬號密碼錯誤,返回基本流步驟4 | |||
付款 | 賬號余額:200元 | |||
生成訂單 | ||||
場景4:賬戶余額不足 | 登錄HB | |||
選擇方案/視頻,放入購物車 | 總價:80元人民幣 | |||
登錄賬號 | 賬號:王五,密碼:123456 | |||
付款 | ||||
余額不足,充值 | 賬號余額:30元 | 提示賬號余額不足,請充值;返回基本流步驟5 | ||
付款 | ||||
生成訂單 | ||||
場景5:賬戶無金額 | 登錄HB | |||
選擇方案/視頻,放入購物車 | 總價:80元人民幣 | |||
登錄賬號 | 賬號:張華,密碼:123456 | |||
付款 | ||||
賬號無金額,充值 | 賬號余額:無余額 | 提示賬號無余額,請充值;返回基本流步驟5 | ||
付款 | ||||
生成訂單 |
提款測試用例
基本流/備用流 | 流程描述 |
---|---|
基本流 | 本用例的開端是 ATM 處於准備就緒狀態。 准備提款 - 客戶將銀行卡插入 ATM 機的讀卡機。 驗證銀行卡 - ATM 機從銀行卡的磁條中讀取帳戶代碼,並檢查它是否屬於可以接收的銀行卡。 輸入 PIN - ATM 要求客戶輸入 PIN 碼(4 位) 驗證帳戶代碼和 PIN - 驗證帳戶代碼和 PIN 以確定該帳戶是否有效以及所輸入的 PIN 對該帳戶來說是否正確。對於此事件流,帳戶是有效的而且 PIN 對此帳戶來說正確無誤。 ATM 選項 - ATM 顯示在本機上可用的各種選項。在此事件流中,銀行客戶通常選擇“提款”。 輸入金額 - 要從 ATM 中提取的金額。對於此事件流,客戶需選擇預設的金額(10 美元、20 美元、50 美元或 100 美元) 。 授權-ATM 通過將卡 ID、PIN、金額以及帳戶信息作為一筆交易發送給銀行系統來啟動驗證過程。對於此事件流,銀行系統處於聯機狀態,而且對授權請求給予答復,批准完成提款過程,並且據此更新帳戶余額。 出鈔 - 提供現金。 返回銀行卡 - 銀行卡被返還。 收據 - 打印收據並提供給客戶。ATM 還相應地更新內部記錄。 用例結束時 ATM 又回到准備就緒狀態。 |
備選流 1 - 銀行卡無效 | 在基本流步驟 2 中 - 驗證銀行卡,如果卡是無效的,則卡被退回,同時會通知相關消息。 |
備選流 2 - ATM 內沒有現金 | 在基本流步驟 5 中 - ATM 選項,如果 ATM 內沒有現金,則“提款”選項將無法使用。 |
備選流 3 - ATM 內現金不足 | 在基本流步驟 6 中- 輸入金額,如果 ATM 機內金額少於請求提取的金額,則將顯示一則適當的消息,並且在步驟 6 - 輸入金額處重新加入基本流。 |
備選流 4 - PIN 有誤 | 在基本流步驟 4 中- 驗證帳戶和 PIN,客戶有三次機會輸入 PIN。 如果 PIN 輸入有誤,ATM 將顯示適當的消息;如果還存在輸入機會,則此事件流在步驟 3 - 輸入 PIN 處重新加入基本流。 如果最后一次嘗試輸入的 PIN 碼仍然錯誤,則該卡將被 ATM 機保留, 同時 ATM 返回到准備就緒狀態,本用例終止。 |
備選流 5 - 帳戶不存在 | 在基本流步驟 4 中 - 驗證帳戶和 PIN,如果銀行系統返回的代碼表明找不到該帳戶或禁止從該帳戶中提款,則 ATM 顯示適當的消息並且在步驟 9 - 返回銀行卡處重新加入基本流。 |
備選流 6 - 帳面金額不足 | 在基本流步驟 7 - 授權中,銀行系統返回代碼表明帳戶余額少於在基本流步驟 6 - 輸入金額內輸入的金額,則 ATM 顯示適當的消息並且在步驟 6 - 輸入金額處重新加入基本流。 |
備選流 7 - 達到每日最大的提款 金額 | 在基本流步驟7- 授權中, 銀行系統返回的代碼表明包括本提款請求在內,客戶已經或將超過在 24 小時內允許提取的最多金額,則 ATM 顯示適當的消息並在步驟 6 - 輸入金額上重新加入基本流。 |
備選流 x - 記錄錯誤 | 如果在基本流步驟 10 - 收據中,記錄無法更新,則 ATM 進入“安全模式”,在此模式下所有功能都將暫停使用。同時向銀行系統發送一條適當的警報信息表明 ATM 已經暫停工作。 |
備選流 y - 退出 | 客戶可隨時決定終止交易(退出) 。交易終止,銀行卡隨之退出。 |
備選流 z - “翹起” | ATM 包含大量的傳感器,用以監控各種功能,如電源檢測器、不同的門和出入口處的測壓器以及動作檢測器等。在任一時刻,如果某個傳感器被激活,則警報信號將發送 給警方而且 ATM 進入“安全模式”,在此模式下所有功能都暫停使用,直到采取適當的重啟/重新初始化的措施。 |
第一次迭代中,根據迭代計划,我們需要核實提款用例已經正確地實施。此時尚未實施整個用例,只實
施了下面的事件流:
基本流 - 提取預設金額(10 美元、20 美元、50 美元、100 美元)
備選流 2 - ATM 內沒有現金
備選流 3 - ATM 內現金不足
備選流 4 - PIN 有誤
備選流 5 - 帳戶不存在/帳戶類型有誤
備選流 6 - 帳面金額不足
以從這個用例生成下列場景
場景描述 | 基本流/備用流 | 基本流/備用流 |
---|---|---|
場景1 - 成功的提款 | 基本流 | |
場景2 - ATM 內沒有現金 | 基本流 | 備選流2 |
場景3 - ATM 內現金不足 | 基本流 | 備選流3 |
場景4 - PIN 有誤(還有輸入機會) | 基本流 | 備選流4 |
場景5 - PIN 有誤(不再有輸入機會) | 基本流 | 備選流4 |
場景 6 - 帳戶不存在/帳戶類型有誤 | 基本流 | 備選流 5 |
場景 7 - 帳戶余額不足 | 基本流 | 備選流 6 |
表1-3 提款場景
注:為方便起見,備選流 3 和 6(場景 3 和 7)內的循環以及循環組合未納入上表。
對於這 7 個場景中的每一個場景都需要確定測試用例。可以采用矩陣或決策表來確定和管理測試用例。下面顯示了一種通用格式,其中各行代表各個測試用例,而各列則代表 測試用例的信息。本示例中,對於每個測試用例,存在一個測試用例 ID、條件(或說明)、測試用例中涉及的所有數據元素(作為輸入或已經存在於數據庫中)以及預期結果。
通過從確定執行用例場景所需的數據元素入手構建矩陣。然后,對於每個場景,至少要確定包含執行場景所需的適當條件的測試用例。例如,在下面的矩陣 中,V(有效)用於表明這個條件必須是 VALID(有效的)才可執行基本流,而 I(無效)用於表明這種條件下將激活所需備選流。下表中使用的“n/a”(不適用)表明這個條件不適用於測試用例。
表1-4 用例矩陣
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 | 警告消息,卡予保留,用例結束 |
在上面的矩陣中,六個測試用例執行了四個場景。對於基本流,上述測試用例 CW1 稱為正面測試用例。它一直沿着用例的基本流路徑執行,未發生任何偏差。基本流的全面測試必須包括負面測試用例,以確保只有在符合條件的情況下才執行基本 流。這些負面測試用例由 CW2 至 6 表示(陰影單元格表明這種條件下需要執行備選流)。雖然 CW2 至 6 對於基本流而言都是負面測試用例,但它們相對於備選流 2 至 4 而言是正面測試用例。而且對於這些備選流中的每一個而言,至少存在一個負面測試用例(CW1 - 基本流)。
每個場景只具有一個正面測試用例和負面測試用例是不充分的,場景 4 正是這樣的一個示例。要全面地測試場景 4 - PIN 有誤,至少需要三個正面測試用例(以激活場景 4):
輸入了錯誤的 PIN,但仍存在輸入機會,此備選流重新加入基本流中的步驟 3 - 輸入 PIN。
輸入了錯誤的 PIN,而且不再有輸入機會,則此備選流將保留銀行卡並終止用例。
最后一次輸入時輸入了“正確”的 PIN。備選流在步驟 5 - 輸入金額處重新加入基本流。
注:在上面的矩陣中,無需為條件(數據)輸入任何實際的值。以這種方式創建測試用例矩陣的一個優點在於容易看到測試的是什么條件。由於只需要查看 V 和 I(或此處采用的陰影單元格),這種方式還易於判斷是否已經確定了充足的測試用例。從上表中可發現存在幾個條件不具備陰影單元格,這表明測試用例還不完 全,如場景 6 - 不存在的帳戶/帳戶類型有誤和場景 7 - 帳戶余額不足就缺少測試用例。
一旦確定了所有的測試用例,則應對這些用例進行復審和驗證以確保其准確且適度,並取消多余或等效的測試用例。
測試用例一經認可,就可以確定實際數據值(在測試用例實施矩陣中)並且設定測試數據。
表1-5 實際用例
TC ( 測試用例)ID 號 | 場景/條件 | PIN | 帳號 | 輸入的金額或 選擇的金額 | 帳面金額 | ATM 內的金額 | 預期結果 |
---|---|---|---|---|---|---|---|
CW1. | 場景1 - 成功的提款 | 4987 | 809 - 498 | 50.00 | 500.00 | 2,000 | 成功的提款。帳戶 余額被更新為450.00 |
CW2. | 場景2 - ATM 內沒有現金 | 4987 | 809 - 498 | 100.00 | 500.00 | 0.00 | 提款選項不可用,用例結束 |
CW3. | 場景3 - ATM 內現金不足 | 4987 | 809 - 498 | 100.00 | 500.00 | 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 | 警告消息,卡予保留, 用例結束 |
以上測試用例只是在本次迭代中需要用來驗證提款用例的一部分測試用例。需要的其他測試用例包括:
場景 6 - 帳戶不存在/帳戶類型有誤:未找到帳戶或帳戶不可用
場景 6 - 帳戶不存在/帳戶類型有誤:禁止從該帳戶中提款
場景 7 - 帳戶余額不足:請求的金額超出帳面金額
在將來的迭代中,當實施其他事件流時,在下列情況下將需要測試用例:
無效卡(所持卡為掛失卡、被盜卡、非承兌銀行發卡、磁條損壞等).
無法讀卡(讀卡機堵塞、脫機或出現故障).
帳戶已消戶、凍結或由於其他方面原因而無法使用.
ATM 內的現金不足或不能提供所請求的金額(與 CW3 不同,在 CW3 中只是一種幣值不足,而不是所有幣值都不足).
無法聯系銀行系統以獲得認可.
銀行網絡離線或交易過程中斷電.
分析
what?
分析軟件應用場景,從用戶角度出發,從場景角度設計測試用例,是一種面向用戶的測試用例設計方法。
- 基本流:經過用例的最簡單路徑(正常流程)
- 備選流:一個備選流可以從基本流開始,在某個特定條件下執行,然后重新加入基本流中;也可以起源於另一個備選流,或終止用例。(當備選流不再加入基本流時,備選流一般為錯誤流程)
why?
從用戶角度出發,是一種面向用戶的測試用例設計方法。
how?
1.根據需求,描述出程序的基本流以及各項備選流
2.根據基本流和各項備選流生成不同的場景
3.對每一個場景生成相應的測試用例
4.對生成的測試用例重新復審,去掉多余的測試用例
5.測試用例確定后,為每一個測試用例確定測試數據值