實驗3 因果圖法與用例設計
1. 實驗目標
(1)能夠依據需求分析原因和結果。
(2)能夠繪制因果圖,標注相應的關系符號。
(3)能夠將因果圖轉化成判定表。
(4)能夠使用因果圖法進行測試用例設計。
2. 背景知識
需求:某旅館住宿系統可辦理房間選定、房款支付及房間管理相關業務。其需求描述如下:游客的情況分為支付全部房款(即預期入住天數內所有房款)和支付部分房款(僅支付定金)。可選擇“單人間”“雙人間”或“豪華間”,若某類型房間有空房,則相應類型的房間被開啟;若某類型房間無空房,則“房間已滿”提示燈亮。無空房時,支付部分房款的游客選擇該類型的房間,則該類型房間不被開啟且提示辦理退款。若此期間,該類型房間有客人退房,則“房間已滿”提示燈滅,該類型房間的某間房被開啟的同時提示房款不足。
界面原型:旅館住宿系統業務辦理頁面如圖3.1所示。

圖3.1 旅館住宿系統業務辦理頁面
首先,基于上述需求,思考采用等價類劃分法如何進行測試用例設計。讀者采用等價類劃分法進行上述需求的測試用例設計時,不難發現設計出的測試用例存在如下特點。其一,數量甚少。其二,僅著重考慮了各項輸入條件,并未考慮輸入條件的各種組合情況。例如,選擇不同的房款支付方式及房間類型,在“房間已滿”和“房間空余”的不同前提下,產生的結果會有所差異,此情況在等價類劃分法中并未涉及和考慮。其三,未考慮各輸入情況之間的相互制約關系。例如,“支付房款”與“支付定金”不能同時選擇,最多只能選擇一個;“單人間”“雙人間”和“豪華間”不能同時選擇,最多僅能選擇一個等,上述列舉的兩種情況在等價類劃分法中也并未涉及和考慮。
再如某保險公司的預約投保系統,界面原型如圖3.2所示。讀者針對此界面原型采用等價類劃分法進行測試用例設計時,同樣會忽略多種關系不能同時存在的情況。例如,“稱謂”字段中“先生”與“女士”不能同時成立,最多僅能成立兩者之一;“所在地”字段中,當選擇某市時,該市所屬省份必須同步出現,不能有選擇某市后該市所屬省份不出現的情況發生;“聯系電話”字段中,“固定電話”“小靈通”及“手機號”至少填寫一個即可。

圖3.2 預約投保系統界面原型
讀者充分理解了上述兩實例后,則不難理解僅采用等價類劃分法并不能很好地處理“當系統中輸入項之間以及輸入項與輸出之間存在多種關系”時的測試用例設計問題,這正是引入因果圖法的主要原因。
因果圖法是從需求中找出因(輸入條件)和果(輸出或程序狀態的改變),通過分析輸入條件之間的關系(組合關系、約束關系等)以及輸入和輸出之間的關系繪制出因果圖,再轉化成判定表,從而設計出測試用例的方法,如圖3.3所示。不難理解,該方法主要適用于各種輸入條件之間存在某種相互制約關系或輸出結果依賴于各種輸入條件的組合時的情況。

圖3.3 因果圖法介紹
下面以圖3.4為例,對因果圖進行初步介紹。
通過觀察可以發現,圖3.4中無法識別的符號較多,如E、∨等。下面結合圖3.5,對因果圖中的常用符號含義進行介紹。

圖3.4 因果圖初識

圖3.5 因果圖符號
因果圖符號的種類繁多,常用符號介紹如下。
(1)CI:原因。I取“0”表示狀態不出現,“1”表示狀態出現,若有多狀態,可用大于1的多個值表示。
(2)EI:結果。I取“0”表示狀態不出現,“1”表示狀態出現,若有多狀態,可用大于1的多個值表示。
(3)恒等:原因結果同時出現。
(4)非:原因出現,結果不出現;原因不出現,結果出現。
(5)或:只要有一個原因出現,結果就出現;原因都不出現,結果就不出現。
(6)且:原因都出現,結果才出現。
注意:圖3.5所示的每個結點表示一個狀態。
為了表示原因與原因之間、結果與結果之間可能存在的約束條件,因果圖中通常還附加一些表示約束條件的符號,如圖3.6所示。

圖3.6 帶約束條件的因果圖符號
約束符號也包含多種類型,分別從輸入考慮和從輸出考慮兩方面進行歸類如下。
(1)從輸入考慮。
①E(互斥/異或):表示a、b兩個原因不會同時成立,最多只有一個成立。
②I(包含):a、b、c三個原因中至少有一個必須成立。
③O(唯一):a、b兩個原因中必須有一個,且僅有一個成立。
④R(要求):當a出現時,b必須也出現,不可能出現a而不出現b。
(2)從輸出考慮。
M(強制或屏蔽):a是1時,b必須是0;a是0時,b的值不確定。
下面再次對某保險公司的預約投保系統的“預約投保”頁面進行分析,結果如圖3.7所示。

圖3.7 預約投保頁面各字段關系分析
到目前為止,已經強調了因果圖中各符號的含義,究竟如何使用因果圖法進行測試用例設計呢?可參照如下步驟。
(1)分析需求,提取原因和結果,并賦予標識符;
(2)分析需求,提取因果關系,并表示成因果圖;
(3)標明因果圖中的約束條件;
(4)將因果圖轉換成判定表;
(5)為判定表中每一列表示的情況設計測試用例。
注意:原因常常是輸入條件或輸入條件的等價類;結果常常是輸出條件。
下面以旅館住宿系統為例,針對忽略房間狀態和考慮房間狀態兩種不同的需求情況,采用因果圖法進行測試用例設計。
3. 實驗任務
【任務3.1】 旅館住宿系統測試用例設計(忽略房間狀態)。
需求:某旅館住宿系統可辦理房間選定、房款支付及房間管理相關業務,系統默認房間資源始終保持充足的狀態。其需求描述如下:游客的情況分為支付全部房款(即預期入住天數內所有房款)和支付部分房款(僅支付定金)。選擇“單人間”“雙人間”或“豪華間”,則相應類型的房間被開啟。若游客支付的房款不足,則在開啟房間的同時系統提示房款不足。
界面原型:旅館住宿系統業務辦理頁面(忽略房間狀態)如圖3.8所示。

圖3.8 旅館住宿系統業務辦理頁面(忽略房間狀態)
問題:采用因果圖法進行測試用例設計。
前提條件:對需求進行分析后可發現,該需求的輸入項與輸入項之間以及輸入項與結果之間存在多種關系,此時采用因果圖法進行測試用例設計更為合適。
第1步,分析需求,找出原因和結果,即輸入和輸出。
原因:
(1)游客支付全部房款。
(2)游客支付部分房款。
(3)游客選擇“單人間”。
(4)游客選擇“雙人間”。
(5)游客選擇“豪華間”。
結果:
(21)該類型房間被打開且提示房款支付不足。
(22)某單人間被打開。
(23)某雙人間被打開。
(24)某豪華間被打開。
第2步,繪制因果圖,并標注相應的關系符號,如圖3.9所示。圖3.9中,所有原因結點顯示于左側,所有結果結點顯示于右側,中間結點表示處理的中間狀態。

圖3.9 業務辦理_因果圖(忽略房間狀態)
中間結點:
(11)已支付房款。
(12)已選擇房間類型。
注意:中間結點的設立并非必須要完成的工作,但是它的設立可使繪制出的因果圖更簡單和美觀,閱讀起來也較為方便。
第3步,轉換成判定表,如表3.1所示。
表3.1 業務辦理_判定表(忽略房間狀態)

第4步,可將表3.1作為確定測試用例的依據。設計測試用例如表3.2所示。
表3.2 業務辦理_測試用例設計(忽略房間狀態)

【任務3.2】 旅館住宿系統測試用例設計(考慮房間狀態)。
需求:某旅館住宿系統可辦理房間選定、房款支付及房間管理相關業務。其需求描述如下:游客的情況分為支付全部房款(即預期入住天數內所有房款)和支付部分房款不足(僅支付定金)。可選擇“單人間”“雙人間”或“豪華間”,若某類型房間有空房,則相應類型的房間被開啟;若某類型房間無空房,則“房間已滿”提示燈亮。無空房時,支付部分房款的游客選擇該類型的房間,則該類型房間不被開啟且提示辦理退款。若此期間,該類型房間有客人退房,則“房間已滿”提示燈滅,該類型房間的某間房被開啟的同時提示房款不足。
界面原型:旅館住宿系統業務辦理頁面(考慮房間狀態)如圖3.10所示。

圖3.10 旅館住宿系統業務辦理頁面(考慮房間狀態)
問題:采用因果圖法進行測試用例設計。
前提條件:對需求進行分析后可發現,該需求的輸入項與輸入項之間以及輸入項與結果之間存在多種關系,此時采用因果圖法進行測試用例設計更為合適。
第1步,分析需求說明,找出原因和結果,即輸入和輸出。
原因:
(1)該類型房間有空房。
(2)游客支付部分房款。
(3)游客支付全部房款。
(4)游客選擇“單人間”。
(5)游客選擇“雙人間”。
(6)游客選擇“豪華間”。
結果:
(21)該類型房間“房間已滿”燈亮。
(22)提示辦理退款。
(23)提示房款不足。
(24)某單人間被打開。
(25)某雙人間被打開。
(26)某豪華間被打開。
第2步,繪制因果圖,并標注相應關系符號,如圖3.11所示。圖3.11中,所有原因結點顯示于左側,所有結果結點顯示于右側,中間結點表示處理的中間狀態。

圖3.11 業務辦理_因果圖(考慮房間狀態)
中間結點:
(11)支付房款不足且已選擇房間類型。
(12)已選擇房間類型。
(13)該類型房間有空房并且提示房款支付不足。
(14)房款已支付。
注意:中間結點的設置并非必須要完成的工作,但是設立中間結點可使繪制出的因果圖更簡單和美觀,閱讀起來也較為方便。
第3步,轉換成判定表,如表3.3和表3.4所示。
表3.3 業務辦理_判定表一(考慮房間狀態)

表3.4 業務辦理_判定表二(考慮房間狀態)

注意:
①轉化判定表時,通過分析,可先將違反約束條件的組合省略,再列出判定表,則可大大減少工作量。本任務組合項較多,為避免講解不充分,特列舉出所有組合。
②表3.3和表3.4中未列出中間結點的取值情況,讀者可自行列舉。
第4步,在判定表中,空白部分表示因違反約束條件而不可能出現的情況,故不對此進行測試用例設計。將表3.3和表3.4作為確定測試用例的依據。設計測試用例如表3.5所示。
表3.5 業務辦理_測試用例設計(考慮房間狀態)

注意:需求中描述當房間沒有空余時,“房間已滿”燈亮。但是,讀者會發現界面原型中并未顯示“燈”。在此,值得一提的是,實際項目中界面原型可能會采用其他方式來實現需求說明中的要求,所采取的表現方式或許更加易于理解和使用。建議開發人員確定界面原型后,及時與客戶進行溝通并確認,便于后續工作在此基礎上順利開展。
思考:若此處采用等價類劃分法設計測試用例,又該如何考慮呢?
4. 拓展練習
【練習3.1】 采用因果圖法針對以下需求進行測試用例設計。
需求:輸入的第一個字符必須是#或?,第二個字符必須是一個數字,此情況下進行文件的修改。若第一個字符不是#或?,則給出信息N;若第二個字符不是數字,則給出信息M。
【練習3.2】 采用因果圖法針對以下需求進行測試用例設計。
需求:有一個自動售貨機,若投入5角或1元的硬幣,按下“橙汁”或“啤酒”按鈕,則相應的飲料就送出來。若售貨機沒有零錢,則顯示“零錢找完”的紅燈亮,這時再投入1元硬幣并按下按鈕后,飲料不送出來而且1元硬幣也退出來;若售貨機有零錢,則顯示“零錢找完”的紅燈滅,投入1元硬幣并按下按鈕后,在送出飲料的同時退還5角硬幣。
- Practical Data Analysis Cookbook
- Advanced Quantitative Finance with C++
- 數據庫系統教程(第2版)
- Java程序設計:原理與范例
- ServiceNow:Building Powerful Workflows
- GameMaker Essentials
- Node.js區塊鏈開發
- Python一行流:像專家一樣寫代碼
- SCRATCH編程課:我的游戲我做主
- Arduino Electronics Blueprints
- Web前端測試與集成:Jasmine/Selenium/Protractor/Jenkins的最佳實踐
- Instant Pygame for Python Game Development How-to
- Internet of Things with Arduino Cookbook
- 少年小魚的魔法之旅:神奇的Python
- PhoneGap 3.x Mobile Application Development Hotshot