C++程序设计：原理与实践（进阶篇）（原书第2版）

26.3.3　算法和非算法

上文以binary_search（）为例介绍了一些简单的测试技术，binary_search（）是一个恰当的算法，它具有下列特点：

·对输入数据有明确的要求。

·明确描述了算法运行后对输入数据有什么影响（在本例中，没有影响）。

·算法不依赖于显式输入之外的数据。

·对于外部环境没有严格限制（例如，没有特殊的时间、空间和资源共享要求）。

它还包含了明显的前置和后置条件（见5.10节）。换句话说，它是测试人员梦寐以求的。但是，我们不可能总是这么幸运：很多时候我们不得不测试用糟糕的英语和很多图表表示的混乱代码（这还是乐观估计）。

等一下！我们是否对混乱的程序逻辑有些放任了呢？在不能准确描述代码要做什么的情况下，我们如何能够讨论正确性和测试呢？但问题是，在软件开发、测试中，很多内容都很难用非常清晰的数学形式来描述。而且，很多时候虽然在理论上能够给出严谨的数学描述，但所需数学知识超出了编写和测试代码的程序员的能力。因此，在现实世界的实际条件以及时间的双重压力下，我们只好放弃准确描述被测程序的理想目标，而要面对现实：只要被测程序在（测试人员，很多时候就是我们自己）掌握之中就可以了。

假设你要测试一个混乱的函数代码，这里“混乱”是指：

·输入：它对输入（隐式或显式的）的要求没有像我们希望的那样进行准确定义。

·输出：它对输出（隐式或显式的）的要求没有像我们希望的那样进行准确定义。

·资源：它所使用的资源（时间、内存、文件等）没有像我们希望的那样准确定义。

这里的“隐式或显式”表示我们不但要检查正式的参数和返回值，还要检查函数对全局变量、iostream、文件、空闲内存空间的分配等的影响。那么，我们要怎么做呢？首先，这类函数一般都很长，或者我们不能把它的需求和影响描述清楚。也许我们讨论的是一个有5页长的函数，或者它使用“辅助函数”的方式复杂、烦琐。你可能会认为5页很长了。是的，这确实很长，但我们还会遇到更长的函数。而且不幸的是，这种事情经常会发生。 ...