因果图测试用例设计方法介绍（超全的总结笔记错过就没有了）
前言 为什么需要测试用例
测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测试。
而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容，这样就很容易出现测试不全面的问题。再者，现有的软件开发大多都是迭代式进行的，需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全面，当进行第二轮的时候，可能也会遗漏某些点。这种情况下，测试过程是由人控制的，具有盲目性，是不可控制的。
而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。
一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。
在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。
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表示结果。
n 恒等：如果原因为真，那么结果必定为真。
n 与：只有2个原因都为真，那么结果为真。
n 或：2个原因中有一个为真时，结果就为真。
n 非：只有原因为假，结果才为真。
n 与非：先与后非。
n 或非：先或后非。
2.2.2. 因果图的约束关系表示法
因果图中有4种符号描述原因之间的约束关系，1种符号描述结果之间的约束关系。下面分别介绍：
n 排他性约束：各个原因之间不能同时为真，但可以同时为假。举个例子，小明同学不可能同时属于A班和B班，但可能既不是A班的，也不是B班的，而是C班的。
n 包含性约束：各个原因中总有一个为真。即可以同时为真，但不可以同时为假。举个例子，支付宝买家付款时，有个输入条件（既原因）是余额支付、网银支付，买家可以选择单独余额支付或者单独网银支付，也可以同时选择余额支付和网银支付2种方式。但是不可以选择不支付。
n 必要性约束：当原因a为真时，原因b必须同时为真；但是原因b为真时，原因a既可以为真，也可以为假。举数字证书的例子：现有的业务规则下，如果申请了数字证书（原因a），那么该用户必然通过了支付宝认证（原因b）。反之，如果用户通过了支付宝认证，那么不一定申请了数字证书（a）。
n 唯一性约束：有且只有原因a和原因b中的一个为真。非此即彼，不存在第三种情况。举例来说，人的性别不是男，就是女，不会存在既不是男也不是女的人。
n 掩码标记（结果约束）：如果结果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. 确定约束关系
继续分析需求，找出原因和原因、结果与结果之间的约束限制，用上面说的约束关系标出。
总结：
因篇幅限制、我把软件测试用例设计方法汇总成了文档，包括
等价类划分法：将输入数据划分为等效类，从每个等效类中选择代表性的测试数据进行测试。
边界值分析法：测试输入数据的边界和邻近值，以检测在输入值边界处是否存在错误。
决策表测试法：针对系统不同的决策情况，设计出相应的测试用例。
状态转换测试法：针对系统状态的变化，设计出相应的测试用例。
异常处理测试法：测试程序对异常情况的处理能力，如输入非法字符、超时等。
回归测试法：在修改或添加新功能后，重新运行之前的测试用例，以检查是否引入了新的问题。
随机测试法：随机生成测试数据进行测试，发现潜在问题。
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
