让我们来看看编译器报错的目的，很容易我们就可以看出它是用来保证我们编出正确的代码的，当然这
仅仅是正确的语法。它并不保证代码的功能。编译器对代码的测试，就很有效的提高了我们的工作效率。

我们也许应该尝试考虑这样的一个测试计划，用它来保证生产出正确的软件，而非仅仅是查找

Bug。Bug 或者说缺陷，通常的理解就是干扰程序正常运行的因素。很显然，如果程序正确，那么，Bug 就不应该
存在。这是一个理想状态，一个合理的测试过程，应该让我们更加接近这个状态。

合理的测试，会使软件产品趋于正确和完善。同时，测试也是验证这一结果的过程。对于用户而言，他
期望的是符合他需求的产品，测试的目的就是使产品不会偏离用户需求，并且达到一个合理的质量水平。并且当
场品对于客户的标准有所偏离时，测试能够为我们指明改正的方向。

4. 测试的效果

怎样评价一个测试的好坏呢？

最直接的看法是，是否找到了足够多的缺陷。假如我们有 50 个缺陷，几次测试中，分别找到了

1、20、0、50、13……也许我们会说，找到 50 个的那次最好，于是，大家学习他怎么测试的，答案也很简单，认
真。于是大家一起认真的测试，但还是没有几个能重复的找出全部缺陷。也许这个例子并不是很准确（里面描述
的情况比较理想化）。但是至少有一点我们可以肯定，认真是不可量化的，于是依赖于认真的结果也就无法有效

“

的进行评价。同时，这样的测试，我们绝对不敢拍着胸脯说：放心，一周内，我们会满足您的要求

!” 因为每次

测试的结果是不固定的，我们没有办法确定的评估产品目前的状况。

好的测试也许不能发现所有的缺陷，但是可以让我们准确的知道经过测试，我们的程序能够在什么样的
条件下正确，每次测试我们都能够提前的预知完全通过测试后的结果。

测试不是为了发现缺陷，而是让我们更加了解我们的软件产品。能够让我们有效的评估产品的测试，就
是好的测试。

另外，对于 Bug、缺陷等词汇最好有自己严格的定义，同时对于严重等级以及 Bug 分配规则等，也要
有不易产生误解的定义，才会使测试的效果得到保证。

5. 什么时候测试

我们通常在程序接近完成的时候开始测试。或者在程序有了雏形后开始测试。使雏形在不断的迭代中完
善。

从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对
较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。
即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，
按软件工程各阶段形成的结果，分别进行严格的审查。（《软件测试的组织与管理》）

测试不是为了我们编出正确的代码，而是制造出正确的产品，这是有很大不同的。软件产品的制造周期
不只是编码。我们完全有理由相信，在其他的过程中，同样会产生很多缺陷和

Bug。一个好的测试方案，应该贯

穿整个软件生命周期，而不是将测试排在编码之后（如经典的瀑布开发）。

同样，测试前置也是 XP( XProgramming )和 RUP（Rational Unified Process)的重要思想
之一。

我们为何不尽早的发现缺陷呢？（在我参与的几个项目中，我们都有一套比较完整的评审机制去完成这

“

”

些提前的测试工作。起到了很好的效果。）如果你问我什么时候需要测试，我会说：随时！

6. 通常的测试方法

自动测试，通常是利用专用的工具软件或专门为测试编写的代码进行的测试。特点是速度快，测试结果
准确，对于批量化的测试尤为明显。同时，测试的过程能够不断的重复。测试的流程清晰，每一个步骤都在控制
之内，我们清楚的知道测试过程中发生了什么。