上一篇文章（http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=26#lastpost）我們解決了“What is it”的問題，下面讓我們來討論“How to do”的問題。使用因果圖設計測試用例一般包括下面幾個步驟：
1.1.1. 分析需求
閱讀需求文檔，如果User Case很復雜，盡量將它分解成若干個簡單的部分。這樣做的好處是，不必在一次處理過程中考慮所有的原因。沒有固定的流程說明究竟分解到何種程度才算簡單，需要測試人員根據自己的經驗和業務復雜度具體分析。
1.1.2. 確定原因和結果
在每個已經分解好的塊中，找出哪些是原因，哪些是結果。並且把原因和結果分別畫出來。原因放在一列，結果放在一列 。如下圖所示。
<ignore_js_op>
1.1.3. 確定邏輯關系
繼續分析需求文檔，找出原因和結果之間的關系，用邏輯運算符標出。
1.1.4. 確定約束關系
繼續分析需求，找出原因和原因、結果與結果之間的約束限制，用上面說的約束關系標出。
1.1.5. 把因果圖轉換為決策表
給每個原因分別取真和假二種狀態，用0和1表示。畫一個有限項決策表，列出所有狀態的狀態組合。包含3個原因、2個結果的有限項決策表如下。
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
|
原因
|
1
|
0
|
0
|
0
|
0
|
1
|
1
|
1
|
1
|
|
2
|
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
|
|
3
|
0
|
1
|
0
|
1
|
0
|
1
|
0
|
1
|
|
|
結果
|
1
|
||||||||
|
2
|
|||||||||
圖中淡黃色區域表示各種原因狀態組合的個數，淡藍色區域表示原因之間的狀態組合。嫩綠色區域則表示不同原因組合所對應的結果。
1.1.1. 根據原因給出結果
上面的決策表中，不一定每個原因的狀態組合都是有效的。要根據因果圖中的約束條件，去掉不可能出現的組合，從決策表中標記出來。並給出每個可能的原因組合對應的結果。
1.1.2. 設計測試用例
上一步完成之后，決策表的每一個有效列都對應一個測試用例。
1.2. 舉例說明
下面用幾個例子來說明因果圖的用法。
1.2.1. 例子1
某軟件需求說明書：
某段文本中，第一列字符必須是A或B，第二列字符必須是一個數字，在此情況下進行文件的修改。但如果第一列字符不正確，則給出信息L；如果第二列字符不是數字，則給出信息M。
由於此需求已經非常清晰，所以標准步驟中的第一步省略，從第二步開始分析。
n 確定原因和結果：從大的方面看，第一列和第二列不同的字符會引起不同的結果，所以初步分析原因結果圖如下
|
原因
|
c1 | 第一列字符正確 |
| c2 | 第二列字符是數字 | |
|
結果
|
e1 | 修改文件 |
| e2 | 給出信息L | |
| e3 | 給出信息M |
n 確定因果邏輯關系：如果第一列和第二列都正確，則修改文件；如果第一列不正確，給出信息L；如果第二列不正確，給出M。可以得出下面的因果圖。
<ignore_js_op>
而根據需求描述，原因c1還可以細分為2個原因：第一列字符是A（c11），第一列字符是B（c12）。因此原因c1其實也可以看作成結果。把它用因果圖表示出來如下：
<ignore_js_op>
根據上面的分析，其實總共有3個原因，3個結果。
n 確定約束關系：從需求描述中可知，原因c11和c12不可能同時為真，但可以同時為假，因此滿足排他性約束。這三個結果之間沒有掩碼標記的約束。完整的因果圖如下：
<ignore_js_op>
n 根據因果圖畫決策表：
列出3個原因所有的狀態組合。
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
|
原因
|
c11
|
0
|
0
|
0
|
0
|
1
|
1
|
1
|
1
|
|
c12
|
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
|
|
c2
|
0
|
1
|
0
|
1
|
0
|
1
|
0
|
1
|
|
|
結果
|
e1
|
||||||||
|
e2
|
|||||||||
|
e3
|
|||||||||
n 根據原因分析結果：分析每一種狀態對應的結果，並根據約束關系，去掉不可能出現的狀態。本例的c11和c12滿足排他性約束，所以同時都為1的狀態不會出現。
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
|
原因
|
c11
|
0
|
0
|
0
|
0
|
1
|
1
|
1
|
1
|
|
c12
|
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
|
|
c2
|
0
|
1
|
0
|
1
|
0
|
1
|
0
|
1
|
|
|
結果
|
e1
|
0
|
0
|
0
|
1
|
0
|
1
|
無此可能
|
無此可能
|
|
e2
|
1
|
1
|
0
|
0
|
0
|
0
|
|||
|
e3
|
0
|
0
|
1
|
0
|
1
|
0
|
|||
n 設計測試用例：根據決策表，列出有效的狀態組合和結果，給出對應的測試用例，可以單獨畫一個表，也可以直接加到決策表中。如下圖：
|
|
1
|
2
|
3
|
4
|
5
|
6
|
7
|
8
|
|
|
原因
|
c11
|
0
|
0
|
0
|
0
|
1
|
1
|
1
|
1
|
|
c12
|
0
|
0
|
1
|
1
|
0
|
0
|
1
|
1
|
|
|
c2
|
0
|
1
|
0
|
1
|
0
|
1
|
0
|
1
|
|
|
結果
|
e1
|
0
|
0
|
0
|
1
|
0
|
1
|
無此可能
|
無此可能
|
|
e2
|
1
|
1
|
0
|
0
|
0
|
0
|
|||
|
e3
|
0
|
0
|
1
|
0
|
1
|
0
|
|||
|
測試用例(字符串)
|
aa
cc
|
a3
c3
|
Be
|
B3
|
Aq
|
A4
|
|||
到現在為止，使用因果圖設計測試用例的一個簡單的例子就完成了。
1.2.2. 例子2
再以支付寶認證總流程為例，說明因果圖的實際應用。
支付寶個人認證中，分為兩部分：個人身份認證和銀行卡認證。這兩者都通過后，認為個人認證成功。
個人身份認證需要提交個人基本信息及身份證復印件。
銀行卡認證分為兩種：提現認證和充值認證。
提現認證的流程是：用戶提交正確的銀行帳號——>支付寶給用戶的銀行卡中隨機打款——>用戶確認金額，認證成功。
充值認證的流程是：用戶提交正確的銀行帳號——>充值——>充值完成——>網銀反饋，認證成功。
n 從上面的描述中，我們可以總結出2大原因和一個結果。
原因一：身份認證成功
身份認證成功也是一個中間結果，它也有2個原因，提交基本信息成功和提交身份證成功。
原因二：銀行卡認證成功，包含2個原因：充值認證成功和提現認證成功。這2種原因也可以看做是中間結果，產生結果的原因在需求中可以也能明顯看出來，不再贅述。
一個結果：個人認證成功。
注意：為了簡便起見，我們假設個人信息提交和身份證件提交成功后，身份認證則成功，忽略人工審核過程。
原因和結果表如下：
| 原因 | c11 | 個人基本信息提交成功 |
| c12 | 個人身份證件提交成功 | |
| 原因 | c221 | 充值認證的銀行帳號提交成功 |
| c222 | 充值成功 | |
| c223 | 網銀反饋成功 | |
| 原因 | c211 | 提現認證的銀行帳號提交成功 |
| c212 | 支付寶打款成功 | |
| c213 | 用戶確認成功 | |
| 中間結果 | c21 | 銀行卡提現認證成功 |
| c22 | 銀行卡充值認證成功 | |
| 中間結果 | c1 | 身份認證成功 |
| c2 | 銀行卡認證成功 | |
|
結果
|
e1 | 個人認證成功 |
n 確定因果邏輯關系
對於因果關系較為的復雜的邏輯，通過結果向前推原因是一個不錯的方法。
認證成功：身份認證成功和銀行卡認證同時為真，認證成功才為真。
身份認證成功：基本信息和身份證件同時為真，身份認證成功才為真。
銀行卡認證：提現認證和充值認證有一個成功，銀行卡認證則成功。
提現認證、充值認證都是所有的原因都為真時，自己才為真。
n 確定約束關系
從業務流程可知：提現認證和充值認證是二擇一的，滿足唯一性約束條件。而充值認證的三個原因，有流程上的先后順序，滿足必要性約束條件。同樣，提現認證的三個原因也滿足必要性約束條件。
根據約束關系，我們畫出因果圖如下：
<ignore_js_op>
n 畫決策表及設計測試用例的過程略。
使用因果圖的好處
總上所述，我認為因果圖最大的好處有2點：
n 考慮了多個輸入之間的相互組合、相互制約關系。
n 幫助我們按一定步驟，高效率地選擇測試用例。
http://www.bcbxhome.com/bcbx/forum.php?mod=viewthread&tid=27&fromuid=27
(出處: 編測編學軟件測試)