第1章 一次自评价测试
所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码全成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外惊奇。
我们要求设计一组测试用例（特定的数据集合），适当地测试一个相当简单的程序。为此要为该程序建立一组测试数据，程序须对数据进行正确处理以证明自身的成功。下面是对程序的描述：
这个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。
1.是否有这样的测试用例，代表了一个有效地不规则三角形？（注意，如1，2，3和2，5，10这样的测试用例并不能确保“是”的答案，因为具备这样边长的三角形不存在。）
2.是否有这样的测试用例，代表一个有效地等边三角形？
3.是否有这样的测试用例，代表一个有效地等腰三角形？（注意如2，2，4的测试用例无效，因为这不是一个有效地三角形。）
4.是否至少有三个这样的测试用例，代表有效地等腰三角形，从而可以测试到两等边的所有三种可能情况（如3，3，4；3，4，3；4，3，3）？
5.是否有这样的测试用例，某边的长度等于0？
6.是否有这样的测试用例，某边的长度为负数？
7.是否有这样的测试用例，三个整数皆大于0，其中两个整数之和等于第三个？（也就是说，如果程序判断1，2，3表示一个不规则三角形，它可能就包含一个缺陷。）
8.是否至少有三个第7类的测试用例，例举了一边等于另外两边之和的全部可能情况（如1，2，3；1，3，2；3，1，2）？
9.是否有这样的测试用例，三个整数皆大于0，其中两个整数之和小于第三个整数（如1，2，4；12，15，30）？
10.是否至少有三个第9类的测试用例，例举了一边大于另外两边之和的全部可能情况（如1，2，4；1，4，2；4，1，2）？
11.是否有这样的测试用例，三边长度皆为0？
12.是否至少有一个这样的测试用例，输入的边长为非整数值（如2.5，3.5，5.5）？
13.是否至少有一个这样的测试用例，输入的边长个数不对（如仅输入了两个而不是三个整数）？
14.对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值的预期输出值？
第2章软件测试的心理学和经济学
测试是为发现错误而执行程度的过程。
所谓“不成功的”测试，仅指未能适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”，这是因为认为软件中不包含错误的观点基本上是不切实际的。
黑盒测试又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。在这种方法中，测试数据完全来源于软件规范（换句话说，不需要去了解程序的内部结构）。如果想用这种方法来发现程序的所有错误，判定的标准就是“穷举输入测试”，将所有可能的输入条件都作为测试用例。
穷举输入测试是无法实现的。这有两方面的含义，一是我们无法测试一个程序以确保它是无错的，二是软件测试中需要考虑的一个基本问题是软件测试的经济学。也就是说，由于穷举测试是不可能的，测试投入的目标在于通过有限的测试用例，最大限度地提高发现的问题的数量，以取得最好的测试效果。
白盒测试或称逻辑驱动的测试，允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构进行检查，从中获取测试数据（遗憾的是，常常忽略了程序的规范）。
所谓穷举路径测试，即如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全测试。然而，这个论断存在两个问题。首先，程序中不同逻辑路径的数量可能达到天文数字。其次，虽然我们可以测试到程序中的所有路径，但是程序可能仍然存在着错误。这有三个原因：第一，即使是穷举路径测试也决不能保证程序符合其设计规范。第二，程序可能会因为缺少某些路径而存在问题。第三，穷举路径测试可能不会暴露数据敏感错误。
穷举输入测试要强于穷举路径测试。
软件测试的原则
1.测试用例中一个必需部分是对于其输出或结果进行定义
2.程序员应当避免测试自己编写的程序
3.编写软件的组织不应当测试自己编写的软件
4.应当彻底检查每个测试的执行结果
5.测试用例的编写不仅应当根据有效和预料到的输入情况，而且也应当根据无效和未预料到的输入情况
6.检查程序是否“未做其应该做的”仅是测试的一半，测试的另一半是检查程序是否“做了其不应该做的”
7.应避免测试用例用后即弃，除非软件本身就是一个一次性的软件
8.计划测试工作时不应默许假定不会发现错误
9.程序某部分存在更多错误的可能性，与该部分已发现错误的数量成正比
10.软件测试是一项极富创造性、极具智力挑战性的工作
