好的测试也许不能发现所有的缺陷，但是可以让我们准确的知道经过测试，我们的程序能够在什么样的条件下正确，每次测试我们都能够提前的预知完全通过测试后的结果。
测试不是为了发现缺陷，而是让我们更加了解我们的软件产品。能够让我们有效的评估产品的测试，就是好的测试。
另外，对于Bug、缺陷等词汇最好有自己严格的定义，同时对于严重等级以及Bug分配规则等，也要有不易产生误解的定义，才会使测试的效果得到保证。
5. 什么时候测试
我们通常在程序接近完成的时候开始测试。或者在程序有了雏形后开始测试。使雏形在不断的迭代中完善。
从软件的生存周期看，测试往往指对程序的测试，这样做的优点是被测对象明确，测试的可操作性相对较强。但是，由于测试的依据是规格说明书、设计文档和使用说明书，如果设计有错误，测试的质量就难以保证。即使测试后发现是设计的错误，这时，修改的代价是相当昂贵的。因此，较理想的做法应该是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的审查。（《软件测试的组织与管理》）
测试不是为了我们编出正确的代码，而是制造出正确的产品，这是有很大不同的。软件产品的制造周期不只是编码。我们完全有理由相信，在其他的过程中，同样会产生很多缺陷和Bug。一个好的测试方案，应该贯穿整个软件生命周期，而不是将测试排在编码之后（如经典的瀑布开发）。
同样，测试前置也是XP( XProgramming )和RUP（Rational Unified Process)的重要思想之一。
我们为何不尽早的发现缺陷呢？（在我参与的几个项目中，我们都有一套比较完整的评审机制去完成这些提前的测试工作。起到了很好的效果。）如果你问我什么时候需要测试，我会说：“随时！”
6. 通常的测试方法
自动测试，通常是利用专用的工具软件或专门为测试编写的代码进行的测试。特点是速度快，测试结果准确，对于批量化的测试尤为明显。同时，测试的过程能够不断的重复。测试的流程清晰，每一个步骤都在控制之内，我们清楚的知道测试过程中发生了什么。
缺点是，前期投入较大，为了建立起一个测试架构，必须在前期准备很多工作。且对于部分问题，机器是无法代替人的。
手动测试，恐怕是最直接简单的测试了。人与机器相比，有更好的逻辑思维能力，对于很多问题，只有人才能给出正确的答案。所以手动测试是不可替代的。
但是对于批量化的测试用例，输入输出检查，压力测试，算法逻辑检查等等，人力就显得过于单薄了。对于大批量的工作，人是十分容易疲倦和出现意外错误的。这会使测试过程效率低下且充满不确定因素。
对需要测试的软件选择人工测试还是自动测试就要看工作对于时间、人力、技术以及对稳定性的要求来平衡两者的比例了。这种情况下，不仅是努力工作就能完成工作的唯一方法了。 “Work Smartly”就显得非常重要。在ATC的测试组，每个人都不断地被来自Work Smartly的成就感所激励，测试工作成为他们展示创造性和智慧的舞台。（《微软是怎样做测试的》——ATC ( Advanced Technology Center，微软亚洲工程院 ) 测试组相关负责人）
文章来源于领测软件测试网 https://www.ltesting.net/
