软件测试的经济学
给出了软件测试的适当定义之后，下一步是确定软件测试是否能够发现“所有”的错误。我们将证明答案是否定的，即使是规模很小的程序。一般说来，要发现程序中的所有错误也是不切实际的，常常也是不可能的。这个基本的问题反过来暗示出软件测试的经济学问题、测试人员对被测软件的期望，以及测试用例的设计方式。
为了应对测试经济学的挑战，应该在开始测试之前建立某些策略。黑盒测试和白盒测试是两种昀普遍的策略，我们将在下面两节中讨论。
黑盒测试
黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输入/输出驱动的测试。使用这种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将重点集中放在发现程序不按其规范正确运行的环境条件。
在这种方法中，测试数据完全来源于软件规范（换句话说，不需要去了解程序的内部结构）。如果想用这种方法来发现程序的所有错误，判定的标准是“穷举输入测试”，将所有可能的输入条件都作为测试用例。为什么这样做？比如说在三角形测试的程序中，试过了三个等边三角形的测试用例。这不能确保正确地判断出所有的等边三角形。程序中可能包含对边长为 3842，3842，3842的特殊检查，并指出此三角形为不规则三角形。由于程序是个黑盒子，因此能够确定此条语句存在的惟一方法，是试验所有的输入情况。
要穷举测试这个三角形程序，可能需要为所有有效的三角形创建测试用例，只要三角形边长在开发语言允许的昀大整数值范围内。这些测试用例本身是天文数字，但这还决不是所谓穷尽的，当程序指出 -3，4，5是一个不规则三角形或 2，A， 2是一个等腰三角形时，问题暴露出来了，为了确保能够发现所有这样的错误，不仅得用所有有效的输入，而且还得用所有可能的输入进行测试。因此，为了穷举测试三角形程序，实际上需要创建无限的测试用例：这当然是不可能的。
如果测试这个三角形程序都这么难的话，那么要穷举测试一个稍大些的程序的难度更大了，设想一下，如果要对一个 C++编译器进行黑盒穷举测试，不仅要创建代表所有有效 C++程序的测试用例（实际上，这又是个无穷数），还需要创建代表所有无效 C++程序的测试用例（无穷数），以确保编译器能够检测出它们是无效的。也是说，编译器必须进行测试，确保其不会执行不应执行的操作——如顺利地编译成功一个语法上不正确的程序。
如果程序使用到数据存储，如操作系统或数据库应用程序，这个问题会变得尤为严重。举例来说，在航班预定系统这样的数据库应用程序中，诸如数据库查询、航班预约这样的事务处理需要随上次事务的执行情况而定，因此，不仅要测试所有有效的和无效的事务处理，还要测试所有可能的事务处理顺序。
上述讨论说明，穷举输入测试是无法实现的，这有两方面的含义，一是我们无法测试一个程序以确保它是无错的，二是软件测试中需要考虑的一个基本问题是软件测试的经济学。也是说，由于穷举测试是不可能的，测试投人的目标在于通过有限的测试用例，昀大限度地提高发现的问题的数量，以取得昀好的测试效果。除了其他因素之外，要实现这个目标，还需要能够窥见软件的内部，对程序作些合理但非无懈可击的假设（例如，如果三角形程序将 2，2，2视为等边三角形，那有理由认为程序对 3，3，3也作同样判断）。
白盒测试
另一种测试策略称为白盒测试或称逻辑驱动的测试，允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构迸行检查，从中获取测试数据（遗憾的是，常常忽略了程序的规范）。
在这里我们的目标是针对达种测试策略，建立起与黑盒测试中穷举输入测试相似的测试方法。也许有一个解决的办法，即将程序中的每条语句至少执行一次。但是我们不难证明，这还是远远不够的。这种方法通常称为穷举路径测试，以后将进一步进行深入探讨，在这里不多加叙述。所谓穷举路径测试，即如果使用测试用例执行了程序中所有可能的控制流路径，那么程序有可能得到了完全测试。
然而，这个论断存在两个问题。首先，程序中不同逻辑路径的数昀可能达到天文数字。图 2-1所示的小程序显示了这一点。该图是一个控制流图，每一个结点或圆圈都代表一个按顺序执行的语句段，通常以一个分支语句结束。每一条边或弧线表示语句段之间的控制(分支)的转换。图 2-1描述的是一个有着 10~20行语句的程序，包含一个迭代 20次的 DO循环。在 DO循环体中，包含一系列嵌套的 IF语句。要确定不同逻辑路径的数量，也相当于要确定从点 a~点 b之间所有不同路径的数量(假定程序中所有的判断语句都是相互独立的)。这个数量大约是 1014，即 100万亿，是从 520+519…十 51计算而来，5是循环体内的路径数量。由于大多数的人难以对这个数字有一个直观的概念，不妨设想一下：如果在每五分钟内可以编写、执行和确认一个测试用例，那么需要大约 10亿年才能测试完所有的路径。假如可以快上 300倍，每秒完成一次测试，也得用漫长的 320万年才能完成这项工作。
当然，在实际程序中，判断并非都是彼此独立的，这意味着可能实际执行的路径数量要稍微少一些。但是，从另一方面来讲，实际应用的程序要比图 2-1所描述的简单程序复杂得多。因此，穷举路径测试如同穷举输入测试，非但不可能，也是不切实际的。
“穷举路径测试即完全的测试”论断存在的第二个问题是，虽然我们可以测试到程序中的所有路径，但是程序可能仍然存在着错误。这有三个原因。
第一，即使是穷举路径测试也决不能保证程序符合其设计规范。举例来说，如果要编写一个升序排序程序，但却错误地编成了一个降序排序程序，那么穷举路径测试没多大价值了；程序仍然存在着一个缺陷：它是个错误的程序因为不符合设计的规范。
第二，程序可能会因为缺少某些路径而存在问题。穷举路径测试当然不能发现缺少了哪些必需路径。
第三，穷举路径测试可能不会暴露数据敏感错误。这样的例子有很多，举一个简单的例子能说明问题。假设在某个程序中要比较两个数值是否收敛，也是检查两个数值之间的差异是否小于某个既定的值。比如，我们可能会这样编一条 Java 语言的 IF语句：
if (a – b < c)System.Out.println(“a-b<c”)； 当然，这条语句包含一个错误，因为它可能将 c与 a-b的值进行比较。然而，要找出这样的错误，取决于 a和 b所取的值，而仅仅执行程序中的每条路径并不一定能找出错误来。
总之，尽管穷举输入测试要强于穷举路径测试，但两者都不是有效的方法，因为这两种方法都不可行。那么，也许存在别的方法，将黑盒测试和白盒测试的要素结合起来，形成一个合理但并不十分完美的测试策略。
