测试人员一般使用两种形式的动态测试：自动化测试（通过编写代码来测试一个应用程序）和手工测试（使用程序的用户界面，手工输入数据进行测试）。

　　对自动化测试的评价可以说是毁誉参半。

　　说它不好是因为使用代码来进行测试，首先必须编写这些代码，这意味着测试人员也必须是一个开发人员。开发人员能否成为一个的测试人员呢？很多人可以，也有很多人不行，这并没有什么定论。但是自动化的测试代码中也存在缺陷，这是一个反复出现的事实，这意味着测试人员需要花费大量时间来编写代码、调试代码和再重写代码。一旦测试变成了一个开发项目，问题无法避免，即测试人员花费在测试软件上的时间多，还是花在维护自动化测试代码上的时间多？不用多想可以知道，后者的情况居多。

　　说它好是因为自动化测试很炫。编写一个简单的程序，可以执行无数次测试用例，还可以发现很多软件缺陷。在应用程序的代码改变后或需要进行回归测试（regression test）时，自动化测试代码可以被多次重复使用。这太妙了！太神奇了！简直应该对它顶礼膜拜！如果根据运行的测试用例多少来评价测试人员的能力的话，自动化测试铁定。但如果把评价标准变成根据所运行的测试用例的优劣来排名，结论完全不同了。

　　在软件行业，自动化测试已经行之多年，有些领域甚至已经有几十年历史了，但为什么软件发布到终用户手里时还会出问题？这是因为自动化测试和开发人员所做的其他测试都有某些共通的问题。首先是运行环境，代码运行的环境是一个测试环境，而不是一个真实的用户环境。因为自动化测试代码并不非常可靠（毕竟，它也属于软件的范畴），所以基本不会使用客户的真实数据库来运行自动化测试代码。如果自动化测试需要在数据库中删除或添加一些数据，想象一下哪个客户愿意在他们的真实数据库中运行这些代码？自动化测试还有一个致命弱点是“预言家难题”（oracle problem），至今尚无解决方案。

　　这里的“预言家难题”（oracle problem）指的是测试中艰巨的任务之一，是在运行一个测试用例时，如何才能知道被测试软件确实完成了它应该完成的任务？被测试软件是否输出了正确的结果？在运行过程中，是否带来任何副作用？如何才能确信这一点？如果给定一个用户环境，特定的数据配置和输入顺序，是否存在一个“预言家”可以根据这些情况做出这样的断言：“软件确实做了，也只做了它所应该做的事”？现实情况下，往往由于软件的设计规格说明书（spec）并不完整，或者根本没有，这导致软件的测试人员也没有办法做这个断言。

　　缺少这样一个预言家，自动化测试只能找到那些极端的问题，比如程序崩溃（crash）、死机（hang）或突发异常（exception）的情况。因为自动化测试本身是一个软件，所以不仅被测试的软件会崩溃，测试代码也常常会发生崩溃。那些比较微妙或复杂的错误便如此这般被略过了。看看第1章知道，有多少这样的关键错误躲过了测试，悄悄地溜入正式发布的代码。自动化确实很重要，但光靠它还不够，过度依赖自动化测试会为程序的终成功带来隐患。

　　现在，测试人员该怎么办呢？如果测试人员不能依靠开发人员的缺陷预防工具和自动化手段，他们还能寄希望于什么呢？的答案是手工测试。