从一次故障聊聊前端 UI 自动化测试

背景

事件的原由在于老板最近的两次“故障”，一次去年的，一次最近。共同缘由都是脚手架在发布平台发布打包时出错，致使线上应用白屏不可用。

最神奇的是，过后屡次 Code Review，结果仍是没有发现任何可以致使该问题的 bug，最后推测有多是服务器在发布打包的时候出了问题。

当老板第 N + 1 次吐槽由于他写的工程化工具领来的天外飞锅，我忽然思考起来，如何才能避免这种天外飞锅。

归根结底，致使这类线上故障的缘由都是在于打包上线的代码没有通过验证。针对这个问题，有两种方法能够解决：

1. 治本，因为请求地址不一样，预发（测试）版本不可直接发线上，而线上版本缺乏了上线以前的验证过程。因此，能够经过在发布系统的预发和线上之间，新增一个 beta 发布，beta 发布使用线上发布的打包流程，不一样的是，只容许内网访问，专门用于内部测试。有人可能会问，哪怕添加了 beta 发布，依然没法保证线上发布从新打包的时候不出错呀？重点来了，这种解决方案的核心就在于，beta 发布测试经过后，直接将 beta 发布的打包产物进行线上发布，由于不须要二次打包，因此避免了打包过程当中产生新的问题。因为添加 beta 发布须要不一样岗位，好比运维、后端、移动端的协做，因此实施难度较大。
2. 治标，既然线上版本上线以前验证不了，那么上线以后马上回归验证，若是发现问题，马上手动回滚。正所谓没有人发现的故障就不是故障，perfect！

正如以前所说的，治本的方法实施难度较大，因此，咱们重点关注治标的方法，即上线以后进行回归验证。

说到这里，问你们一个问题，需求上线以后，做为前端，你们会主动进行回归验证而不是等测试进行验证吗？

无论大家会不会，反正我是不会[doge]。

在这种状况下，前端 UI 自动化测试闪亮登场。

什么是前端 UI 自动化测试

众所周知，测试是一个很重要的环节，因为它的重要性，甚至软件工程中出现了 TDD 这种说法。

在以前，所谓的前端测试，更多的是在页面上点点点，进行人肉测试，毫无疑问，效率低下。

因此，有了前端自动化测试，使用机器代替人工。通常来讲，前端自动化测试分为两种：单元测试以及 e2e 测试（UI 自动化测试）。

单元测试本质上是一种白盒测试，是对程序中的最小可测试单元进行测试。

e2e 测试本质上是一种黑盒测试，至关于模拟用户访问应用程序，主要检查界面或功能是否正确。

相比于单元测试，UI 自动化测试更多的是站在用户角度，从用户的角度发现问题。可是，因为它实际上是一种黑盒测试，因此效率相对于白盒测试要低一些。

前端 UI 自动化测试框架对比

Selenium：e2e 测试鼻祖级的框架，有多种编程语言的版本，若是你去问问大家公司的测试，那么你必定会发现，他们正在用 Python 版本的 Selenium 写自动化测试脚本。值得一提的是，它是基于 webdriver 而不是 webkit 内核实现的，因此，Selenium 的浏览器兼容性相对于其余浏览器要好不少。

PhantomJS：开创性的 headless（无头）测试框架，何为 headless？即没有 UI 界面的浏览器。headless 最大好处在于能够像单元测试同样，在命令行中跑 e2e 测试。

nightmare：一句话——增强版的 PhantomJS，相对于 PhantomJS，不管是开发仍是运行效率都获得了很大的提高。

tips：nightmare 还有个优势——它提供了一个 Chrome 插件 daydream，该插件能够经过录制屏幕，自动化生成测试代码，懒人福音。

nightwatch：名字和 nightmare 很像，可是彻底不同的一个 e2e 框架，使用 Node 调用 webdriver 实现。相对于 Selenium，开发和运行效率更高，最重要的是，迭代很活跃，这点，用开源产品的用户懂得都懂。

cypress：我接触的第一个 e2e 测试框架，测试界面和文档作到极致的一个产品，推荐你们能够试一试。

puppeteer：e2e 测试框架的集大成者，默认以 headless 模式运行，可是也能够经过配置变为 Chromium 运行。开发效率以及运行效率一流，最重要的是，它像 nightmare 同样，提供了测试代码生成插件——puppeteer-recorder。

综上所述，若是考虑浏览器兼容性，使用 nightwatch，反之，选择 cypress 或者 puppeteer，若是须要 headless 或者自动化生成代码的功能，那就使用 puppeteer。

使用前端 UI 自动化测试的价值

从自动化测试的收益来讲，自动化测试有个公式：

自动化的收益 = 迭代次数 * 全手动执行成本 - 首次自动化成本 - 维护次数 * 维护成本

简而言之，迭代越频繁，维护成本越高的项目，添加自动化测试的价值越高。在基建项目或频繁迭代项目中引入前端 UI 自动化测试，能够大大减小每次迭代后手动测试的时间。比起手动测试，前端 UI 自动化测试测试的更快也更完全。

另外一个方面，随着前端技术的高速发展，各个公司的前端开发、监控体系已经很完善了，可是缺乏前端在测试方向上的延伸。而前端 UI 自动化测试最大的价值，就是在前端部分，弥补开发和监控之间的空白区域，造成一个完整的闭环，三管齐下，极大地保障了项目的质量。

将来的展望

针对前端 UI 自动化测试，我思考了好久，我的认为主要有两大方向：

1. 针对单个项目，进行一系列关键功能的测试，不过若是须要追求测试覆盖率的话，比较耗费时间，算是一种比较常规、精细的测试方案，因此比较适合一些长期维护的基建项目或者大型业务项目，缺点在于活动页基本覆盖不了。
2. 针对全部项目，添加一个自动化测试的脚手架（或者平台化），可以经过配置项，自动访问目标页面，并进行一系列的 e2e 测试，根据不一样的结果采起截图、生成 pdf、报警等不一样处理方案。

第二个方案，即通用化方案也是我最近开发的重点方向，接下来我应该会专门写一篇文章，大概介绍下该方案的设计以及具体实现（若是我没有懒癌发做的话[doge]）。

若是有不一样想法的同窗，欢迎一块儿交流~

个人 github：https://github.com/KarthusLorin/blog