在程序发展的每一个阶段所产生的问题是，每次重复的的回归测试所需时间太长，而且往往被证实功能并无明显变化。因此，缺陷存在的可能性是相当低的。自然的，其产生的结果就是，我们得出一个想法，自动化所有回归测试的场景，并拒绝手动进行回归测试。这里的好处非常显而易见：
自动化测试比人工更快;
自动化测试可以在任何时间进行;
自动化测试非常精确;
自动化可以用在几乎所有的测试过程中
可以自动创建报告。
但不幸的是，很少有关于回归测试自动化中所包含的陷阱的讨论。
在您开始进行自动化回归测试前，必须要解决几个问题：
测试将覆盖哪些功能;
自动测试架构；
选择回归测试自动化所使用的工具；
我们回到实际情况的做法。在从手动测试，我有一个项目，在自动化测试切换的阶段，我必须在43个由所在国家决定的域内测试两种类型的帐户注册。这简直糟透了。客户并不关心所显示的信息的质量。
要求如下：
创建账户时没有任何致命的错误;
输入信息与创建后显示在设置中的值一致。
经过几次运行，我意识到，我已经受够了。在那一刻，我只看到登记的字段数根据一些所在国家而不同，而我也有在C＃中一些编码经验。下一个回归测试近在咫尺，我不能再犹豫。我问我的熟悉自动化测试的朋友如何编写测试。经过很多问题，尝试和错误之后，一个简单的定位测试诞生了。我发现定位器和Selenium web driver——你瞧，所有的域都在使用相同的定位器。我有一个小事需要完成——对所有域运行人生中最后一次手动回归测试，并填写表中的字段和相应的域。新一轮的手动回归——一个长期的过程并完成表格——看起来一切都完成了。
我喜欢每一个的回归。我可以在运行回归测试的时候看一些电视剧。顺便说一句，这正好跟一集时间一致。虽然我曾经花费大约4-5小时测试43域的注册，现在自动化的回归测试只需花我40-45分钟，提供的非优化的代码，没有报告制度，没有合适的异常处理程序。
根据上面所说的，我们可以得到结论＃1：要说自动化测试的优势，我们应该先从最多次重复的测试开始，这通常是正面的，但他们需要每一个版本后运行。
这种情况持续了几个版本，直到该公司决定正式自动化大部分功能的测试。由于客户并不精通自动化测试，我们决定自动化所有在我的自动化测试知识范围内的部分。
这样一来，我们的自动测试已经覆盖了整个系统。一切应该都会好起来，但任何修正后的一些测试启动失败。大多数情况下，其发生原因是因为包含很多步骤的长脚本：
测试可以在第二个步骤就失败，作为测试的第一部分，往往会把系统带到某种状态，运行整个测试没有意义;
冗长的场景含有大量的代码和类似的行动;这使得重复第一步骤可能导致的许多测试失败。
因为代码的重复，自动测试会对相同的部分检查很多次;这会导致不必要的测试时间的增加。
在此基础上，我们可以得到结论＃2：过长的场景时，应手动运行，因为写他们需要花很多时间，而他们往往会因为第二个步骤所说的一些小错误或失误而失败。
让我们看看另一个非常有趣的情况。客户订购和往常一样的的自动测试，并要求写几个例子。他批准这个主意，并在几天内，我们添加了自动化测试的计划。但是，我们的程序员没有赶上最后期限，最后只好根据现阶段情况编写自动测试。随着程序员一两天的延迟发布，超过半数的自动测试不合格。
结论3：千万不要在有一个稳定的版本前开始写自动化测试。
就前段时间，我们有一个比较搞笑的事情。我们收到了完成一个网站的自动化测试的命令，并迅速所做好了一切。一切都很比以往任何时候更顺利。几个星期后，客户发了一封信，抱怨测试无法运行。事实证明，他开始重新设计网站，因此所有的测试都失败了。这件事教会了我测试稳定性的重要性。
因此，结论＃4：如果可能的话，使用定位程序，这样的话在微小的改变后元素还可以被找到。
因此，手工测试的优点是清楚地看到 - 它不依赖于任何东西，可以在所有的时间完成。抛弃手动测试不会带来什么好处。自动和手动测试是相互联系，相辅相成的测试方法，每个人都有优点和缺点。思考回归方案的自动化之前先考虑为其编写测试和支持的时间支出。另外，要注意手动测试专家通常薪水比那些拥有将测试自动化技能的人要低。
所以，一如既往，整个问题其实就是钱的问题。如果回归测试自动化方案节省了资金又不失产品的质量，那你可以扩大自动化方案的范围，直到产品质量升高，而你又节约了成本。这里的平衡方式是由你来决定的，取决于个人经验和喜好。
