你不知道的Cypress系列（13） -- 你真的需要多浏览器测试吗？

今天是你不知道的Cypress系列（13） -- 你真的需要多浏览器测试吗？

在自动化测试过程中，特别是Web端UI自动化测试过程中，发现很多同学对多浏览器测试/跨浏览器测试有很多误区， 今天来尝试解答下。

多浏览器测试 VS 跨浏览器测试

自动化测试过程中，很少同学会去区分这两个概念，常将它们混为一谈。实际上，它们还是有些区别：

1. 多浏览器测试是指在自动化测试的一次执行过程中，使用多个浏览器进行测试。这里有两个重点：
   1. 一次运行过程中
   2. 多个浏览器在同时/顺时执行测试用例
2. 跨浏览器测试是指自动化测试支持在不同的浏览器上执行测试。这里也有两个重点：
   1. 支持自动化测试运行在不同浏览器上
   2. 在一次运行过程中，没有要求必须同时在不同浏览器上运行测试

从业界大部分UI自动化测试框架来看，跨浏览器测试，基本上是任何一个自动化测试框架都支持的，不同点仅在支持程度即支持的浏览器种类的数量上。

跨浏览器测试的场景

跨浏览器测试的场景很常见，比如：

1. 业务需求。 刚需。例如，产品描述写明支持在不同浏览器上执行。
2. 不同浏览器使用同一内核。 例如Chrome家族的Chromium内核。Chrome，包括一众国产浏览器，其实都是同一个内核。理论上同一产品在使用同一内核的浏览器上的表现应该相同。

在实际测试中，测试人员常常需要根据产品需求进行测试，这就意味着，同一个测试用例在不同测试浏览器上执行是必须的。

多浏览器测试的场景

多浏览器测试的场景不太常见，这里说一个典型场景：

• 我的产品是Web端聊天室。为了达成测试目标（模拟用户聊天），我不得不在同一次测试中，驱动两个浏览器示例代表两个不同的用户进行操作。

跨浏览器测试、多浏览器测试解决方案

如果是分布式运行，则无论是跨浏览器测试，还是多浏览器测试，解决方案都很简单， 核心原理都一样：

将测试分发到不同的虚拟机/Docker下执行。
同一个虚拟机/Docker上仅有一个浏览器类型。

在实现上，最常见的有Selenium/WebDriver里的Selenium Grid，以及Cypress中的DashBoard。 大多数技术实力还OK的公司，基本都会自己实现一套并发运行方案，在此不再赘述。

但如果在本地运行，则看起来Selenium/WebDriver的这一套方案更加流行，况且Cypress自己声明不支持多浏览器测试。这让很多初次拥抱Cypress技术的同学很受伤，认为Cypress还是不成熟。

果真如此么？

多浏览器测试真的是必须的么？

往前10年，Web端自动化基本上是Selenium/WebDriver的天下。这也造成了很多同学有了思维定势， 其中最经典的一条就是：

UI自动化测试一定要完全模拟用户行为

从这个道理讲，如果我要测试一个Web端聊天室，可不就是需要至少2个浏览器同时运行么？

同时，UI自动化测试一定要完全模拟用户行为这条伪军规也变成个别公司摒弃UI自动化测试的最大理由，因为投入产出比实在是不高啊！况且，如果要完全模拟用户行为，从自动化测试角度来说，意味着对页面元素的各种操作。但是由于UI频繁变化是常规操作，这就导致自动化测试每天发现很多错误，调查下来发现都是UI自动化测试脚本引起的错误，真正的Bug反而追踪不到（Flaky Test迷雾）。

可是，可是啊，谁告诉你UI自动化测试一定要全部走UI的啊！！！

剖析多浏览器测试

在没有Cypress之前，市面上绝大多数测试框架都是基于Selenium/WebDriver的（底层都是JSON Payloads Protocol），这意味着，所有针对浏览器的操作全部是在浏览器之外执行的。所以当涉及到模拟用户操作时，只能是从UI层面一步步点击。

大家都知道，Cypress的运行原理跟Selenium/WebDriver是不同的（哪里不同，请参考鄙人《前端自动化测试框架 -- Cypress从入门到精通》一书。

这种不同，也让Cypress对多浏览器测试这一伪需求，毫不犹豫的进行了鄙视：

Cypress will also never support driving more than 1 browser at a time. 
It is possible .... Yet completely unnecessaryill also never support driving more than 1 browser at a time.

我就不翻译了，大家有兴趣可以找找官网看。

那么，如果说多浏览器测试是伪需求，正确的姿势应该是如何呢？

stub or programatically control the other user without needing an entire browser stub or programatically control the other user without needing an entire browser

简而言之啊，就是，使用stub。

降维解决多浏览器测试

Stub是什么？Cypress说Stub有如下功效：

Replace a function, record its usage and control its behavior.

加上Cypress是完全运行在浏览器之内的，跟你的应用程序共享同一个生命周期，这就以为着。浏览器里发生的一切，它都可以捕捉并且改变，于是，我们可以用Stub来达成这个操作。具体怎么执行呢？ 公众号回复你的微信号，拉你到Cypress中国群。

实际上，只有掌握了Stub命令，配合上cy.spy()以及Cypress.on()， 你才能真正理解Cypress官网的第一句话到底能在前端测试界掀起多大风和浪：

 The web has evolved.
 Finally, testing has too.

跨览器测试举例

我们回到跨浏览器测试中来， 假设你使用《前端自动化测试框架 -- Cypress从入门到精通》一书的框架，那么，当你需要你的测试运行在不同的浏览器时候，你仅仅需要在mergeReport.js下，更改下浏览器名称即可，

  const { totalFailed } = await cypress.run({
    spec: `${specFileList}`,
    //改这里
    browser: 'chrome',
    headless: true,
    reporter: 'mochawesome',
    reporterOptions: {
      reportDir: `${sourceReport.reportDir}`,
      overwrite: false,
      html: true,
      json: true,
    },
  })

当然，你也可以将之参数化，然后从命令行传入进来。

那么，对于没有使用笔者给定框架的同学，如何在命令行执行中指定浏览器呢？在启动Cypress命令行时，直接指定浏览器即可。

//执行运行在chrome浏览器上
yarn cypress run --browser chrome
})

如果你想要你的某些测试用例，仅仅在某个浏览器下才运行，又该如何做呢？

it('关注iTesting，跟万人测试团一起成长', { browser: 'chrome' }, () => {
  cy.visit("https://www.helloqa.com")
  //你的其它代码
})

很简单，你只要在it中添加你希望运行在哪个浏览器上即可。注意，如果你的本次测试不是用Chrome执行的，那么这条用例就不会执行。

往期回看：

你不知道的Cypress系列（1） --鸡肋的BDD

你不知道的Cypress系列（2） -- ”该死"的PO模型！

你不知道的Cypress系列（3） -- 是时候重构自己的思维了！

你不知道的Cypress系列（4） -- “PO”已死，App Action当立？

你不知道的Cypress系列（5） -- "眼瞎"的TestRunner

你不知道的Cypress系列（6） -- 多Tab的小秘密

你不知道的Cypress系列（7） -- 当iFrame遇见弹出框

你不知道的Cypress系列（8） -- “可视化”测试你知多少

你不知道的Cypress系列（9） -- 代码“自动生成”术

你不知道的Cypress系列（10） -- CypressHelper

你不知道的Cypress系列（11） -- 使用cy.session()加速鉴权。

你不知道的Cypress系列（12） -- 测试报告Allure