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

　背景

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

　　最神奇的是，事后多次 Code Review，结果还是没有发现任何能够导致该问题的 bug，最后推测有可能是服务器在发布打包的时候出了问题。

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

　　归根结底，导致这类线上故障的原因都是在于打包上线的代码没有经过验证。针对这个问题，有两种方法可以解决：

　　治本

　　由于请求地址不同，预发（测试）版本不可直接发线上，而线上版本缺少了上线之前的验证过程。所以，可以通过在发布系统的预发和线上之间，新增一个 beta 发布，beta 发布使用线上发布的打包流程，不同的是，只允许内网访问，专门用于内部测试。

　　有人可能会问，哪怕添加了 beta 发布，依然无法保证线上发布重新打包的时候不出错呀？

　　重点来了，这种解决方案的核心就在于，beta 发布测试通过后，直接将 beta 发布的打包产物进行线上发布，因为不需要二次打包，所以避免了打包过程中产生新的问题。由于添加 beta 发布需要不同岗位，比如运维、后端、移动端的协作，所以实施难度较大。

　　治标

　　既然线上版本上线之前验证不了，那么上线之后立刻回归验证，如果发现问题，立刻手动回滚。正所谓没有人发现的故障就不是故障，perfect！

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

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

　　不管你们会不会，反正我是不会。在这种情况下，前端 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、报警等不同处理方案。