上一篇文章（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
(出处: 编测编学软件测试)