终于有人拿来比较这几种了 Playwright 基于Puppeteer,但又向Selenium取了经,它能使用熟悉的npm语法快速轻松地安装,并使用JavaScript来构建网络应用程序自动化和测试。它可与更多浏览器一起使用,并支持Edge等基于Chromium的浏览器,以及Firefox和Apple的WebKit。但它也有它的劣势,用的人暂时不是很多,生态还不是很完整。不过从微软的投入上来看,Playwright还是很有发展前途的。Playwright VS Selenium VS Puppeteer VS Cypress
最终推荐还是用node.js 版本
这就的看公司技术栈了
image.png
Playwright VS Selenium 的区别
Context支持
Playwright有一个非常重要的功能,是它对浏览器Context的支持。它能够在单个浏览器实例中运行隔离的操作,因此您可以设置多个Context以同时测试多个Web页面。在每个Context中创建页面。页面支持它们自己的单击交互,并且可以并行监视。进入页面后,可以使用CSS或XPath选择器,HTML属性或文本,以不同的方式查找与之交互的内容。如果您熟悉Selenium,则应该浏览熟悉的页面,并具有等待页面完全加载或在单页面Web应用程序中呈现动态内容的附加功能。
推荐阅读更多精彩内容
第一部分 HTML&CSS整理答案 1. 什么是HTML5? 答:HTML5是最新的HTML标准。 注意:讲述HT...
HTML 篇 说说 title 和 alt 属性 两个属性都是当鼠标滑动到元素上的时候显示 alt 是 img 的...
1.一些开放性题目 1.自我介绍:除了基本个人信息以外,面试官更想听的是你与众不同的地方和你的优势。 2.项目介绍...
【转载】CSDN - 张林blog //blog.csdn.net/XIAOZHUXMEN/articl...
竿牍阅读 3,210评论 1赞 14
1.一些开放性题目 1.自我介绍:除了基本个人信息以外,面试官更想听的是你与众不同的地方和你的优势。 2.项目介绍...
第八章 教学评价 第一节 从考试文化走向评价文化 一、教学评价的早期发展 (一)传统考试阶段 ★《学记》——我国最...
今天青石的票圈出镜率最高的,莫过于张艺谋的新片终于定档了。 一张满溢着水墨风的海报一次次的出现在票圈里,也就是老谋...
青石电影阅读 9,047评论 1赞 3
今天主要学习了flex布局,学习笔记如下: 1.指定flex布局: display:flex(任意容器)...
插打法原为少林六合门打法,一代宗师万籁声将少林六合门、罗汉门、自然门等内外家之所长融为一家,自然门本无固定招式,然...
有人给现存的web自动化测试框架分类,第1类叫做 Selenium,第2类叫 Selenium less,间接说明了 Selenium 在 web 自动化测试的统治地位。
如果有项目需要引入web自动化测试,首选就是 Selenium ,因为它具备以下学习优势:
- API 非常成熟和稳定,几乎不需要为了适配新的版本修改旧代码;
- 教程和解决方案非常丰富,如果想学,可以看很多教程,代码出现问题,可以直接在网上收集解决方案。
而其他的自动化测试框架就不具备这个优势了。目前比较流行的 Cypress.io 和Playwright 都提供了详细的官方文档,入门会很简单,但是在实际的操作过程中,如果遇到了一些问题无法解决,在网上很难找到现成的解决方案,就算是一些比较基础的 API 调用,也很难找到使用的案例。
Selenium 除了学习优势,还具备的优势有:
- selenium 跨语言。主流的编程语言都有完善的 selenium 库支持,就算是新兴的 go 语言和 rust 语言,都有对应的库
- selenium 不仅可以用在web自动化测试里面,而且拓展到移动端的APP自动化测试;
- selenium 的 web driver作为W3C的一个标准,可扩展性能力很强。
- 生态庞大,不容易被轻易取代,有很多扩展工具可以使用。
selenium 有这么多优势?为什么还会有其他优秀的框架层出不穷呢?微软做了 playwright ,谷歌做了 pupeteer,由一个小团队做出来的 cypress 也大受欢迎。为了避免盲目追求新技术,使用新工具,我们有必要想清楚一个问题:一个优秀的 web 自动化测试框架,应该具备什么能力?
第一,它最好是跨语言的,至少应该支持主流的编程语言,才会有更多的人去推动社区发展,供更多人使用。 这一点,cypress 和 pupeteer 占劣势,cypress 只支持 JavaScript 语言,pupeteer 虽然支持其他语言,但是都不是官方维护的, playwright 具备多语言的官方维护。
第二,它应该是容易使用的。在外部暴露的API使用起来会比较简单,降低初学者的门槛。它的设计和原理要比较容易理解,这样的话,一些高级开发者能够快速的对其进行二次开发。 这一点 selenium 做得不错,不过缺乏高层次的 API 使用,而二次开发出来的上层框架使用起来差异较大,很难统一。其他三个框架的用法都很简单,只是要建立更庞大的社区还需要时间。
第三,安装越简单越好,降低使用门槛。selenium 做得不够好,需要独立去管理浏览器、webdriver 驱动、语言包等多个依赖条件,而 playwright 基本能做到一键安装,连浏览器都整合下载,非常方便。
第四,针对 web 自动化测试具备的脆弱性,需要加强的功能,比如说自动等待,代码追踪和调试工具,截图和录制功能。 这些 selenium 做得都不太好,所以像 playwright 和 cypress 在这方面都会提供非常多的惊喜。
第五,网络监听和控制。当网页请求需要 mock 或者需要进行服务虚拟化时,selenium 完全无法提供类似功能,而 playwright 这些工具做得很好。 这对于推进自动化测试流程已经提高测试效率方面是非常有用的。
第六,他最好是能够与编程语言已经具备的测试生态更好的协调起来,比如说 Selenium 能通过 python 中的 pytest 插件更方便的使用, playwright 也有 pytest 插件。
第七,易于集成。现在的 web 自动化测试,通常都会放到像 jenkins 这样的持续集成工具上管理和运行;同时,脚本通常也会采用 docker 等容器管理技术进行管理。
在这些能力当中,selenium 已经能做到绝大多数,但是在以下方面需要加强:
一、API比较底层,这就意味着经常你需要对其进行二次封装,市面上有很多很多基于 selenium 封装的框架,但是这些框架使用起来有很大差异,而且市场份额都不大,很难统一。
二、selenium 等待机制基本上需要手工实现,这很容易造成脆弱测试。有部分API使用起来会比较麻烦,甚至造成功能缺失。比如说文件上传和文件下载,处理起来会比较复杂。
三、selenium 几乎没有调试和跟踪机制,selenium IDE 也是独立的工具,很难和 webdriver 协调工作。这会造成当脆弱测试出现的时候,测试员很难去调试问题。
四、没有网络监控机制,只能控制页面行为,无法控制网络请求。
而这些短板都已经被 playwright 弥补, playwright 的 API 层次清晰,有高级的也有底层的,既可以使用高层次 API 快速使用,也可以基于底层 API 实现功能;等待几乎都是自动的、智能的,你不需要进行额外的处理;跟踪和调试、截屏和录制等功能一应俱全,能更快速的定位问题、也能方便的回溯测试过程;网络监控、网络请求的mock,请求的修改都可以做到。
也许实现 web 自动化测试的任务,用 selenium 就足够了。但是正因为 playwright 这样的后起之秀不断在打破规则,创建一些新的机制和用法,让我们做自动化测试有了更多选择,更快的效果,更完善的流程。
希望微软能持续投入这个项目,让它变得更好。
对 UI 自动化的见解
加权类别以查看分数
关于端到端测试的悲惨现实
根据调查结果并与去年相似,大多数公司没有将自动化的端到端测试作为其 CI 流程的一部分运行。目前,大多数公司都具有单元测试(是的!),但是很少有自动化的端到端测试。
调查的大多数公司( 284 家公司中有 85%)在发布过程中执行手动端到端测试。这使得发布软件的速度明显变慢并且更容易出错。在剩下的 15% 中,绝大多数运行 E2E 测试的用户使用 Selenium。
我相信其中很大一部分是因为从理论上讲,软件是一件好事,而实际上,软件是一团糟。
像大多数软件项目一样,大多数测试自动化项目都会失败。这令人沮丧,我们必须对此进行更改。幸运的是,这就是趋势,测试领域创新的爆炸式发展正在影响我们编写代码的方式。
自动化框架
让我们从基础开始。这篇文章中的自动化框架通过模拟诸如点击之类的用户操作来使您的浏览器自动化。
自动化框架执行点击和用户操作的主要方式有两种:
- 他们可以在页面上执行 JavaScript(在页面上调度事件)。
- 他们可以使用 devtools 协议(或非铬浏览器中的类似协议)以特权方式“本地”执行浏览器命令。
为了使长话短说,大多数框架,包括硒,用来采取第一种方法-但因为它是内在古怪和问题-他们搬到了第二种方法。
当您执行点击时,会发生很多事情。最终,原始的调试器单击最终将作为本机操作系统调用结束:
流行的自动化框架
我们被问到有四个流行的自动化框架,这些框架已被评估为基于 AI 的功能(如智能定位器)的基础架构。
我们将首先分别讨论它们,然后进行详细比较。我们将从 Selenium 开始-它是迄今为止最受欢迎的框架,也是最成熟的框架。
selenium
使用 HTTP REST JSON 协议发送称为“WebDriver 协议”的命令。WebDriver 是一个开放标准:
这意味着使用 Selenium 可以很容易地使用任何源语言和任何目标平台。Selenium 可以自动化大量浏览器,包括 Internet Explorer,移动浏览器,甚至移动应用程序(通过使用 Appium)。
由于 Selenium 是 REST JSON API,因此非常容易理解。创建会话只是向发送 POST请求/session。执行点击只是向/ session /:session-id /:element-id / click 发送 POST请求。
在引擎盖下–实际的自动化是由 ChromeDriver(在 Chrome 中)执行的,它只是一个 http 服务器。ChromeDriver 启动时,它会通过调试器连接到 Chrome。然后,当用户单击时,它控制调试器并执行“鼠标移动,鼠标向下,鼠标向上”的序列(使用调试器命令 Input.dispatchMouseEvent)。
WebDriver 也是一个开放标准,因此有很多网格选项和不同的方式来扩展 Selenium 以同时运行数百或数千个测试。
这意味着 selenium 避免了 JavaScript 基于事件的自动化的陷阱。因此,硒具有非常简单的架构:
使用 Selenium +语法
我将从安装官方驱动程序开始(有一些不错的替代品):
npm 安装 selenium-webdriver
创建驱动程序并使用它很容易-与其他方法相比,语法冗长,但仍然非常简单:
执行摘要
优点:
- 在所有浏览器上运行
- 许多司机和客户
- 使用调试器调度点击
- 很多网格选项
- 可以使用任何语言,例如 Java 或 Python,而不仅仅是 JavaScript
缺点:
- 还不是双向的,因为它是 Http 服务器。这意味着收集网络事件或控制台日志之类的事情非常困难
- 比其他选择更难建立自己
- 详细 API 与某些替代方案相比
- 最古老的选择。虽然代码不会生锈。
Cypress
赛普拉斯是一个 E2E 测试框架。它着重于尝试提供良好的开发人员体验和集成环境。赛普拉斯是开源的,但它不基于 WebDriver 等开放标准。
当我们评估赛普拉斯内部使用时–对于我们而言,有一些展示亮点。单击赛普拉斯的方式类似于 Selenium 1(Selenium WebDriver 的前身),并直接调度 DOM 事件。
另外,缺少多标签和框架的支持以及框架中没有等待的现象也给我们带来了问题。实际上,我们的赛普拉斯套件的稳定性要比其他三个替代套件差很多。
此外,作为赛普拉斯使用的开源库的维护者,我倾向于喜欢它们。但是像 2013 年的代码一样,赛普拉斯不允许您编写常规的 JavaScript。即使与官方的 Selenium 驱动程序相比,这也觉得 IMO 已过时了。
就是说,在评估赛普拉斯时,我们享受了出色的文档资料和简化的流程。
执行摘要–赛普拉斯
优点:
- 好的文档
- 友善社区
- Benji 参与其中的使用库❤️
缺点:
- 使用与 Selenium 1 不再使用的相同技术进行自动化
- 没有多标签支持
- 当我们评估它们时,具有多个框架的测试非常好用
- 浏览器支持非常有限
- 基于 jQuery 的 API 感觉已经过时了
- 为了做好并行性,您需要使用供应商锁定的软件。
Puppeteer
Puppeteer 是 Google 维护的一种流行的测试自动化工具。它可以自动执行 Chrome 和 Firefox。它相对简单且稳定。
从根本上讲,Puppeteer 是自动化工具,而不是测试工具。这意味着它在刮擦,生成 PDF 等用例中非常受欢迎。
Puppeteer 使用 Selenium(很好,ChromeDriver)使用相同的调试器协议来执行单击,实际上 Puppeteer(我们将在后面讨论的 Playwright)和 Selenium 都使用相同的代码来执行单击。实际上,Puppeteer 的体系结构如下所示:
因此,这只是对 devtools 协议(以及 Firefox 的等效工具)的一个非常简单而酷的包装。
Puppeteer 还负责为您下载 Chrome,并且在开发流程方面通常比 Selenium 更容易设置。
使用 Puppeteer +语法
npm 安装 puppeteer
然后语法非常简单,现代且不错:
如果需要,Puppeteer 还可让您直接访问 CDP。有时这很有用,总的来说,感觉到运动部件更少。
执行摘要– Puppeteer
优点:
- 设置简单
- 好的文档
- 自动以工作版本安装 Chrome
- 薄包装纸
- 双向(事件)–自动化控制台日志之类的事情很容易
- 由 Google 维护。
- 首先使用 JavaScript,因此代码很自然
缺点:
- 有限的跨浏览器支持-仅 Chrome 和 Firefox
- 感觉像自动化框架而不是测试框架,您通常不得不重新实现与测试相关的工具
- 生产中的网格(并发运行)通常是一个挑战
- 自动浏览器设置会下载 Chromium 而不是 Chrome,并且两者之间存在细微的差异。
Playwright
剧作家是新手。它由撰写 Puppeteer 的同一人撰写,并且由 Microsoft 维护。
Playwright 使用与 Puppeteer 相同的体系结构,并且是瘦 WebSocket 客户端。它使用非常相似的语法和语言,但有一些区别-即 Playwright 支持更多浏览器(Safari),并且 Playwright 感觉像是测试自动化工具,而不仅仅是自动化工具。
这意味着使用 Playwright 可以轻松完成某些事情,而使用 Puppeteer 则更困难:
- 通过文本而不是 CSS 选择器选择元素
- 使用 Shadow DOM
- 等待元素自动可用
- 可靠的网络验证和网络模拟。
Puppeteer可以实现所有这些功能,而 Playwright可以使这些感觉自然。Playwright 仍然感觉像是基础设施,但感觉像测试基础设施,而不是自动化基础设施。他们还在网格浏览器中的隔离会话上工作,我并不完全喜欢它,但是绝对很有趣。语法和安装与 Puppeteer 非常相似,因此无需再次复制/粘贴即可显示它。
执行摘要–剧作家
优点:
- 设置简单
- 测试框架稳定性功能。当我们在内部对 Playwright 和 Cypress 进行比较时,在稳定性方面 Playwright 始终优于 Cypress
- 自动以工作版本安装 Chrome,Firefox 或 WebKit(Safari)
- 薄包装纸
- 双向(事件)–自动化控制台日志之类的事情很容易
- 由具有维护 Puppeteer 经验的 Microsoft 人员维护
- 首先使用 JavaScript,因此代码很自然
缺点:
- 太新了,因此 API 也在不断发展
- 不支持 IE11 或非浏览器平台
- 仍然很少有集成和教程
- 网格仍然是一个挑战
- 文档和社区不如其他人。
关键差异
跨浏览器
- Selenium:✅ ✅ ✅ ✅ runs everywhere.
- Cypress:❌ (Only Chrome/Firefox)
- Puppeteer: ❌ (Only Chrome/Firefox)
- Playwright: ✅✅ (Chrome/Safari/Firefox)
多个标签和框架
- Selenium:✅✅ (Supported with bad switch API)
- Cypress:❌ (No real support)
- Puppeteer: ✅ ✅ ✅ ✅ (Intuitive API)
- Playwright: ✅ ✅ ✅ ✅ (Intuitive API)
测试创建速度
- Selenium:✅ Yes (with Testim Playground / Selenium IDE)
- Cypress:❌ (If you want us to add support for Cypress inthe playgroundplease let us know)
- Puppeteer: ✅ Yes (with Testim Playground)
- Playwright: ✅ Yes (with Testim Playground)
值得信赖的行动
此标准意味着由用户代理调度事件,这允许用户代理行为(如悬停)
- Selenium: ✅ Yes
- Cypress:❌ No support (can use Puppeteer plugin)
- Puppeteer: ✅ Yes
- Playwright: ✅ Yes
并行网格和基础架构
- Selenium: ✅ Yes (managed, costly) or build your own solution
- Cypress:🤷 Only in their closed source paid cloud or build your own
- Puppeteer: ❌ Usually people build their own (will change soon)
- Playwright: ❌ Usually people build their own (will change soon)
Performance(性能)
端到端测试在实践中非常快,但是人们对 Selenium 测试的执行速度存在误解。通常,是网站或 Web 应用程序运行缓慢,并且大多数情况下测试等待 Web 应用程序准备就绪
- Selenium:✅ It’s fast enough, really
- Cypress:✅ It’s fast enough, really
- Puppeteer: ✅ It’s fast enough, really
- Playwright: ✅ It’s fast enough, really
稳定性
这意味着编写测试后失败的频率,而不是检测到实际的应用程序错误时
- Selenium:❌✅Complex Automatic Wait For mechanism
- Cypress:❌✅Complex mechanism that doesn’t work with frames
- Puppeteer: ❌ ✅ Wait fors for certain things, but have to waitFor manually for others
- Playwright: ❌✅ ✅ Better wait fors for certain things, but have to waitFor manually for others
实际上,等待测试基础结构中的元素实际上取决于您的网站或应用程序的工作方式
智能定位器
- Selenium:❌No support for selecting elements in multiple ways
- Cypress:❌No support for selecting elements in multiple ways
- Puppeteer ❌No support for selecting elements in multiple ways
- Playwright: ❌✅✅ Very promising start of supporting custom selector engines.
自我修复测试和自动改进测试
- Selenium:❌ No
- Cypress:❌ No
- Puppeteer❌ No
- Playwright: ❌ No
调试
- Selenium:❌✅ A bit hard to figure out all the terminology. Debugging remote grids relies on the grid provider
- Cypress:❌✅ You’re not even writing regular JavaScript, you’re chaining promises. Makes up with DOMs
- Puppeteer: ✅ Writing and debugging JavaScript from your IDE
- Playwright: ✅ Writing and debugging JavaScript from your IDE
文档和资源
- Selenium: ✅✅ Very large community. Many testers.
- Cypress:✅✅ Small community but buzz – and very nice documentation.
- Puppeteer: ✅ Small community but lots of tutorials at this point
- Playwright: ✅❌ Docs and tutorials out of date due to changing API. Still feels a bit experimental.
自主测试
- Selenium: ❌No.
- Cypress:❌No.
- Puppeteer: ❌No.
- Playwright: ❌No.
如何选择?
请注意,这是评估测试基础结构的指南。无论选择什么,除非使用托管平台,否则都需要在测试基础结构上花费大量时间(毫不奇怪,就像其他任何软件开发项目一样)。
我们看到的测试自动化项目中最大的错误是人们没有计划。他们开始编写测试,然后在无法维护时放弃该项目。如我们前面所述,大多数测试自动化项目都会失败,并且大多数公司会执行手动质量检查。
如果您不想使用 JavaScript,则最好还是使用 Selenium。对于 Selenium 之外的所有框架,Java 和 Python 支持的社区和生态系统的规模要小得多。有些项目像 jpuppeteer 和 puppeteer-sharp,但它们是第三方的,比 Selenium 的官方替代方案小得多。
如果要使用 JavaScript,则可以混合使用 Selenium 和 Puppeteer或使用 Playwright。您目前无法将 Playwright 和 Selenium 混合在一起。
都是不错的选择。没有谁好,只有合适
请记住,编写成功的自动化项目不只是基础架构。像其他任何软件项目一样对待自动化。您不会编写无法维护的前端代码(有意地:),而不会编写无法维护的测试或代码。
自动化正在随着新事物爆炸。您可以而且可能应该参与其中!
这些工具都是开源的。参与进来,您可以帮助明年进行比较。自动化有很多折衷。测试自动化工具之所以彼此不同,是因为它们的开发时间,开发人员,制定的目标。没有一个万能的自动化框架,许多公司根据其应用和需求进行混合和匹配。
*文章为作者独立观点,不代表BOSS直聘立场。
本文系 BOSS直聘「有了」社区签约作者原创内容,未经账号授权,禁止随意转载。