第2 章软件测试的心理学和经济学
2.4 小结
在阅读本书接下来的内容时，请牢记以下三个重要的测试原则：
• 软件测试是为发现错误而执行程序的过程。
• 一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。
• 一个成功的测试用例能够发现某个尚未发现的错误。
第3 章 代码检查、走查与评审
一些测试人员在使
用了人工方法之后发现，对于某些特定类型的错误，人工方法比基于计算机的方法
更有效，而对于其他错误类型，基于计算机的方法更有效。这就意味着，代码检查
/走查与基于计算机的测试是互补的。缺少其中任何一种，错误检查的效率都会降低。
3.3 用于代码检查的错误列表
3.7 小结
本章讨论了软件开发人员通常不会考虑到的一种测试形式——人工测试。大多
数人都以为，因为程序是为了供机器执行而编写的，那么也该由机器来对程序进行
测试。这种想法是有问题的。人工测试方法在暴露错误方面是很有成效的。实际上，
大多数的软件项目都应使用到以下的人工测试方法：
• 利用错误列表进行代码检查。
• 小组代码走查。
• 桌面检查。
• 同行评审。
第4 章测试用例的设计
一般而言，在所有的方法中效率最低的是随机输入测试。
本书第2 章已经证明穷举的黑盒和白盒测试通常都是不可能的，但同时也建议：
将这两种测试的要素组合起来得到一种合理的测试策略。
本章将要讨论的测试方法如下：
黑盒测试 白盒测试
等价类划分 语句覆盖
边界值分析 判定覆盖
因果图分析 条件覆盖
错误测试 判定/条件覆盖
多重条件覆盖
我们推荐的步骤是先使用黑盒测试方法来设计测试用例，然后视情况需要使用
白盒测试方法来设计补充的测试用例。下面首先讨论较为有名的白盒测试方法。
4.1 白盒测试(White-Box Testing)
4.1.1 逻辑覆盖测试(Logic-Coverage Testing)
判定覆盖或分支覆盖是较强一些的逻辑覆盖准则
比判定覆盖更强一些的准则是条件覆盖
总的来说，对于包含每个判断只存在一种条件的程序，最简单的测试准则就是
设计出足够数量的测试用例，实现：（1）将每个判断的所有结果都至少执行一次；
（2）将所有的程序入口（例如入口点或ON 单元）都至少调用一次，以确保全部的
语句都至少执行一次
4.1.2 等价划分(Equivalence Partitioning)
确定这个子集的一种方法，就是要意识到一个精心挑选的测试用例还应具备另
外两个特性：
1. 严格控制测试用例的增加，减少为达到“合理测试”的某些既定日标而必
须设计的其他测试用例的数量。
2. 它覆盖了大部分其他可能的测试用例。也就是说，它会告诉我们，使用或
不使用这个特定的输入集合，哪些错误会被发现，哪些会被遗漏掉。
使用等价划分方法设计测试用例主要有两个步骤：（1）确定等价类；（2）生成
测试用例。
4.1.4 边界值分析(Boundary-Value Analysis)
经验证明，考虑了边界条件的测试用例与其他没有考虑边界条件的测试用例相
比，具有更高的测试回报率。所谓边界条件，是指输入和输出等价类中那些恰好处
于边界、或超过边界、或在边界以下的状态。
因此，边界值分析方法和等价划分之间的重要区别是，边界值分析考察正处于等价
划分边界或在边界附近的状态。
即42 个测试用例的大部分代表了在开发
该程序的过程中可能会犯的共性错误，但如果我们采用的是随机生成或特殊的测试
用例设计方法，这些错误中的大多数都不会被检查出来。如果使用得正确，边界值
分析是最为有效的测试用例设计方法之一
4.1.5 因果图(Cause-Effect Graphing)
边界值分析和等价划分的一个弱点是未对输入条件的组合进行分析。
因果图有助于用一个系统的方法选择出高效的测试用例集。它还有一个额外的
好处，就是可以指出规格说明的不完整性和不明确之处。
4 .2 错误猜测(Error Guessing)
由于错误猜测主要是一项依赖于直觉的非正规的过程，因此很难描述出这种方
法的规程。其基本思想是列举出可能犯的错误或错误易发情况的清单，然后依据清
单来编写测试用例
4.3 测试策略
本章讨论的测试用例设计方法可以组合为一个整体的策略。之所以组合，原因
现在已经很清楚了，每一种方法都可以提供一组具体的有用的测试用例，但是都
不能单独提供一个完整的测试用例集。一组合理的策略如下：
1. 如果规格说明中包含输入条件组合的情况，应首先使用因果图分析方法。
2. 在任何情况下都应使用边界值分析方法。应记住，这是对输入和输出边界
进行的分析。边界值分析可以产生一系列补充的测试条件，但是，也正如
“因果图分析”一节所述，多数甚至全部条件都可以被整合到因果图分析中。
3. 应为输入和输出确定有效和无效等价类，在必要情况下对上面确认的测试
用例进行补充。
4. 使用错误猜测技术增加更多的测试用例。
5. 针对上述测试用例集检查程序的逻辑结构。应使用判定覆盖、条件覆盖、
判定/条件覆盖或多重条件覆盖准则（最后的一个最为完整）。如果覆盖准
则未能被前四个步骤中确定的测试用例所满足，并且满足准则也并非不可
能（由于程序的性质限制，某些条件的组合也许是不可能实现的），那么增
加足够数量的测试用例，以使覆盖准则得到满足。
第5 章模块（单元）测试
5.1 测试用例设计
模块测试总体上是面向白盒测试的
上述规格说明并不适合于因果图分析方法（没有一组应检查其组合情况的能力
分辨出来的输入条件），因此采用边界值分析方法。
5.2 增量测试
在执行模块测试过程中,我们主要有两点考虑：第一，如何设计一个有效的测试
用例集，这在上一节已经讨论过。第二，将模块组装成工作程序的方式。