功能测试自动化工具的王座出现了新的争夺：Cypress.io。赛普拉斯速度快吗？是的。赛普拉斯是交互式的吗？是的。赛普拉斯可靠吗？你打赌。最重要的是……这很酷！

但 Cypress 是Selenium WebDriver的替代品吗？Selenium，当前的 Web 自动化和测试框架之王，是否会因担心自己的地位而畏缩，或者它是否对所谓的篡夺者仁慈地微笑，因为它完全知道，好吧，它只是一个孩子！

Cypress 比 Selenium WebDriver 更好吗？我经常被问到这个问题。坦率地说，“这个与那个”文章的最简单途径是尝试找出哪个是“最好的”。但我不会走那条路。相反，我将尝试解释 Cypress 与 Selenium WebDriver 有何不同。

将 PostgreSQL 数据库与 ANF 无缝集成

想象一下无需支付任何许可费即可获得最高性能。加入我们即将举办的研讨会，了解Instaclustr 如何让您比以往更轻松地部署数据库等！

通过描述 Cypress 和 Selenium WebDriver 之间的区别，您将能够了解 Cypress 的工作原理。这篇文章还将尝试解释为什么Cypress 采取了 Web 浏览器自动化的道路，这条道路与 WebDriver 所采取的道路截然不同。

Cypress 与 Selenium WebDriver 有何相似之处？它们都控制和自动化 Web 浏览器，从而使您能够编写模拟用户操作的功能测试，并验证结果是否正确。但这就是相似之处结束的地方，也是差异开始的地方。希望了解这两种测试工具之间的差异以及造成这种差异的原因能够帮助您选择使用哪种工具以及何时使用。

让我们开始探索这些差异。

适用于前端开发人员！
Selenium WebDriver 专为 Web 应用程序的端到端回归测试而构建。Selenium 前端测试框架主要由 QA 开发人员使用，但开发人员并不多。这是因为前端开发人员测试自己的代码的想法并不常见。

但前端开发人员的世界正在开始发生一场小革命。前端开发人员开始编写自己的测试。是的，他们正在迎接敏捷软件方法的挑战。他们明白，如果不编写自己的测试，敏捷开发就不可能发生。他们正在编写单元测试，但也在编写集成，是的，还有使用真实浏览器检查其前端的端到端功能测试，就像 QA 开发人员编写的自动化测试一样。“左移”运动有很多这样的趋势。

前端开发人员对端到端测试的需求与 QA 开发人员的需求不同。前端开发人员不需要部署应用程序（前端、后端和数据库系统）的临时环境。他们只需在本地运行前端部分就可以了，并且可以轻松地模拟后端 。

这一事实——Cypress 的目标受众是前端开发人员——是 Cypress 和 WebDriver 之间所有差异的核心。它们是针对不同用户的不同工具。

仅限 JavaScript！
前端 Web 开发人员只使用一种语言编写——JavaScript。它是浏览器可以执行的唯一语言，因此它们别无选择。这种限制有其缺点和优点，但事实是存在的——前端开发人员只有一种语言（尽管有像TypeScript 这样的变体）。

而且，由于 Cypress 是为前端开发人员设计的，因此 Cypress 测试只能用 JavaScript 编写。不支持其他语言。与 Selenium WebDriver 相比，Selenium WebDriver 的 API 与多种语言绑定，包括 Java、C#、Python、Ruby、R、Dart、Objective-C，当然还有 JavaScript。

所以记住——如果你想做 Cypress 测试，你就必须学习 JavaScript。这很酷，因为今天的 JavaScript 不是你祖父母的 JavaScript。它是一种现代的、强大的、简洁的语言，如今被广泛使用，并拥有世界上最大的开源包存储库（http://stackoverflow.com/questions/1744777/），这个代码存储库在几年前超过了曾经最大的存储库，即存储库。

仅限摩卡！
Cypress 不仅限制您可以编写的语言，还限制您使用的测试框架。Mocha 是您用来编写测试的测试框架（测试框架在 JavaScript 中的作用类似于JUnit 在 Java 中的作用，或NUnit 在 C# 中的作用）。您无法在其他 JavaScript 框架（例如Jest 或Tape）中编写测试。

另一方面，Selenium WebDriver 不会将测试框架强加给您。此外，您甚至不必使用测试框架。您可以编写一个不是测试的常规程序，一个仅驱动浏览器的程序。许多项目都以这种方式使用 WebDriver，例如抓取网页和收集信息。

但Cypress很早就决定，它专门负责编写前端测试的任务，并且只能在测试框架内使用，而测试框架必须是Mocha。

cy.visit 将使浏览器导航到给定的 url。

cy.get 将返回对相关元素的引用，您可以在该元素上键入、单击或检查有关使用 contains 和其他断言的断言。

正如您所看到的，从表面上看，它与 Selenium Webdriver 惊人地相似，尽管更简单，而且功能更强大。

仅限 Chrome！
Cypress 测试运行程序仅适用于 Chrome。它不支持 Firefox、Safari、Edge 或 IE。这可能会让习惯了 WebDriver对所有这些浏览器的惊人支持的 QA 开发人员感到震惊。但是，是的，Cypress 只是 Chrome。有一个针对跨浏览器支持的问题，但该问题已经存在了近一年了。赛普拉斯的优先事项似乎在其他地方。

为什么前端开发人员只想在 Chrome 中运行测试？我相信这个问题有多种答案。首先，现在 Chrome、Firefox、Safari 和 Edge 之间的差异很小，而且对于大多数应用程序来说，差异越来越小。因此，在开发中进行测试时，仅在 Chrome 中进行检查可能就足够了。

其次，在所有浏览器上运行所有测试需要时间，正如我们上面所说，前端开发人员不想等待他们的测试。

第三，许多公司都有 QA 开发人员在所有浏览器上运行端到端测试，因此他们可以接受偶尔出现的非常罕见的错误并被 QA 团队发现。那些没有进行广泛的跨浏览器测试的公司呢？然后，他们就可以接受这些罕见的错误时不时地溜到用户手中。

第四，前端开发人员确实关心，并希望 Cypress 支持更多浏览器，但考虑到上述原因，这并不是他们的优先事项。

它在浏览器中运行！
除了前端开发人员习惯使用 JavaScript 之外，还有另一个更技术性的原因：仅支持 JavaScript。

您在 Cypress 测试脚本中编写的代码不会像在 WebDriver 中那样在浏览器外部运行。它运行浏览器。它正在执行您的测试代码。事实上，它正在执行您正在测试的应用程序代码的测试代码！

当您运行测试时，首先，Cypress 将准备您的代码以在浏览器中运行（从技术上讲，它将使用 webpack 将代码中的所有模块捆绑到一个 JS 文件中）。准备好后，它将运行 Chrome，并将您的测试代码注入到空白页面中。然后它将在浏览器中运行该测试代码。

该测试代码首先导航到应用程序页面（使用 `cy.navigate(' http://localhost:8080  ')`），该页面在 . Cypress 将使 iframe 导航到该页面，但您的代码正在浏览器中运行，并且（有点神奇地）可以访问与该 iframe 相同的内容，因此所有命令（例如“单击”或“类型”）都发生在内部浏览器，使用常规 .

为了进行比较，让我们回顾一下 Selenium WebDriver 架构以及这对于 Selenium 测试的运行方式意味着什么。看一下下图。

使用 Selenium WebDriver，您有三个流程：

硒网络驱动程序
浏览器驱动程序，例如ChromeDriver、GeckoDriver（适用于 Firefox）、EdgeDriver、SafariDriver等。
浏览器本身
这些进程之间的所有通信意味着 Selenium 测试需要很长时间才能运行。这将我们引向下一点：

它很快！
这种浏览器内执行是基于赛普拉斯测试的速度。使用 Cypress，您只有一个进程：浏览器本身。使用 Cypress，您的测试代码与应用程序代码一起运行。

因此，自动化命令（例如，单击按钮）不会像 WebDriver 那样通过进程外通信将命令发送到浏览器。相反，Cypress 使用DOM 事件向按钮发送单击命令。快得多。

虽然 WebDriver 的进程外自动化涉及异步通信，但 Cypress 的自动化命令大多是同步的且位于内存中。这会产生极快的测试。

我相信正是这种速度才是前端开发者迷恋Cypress的主要原因。WebDriver，至少在感知方面，没有给他们提供他们需要的速度。前端开发人员希望一直运行他们的测试，并且无法承受需要运行数十分钟的套件的奢侈。他们想要运行他们的套件，并且需要它在一两分钟内运行，而不是更长时间。

这种速度差异真的像赛普拉斯文档声称的那样很大吗？从我公认的小实验来看，是的，但我不相信这种差异值得 WebDriver 所具有的其他好处。亲自尝试一下小样本测试，然后亲自看看！

它有内置的服务器模拟！
但赛普拉斯被认为更快还有另一个原因。让我们提醒自己，Cypress 是为前端开发人员设计的。我们还要提醒自己，前端开发人员有时不使用真正的后端，而是模拟发送到服务器的XML HttpRequest 。无论您使用的是 Cypress 还是 Selenium WebDriver，这都可以实现极快的测试，只需几秒。

Cypress 明白这一点，并且拥有用于模拟服务器响应的内置设施，这些设施对于其目标受众（前端开发人员）至关重要。Selenium WebDriver 没有这方面的设施，为了模拟服务器响应，WebDriver 测试需要运行一个返回正确响应的模拟服务器。虽然可能，但它是一种较慢且不太方便的选择：用于模拟的快速且内存中的设施总是优于缓慢的进程外设施。

这不仅仅是执行速度。就编写测试的速度而言，模拟服务器的内置工具的便利性怎么强调都不为过。事实上，每个测试都明确地描述了模拟响应，这比模拟相同响应的单独服务器程序更容易编码（和理解！）。