我们是否应该开展 UI 自动化测试

慢慢的，写了5篇文章了，从最初的觉得自己既然开始了，就得坚持每周写点东西。给自己总结，若是还能给别人帮助，那么就太好了。到现在突然发现貌似周四周五的深夜，喜欢思考，静下心来想想得失，然后把文章写出来，挺高兴的。

当然我应该是做不到一周一篇文章的，我首先还是把这件事情，当成对自己的总结、提升。其次，确实是非职业再做，更不想写烂文章。

这篇文章，想和大家聊聊，我们是否应该开展UI自动化测试。

当然，如果我们广义上认为只要是UI层的都算，比如Monkey测试、各种专项测试等等，那么答案还是一定要做的，但这次我是想聊狭义上的，只是针对UI层的功能自动化，我们是否应该开展。

近10年的测试工作，我经历了3家公司，都是总公司在北京，分公司在我当地的城市。二线城市，大厂很少。从第二家起，我开始真正涉及到UI自动化，并从学习到维护框架到搭建框架。

第三家公司，领导特别重视 UI功能自动化 ，注意我说的是UI的功能自动化，并非其他自动化。反而我在经过了这几年以后，对UI自动化已经从最初的 热情、激动 ，变为现在的 平静， 甚至 冷淡 了。

我们在第一篇文章说过，UI自动化是投资最高，收获最低的，详见第一篇文章内容： 我们应该如何推进测试体系建设 —— 技术推进篇

不知道有多少公司真正把UI自动化做好了，假定我指的是覆盖率很高，比如 80%以上 。那你说，这公司、这产品、这版本，得多稳定啊。

首先，我们既然聊到这了，还是把UI自动化的开展思路和大家聊一下吧。

1， 通过代码方式实现框架，要么自研，要么直接使用开源

2， 使用开源软件进行工具级别投入使用，少量自己开发，基本无代码

下来我们聊聊这2个方面

1， 代码方式

好处：灵活、定制化高、可锻炼人员能力

问题：需要大家掌握代码，起码达到用例编写级别

2， 工具方式

好处：对人员能力要求低，基于成熟工具可达到量产的地步

问题：工具本身可能存在限制，过于依赖工具本身，也可能无法解决某些特殊的问题

其实，所有工具其实都是为了一个目标，即： 降低人员要求，提高团队效率

这里我们顺便提下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，我们要结合公司当前现状，发版节奏、需求变化、产品生命周期等等综合因素一起确定。

如果你要做，那么我们聊聊应该怎么样让他产生价值：

试想了下最后应该达成的最次效果，应该是这样的。
每天晚上服务器部署后，按照模块+场景执行API测试 → 按照模块+场景执行UI测试 → 进行各项专项测试（当然，2和3的顺序不一定一样），然后大家第二天上班，就可以看报告分析结果了。

最后，补充1点：

做为管理者，我们本着以终为始的方式做事情，我们本着每件事情都是有正确的方向和目标的，基于这2点判断，相信本文的问题，你一定会有好的答案。毕竟，我们得让大家做正确的事情啊。