从一次故障聊聊前端 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

posted @ 2020-07-19 00:43  格子熊  阅读(495)  评论(2编辑  收藏