1. 程式人生 > >黑盒測試用例設計-錯誤推測和因果圖方法

黑盒測試用例設計-錯誤推測和因果圖方法

9.png sub png str 二義性 生成 當前 其中 關系

3.錯誤推測方法

基於經驗和直覺,找出程序中你認為可能出現的錯誤,有針對性地設計測試用例。經驗可能來自於在對某項業務的測試較多,也可以來自於售後用戶的反饋意見,或者從故障管理庫中整理bug。梳理出產品以往哪些地方容易出現問題,問題越多的地方,潛在的bug也就越多。

另外,在項目測試過程中,針對非用例所發現的問題,如通過探索測試、隨機測試等方法發現的或售後反饋的問題,如果具有普遍性,可以將其轉化為用例,作為當前用例庫的經驗用例補充。

4.因果圖方法

前面介紹的等價類劃分法和邊界值分析法都是著重考慮輸入條件的羅列,並沒有考慮到輸入的各種組合,也沒有考慮各個輸入之間的相互制約關系。如果在測試時考慮全部輸入條件的各種組合,可能組合數將是天文數字。因此必須考慮描述多種條件的組合的合理性,這就需要利用因果圖。

在軟件工程中,有些程序的功能可以用判定表的形式來表示,並根據輸入條件的組合情況規定相應的操作。判定表的每一列對應一條測試用例,以便保證測試程序在輸入條件的某種組合下,操作是正確的。

例如:彩信發送時,聯系人&&附件&&文本相互制約能力,等價類劃分法和邊界值分析方法就變得不適用了。

技術分享

(1) 因果圖的設計方法

因果圖設計圖從【自然語言書寫的程序規格說明】的描述中,找出因(輸入條件)和果(輸出或程序狀態的改變),通過因果圖轉換為判定表。

步驟如下:

① 分析【程序規格說明】的描述中,哪些是原因、結果。原因常是輸入條件或是輸入條件的等價類,而結果是輸出條件。

② 分析【程序規格說明】的描述中語義內容,並將其表示成連接各個原因與各個結果的“因果圖”。

③ 標明約束條件。由於業務邏輯等現實因素,有些原因和結果的組合是不可能出現的。因果圖中,使用若幹標準的符號標明約束條件。

④ 因果圖轉換成判定表。

⑤ 判定表的每一列設計出一條測試用例。

因果圖生成的測試用例包括了所有輸入數據的TRUE與FALSE的情況,構成的測試用例數目達到最少。且測試用例數目隨入數據數目的增加而增加。

說明:在因果圖中,用Ci表示原因,Ei表示結果,各節點狀態可取“0”或“1”值。“0”表示不出現,“1”表示出現。如下圖,原因與結果之間的關系:

技術分享

① 恒等:若原因出現,則結果出現;若原因不出現,則結果也不出現;

② 非(~):若原因出現,則結果不出現;若原因不出現,則結果出現;

③ 或(∨):若幾個原因中有1個出現,則結果出現;若幾個原因都不出現,則結果不出現;

④ 與(∧):若幾個原因都出現,結果才出現。若其中有1個原因不出現,則結果不出現。

原因與原因之間、結果與結果之間可能存在的約束關系,因果圖提供了以下約束條件的符號。

技術分享

原因與原因之間、結果與結果之間可能存在的約束關系,因果圖提供了以下約束條件的符號。

① E(互斥):表示a、b兩個原因不會同時成立,兩個中最多有一個可能成立。

② I(包含):表示a、b、c這3個原因中至少有一個必須成立。

③ O(唯一):表示a和b當中必須有一個,且僅有一個成立;

④ R(要求):表示當a出現時,b必須也出現。a出現時不可能b不出現。

⑤ M(屏蔽):表示當a是1時,b必須是0。而當a為0時,b的值不定。

(2) 因果圖測試用例

見文章末尾

(3) 因果圖法優缺點

·優點:

① 考慮到了輸入情況的各種組合以及各個輸入情況之間的相互制約關系。

② 能夠幫助測試人員按照一定的步驟,高效率的開發測試用例。

③ 因果圖法是將自然語言規格說明轉化成形式語言規格說明的一種嚴格的方法,可以指出規格說明存在的不完整性和二義性。

·缺點:

① 因果圖來設計測試用例時,作為輸入條件的原因與輸出結果之間的因果關系,有時很難從軟件需求規格說明中得到。

② 而且往往因果關系非常龐大,以至於據此因果圖而得到的測試用例數目多的驚人,給軟件測試,特別是手工測試帶來沈重的負擔,為了有效地,合理地減少測試的工時與費用,可利用正交實驗設計方法進行測試用例的設計。

感興趣的同學可以進一步查看因果圖用例的例題:

例題1:

技術分享

例題2:

技術分享

黑盒測試用例設計-錯誤推測和因果圖方法