Web UI 自动化测试技术选型

更新日期: 2018-08-16阅读: 3k标签: 自动化
The web has evolved. Finally, testing has too.

事实上对于 UI 自动化测试来说,许多所谓框架之间并没有太多差别,也从来不是影响整套测试用例是否健壮的关键性因素。相比之下,如何提高测试用例稳定性以及出现错误时 debug 的便捷性才是让 UI 自动化测试方案落地的重要细节。

那么为什么我们还需要讨论技术选型呢?首先我们来看看技术选型包含哪些部分。

通常 UI 自动化测试的技术方案分为控制(控制客户端)、执行(运行通过特定 api 编写的测试用例)、结果上报这几个主要组成部分,在过去各类框架往往喜欢在执行和结果上报两个部分提供差异化的 API 来提高开发效率,但这很难对我们开头提到的两个重要细节起到本质上的帮助。
随着 Web 技术的不断演进,Web UI 自动化测试中的控制部分也终于有了更进一步的发展,而且这一部分正是解决用例稳定性、提升 debug 能力的核心所在。

接下来就对比一下目前可选的几种控制方案的优缺点。


selenium + webdriver

selenium 的方案最为传统,也是目前最常见的浏览器控制方法。selenium 通常需要和 webdriver 配合使用,selenium 通过 webdriver 控制浏览器,再对上层执行层暴露 API 或 sdk。
同时 selenium 也提供 standalone server 的方案,允许执行层通过调用标准 restful API 控制浏览器,在这种模式下对执行层的编程语言和运行时都没有任何限制,这也是 selenium 生态繁荣的重要原因。

优点

selenium 的 API 封装遵循 W3C 提供的 webdriver 标准,因此 selenium 对各大主流浏览器的支持都不错,如果测试场景对浏览器兼容性有较高的要求,需要在多种浏览器中执行测试用例,selenium 仍是首选。
同时由于 selenium 已经发展多年,各种解决方案也更为完善。例如并行方案 selenium grid,可以支持多节点的用例负载均衡;还有在 CI 场景下官方维护的各种 docker image 等。

不足

selenium 是一套较重的方案,选择 selenium 意味着依赖 webdriver、java,如果执行层的编程语言不是 java,那么额外引入这些无疑是较为痛苦的。
另一方面,selenium 为主的方案一般会形成一个“测试用例 -> 测试框架 -> selenium -> webdriver -> 浏览器”的复杂控制链,链上每多一环就意味着 debug 的复杂度上升一级,这会让测试用例的编写成本显著上升。


chrome devtools protocol

chrome devtools protocol(以下简称 CDP)可以看作 chrome(或其他使用 Blink 内核的浏览器)开放的远程控制协议。通过 CDP 我们可以控制 dom、Debugger 和网络请求等浏览器内部领域,从而实现测试的目的。
相比之下 CDP 不依赖 webdriver 这样的二进制文件,也不绑定特定的编程语言,理论上可以直接在测试用例文件中和 CDP 通信,控制浏览器。但是实际上已经有很多成熟的 CDP 封装,大部分情况下我们使用它们而不是直接和 CDP 交互。
对 CDP 的封装可以大致分为两类,一类是只对网络通信部分封装,而不涉及启动浏览器、管理浏览器进程等工作。例如 chrome-remote-interface 就属于这类,只提供了良好的 JS API 封装,如果需要满足自动化测试的需求还需要搭配 chrome-launcher 这样的库对浏览器进程进行可编程的管理。
另一类则是一体化的方案,最佳实践是 google 自己维护的 puppeteer 项目。puppeteer 不仅负责管理浏览器和将 CDP 封装成 high level 的 API,甚至还默认下载一个指定版本的 chromium 并使用,以避免本地浏览器版本不确定带来的稳定性隐患。

优点

作为控制部分,CDP 的方案往往控制链较短,并且对编程语言没有限制,相对而言会更加稳定,并且也带来更好的执行速度。
chrome 在 59 版本开始引入了 headless 模式,这对 CI 流程来说有很大的帮助。过去如果需要在 linux 服务器上运行 Web UI 测试,通常都需要引入 xvfb 模拟屏幕,headless 模式则可以省去。
除此之外,CDP 相比 webdriver 标准控制能力更强,例如可以对网络层进行监听,从而可以轻松实现“所有网络请求完成后开始交互”这样的功能。

不足

CDP 方案只能兼容 Blink 内核的浏览器,因此对浏览器兼容性有要求的测试不应该选用。
不论是 CDP 还是更进一步的 puppeteer,目标都是实现一个通用的自动化工具,而不是聚焦于测试。因此其内部没有集成测试相关的功能,例如断言、用例编排、结果上报、执行负载均衡等等,需要继续引入第三方库或自行实现,这作为一个测试框架而言不够理想。


Inject script

Inject script 的方式是指在浏览器打开的 Web 应用内注入测试引擎、测试用例等脚本,将测试用例执行在被测试应用的运行时中。
Cypress 和 Testcafe 这两个测试框架是这类控制方式的实践者,它们认为过去许多依托于 selenium 构建的测试框架的核心问题在于都是从外部控制浏览器和 Web 应用,执行命令或者获取信息都需要通过网络请求进行交互,因此交互的信息需要进行序列化。这不仅限制了交互的内容,还对 debug 带来了极大的不便,同时网络请求带来的开销也让测试变得更加缓慢。
与之相反的是 inject script 选择从内部控制浏览器,测试用例代码将和被测试的 Web 应用运行在同一个浏览器运行时中,可以理解为注入的脚本即为测试客户端,与后端建立通信,所有的操作指令都是通过 Javascipt 实现并执行,本质上只是函数的调用,客户端和后端之间的通信仅用于测试结果的收集,不包含具体的指令执行。
值得一提的是 selenium 1 中最早采用的也是类似 inject script 的实现,但是由于当时各个浏览器中的 Javascript 运行时缺乏统一的标准,执行结果不一致,因此产生了很多兼容性问题,selenium 才不得不通过标准更规范、并且有厂商支持的 webdriver 来进行控制。但时至今日,Javascript 规范已经非常成熟,主流浏览器的 Javascript 内核也都严格遵循规范予以实现,inject script 方案最大的弱点也就得以克服。
Cypress 和 Testcafe 的定位是完整的测试框架,并且只聚焦于完成 UI 自动化测试这一个任务,内部包含执行框架、断言、请求 mock、结果上报等所有测试所需功能,不需要再配置其它的依赖项。
由于控制流程的改进,双方在测试稳定性、运行速度方面都有很大的改善,可以被视作是下一代 UI 测试框架,但是两者也因为目标场景略有不同而在一些方面各有优劣,需要根据实际使用场景进行选择。

优点

用例执行的稳定性在两个框架中都作为最高优先级加以解决。许多 UI 测试的不稳定性来源于不能很好的处理界面中的异步情况,而 Cypress 和 Testcafe 在指令的 API 设计中就默认所有指令均有异步情况,会自动完成 wait 的处理。
此外同一运行时的设计在测试一些现代前端框架构建的应用时有巨大的优势,例如直接测试框架数据状态管理(如 redux)的正确性等等,支持编写一些更偏向白盒测试的用例。
双方也都有官方支持的 CI 集成方案,保证在 linux 服务器环境下也能够快速的搭建起运行环境。
不同之处在于 Testcafe 原本是商业产品,有着成熟的客户群体和解决方案,在转向开源之后依然能够发挥其经验丰富的优势,在一些实现上更注重易用性。因此会封装更高级的指令,例如拖拽、文件上传等等,并且所有指令均用原生 Javascript 实现,所以对浏览器的兼容性很好。还对测试用例提供了预处理器,所以用户可以选择用最新的 Javascript 特性编写用例或者使用 Typescript 这样的超集语言。
高级功能方面 testcafe 支持通过录制操作生成脚本,对于一些非开发人员来说提供了一定的便利性。
相比之下 Cypress 的目标不仅仅是做 selenium 的替代品,更希望成为革命性的测试框架,因此做了更多大刀阔斧的改进。
以上多次提到的 debug 问题是 Cypress 的最大优势,Cypress 实现了 DOM 快照、操作回放、指令可视化、网络请求监控等功能让用例执行失败的原因一目了然。
高级功能方面 Cypress 原生支持截屏、录屏等功能,进一步加强 headless 模式或 CI 模式下的 debug 能力。
Cypress 另一大高级功能是对应用中的网络请求实现监控、mock 等操作,让一些原本通过 UI 比较难以实现的断言可以转为对网络请求进行判断。

不足

双方的不足更多是和对方相比较之下产生的。
Testcafe 对高级功能的支持有所不足,例如录屏和 DOM 快照等高效的 debug 方案还未实现。
Cypress 部分指令和高级功能普通 Javascript 无法实现,需要借助 chrome extension API,因此目前并不能兼容所有的浏览器。并且由于特殊的控制实现方式,Cypress 不能支持跨浏览器、跨 tab 的测试需求,还要求被测试 Web 应用是同源的。
此外 Cypress 还有一些临时性的不足,例如用例执行时的负载均衡等高级功能的支持还不完整,一些原生操作例如文件上传也还需要通过 Javascript 模拟,不过这些临时问题都在 roadmap 上排期解决。


来源:https://segmentfault.com/a/1190000016012033

链接: https://www.fly63.com/article/detial/1011

mocha自动化测试程序:node.js测试框架Mocha源码分析

Mocha.js是被广泛使用的Javascript测试框架,在浏览器和Node环境都可以使用。Mocha提供TDD和BDD的测试接口。 Mocha提供了:断言单元测试,可以进行功能性测试,同步代码测试,异步代码测试

什么时候需要自动化?

自动化是科技行业前进的方向,但它也是一把双刃剑。做对了,能够削减费用开销,减少维护工作;做错了,会让流程更加复杂,并增加预算。就像任何技术或流程一样,自动化在某些时候、某些地方是有效的,而在其他一些领域

十大最佳自动化测试工具

对更快交付高质量软件(或\\\\\\\"快速质量\\\\\\\")的需求要求组织以敏捷,持续集成(CI)和DevOps方法论来寻找解决方案。测试自动化是这些方面的重要组成部分。最新的《 2018-2019年世界质量报告》表明

理解前端自动化测试TDD + BDD

在日常的开发中,整天赶需求的我们好像没有时间顾及自动化测试,尤其是在敏捷开发的时候。但其实自动化测试可以帮助我们提高代码和功能的健壮程度,大幅减少可能出现的bug。尤其是在复杂系统中

前端赋能业务 - Node实现自动化部署平台

是否有很多人跟我一样有这样的一个烦恼,每天有写不完的需求、改不完的BUG,每天撸着重复、繁琐的业务代码,担心着自己的技术成长

使用require.context实现前端工程自动化

一个webpack的api,通过执行require.context函数获取一个特定的上下文,主要用来实现自动化导入模块,在前端工程中,如果遇到从一个文件夹引入很多模块的情况,可以使用这个api,它会遍历文件夹中的指定文件,然后自动导入

使用自动化时的五个常见错误

随着自动化扩展到涵盖 IT 的更多方面,越来越多的管理员正在学习自动化技能并应用它们来减轻他们的工作量。自动化可以减轻重复性任务的负担,并为基础设施增加一定程度的一致性

内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!