步骤二、定义需求
在我们的故事里，我们可以看到和发起人相比自动化人员有不同的目标。为了避免这种情况，我们需要确信大家在测试自动化的需求上达成了一致。我们已经有描述哪些地方需要测试的测试需求。它要详细地描述我们的测试设计，而且要有描述自动化目标的自动化需求。很多人认为测试自动化就是目标，不需要再描述他们希望得到的是什么。以下是几个人们为什么选择自动化测试的原因：
加速测试以加快发布版本
测试可以执行地更加频繁
通过减少人力以减少测试的成本
提高测试覆盖率
确保一致性
提高测试的可靠性
允许没有什么技术的人员测试
定义测试流程并减少对了解产品的少数人的依赖
使测试更有意思
发展程序技能
开发管理层，测试管理层，测试人员和自动化测试的人员的目标经常是不同的。除非他们达成了一些协议，否则很难获得成功。
当然，以上有一些测试目标比其他的目标更容易达到。测试自动化实际上经常提高了测试人员所需的技能水平，因为他们必须要能够充分地理解已自动化的测试以便他们能够重现发现的问题。自动化不能帮助你从你的职员中抽取测试知识。无论如何，先清楚人们认为成功是什么。
手工测试人员在运行测试时，做了很多没有意识的事情。他们计划然后得到所需的资源。他们设置然后执行测试。他们注意是否有任何不正常的事情发生。他们对照测试结果。他们记录结果并重新设置系统以准备下一次测试。他们分析错误并调查古怪的行为。他们寻找失败的模式并想办法执行更多的测试以帮助定义缺陷。然后记录缺陷报告以使其得到修复，总结报告以让其他人知道他们已经测试了哪些地方。
不要硬逼自己自动化测试的每一部分。寻找你将来可能得到最大回报的地方。部分的自动化都是可行的。你可能发现最好的是自动化执行过程加上手工验证结果。或者你会选择自动化验证过程加上手工执行测试。我曾经听一些人说除非自动化测试完成了所有的事情，否则不是真正的自动化。那是胡说。如果你只是单纯地寻求挑战，那么你会尝试做所有的事。但是如果你是寻找成功，那么就集中精力在你可以快速获得能够让你再三使用的自动化测试上。
为你的测试自动化项目定义需求将促使多样的权衡变得更清晰。它也有助于合理地设置不同团体的期望。通过定义你的目标，你已经迈出了通往测试自动化成功的下一步。
步骤三、证实想法
在我们的故事里，我们看到自动化人员不是十分确切地明确他们的方向在哪里就进入了自动化项目。但是期间也得到了一些为项目提供的支持。
你可能没有意识到这一点，但是你必须证明你的测试自动化项目的可行性。它总是花了比人们想象更长的时间。为了得到承诺，我们需要得到来自组织里的各方面人员的支持。
许多年前，我在一个测试自动化项目里工作，我们有各式各样的好想法。我们设计了一个复杂的测试系统，接着努力的开发许多的组件。我们定时地做一些说明自己想法和进展情况的报告。我们甚至演示自己正在工作的部分。但是我们没有演示真正的测试。最终这个项目被取消了。从此我再也没有犯同样的错误。
你需要尽快地确认你的工具和方法。你的项目可能做自动化测试吗？这常常是很困难的。你需要尽快地找到答案。你需要查明你的工具和方法是否适合你的产品和职员。你需要的是一个想法的证据－一个快速的，有意义的可以证明你走在正确的道路上的测试包。可以证明想法的测试包是评估一个测试工具的最好方法。
对于很多人来说，测试自动化意味着GUI测试自动化。这和我所想的不一样。我做过GUI和非GUI的自动化，对听说大多数计划中所关心的问题是互相共享的，我感到吃惊。但是GUI测试工具是非常昂贵且很讲究的。很难说它们将会碰到什么样的困难。因此，选择正确的GUI测试工具是一个非常重要的决定。Elisabeth Hendrickson提供了一份非常好的选择工具的指南。我建议你将证实想法作为你评估的重要部分。这要求至少一个月的工具使用协议。你甚至可以先采购一份拷贝，评估之后再购买更多的拷贝。在你付出这一大笔钱之前，你应该可以找出工具的问题。你可以从供应商那得到些帮助，这样即使你发现不得不切换使用其他的工具时你也不会感到被欺骗了。
以下是一些证实想法的备选项：
回归测试。每一个版本你都要测试吗？这种测试是自动化的非常好的候选项
配置测试。你的软件要支持多少个不同的平台？你要测试所有的平台吗？一些自动化可能有些帮助。
设置测试床（Test bed）。相同的设置过程可能在许多不同的测试中使用。在自动化测试之前，先自动化设置步骤。
非GUI测试。自动化命令行和API测试比自动化GUI测试容易的多。
不管你的方法如何，定义一个可证明的目标然后集中证明它。这可以使你在成功的道路上迈的更远。
步骤四、拥护产品的可测试性
一个产品可能有三个不同的接口，分别是命令行接口（CLIs），应用程序编程接口（APIs）和图形用户界面（GUIs）。有些可能三个都有，但多数只有一个或两个。它们是你测试可用的接口。本质上，APIs和CLIs比自动化GUI容易地多。查明你的产品是否有这两者之一。有时它可能被隐藏了或者只给内部用户使用。如果不是的话，支持产品的可测试性要求你鼓励开发人员将CLI或API放到你的产品中。
但是首先，让我说说一些关于GUI测试自动化的事情。GUI测试自动化比人们常认识到的更困难，有几个原因。第一个原因是GUI测试自动化要求编写一些手工脚本。大多数的GUI自动化工有个叫“录制和回放”的功能，或叫“捕捉/回放”。这个想法是非常好的。你手工执行测试的同时，测试工具在后台工作并记录你的操作。然后生成你可以运行以重新执行测试的脚本。这是非常好的想法但很少工作。大多数作者认为尽管产生的代码可以重用，还是有各式各样的问题会阻止录制器有效地用于全面地测试生成。因此，你首先需要手工创建你的GUI测试。
第二个造成GUI测试自动化难点的原因关系到工具工作在产品上的技术挑战。这需要相当多专业的技术使GUI测试工具可以工作在最新的用户接口技术上。这个难点也是为什么GUI测试工具如此昂贵的一个主要原因。不标准的或自定制的控件会增加其他的难度。一般可以找到解决办法，但是通常需要修改产品的源代码或从工具供应商获得更新。测试工具中的错误可能需要分析和补丁或者绕行的办法。测试工具可能要求相当多的定制以使其更有效地工作在你产品接口的自定制的控件上。这种工作的困难度让大家吃惊。你可能也会重设计测试以避开那些有困难的控件。
第三个使GUI测试自动化的原因涉及到要跟上GUI的设计变更。众人皆知GUI在整个开发得过程中是经常要修改的和重新设计。GUI的第一个版本一般是比较糟的。但是要保持自动化脚本在GUI一直在更改的过程中都可以运行必须经常要运行它。你可以花大量的时间修改你的测试脚本以使其可以运行在变更中的界面。然而，你不想站在争论有帮助的改进方法的对立面。我曾经处在那种情况下，那是非常不舒服的。在最初的设计被重新做过之后可编程接口的变动率会便少。
以上是不依赖GUI测试自动化作为测试你产品功能的基础原因。GUI仍然需要测试，当然，你可以选择自动化这些测试。但是你应该有其他的可以依赖测试核心产品功能的测试，它们在GUI重新被设计时不会被破坏的。这些测试需要通过一个不同的接口的工作：命令行或API。我曾经看过人们选择GUI测试自动化是因为他们不想修改产品。但是最终他们认识到为了使GUI测试自动化可以工作，必须修改产品。自动化是很可能要求产品修改成你所需的模样。因此要求一个可编程的接口是可靠的。
为了使测试一个API更加容易，你可以需要绑定一个编译器，好比TCL或Perl或甚至使Python。它们使互动测试变得可能并且可以加快自动化测试的开发速度。工作在API上可以使你为单独的产品组件成为自动化单元测试。
一个很可能隐藏的可编程接口的例子是InstallShield，一种非常流行的开发安装程序的工具。InstallShield有命令行选项可以激活安静安装（Silent Install）。这样允许从你提前创建的回应文件中读取安装选项。利用这种方法比自动化InstallShield的GUI本身更容易和可靠。
另一个关于你可能如何避开GUI自动化的例子是关于基于web的软件。GUI工具可以通过浏览器操作web的界面。但是直接测试web浏览器用来和Web服务器通信的HTTP协议会更容易些。Perl是也是唯一一个能够直接连接到TCP/IP端口的语言工具，可以做它的自动化。使用先进的接口技术的应用程序，例如客户端的Java或ActiveX不能采用这种方法。但是如果这种方法是适用的话，你可能会发现这种自动化比通过GUI工作更便宜且更容易。
我曾经被雇来为一个产品的GUI编写自动化的测试。这个产品有一个已经被自动化测试了的命令行的接口。在经过一些调查之后，我认识到要发现GUI的错误不是困难的，但是客户没有给予和他们高兴使用CLI一样多的关心。我也认识到我们没有为最新的功能做自动化（不管是通过GUI还是CLI）。我决定不作GUI测试自动化而是扩张CLI的测试包以覆盖最新的功能。回头想想，我有时认为我选择不做GUI测试自动化项目是我最大的成功之一，因为那可能会浪费所有的时间和工作量。他们已经为GUI自动化做好准备了，他们购买了工具和所有的东西。但是我知道他们也将面临各种各样的困难和障碍，然而可能只会收获非常有限的回报。
无论你是需要GUI，CLI或是API自动化的支持，如果你早一些提出问题，你将更成功的得到为产品设计可测试性的功能，尽管产品可能还在设计中。启发开发人员认识到可测试性也是产品的一个需求。
