基于数据沙箱与LLM用例自愈的UI自动化测试平台

UI自动化测试能够在一定程度上确保产品质量，尤其在降本提效的大背景下，其重要性愈发凸显。理想情况下，UI自动化测试不仅能够能帮我们规避不少线上问题，又能加快产品上线速度。然而现实却往往相去甚远，在多数情况下，编写测试脚本的工作量很大，且由于应用程序的频繁迭代，这些脚本很快就会过时。此外，网络数据的多变也常常导致测试结果不稳定，从而影响测试的可信度。

基于这些挑战，我们开发了一套UI自动化测试平台- AutoMotion，旨在降低UI自动化测试的使用门槛、提升易用性。该平台不但能便捷地生成用例，且借助最新的大型语言模型，该平台也具备了用例自愈能力，能够智能适应界面的合理变动，并自动修正测试脚本；同时，通过构造数据沙箱来隔离和控制测试数据，使平台能够确保测试的一致性和可重复性。

本文将对AutoMotion平台的设计理念、核心功能以及实现原理进行介绍。

背景

我们组内曾尝试过使用cypress等常见工具进行UI自动化测试，但遇到不少问题和痛点，主要归为以下四类：

手写脚本成本高

页面多如繁星，手写自动化测试脚本成本很高。（这点无需赘述）

（有些工具支持根据录制你的操作，然后生成脚本，但普遍能力有限，比如cypress提供的这种工具就无法记录滚动操作）

网络数据变化导致测试结果不可信

无论是线上、预发还是测试环境，数据都会不断变化，导致很多情况下执行通过与否不能正确反应实际功能逻辑有无问题。哪怕指定某个固定测试账号去做某个特定用例的测试也会如此，比如存在一些非幂等的操作时便可能导致问题。

举个简单的例子。某活动页，用户可报名参与该活动（每人只能报名一次），测试用例是“登录账号1，点击活动的报名按钮，页面显示’报名成功‘” ，假如第一次执行用例成功了，此时活动会变为“已报名”状态，第二次执行该用例将无法再次报名，用例不通过，但此时前后端代码并无任何问题。

当然，可以考虑写个重置数据的脚本，然而：第一，需要后端同学的配合；第二，数据背后的关联逻辑可能很复杂（比如以上例子下可以重置账号1的报名状态，但活动可能还会有报名结束时间，或活动被下架，或报名名额达到上限，等等各类情况），且针对不同项目不同场景要准备不同数据，实现成本很高；第三，很难重置线上数据

项目迭代频繁导致用例脚本维护成本高

当页面发生迭代后，哪怕从功能上看此次迭代与某用例无关，也往往会导致该用例脚本失去作用，需要被更新。

参考如下例子：

测试用例是”...点击任务的’去完成‘按钮...“。

页面结构如图所示：

在自动化测试脚本中，我们可以通过“.task > .btn”这个selector选取到“去完成”按钮，然后执行点击操作，cypress代码为：

cy.get('.task > .btn').click()

但在后续迭代中，可能发生一些变化，比如在“.btn”外多包了一层“.task-content”：

此时通过“.task > .btn”就获取不到了，所以我们需要在用例脚本中将selector更新为”.task > .task-content > .btn“。

当然，在这个特定例子下，我们还可以将selector写成“.task .btn”，这样即使在“.btn”外多包了任意层元素也不影响。但如果“.btn”被改成了“.btn-primary”呢？类似的情况还有很多，很多理应与旧用例无关的迭代，都需要我们去更新用例脚本，大大提高了维护成本。甚至在有些时候，每次迭代都需大幅更新大量用例脚本，导致自动化测试完全失去了意义，还不如人肉回归。

如何接入标准流程中

如何把各项目的自动化测试任务便捷地、灵活地接入到开发、发布流程中。（此条也无需赘述）

为了解决以上问题，我们决定自研一个UI自动化测试平台：

UI自动化测试平台 - AutoMotion

针对以上四大问题，该平台对应提供了四大机制以解决：

针对以上四大问题，该平台对应提供了四大机制以解决：

用例脚本录制生成

用以解决：手写脚本成本高

提供chrome插件，开启录制后，你可以模仿用户在页面中进行一系列操作，该插件可识别你的操作，自动生成UI自动化测试脚本。支持点击、键盘输入、滚动、拖动等大部分常见操作。

数据沙箱

用以解决：网络数据变化导致测试结果不可信

为了对之有更确切的理解，这里不妨先将目光从该问题本身向上拉至更一般的角度。

我们可将某浏览器看做一个函数，该函数的“输入”为前端代码、用户操作、接口数据、日期、随机数等，“输出”为渲染后的界面，在几乎99.9%的情况下，可以认为该函数是确定的、无副作用的、可预测的（即在以上“输入”保持不变的情况下，使浏览器运任意次，“输出”也应始终不变）。

然后带着以上视角下重新审视UI自动化测试：

如下图，通常，在某次迭代后执行UI自动化测试用例时，相比前一次的执行，“用户操作”是不变的（写死在测试脚本里），但在它之外可能存在多个输入项的变化，此时若渲染结果发生了变化，导致用例执行失败(中断或不符合断言)，我们很难直接将其归因为“前端代码变更所致”：

而若能使得每次执行UI自动化测试用例时，仅前端代码存在变化，若某次用例执行失败，便能更确切地得知其为“前端代码变更所致”：

至此，“数据沙箱”的想法应运而生：

在用例录制阶段，于录制用户操作的同时，收集过程中的接口请求、storage、cookies、窗口大小等外部数据（你也可以自行修改这些数据），并在用例执行阶段1:1地“复现”出来。

当然，使用“数据沙箱”是有取舍的，使用后虽然避免了接口数据干扰问题，大幅省心，但这样相当于只测前端代码了。所以该平台也支持根据需要关闭特定数据沙箱（比如关闭接口请求沙箱以测到后端逻辑、保留cookies沙箱以避免登录问题）。

用例可视化编辑、用例自愈机制

用以解决：项目迭代频繁导致用例脚本维护成本高

首先，上文介绍的“用例脚本录制生成”能力就已很大程度上解决了该问题，用例需要更新时重新录制一遍即可。

其次，该平台还提供了：

1. “用例可视化编辑”能力，在用例仅需小幅更新时，可快速编辑、更新；

2. “用例脚本编辑”能力，录制的用例可直接转为cypress脚本（后续考虑支持playwright），以进行更加灵活、无约束的编辑。

这些更新方式都较为便捷，但在实际使用中依然存在一大问题：

经过某些迭代后执行用例时，可能很多用例执行不通过，但大部分是页面结构的合理更新后所至，而非新引入的bug，此时需人工一一审阅报错原因，确认是feature或bug。且此次因feature导致的用例不通过，若不及时更新，则下次执行时将有极大概率依然不通过，如此不断叠加，不通过的用例越来越多，导致我们不得不在每次迭代后及时地花费很大精力去排查、更新用例，完全违背了“自动化测试”的初衷。

其实观察该类问题后会发现，它们大部分都出自同一个“简单”的原因：页面更新后，用例执行时获取不到目标元素（请回顾一下上文“③ 项目迭代频繁导致用例脚本维护成本高”中所举的例子）。

针对这种情况，我们对传统的css selector规则进行了扩展，并基于现有的LLM实现了目标元素的智能识别与“用例自愈”。使得在页面结构变化后（非大的功能更新），依然能够获取到目标元素，并自动根据最新页面结构自动更新用例脚本。

Open API

用以解决：如何接入标准流程中

对于录制保存后的每个用例，该平台都会生成相应的open api，调用该api即可执行用例并得到结果。该api可被灵活地接入gitlab、流水线/构建/发布平台、cli工具等，实现在任意流程节点上执行自动化测试。

也可在该平台上设置定时器进行定期自动化测试。

方案与原理介绍

以下会介绍该平台的部分关键技术点和一些背后的思考。

用例录入

chrome插件

用例录入是通过chrome插件实现的，在开启录制时，该插件会进行以下处理：

• 在页面头部植入一段js脚本，侵入页面运行时环境，通过操作页面window对象捕获录制过程中的所有操作行为、storage数据等；

• 在devtools page中捕获录制期间所有接口数据；

• 在background page（service worker）中捕获cookies；

• 在content script中捕获useragent、窗口大小等信息。

录制结束后，该插件会将以上收集到的信息转成符合我们定义规范的用例DSL，存储至后台。除了以上基础能力，该插件中还实现了DSL可视化/编辑、元素可视化拾取、环境识别、异常检测、用例试运行等功能。

由于chrome插件的一些限制，在实际实现以上功能时，需要按照chrome插件支持的能力范围划分模块，且很多模块间不能直接通信，导致数据流相对难以管理（所以我们对通信数据的类型和格式进行了一定规范，这里不展开）。部分细节如下（示意图，仅供参考，大致浏览即可）：

构建与更新

chrome插件与常规前端项目结构有所不同，且该chrome插件目前仅为公司内部使用（未上传至chrome商店），故在构建、打包、版本更新方面也做了一些处理，封装在我们的构建脚本中，运行后可自动完成如下流程：

1. 使用webpack对devtools页面（即本插件中所有UI展示的部分）进行构建；

2. 对devtools页面以外全部文件进行构建（如统一替换环境变量）；

3. 更新manifest中版本号；

4. 将整个项目压缩为zip包，上传至线上；

5. 更新数据库中最新版本号；

6. （用户在打开旧版本chrome插件时会提示更新，点击即可下载）。

用例执行

我们是通过nodejs和cypress实现用例执行的。nodejs服务会在容器中初始化cypress项目环境，在需执行用例时，将用例DSL转为可执行的cypress脚本和相关数据文件，其中包含用户操作、数据沙箱等信息，然后通过cypress运行（支持数个cypress实例并发），最后生成运行结果，并触达给前台触发方或预警方。

行为监听

在上文中已经提到了，在用例录制时，chrome插件会在页面头部植入一段js脚本，监听操作者行为，这里进一步阐述一下监听方式。

基础事件监听

chrome插件植入的js脚本会在页面window对象上进行全局事件委托，以监听用户相关操作。如：

window.addEventListener('input', this.handleInput, true)

特殊事件监听

以上“基础事件监听”方式似乎已经足够，但细想一下，mouseenter、mouseleave、mousemove、mouseover、mouseout等事件也能通过这种方式绑在window或document节点上进行监听吗？

显然不合理，比如若在document上监听mouseenter事件，那么当我们的鼠标划过页面中任意元素时，都会触发该事件，这些信息是冗余的。可以对比一下click，因为用户在页面中的大部分点击操作都是“有意义”的（是整个”页面函数“中的一个有意义的输入），所以整个页面中任意位置触发click是都可以记录，而大部分鼠标移动操作都对页面无实际意义。

这里应当反过来思考：只有本身已经绑定了这些事件的元素，触发这些事件对它来说才大概率是有意义的，我们对这些元素做监听就行。比如页面中有个元素A，它被绑定了mouseenter事件以在鼠标移入时展示tips，那么在用例录制时，若用户将鼠标移入元素A，触发了tips展示，就需要将该mouseenter事件录制下来、在用例执行时触发，否则就无需记录。那么如何知道哪些元素被绑定了这些事件呢？可以将页面中window.Element.prototype.addEventListener函数替换成我们自己构造的函数，实现对任意页面中原本的所有”事件绑定“行为的拦截，当然同时也需调用原函数，不影响原功能。代码示意如下：

const originalAddEventListener = window.Element.prototype.addEventListener;// 替换所有元素的addEventListenerwindow.Element.prototype.addEventListener = function(type, originalListener, ...others) {   // 替换所有元素的listener回调函数，进而拦截mouseenter、mouseleave、mouseover、mouseout事件  const listener = function(event) {    if (isRecording && ['mouseenter', 'mouseleave', 'mouseover', 'mouseout', 'mousemove'].includes(event.type) && event.target === this) {      handleMouseAction(event)    }    originalListener.call(this, event)  }  return originalAddEventListener.call(this, type, listener, ...others)}

目标元素定位

“行为”实际上包括“动作”和“作用对象”（即“目标元素”）两块。比如“用户点击元素A”，其中“动作”是“点击”，“目标元素”是“元素A”。上文已经介绍了如何识别“动作”，这里介绍如何定位“目标元素”

基础定位

以“从根节点到目标元素的唯一路径的css selector”作为定位方式。如：body > div > #app > div.app-right > div > div:nth-child(2) > div.text

基础定位增强

请先看一个例子，如下图，“导出”按钮是目标元素，通过“基础定位”记录下的selector可能是“xxx > div:nth-child(2)”：

但在某次迭代后，在“导出”之前新增了一个“重置”按钮：

此时“xxx > div:nth-child(2)”定位到的就是“重置”按钮了。

这里我们会发现，常规css selector的描述能力似乎并不够，对于某个元素，你可以准确描述它的class，也可以准确描述它是当前层级中的第几个元素，但无法将二者结合，即无法描述“它是当前层级中class为xx的第几个元素”（前端界的“测不准原理”？声明：本文内容由网友自发贡献，转载请注明出处：【wpsshop】