测试用例设计方法的介绍因果图.doc

测试用例设计方法的介绍因果图 前言前言 为什么需要测试用例为什么需要测试用例.1 1.测试用例设计的方法分类测试用例设计的方法分类.2 1.1.黑盒测试黑盒测试.2 1.2.白盒测试白盒测试.2 1.3.灰盒测试灰盒测试.3 2.因果图的具体介绍因果图的具体介绍.3 2.1.为什么么需要因果图为什么么需要因果图.3 2.2.因果图概念介绍因果图概念介绍.4 2.2.1.布尔逻辑运算符布尔逻辑运算符.4 2.2.2.因果图的约束关系表示法因果图的约束关系表示法.5 2.3.使用因果图设计测试用例的步骤使用因果图设计测试用例的步骤.7 2.3.1.分析需求分析需求.7 2.3.2.确定原因和结果确定原因和结果.7 2.3.3.确定逻辑关系确定逻辑关系.8 2.3.4.确定约束关系确定约束关系.8 2.3.5.把因果图转换为决策表把因果图转换为决策表.8 2.3.6.根据原因给出结果根据原因给出结果.8 2.3.7.设计测试用例设计测试用例.8 2.4.举例说明举例说明.9 2.4.1.例子例子1.9 2.4.2.例子例子2.12 3.使用因果图的好处使用因果图的好处.12 4.12 前言前言 为什么需要测试用例为什么需要测试用例 测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。这就要 求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测 试。 而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容， 这样就很容易出现测试不全面的问题。再者，现有的软件开发大多都是迭代 式进行的，需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全 面，当进行第二轮的时候，可能也会遗漏某些点。这种情况下，测试过程是 由人控制的，具有盲目性，是不可控制的。 而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指 导测试行为。 一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根 据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计 好的过程去执行，避免由于人为的原因使测试不全面。 在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求 提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提 早发现问题，降低项目风险。 1. 测试用例设计的方法分类测试用例设计的方法分类 从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。 1.1. 黑盒测试黑盒测试 程序的内部逻辑实现对测试人员是透明的。测试人员只需要根据需求文 档来决定程序应该做什么事情，会产生什么样的结果。测试人员对需求中 的每个点进行覆盖测试。目前流行的黑盒测试设计方法有： 等价类划分 边界值分析 因果图法 场景法 1.2. 白盒测试白盒测试 属于代码级的测试。测试人员不仅要了解程序要做什么，还要了解程序 是如何实现的，根据实现方法设计测试用例。测试人员需要对代码进行覆 盖测试。由于现在的程序分支、循环都很多，所以完全覆盖代码是不可能 的，现在比较常用的设计方法有： 语句覆盖 分支覆盖 条件覆盖 条件组合覆盖 基本路径覆盖 循环覆盖 1.3. 灰盒测试灰盒测试 类和接口级的测试。介于黑盒测试和白盒测试之间，既关心程序输出的 正确性，也关心程序的内部逻辑，但这个逻辑不是代码级的。举例来说， 对类或者接口进行测试，不关心代码的实现，只关心每个方法和属性在执 行过程中是否正确，这就属于灰盒测试。 2. 因果图的具体介绍因果图的具体介绍 2.1. 为什么么需要因果图为什么么需要因果图 在黑盒测试中，等价类划分或边界值分析法只考虑了不同的输入和不同 的输出之间的关系。但是如果是各个输入条件之间有很复杂的组合，这二 种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测 试人员主观的猜测或者分析，具有很大的盲目性。 让我们先来看一个简单的例子。 假设某个软件需求文档中有这样的说明： 第一列字符必须是 A 或 B，第二列字符必须是一个数字，在此情况下 进行文件的修改。但如果第一列字符不正确，则给出信息 L；如果第二列 字符不是数字，则给出信息 M。 先用等价类来分析，第一列会有三个输入：A、B、非(A B)的字符。第 二列字符有二个输入：数字、非数字（为了简便起见，有关数字再细化的 问题不做讨论） 。这是一个根据理论进行分析的过程。但是做完了这一步， 并不能得出输出。也就是说如何分析第一列和第二列的关系，没有明确的 理论指导。实际操作过程中，各个测试人员可能会设计出不同的测试用例。 这个例子还仅仅是一个 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. 使用因果图设计测试用例的步骤使用因果图设计测试用例的步骤 上面我们解决了“What is it”的问题，下面让我们来讨论“How to do”的 问题。使用因果图设计测试用例一般包括下面几个步骤： 2.3.1. 分析需求分析需求 阅读需求文档，如果 User Case 很复杂，尽量将它分解成若干个简单的部 分。这样做的好处是，不必在一次处理过程中考虑所有的原因。没有固定的 流程说明究竟分解到何种程度才算简单，需要测试人员根据自己的经验和业 务复杂度具体分析。 2.3.2. 确定原因和结果确定原因和结果 在每个已经分解好的块中，找出哪些是原因，哪些是结果。并且把原因和 结果分别画出来。原因放在一列，结果放在一列 。如下图所示。 2.3.3. 确定逻辑关系确定逻辑关系 继续分析需求文档，找出原因和结果之间的关系，用逻辑运算符标出。 2.3.4. 确定约束关系确定约束关系 继续分析需求，找出原因和原因、结果与结果之间的约束限制，用上面说 的约束关系标出。 2.3.5. 把因果图转换为决策表把因果图转换为决策表 给每个原因分别取真和假二种状态，用 0 和 1 表示。画一个有限项决策表， 列出所有状态的状态组合。包含 3 个原因、2 个结果的有限项决策表如下。 12345678 100001111原 因200110011 301010101 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 个原因所有的状态组合。 12345678 c1100001111 c1200110011 原 因 c201010101 e1 e2 结 果 e3 根据原因分析结果：分析每一种状态对应的结果，并根据约束关 系，去掉不可能出现的状态。本例的 c11 和 c12 满足排他性约束， 所以同时都为 1 的状态不会出现。 12345678 c1100001111 c1200110011 原 因 c201010101 e1000101 e2110000 结 果 e3001010 无 此 可 能 无 此 可 能 设计测试用例：根据决策表，列出有效的状态组合和结果，给出 对应的测试用例，可以单独画一个表，也可以直接加到决策表中。 如下图： 12345678 c1100001111 c1200110011 原 因 c201010101 e1000101 e2110000 结 果 e3001010 无 此 可 能 无 此 可 能 测试用例 (字符串) aa cc a3 c3 BeB3AqA4 到现在为止，使用因果图设计测试用例的一个简单的例子就完成了。 2.4.2. 例子例子 2 再以支付宝认证总流程为例，说明因果图的实际应用。 支付宝个人认证中，分为两部分：个人身份认证和银行卡认证。这两者都 通过后，认为个人认证成功。 个人身份认证需要提交个人基本信息及身份证复印件。 银行卡认证分为两种：提现认证和充值认证。 提现认证的流程是：用户提交正确的银行帐号支付宝给用户的银行 卡中随机打款用户确认金额，认证成功。 充值认证的流程是：用户提交正确的银行帐号充值充值完成 网银反馈，认证成功。 从上面的描述中，我们可以总结出 2 大原因和一个结果。 原因一：身份认证成功 身份认证成功也是一个中间结果，它也有 2 个原因，提交基本信息 成功和提交身份证成功。 原因二：银行卡认证成功，包含 2 个原因：充值认证成功和提现认 证成功。这 2 种原因也可以看做是中间结果，产生结果的原因在需求中 可以也能明显看出来，不再赘述。 一个结果：个人认证成功。 注意：为了简便起见，我们假设个人信息提交和身份证件提交成功 后，身份认证则成功，忽略人工审核过程。 原因和结果表如下： c11个人基本信息提交成功原因 c12个人身份证件提交成功 c221充值认证的银行帐号提交成功 c222充值成功 原因 c223网银反馈成功 c211提现认证的银行帐号提交成功 c212支付宝打款成功 原因 c213用户确认成功 c21银行卡提现认证成功中间结果 c22银行卡充值认证成功 c1身份认证成功中间结果 c2银行卡认证成功 结果e1个人认证成功 确定因果逻辑关系 对于因果关系较为的复杂的逻辑，通过结果向前推原因是一个不错 的方法。 认证成功：身份认证成功和银行卡认证同时为真，认证成功才为真。 身份认证成功