探索自动化测试是个好主意，但很难创建一个允许您“按几个按钮左右以确保一切按预期运行”的系统。自动化很少能完全或容易地替代手动测试。测试自动化需要大量的前期投资和持续的维护成本。它还需要手动测试人员不一定具备的技能。

Selenium 有两种使用方式：作为捕获/重放工具或作为编程 API。捕获/重播工具永远不会很好地工作（观看http://www.youtube.com/watch?feature=player_embedded&v=s_CUPs6xAWw以获得很好的解释），我不建议使用。Selenium 是用于编写 UI 测试的不错的编程 API，但它需要编程技能。

如果您对自动化测试感兴趣，我建议您为您的测试团队聘请一名程序员。与其启动一个大型项目来用自动化取代所有手动测试，我还建议从一个小型试点项目开始，因为你会边做边学。

目前，本论坛有 143 个问题提到了“自动化”这个词。我建议您至少阅读其中的一些以熟悉其中的一些问题。

目前，我们手动完成所有操作。当然这有几十个问题，最大的是耗时且不一致

恐怕这句话在 6 个月内很容易适用于任何建立在较弱手动流程上的自动化工作

目前，我们将一切自动化。当然这有几十个问题，最大的是耗时且不一致

有时自动化看起来是一个答案，但它几乎总是一个更好的长期投资来查看您的流程并询问一些关于您为什么处于当前位置的问题，当您需要考虑自动化以跟上时（这是不是自动化的目标，对您的团队来说是一个很大的警告信号，表明自动化无法实现您的目标）

我从您所说的内容中得到的印象是，您可能会被锁定在一个永久性的回归测试周期中，以达到非常短的发布期限；我的建议是寻找改进这个过程的方法并设定一个可持续的步伐，如果可能的话打包稍微大一点的版本，仍然可以尽早进行更改以进行测试，但不那么定期地发布到生产环境。我建议与您的开发人员讨论他们在检查更改方面可以做的事情，因为他们将是您业务中最有资格的人之一，可以建议您的特定产品可以实现何种程度的自动化。

我建议与您的开发人员和产品经理交谈，以解决手动流程中的问题，并在调查特定工具之前从高层次突出风险点，只有这样您才能评估自动化的真正成本/收益。

如果您最大的问题是时间和不一致，那么我建议您花一些时间查看您现有的流程（阅读：工作方式），看看可以以很少或没有成本的方式改进哪些内容，同时为您的整体提供非常直观的好处办公室。

一旦您了解了自己的工作方式，您将能够更好地了解如何引入涵盖每周构建回归的测试；只有这样，您才能引入让您变得更有效的测试。

现在我不会太担心测试自动化——它只是达到目的的一种手段——专注于你所知道的。

您需要做的第一件事是掌握您正在运行的测试类型。如果编写的自动化测试质量很差，那么进行一系列自动化测试将无济于事。

我曾与 TMap (www.tmap.net/en) 合作过，这是一种由荷兰大型咨询公司 Sogeti 撰写的测试宣言。他们有一系列白皮书和清单，您可以仔细阅读，包括确定您是否拥有正确的测试资源以及您应该进行哪种测试。

一旦你感觉到你的手动测试在正确的轨道上并且你想要自动化一系列重复的动作，那么你就可以开始研究什么样的自动化测试工具最适合你。你应该问自己一些关键问题：

1. 我在什么类型的平台上进行大部分测试？
2. 未来我们可能会使用哪些平台？
3. 我最想从我的自动化测试中完成什么？

请记住，编写自动化测试将与您现在正在进行的手动测试一样耗时，甚至更多。正如该线程的另一个答案中提到的那样，编写测试脚本没有灵丹妙药，尤其是在自动化测试方面。如果自动化程序正在您的屏幕上寻找 x/y 位置以进行点击，那么像调整屏幕大小这样简单的操作可能会破坏您的测试。

就自动化测试入门而言，Selenium 确实是一个很好的免费软件工具，用于测试基于 Web 的应用程序。请记住，一开始，您将在 FireFox 中进行所有测试。如果您的主要浏览器平台是 IE，则必须进行抽查，因为某些屏幕在 FireFox 中的绘制方式与在 IE 中的不同（我应该知道 - 我的上一个任务需要大量手动测试，因为我们只支持 IE，但开发人员一直在 FireFox 或 Chrome 上进行测试）。如果您需要测试桌面应用程序，您可以尝试 AutoHotKey，它提供了很多自动化功能，而无需眯着眼看屏幕试图弄清楚代码的含义。如果您有可以提供帮助的程序员，您也许可以将 Cucumber 与 Ruby 结合使用——前提是您有可以快速调试 Ruby 代码的人员。