谈谈UI自动化测试

前端逻辑越来越复杂之后，前端的发版压力也随之上升，曾几何时，发版当天晚上熬到凌晨，第二天还没到公司，已经心跳加速，两腿发软，指不定还没上班，报障电话已经打过来了，一直过了晌午才敢长嘘一口气。何以解忧，唯有自动化测试，那么前端自动化测试既然这么重要，为什么很难实施呢？

前端自身业务开发压力就很大

前端的业务交付压力很大，很难一边赶进度一边写用例，几乎兼顾不了。测试自己有手动测试任务，自动化测试又很难立竿见影对手动测试起到帮助作用，所以面临一个冷启动问题。

前端界面善变

随业务不断变化，UI就会发生变化，一旦发生变化很多自动化测试就跑不通，就要修改，这是一件很考验耐心的事情。

没有顺手的工具

工具太繁琐，跑一个用例要装这个装那个，还没写一个用例就已经把电脑卡的不行了。还有一些自动录制回放生成代码的工具，但是所生成的代码几乎难以维护。

解决方案

选择合适的工具

不要选择自动录制脚本的工具，那些必须依赖工具进行元素选择的测试框架。编程是唯一出路，除了编程的一切捷径就是自寻烦恼，因为代码都难维护，何况不是代码而是由工具生成的一堆语义不清的字符串？

选择合适的语言

nidejs仍然认为是首选，因为毕竟利益相关者是前端开发，并且前端开发有语言基础，然而秉着团结大多数的选择，选择JAVA也也不会错。

考虑移动端

如果兼顾到移动端，那么我们将争取到更多同盟者，自动化也就更有长期发展维护的可能性。

适当使用前端辅助

记住我们最终的目的是实现质量提升，而且在有限的资源投入情况下。如果在某些情况下，单纯自动化实现非常困难，可以让前端开发修改代码添加合适的类名，毕竟语义化对前端代码自身也是有价值的。甚至，前端提供一些后门代码帮助自动化测试顺利进行也是可以接受的。

最后，推荐几个工具供参考

selenide

一个对selenium接口进行简单封装的java自动化框架

puppeteer

chrome的无头浏览器版本

appium

可以用于移动端自动化测试的框架

nightwatch

nodejs版本的selenium接口封装