【书山有路】软件测试的艺术第4章

本章的主题是测试用例的设计，是非常重要的一章，也是这本书的核心内容。不出意外的话后面的章节这次就看不了了。应该是最后一章读书笔记了。

观点

• 软件测试中最重要的因素是设计和生成有效的测试用例。在所有可能的测试用例中，哪个子集最有可能发现最多的错误？
• 随机输入测试是效率最低的方法
• 可以通过使用特定的面向黑盒测试的测试用例设计方法而后使用百合测试方法对程序的逻辑结构进行检查来补充这些测试用例。
• 建议综合最多的测试方法来设计严格的程序测试，每一种方法都有独特的优势和软点。
• 严格控制测试用例的增加，减少到为达到“合理测试”的某县既定目标而必须设计的其他测试用例的数量。–每个测试用例必须体现尽可能多的不同的输入情况。
• 测试用例应覆盖大部分其他可能的测试用例。–尽量将程序输入范围进行划分，将它划分为有限数量的等价类。
• 可以假设测试每个等价类的代表性数据等同于测试该类的其他任何数据。

主要的测试方法列表

黑盒测试

等价类划分、边界值分析、因果图分析、错误猜测

等价类划分

两个步骤：1.确定等价类 2.生成测试用例

等价类划分的不足：它可能忽略掉某些特定类型的高效测试用例，边界值分析和因果图可以弥补其中很多不足。

确定等价类

选取每一个输入条件（通常是规格说明中的一个句子或短语）并将其划分成两个或更多的组。可以用下图的表格进行划分。

给出了输入或外部条件后，确定等价类大体上是一个启发式的过程。下面给出一些指导原则：

• 如果输入条件规定了一个取值范围（例如数量可以是从1到999），那么就应该确定出一个有效等价类（1<数量<999),以及两个无效等价类（数量<1,数量>999)
• 如果输入条件规定了取值的个数（例如“汽车可以等级一至六名车主”），那么就应该确定出一个有效等价类和两个无效等价类（没有车主或车主多余六个）
• 如果输入条件规定了一个输入值的集合，而且有理由认为程序会对每个值进行不同的处理，那么确定每个输入值为一个有效等价类，可确定一个无效等价类。

如果有任何理由可以认为程序并未等同的处理等价类中的元素，那么应该将这个等价类再划分成小一些的等价类。

生成测试用例

步骤如下：
1. 为每个等价类设置一个不同的编号
2. 编写新的测试用例，尽可能多的覆盖那些尚未被覆盖的有效等价类，直到所有的有效等价类都被测试用例所覆盖
3. 编写新的用例，覆盖一个且仅一个尚未被覆盖的无效等价类，直到所有的无效等价类都被测试用例所覆盖

边界值分析

边界条件是指输入和输出等价类中那些恰好处于边界、或超过边界、或在边界以下的状态。

边界值分析需要选择一个或多个元素，以便等价类的每个边界都经过一次测试。

还需要考虑从输出等价类中设计测试用例。边界值分析考察正处于等价划分边界或在边界附近的状态。

白盒测试

判定覆盖、条件覆盖、判定/条件覆盖、多重条件覆盖

白盒测试关注的是测试用例执行的程度或覆盖程序逻辑结构（源代码）的程度。

判定覆盖或分支覆盖

判定覆盖要求必须编写足够的测试用例，使得每一个判断的每个可能结果都至少执行一次。

条件覆盖要求必须编写足够的测试用例，使得每一个判断的每个条件的所有结果都至少执行一次。

不能语句覆盖的三种例外：
* 程序中不存在判断
* 程序有多重入口点，从特定的入口点进入时某条语句才能执行。
* ON-unit

解决办法（判定/条件覆盖准则）：将一个判断中的每个条件的所有可能的结果至少执行一次，将每个判断的所有可能的结果至少执行一次，将每个入口点都至少调用一次。

判定/条件覆盖准则不一定会发现逻辑表达式中的错误。

总结
对于包含每个判断只存在一种条件的程序，最简单的测试准则就是设计出足够数量的测试用例，实现：(1)将每个判断的所有结果的都至少执行一次。(2)将所有的程序入口（入口点和ON-unit）都至少调用一次。

对于包含多重条件判断的程序，最简单的测试准则是设计出足够数量的测试用例，将每个判断的所有可能的条件结果的组合，以及所有的入口点都至少执行一次

错误猜测

错误猜测主要是一项依赖于只觉得的非正规的过程，因此很难表述出这种方法的规程。其基本思想是列举出可能犯的错误或错误易发情况的清单，然后根据清单来编写测试用例。

因果图

太复杂了，没看懂，先略过了。

测试策略

1. 如果规格说明中包含输入条件组合的情况，首先使用因果图分析方法
2. 在任何情况下应使用边界值分析方法
3. 应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试用例进行补充。
4. 使用错误猜测技术增加更多的测试用例
5. 针对上述测试用例集检查程序的逻辑结构。必要时增加测试用例