因果图设计测试用例.docx
《因果图设计测试用例.docx》由会员分享，可在线阅读，更多相关《因果图设计测试用例.docx（9页珍藏版）》请在冰豆网上搜索。
因果图设计测试用例
测试用例设计方法的介绍—因果图
前言为什么需要测试用例
测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。
这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测试。
而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容，这样就很容易出现测试不全面的问题。
再者，现有的软件开发大多都是迭代式进行的，需要对同一个功能反复测试多遍。
很有可能第一轮测试得比较全面，当进行第二轮的时候，可能也会遗漏某些点。
这种情况下，测试过程是由人控制的，具有盲目性，是不可控制的。
而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。
一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。
这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。
在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。
1.测试用例设计的方法分类
从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。
1.1.黑盒测试
程序的内部逻辑实现对测试人员是透明的。
测试人员只需要根据需求文档来决定程序应该做什么事情，会产生什么样的结果。
测试人员对需求中的每个点进行覆盖测试。
目前流行的黑盒测试设计方法有：
Ø等价类划分
Ø边界值分析
Ø因果图法
Ø场景法
1.2.白盒测试
属于代码级的测试。
测试人员不仅要了解程序要做什么，还要了解程序是如何实现的，根据实现方法设计测试用例。
测试人员需要对代码进行覆盖测试。
由于现在的程序分支、循环都很多，所以完全覆盖代码是不可能的，现在比较常用的设计方法有：
Ø语句覆盖
Ø分支覆盖
Ø条件覆盖
Ø条件组合覆盖
Ø基本路径覆盖
Ø循环覆盖
1.3.灰盒测试
类和接口级的测试。
介于黑盒测试和白盒测试之间，既关心程序输出的正确性，也关心程序的内部逻辑，但这个逻辑不是代码级的。
举例来说，对类或者接口进行测试，不关心代码的实现，只关心每个方法和属性在执行过程中是否正确，这就属于灰盒测试。
2.因果图的具体介绍
2.1.为什么么需要因果图
在黑盒测试中，等价类划分或边界值分析法只考虑了不同的输入和不同的输出之间的关系。
但是如果是各个输入条件之间有很复杂的组合，这二种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测试人员主观的猜测或者分析，具有很大的盲目性。
让我们先来看一个简单的例子。
假设某个软件需求文档中有这样的说明：
第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。
但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
先用等价类来分析，第一列会有三个输入：
A、B、非（AB）的字符。
第二列字符有二个输入：
数字、非数字（为了简便起见，有关数字再细化的问题不做讨论）。
这是一个根据理论进行分析的过程。
但是做完了这一步，并不能得出输出。
也就是说如何分析第一列和第二列的关系，没有明确的理论指导。
实际操作过程中，各个测试人员可能会设计出不同的测试用例。
这个例子还仅仅是一个2个输入条件之间有关系，如果到更复杂的应用中，可能会更多。
如果没有一种方法指导我们的思想，测试用例就会很不全面。
而因果图正好弥补了上述缺点。
我们先来看一下什么叫因果图。
因果图是一种形式化的语言（以图的形式表现），它不仅描述了原因和结果之间的关系，也描述了各个原因之间、各个结果之间复杂关系的组合。
在这里，因就是程序的输入条件，而果则是程序的输出。
正确的使用因果图可以对很复杂的功能逻辑进行分析，设计出高效而简洁的测试用例。
2.2.因果图概念介绍
学习因果图需要的基本知识是：
2.2.1.布尔逻辑运算符
三种常用的运算符是NOT、AND、OR。
还有两种比较少用的是NAND、NOR。
再加上恒等，这六种符号是描述原因和结果之间的逻辑关系的。
下面以图的形式详细说明6种因果逻辑。
c表示原因，e表示结果。
⏹恒等：
如果原因为真，那么结果必定为真。
⏹与：
只有2个原因都为真，那么结果为真。
⏹或：
2个原因中有一个为真时，结果就为真。
⏹非：
只有原因为假，结果才为真。
⏹与非：
先与后非。
⏹或非：
先或后非。
2.2.2.因果图的约束关系表示法
因果图中有4种符号描述原因之间的约束关系，1种符号描述结果之间的约束关系。
下面分别介绍：
⏹排他性约束：
各个原因之间不能同时为真，但可以同时为假。
举个例子，小明同学不可能同时属于A班和B班，但可能既不是A班的，也不是B班的，而是C班的。
⏹包含性约束：
各个原因中总有一个为真。
即可以同时为真，但不可以同时为假。
举个例子，支付宝买家付款时，有个输入条件（既原因）是余额支付、网银支付，买家可以选择单独余额支付或者单独网银支付，也可以同时选择余额支付和网银支付2种方式。
但是不可以选择不支付。
⏹必要性约束：
当原因a为真时，原因b必须同时为真；但是原因b为真时，原因a既可以为真，也可以为假。
举数字证书的例子：
现有的业务规则下，如果申请了数字证书（原因a），那么该用户必然通过了支付宝认证（原因b）。
反之，如果用户通过了支付宝认证，那么不一定申请了数字证书（a）。
⏹唯一性约束：
有且只有原因a和原因b中的一个为真。
非此即彼，不存在第三种情况。
举例来说，人的性别不是男，就是女，不会存在既不是男也不是女的人。
⏹掩码标记（结果约束）：
如果结果b为真，那么结果a一定为假，如果结果b为假，则结果a的状态不定。
还拿支付宝来举例子，先给出两个结果：
安全控件运行正常（a），无法输入登陆密码（b）。
如果无法输入登陆密码，那么可以判断是安全控件没有正常运行，反过来，如果可以输入登陆密码，则不能确定安全控件一定工作正常，有可能是用了FireFox浏览器访问Alipay的。
2.3.使用因果图设计测试用例的步骤
上面我们解决了“Whatisit”的问题，下面让我们来讨论“Howtodo”的问题。
使用因果图设计测试用例一般包括下面几个步骤：
2.3.1.分析需求
阅读需求文档，如果UserCase很复杂，尽量将它分解成若干个简单的部分。
这样做的好处是，不必在一次处理过程中考虑所有的原因。
没有固定的流程说明究竟分解到何种程度才算简单，需要测试人员根据自己的经验和业务复杂度具体分析。
2.3.2.确定原因和结果
在每个已经分解好的块中，找出哪些是原因，哪些是结果。
并且把原因和结果分别画出来。
原因放在一列，结果放在一列。
如下图所示。
2.3.3.确定逻辑关系
继续分析需求文档，找出原因和结果之间的关系，用逻辑运算符标出。
2.3.4.确定约束关系
继续分析需求，找出原因和原因、结果与结果之间的约束限制，用上面说的约束关系标出。
2.3.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
图中淡黄色区域表示各种原因状态组合的个数，淡蓝色区域表示原因之间的状态组合。
嫩绿色区域则表示不同原因组合所对应的结果。
2.3.6.根据原因给出结果
上面的决策表中，不一定每个原因的状态组合都是有效的。
要根据因果图中的约束条件，去掉不可能出现的组合，从决策表中标记出来。
并给出每个可能的原因组合对应的结果。
2.3.7.设计测试用例
上一步完成之后，决策表的每一个有效列都对应一个测试用例。
2.4.举例说明
下面用几个例子来说明因果图的用法。
2.4.1.例子1
某软件需求说明书：
某段文本中，第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。
但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。
由于此需求已经非常清晰，所以标准步骤中的第一步省略，从第二步开始分析。
⏹确定原因和结果：
从大的方面看，第一列和第二列不同的字符会引起不同的结果，所以初步分析原因结果图如下。
原因
c1
第一列字符正确
c2
第二列字符是数字
结果
e1
修改文件
e2
给出信息L
e3
给出信息M
⏹确定因果逻辑关系：
如果第一列和第二列都正确，则修改文件；如果第一列不正确，给出信息L；如果第二列不正确，给出M。
可以得出下面的因果图。
而根据需求描述，原因c1还可以细分为2个原因：
第一列字符是A（c11），第一列字符是B（c12）。
因此原因c1其实也可以看作成结果。
把它用因果图表示出来如下：
根据上面的分析，其实总共有3个原因，3个结果。
⏹确定约束关系：
从需求描述中可知，原因c11和c12不可能同时为真，但可以同时为假，因此满足排他性约束。
这三个结果之间没有掩码标记的约束。
完整的因果图如下：
⏹根据因果图画决策表：
列出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
⏹根据原因分析结果：
分析每一种状态对应的结果，并根据约束关系，去掉不可能出现的状态。
本例的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
⏹设计测试用例：
根据决策表，列出有效的状态组合和结果，给出对应的测试用例，可以单独画一个表，也可以直接加到决策表中。
如下图：
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
到现在为止，使用因果图设计测试用例的一个简单的例子就完成了。
2.4.2.例子2
再以支付宝认证总流程为例，说明因果图的实际应用。
支付宝个人认证中，分为两部分：
个人身份认证和银行卡认证。
这两者都通过后，认为个人认证成功。
个人身份认证需要提交个人基本信息及身份证复印件。
银行卡认证分为两种：
提现认证和充值认证。
提现认证的流程是：
用户提交正确的银行帐号——>支付宝给用户的银行卡中随机打款——>用户确认金额，认证成功。
充值认证的流程是：
用户提交正确的银行帐号——>充值——>充值完成——>网银反馈，认证成功。
⏹从上面的描述中，我们可以总结出2大原因和一个结果。
原因一：
身份认证成功
身份认证成功也是一个中间结果，它也有2个原因，提交基本信息成功和提交身份证成功。
原因二：
银行卡认证成功，包含2个原因：
充值认证成功和提现认证成功。
这2种原因也可以看做是中间结果，产生结果的原因在需求中可以也能明显看出来，不再赘述。
一个结果：
个人认证成功。
注意：
为了简便起见，我们假设个人信息提交和身份证件提交成功后，身份认证则成功，忽略人工审核过程。
原因和结果表如下：
原因
c11
个人基本信息提交成功
c12
个人身份证件提交成功
原因
c221
充值认证的银行帐号提交成功
c222
充值成功
c223
网银反馈成功
原因
c211
提现认证的银行帐号提交成功
c212
支付宝打款成功
c213
用户确认成功
中间结果
c21
银行卡提现认证成功
c22
银行卡充值认证成功
中间结果
c1
身份认证成功
c2
银行卡认证成功
结果
e1
个人认证成功
⏹确定因果逻辑关系
对于因果关系较为的复杂的逻辑，通过结果向前推原因是一个不错的方法。
认证成功：
身份认证成功和银行卡认证同时为真，认证成功才为真。
身份认证成功：
基本信息和身份证件同时为真，身份认证成功才为真。
银行卡认证：
提现认证和充值认证有一个成功，银行卡认证则成功。
提现认证、充值认证都是所有的原因都为真时，自己才为真。
⏹确定约束关系
从业务流程可知：
提现认证和充值认证是二择一的，满足唯一性约束条件。
而充值认证的三个原因，有流程上的先后顺序，满足必要性约束条件。
同样，提现认证的三个原因也满足必要性约束条件。
根据约束关系，我们画出因果图如下：
⏹画决策表及设计测试用例的过程略。
3.使用因果图的好处
总上所述，我认为因果图最大的好处有2点：
⏹考虑了多个输入之间的相互组合、相互制约关系。
⏹帮助我们按一定步骤，高效率地选择测试用例。
升级会员 