很多团队都尝试过自动化测试，但一般都是浅尝则止，很少有非纯技术团队能够在自动化测试的道路上坚持下去。这到底是什么原因造成的呢？

首先自动化测试是一个很广义的概念，一般说来所有能替代人工测试的方式都属于自动化测试，我们一般说的单元测试就是自动化测试的一种，单元测试很多人称之为“毫秒级的自动化测试”。

自动化测试是很难的，从某种意义上来说比性能测试更难。性能测试可以依仗的东西很多，比如性能测试工具PR等，而自动化测试的工具很多情况下只是一个半成品，比如selenium ，你需要花很多时间去使用代码编写用例，并且维护这些用例，这一过程是漫长而艰辛的，特别对一些没有开发经验的测试人员来说，这个过程非常痛苦，每天的工作内容好像是自虐，而且自虐一段时间后信心基本崩溃，从此谈自动化色变，把所以的错归结于自动化测试策略与技术，而不从本身去找问题。 不过相比于性能测试而言，自动化测试的实践者往往是更加幸运的。

最简单的例子是一般的性能测试人员离开了性能测试工具PR基本上就无所作为了，而自动化测试人员则可以利用自己掌握的语言知识与代码知识自己创造工具，说实在的，这是一件很有成就感的事情，从简单的cli工具到复杂的web工具，一切都是托以前自动化测试实践的福。

自动化测试很难，那么我们为什么要坚持自动化呢？单元测试是保证代码质量最基本也是最根本的途径，单元测试是自动化测试的一种，因此自动化的重要性不言而喻；集成测试在很多情况下非常适合使用自动化的手段去运行，最明显的例子是rails里的integration test。

当你的单元测试和集成测试都没做好，甚至是没有做的情况下，UI级的自动化测试可以扮演救火队员的角色，尽管自动化测试的成本很高，但是可维护的UI测试代码是回归测试的福音，也是提高测试生产力的重要手段；

自动化测试可以培养团队，一个团队如果可以把自动化测试做好，那么他们的开发水平一定不低，而且如果这些人去做开发，代码的质量反而比一般的开发人员要高，原因很容易理解，测试人员坚信没有测试过的东西就是不可信的，代码如果没有被测试过，那么代码自然是不可信的，不可信的代码就需要用单元测试去覆盖，因此这可以从根本上提高代码的质量。