稳定性建设之单测、e2e、快照如何选？

bigtree
870 阅读6分钟

背景

去年业务对稳定性方面是沉淀了非常多的东西，借此机会，也给大家分享一下我个人对稳定性的一些思考。今天的主题是一些自动化措施的分享，主要集中在自动化测试这一块。

单测、e2e、快照测试，这3种流行的自动化测试措施各有擅长点和适合的场景，需了解原理，才能更好的利用他们来保障稳定性

单测

看我上一篇：对单测的思考（稳定性建设）

目录：

  1. 单测是什么？
  2. 为什么要写单测？
  3. 单测是跑在什么环境的？
    • 那为什么可以测试一些和浏览器环境相关的操作？比如： document.createElement
    • 那jest是怎么做到模拟浏览器环境的？
  4. 单测的原理是什么？
  5. 单测中需要注意哪些问题？为什么单测会引发这些问题？
    • 为什么单测会引发这些问题，感觉这么麻烦？
  6. 哪些场景适合写单测？
  7. 怎么定义一个单测写的好不好？
  8. 对单测成本和收益的思考？

e2e

1. e2e是什么？

e2e: end to end，指的是端到端测试

  • 第1个端指的是用户端，会模拟一个无痕浏览器，作为真实的一个用户端场景
  • 第2个端是服务端，是我们真正部署好的server端

2. 为什么要写e2e？

  1. 模拟最真实的用户访问
    • 单测和快照毕竟只是在node沙箱里面、并且很多都是mock数据。e2e的环境是用户的真实环境。
  2. 覆盖单测和快照测试不到的场景
    • 像一些路由跳转功能、html结构、样式渲染，就只有e2e比较好覆盖

3. e2e是跑在什么环境的？

跑在最真实的用户浏览器环境

4. e2e的原理是什么？

原理是：用一个无头浏览器（不渲染UI界面）去模拟用户的真实的操作

  • 无头Headless就是没有图形交互界面GUI的意思，Headless模式下的Chrome开放了编程接口，可以通过代码控制它的行为而不再需要图形界面，方便做浏览器自动化

如何模拟用户的操作？

  • 用脚本来控制的，比如说可以用js或jq

  • 我们实际写e2e的话，可以用框架，比如cypress

无头浏览器（e2e用的浏览器环境）和jsdom（单测用的浏览器环境）的区别是什么？

  • 无头浏览器可以理解为真实的浏览器

    访问真正部署好的url链接（底层是用浏览器提供的api，解析网站内容）

    const {Builder} = require('selenium-webdriver');
require("chromedriver");

(async function helloSelenium() {
  let driver = await new Builder().forBrowser('chrome').build();

  await driver.get('https://www.baidu.com'); // 访问真正部署好的url链接

  await driver.quit();
})();

  • jsdom只是解析html字符串，不是真实的浏览器

    const { window } = new JSDOM(`<!DOCTYPE html><p>Hello world</p>`); 
console.log(window.document.querySelector("p").textContent); // "Hello world"

5. e2e中需要注意哪些问题？为什么e2e会引发这些问题？

  1. 因为e2e模拟的是最真实的用户环境和操作，所以当有些用户操作，很难用脚本实现的时候，就很难实现e2e

    • 比如说验证码点选。 比如测试注册功能（测注册功能每次都要换注册账号）

  2. 要把qps控制好，否则容易被公司的防火墙给block + ip拉黑

  3. 因为e2e是要每天跑重复跑的，所以有些情况下有些东西可能会创建过多次。有可能会超出后端可接受的范围，这方面也要提前告知好，别引起线上问题

6. 哪些场景适合写e2e？

  1. 和单测一样，是有成本考虑的，所以 首先需要是 toC重要项目的核心流程 单侧
  2. e2e是真实用户访问场景，和单测的node沙盒不同，理论上和单测是互补的。单测侧重最小单元，e2e可以覆盖完整的操作流程，包括上下游串联（比如跨项目的跳转，检测内容是否显示正确）

7. 怎么定义一个e2e写的好不好？

  1. 除了基本的覆盖核心流程外，好的e2e应该是兼容能力更强的，case更稳定的。这样减少维护成本

    • 写的不好的e2e，会经常可能需要修改case或者维护。因为项目代码可能会变动

    • 比如直接去匹配文本内容，而不是通过class定位到上层级，然后往下层去拿。因为结构可能会在未来有变动

    • 更多的模糊匹配，而不是精准匹配。比如表单完成后，会跳到 xxx url，如果精准匹配的话，未来这个url可能会加带query，这样e2e就会失败了

8. 一些e2e的其他问题

可以看我早先写的一篇： 稳定性建设之e2e

目录：

快照测试

  1. 快照测试是什么？

    1. 对当前渲染的状况打一个快照。后续运行测试的时候，希望后期渲染的效果跟快照一模一样。 这里的快照可以理解为字符串，拷贝一份字符串。然后做精准匹配。

    2. 可以匹配dom结构或css的结构内容是否跟预期的一致

  2. 快照测试的原理是什么？

    1. 需要提前准备好预期的结果。并做好精准匹配。

  3. 适合哪些场景？

    1. 适合匹配dom结构或css的结构内容是否跟预期的一致

  4. 缺点？

    1. 维护成本高，收益一般（因为业务可能迭代更新后，快照就需要更新，并且快照测试是看html结构或css结构，这类问题，自测已经可以覆盖了，所以有点重复）

总结：

特点适合场景
单测1. 快速，成本低
2. 可以覆盖最小单元的边界case		1. 覆盖最小单元的边界case
e2e1. 最真实的浏览器环境
2 可以模拟最真实的用户行为		1. 模拟最真实的用户行为
快照1. 适合匹配dom结构或css的结构内容是否跟预期的一致1. dom或css的结构是否和预期一致

具体怎么选还是得根据自己的业务来看，我个人觉得写e2e和部分单测都非常好：

  1. e2e可以减少很多人工自测的成本（并且几乎都是枯燥的反复自测）

  2. 单测可以保障一些功能单元的边界case无bug

码字不易，点赞鼓励！！

本文正在参加「金石计划」

avatar
文章
阅读
粉丝