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

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

1，优先挑选稳定少变的模块覆盖；
2，选择重点场景进行覆盖；
3，不要仅按照功能测试用例的步骤实现，而是要按照功能测试用例的一个 suite 为单位进行实现（设想如果一个用例有 10 步，你实现了其中 6 步，你认为覆盖率是 60%，其实是 0%。。。因为你少了 4 步，这个用例还是得需要人工执行）；
4，框架设计一定要好，这里面包括几点：
4.1 用例分层
4.2 数据分离
4.3 模块公用
4.4 元素分离
4.5 数据驱动

试想了下最后的效果，应该是这样的，或者不能比这个次。

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