基于像素对比的前端E2E测试探索

2023-03-22 本文已影响0人 cd2001cjm

一，背景

近期我们做了一版新的web运行框架，试运行后，领导和同事给了很多的建议和反馈，有些是需求有些是Bug。但当我们在修复Bug或实现需求的时候。发现一个质量问题，经常出现修改1个问题引入1个问题的现象，比如调整了一种场景下的菜单宽度会导致另一种场景下的菜单显示偏移不齐。

随着新版web运行框架内容的不断丰富，每次修改靠人工去判断对错，不管是在效率方面还是结果方面，都不太理想。所以我们需要用一种新的测试手段去进行可视化效果的E2E验证。期望：每次修改发布测试环境后，我们跑一遍测试用例，就能知道可视化效果有没有受损，有没有意外影响。

二，实现方案

一番搜索后发现，其实很多大厂都已经有了解决方案并用于实践，我们在这方面有点后知后觉了。其实现思路是基于图的像素比对，主要流程如下：

对预期结果抓图并保存
用无头浏览器访问，并进行动作模拟。最后抓取运行结果图片并保存
对比预期图片与结果图片间的像素差异，大于某个值就认为有错

通过选型最终结果如下：

puppeteer 提供无头浏览器(Headless browser)
pixelmatch 提供图片像素级别的比较
pngjs 提供png的读写能力

三，关键技术解读

pixelmatch是该方案的关键，所以笔者就学习了一下pixelmatch的源码，粗略学习了像素对比的实现原理。其过程大致如下：

如果两张图片完全相同，则返回0。否则，它根据匹配阈值和YIQ差异度量计算两种颜色之间的最大可接受平方距离。然后，它将每个相应像素进行比较，并使用YIQ差异度量计算它们之间的颜色差异。
如果颜色差异超过阈值，则检查它是否是真正的渲染差异或仅是反锯齿。
如果是反锯齿，则将像素绘制为黄色，并将其不计为差异。
如果是真正的渲染差异，则将像素绘制为差异，并增加差异计数。
如果像素相似，则将背景绘制为与白色混合的灰度图像。

在这个过程中有两个比较关键的点：

1，颜色差异的比较采用的是YIQ差异度量计算

YIQ，是NTSC（National Television Standards Committee）电视系统标准。Y是提供黑白电视及彩色电视的亮度信号（Luminance），即亮度（Brightness），I代表In-phase，色彩从橙色到青色，Q代表Quadrature-phase，色彩从紫色到黄绿色

这里实现分两步：

第一步是RGBA转YIQ，其标准公式如下：

function rgb2y(r, g, b) { return r * 0.29889531 + g * 0.58662247 + b * 0.11448223; }

如果是有透明度的：会按一定的公式与白色进行混合，其公式如下：

255 + (c - 255) * a;

第二步就是差异计算的理论基于YIQ NTSC transmission color space in mobile applications，计算公式如下：

delta = 0.5053 * (Y1 - Y2) ^ 2 + 0.299 * (I1 - I2) ^ 2 + 0.1957 * (Q1 - Q2) ^ 2

2，区分渲染差异和反锯齿

什么是反锯齿？

反锯齿（英语：anti-aliasing，简称AA），也译为抗锯齿或边缘柔化、消除混叠、抗图像折叠有损等。它是一种消除显示器输出的画面中图物边缘出现凹凸锯齿的技术。

当我们计算出像素差异后，需要区分一下是真的差异还是反锯齿引起。其判断依据是通过检查像素是否具有3个或更多相邻的相同颜色像素来进行判定。如果周围像素颜色一致，那么就认为是反锯齿。反之则认为是真正的像素差异。

四，实践情况

我们先实现了一个基础版，然后通过边实践边丰富方式来渐进完善。

其代码主要部分如下，无头浏览器部分：

/**
 * 执行测试case
 * @param {} caseInfo  测试case信息
 */
async function runCase(caseInfo) {
  const browser = await puppeteer.launch({ headless: true });
  const page = await browser.newPage();
  await page.setViewport({
    width: caseInfo.imgWidth,
    height: caseInfo.imgHeight,
    deviceScaleFactor: 1,
  });

  await page.goto(caseInfo.caseUrl);

  if(caseInfo.autoLogin){

    let username = caseInfo.username
    let password = caseInfo.password
    await page.evaluate(async (username,password) => {
      window.autoLogin(username,password)
    },username,password);

    await page.waitForNavigation()
  }
  
  await page.waitForTimeout(5000);

  if(caseInfo.operators){
   await caseInfo.operators(page)
   await page.waitForTimeout(1000);
  }
  
  let _p = path.join(caseInfo.baseDir,'result.png')
  await page.screenshot({ path: _p });
  await browser.close();
  const diff  = await compareImages(_p, path.join(caseInfo.baseDir,caseInfo.expectImg),caseInfo);
  if (diff > 0.005) {
    console.log(caseInfo.caseTitle +'\x1b[31m%s\x1b[0m', '❌');
  } else {
    console.log(caseInfo.caseTitle +':\x1b[32m%s\x1b[0m', '✅');
  }
}

图片像素比对部分：

/**
 * 图片比较
 * @param {*} img1Path 图1
 * @param {*} img2Path 图2
 * @param {*} caseInfo 测试case信息
 * @returns 
 */
async function compareImages(img1Path, img2Path,caseInfo) {

  const img1 = PNG.sync.read(fs.readFileSync(img1Path));
  const img2 = PNG.sync.read(fs.readFileSync(img2Path));
  const {width, height} = img1;
  const diff = new PNG({width, height});
  
  const numDiffPixels = pixelmatch(img1.data, img2.data, diff.data, width, height, {threshold: 0.1});
  
  fs.writeFileSync(path.join(caseInfo.baseDir,'diff.png'), PNG.sync.write(diff));

  const deviationRate = numDiffPixels / (width * height);

  return deviationRate
}

逻辑上我们把图片分为三个：

预期的叫expect
执行结果叫result
差异叫diff

最后判断偏差是否大于0.005，大于就认为有问题。

我们做了两个demoCase进行了效果验证，分别是

登录页面测试
首页面(展开菜单)测试

执行测试后，结果如下图：

image.png

一个成功一个失败，然后我们分别看一下图形对比：（图片依次为expect，result，diff）*

登录页面测试对比图：

image.png

首页面(展开菜单)测试对比图：

image.png

通过图形对比我们可以看到，判断结果是准确的。

五，总结

目前为止，我们还只是快速实现了一个测试的原型，大量case还在补充验证中。至于是否可以解决开篇描述的问题，还需要进一步观察和实践。同时一些细节以及测试Case的功能完备性方面也会不断加强完善。比如结果对比可视化，执行脚本可录制化等等

前端代码质量可以通过单元测试解决，在可视化效果验证方面，像素对比应该是一个好的方向。

基于像素对比的前端E2E测试探索

猜你喜欢

热点阅读