终于有人拿来比较这几种了 Playwright 基于Puppeteer,但又向Selenium取了经,它能使用熟悉的npm语法快速轻松地安装,并使用JavaScript来构建网络应用程序自动化和测试。它可与更多浏览器一起使用,并支持Edge等基于Chromium的浏览器,以及Firefox和Apple的WebKit。但它也有它的劣势,用的人暂时不是很多,生态还不是很完整。不过从微软的投入上来看,Playwright还是很有发展前途的。 image.png Playwright VS Selenium 的区别 Context支持 Playwright有一个非常重要的功能,是它对浏览器Context的支持。它能够在单个浏览器实例中运行隔离的操作,因此您可以设置多个Context以同时测试多个Web页面。在每个Context中创建页面。页面支持它们自己的单击交互,并且可以并行监视。进入页面后,可以使用CSS或XPath选择器,HTML属性或文本,以不同的方式查找与之交互的内容。如果您熟悉Selenium,则应该浏览熟悉的页面,并具有等待页面完全加载或在单页面Web应用程序中呈现动态内容的附加功能。 推荐阅读更多精彩内容
有人给现存的web自动化测试框架分类,第1类叫做 Selenium,第2类叫 Selenium less,间接说明了 Selenium 在 web 自动化测试的统治地位。 如果有项目需要引入web自动化测试,首选就是 Selenium ,因为它具备以下学习优势:
而其他的自动化测试框架就不具备这个优势了。目前比较流行的 Cypress.io 和Playwright 都提供了详细的官方文档,入门会很简单,但是在实际的操作过程中,如果遇到了一些问题无法解决,在网上很难找到现成的解决方案,就算是一些比较基础的 API 调用,也很难找到使用的案例。 Selenium 除了学习优势,还具备的优势有:
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。 我相信其中很大一部分是因为从理论上讲,软件是一件好事,而实际上,软件是一团糟。 像大多数软件项目一样,大多数测试自动化项目都会失败。这令人沮丧,我们必须对此进行更改。幸运的是,这就是趋势,测试领域创新的爆炸式发展正在影响我们编写代码的方式。 自动化框架让我们从基础开始。这篇文章中的自动化框架通过模拟诸如点击之类的用户操作来使您的浏览器自动化。 自动化框架执行点击和用户操作的主要方式有两种:
为了使长话短说,大多数框架,包括硒,用来采取第一种方法-但因为它是内在古怪和问题-他们搬到了第二种方法。 当您执行点击时,会发生很多事情。最终,原始的调试器单击最终将作为本机操作系统调用结束: 流行的自动化框架我们被问到有四个流行的自动化框架,这些框架已被评估为基于 AI 的功能(如智能定位器)的基础架构。 我们将首先分别讨论它们,然后进行详细比较。我们将从 Selenium 开始-它是迄今为止最受欢迎的框架,也是最成熟的框架。 selenium 使用 HTTP REST JSON 协议发送称为“WebDriver 协议”的命令。WebDriver 是一个开放标准: 这意味着使用 Selenium 可以很容易地使用任何源语言和任何目标平台。Selenium 可以自动化大量浏览器,包括 Internet Explorer,移动浏览器,甚至移动应用程序(通过使用 Appium)。 由于 Selenium 是 REST JSON API,因此非常容易理解。创建会话只是向发送 POST请求 在引擎盖下–实际的自动化是由 ChromeDriver(在 Chrome 中)执行的,它只是一个 http 服务器。ChromeDriver 启动时,它会通过调试器连接到 Chrome。然后,当用户单击时,它控制调试器并执行“鼠标移动,鼠标向下,鼠标向上”的序列(使用调试器命令 Input.dispatchMouseEvent)。 WebDriver 也是一个开放标准,因此有很多网格选项和不同的方式来扩展 Selenium 以同时运行数百或数千个测试。 这意味着 selenium 避免了 JavaScript 基于事件的自动化的陷阱。因此,硒具有非常简单的架构: 使用 Selenium +语法我将从安装官方驱动程序开始(有一些不错的替代品): npm 安装 selenium-webdriver 创建驱动程序并使用它很容易-与其他方法相比,语法冗长,但仍然非常简单: 执行摘要优点:
缺点:
Cypress赛普拉斯是一个 E2E 测试框架。它着重于尝试提供良好的开发人员体验和集成环境。赛普拉斯是开源的,但它不基于 WebDriver 等开放标准。 当我们评估赛普拉斯内部使用时–对于我们而言,有一些展示亮点。单击赛普拉斯的方式类似于 Selenium 1(Selenium WebDriver 的前身),并直接调度 DOM 事件。 另外,缺少多标签和框架的支持以及框架中没有等待的现象也给我们带来了问题。实际上,我们的赛普拉斯套件的稳定性要比其他三个替代套件差很多。 此外,作为赛普拉斯使用的开源库的维护者,我倾向于喜欢它们。但是像 2013 年的代码一样,赛普拉斯不允许您编写常规的 JavaScript。即使与官方的 Selenium 驱动程序相比,这也觉得 IMO 已过时了。 就是说,在评估赛普拉斯时,我们享受了出色的文档资料和简化的流程。 执行摘要–赛普拉斯优点:
缺点:
PuppeteerPuppeteer 是 Google 维护的一种流行的测试自动化工具。它可以自动执行 Chrome 和 Firefox。它相对简单且稳定。 从根本上讲,Puppeteer 是自动化工具,而不是测试工具。这意味着它在刮擦,生成 PDF 等用例中非常受欢迎。 Puppeteer 使用 Selenium(很好,ChromeDriver)使用相同的调试器协议来执行单击,实际上 Puppeteer(我们将在后面讨论的 Playwright)和 Selenium 都使用相同的代码来执行单击。实际上,Puppeteer 的体系结构如下所示: 因此,这只是对 devtools 协议(以及 Firefox 的等效工具)的一个非常简单而酷的包装。 Puppeteer 还负责为您下载 Chrome,并且在开发流程方面通常比 Selenium 更容易设置。 使用 Puppeteer +语法npm 安装 puppeteer 然后语法非常简单,现代且不错: 如果需要,Puppeteer 还可让您直接访问 CDP。有时这很有用,总的来说,感觉到运动部件更少。 执行摘要– Puppeteer优点:
缺点:
Playwright剧作家是新手。它由撰写 Puppeteer 的同一人撰写,并且由 Microsoft 维护。 Playwright 使用与 Puppeteer 相同的体系结构,并且是瘦 WebSocket 客户端。它使用非常相似的语法和语言,但有一些区别-即 Playwright 支持更多浏览器(Safari),并且 Playwright 感觉像是测试自动化工具,而不仅仅是自动化工具。 这意味着使用 Playwright 可以轻松完成某些事情,而使用 Puppeteer 则更困难:
Puppeteer可以实现所有这些功能,而 Playwright可以使这些感觉自然。Playwright 仍然感觉像是基础设施,但感觉像测试基础设施,而不是自动化基础设施。他们还在网格浏览器中的隔离会话上工作,我并不完全喜欢它,但是绝对很有趣。语法和安装与 Puppeteer 非常相似,因此无需再次复制/粘贴即可显示它。 执行摘要–剧作家优点:
缺点:
关键差异跨浏览器
多个标签和框架
测试创建速度
值得信赖的行动此标准意味着由用户代理调度事件,这允许用户代理行为(如悬停)
并行网格和基础架构
Performance(性能)端到端测试在实践中非常快,但是人们对 Selenium 测试的执行速度存在误解。通常,是网站或 Web 应用程序运行缓慢,并且大多数情况下测试等待 Web 应用程序准备就绪
稳定性这意味着编写测试后失败的频率,而不是检测到实际的应用程序错误时
实际上,等待测试基础结构中的元素实际上取决于您的网站或应用程序的工作方式 智能定位器
自我修复测试和自动改进测试
调试
文档和资源
自主测试
如何选择?请注意,这是评估测试基础结构的指南。无论选择什么,除非使用托管平台,否则都需要在测试基础结构上花费大量时间(毫不奇怪,就像其他任何软件开发项目一样)。 我们看到的测试自动化项目中最大的错误是人们没有计划。他们开始编写测试,然后在无法维护时放弃该项目。如我们前面所述,大多数测试自动化项目都会失败,并且大多数公司会执行手动质量检查。 如果您不想使用 JavaScript,则最好还是使用 Selenium。对于 Selenium 之外的所有框架,Java 和 Python 支持的社区和生态系统的规模要小得多。有些项目像 jpuppeteer 和 puppeteer-sharp,但它们是第三方的,比 Selenium 的官方替代方案小得多。 如果要使用 JavaScript,则可以混合使用 Selenium 和 Puppeteer或使用 Playwright。您目前无法将 Playwright 和 Selenium 混合在一起。 都是不错的选择。没有谁好,只有合适 请记住,编写成功的自动化项目不只是基础架构。像其他任何软件项目一样对待自动化。您不会编写无法维护的前端代码(有意地:),而不会编写无法维护的测试或代码。 自动化正在随着新事物爆炸。您可以而且可能应该参与其中! 这些工具都是开源的。参与进来,您可以帮助明年进行比较。自动化有很多折衷。测试自动化工具之所以彼此不同,是因为它们的开发时间,开发人员,制定的目标。没有一个万能的自动化框架,许多公司根据其应用和需求进行混合和匹配。 *文章为作者独立观点,不代表BOSS直聘立场。 |