《PlayWright全解析——从入门到精通》-1
写在前面的话
为啥会想到写关于PlayWright的东西,其实也是同事和网友的鼓励,都想全面学习一下这个新框架,行吧,那就写吧。虽然我也没接触多久,不过从源代码来看,整体还是比较简单的,再基于十多年的工作经验,以及Selenium和Cypress的使用经历,把自动化的这点东西用PlayWright展现一下,并不是多复杂的事情。
学一个框架,并没有什么困难的,跟着来吧。
PlayWright是啥
就像它的官方主页描述的那样:
-
它的自动等待,页面元素的智能断言,以及执行追踪特点,使得它能很好的应对了Web页面的不稳定性。
-
在不同于浏览器的进程中控制浏览器执行测试,这使得PlayWright摆脱了典型的进程内测试运行器的限制。并且可以穿透
Shadow DOM
。 -
Playwright为每个测试创建一个浏览器上下文,浏览器上下文相当于一个全新的浏览器配置文件,这提供了零开销的完全测试隔离,创建一个新的浏览器上下文只需要几毫秒。
-
提供了代码生成器,单步调试,追踪查看功能。
PlayWright VS Selenium VS Cypress
现在有什么好用的WebUI自动化测试框架?脱颖而出的自然是发展了十多年的Selenium
,以及这几年比较火的Cypress
。和我们这里将要介绍的PlayWright相比,有什么差别呢?我特意整理了一张表,给大家参考下:
特性 | PlayWright | Selenium | Cypress |
---|---|---|---|
支持的语言 | JavaScript, Java, C#, Python |
JavaScript, Java, C#, Python, Ruby |
JavaScript/TypeScript |
支持的浏览器 | Chrome, Edge, Firefox, Safari |
Chrome, Edge, Firefox, Safari, IE |
Chrome, Edge, Firefox, Safari |
测试框架 | 所支持语言的测试框架 | 所支持语言的测试框架 | 所支持语言的测试框架 |
易用性 | 使用和配置都简易 | 设置较为复杂, 有一定学习成本 |
使用和配置都简易 |
代码难度 | 简易 | 中等 | 简易 |
DOM操作 | 简易 | 中等 | 简易 |
社区成熟的 | 逐步完善 | 极为成熟 | 较为成熟 |
是否支持无头模式 | 是 | 是 | 是 |
是否支持并发 | 支持 | 支持 | 依赖CI/CD工具 |
iframe支持 | 支持 | 支持 | 通过插件支持 |
Driver | 不需要 | 每一种浏览器匹配一种Driver | 不需要 |
多Tab操作 | 支持 | 不支持 | 支持 |
拖拽 | 支持 | 支持 | 支持 |
内置报告 | 有 | 无 | 有 |
跨域 | 支持 | 支持 | 支持 |
内置调试功能 | 有 | 无 | 有 |
自动等待 | 有 | 无 | 有 |
内置截屏/录屏 | 有 | 无录屏 | 有 |
整体对比来看差别不大,对与测试工程师来说,能熟练使用
JavaScript/TypeScript
的不多,所以能支持Java
、C#
、Python
语言的测试框架显然会更受测试工程师的欢迎。
从原理方面而言,PlayWright和Selenium很接近,控制Chronium
类型的浏览器,都是使用了Google的Remote Debugging Protocol
,对Firefox这类没有Remote Debugging Protocol
的,则是采用了挂接js的方式,差别是Selenium封装了一个Driver,PlayWright则是直接调用。而Cypress则是直接使用了js来控制浏览器。
从支持的浏览器看,Selenium比其他两款多支持了IE浏览器,不过随着IE逐渐退出历史舞台,这一点已经不重要了。
易用性而言,三者其实差不多,都有一定的门槛,但是PlayWright和Cypress如果只是按照官方Demo写的简单用一下,那确实够方便,比Selenium更友好。但是要深入使用的话,三者都是有一定难度的。
执行效率而言,Cypress最高效,其次是PlayWright,最慢的是Selenium。经过实验,PlayWright的执行效率大概比Selenium(最新版本)高40%左右。
社区资源而已,Selenium是最成熟的,你在使用Selenium的时候,不管遇到什么问题,都能在网络上找到答案。Cypress这两年的资源也越来越多,而PlayWright还比较新,所以网上能找到的资料还比较少,很多问题需要自己读源码来理解。
至于录制,生成代码的功能,其实我不太关注,对真正做自动化测试来说也不实用,因为自动化一旦成规模,需要的是工程化的管理,录制生成的代码都要进行工程化改造,与其要改一堆代码来适配自己公司的工程化框架,还不如从一开始就自己手写更方便。
开始使用
虽然PlayWright支持多语言,实际上核心还是要依赖node.js
,不管是Python版本还是Java版本,在初始化时候都需要检查node.js
环境,并在初始化的时候,下载一个node.js
的driver
,而Java也好Python也好,封装的API都是需要调用这个程序。所以为了回归本源,这里主要使用JavaScript/TypeScript
来介绍。
安装与Demo
首先需要确定本机上已经安装了最新版本的node.js
,这个环境的安装就不再这里说了,自行去看node.js官网的说明。
接着就可以使用了,PlayWright的环境准备很简单,几乎不用配置什么东西,除非你需要使用自己的测试框架来创建PlayWright测试。
我们现在用PlayWright自身框架来创建测试项目,npm或者yarn都可以:
1 2 3 4 5 |
# 使用npm npm init playwright@latest # 使用yarn yarn create playwright |
注意,要在你准备好的项目目录下执行。
接着就是会引导你进行输入:
-
使用TypeScript还是JavaScript,默认是TypeScript;
-
测试案例目录名称;
-
是否需要添加一个GitHub的Action,用于在GitHub仓库中执行CI,默认是False;
-
是否需要安装PlayWright支持的浏览器,默认是True。
选择完成后,如果你在最后一步选择了需要它自行下载浏览器,那么PlayWright会进行必要的下载,它将从默认的网址去下载各个浏览器(chromium、firefox、webkit),这个过程时间会有点长,请耐心等待完成。
这个下载过程只会在机器上首次创建PlayWright测试项目的时候会经历,下载过一次后,只要PlayWright版本没有升级,那么就不会再次下载。原因这里就不说了,后面的章节我会详细介绍原因的。
PlayWright会自动生成项目模版,结构如下:
1 2 3 4 5 6 7 |
playwright.config.ts # PlayWright配置文件 package.json # nodejs配置文件 package-lock.json # nodejs配置锁定 tests/ # 你指定的测试案例目录 example.spec.ts # 测试案例的一个模版,实际编写时候可以删掉 tests-examples/ # 样例目录 demo-todo-app.spec.ts # 测试案例的样例 |
如果你想自己来组织目录,使用自己的测试框架,那就把PlayWright作为一个依赖引入,我会在后面的章节介绍这种做法。
因为有个example.spec.ts
,所以现在是可以直接运行的,在命令行执行:
1
|
npx playwright test
|
整个执行过程你将不会看到有任何浏览器弹出来,自动执行这个测试,而是在默默的运行,看下执行结果:
1 2 3 4 5 6 7 |
Running 6 tests using 6 workers 6 passed (21.8s) To open last HTML report run: npx playwright show-report |
显示执行了6个测试案例,并且使用了6个“工人”(workers),总共耗时21.8秒,如果想看html版本的测试报告,请运行如下命令。
1
|
npx playwright show-report
|
执行这个命令后会自动启动一个本地web服务,并且自动打开一个浏览器,展示HTML格式的报告如下:
从这个报告中我们可以看到其实执行了两个测试案例,一个叫”has title”,另一个叫”get started link”,这两个测试案例分别在三种浏览器上运行的结果,测试案例名称前面的勾子✅,则代表测试通过,如果失败会用红叉表示。