从TechRadar看UI自动化测试的未来

在2017年第17期和2018年19期技术雷达中，分别出现了两个新的工具——cypress,testcafe，之前只接触过webdriver框架的同学可能会有些陌生。而cypress已经在最新一期的技术雷达中进入了评估阶段，并在多个项目得到了应用，总体反馈利大于弊。

先来详细的介绍下cypress以及我所在项目使用中踩过的坑，关于testcafe会在另外一篇文章中介绍,testcafe主要是用来做UI的回归测试，以及多浏览器测试，cypress不足之处则是testcafe的长处。

框架理念

虽然我很鄙视这种行为，但也能够理解，毕竟身后有巨大开发团队在支持，各种开销，总得有收入来维持运转，所以它走了很多中国产品的营销策略，即免费使用，然后通过提供增值服务来赚取利益，也印证了一句话：服务即未来。

框架架构

让我们先来看看它没有公布的设计架构。

这是一张来自cypress 架构师画出的所谓架构图，其实等于什么都没说，但是我们还是能够通过蛛丝马迹，找到一些重要的信息点。electron 与termina，driver ，launcher 等玩过Puppeteer的人肯定知道 chrome headless 既可以在命令中直接执行脚本，又可以通过puppeteer调用chrome launcher在页面运行，显示测试运行过程。

然后我们看下 cypress的运行界面。

貌似就是一个chrome浏览器，没错就是经过二次开发后以electron封装出的工具。没猜错的话，它的底层应该是基于chrome remote-interface这个库，通过在其之上开发出专有的自动化api来控制浏览器。这意味着每个所支持的浏览器都需要一个新的driver。这个driver是什么，用chrome的话其实就是chrome headless。当然还有Firefox，尽管Firefox已经公布了headless模式 但是cypress目前还没有支持。

（chrome headless 架构图）

优点

我们了解了架构，再来说说这种架构之上有哪些优点，和webdriver区别又是什么。

最大的优点：快

我们之前使用基于webdriver的各种测试框架，被运行效率折磨的痛不欲生。在用上cypess之后，感受到要起飞的节奏，为什么？ 之前我们说过cypress其实就是一个二次开发过的chrome，而且你所写的测试是在浏览器进程中运行的，这也意味Cypress测试直接访问真实的DOM元素，而不是像webdriver一样通过json wire protocol、通过proxy server 转换成各种浏览器driver所能识别的命令，这样来来回回会耗费很多时间，所以cypress设计之初就抛弃了 webdriver这种架构。

第二个优点：异步

Cypress is asynchronous and relies on timeouts to know when to stop waiting on an app to get into the expected state. Timeouts can be configured globally, or on a per-command basis.

这是来自官方的文档，所以我们不用再像webdriver那样去封装等待方法，cypress 所有的操作都已经自带了retry功能，直到到达设置的timeout。

第三个优点：只支持js

很多人会诧异，“什么？这也算优点？难道我不会js是我的错？其实cypress面向的主要对象是前端DEV与QA，cypress的底层与所使用工具都来源于前端，面向的测试也是基于前端，例如api，E2E等。

第四个优点：方便调试

前端工具很多都支持hotload，cypress也贴心的加入修改测试代码自动rerun测试的功能，并且支持代码debug，甚至可以在chrome dev tool中方便的调试，更甚每个步骤的操作都会清晰的在图像界面中展示，还有详尽的log信息在console界面打印，还不够的话，还支持录制回放功能，方便你查看整个流程。

其它优点

类似jquery 或者直接使用jquery是获取操作对象。

Cypress.$("ul li").map(function () {
  return Cypress
  .$(this)
  .text()
}

mock普通的http请求。

cy.server()           // enable response stubbing
cy.route({
  method: 'GET',      // Route all GET requests
  url: '/users/*',    // that have a URL that matches '/users/*'
  response: []        // and force the response to be: []
})

以及上面提到的mock graphQL请求。

beforeEach(() => { 
  cy.server();
  cy.mockGraphql({
    schema,
    endpoint: '/gql'
  });
});

还提供了各种CI工具结合的接口，方便与不同CI集成。

不一一介绍，请看文档：

https://docs.cypress.io/guides/guides/continuous-integration.html#Setting-up-CI

缺点

上面吹了那么多好的地方，也该来黑一波了。

坑一：除了cy对象外的所有操作都是同步的

这就意味着类似以下代码你必须用promise封装，否则将会出现错误永远拿不到正确值，因为Cypress.$其实使用的是jquery对象，方法返回永远都是同步。

getElementsText(selector) {
  return Cypress.$(fxConfig[selector]).map(function () {
    return Cypress.$(this).text()
  })get()))
}

有没有方法解决？有 有 有！

使用cypress-promise这个库 如上述代码在返回最外层使用 promisify()方法，在使用ES7 promise语法 async await 就可以转换成为异步操作。

async getElementsText(selector) {
  return await promisify(Cypress.$(fxConfig[selector]).map(function () {
    return Cypress.$(this).text()
  }).get()))
}

坑二：并发测试

当我们的测试用例越来越多时，我们第一个想到是并发测试，但是这是cypress 收费服务。当你按照以下图做了配置时，高高兴兴的在云端运行时，发现根本没有用，因为你没交钱！

有没有方法解决？有 有 有！

1. 利用concurrently这个库或者GNU命令起多个进程去执行不同测试文件，从而绕过cypress的限制。
2. 测试设计层面，利用cucumber的tag 将测试分类，再利用CI 设计不同pipeline 来并发运行不同tag的测试，进而绕开收费限制。

坑三：当元素不存在或者没有找到时，测试会失败

这个坑貌似听起来很正确，但我们想一下这个场景：如果我们希望当某个元素不存在时，需要执行某个操作。但是因为以上默认的实现，没有找到元素，所以会直接报错。

或者某个元素刚开始没有出现，必须将页面滚动到底部，直到全部数据加载完后才出现，也会遇到问题。

有没有方法解决？有 有 有！

利用jquery 查找元素的length是否大于0，然后利用if或while循环进行判断。

if (Cypress.$(".show-more-button").length > 0) {
  cy.get('.show-more-button a').click();
}
else{
  do something
}/

肯定有人问：为什么不直接cypress去查这个元素的length对不起 cypress没有这个方法。

坑四：不支持多浏览器测试

对，cypress首席执行官也说了，多浏览器测试也许在未来已经不需要了，因为微软已经放弃IE啦，好了世界都是chrome和webkit的了。

再来谈谈它的云服务

先看看界面吧。

类似继承了一个CI，但是刚才提到收费项目，并发测试，以及 bar chart分析。

再来看看到底怎么收费？

收费也不算高，这在国外也就一顿大餐，但是提供的服务还是有限，期望以后能够提供一些自动化测试结果分析以及预测的功能，或者结合ML,AI实现一部分的自动化混淆测试。

坑还很多，需要慢慢填，记得当初在上一次提及cypress工具后，很多人都说“坑很多慎入”，其实我觉得和webdriver最开始一样，坑也很多，只有不断有人去填坑，这个工具才会有更好的未来，与其慎入，不如来尝试下他的优点，何乐而不为。

未来预见

对于QA而言，JS势必会成为一门必须要掌握的语言。 由于我们大部分项目都是以前端为主，前端方面的知识储备能够帮助QA快速的融入团队技术架构，快速构建适用于项目的自动化架构。 自动化测试平台化离我们越来越近，Webdriver离我们越来越远，像cypress这种打着免费旗子的工具只会越来越多，那么谁提供的服务更好，性价比最高，就将在这场争夺中存活下来。 就像很多公司在做类似于AWS的产品，但市场中占绝对统治地位仍是AWS，还是那句话——服务即未来。

我们并不需要一个大而全的工具，我们需要的是一个能够帮助整个团队提升工作效率与体验的工具，那么目前来说cypress在E2E的测试上是成功的。 所以从现阶段看像webdriver这种效率低下且体验差的工具在软件开发历史长河中终将泯灭，但还是要感谢它在自动化领域做出的巨大贡献。