自动化测试一直是测试人员的夙愿。
从 AutoIT，到 winrunner。从 QTP 到 UFT。
从 Selenium 到 Cucumber。
从 UI 自动化到接口自动化。
从工具到代码，再到测试平台。
可以说伴随测试的发展，关于自动化的讨论和尝试就没有停止过。
但是纵观目前的实际测试工作中，依然以手工测试为主，自动化只能用来装点门面和提高逼格。
能够使用自动化达到一定效果的公司都是凤毛麟角。自动化团队建了又拆，拆了又建。
感觉自动化就是一个谬论。
其实自动化为何难做，就像测试始终无法统一技术一样，因为开发的技术多种多样没有统一。不同的公司，不同的团队，使用的语言、架构、针对的业务也千差万别。所以没有通用的理论和可借鉴的经验，完全只有靠自己摸索。
当互联网时代来临，所有的软件开发都求一个快字，不止技术快，业务变化也快。昨天共享经济还是风口上的猪，今天就已日落西山；昨天还是未来希望的技术，明天就可能一文不值。
在这样的时代，测试只有追随。面对变化多端的业务，自动化的脚本才写出来，可能项目就结束了。
现在的技术架构也越来越复杂，导致环境部署变得复杂而脆弱，自动化脚本在自己机器上运行 100 次都 0 故障，到了测试环境一上去就挂。
如何让自动化能达到效果，不再仅仅是学一门语言一个框架一个工具就能搞定的事情了。
自动化测试不宜大力投入
不管是自动化测试还是接口测试，都不宜在前期大量投入。当前业务是否适用自动化，哪些框架或者工具更适合，适合做接口自动化还是 UI 的自动化？如何让自动化达到收益和效果？
这些问题都需要根据团队和业务具体的情况去尝试，找到合适的才行。如果前期投入太大，团队对其期望太高，非常容易在遇到一点挫折的时候对自动化丧失信心。
另外，投入太大，毕竟加大人力或者减少手工测试的投入，会造成测试资源的紧张。在项目时间和成本的压力下，测试管理者需要顶着巨大的压力，这本身就很难成功。
可以安排一些技术强或者技术兴趣浓厚的成员，在项目允许的情况下减少其手工测试工作量，让其可以利用部分工作时间和部分业余时间尝试做自动化，先局部功能尝试，能够有效果，在扩大范围。逐步达到一定的自动化规模。
以接口为主UI为辅
UI 自动化因其运行环境的问题，会导致运行速度慢，对环境依赖过高。同时因程序界面的多变性，导致自动化脚本维护成本大大增加。
接口测试有很多优于 UI 自动化的地方。但是接口测试也自有其短板，对流程性质的测试并不适合用接口自动化来覆盖。接口自动化更适合覆盖单一接口功能的检查。
所以我们可以采用核心业务流程使用 UI 自动化，单一功能使用接口自动化，两种层面的自动化结合的方式来进行。
不轻谈自动化测试平台
目前测试界开始流行起自己开发测试平台（以接口为主）。简单来说就是模仿常见的接口测试工具，用 Python 或者 Java 写成了一个 web 版本的。
当然也有其理由，“定制性更强！”但是毕竟是软件都需要进行测试，花大量精力开发的平台并不稳定，而本身功能和理念上并没有太多更新。而这样的一些功能，市面上的绝大部分测试工具都能胜任。
如果是为了提高个人能力，项目时间有空余，怎么玩都可以。若是要在实际工作中应用，那么就有点得不偿失了。
自动化测试中，工具的重要性始终是最低的。理念、思维和环境治理才是最重要的。
通过不断小范围试错，找到适合自己团队的自动化策略才是最重要的。任何技术脱离实际应用都是耍流氓。
