● 自动化测试无法代替测试者

　　虽然 IBM 的“沃森”能够赢得智力问答比赛，但这并不代表当前的自动化测试具备足够的“智能”来替代测试人员。自动化测试只能够按照指定的步骤来执行测试，它实际上是在帮我们完成需要不断重复或者通过人工执行容易出错的工作，充当我们的“廉价劳动力”。而测试人员则能够解脱出来，进行更多创造性的工作。要知道测试人员在项目中永远是短缺的。

　　● 自动化测试的覆盖范围并非越大越好

　　100% 的自动化测试只是一个美好的愿景。事实上，有很多测试工作目前是计算机难以完成的。比如说，我们需要检查一篇文档打印稿的格式正确性，自动化测试脚本要如何实现呢？如果能够通过计算得出正确的结果，我们完全可以直接把它作为产品里的排版代码了。事实上，人所擅长的模糊判断恰恰是程序的短板。另外，自动化脚本的编写和维护同样需要成本，如果脚本的复用和重复执行所带来的收益小于我们的付出，这种自动化将变得毫无价值，因此，自动化测试也不适用于变化较频繁的功能区域——我们需要在覆盖率和成本之间寻求一个平衡。

　　● 自动化测试无法发现新的问题

　　呃，这是很奇怪的一个观点，对吧？在我们编写和调试自动化脚本的时候，或许能够发现一些产品的新问题，而一旦脚本投入使用之后，将不会帮助我们发现“新”的产品问题。因为，这些脚本只能不断的重复，来确保我们设计的测试用例在今后的日子里不会发现问题。自动测试脚本充当的更像是一个“守护者”而非“探索者”的角色，它将帮助我们更加确信产品没有问题。它们发现的问题通常都是回归性的，而不是新问题。

　　● 自动化测试需要成本

　　这又是一个显而易见的命题，不过自动化测试的成本经常会被忽略。和我们的产品一样，自动化测试脚本也是一堆代码。我们通过自动化测试来保证产品的正确性，而保证这些脚本的正确性却需要人工，这意味着我们需要开发、调试；产品是会不断演化的，昨天正确的脚本今天可能就是错误的，这意味着我们需要不断的维护。为了复用现有的脚本获得更大的价值，我们需要持续的改进自动化系统，甚至移植到新平台上。开发，维护，演进，请记住自动化测试需要长期的持续投资。

　　看过了上面这些内容，您是否会觉得自动化测试不再像想象中的那么美妙了？呵呵，请相信自动化测试并非万能，而现在的大型产品没有自动化测试的支持是万万不能的。作为我们的工具箱中的一个强力工具，我们需要用好它，发挥出它的威力。

　　如何进行 GUI 产品的自动化测试

　　四年前，在我们决定开始支持自动化测试时，所面对的最直接的问题就是，我们应该如何进行 GUI 产品的自动化测试呢？对于普通的单元测试，我们只需要给目标函数一个输入并检测输出就可以了；对于 Server 端逻辑的测试，我们只需要模拟客户端发起一个 HTTP 的请求就可以了；对于浏览器里的 Web 应用，我们理论上也可以通过 DOM 树进行直接操作。那么，对于在本地运行的 GUI 产品呢？我们又应该怎样去支持界面交互操作的自动化？在实际工作中我们发现这个问题其实可以分解成三个基础问题：

　　● 如何捕获需要操作的对象？

　　● 如何对捕获到的对象进行操作？

　　● 如何验证操作的结果？

　　好吧，让我们举个简单的例子来详细说明这三个问题。

　　下图 1 展示了一个基于 Java SWT 框架的 GUI 应用程序，它可以帮助您从 CD 库中挑选 CD 并下订单。您可以简单的通过列表选择您喜欢的 CD，然后通过点击“Place Order”按钮来下订单。

图 1. CD 订购程序