在这篇文章，我想和大家聊聊，是否应该开展UI自动化测试？
当然，如果我们广义上认为只要是UI层的都算，比如Monkey测试、各种专项测试等等，那么答案是一定要做的，但这次我是想聊狭义上的，只是针对UI层的功能自动化，我们是否应该开展？
不知道有多少公司真正把UI自动化做好了，假定我指的是覆盖率很高，比如80%以上。那你说，这公司、这产品、这版本，得多稳定啊！
首先，还是把UI自动化的开展思路和大家聊一下吧：
1、通过代码方式实现框架，要么自研，要么直接使用开源；
2、使用开源软件进行工具级别投入使用，少量自己开发，基本无代码；
下面来聊聊这两个方面
1、代码方式
好处：灵活、定制化高、可锻炼人员能力。
问题：需要大家掌握代码，起码达到用例编写级别。
2、工具方式
好处：对人员能力要求低，基于成熟工具可达到量产的地步。
问题：工具本身可能存在限制，过于依赖工具本身，也可能无法解决某些特殊的问题。
其实，所有工具都是为了一个目标，即：降低人员要求，提高团队效率。
这里顺便提下两款UI自动化测试工具：Robot Framework，Katalon。
不过多做细节阐述了，尤其Robot Framework知道的人太多了，这里我们简单聊一下Katalon。
总结以下几点好处：
1、能和CI集成，且很简单（这个是极其重要的）。
2、Web、App均可以。
3、无代码、易学习。
附2张图，图1是官方放出的Katalon Studio vs. Open source frameworks的直观对比，图2是2018 Top5的自动化测试工具，通过这2张图，你会发现Katalon确实是值得学习并且投入使用的。
回到正题，是否应该开展UI自动化测试？
1、应该开展UI层面的自动化，但不一定是功能的；
2、如果要做功能级别的UI自动化，前提是API层做的比较好了；
3、我们要结合公司当前现状，发版节奏、需求变化、产品生命周期等等综合因素一起确定。
如果你要做，那么我们聊聊应该怎么样让他产生价值：
1、优先挑选稳定少变的模块覆盖；
2、选择重点场景进行覆盖；
3、不要仅按照功能测试用例的步骤实现，而是要按照功能测试用例的一个suite为单位进行实现（设想如果一个用例有10步，你实现了其中6步，你认为覆盖率是60%，其实是0%。。。因为你少了4步，这个用例还是得需要人工执行）；
4、框架设计一定要好，这里面包括几点：用例分层、数据分离、模块公用、元素分离、数据驱动。
最后应该达成的最次效果，应该是这样的：
每天晚上服务器部署后，按照模块+场景执行API测试 → 按照模块+场景执行UI测试 → 进行各项专项测试（当然，2和3的顺序不一定一样），然后大家第二天上班，就可以看报告分析结果了。
最后：
做为管理者，我们本着以终为始的方式做事情，本着每件事情都有正确的方向和目标，基于这两点判断，相信本文的问题，你一定会有好的答案。