有赞页面级E2E测试探索-页面比对

作者：高祺

部门：电商测试

前言

页面级测试是Web测试中的重要组成部分，它主要关注用户界面的展示、交互以及用户体验，在有赞以及整个业界，页面级测试往往涉及复杂的用户交互，这使得自动化测试面临很大挑战，部分工具如Selenium虽然可以模拟用户行为，但是维护成本高，随着页面功能和布局的频繁变化，维护测试脚本的成本也越来越高，且容易受前端页面变更的影响导致执行失败。

页面比对思路定位为一种视觉回归工具，用于捕获页面的屏幕截图进行比较，以检测页面在不同时间点之间的变化。相比其他UI工具Selenium、Cypress（用于模拟用户操作与页面进行交互，验证页面的功能是否按照预期运行）等，解决需要人工设置断言的问题，更聚焦在前端样式交互上。因为页面比对主要关注页面外观，避免了复杂的交互逻辑，所以维护成本更低，由于核心逻辑是捕获run的过程中页面变化的截图比对，相对UI自动化测试框架，执行速度取决于测试脚本的编写质量和所模拟的操作复杂程度，会相对比较耗时。综上所述，页面比对的思路是传统UIA的一种补充，聚焦前端交互，样式回归。

一、有赞页面级E2E质量策略

目前有赞在前端质量保障方面主要的手段包括，UITest自动化（用于回归交互类问题），云测（用于小程序主流程交互类回归）、手工测试（用于保障前端页面展示），UITest和云测最大的问题在于，不稳定，维护成本较高、且在静态页面方面只有设定的场景支持差异比较，很容易遗漏或者忽略部分场景，基于此页面比对工具变得尤为重要。

在电子商务领域，各个核心业务模块（如商品、交易、营销、会员和企助等）都涉及众多多样化的页面场景。以商品为例，同一个商品的详情页面可能会因为不同的促销活动而展现出不同的布局和内容。这些页面通常包含大量的功能点，而传统的人工测试方法很难全面覆盖并识别所有功能点的细微差异，这容易导致测试场景的遗漏，甚至造成资损。随着公司业务的快速扩展，为了有效支持业务的持续迭代，提供更加稳定和高效的测试保障能力是至关重要的。在此过程中，业务架构的重构、项目发布、大巴车发布、日常发布、前端中台化的改造升级以及页面品牌风改造都对测试工作提出了更高的要求。

为了应对这些挑战，页面比对工具，在有赞电商的各个业务领域中扮演了关键角色。页面比对以自动化的方式，通过预发环境和线上环境执行同一页面地址，截图相同时刻同一地址截图，比较渲染页面是否存在差异，帮助团队快速验证现有业务流程，确保在业务架构调整和前端改造过程中，页面的功能和表现保持一致。页面比对工具的使用显著提高了测试的覆盖率，降低了因为重复测试而产生的成本，为项目提供了强有力的支撑。

二、静态页面比较工具调研

综上区别，选择BackstopJS，考虑如下几点

• 易于上手：BackstopJS以其简洁的配置和直观的命令行界面，让新手和经验丰富的开发人员都能快速开始使用。
• 专注于视觉：与市场上其他多功能测试工具不同，BackstopJS专注于视觉回归测试，确保每次改动预发和线上页面保持一致。
• 免费且开源：作为一个开源项目，BackstopJS开源免费，没有额外的授权费用。
• 技术栈无关性：BackstopJS不依赖于特定的编程语言或框架，使其成为任何技术栈的理想选择。
• 现代化的浏览器支持：通过Puppeteer，BackstopJS支持最新的Chrome和Firefox浏览器。
• 高效的测试流程：BackstopJS的测试流程高效且易于集成到现有的CI/CD流程中。
• 灵活的配置选项：从简单的截图比较到复杂的场景配置，BackstopJS提供了丰富的配置选项，以满足特定需求。
• 清晰的报告：BackstopJS生成的报告直观易懂，能够快速识别和解决视觉差异。

三、静态页面比对实现方式

页面比对实现是基于BackStopJS提供的部分能力进行二次开发，通过聚合BackStopJS对外功能，进行线上和预发，线上和线上不同场景的页面比较，实现多种场景的巡检回归，页面比对运行示意图如下。

3.1 核心功能

• 用例管理能力-维护每个页面场景的最小执行单位
• 场景管理能力-对用例进行聚合，方便执行一类问题
• 标签管理能力-对特性场景打标能力，后期支持分类分析和过滤
• 执行集&报告能力-对一类要执行的用例和场景进行汇总，并以报告的形式体现，直观观察执行接口，并实时推送结果到执行人。
• 选择器管理-对用例配置的CSS定位元素，进行统一管理，方便后边前端能力变化导致的维护成本升高
• 快速批量配置元素能力-应对预期内页面比对失败进行全局配置的快速恢复手段能力

3.2 整体架构图

3.3 页面比对核心功能介绍

1. 用例管理——准备阶段
   1. 用户进行用例录入，通过页面url即可完成，简单便捷，无需维护前端多变的css命名变化和元素位置变化
2. 选择器管理——特定场景
   1. 对于前端多变的元素变化，特殊用例可能会针对前端的元素有对应操作（隐藏，点击）等，将共同的元素抽离，通过用例引用选择器，降低前端元素变化后，海量用例只需要改动选择器属性值即可
3. 执行集&报告管理——执行阶段
   1. 将用户选定的组合场景，汇总到执行集合里边，通过执行集合，统一执行调度
   2. 执行集执行完成后，单独以报告的形式展示，方便用户查看执行结果。

总得来说，在用户交互上，基于用例、执行集、报告等能力的结合，单条用例根据配置自动完成，预发<->线上，线上<->线上的页面切换，自动完成截图比较，结果差异展示等。

3.4 页面比对平台和BackStopJS组件的部分交互代码

1. 传入BackStopJS的配置文件

1. 执行BackStopJS比对，生成对比图片的命令代码，只需要传入配置json，并调用reference和test两个命令即可

四、页面比对在有赞的应用

4.1 电商业务实际应用效果

• 实际应用情况

在电商的各个主要业务领域，页面比对工具已经成为前端发布流程的一个关键环节。无论是在项目迭代、技术改进还是常规的日常发布中，页面比对都是一个必不可少的卡点环节。我们通过这个工具来确保每次发布后，页面的显示效果与预期一致。一旦发现问题，我们会迅速进行核查和修正。此外，为了保持测试案例的时效性和准确性，我们不断地对其进行更新和优化，用例持续保鲜。

目前，我们的页面比对主要在电商域应用，用例1000+，节省300人日/年（相当于多招了1.5个人），帮助我们在前端发布过程中发现并拦截了100+潜在的低危&严重问题。接下来会持续覆盖商品、交易、会员、营销、装修、分销员、CRM、群团团、商赋、跨境、企助、账号等多个业务域。

随着用例的增加，更多业务域的接入，相信效果会进一步凸显。随着用例量的增加，产品的验收从“造场景”->“看场景”，直接打开页面比对验收即可，所见即所得。如商详页+营销活动商详页的场景，用例量远远超出产品验收预期。页面比对在电商测试中的广泛应用，对提升整个端的测试和发布流程的质量保障起到了关键作用。

• 真实应用场景举例

1. 权益卡C端页面开放能力改造，需要对权益卡展示页面的实现方案进行整体改造（不改变页面展示样式的前提），需要归回的场景如下：

1. 如上场景，通过页面比对工具，只需要跑一遍相关用例即可，无需人工介入（需要前置录入相关页面）
   1. 如上场景，页面比对发现问题case-改动导致页面渲染数据丢失，Fail

   

   

   1. 付费权益卡执行成功case-改动对当前页面无影响场景，Pass

   

• 维护成本

因为页面比对主要关注页面外观，避免了复杂的交互逻辑，页面url一般不会有啥变化，所以维护成本更低、只需要维护前端功能点的url即可（如果想支持一些点击事件，只需要增加CSS定位页面元素即可，css样式一般也不会有太大变化，为了应对这一变化，可以将点击事件的选择器抽离为公共配置，多个用例引用同一份配置即可降低CSS选择器的维护成本）

4. 2 页面比对操作及效果展示

操作展示

第一步、通过页面url创建用例，填写名称和场景值即可

第二步、比对规则，模板自动生成，只需要小改部分内容即可（无需添加部分按钮点击事件。则无需改动）

第三步、页面比对工具执行方式

执行方式1：一键手动执行，自定义执行环境

执行方式2：大巴车自动执行

效果展示

1. 后端数据差异导致展示不一致Fail（粉色部分代表比对失败-有差异）

1. 页面渲染失败异常Fail（粉色部分代表比对失败-有差异）

1. 前端渲染问题导致的页面差异Fail（粉色部分代表比对失败-有差异）

五、未来展望

能做什么

1. 项目、日常等发布非相关页面和相关页面的巡检
2. 前后端发布的质量门禁卡点
3. 前端组件技改的页面场景回归
4. 日常线上页面能力巡检等等，还有很多其他场景就不一一列举了

不能做什么

1. 小程序页面巡检回归--正在规划中
2. 无法完成复杂的页面交互行为，只能部分场景替代

综上

1. 目前，页面比对工具主要支持Web页面的视觉回归测试，但对于小程序场景的测试覆盖还存在一些局限性。这主要是因为微信环境下对小程序截图功能的限制。为了解决这一问题，我们计划与第三方合作伙伴协作，这些合作方提供真实的设备模拟，能够进行小程序、多端用户界面的自动化回归测试。通过这种方式，我们可以获得小程序各个操作流程的截图，进而实现对小程序的全面测试覆盖。
2. 此外，我们还将致力于提升页面比对工具与主流前端框架（例如React和Vue）的兼容性和集成度。这将使得工具能够支持在组件级别的视觉回归测试，从而进一步提高测试的精细度和准确性。
3. 同时，我们会探索将页面比对工具与用户界面(UI)操作流程和实时流量回放技术相结合的可能性，基与前端样式的流量录制回放。这样，页面比对不仅能够对静态页面快照进行比对，还能监控和分析用户与页面交互时产生的动态变化。这将有助于我们更全面地捕捉和识别页面在实际使用中可能出现的问题，为业务提供更加稳定、高效的质量保障。

六、遇到的问题及如何解决

问题1：前端页面元素持续变化

针对前端页面元素频繁变动导致的测试用例执行失败问题，页面比对工具采取了一种策略，即把所有用例的选择器逻辑单独抽离出来。

通过这种方式，当页面元素发生变化时，只需要在一个地方更新选择器，就能实现所有相关用例的同步更新，从而显著降低了因页面变动导致的维护成本。

问题2：比对工具&持续集成

此外，为了解决页面比对工具与OPS大巴车（一种持续集成和持续部署的平台）执行流程之间的脱节问题，页面比对工具进行了优化，实现了与OPS大巴车的无缝对接。

现在，用户可以在OPS大巴车平台上一键触发页面比对工具的执行，工具会自动完成测试用例的运行，并将结果反馈回平台，从而简化了整个流程，提高了工作效率。

问题3：项目改造大面积预期内的失败

对于页面比对工具在项目改造中可能出现的预期内失败用例，这些用例可能会干扰真实问题用例的识别。

为了减少这种误报，页面比对工具提供了批量修改用例的功能，允许用户隐藏在页面改造中预期会变动的元素，这样就能更准确地识别和关注那些真正因代码更改而产生的问题。

另外，页面比对工具还面临其他挑战，例如如何实现多环境的比对测试，如何支持特定的测试环境（如sc环境），以及如何处理特定平台（如有赞CAS）的登录限制，还有用例执行过程中性能等。这些问题都需要工具的开发者和使用者共同努力，通过技术创新和流程改进来解决。随着工具的不断迭代和优化，相信这些问题都将得到有效的应对。

参考资料：

1. https://github.com/garris/BackstopJS
2. https://gitcode.com/obfuscurity/backstop/overview?utm_source=artical_gitcode

‍

‍