因果图设计测试用例(共14页).doc

《因果图设计测试用例(共14页).doc》由会员分享，可在线阅读，更多相关《因果图设计测试用例(共14页).doc（14页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选优质文档-倾情为你奉上测试用例设计方法的介绍因果图前言 为什么需要测试用例测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测试。而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容，这样就很容易出现测试不全面的问题。再者，现有的软件开发大多都是迭代式进行的，需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全面，当进行第二轮的时候，可能也会遗漏某些点。这种情况下，测试过程是由人控制的，具有盲目性，是不可控制的。而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。一般需求入基线后，测试

2、人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。1. 测试用例设计的方法分类从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。1.1. 黑盒测试程序的内部逻辑实现对测试人员是透明的。测试人员只需要根据需求文档来决定程序应该做什么事情，会产生什么样的结果。测试人员对需求中的每个点进行覆盖测试。目前流行的黑盒测试设计方法有： 等价类划分 边界值分

3、析 因果图法 场景法1.2. 白盒测试属于代码级的测试。测试人员不仅要了解程序要做什么，还要了解程序是如何实现的，根据实现方法设计测试用例。测试人员需要对代码进行覆盖测试。由于现在的程序分支、循环都很多，所以完全覆盖代码是不可能的，现在比较常用的设计方法有： 语句覆盖 分支覆盖 条件覆盖 条件组合覆盖 基本路径覆盖 循环覆盖1.3. 灰盒测试类和接口级的测试。介于黑盒测试和白盒测试之间，既关心程序输出的正确性，也关心程序的内部逻辑，但这个逻辑不是代码级的。举例来说，对类或者接口进行测试，不关心代码的实现，只关心每个方法和属性在执行过程中是否正确，这就属于灰盒测试。2. 因果图的具体介绍2.1.

4、 为什么么需要因果图在黑盒测试中，等价类划分或边界值分析法只考虑了不同的输入和不同的输出之间的关系。但是如果是各个输入条件之间有很复杂的组合，这二种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测试人员主观的猜测或者分析，具有很大的盲目性。让我们先来看一个简单的例子。假设某个软件需求文档中有这样的说明：第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。先用等价类来分析，第一列会有三个输入：A、B、非(A B)的字符。第二列字符有二个输入：数字、非数字（为了简便起见，有关数字再细化

5、的问题不做讨论）。这是一个根据理论进行分析的过程。但是做完了这一步，并不能得出输出。也就是说如何分析第一列和第二列的关系，没有明确的理论指导。实际操作过程中，各个测试人员可能会设计出不同的测试用例。这个例子还仅仅是一个2个输入条件之间有关系，如果到更复杂的应用中，可能会更多。如果没有一种方法指导我们的思想，测试用例就会很不全面。而因果图正好弥补了上述缺点。我们先来看一下什么叫因果图。因果图是一种形式化的语言（以图的形式表现），它不仅描述了原因和结果之间的关系，也描述了各个原因之间、各个结果之间复杂关系的组合。在这里，因就是程序的输入条件，而果则是程序的输出。正确的使用因果图可以对很复杂的功能逻

6、辑进行分析，设计出高效而简洁的测试用例。2.2. 因果图概念介绍学习因果图需要的基本知识是：2.2.1. 布尔逻辑运算符三种常用的运算符是NOT、AND、OR。还有两种比较少用的是NAND、NOR。再加上恒等，这六种符号是描述原因和结果之间的逻辑关系的。下面以图的形式详细说明6种因果逻辑。c表示原因，e表示结果。n 恒等：如果原因为真，那么结果必定为真。n 与：只有2个原因都为真，那么结果为真。n 或：2个原因中有一个为真时，结果就为真。n 非：只有原因为假，结果才为真。n 与非：先与后非。n 或非：先或后非。2.2.2. 因果图的约束关系表示法因果图中有4种符号描述原因之间的约束关系，1种符

7、号描述结果之间的约束关系。下面分别介绍：n 排他性约束：各个原因之间不能同时为真，但可以同时为假。举个例子，小明同学不可能同时属于A班和B班，但可能既不是A班的，也不是B班的，而是C班的。n 包含性约束：各个原因中总有一个为真。即可以同时为真，但不可以同时为假。举个例子，支付宝买家付款时，有个输入条件（既原因）是余额支付、网银支付，买家可以选择单独余额支付或者单独网银支付，也可以同时选择余额支付和网银支付2种方式。但是不可以选择不支付。n 必要性约束：当原因a为真时，原因b必须同时为真；但是原因b为真时，原因a既可以为真，也可以为假。举数字证书的例子：现有的业务规则下，如果申请了数字证书（原因

8、a），那么该用户必然通过了支付宝认证（原因b）。反之，如果用户通过了支付宝认证，那么不一定申请了数字证书（a）。n 唯一性约束：有且只有原因a和原因b中的一个为真。非此即彼，不存在第三种情况。举例来说，人的性别不是男，就是女，不会存在既不是男也不是女的人。n 掩码标记（结果约束）：如果结果b为真，那么结果a一定为假，如果结果b为假，则结果a的状态不定。还拿支付宝来举例子，先给出两个结果：安全控件运行正常（a），无法输入登陆密码（b）。如果无法输入登陆密码，那么可以判断是安全控件没有正常运行，反过来，如果可以输入登陆密码，则不能确定安全控件一定工作正常，有可能是用了FireFox浏览器访问Ali

9、pay的。2.3. 使用因果图设计测试用例的步骤上面我们解决了“What is it”的问题，下面让我们来讨论“How to do”的问题。使用因果图设计测试用例一般包括下面几个步骤：2.3.1. 分析需求阅读需求文档，如果User Case很复杂，尽量将它分解成若干个简单的部分。这样做的好处是，不必在一次处理过程中考虑所有的原因。没有固定的流程说明究竟分解到何种程度才算简单，需要测试人员根据自己的经验和业务复杂度具体分析。2.3.2. 确定原因和结果在每个已经分解好的块中，找出哪些是原因，哪些是结果。并且把原因和结果分别画出来。原因放在一列，结果放在一列 。如下图所示。2.3.3. 确定逻辑

10、关系继续分析需求文档，找出原因和结果之间的关系，用逻辑运算符标出。2.3.4. 确定约束关系继续分析需求，找出原因和原因、结果与结果之间的约束限制，用上面说的约束关系标出。2.3.5. 把因果图转换为决策表给每个原因分别取真和假二种状态，用0和1表示。画一个有限项决策表，列出所有状态的状态组合。包含3个原因、2个结果的有限项决策表如下。12345678原因100001111200110011301010101结果12图中淡黄色区域表示各种原因状态组合的个数，淡蓝色区域表示原因之间的状态组合。嫩绿色区域则表示不同原因组合所对应的结果。2.3.6. 根据原因给出结果上面的决策表中，不一定每个原因的

11、状态组合都是有效的。要根据因果图中的约束条件，去掉不可能出现的组合，从决策表中标记出来。并给出每个可能的原因组合对应的结果。2.3.7. 设计测试用例上一步完成之后，决策表的每一个有效列都对应一个测试用例。2.4. 举例说明下面用几个例子来说明因果图的用法。2.4.1. 例子1某软件需求说明书：某段文本中，第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。由于此需求已经非常清晰，所以标准步骤中的第一步省略，从第二步开始分析。n 确定原因和结果：从大的方面看，第一列和第二列不同的字符会引起不同的

12、结果，所以初步分析原因结果图如下。原因c1第一列字符正确c2第二列字符是数字结果e1修改文件e2给出信息Le3给出信息Mn 确定因果逻辑关系：如果第一列和第二列都正确，则修改文件；如果第一列不正确，给出信息L；如果第二列不正确，给出M。可以得出下面的因果图。而根据需求描述，原因c1还可以细分为2个原因：第一列字符是A（c11），第一列字符是B（c12）。因此原因c1其实也可以看作成结果。把它用因果图表示出来如下：根据上面的分析，其实总共有3个原因，3个结果。n 确定约束关系：从需求描述中可知，原因c11和c12不可能同时为真，但可以同时为假，因此满足排他性约束。这三个结果之间没有掩码标记的约束

13、。完整的因果图如下：n 根据因果图画决策表：列出3个原因所有的状态组合。12345678原因c1100001111c1200110011c201010101结果e1e2e3n 根据原因分析结果：分析每一种状态对应的结果，并根据约束关系，去掉不可能出现的状态。本例的c11和c12满足排他性约束，所以同时都为1的状态不会出现。12345678原因c1100001111c1200110011c201010101结果e1000101无此可能无此可能e2110000e3001010n 设计测试用例：根据决策表，列出有效的状态组合和结果，给出对应的测试用例，可以单独画一个表，也可以直接加到决策表中。如下图

14、：12345678原因c1100001111c1200110011c201010101结果e1000101无此可能无此可能e2110000e3001010测试用例(字符串)aacca3c3BeB3AqA4到现在为止，使用因果图设计测试用例的一个简单的例子就完成了。2.4.2. 例子2再以支付宝认证总流程为例，说明因果图的实际应用。支付宝个人认证中，分为两部分：个人身份认证和银行卡认证。这两者都通过后，认为个人认证成功。个人身份认证需要提交个人基本信息及身份证复印件。银行卡认证分为两种：提现认证和充值认证。提现认证的流程是：用户提交正确的银行帐号支付宝给用户的银行卡中随机打款用户确认金额，认证成

15、功。充值认证的流程是：用户提交正确的银行帐号充值充值完成网银反馈，认证成功。n 从上面的描述中，我们可以总结出2大原因和一个结果。原因一：身份认证成功身份认证成功也是一个中间结果，它也有2个原因，提交基本信息成功和提交身份证成功。原因二：银行卡认证成功，包含2个原因：充值认证成功和提现认证成功。这2种原因也可以看做是中间结果，产生结果的原因在需求中可以也能明显看出来，不再赘述。一个结果：个人认证成功。注意：为了简便起见，我们假设个人信息提交和身份证件提交成功后，身份认证则成功，忽略人工审核过程。原因和结果表如下：原因c11个人基本信息提交成功c12个人身份证件提交成功原因c221充值认证的银行

16、帐号提交成功c222充值成功c223网银反馈成功原因c211提现认证的银行帐号提交成功c212支付宝打款成功c213用户确认成功中间结果c21银行卡提现认证成功c22银行卡充值认证成功中间结果c1身份认证成功c2银行卡认证成功结果e1个人认证成功n 确定因果逻辑关系对于因果关系较为的复杂的逻辑，通过结果向前推原因是一个不错的方法。认证成功：身份认证成功和银行卡认证同时为真，认证成功才为真。 身份认证成功：基本信息和身份证件同时为真，身份认证成功才为真。银行卡认证：提现认证和充值认证有一个成功，银行卡认证则成功。提现认证、充值认证都是所有的原因都为真时，自己才为真。n 确定约束关系从业务流程可知：提现认证和充值认证是二择一的，满足唯一性约束条件。而充值认证的三个原因，有流程上的先后顺序，满足必要性约束条件。同样，提现认证的三个原因也满足必要性约束条件。根据约束关系，我们画出因果图如下：n 画决策表及设计测试用例的过程略。3. 使用因果图的好处总上所述，我认为因果图最大的好处有2点：n 考虑了多个输入之间的相互组合、相互制约关系。n 帮助我们按一定步骤，高效率地选择测试用例。专心-专注-专业