如何进行前端自动化测试？

没人邀请，路过回答。

前端测试是前端工程方面的重要分支，有过一些探索，这里简单分享一下。

首先，还是要强调一点：

前端是一种特殊的GUI软件

看过我最近一年内做前端工程方面相关分享的人可能有印象，我总是在强调这一点。前端测试也跟这个理论基础有所关联。

在这里，我还想吐槽一下：

API测试方法论在测试GUI时并不能解决所有问题。

与很多前端工程师讨论过前端测试，大家更多的还是盯着API测试方法论。诚然，前端有那么一小部分代码是可以用API测试保证质量的，但前端项目中的绝大多数代码是GUI界面，前端测试应该向传统GUI测试方法论需求解决方案：

，这个百科词条介绍的很不错，大家可以感受一下GUI测试相关概念和方法。它的测试用例、覆盖率统计、测试方法等等都与API测试有着很大的不同。

统一了这个认知之后，我们来讨论一下前端GUI测试的特殊性。根据百科词条上的那些介绍，相信大家都能感觉到GUI测试的成本非常高，而前端这种特殊的GUI软件，具有天生的快速迭代特征，这使得case维护成本也变得非常高，经常跟不上迭代速度。

一个标准的互联网应用产品的前端部分，我粗略估计大概有20%的业务基础代码比较稳定，比如通用组件、通用算法和数据模块等，可以针对这些建立复杂一些的API和GUI测试用例来保证质量。剩下80%的部分不是很稳定，每天都在迭代，针对他们维护case的成本非常高。目前业界中号称做了自动化测试的项目，也大多是在做那稳定的20%。

关于稳定部分的单元测试方法我这里就不赘述了，

的答案给出了很多关键字，有兴趣的去搜索就好了。我想讨论的是针对剩下80%不稳定部分的工程化测试方案。据我了解，前端测试面对这些问题还是很无力的，业内大部分团队还是靠堆人解决。

面对这种现状，我其实也没想到过什么好的方法，基本原则就是：以最低的成本建立和维护自动化测试用例。到目前为止，就想到过两个方案（都不是测试方案，只是回归测试辅助）：

1. 不太靠谱的“超级工位”大法。

这个方案可以说根本不是什么技术方案，而是一个办公设施，就是我们准备一个工位，摆上所有我们需要测试的主流设备，然后设备通过某种方式与一台电脑相连接，测试人员坐在工位上，在电脑中输入某个url，就能同步到所有设备中，然后开始逐个的人肉测试。

超级工位大法示意图（应该很多设备的，这里就是随便展示一下而已。。。）

相比现在的前端GUI测试，超级工位已经算是从0到1的飞跃了，虽然没解决什么技术问题，但为测试前的准备工作做好了铺垫。如果把前端测试比作吃屎，超级工位就是为这餐准备了一个好一点的餐桌。。。

2. 靠谱一些的“页面差异监控”

12年的时候还在百度，当时有同事去美国参加velocity，twitter分享了一下他们的开发流程，其中有一个环节就是页面对比监控，利用了一个叫pdiff的工具，每次提交代码，会自动对比页面之间的差异然后提醒测试人员注意回归。这也是一个典型的GUI测试零成本维护用例的案例。不过pdiff这个工具是基于像素对比的，误报率比较高，所以去年我做了一个这个项目：

基于DOM树的diff，这样就能很大程度上自主控制要监控的元素，可以设置监控样式、文本的变化，比起像素diff智能了一些。

其工作原理就是利用phantom或其他headless浏览器访问页面，然后截图，然后执行一段js，遍历整个dom树，获取元素计算样式和元素内文本内容，构造出一个JSON结构，然后每次diff这个json来判断页面差异，并标记在截图上展示。dom树的diff过程有点类似react的虚拟dom树diff。

（react的dom树diff算法示意图）

（react的dom树diff算法示意图）

DOM树diff我们可以分辨出元素样式修改/内容修改/新增元素/删除元素四种不同的页面差异，我们可以配置选择器来忽略元素。四种页面差异的效果图：

新增元素（绿色区域标记部分，“i am new here”）

删除元素（灰色区域标记部分，“你好”）

内容修改（黄色区域标记部分，“百-度”，“新-浪”）

样式修改（红色区域标记的部分）

基于这样的页面差异对比监控，我们可以建立一个任务系统，把应用的所有页面url监控起来，这样每次版本迭代提交代码后，系统就能自动告诉我们，哪些页面的元素展现发生了改变，用于确定回归范围。

（目前我还只是把这个系统用于竞品或者自家产品的运营监控）

团队开发的基于像素diff的组件监控平台）

用监控的方式确定测试回归范围，是一种“少吃屎”的手段，符合工程化要求，能比较大范围的应用，虽然不能完美解决GUI中的交互问题，但能保证GUI的展现问题已经是不小的进步了。

=====[ 补充 ]=====

大大的提醒，这里强调一下，页面差异监控的目的是方便的通知人肉回归范围，这并非测试方案，而是一种辅助测试的手段。

还有 Selenium 神马的吧

当然 berserkJS 兴许也能凑合干干这事儿（类似phantomjs ）

个人认为一般前端自动化测试大致包括

• 类库单元测试自动化
• UI组件测试自动化

类库单元测试自动化

基本思路是让不同的浏览器可以自动根据指令跑一些JS函数

结果与预期比对后返回是否通过case测试标志

其中一般有两种实现方式：

1. 打开目标浏览器，运行测试框架站点
2. 测试框架站点通过ajax 轮询、websocket 等方式，将待测 js 的 case 在浏览器内运行（通过eval 、createElement("script") 等方式）
3. 比对测试结果，将结果 post 到远端
4. 远端接受测试结果
5. 远端等待所有浏览器返回结果完成
6. marge 所有浏览器数据显示最终通过与否结果。

这种方式弊端：

• 人工开启一次所有浏览器
• 需要排队测试，浏览器只能一次运行完一组测试后才能再运行下一组
• 如果中间某testcase导致浏览器异常，返回结果将缺失，需要人工去服务器上检查下浏览器状态

• 可以覆盖所有想覆盖到的浏览器

另一种方式：

1. 将常用浏览器内核放进一个或多个相互有关联的进程内
2. 用例通过系统消息发送到各个包装的内核中
3. 每次开启一个新内核进程运行JS用例
4. 用例结果发送给包装进程
5. 包装进程汇集所有用例结果后post到远端保存
6. 包装进程连带内核进程一起退出

• 无序人工开启一次浏览器
• 独立进程运行，无需排队
• 不怕内核异常，异常后包装进程可以直接恢复内核或者通知测试失败

• 前端实现太困难，需要C++开发
• 无法覆盖到所有浏览器
• 常用内核覆盖更新劳心劳力

UI组件测试自动化

这是个大坑

因为 UI 涉及可视化内容

需要实现不同 testcase 的自动化界面操作

常见的如，单双击、拖拽、自动表单内容填写等

一般用 Selenium 来录操作后执行

或者使用 phantomjs 等工具写模拟操作脚本来实现

这类东西一般就不太指望能跨全平台了，一个浏览器能跑通就不错了。

======

针对这个稍微补充

说的方法，也只能针对 phantom 之类 qtwebkit 核来作简单页面 diff 展示情况对比。

它不能解决实际复杂情况：

• 针对不同浏览（或不同网络情况）中断吐出内容不一致（想象wap，虽然过时了）
• 个人登录后吐出内容不一致（社交网络）
• 根据地域不同吐出内容不一致（百度搜索框计算什么的）

大致问题了解下就好了

主要是 UI 的 testcase 写起来太烦

而且 UI 还是最善变的

一般公司不去做这种费力不讨好的自动化测试

基于 phantomjs 的自动化测试

它主要靠js脚本来模拟操作

一般流程是写代码写代码写代码

1. open 某个 url
2. 监听 onload 事件
3. 事件完成后调用 sendEvent 之类的 api 去点击某个 DOM 元素所在 point
4. 根据 UI 交互情况 延时 setTimeout （规避惰加载组件点不到的情况）继续 sendEvent 之类的交互
5. 最后调用截图 api 发送操作结果到远端用于人工（或机器）审核 UI 结果是否正常。

简单说几个方面，我自己尝试过的。

1，nodejs端的有phantomjs, java的selenium都可以做固定流程的功能测试，比如全站的登陆，比如设置流程，比如网站功能的主流程，都可以测到，录成脚本，后端直接跑。

2，浏览器插件部分，记得油猴么，还有chrome应该也可以写定制的页面额外脚本，管理好了，自己跑一跑当前页面的ui测试也是可以的。一般用作回归，这个对js的对外api有要求，脚本要能调用的到。

3，单测mocha，jasmine等等，不一一列举，这个很多人熟悉啦。

4，截屏监控与页面质量监控，这个一般成熟点的公司都有，比如上线后发现页面大量dom有变化，会发出警报（短信邮件），设置一个阙值就ok了。

5，找台测试机写脚本批量调用浏览器进程实测页面，收集一些埋点，内嵌一些js跑功能，类似berserkJS。

6，最后的问题，测什么，怎么写，回答：同学写过爬虫么，就是假装自己是个用户，去做操作，然后设置延迟，等待结果（跳转，ajax 返回做dom修改等），再判断此功能是否执行成功，ps，注意如果有flash的页面，phantomjs配置起来略麻烦，那个可以再开个问题提问了。

其他答案基本把方案都说了，只能分享点我们团队的经验，主要是我们团队没那么多人，没有精力进行繁琐的监控和人肉测试。

准备工作：

1. 我们为了能够同时测试所有浏览器，选用 selenium，js 框架用 jasmine

2. 后端因为是 PHP，选用

来调用 selenium

3. 需要某种方法对页面注入 jasmine 框架，我们因为是 Web App 图方便直接用 ?test=1 的方式打开前端测试

4. 一个 staging 环境

测试/发布流程：

1. 脚本自动 deploy 到 staging，staging 先启动 unit test，测试所有后端代码一切正常

2. unit test 的最后，启动前端测试，发送请求到装有各种浏览器的一台机子，各种浏览器一一测试，webdriver 等待 jasmine 告知测试结果，看有没有 errors

3. 一旦有 errors，deploy 工作暂停，修复bug，再来一遍

4. 如果 jasmine 告知 all tests passed，deploy 继续，staging 环境启动脚本，把代码推送到production，执行 migration，本次发布结束。

（staging 就是和 production 相同环境相同机子，但使用不同域名和数据库的测试站点）

其实我们试过用 CasperJS + PhantomJS + SlimerJS 写测试，但这个方案不能覆盖 IE，虽然我们只支持IE9+，但还是经常碰到一些莫名其妙的问题，最后放弃了。

（其实 webdriver 那段测试已经被我注释了，因为前端测试经常无法通过，我们赶时间发版本，实在来不及修复）

转自专栏：

[从入门到不放弃]多浏览器的自动化测试(1)-本地测试 - 知乎专栏

[从入门到不放弃]多浏览器的自动化测试(2)-云服务测试

前端之殇

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

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

通常情况下，发现兼容性问题的方法莫过于将程序在各个浏览器中执行一遍，但这是极其浪费人力和时间的，最省力的方法也需要在每次版本的更迭时重复一遍测试工作。对于不同的兼容性要求，测试需要的时间各不相同，若是只支持最新版本的浏览器，那么便测试3、4个浏览器即可，但是对于兼容性要求高的程序，有可能要测试10个浏览器以上。对于中小型公司来说，如果没有专职的测试人员，这样的测试耗时是致命的。若进行严格测试，则会拖慢项目进度，倘若敷衍了事，那程序的质量便没法保证。

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

小窥测试

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

在多浏览器的自动化测试，我们多半是进行端到端的测试工作，一小部分是大粒度的单元测试。端到端测试测试模拟用户的行为。在 Web 应用程序中，他们会启动服务器，打开浏览器，模拟用户的行为进行点击、输入、提交等动作，断言浏览器中发生了特定的事情或者是得到了期待的结果，从而让我们相信功能可以正常的运行。而单元测试根据代码单元的公共 API 运行它们。这些测试需要创建一个类的实例，使用特定的输入调用它的方法，断言被调用的方法达到了预期的效果。在下文中我们会看到这两种测试的实践，当然有时候区分度并不大，可能无法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的目标是保证功能可以正常运行救足够了。

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

测试的技术方案选择

在进行项目实践前，很重要的一项工作是选择合适的技术栈。好比在前端开发时应该选择 React，Vue 还是 Angular 作为框架一样，前端的测试工作也需要选择一套技术栈。很多时候大家在制定技术栈时容易走偏，在选择技术框架时不是选择最合适的框架，而是选择最热门的框架。当然一定程度上热门的框架能反应其受欢迎程度，可能是因为其出众的优点，如较高的开发效率、高效的渲染特性或者是活跃的社区。在前端开发中，很容易有这样的感受，就是只要半个月没有关注业界的最新动态，就感觉恍若隔世，新的解决方案层出不穷，让人喘不过气。就作者本人经验来说，已经过了慌乱的年纪，再也不会盲目地追寻新技术，而转向关注技术背后解决的痛点，就好像2C创业者们嘴上老说的用户痛点一样。

在介绍本文涉及项目的技术栈之前，需要提醒诸位，此处的技术选择并不一定完全适用于诸位的项目，请各位三思而测。目前市场上有众多的测试框架，测试断言库甚至是全套的测试解决方案。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所示：

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

1. 安装测试所需包

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

npm install nightwatch --save-dev

2. 增加 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"
  ...
}

3. 配置 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。

4. 书写测试用例

在各项准备工作完毕后，就只差测试用例了，下面是项目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)。

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

本地测试与云测试

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

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

转自：[从入门到不放弃]多浏览器的自动化测试(2)-云服务测试 - 知乎专栏

在上一篇文章中，撸主已手把手教大家如何从零开始构建一个本地自动化测试工程。如果你没有看过上一篇文章，请先逐字阅读。本文将在上一篇文章的基础上主要为大家介绍两个内容：一是如何免费地搭建多机的自动化测试环境，二是如何使用云测试服务进行360度无死角的自动化测试。信息量大，请各位阅后勿焚，动手牢记。

本地测试鞭长莫及

由于一台计算机支持的浏览器种类有限，如一台 mac 上可以安装 safari, chrome, firefox, opera 等，而且通常只能安装一个版本的产品，所以本地测试多用于检验功能逻辑是否正确，或者是检验特定浏览器的特定功能。对于未知的兼容性测试，单凭本地测试是没法进行的。下文中介绍的方法将提供给测试者一种全新的测试体验，通过远程测试的方式对自己的代码进行测试。 远程测试需要搞清楚两个概念，一是客户端 (Client)，一是服务端 (Server)，Client 是用于运行 test cases 代码的地方，Server 则是浏览器所在地。通过 Server 上的一些 servlet 来连接 Client 和 Server 上的浏览器，实现将 test 中的用例行为在远程端的浏览器上执行。 通过浏览器和 test 执行宿主机的分离，使得test能在更多的浏览器上执行，并且更易于扩展测试浏览器的数量。在下文的实践当中，读者会对 Client 和 Server 有更清楚的了解，在此不再赘述。

自己的云测试环境

既然测试代码要和浏览器环境分割开来，那么我们需要在前文的基础上将浏览器安装到其他的环境中，而不是将浏览器和测试的 Node 测试环境放在同一台机子。安装完成之后需要使用服务端的 Servlet 也就是 Selenium 提供的 webdriver server 将测试环境和浏览器连接起来。具体的步骤如下： 1. 寻找到一台可用的主机： 无论是实体机还是虚拟机都是可以的，不过需要主机可以接入到测试运行主机的网络。

2. 在主机上安装浏览器： 具体安装的浏览器类型和版本根据操作系统和测试需求而定， 例如可以在 windows 操作系统上安装 IE， firefox等浏览器，在 Linux 系统安装 chrome, firefox等浏览器， 在 Mac系统上安装 safari, chrome 等浏览器。

3. 下载对应浏览器的 driver 到Server主机上。因为 selenium 需要使用不同的 driver 来启动不同的浏览器，如同上一篇文章提到的bin目录下的 driver 可执行文件，此时要将需要测试浏览器对应的 driver 下载到 server 上，然后再通过测试工程的配置告诉 selenium-server-standalone 这些 driver 在哪，从而执行它们来操作浏览器。

4. 在主机上下载并启动 Selenium Server: 该 Server 实际上是一个 Java 小程序，用于 client 和 server 之间的通信（有关 selenium 原理的文章请关注《搞不懂不甘心》系列）。首先在 Selenium 的官网上下载 selenium-server-standalone-{VERSION}.jar， 然后启动该 Jar 包。

java -jar selenium-server-standalone-{VERSION}.jar

如果主机没有安装 JRE, 则需要再安装 java 的运行环境或者是直接安装 jdk 。

5. 修改测试项目的配置文件：还记得启动测试时需要指定的配置文件吗？这个配置文件 test.conf.js 非常重要，用于配置 selenium 以及测试的浏览器，当我们改变使用远程server的浏览器作为测试目标时，当然需要修改配置文件。我们需要将配置文件中的 selenium 项修改为如下形式：

selenium : {
    "start_process" : true,

    //server的ip地址
    "host" : "192.168.10.1",

    "port" : 4444,

    "cli_args": {

      //chromedriver 在server主机上的文件路径
      "webdriver.chrome.driver": "/home/bin/chromedriver",

      //geckodriver 在server主机上的文件路径
      "webdriver.gecko.driver" : "/home/bin/geckodriver"
    }
  }

对于test_settings的设置请参照上文，然后按照自己安装的浏览器版本进行修改。

6. 启动测试：一切准备好了之后，在client主机上，也就是测试代码运行的机子上便可启动测试。

"scripts": {
  ...
  "test": "./node_modules/.bin/nightwatch -c conf/test.conf.js -e A,B"
  ...
}

自己搭建测试云环境的过程其实并不复杂，只需要在将 selenium server 和浏览器安装到其他主机即可，对于 client 上的代码不需要改动，只需要改动配置中的 selenium 配置。但是很快测试者会发现，当我们需要测试更多的机子，用手工的方式去维护这些 server 是一件费时费力的事，也消耗了公司的计算资源。有没有更好的办法让我们既可以全面的测试自己的代码又可以不用费尽心思维护主机？答案是有，请继续阅读。

云测试服务

对于繁琐重复的工程任务，商家们总是能想到赚钱的办法，这不对于上文我们碰到的麻烦就有商家提供了相应的产品。该产品为测试者们提供无数个测试浏览器，测试者不需要关心这些浏览器在何处运行，应该怎么样维护，只需要一个服务地址便可以将自己的测试页面跑在这些浏览器上，其实这个服务地址和之前我们自己搭建的 Server ip 类似，只不过如果使用自己的测试云，使用不同的测试主机时，需要手动更改host。而这些商家提供了一个类似分销中心，用于流量分发，所以我们只需要用一个地址便可实现使用不同的主机进行测试。 目前提供此类服务的商家有很多，如 browserstack、saucelabs、crossbrowsertesting 等，大家可以根据自己手头黄金和测试的需要选择性价比高的服务。本文将使用 browserstack 作为例子为大家科普此类服务，不过它并不是撸主的金钱爸爸，请大家放下水文的猜疑。

根据我们自行搭建云测试环境的经验，我们将 browserstack 的测试后台架构猜想为下图所示。我们不关心该架构是否是真实的实现，但是这是合理的理论猜想，希望此图能让我们对此服务有个大概的技术了解：

browserstack 为用户提供了自动化测试、实时交互测试、截图等服务，关于具体的服务细节请移步官网。本节将主要介绍如何使用其自动化测试服务，会稍微提及实时交互测试的功能。那接下来便开始我们的云测试使用体验： 首先在其[网站](https://www.browserstack.com)上注册账号，点击最上方的导航栏中的 Automate，跳转页面后在新页面左侧最上方点击 ”Username and Access Keys”，便可看到用于使用云测试服务的用户名和key，我们将使用此auth来修改测试配置。 现在回到我们的测试项目，对 test.conf.js 的 selenium 项进行修改，并添加 common_capabilities 项，用于配置云服务的信息。

selenium : {
    "start_process" : false,
    "host" : "hub-cloud.browserstack.com",
    "port" : 80
  },

  common_capabilities: {
    'build': 'nightwatch-browserstack',
    // Browserstack 的 username 对应配置项
    'browserstack.user': process.env.BROWSERSTACK_USERNAME',
    // Browserstack 的 key 对应配置项
    'browserstack.key': process.env.BROWSERSTACK_ACCESS_KEY,
    'browserstack.debug': true,
    'browserstack.local': true
  }

连接云测试服务的配置工作完成后，我们需要指定测试的浏览器种类和版本。如果有不指定的字段，云服务会有缺省值来填充，例如配置中没有指定操作系统，云服务则会自动选择最快的一个测试机，而不管浏览器所在的操作系统。再例如当没指定测试浏览器的版本时，云服务则会测试最新版本的浏览器。官网上的文档提供了所有可提供测试的浏览器种类和版本，为了说明方便，我们现在只指定浏览器种类，不规定版本。简要的浏览器配置项如下：

...
    safari: {
      desiredCapabilities: {
        browserName: 'safari'
      }
    },
    ie: {
      desiredCapabilities: {
        browserName: 'ie'
      }
    },
    ...
    ios: {
      desiredCapabilities: {
        browserName: 'iPhone'
      }
    }
    ...
  }

以上工作做完之后便可以启动测试了，是不是so easy。除了命令行返回的测试结果之外，browsertack 自动化测试还为我们提供了测试回放等。如果发现测试出错，可以通过商家提供的在线实时测试来进行调试，这也是一个非常方便的功能。

有的放矢地测试

阅读完自动化测试的文章，相信大家已经迫不及待想体验云测试的便利。在各位动手之前，有一些温馨提示需要告知大家。首先这些云测试服务因为由国外服务商提供，所以网络延时有些时候会过高，测试可能会出现超时的情况，请选择网络较好的主机来运行测试用例。其次是因为自动化测试会让大家写测试用例上瘾，反正测试扔上去测就好，但是撸主认为测试人员还是要清楚地划分测试的粒度，有些测试用例比如细粒度的单元测试和端对端的测试，有很多测试覆盖的都是同样的代码，这样的测试其实是浪费的，所以在明确目标之后，还需要精心设计测试用例。最后如有不懂请先 google，其他不能 google 的问题欢迎和撸主交流，文章若有错请指教。