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

发表于:2020-7-30 11:09

字体: | 上一篇 | 下一篇 | 我要投稿

 作者:鸽子熊    来源:博客园

  背景
  事件的起因在于老板最近的两次“故障”,一次去年的,一次最近。共同原因都是脚手架在发布平台发布打包时出错,导致线上应用白屏不可用。
  最神奇的是,事后多次 Code Review,结果还是没有发现任何能够导致该问题的 bug,最后推测有可能是服务器在发布打包的时候出了问题。
  当老板第 N + 1 次吐槽因为他写的工程化工具领来的天外飞锅,我突然思考起来,如何才能避免这种天外飞锅。
  归根结底,导致这类线上故障的原因都是在于打包上线的代码没有经过验证。针对这个问题,有两种方法可以解决:
  治本,由于请求地址不同,预发(测试)版本不可直接发线上,而线上版本缺少了上线之前的验证过程。所以,可以通过在发布系统的预发和线上之间,新增一个 beta 发布,beta 发布使用线上发布的打包流程,不同的是,只允许内网访问,专门用于内部测试。有人可能会问,哪怕添加了 beta 发布,依然无法保证线上发布重新打包的时候不出错呀?重点来了,这种解决方案的核心就在于,beta 发布测试通过后,直接将 beta 发布的打包产物进行线上发布,因为不需要二次打包,所以避免了打包过程中产生新的问题。由于添加 beta 发布需要不同岗位,比如运维、后端、移动端的协作,所以实施难度较大。
  治标,既然线上版本上线之前验证不了,那么上线之后立刻回归验证,如果发现问题,立刻手动回滚。正所谓没有人发现的故障就不是故障,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 自动化测试,我思考了很久,个人认为主要有两大方向:
  针对单个项目,进行一系列关键功能的测试,不过如果需要追求测试覆盖率的话,比较耗费时间,算是一种比较常规、精细的测试方案,所以比较适合一些长期维护的基建项目或者大型业务项目,缺点在于活动页基本覆盖不了。
  针对所有项目,添加一个自动化测试的脚手架(或者平台化),能够通过配置项,自动访问目标页面,并进行一系列的 e2e 测试,根据不同的结果采取截图、生成 pdf、报警等不同处理方案。
  第二个方案,即通用化方案也是我最近开发的重点方向,接下来我应该会专门写一篇文章,大概介绍下该方案的设计以及具体实现(如果我没有懒癌发作的话[doge])。
  如果有不同想法的同学,欢迎一起交流~
  我的 github:https://github.com/KarthusLorin/blog

      本文内容不用于商业目的,如涉及知识产权问题,请权利人联系51Testing小编(021-64471599-8017),我们将立即处理
《2023软件测试行业现状调查报告》独家发布~

关注51Testing

联系我们

快捷面板 站点地图 联系我们 广告服务 关于我们 站长统计 发展历程

法律顾问:上海兰迪律师事务所 项棋律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2024
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪ICP备05003035号

沪公网安备 31010102002173号