从入门到不放弃：多浏览器的自动化测试（1）- 本地测试

朴灿烈づ我的快乐病毒、 2022-06-07 13:53 305阅读 0赞

本文将作为多浏览器自动化测试的第一篇文章，给读者从头介绍如何进行本地多浏览的自动化测试工作，包括测试的原理、测试框架的选取、测试工程的搭建和实现等。另外“从入门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项目自动化构建等案例，欢迎大家关注本系列的其他文章。

前端之殇

要是你碰到前端工程师朋友，那聊聊浏览器的兼容性准是没错，这和碰到英国朋友就谈天气是一个道理。大部分程序员朋友们一定会捶胸顿足，连连诉苦，不过如果对方一时语塞，或者欲言又止，请拍拍他 / 她肩膀说：

“没事，过两年出了新浏览器又是一条好汉。”

在前端界，浏览器兼容性是让工程师们头疼的问题，对于经验丰富的人来说，很清楚浏览器有哪些坑，但是对于大部分程序员，最可怕的是代码明明在这个浏览器运行得很好，但是到了另一个浏览器中就不能正常运行了。对于这部分的程序员，保障代码能正常运行的方法便是能尽早发现问题，然后将其解决。

![Center][]

通常情况下，发现兼容性问题的方法莫过于将程序在各个浏览器中执行一遍，但这是极其浪费人力和时间的，最省力的方法也需要在每次版本的更迭时重复一遍测试工作。对于不同的兼容性要求，测试需要的时间各不相同，若是只支持最新版本的浏览器，那么便测试 3、4 个浏览器即可，但是对于兼容性要求高的程序，有可能要测试 10 个浏览器以上。

对于中小型公司来说，如果没有专职的测试人员，这样的测试耗时是致命的。若进行严格测试，则会拖慢项目进度，倘若敷衍了事，那程序的质量便没法保证。

本文将作为多浏览器自动化测试的第一篇文章，将以项目 A 作为例子，给读者从头介绍如何进行本地多浏览的自动化测试工作，包括测试的原理、测试框架的选取、测试工程的搭建和实现等。在下一篇文章中将介绍如何使用云服务实现更多浏览器的测试工作。另外“从入门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项目自动化构建等案例，欢迎大家关注本系列的其他文章。

小窥测试

测试是一个庞大的主题，包括各种分类的测试，诸如黑盒测试/白盒测试、单元测试 / 集成测试 / 端到端测试等。通常程序员在测试自己的代码的时候用得最多的便是单元测试，但是因为测试也是需要代价，很多人是不喜欢写测试的，甚至是一点都不写。当然今天我们不是要讨伐诸位，而是希望读者能从文中受益，从一个测试小白可以自己动手搭建自己的测试工程。

在多浏览器的自动化测试，我们多半是进行端到端的测试工作，一小部分是大粒度的单元测试。端到端测试测试模拟用户的行为。在 Web 应用程序中，他们会启动服务器，打开浏览器，模拟用户的行为进行点击、输入、提交等动作，断言浏览器中发生了特定的事情或者是得到了期待的结果，从而让我们相信功能可以正常的运行。而单元测试根据代码单元的公共 API 运行它们。这些测试需要创建一个类的实例，使用特定的输入调用它的方法，断言被调用的方法达到了预期的效果。

在下文中我们会看到这两种测试的实践，当然有时候区分度并不大，可能无法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的目标是保证功能可以正常运行就足够了。

在浏览器的测试中，Selenium 可谓是最重要的工具之一。简单来说 Selenium的作用是 "Automate Browsers"——让浏览器可以自动化起来的工具。它提供了统一的接口，让用户可以使用不同的编程语言，调用其接口来模拟用户的操作，例如点击，移动等操作。基本上一切人工操作的行为都可以通过 Selenium 的 API 进行触发操作。我们将 Selenium 看作是人手的代理，帮程序员完成一切用手干的活。

测试的技术方案选择

在进行项目实践前，很重要的一项工作是选择合适的技术栈。好比在前端开发时应该选择 React，Vue 还是 Angular 作为框架一样，前端的测试工作也需要选择一套技术栈。

很多时候大家在制定技术栈时容易走偏，在选择技术框架时不是选择最合适的框架，而是选择最热门的框架。当然一定程度上热门的框架能反应其受欢迎程度，可能是因为其出众的优点，如较高的开发效率、高效的渲染特性或者是活跃的社区。在前端开发中，很容易有这样的感受，就是只要半个月没有关注业界的最新动态，就感觉恍若隔世，新的解决方案层出不穷，让人喘不过气。

就作者本人经验来说，已经过了慌乱的年纪，再也不会盲目地追寻新技术，而转向关注技术背后解决的痛点，就好像 2C 创业者们嘴上老说的用户痛点一样。

![Center 1][]

在介绍本文涉及项目的技术栈之前，需要提醒诸位，此处的技术选择并不一定完全适用于诸位的项目，请各位三思而测。目前市场上有众多的测试框架，测试断言库甚至是全套的测试解决方案。Karma、Jasmine 和 Mocha 是大家熟知的测试框架，而 chai, should.js 是流行的断言库，另外在不同的技术社区还有自成一套的测试技术，比如 React 社区中的 Jest 和 Enzyme 都是受开发者喜爱的测试框架和库，最近一些新的并行测试解决方案也日渐流行，如 AVA 、Intern 。本文中的实践来自于项目 A，在项目测试前期我们分析了测试需求，我们希望整个测试方案能满足一下要求：

*  支持端到端测试
 *  对接云测试服务方便
 *  本地测试和云测试切换方便
 *  提供封装的浏览器操作接口
 *  测试用例可以快速迁移到其他框架下执行

考量了以上的需求，我们认为 NightWatch.js 是一款非常合适的测试解决方案。当然其他的测试框架也基本能满足需求，但是从方便易用性上考虑，我们最后采用了 NightWatch.js，该方案不仅提供简易封装的浏览器代理操作 API， 还给我们提供了方便便捷的云测试配置(下一篇文章将着重介绍此内容)，就凭这两点就已经非常吸引我们了。对于前端测试新手，强烈推荐试用此框架，让你可以迅速完成曾经畏而却步的测试工作。

项目实践

项目 A 的本地测试实践是需要分别在两台电脑上的多浏览器中执行测试，两台电脑分别是 Windows 系统和 Mac 系统，包括了 IE 、Firefox(windows / mac)、Chrome(windows / mac)、Safari 等最新的主流浏览器。两台机子的测试是分别执行的，我们通过 Jenkins 分别定期执行机子上的测试任务，将测试结果通过邮件的方式反馈给开发人员。 Jenkins 是一个持续集成的平台，关于如果使用 Jenkins 请各位自己 Google。

在接下来的文章中，我们将只介绍在一台机子上的工程实践，对于多个机子的测试需要将如下的工程部署到不同的机子，再使用诸如 Jenkins 之类的工具进行定期执行就可以。

开始工作前，我们需要将技术关系了然于心。我们在 Nightwatch 框架下使用 Selenium 中的 driver对浏览器进行操作。不同的浏览器有不同的 Driver，整个技术栈图如图1所示：

![Center 2][]

在图中 Test Runner 即为 Nightwatch，我们使用 Nightwatch 提供封装过的 API 进行 Test Case 的书写。下面我们将从零开始手把手教你如何使用 Nightwatch 启动你的第一个 Test case。

安装测试所需包

在自己的前端项目中安装 Nightwatch.js，并将其保存在 package.json的 devDependencies 中。

\`\`\`

npm install nightwatch --save-dev

\`\`\`

增加 npm script 入口

在 npm scripts 中加入 test 指令入口，该条指令的具体工作是使用 test.conf.js 的配置，执行名为 'A' 、'B' 、'C' 的配置项(若为了直观查看测试的内容，可根据项目的测试浏览器和版本将名字设为 chrome52.0, safari9.0 这样的名字，此处设为 A , B , C 是避免大家误认为是指令是自动根据名字去寻找匹配的浏览器）。更多命令的详解请参照 Nightwatch 文档。

\`\`\`

"scripts": \{

...

"test": "./node\_modules/.bin/nightwatch -c conf/test.conf.js -e A,B"

...

\`\`\`

配置 Nightwatch

完成指令入口的配置工作，接下来需要完成 test.conf.js 的配置工作。在本地测试中，我们使用 Selenium 对浏览器进行代理操作。配置使用本地 Selenium 操作本机浏览器 Nightwatch 有三个重点：

*  Selenium 的配置：配置好 Selenium jar 包的路径，该包从 Selenium 的官网上下载，host 和 port 按照下文配置书写。
 *  driver 的配置：cli\_args 是 Selenium 参数，在这我们指定了 chromedriver 和 geckodriver 的路径，chromedriver 是用来操作 chrome，geckodriver 用来操作 safari 和 firefox（顾名思义，geckodriver 支持基于 gecko 的浏览器），都可以从网上进行下载。在项目A中，我们将其下载到前端下面的 bin 目录下。
 *  测试目标浏览器的配置：也就是A和B，每一个 Object 都是一个配置项，A是测试Chrome浏览器，B是测试 Safari 浏览器，如果没有指定版本，就使用本地最新版，更多的配置可以参考 Nightwatch 文档，可以指定系统、版本，并可以启动、禁用浏览器的某些特性，如 Cookie。

\`\`\`

...

selenium : \{

"start\_process" : true,

"server\_path":"./bin/selenium-server-standalone-3.4.0.jar",

"host" : "127.0.0.1",

"port" : 4444,

"cli\_args": \{

"webdriver.chrome.driver": "bin/chromedriver",

"webdriver.gecko.driver" : "bin/geckodriver"

\},

...

test\_settings: \{

A: \{

desiredCapabilities: \{

'browserName': 'chrome'

\},

B: \{

desiredCapabilities: \{

'browserName': 'safari'

\`\`\`

诸位需要根据自己机子的实际情况进行配置，如果是Windows系统，那么将没有safari浏览器，而使用 IE 浏览器，这样则会需要 IE 浏览器对应的 driver。

书写测试用例

在各项准备工作完毕后，就只差测试用例了，下面是项目 A 的一个测试用例的片段，用于检测页面上 id 为 testid 的 DOM 中的内容字符，我们期待字符的长度为 32， 如果该字符为 32 个字符，那么测试通过，否则测试失败。

需要注意的是因为此 DOM 是动态插入的，所以在判断其字符前，我们使用 waitForElementVisible 来检查浏览器中 testid 的 DOM 是否已经显示，若在5秒内显示则进行下面的工作，如果没有显示，那么测试也会失败。

\`\`\`

module.exports = \{

'@tags': \['unit'\],

'unit testing' : function (browser) \{

browser.url(\`http://localhost:3010/test\`)

.waitForElementVisible('\#testid', 5000)

.getText("\#testid",function(result)\{

this.assert.equal(result.value.length,32);

\});

browser.end();

\};

\`\`\`

5. 运行测试

到此为止，我们简单的测试工程已经搭建完毕。现在我们回过头去，执行我们最开始配置的 test 指令，启动测试任务。你需要在命令中执行：

\`\`\`

npm test

\`\`\`

如果顺利的话，此时你会看到浏览器自动地打开关闭，很快就能从终端上看到如下的测试结果,图 2 展示的是多个测试用例成功的结果，图 3 展示的是测试失败的结果（如遇到无法测试或者其它异常情况请 Google。：D)。

![Center 3][]

![Center 4][]

从测试结果中可以查看测试用例的测试结果，包括测试的浏览器、未通过测试的信息详情等。至此，一个从零开始的本地测试实践教程结束。

本地测试与云测试

因为本地浏览器的类型有限，一般我们更多地使用本地的多浏览器测试来完成功能验证的工作，对于要求更严的兼容性测试，我们将采用云测试的方式。云测试即云服务提供商将向我们提供更多的云主机，每台主机上运行着不同版本的浏览器。通过使用云测试服务，我们就能将测试覆盖到更多类型、版本的浏览器。

在下一篇文章中，我们仍以项目 A 为例子，使用 Nightwatch 框架，在此文章的基础上介绍云测试和云测试工程的搭建。

> 潘潘，岂安科技软件工程师  
> 
> 
>   
> 
> 
> 同济大学毕业，曾在VMware等多家知名公司实习，3年全栈开发经验，负责岂安科技核心产品初期的前端开发和架构工作。
> 
>   
>

[Center]: /images/20220607/7d50b281f9034c7e817bfe7c0fe9d356.png
[Center 1]: /images/20220607/139f464a99684a38ad9529c26baf0f5b.png
[Center 2]: /images/20220607/d4b49850bdd643ddb42edf4e8d215b39.png
[Center 3]: /images/20220607/3d485842321a4250a4552d5b3d5d5d6b.png
[Center 4]: /images/20220607/8829d032daaf4aecb608441a3d3640ad.png