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

Posted 2021-03-07 zihkj

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