背景

前端业务场景中每次性能公布都会面临着相应的ui功能测试，因为前端业务的性能迭代之间往往存在显性或者隐性的关联性，每次上线某个性能迭代后，严格意义上也须要对整体性能进行回归，因而单靠人力的手工测试须要破费较多的工夫和精力在性能回归上，且容易漏掉一些细节问题。
基于业务中的上述现状，咱们尝试引入ui自动化测试来解决测试中的“反复回归”问题，基于 puppeteer 和 jest 两大开源工具，封装了一款UI自动化测试sdk，实用于以下两个常见业务场景：

  • 稳固的老业务，性能不常常迭代，通过自动化测试实现每次公布的测试
  • 正在疾速迭代中业务中的外围流程，通过自动化测试保障每次公布后外围流程的性能失常

性能阐明

  1. 通过sdk和配置文件，主动实现ui自动化测试流程
  2. 反对浏览器实时复现整个测试过程
  3. 反对pc和h5不同终端的测试
  4. 主动生成测试流程中的性能页面截图，用户自行通过截图进行测试后果断定
  5. 反对预设页面性能的比对图片，主动实现页面截图和预设比对图片的比对，依据比对差别进行测试后果断定
  6. 主动输入最终的测试报告
  7. 反对全局接口的监控，反对自定义接口测试
  8. 同时反对es和cjs的输入，兼容import和require的导入
  9. 测试过程中命令行终端中实时输入测试停顿

应用形式

第一步：前端工程中引入

通过npm的形式，装置好sdk

npm i xxx// 这里须要留神的是，肯定不要用原始的npm镜像源，因为包外面的chromium的源地址在国外，下载会失败，能够用cnpm、taobao镜像源等代理镜像源

第二步：在工程中创立测试入口文件，举荐的文件目录如下

工程根目录    |    +---uiTest        |               +---origin // 如果须要图片比对，寄存原始的比对图片的目录        |       xxx.png        |       xxx.png        |               +---result // 寄存测试过程中截图和最终图片比对后果图的目录        |       xxx.png        |       xxx.png        |        +---test.js // 测试入口文件

第三步：在测试入口文件 test.js 中接入sdk

const UITestPlayer = require('xxx');const myUITestPlayer = new UITestPlayer({  headless: false,  fullScreen: true});myUITestPlayer.run(runConfig);

若应用 import 形式，则须要保障以后工程的 package.json 中具备 type:module 字段，或者创立的入口文件的后缀是.mjs（test.mjs）

import UITestPlayer from 'xxx';const myUITestPlayer = new UITestPlayer({  headless: false,});myUITestPlayer.run(runConfig);

第四步：运行测试文件

在以后工程下的命令行中执行下述指令，即可期待自动化测试运行

node uiTest/test.js

更好的做法是在以后工程的 package.json 中的 scripts 字段中配置如下命令：

{  "scripts": {    "uiTest": "node uiTest/test.js"  }}

配置完之后，在以后工程下的命令行中执行下述指令即可

npm run uiTest

配置阐明

初始化options配置阐明

{  chromiumPath?: string; // chromiumPath浏览器文件的寄存目录, 如果须要应用本地的chromium  headless?: boolean; // 是否是无浏览器模式，默认true  ignoreHTTPSErrors?: boolean; //是否疏忽https的报错，默认true  fullScreen?: boolean; // 当headless为false时，关上的浏览器是否全屏，优先级高于width和height配置  width?: number; // 当headless为false时，关上的浏览器的width, 默认800  height?: number; // 当headless为false时，关上的浏览器的height, 默认600}

runConfig配置文件阐明

{  title?: 'ui自动化测试' // 生成测试报告的题目  url: 'http://localhost:7002/', // 测试的页面地址  screenshotPath?: 'uiTest/result', // 截图寄存的门路，默认会创立uiTest目录  expectedMismatch?: 1000; // 截图比照可承受的像素差，默认1000  pageLoadTest?: { // 首页测试    value?: 'xxxx', // 比对图片的url, 如果配置了会做截图比对，如果为空只会截图    trigger?: { // 截图触发机会，默认 time 2000ms      mode: 'time', // 截图触发的形式，目前有'time'和'dom'两种形式      value: 5000 // 数字对应time，字符串对应dom    }  },    process: [{ // 测试流程配置        title?: 'top视图性能', // 测试性能名称        step: [ // 测试的具体步骤，如果只须要一次操作则配置单个对象即可，否则按程序配置多个对象      {        eventType: 'click', // click: 点击 ｜ hover: 鼠标悬浮 ｜ goTo: 页面跳转 ｜ reload: 刷新页面 ｜ focus: 聚焦页面元素 ｜ keydown: 键盘按键按下 ｜ keyup: 键盘按键抬起 等等浏览器事件        eventTarget: '.minimap-container',        eventOption?: {}; // 事件参数            test?: {              value?: 'xxxx', // 比对图片url, 配置了会做截图比对，为空只会截图              trigger?: { // 截图触发机会，默认 time 2000ms                  mode: 'time', // 触发的形式，目前有'time'和'dom'两种形式                  value: 5000 // 数字对应time，字符串对应dom                },          skipScreenshot?: false; // 是否跳过截屏，默认false        },      }    ],  }]}

留神点

初始化options
  1. 默认不开启浏览器运行成果，在控制台会实时输入测试过程中的要害信息，能够通过 headless: true 进行开启
  2. width和height是运行浏览器的尺寸，因而过程中的测试截图也是这个尺寸
runConfig
  1. 最终会调用jest主动生成测试报告，title的配置就是用于最终的测试报告
  2. 预设的比对图片的宽高必须和初始化 options 中的宽高尺寸（默认800*600） 放弃同比例，否则缩放后会有压缩或拉伸，会影响比对后果
  3. expectedMismatch 是测试截图和预设比对截图的比照的像素差，完全一致的状况下最后比照的后果是0，能够依据理论要求的精确度进行数值调整
  4. process用于配置整体须要测试的流程，测试运行时会依照数组对象的程序执行，外面的每个对象都是一个独自的测试用例。每个测试用例里用step字段配置具体的测试操作，大多数状况下能够采纳单个操作来配置，比方点击某个按钮，期待响应后，主动进行截图，形成了一个step。然而如果是有多个连贯操作形成的测试操作，比方先跳转到某个页面，再进行点击，则在step中就要进行跳转和点击两个先后操作的配置。
  5. 测试后果判断，如果没有配置比对图片，则默认每个测试用例都是通过的。如果配置了比对图片，则只有测试截图和比对图片的差别小于设定的 expectedMismatch 值，才判断测试通过。如果一个测试用例的step蕴含多个对象的图片比对，则须要满足所有图片比对符合要求，才判断测试通过。
  6. skipScreenshot个别用于step中间断操作中的不重要步骤的跳过截图操作，比方先跳转到某个页面，再进行点击，跳转到某个页面后到截图不是关注的重点，点击的成果才是重点。这时候就能够在这个跳转的操作对象中配置跳过截图。

方案设计

理解了性能和用法之后，上面具体说说性能中的一些具体设计思路和实现计划

设计思路

ui自动化测试的是否真的须要，跟具体的前端业务有非常亲密的关联，这一点在文章结尾就说了。依据本人的开发教训来看，如果太过繁琐的测试操作（比方全副手写测试用例），往往会有点鸡肋的感觉，所以sdk的设计思路就是做出一款比较简单灵便的测试工具。测试的后果判断能够是全自动化的（配置了比对图片，通过图片比对来给出测试后果），也能够是半自动化的（不配置比对图片，只让sdk做默认的测试截图，最初人工查阅这些截图做出测试后果的判断）。理论应用下来之后，一个比拟好的实际是第一次测试半自动化，主动生成测试截图，将合乎预期的图片作为后续测试的比对图片，配置好比对图片后，后续在没有ui调整的状况下都进行自动化测试。

外围能力的选型

前端的ui自动化测试须要用到浏览器的能力，后期的技术调研次要思考的就是 selenium 和 puppeteer,比照后的大抵论断是 selenium 的能力更强，puppeteer的应用更敌对。基于轻量化的定位，最终选取了puppeteer作为外围框架。如果要做更强的测试能力（如反对多终端，测试浏览器兼容性）那么可能 selenium会更适宜。此外，在这个过程中，还思考过另外一种ui自动化测试的模式，即录屏记录测试人对页面的操作流程，自动化生成测试的脚本。这种计划其实感觉更好，例如sahi pro就肯定水平上反对，然而本人走下来遇到的问题比拟多，偏离了"轻量化"的定位。
至于测试脚本的的技术选型，这个因为jest和mocha都比拟成熟，之前用得都比拟相熟。所以两者其实都是能够的，最终随机抉择了jest。

puppeteer

在这里不说得太多，能够去 puppeteer中武官网 以及很多材料上具体看。要害就在于puppeteer提供了一套页面操作相干的api，可能唤起一个chrome浏览器，并且模拟出常见的用户操作，比方鼠标事件、键盘事件、页面跳转等，这就让咱们能够通过代码模拟出用户对页面的常见操作，形成了整个自动化测试的主体流程。此外利用puppeteer提供的申请拦挡的能力，sdk封装后就能做到对页面接口的相干测试。

整体逻辑

初始化

sdk中封装了一个类，在这个类承受初始化参数并进行参数解决，而后就会初始化一个 puppeteer 的实例，启动一个全局浏览器，并依据参数设定启动的浏览器的尺寸、是否是h5的页面。

  private async _init() {    this.log('process', '程序初始化中...');    const browserOptions = this.browserOptionsCheck(this.option);    this.browser = await Puppeteer.launch(browserOptions);    this.page = await this.browser.newPage();    await this.runOnH5(this.option?.h5, IPHONE6);    this.log('process', '程序初始化完结');  }

执行测试操作

初始化实现后，当run办法被调用，就会进入测试操作，首先也会对传入的 runConfig 进行一系列的参数解决和合并。紧接着就开始执行首页测试的逻辑，操作浏览器跳转到首页，进行首页的截图操作，如果以后工程中不存在寄存截图的目录，在这里也会将目录创立好。

  private async _pageLoadTest() {    if (this.isClose()) return;    this.log('process', '开始运行首页测试...');    const { value, trigger } = this.playConfig.pageLoadTest;    await this.pageGoto(this.playConfig.url);    await this.waitForByTrigger(trigger);    this.mkdirSync(this.playConfig.screenshotPath);    this.log('process', '首页截图中...');    const imgPath = `${this.playConfig.screenshotPath}/screenshot_home_page.png`;    try {      await this.page.screenshot({        path: imgPath,      });      this.log('success', `${imgPath} 截图胜利！`);    } catch (error) {      this.log('error', `${imgPath} 截图失败`);    }    this.log('process', '首页测试完结');  }

接下来就会进行process中配置的测试操作，其实这个测试的逻辑跟pageLoadTest的首页测试基本上雷同。为什么会分成两个呢，是因为思考到刚进入首页是一个比拟非凡的节点，心愿把这个页面进行截图保留下来，不论用户有没有配置pageLoadTest都会做这么一个操作。而process则是齐全交给了使用者去配置，依据配置的后果进行相应的的测试操作。process的测试代码跟pageLoadTest相比多了一些遍历的操作和依据参数不同调用不同的页面操作api。

 const process = this.playConfig.process;    for (let i = 0; i < process.length; i++) {      const processItem = process[i];      for (let j = 0; j < processItem.step.length; j++) {        const stepItem = processItem.step[j];        const { eventType, eventTarget, eventOption, test } = stepItem;        switch (eventType) {          case processEventType.selectorclick: {            await this.page.click(eventTarget, eventOption);            break;          }          case processEventType.hover: {            await this.page.hover(eventTarget);            break;          }           case processEventType.goto: {            await this.page.goto(eventTarget, eventOption);            break;          }    ......     const { trigger, skipScreenshot } = test;        await this.waitForByTrigger(trigger);        const imgPath = `${this.playConfig.screenshotPath}/screenshot_${processItem.name}_${j}.png`;        if (!skipScreenshot) {          try {            await this.page.screenshot({              path: imgPath,            });            this.log('success', `${imgPath} 截图胜利！`);          } catch (error) {            this.log('error', `${imgPath} 截图失败`);          }    ......    this.log('process', 'process运行完结');

jest进行图片比对

等到测试流程都执行实现后，这时候曾经在相应的目录下生成了页面截图的图片。接下来就进入了最初一步：调用jest进行图片比照，生成最终的测试报告。这个过程其实能够分为两个步骤：

  1. 启动jest测试脚本
  2. 在测试脚本中进行图片比对
启动脚本

在这一步遇到了很多坑，首先要思考到jest匹配测试脚本的门路问题，因为最终这个sdk是在业务工程中去应用的，当执行自动化测试时，所在的目录是在业务工程的根目录下，而此时sdk是在业务工程的node_modules下。因而在jest的配置文件中，须要把rootDir设置为以后文件目录，否则默认就是被执行时的目录，即业务工程的根目录，那么就找不到sdk中的index.test.js这个测试脚本了。

  rootDir: path.resolve(__dirname, '.'),

这时候又引发了第二个问题，“__dirname” 是在node环境下的存在的变量，在sdk中是获取不到值的，因而须要通过另一种形式去获取以后文件的目录，即：

import * as url from 'url';const __dirname = url.fileURLToPath(new URL('.', import.meta.url));

解决了以后门路的问题后，接下来就要执行jest脚本，并把图片比对须要的配置参数传入脚本中。在这里遇到了第三个问题，就是index.test.js匹配不到的问题，试了很多种形式，配合jest配置中 rootDir、testMatch 和 testPathIgnorePatterns 字段进行了屡次的测试。依据配置阐明实践上感觉应该曾经能够了，然而后果始终有问题。通过重复尝试，最终去掉了testMatch（同理testRegex）字段，并用 --runTestsByPath 指定文件门路，终于拜访到了。。。这一步破费了很多工夫，解决之后泪流满面，至于为什么后面的屡次尝试都失败了，可能得从jest源码中找答案了。。。

 await execa(        'npx',        ['jest', '--runTestsByPath', __dirname + 'index.test.js', '--config', JSON.stringify(configFinal)],        {          stdio: 'inherit',        }      );

配置中的几个重要参数也提一下：

  1. reporters字段指定了生成报告的工具包和具体的一些配置，jest-html-reporters会依据测试后果生成一份简略的测试报告
  2. globals 参数是jest提供的能够在测试脚本中全局拜访到的字段配置，把runConfig的配置挂载在__DEV__字段下，这样在index.test.js下就能取到了

这部分具体的代码如下：

try {      const jestConfig = {        preset: 'ts-jest',        testEnvironment: 'node',        transform: {          '^.+\\.(js|ts|tsx)$': 'ts-jest',        },        rootDir: path.resolve(__dirname, '.'),        testPathIgnorePatterns: ['<rootDir>/node_modules/'],        reporters: [          'default',          [            'jest-html-reporters',            {              pageTitle: this.playConfig.title,              publicPath: `${reportPath}/uiTestReport`,              filename: 'UITestReport.html',              openReport: true,            },          ],        ],        testTimeout: 1000 * 60 * 10,      };      const configFinal = {        globals: {          __DEV__: { ...this.playConfig },        },        ...jestConfig,      };      this.log('process', '开始截图比对');      this.closeBrowser();      await execa(        'npx',        ['jest', '--runTestsByPath', __dirname + 'index.test.js', '--config', JSON.stringify(configFinal)],        {          stdio: 'inherit',        }      );    } catch (error) {      this.closeBrowser();      throw new Error('' + error);    }    this.log('done', '全副测试运行完结');  }
图片比对和断言

接下来就进入index.test.js中执行具体的图片比对和测试断言，这部分的逻辑也比拟清晰，首页pageLoadTest比对和过程process配置比对，如果没有提供比对图片的，则只有截图存在就通过测试用例；如果提供了比对图片的，调用图片像素比对办法，将测试截图和比对图片进行像素比对，满足要求则通过测试用例，不满足则不通过，同时生成比对后的后果图片。至此整个测试流程完结，期待生成测试报告。以首页比对为例，代码如下：

describe(playConfig.globals.__DEV__.title, () => {  const { screenshotPath, pageLoadTest, process, expectedMismatch } = playConfig.globals.__DEV__;  it('首页测试', async () => {    const originImagePath = pageLoadTest.value;    const screenShotImagePath = screenshotPath + '/screenshot_home_page.png';    const diffImagePath = screenshotPath + '/diff_home_page.png';    if (originImagePath) {      const diffRes = await diffImage(originImagePath, screenShotImagePath, diffImagePath, expectedMismatch);      try {        expect(diffRes).toBeTruthy();      } catch (error) {        throw new Error('首页截图比照超过预期像素差');      }    } else {      fs.readFile(screenShotImagePath, (err, data) => {        try {          expect(!!data).toBeTruthy();        } catch (error) {          throw new Error('读取首页截图失败');        }      });    }  });

测试信息输入

如果启动sdk的时候用的是无浏览器模式，那么测试者是没有直观感触测试过程的，测试过程中破费的工夫也不算短，直到整个自动化测试流程跑完之后才会主动跳出测试报告的页面。这对测试者来说是很突兀的，甚至中途的期待过程中可能就认为出错了。因而必要的测试过程中的信息反馈是很重要的，如果仔细观察上述的一些代码，会发现有this.log的输入，如：

this.log('process', '程序初始化中...');

这是sdk中基于chalk这款工具封装的终端信息输入办法，理论中的应用成果如下:

有了这些信息的反馈，给测试者的体验成果就会好很多了

成果展现

最初附上一个理论的测试成果demo(ps.录制好视频demo才发现居然不反对上传本地视频...心愿看到sf早日反对吧)

运行测试

测试截图

测试报告