2023年6月21日发(作者：)
如何进⾏前端⾃动化测试？转⾃专栏：前端之殇要是你碰到前端⼯程师朋友，那聊聊浏览器的兼容性准是没错，这和碰到英国朋友就谈天⽓是⼀个道理。⼤部分程序员朋友们⼀定会捶胸顿⾜，连连诉苦，不过如果对⽅⼀时语塞，或者欲⾔⼜⽌，请拍拍他/她肩膀说：“没事，过两年出了新浏览器⼜是⼀条好汉。”在前端界，浏览器兼容性是让⼯程师们头疼的问题，对于经验丰富的⼈来说，很清楚浏览器有哪些坑，但是对于⼤部分程序员，最可怕的是代码明明在这个浏览器运⾏得很好，但是到了另⼀个浏览器中就不能正常运⾏了。对于这部分的程序员，保障代码能正常运⾏的⽅法便是能尽早发现问题，然后将其解决。通常情况下，发现兼容性问题的⽅法莫过于将程序在各个浏览器中执⾏⼀遍，但这是极其浪费⼈⼒和时间的，最省⼒的⽅法也需要在每次版本的更迭时重复⼀遍测试⼯作。对于不同的兼容性要求，测试需要的时间各不相同，若是只⽀持最新版本的浏览器，那么便测试3、4个浏览器即可，但是对于兼容性要求⾼的程序，有可能要测试10个浏览器以上。对于中⼩型公司来说，如果没有专职的测试⼈员，这样的测试耗时是致命的。若进⾏严格测试，则会拖慢项⽬进度，倘若敷衍了事，那程序的质量便没法保证。本⽂将作为多浏览器⾃动化测试的第⼀篇⽂章，将以项⽬A作为例⼦，给读者从头介绍如何进⾏本地多浏览的⾃动化测试⼯作，包括测试的原理、测试框架的选取、测试⼯程的搭建和实现等。在下⼀篇⽂章中将介绍如何使⽤云服务实现更多浏览器的测试⼯作。另外“从⼊门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项⽬⾃动化构建等案例，欢迎⼤家关注本系列的其他⽂章。⼩窥测试测试是⼀个庞⼤的主题，包括各种分类的测试，诸如⿊盒测试/⽩盒测试、/集成测试/端到端测试等。通常程序员在测试⾃⼰的代码的时候⽤得最多的便是单元测试，但是因为测试也是需要代价，很多⼈是不喜欢写测试的，甚⾄是⼀点都不写。当然今天我们不是要讨伐诸位，⽽是希望读者能从⽂中受益，从⼀个测试⼩⽩可以⾃⼰动⼿搭建⾃⼰的测试⼯程。在多浏览器的⾃动化测试，我们多半是进⾏端到端的测试⼯作，⼀⼩部分是⼤粒度的单元测试。端到端测试测试模拟⽤户的⾏为。在 Web应⽤程序中，他们会启动服务器，打开浏览器，模拟⽤户的⾏为进⾏点击、输⼊、提交等动作，断⾔浏览器中发⽣了特定的事情或者是得到了期待的结果，从⽽让我们相信功能可以正常的运⾏。⽽单元测试根据代码单元的公共 API 运⾏它们。这些测试需要创建⼀个类的实例，使⽤特定的输⼊调⽤它的⽅法，断⾔被调⽤的⽅法达到了预期的效果。在下⽂中我们会看到这两种测试的实践，当然有时候区分度并不⼤，可能⽆法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的⽬标是保证功能可以正常运⾏救⾜够了。在浏览器的测试中，Selenium 可谓是最重要的⼯具之⼀。简单来说Selenium的作⽤是 "Automate Browsers"——让浏览器可以⾃动化起来的⼯具。它提供了统⼀的接⼝，让⽤户可以使⽤不同的编程语⾔，调⽤其接⼝来模拟⽤户的操作，例如点击，移动等操作。基本上⼀切⼈⼯操作的⾏为都可以通过 Selenium 的 API 进⾏触发操作。我们将 Selenium 看作是⼈⼿的代理，帮程序员完成⼀切⽤⼿⼲的活。测试的技术⽅案选择在进⾏项⽬实践前，很重要的⼀项⼯作是选择合适的技术栈。好⽐在前端开发时应该选择 React，Vue 还是 Angular 作为框架⼀样，前端的测试⼯作也需要选择⼀套技术栈。很多时候⼤家在制定技术栈时容易⾛偏，在选择时不是选择最合适的框架，⽽是选择最热门的框架。当然⼀定程度上热门的框架能反应其受欢迎程度，可能是因为其出众的优点，如较⾼的开发效率、⾼效的渲染特性或者是活跃的社区。在前端开发中，很容易有这样的感受，就是只要半个⽉没有关注业界的最新动态，就感觉恍若隔世，新的解决⽅案层出不穷，让⼈喘不过⽓。就作者本⼈经验来说，已经过了慌乱的年纪，再也不会盲⽬地追寻新技术，⽽转向关注技术背后解决的痛点，就好像2C创业者们嘴上⽼说的⽤户痛点⼀样。在介绍本⽂涉及项⽬的技术栈之前，需要提醒诸位，此处的技术选择并不⼀定完全适⽤于诸位的项⽬，请各位三思⽽测。⽬前市场上有众多的测试框架，测试断⾔库甚⾄是全套的测试解决⽅案。Karma、Jasmine 和 Mocha 是⼤家熟知的测试框架，⽽ chai, 是流⾏的断⾔库，另外在不同的技术社区还有⾃成⼀套的测试技术，⽐如 React 社区中的 Jest 和 Enzyme 都是受开发者喜爱的测试框架和库，最近⼀些新的并⾏测试解决⽅案也⽇渐流⾏，如AVA、Intern。本⽂中的实践来⾃于项⽬A，在项⽬测试前期我们分析了测试需求，我们希望整个测试⽅案能满⾜⼀下要求：⽀持端到端测试对接云测试服务⽅便本地测试和云测试切换⽅便提供封装的浏览器操作接⼝测试⽤例可以快速迁移到其他框架下执⾏考量了以上的需求，我们认为 是⼀款⾮常合适的测试解决⽅案。当然其他的测试框架也基本能满⾜需求，但是从⽅便易⽤性上考虑，我们最后采⽤了 ，该⽅案不仅提供简易封装的浏览器代理操作 API， 还给我们提供了⽅便便捷的云测试配置(下⼀篇⽂章将着重介绍此内容)，就凭这两点就已经⾮常吸引我们了。对于前端测试新⼿，强烈推荐试⽤此框架，让你可以迅速完成曾经畏⽽却步的测试⼯作。项⽬实践项⽬A的本地测试实践是需要分别在两台电脑上的多浏览器中执⾏测试，两台电脑分别是 Windows 系统和 Mac 系统，包括了 IE 、Firefox(windows/mac)、Chrome(windows/mac)、Safari 等最新的主流浏览器。两台机⼦的测试是分别执⾏的，我们通过 Jenkins 分别定期执⾏机⼦上的测试任务，将测试结果通过邮件的⽅式反馈给开发⼈员。 Jenkins 是⼀个持续集成的平台，关于如果使⽤ Jenkins 请各位⾃⼰Google..在接下来的⽂章中，我们将只介绍在⼀台机⼦上的⼯程实践，对于多个机⼦的测试需要将如下的⼯程部署到不同的机⼦，再使⽤诸如Jenkins 之类的⼯具进⾏定期执⾏就可以。开始⼯作前，我们需要将技术关系了然于⼼。我们在 Nightwatch 框架下使⽤ Selenium 中的 driver对浏览器进⾏操作。不同的浏览器有不同的 Driver，整个技术栈图如图1所⽰：
图1在图中 Test Runner 即为 Nightwatch，我们使⽤ Nightwatch 提供封装过的 API 进⾏ Test Case 的书写。下⾯我们将从零开始⼿把⼿教你如何使⽤ Nightwatch 启动你的第⼀个 Test case。1. 安装测试所需包在⾃⼰的前端项⽬中安装 ，并将其保存在 的 devDependencies 中。npm install nightwatch --save-dev2. 增加 npm script ⼊⼝在 中加⼊ test 指令⼊⼝，该条指令的具体⼯作是使⽤ 的配置，执⾏名为'A'、'B'、'C'的配置项(若为了直观查看测试的内容，可根据项⽬的测试浏览器和版本将名字设为 , safari9.0 这样的名字，此处设为 A,B,C 是避免⼤家误认为是指令是⾃动根据名字去寻找匹配的浏览器）。更多命令的详解请参照 Nightwatch ⽂档。"scripts": { ... "test": "./node_modules/.bin/nightwatch -c conf/ -e A,B" ...}3. 配置 Nightwatch完成指令⼊⼝的配置⼯作，接下来需要完成 的配置⼯作。在本地测试中，我们使⽤ 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/-", "host" : "127.0.0.1", "port" : 4444, "cli_args": { "": "bin/chromedriver", "" : "bin/geckodriver" }},...test_settings: { A: { desiredCapabilities: { 'browserName': 'chrome' } }, B: { desiredCapabilities: { 'browserName': 'safari' } }}...诸位需要根据⾃⼰机⼦的实际情况进⾏配置，如果是Windows系统，那么将没有，⽽使⽤ IE 浏览器，这样则会需要 IE 浏览器对应的driver。4. 书写测试⽤例在各项准备⼯作完毕后，就只差测试⽤例了，下⾯是项⽬A的⼀个测试⽤例的⽚段，⽤于检测页⾯上 id 为 testid 的 DOM 中的内容字符，我们期待字符的长度为 32， 如果该字符为 32 个字符，那么测试通过，否则测试失败。需要注意的是因为此 DOM 是动态插⼊的，所以在判断其字符前，我们使⽤ waitForElementVisible 来检查浏览器中 testid 的 DOM 是否已经显⽰，若在5秒内显⽰则进⾏下⾯的⼯作，如果没有显⽰，那么测试也会失败。s = { '@tags': ['unit'], 'unit testing' : function (browser) { (`localhost:3010/test`) .waitForElementVisible('#testid', 5000) .getText("#testid",function(result){ (,32); }); (); }};5. 运⾏测试到此为⽌，我们简单的测试⼯程已经搭建完毕。现在我们回过头去，执⾏我们最开始配置的 test 指令，启动测试任务。你需要在命令中执⾏：如果顺利的话，此时你会看到浏览器⾃动地打开关闭，很快就能从终端上看到如下的测试结果,图2 展⽰的是多个测试⽤例成功的结果，图3展⽰的是测试失败的结果（如遇到⽆法测试或者其它异常情况请 Google。：D)。图2图3从测试结果中可以查看测试⽤例的测试结果，包括测试的浏览器、未通过测试的信息详情等。⾄此，⼀个从零开始的本地测试实践教程结束。本地测试与云测试因为本地浏览器的类型有限，⼀般我们更多地使⽤本地的多浏览器测试来完成功能验证的⼯作，对于要求更严的兼容性测试，我们将采⽤云测试的⽅式。云测试即云服务提供商将向我们提供更多的云主机，每台主机上运⾏着不同版本的浏览器。通过使⽤云测试服务，我们就能将测试覆盖到更多类型、版本的浏览器。在下⼀篇⽂章中，我们仍以项⽬A为例⼦，使⽤ Nightwatch 框架，在此⽂章的基础上介绍云测试和云测试⼯程的搭建。转⾃：在上⼀篇⽂章中，撸主已⼿把⼿教⼤家如何从零开始构建⼀个本地⾃动化测试⼯程。如果你没有看过上⼀篇⽂章，请先逐字阅读。本⽂将在上⼀篇⽂章的基础上主要为⼤家介绍两个内容：⼀是如何免费地搭建多机的⾃动化测试环境，⼆是如何使⽤云测试服务进⾏360度⽆死⾓的⾃动化测试。信息量⼤，请各位阅后勿焚，动⼿牢记。本地测试鞭长莫及由于⼀台计算机⽀持的浏览器种类有限，如⼀台 mac 上可以安装 safari, chrome, firefox, opera 等，⽽且通常只能安装⼀个版本的产品，所以本地测试多⽤于检验功能逻辑是否正确，或者是检验特定浏览器的特定功能。对于未知的兼容性测试，单凭本地测试是没法进⾏的。下⽂中介绍的⽅法将提供给测试者⼀种全新的测试体验，通过远程测试的⽅式对⾃⼰的代码进⾏测试。 远程测试需要搞清楚两个概念，⼀是客户端 (Client)，⼀是服务端 (Server)，Client 是⽤于运⾏ test cases 代码的地⽅，Server 则是浏览器所在地。通过 Server 上的⼀些 servlet 来连接 Client 和 Server 上的浏览器，实现将 test 中的⽤例⾏为在远程端的浏览器上执⾏。 通过浏览器和 test 执⾏宿主机的分离，使得test能在更多的浏览器上执⾏，并且更易于扩展测试浏览器的数量。在下⽂的实践当中，读者会对 Client 和 Server 有更清楚的了解，在此不再赘述。⾃⼰的云测试环境既然测试代码要和浏览器环境分割开来，那么我们需要在前⽂的基础上将浏览器安装到其他的环境中，⽽不是将浏览器和测试的 Node 测试环境放在同⼀台机⼦。安装完成之后需要使⽤服务端的 Servlet 也就是 Selenium 提供的 将测试环境和浏览器连接起来。具体的步骤如下：1. 寻找到⼀台可⽤的主机： ⽆论是实体机还是虚拟机都是可以的，不过需要主机可以接⼊到测试运⾏主机的⽹络。2. 在主机上安装浏览器： 具体安装的浏览器类型和版本根据操作系统和测试需求⽽定， 例如可以在 windows 操作系统上安装 IE， firefox等浏览器，在 Linux 系统安装 chrome, firefox等浏览器， 在 Mac系统上安装 safari, chrome 等浏览器。3. 下载对应浏览器的 driver 到Server主机上。因为 selenium 需要使⽤不同的 driver 来启动不同的浏览器，如同上⼀篇⽂章提到的bin⽬录下的 driver 可执⾏⽂件，此时要将需要测试浏览器对应的 driver 下载到 server 上，然后再通过测试⼯程的配置告诉 selenium-server-standalone 这些 driver 在哪，从⽽执⾏它们来操作浏览器。chromedriver (⽤于 chrome)下载地址:geckodriver (可⽤于 firefox, safari)下载地址: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. 修改测试项⽬的配置⽂件：还记得启动测试时需要指定的配置⽂件吗？这个配置⽂件 ⾮常重要，⽤于配置 selenium 以及测试的浏览器，当我们改变使⽤远程server的浏览器作为测试⽬标时，当然需要修改配置⽂件。我们需要将配置⽂件中的 selenium 项修改为如下形式：selenium : { "start_process" : true, //server的ip地址 "host" : "192.168.10.1", "port" : 4444, "cli_args": { //chromedriver 在server主机上的⽂件路径 "": "/home/bin/chromedriver", //geckodriver 在server主机上的⽂件路径 "" : "/home/bin/geckodriver" } }对于的设置请参照上⽂，然后按照⾃⼰安装的浏览器版本进⾏修改。6. 启动测试：⼀切准备好了之后，在client主机上，也就是测试代码运⾏的机⼦上便可启动测试。"scripts": { ... "test": "./node_modules/.bin/nightwatch -c conf/ -e A,B" ...}⾃⼰搭建测试云环境的过程其实并不复杂，只需要在将 和浏览器安装到其他主机即可，对于 client 上的代码不需要改动，只需要改动配置中的 selenium 配置。但是很快测试者会发现，当我们需要测试更多的机⼦，⽤⼿⼯的⽅式去维护这些 server 是⼀件费时费⼒的事，也消耗了公司的计算资源。有没有更好的办法让我们既可以全⾯的测试⾃⼰的代码⼜可以不⽤费尽⼼思维护主机？答案是有，请继续阅读。云测试服务对于繁琐重复的⼯程任务，商家们总是能想到赚钱的办法，这不对于上⽂我们碰到的⿇烦就有商家提供了相应的产品。该产品为测试者们提供⽆数个测试浏览器，测试者不需要关⼼这些浏览器在何处运⾏，应该怎么样维护，只需要⼀个服务地址便可以将⾃⼰的测试页⾯跑在这些浏览器上，其实这个服务地址和之前我们⾃⼰搭建的 Server ip 类似，只不过如果使⽤⾃⼰的测试云，使⽤不同的测试主机时，需要⼿动更改host。⽽这些商家提供了⼀个类似分销中⼼，⽤于流量分发，所以我们只需要⽤⼀个地址便可实现使⽤不同的主机进⾏测试。 ⽬前提供此类服务的商家有很多，如 browserstack、saucelabs、crossbrowsertesting 等，⼤家可以根据⾃⼰⼿头黄⾦和测试的需要选择性价⽐⾼的服务。本⽂将使⽤ browserstack 作为例⼦为⼤家科普此类服务，不过它并不是撸主的⾦钱爸爸，请⼤家放下⽔⽂的猜疑。根据我们⾃⾏搭建云测试环境的经验，我们将 browserstack 的测试后台架构猜想为下图所⽰。我们不关⼼该架构是否是真实的实现，但是这是合理的理论猜想，希望此图能让我们对此服务有个⼤概的技术了解：selenium : { "start_process" : false, "host" : "", "port" : 80 }, common_capabilities: { 'build': '', // Browserstack 的 username 对应配置项 '': RSTACK_USERNAME', // Browserstack 的 key 对应配置项 '': RSTACK_ACCESS_KEY, '': true, '': true }连接云测试服务的配置⼯作完成后，我们需要指定测试的浏览器种类和版本。如果有不指定的字段，云服务会有缺省值来填充，例如配置中没有指定操作系统，云服务则会⾃动选择最快的⼀个测试机，⽽不管浏览器所在的操作系统。再例如当没指定测试浏览器的版本时，云服务则会测试最新版本的浏览器。官⽹上的⽂档提供了所有可提供测试的浏览器种类和版本，为了说明⽅便，我们现在只指定浏览器种类，不规定版本。简要的浏览器配置项如下：... safari: { desiredCapabilities: { browserName: 'safari' } }, ie: { desiredCapabilities: { browserName: 'ie' } }, ... ios: { desiredCapabilities: { browserName: 'iPhone' } } ... }以上⼯作做完之后便可以启动测试了，是不是so easy。除了命令⾏返回的测试结果之外，browsertack ⾃动化测试还为我们提供了测试回放等。如果发现测试出错，可以通过商家提供的在线实时测试来进⾏调试，这也是⼀个⾮常⽅便的功能。
有的放⽮地测试阅读完⾃动化测试的⽂章，相信⼤家已经迫不及待想体验云测试的便利。在各位动⼿之前，有⼀些温馨提⽰需要告知⼤家。⾸先这些云测试服务因为由国外服务商提供，所以⽹络延时有些时候会过⾼，测试可能会出现超时的情况，请选择⽹络较好的主机来运⾏测试⽤例。其次是因为⾃动化测试会让⼤家写测试⽤例上瘾，反正测试扔上去测就好，但是撸主认为测试⼈员还是要清楚地划分测试的粒度，有些测试⽤例⽐如细粒度的单元测试和端对端的测试，有很多测试覆盖的都是同样的代码，这样的测试其实是浪费的，所以在明确⽬标之后，还需要精⼼设计测试⽤例。最后如有不懂请先 google，其他不能 google 的问题欢迎和撸主交流，⽂章若有错请指教。
2023年6月21日发(作者：)
如何进⾏前端⾃动化测试？转⾃专栏：前端之殇要是你碰到前端⼯程师朋友，那聊聊浏览器的兼容性准是没错，这和碰到英国朋友就谈天⽓是⼀个道理。⼤部分程序员朋友们⼀定会捶胸顿⾜，连连诉苦，不过如果对⽅⼀时语塞，或者欲⾔⼜⽌，请拍拍他/她肩膀说：“没事，过两年出了新浏览器⼜是⼀条好汉。”在前端界，浏览器兼容性是让⼯程师们头疼的问题，对于经验丰富的⼈来说，很清楚浏览器有哪些坑，但是对于⼤部分程序员，最可怕的是代码明明在这个浏览器运⾏得很好，但是到了另⼀个浏览器中就不能正常运⾏了。对于这部分的程序员，保障代码能正常运⾏的⽅法便是能尽早发现问题，然后将其解决。通常情况下，发现兼容性问题的⽅法莫过于将程序在各个浏览器中执⾏⼀遍，但这是极其浪费⼈⼒和时间的，最省⼒的⽅法也需要在每次版本的更迭时重复⼀遍测试⼯作。对于不同的兼容性要求，测试需要的时间各不相同，若是只⽀持最新版本的浏览器，那么便测试3、4个浏览器即可，但是对于兼容性要求⾼的程序，有可能要测试10个浏览器以上。对于中⼩型公司来说，如果没有专职的测试⼈员，这样的测试耗时是致命的。若进⾏严格测试，则会拖慢项⽬进度，倘若敷衍了事，那程序的质量便没法保证。本⽂将作为多浏览器⾃动化测试的第⼀篇⽂章，将以项⽬A作为例⼦，给读者从头介绍如何进⾏本地多浏览的⾃动化测试⼯作，包括测试的原理、测试框架的选取、测试⼯程的搭建和实现等。在下⼀篇⽂章中将介绍如何使⽤云服务实现更多浏览器的测试⼯作。另外“从⼊门到不放弃”系列将给读者们带来更多从零开始的前端实践案例，诸如前端组件库设计与实施、项⽬⾃动化构建等案例，欢迎⼤家关注本系列的其他⽂章。⼩窥测试测试是⼀个庞⼤的主题，包括各种分类的测试，诸如⿊盒测试/⽩盒测试、/集成测试/端到端测试等。通常程序员在测试⾃⼰的代码的时候⽤得最多的便是单元测试，但是因为测试也是需要代价，很多⼈是不喜欢写测试的，甚⾄是⼀点都不写。当然今天我们不是要讨伐诸位，⽽是希望读者能从⽂中受益，从⼀个测试⼩⽩可以⾃⼰动⼿搭建⾃⼰的测试⼯程。在多浏览器的⾃动化测试，我们多半是进⾏端到端的测试⼯作，⼀⼩部分是⼤粒度的单元测试。端到端测试测试模拟⽤户的⾏为。在 Web应⽤程序中，他们会启动服务器，打开浏览器，模拟⽤户的⾏为进⾏点击、输⼊、提交等动作，断⾔浏览器中发⽣了特定的事情或者是得到了期待的结果，从⽽让我们相信功能可以正常的运⾏。⽽单元测试根据代码单元的公共 API 运⾏它们。这些测试需要创建⼀个类的实例，使⽤特定的输⼊调⽤它的⽅法，断⾔被调⽤的⽅法达到了预期的效果。在下⽂中我们会看到这两种测试的实践，当然有时候区分度并不⼤，可能⽆法明显地区分哪些是端对端测试哪些是单元测试，有时候他们是混合起来的，不过只要记住我们的⽬标是保证功能可以正常运⾏救⾜够了。在浏览器的测试中，Selenium 可谓是最重要的⼯具之⼀。简单来说Selenium的作⽤是 "Automate Browsers"——让浏览器可以⾃动化起来的⼯具。它提供了统⼀的接⼝，让⽤户可以使⽤不同的编程语⾔，调⽤其接⼝来模拟⽤户的操作，例如点击，移动等操作。基本上⼀切⼈⼯操作的⾏为都可以通过 Selenium 的 API 进⾏触发操作。我们将 Selenium 看作是⼈⼿的代理，帮程序员完成⼀切⽤⼿⼲的活。测试的技术⽅案选择在进⾏项⽬实践前，很重要的⼀项⼯作是选择合适的技术栈。好⽐在前端开发时应该选择 React，Vue 还是 Angular 作为框架⼀样，前端的测试⼯作也需要选择⼀套技术栈。很多时候⼤家在制定技术栈时容易⾛偏，在选择时不是选择最合适的框架，⽽是选择最热门的框架。当然⼀定程度上热门的框架能反应其受欢迎程度，可能是因为其出众的优点，如较⾼的开发效率、⾼效的渲染特性或者是活跃的社区。在前端开发中，很容易有这样的感受，就是只要半个⽉没有关注业界的最新动态，就感觉恍若隔世，新的解决⽅案层出不穷，让⼈喘不过⽓。就作者本⼈经验来说，已经过了慌乱的年纪，再也不会盲⽬地追寻新技术，⽽转向关注技术背后解决的痛点，就好像2C创业者们嘴上⽼说的⽤户痛点⼀样。在介绍本⽂涉及项⽬的技术栈之前，需要提醒诸位，此处的技术选择并不⼀定完全适⽤于诸位的项⽬，请各位三思⽽测。⽬前市场上有众多的测试框架，测试断⾔库甚⾄是全套的测试解决⽅案。Karma、Jasmine 和 Mocha 是⼤家熟知的测试框架，⽽ chai, 是流⾏的断⾔库，另外在不同的技术社区还有⾃成⼀套的测试技术，⽐如 React 社区中的 Jest 和 Enzyme 都是受开发者喜爱的测试框架和库，最近⼀些新的并⾏测试解决⽅案也⽇渐流⾏，如AVA、Intern。本⽂中的实践来⾃于项⽬A，在项⽬测试前期我们分析了测试需求，我们希望整个测试⽅案能满⾜⼀下要求：⽀持端到端测试对接云测试服务⽅便本地测试和云测试切换⽅便提供封装的浏览器操作接⼝测试⽤例可以快速迁移到其他框架下执⾏考量了以上的需求，我们认为 是⼀款⾮常合适的测试解决⽅案。当然其他的测试框架也基本能满⾜需求，但是从⽅便易⽤性上考虑，我们最后采⽤了 ，该⽅案不仅提供简易封装的浏览器代理操作 API， 还给我们提供了⽅便便捷的云测试配置(下⼀篇⽂章将着重介绍此内容)，就凭这两点就已经⾮常吸引我们了。对于前端测试新⼿，强烈推荐试⽤此框架，让你可以迅速完成曾经畏⽽却步的测试⼯作。项⽬实践项⽬A的本地测试实践是需要分别在两台电脑上的多浏览器中执⾏测试，两台电脑分别是 Windows 系统和 Mac 系统，包括了 IE 、Firefox(windows/mac)、Chrome(windows/mac)、Safari 等最新的主流浏览器。两台机⼦的测试是分别执⾏的，我们通过 Jenkins 分别定期执⾏机⼦上的测试任务，将测试结果通过邮件的⽅式反馈给开发⼈员。 Jenkins 是⼀个持续集成的平台，关于如果使⽤ Jenkins 请各位⾃⼰Google..在接下来的⽂章中，我们将只介绍在⼀台机⼦上的⼯程实践，对于多个机⼦的测试需要将如下的⼯程部署到不同的机⼦，再使⽤诸如Jenkins 之类的⼯具进⾏定期执⾏就可以。开始⼯作前，我们需要将技术关系了然于⼼。我们在 Nightwatch 框架下使⽤ Selenium 中的 driver对浏览器进⾏操作。不同的浏览器有不同的 Driver，整个技术栈图如图1所⽰：
图1在图中 Test Runner 即为 Nightwatch，我们使⽤ Nightwatch 提供封装过的 API 进⾏ Test Case 的书写。下⾯我们将从零开始⼿把⼿教你如何使⽤ Nightwatch 启动你的第⼀个 Test case。1. 安装测试所需包在⾃⼰的前端项⽬中安装 ，并将其保存在 的 devDependencies 中。npm install nightwatch --save-dev2. 增加 npm script ⼊⼝在 中加⼊ test 指令⼊⼝，该条指令的具体⼯作是使⽤ 的配置，执⾏名为'A'、'B'、'C'的配置项(若为了直观查看测试的内容，可根据项⽬的测试浏览器和版本将名字设为 , safari9.0 这样的名字，此处设为 A,B,C 是避免⼤家误认为是指令是⾃动根据名字去寻找匹配的浏览器）。更多命令的详解请参照 Nightwatch ⽂档。"scripts": { ... "test": "./node_modules/.bin/nightwatch -c conf/ -e A,B" ...}3. 配置 Nightwatch完成指令⼊⼝的配置⼯作，接下来需要完成 的配置⼯作。在本地测试中，我们使⽤ 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/-", "host" : "127.0.0.1", "port" : 4444, "cli_args": { "": "bin/chromedriver", "" : "bin/geckodriver" }},...test_settings: { A: { desiredCapabilities: { 'browserName': 'chrome' } }, B: { desiredCapabilities: { 'browserName': 'safari' } }}...诸位需要根据⾃⼰机⼦的实际情况进⾏配置，如果是Windows系统，那么将没有，⽽使⽤ IE 浏览器，这样则会需要 IE 浏览器对应的driver。4. 书写测试⽤例在各项准备⼯作完毕后，就只差测试⽤例了，下⾯是项⽬A的⼀个测试⽤例的⽚段，⽤于检测页⾯上 id 为 testid 的 DOM 中的内容字符，我们期待字符的长度为 32， 如果该字符为 32 个字符，那么测试通过，否则测试失败。需要注意的是因为此 DOM 是动态插⼊的，所以在判断其字符前，我们使⽤ waitForElementVisible 来检查浏览器中 testid 的 DOM 是否已经显⽰，若在5秒内显⽰则进⾏下⾯的⼯作，如果没有显⽰，那么测试也会失败。s = { '@tags': ['unit'], 'unit testing' : function (browser) { (`localhost:3010/test`) .waitForElementVisible('#testid', 5000) .getText("#testid",function(result){ (,32); }); (); }};5. 运⾏测试到此为⽌，我们简单的测试⼯程已经搭建完毕。现在我们回过头去，执⾏我们最开始配置的 test 指令，启动测试任务。你需要在命令中执⾏：如果顺利的话，此时你会看到浏览器⾃动地打开关闭，很快就能从终端上看到如下的测试结果,图2 展⽰的是多个测试⽤例成功的结果，图3展⽰的是测试失败的结果（如遇到⽆法测试或者其它异常情况请 Google。：D)。图2图3从测试结果中可以查看测试⽤例的测试结果，包括测试的浏览器、未通过测试的信息详情等。⾄此，⼀个从零开始的本地测试实践教程结束。本地测试与云测试因为本地浏览器的类型有限，⼀般我们更多地使⽤本地的多浏览器测试来完成功能验证的⼯作，对于要求更严的兼容性测试，我们将采⽤云测试的⽅式。云测试即云服务提供商将向我们提供更多的云主机，每台主机上运⾏着不同版本的浏览器。通过使⽤云测试服务，我们就能将测试覆盖到更多类型、版本的浏览器。在下⼀篇⽂章中，我们仍以项⽬A为例⼦，使⽤ Nightwatch 框架，在此⽂章的基础上介绍云测试和云测试⼯程的搭建。转⾃：在上⼀篇⽂章中，撸主已⼿把⼿教⼤家如何从零开始构建⼀个本地⾃动化测试⼯程。如果你没有看过上⼀篇⽂章，请先逐字阅读。本⽂将在上⼀篇⽂章的基础上主要为⼤家介绍两个内容：⼀是如何免费地搭建多机的⾃动化测试环境，⼆是如何使⽤云测试服务进⾏360度⽆死⾓的⾃动化测试。信息量⼤，请各位阅后勿焚，动⼿牢记。本地测试鞭长莫及由于⼀台计算机⽀持的浏览器种类有限，如⼀台 mac 上可以安装 safari, chrome, firefox, opera 等，⽽且通常只能安装⼀个版本的产品，所以本地测试多⽤于检验功能逻辑是否正确，或者是检验特定浏览器的特定功能。对于未知的兼容性测试，单凭本地测试是没法进⾏的。下⽂中介绍的⽅法将提供给测试者⼀种全新的测试体验，通过远程测试的⽅式对⾃⼰的代码进⾏测试。 远程测试需要搞清楚两个概念，⼀是客户端 (Client)，⼀是服务端 (Server)，Client 是⽤于运⾏ test cases 代码的地⽅，Server 则是浏览器所在地。通过 Server 上的⼀些 servlet 来连接 Client 和 Server 上的浏览器，实现将 test 中的⽤例⾏为在远程端的浏览器上执⾏。 通过浏览器和 test 执⾏宿主机的分离，使得test能在更多的浏览器上执⾏，并且更易于扩展测试浏览器的数量。在下⽂的实践当中，读者会对 Client 和 Server 有更清楚的了解，在此不再赘述。⾃⼰的云测试环境既然测试代码要和浏览器环境分割开来，那么我们需要在前⽂的基础上将浏览器安装到其他的环境中，⽽不是将浏览器和测试的 Node 测试环境放在同⼀台机⼦。安装完成之后需要使⽤服务端的 Servlet 也就是 Selenium 提供的 将测试环境和浏览器连接起来。具体的步骤如下：1. 寻找到⼀台可⽤的主机： ⽆论是实体机还是虚拟机都是可以的，不过需要主机可以接⼊到测试运⾏主机的⽹络。2. 在主机上安装浏览器： 具体安装的浏览器类型和版本根据操作系统和测试需求⽽定， 例如可以在 windows 操作系统上安装 IE， firefox等浏览器，在 Linux 系统安装 chrome, firefox等浏览器， 在 Mac系统上安装 safari, chrome 等浏览器。3. 下载对应浏览器的 driver 到Server主机上。因为 selenium 需要使⽤不同的 driver 来启动不同的浏览器，如同上⼀篇⽂章提到的bin⽬录下的 driver 可执⾏⽂件，此时要将需要测试浏览器对应的 driver 下载到 server 上，然后再通过测试⼯程的配置告诉 selenium-server-standalone 这些 driver 在哪，从⽽执⾏它们来操作浏览器。chromedriver (⽤于 chrome)下载地址:geckodriver (可⽤于 firefox, safari)下载地址: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. 修改测试项⽬的配置⽂件：还记得启动测试时需要指定的配置⽂件吗？这个配置⽂件 ⾮常重要，⽤于配置 selenium 以及测试的浏览器，当我们改变使⽤远程server的浏览器作为测试⽬标时，当然需要修改配置⽂件。我们需要将配置⽂件中的 selenium 项修改为如下形式：selenium : { "start_process" : true, //server的ip地址 "host" : "192.168.10.1", "port" : 4444, "cli_args": { //chromedriver 在server主机上的⽂件路径 "": "/home/bin/chromedriver", //geckodriver 在server主机上的⽂件路径 "" : "/home/bin/geckodriver" } }对于的设置请参照上⽂，然后按照⾃⼰安装的浏览器版本进⾏修改。6. 启动测试：⼀切准备好了之后，在client主机上，也就是测试代码运⾏的机⼦上便可启动测试。"scripts": { ... "test": "./node_modules/.bin/nightwatch -c conf/ -e A,B" ...}⾃⼰搭建测试云环境的过程其实并不复杂，只需要在将 和浏览器安装到其他主机即可，对于 client 上的代码不需要改动，只需要改动配置中的 selenium 配置。但是很快测试者会发现，当我们需要测试更多的机⼦，⽤⼿⼯的⽅式去维护这些 server 是⼀件费时费⼒的事，也消耗了公司的计算资源。有没有更好的办法让我们既可以全⾯的测试⾃⼰的代码⼜可以不⽤费尽⼼思维护主机？答案是有，请继续阅读。云测试服务对于繁琐重复的⼯程任务，商家们总是能想到赚钱的办法，这不对于上⽂我们碰到的⿇烦就有商家提供了相应的产品。该产品为测试者们提供⽆数个测试浏览器，测试者不需要关⼼这些浏览器在何处运⾏，应该怎么样维护，只需要⼀个服务地址便可以将⾃⼰的测试页⾯跑在这些浏览器上，其实这个服务地址和之前我们⾃⼰搭建的 Server ip 类似，只不过如果使⽤⾃⼰的测试云，使⽤不同的测试主机时，需要⼿动更改host。⽽这些商家提供了⼀个类似分销中⼼，⽤于流量分发，所以我们只需要⽤⼀个地址便可实现使⽤不同的主机进⾏测试。 ⽬前提供此类服务的商家有很多，如 browserstack、saucelabs、crossbrowsertesting 等，⼤家可以根据⾃⼰⼿头黄⾦和测试的需要选择性价⽐⾼的服务。本⽂将使⽤ browserstack 作为例⼦为⼤家科普此类服务，不过它并不是撸主的⾦钱爸爸，请⼤家放下⽔⽂的猜疑。根据我们⾃⾏搭建云测试环境的经验，我们将 browserstack 的测试后台架构猜想为下图所⽰。我们不关⼼该架构是否是真实的实现，但是这是合理的理论猜想，希望此图能让我们对此服务有个⼤概的技术了解：selenium : { "start_process" : false, "host" : "", "port" : 80 }, common_capabilities: { 'build': '', // Browserstack 的 username 对应配置项 '': RSTACK_USERNAME', // Browserstack 的 key 对应配置项 '': RSTACK_ACCESS_KEY, '': true, '': true }连接云测试服务的配置⼯作完成后，我们需要指定测试的浏览器种类和版本。如果有不指定的字段，云服务会有缺省值来填充，例如配置中没有指定操作系统，云服务则会⾃动选择最快的⼀个测试机，⽽不管浏览器所在的操作系统。再例如当没指定测试浏览器的版本时，云服务则会测试最新版本的浏览器。官⽹上的⽂档提供了所有可提供测试的浏览器种类和版本，为了说明⽅便，我们现在只指定浏览器种类，不规定版本。简要的浏览器配置项如下：... safari: { desiredCapabilities: { browserName: 'safari' } }, ie: { desiredCapabilities: { browserName: 'ie' } }, ... ios: { desiredCapabilities: { browserName: 'iPhone' } } ... }以上⼯作做完之后便可以启动测试了，是不是so easy。除了命令⾏返回的测试结果之外，browsertack ⾃动化测试还为我们提供了测试回放等。如果发现测试出错，可以通过商家提供的在线实时测试来进⾏调试，这也是⼀个⾮常⽅便的功能。
有的放⽮地测试阅读完⾃动化测试的⽂章，相信⼤家已经迫不及待想体验云测试的便利。在各位动⼿之前，有⼀些温馨提⽰需要告知⼤家。⾸先这些云测试服务因为由国外服务商提供，所以⽹络延时有些时候会过⾼，测试可能会出现超时的情况，请选择⽹络较好的主机来运⾏测试⽤例。其次是因为⾃动化测试会让⼤家写测试⽤例上瘾，反正测试扔上去测就好，但是撸主认为测试⼈员还是要清楚地划分测试的粒度，有些测试⽤例⽐如细粒度的单元测试和端对端的测试，有很多测试覆盖的都是同样的代码，这样的测试其实是浪费的，所以在明确⽬标之后，还需要精⼼设计测试⽤例。最后如有不懂请先 google，其他不能 google 的问题欢迎和撸主交流，⽂章若有错请指教。
发布评论