关于自动化 UI 测试的边边角角

[imsobear]

本文是阉割了内部资料之后的文章，且看且淡定...

相比于非常成熟的后端持续集成测试，针对页面的自动化 UI 测试还是一个相对冷门的领域，无论是业界还是我厂内部都没有一个相对完善的解决方案。

本文结合我开发 uitest 的经验，试图讲一下「如何去实现页面的自动化 UI 测试」，以及「集团内部 UI 测试工具介绍」。因为个人负责 uitest 的开发，无论是底层还是使用都非常熟悉，因此对于 uitest 会做比较详细的介绍。如有不正确之处，还望指正。

一、什么是自动化 UI 测试？

UI 测试大家都比较熟悉，项目提测后，测试和前端同学通过观察页面，点击一些元素，判断页面上的 DOM 是否存在问题，当然，因为大 IE 的存在，这个工作重复量极高。

在去年还是实习生的时候，因为自己是做前端的，所以经常要跟测试同学打交道，那时候就在想这样的测试工作是多么的无聊，当然这个过程会考验测试同学的耐心、经验等等等等，但是但是在技术上有很强的可替代性，换句话说这样的事很多人都可以做。

上面这些想法并非说测试的工作价值不高，相反的，这样的过程对于整个产品的质量非常之重要，但是从测试的角度出发，我们应该做点有技术含量的事，把这些重复的工作交给工具去完成，那么这个工具是什么？就是自动化 UI 测试工具。

假定我们的出发点是**「让工具有效减少测试的重复工作量」**（当然这只是其中之一），那么这个工具需要有什么样的能力？一句话的回答「有能力操作这个页面」。呜，怎么会这么简单，你一定是骗我的...

有能力操作页面可以翻译为：(1) 控制浏览器打开页面; (2) 可以向页面注入脚本(核心)；(3) 通过注入的脚本操作页面，进行一些判断；(4) 将最终的结果输出...

好了，我们大概知道要解决的问题了，那么是时候讨论一下技术方案了。

二、如何实现自动化 UI 测试？

1. 控制浏览器

一切绕过真实浏览器环境的谈自动化 UI 测试的方案都是扯淡。 ——达尔文

控制浏览器最传统的方式就是通过命令行打开一个浏览器，但是因为没法完成注入脚本，所以果断是不靠谱滴。靠谱的方案有连个：(1) webdriver; (2) 无头浏览器：phantomjs || SlimerJS。

(1) webdriver

为了防止本文写成一本书，所以此处不做详细的介绍，真相是楼主不太懂 T_T

webdriver 可以理解为一个封装了操作各种浏览器各种行为接口的一个工具。这里的各种浏览器有：chrome, firefox, IE, phantomjs 等；这里的各种行为有：打开、关闭、刷新、注入 js、引入浏览器插件等等。

webdriver 的优点：（一）真实的浏览器环境，得到的结果更加准确；（二）可以做兼容性测试。缺点：实现成本相对大一些。

(2) phantomjs || SlimerJS

这二位是什么呢，俗称 headless browser，虽然 SlimerJS 声称自己不是 headless，但是我不承认这一点，因为你倒是让我看到你的头啊...所谓 headless browser 就是无界面，运行于终端中的浏览器。

phantomjs 是基于 webkit 内核（类 chrome），SlimerJS 是基于 Gecko 内核（类 firefox），当然还有 CasperJS 是对上面两种封装。此处新的名词这么多，我就不信你还没看晕...

该方案的优点：（一）实现成本相对低一些；（二）提供的 API 更加奔放（实质上也未必）。缺点：与真实的浏览器有差异性。

关于「与真实的浏览器有差异性」这一点我深有体会，虽然说 uitest 是基于 webdriver 的方案，但在内部也整合了 phantomjs 的一些 API，曾经试图用 phantomjs 捕获页面的 jserror，深感差异不小，懂的人自然懂。

2-4. 向页面注入脚本

第 1 点讲了这么多，后面就简单点带过吧，两种方案搞定其一之后，后面的事情就是水到渠成了。

2. 注入脚本：查一下对应的 API，再踩上几十个坑应该就差不多了。
3. 操作脚本：这一步按需进行啦，测试框架需不需要？mocha 还是 jasmine？用 jquery 操作 dom 要不要？爱要不要...踩几个坑就差不多了。
4. 传出结果：工具本身的回调；http；socket.io...任你选，踩个坑就差不多了。

好了，四点都搞定了，自动化 UI 测试工具也差不多完成了。唉，too young too simple, 根据达尔文理论：「底层工具只是一小半，剩下的需要在实践中踩坑->优化」。这估计就是适者生存吧...

三、自动化 UI 测试工具介绍

内部资料，被 github 自动屏蔽掉了...ಥ_ಥ

四、一些个人的思考

关于自动化 UI 测试的意义，我能想到的有三点：

1. 有效减少测试同学的重复工作量；
2. 功能性测试：提早发现线上 bug；
3. 兼容性测试。

在这三点中，从产生价值和可操作性上来讲我更认同第2点，通过定时回归任务+自定义测试用例来近乎实时监控页面，注意这里提到的是自定义测试用例。因为每个业务是个性化的，通用的测试用例只能覆盖通用的问题，对于某个业务特定来讲，前端和测试一定知道这个页面的风险区，比如首屏、运营维护的区域，那针对这些风险点去做自定义的测试用例有更大的意义。

那么问题来了，既然你知道自定义测试用例的重要性，为什么不去推动呢？

门槛！上文说过，对于目前的工具，写自定义测试用例是有一定门槛的，对于前端同学会好一些，但对于测试同学门槛会更高，所以接下来 uitest 的主要目标就是降低这个门槛，让更多的负责人愿意主动去接入。

对于上面的三点意义，再做一些解释：

1. 减少测试同学的工作量：面对业务频繁改版，以及这一点需要高度的自定义化，投入产出比太低；
2. 减少线上 Bug: 参见上文；
3. 兼容性测试：有一定的意义，但跟第 2 点的价值有不小差距，因此更科学的方式应当是在第2 点完善 OK 的情况下再来做兼容性的功能。

好了，本文要讲的东西基本 KO，对于一些你不认可的观点以及不够严谨的技术点，欢迎指正...坚决不改(t_t joke~)

相关链接：

• 提到的工具们：webdriver, phantomjs, slimerjs, casperjs

[zlq4863947]

这个好