自动化测试最大的消耗可能是时间。有很多非常昂贵的工具，但也有免费的工具。即使是昂贵的工具的成本也不太可能与正确设置自动化测试所需的时间成本相匹配。只要管理层了解需要大量的前期成本，并且愿意承担这些成本，那么在实际自动化测试时就要注意这些：
Pitfalls
可维护性
自动化会产生维护方面的长期成本。请记住自动化测试就是软件开发。这意味着您会遇到与任何其他软件相同的潜在问题。这也意味着提高软件可维护性的相同方法也适用于自动化测试。 （这就是为什么我认为所有那些使用 vbscript 而不是正确的 OO 语言的“专业”工具都是垃圾。）
自动化测试也有其特殊的可维护性问题。最大的问题是您使用的是 UI 而不是 API。如果您曾经不得不使用不稳定的 API，您可能会开始理解通过不断变化的 UI 运行程序的痛苦。幸运的是，这个问题的解决方案是已知的，尽管并不总是得到很好的实现：对象映射。基本上，您有一些层一侧连接到 UI，另一侧连接到代码。代码端尽可能保持稳定，而 UI 端可以根据需要经常更改。
我工作的框架的一个例子：
public Image GoImage
{
get { return Browser.Image(Find.ById("BtnGo")); }
}
此示例使用 WatiN。有了这个，我在脚本中写了几行，例如GoImage.Click()，如果图像标签的 id 发生变化，我不会更改所有脚本，只会更新映射。
不应该自动化的测试
并非每个测试都应该自动化。有时，自动化测试比手动运行测试需要更长的时间。如果这是一个您只想运行一次或几次的测试，那么最好根本不要将其自动化。您可以通过创建快速创建自动化测试的方法来缓解这种情况。如果合适的话，数据驱动的测试自动化是实现这一目标的好方法。借助我们的测试自动化框架，我们可以通过修改 Excel 电子表格中的十几行来创建新的测试。
您还应该对创建仅部分自动化的测试脚本犹豫不决。当您可以自动执行测试步骤，但验证必须手动完成时，最常发生这种情况。理论上，您可以通过让自动化飞过 UI 并在用户进行检查时停止来获得一些速度增益，但心理因素会阻碍。大多数人会在自动化运行时退出，并且需要尽可能多的时间来弄清楚他们应该检查什么，因为他们必须手动运行整个测试。
该方法
就像我之前说过的，自动化测试是软件开发，所以这就是你处理它的方式。这是我发现的最基本的测试自动化设计：
接口库
您需要一些可以让您以编程方式控制 UI 的东西。这是商业工具往往做得很好的部分，但最近出现的开源项目也很好地处理了这个问题。对于 Windows UI，有white http://white.codeplex.com/。我从未使用过它，但我喜欢它的 API。 Web 自动化确实属于开源工具，例如watir http://watir.com/ and WatiN http://watin.sourceforge.net.
框架
框架是您自己创建所需的一切的总称。对象映射、辅助函数、数据驱动的脚本运行程序。商业工具试图为您提供这些，但我从未找到能够完全满足我需要的工具。我总是在这里自己滚动。这是大部分维护工作的所在，这就是为什么我如此看不起使用 vbscript 等弱语言的工具。我更喜欢使用 .NET 创建框架。
测试运行者
您需要一些东西来实际运行测试。商业工具也提供了这一点，而且它们在这方面做得足够好。但它们实际上并不比单元测试程序更好。是的，NUnit 对于 UI 自动化测试和单元测试一样有用。您还可以相当轻松地编写自定义测试运行程序。
记录和结果
您需要某种方法来知道测试是否成功。大多数现有的日志库（例如 log4n/log4j）都可以工作。测试运行程序通常也内置了此功能。只要您避免使用专有格式，商业工具通常也能获得良好的结果。
测试脚本
显然你需要测试本身。
我想说的最后一件事。测试自动化可以减少执行相同数量的测试所需的时间，但当您有在相同的时间内执行更多测试的心态时，它的效果会更好。
