《测试蓝本》读后感.docVIP

测试用例设计方法的介绍—因果图 前言 为什么需要测试用例 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 前言 为什么需要测试用例 测试的目的是在有限的资源下，尽可能多的找出系统的缺陷。这就要求在测试中，尽可能完全的走完系统的所有流程，保证所有的分支都经过测试。 而测试过程是由人来执行的，不可能避免的会遗漏一些应该测试内容，这样就很容易出现测试不全面的问题。再者，现有的软件开发大多都是迭代式进行的，需要对同一个功能反复测试多遍。很有可能第一轮测试得比较全面，当进行第二轮的时候，可能也会遗漏某些点。这种情况下，测试过程是由人控制的，具有盲目性，是不可控制的。 而测试用例就是把软件测试行为做一个科学化的组织和归纳，用来指导测试行为。 一般需求入基线后，测试人员开始介入项目，对需求进行分析，并根据自己对需求的理解设计出详细的测试用例。这样在测试执行时，按照设计好的过程去执行，避免由于人为的原因使测试不全面。 在设计测试用例的过程中，测试人员也可以根据自己的理解，对需求提出不同的看法，或者发现需求中某些功能描述得不够详细或者有歧义，提早发现问题，降低项目风险。 测试用例设计的方法分类 从测试方法上可以分为黑盒测试、白盒测试、灰盒测试。 黑盒测试 程序的内部逻辑实现对测试人员是透明的。测试人员只需要根据需求文档来决定程序应该做什么事情，会产生什么样的结果。测试人员对需求中的每个点进行覆盖测试。目前流行的黑盒测试设计方法有： 等价类划分 边界值分析 因果图法 场景法 白盒测试 属于代码级的测试。测试人员不仅要了解程序要做什么，还要了解程序是如何实现的，根据实现方法设计测试用例。测试人员需要对代码进行覆盖测试。由于现在的程序分支、循环都很多，所以完全覆盖代码是不可能的，现在比较常用的设计方法有： 语句覆盖 分支覆盖 条件覆盖 条件组合覆盖 基本路径覆盖 循环覆盖 灰盒测试 类和接口级的测试。介于黑盒测试和白盒测试之间，既关心程序输出的正确性，也关心程序的内部逻辑，但这个逻辑不是代码级的。举例来说，对类或者接口进行测试，不关心代码的实现，只关心每个方法和属性在执行过程中是否正确，这就属于灰盒测试。 因果图的具体介绍 为什么么需要因果图 在黑盒测试中，等价类划分或边界值分析法只考虑了不同的输入和不同的输出之间的关系。但是如果是各个输入条件之间有很复杂的组合，这二种设计方法都很难用一个系统的方法进行描述，设计测试用例只能依靠测试人员主观的猜测或者分析，具有很大的盲目性。 让我们先来看一个简单的例子。 假设某个软件需求文档中有这样的说明： 第一列字符必须是A或B，第二列字符必须是一个数字，在此情况下进行文件的修改。但如果第一列字符不正确，则给出信息L；如果第二列字符不是数字，则给出信息M。 先用等价类来分析，第一列会有三个输入：A、B、非(A B)的字符。第二列字符有二个输入：数字、非数字（为了简便起见，有关数字再细化的问题不做讨论）。这是一个根据理论进行分析的过程。但是做完了这一步，并不能得出输出。也就是说如何分析第一列和第二列的关系，没有明确的理论指导。实际操作过程中，各个测试人员可能会设计出不同的测试用例。 这个例子还仅仅是一个2个输入条件之间有关系，如果到更复杂的应用中，可能会更多。如果没有一种方法指导我们的思想，测试用例就会很不全面。 而因果图正好弥补了上述缺点。我们先来看一下什么叫因果图。因果图是一种形式化的语言（以图的形式表现），它不仅描述了原因和结果之间的关系，也描述了各个原因之间、各个结果之间复杂关系的组合。在这里，因就是程序的输入条件，而果则是程序的输出。正确的使用因果图可以对很复杂的功能逻辑进行分析，设计出高效而简洁的测试用例。 因果图概念介绍 学习因果图需要的基本知识是： 布尔逻辑运算符 三种常用的运算符是NOT、AND、OR。还有两种比较少用的是NAND、NOR。再加上恒等，这六种符号是描述原因和结果之间的逻辑关系的。 下面以图的形式详细说明6种因果逻辑。c表示原因，e表示结果。 恒等：如果原因为真，那么结