因果图设计测试用例的步骤

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

相关推荐