如何使用Playwright视觉测试防止白标业务中的品牌泄露

📝 面试求职： 「面试试题小程序」 ，内容涵盖 测试基础、Linux操作系统、MySQL数据库、Web功能测试、接口测试、APPium移动端测试、Python知识、Selenium自动化测试相关、性能测试、性能测试、计算机网络知识、Jmeter、HR面试，命中率杠杠的。（大家刷起来…）

📝 职场经验干货：

软件测试工程师简历上如何编写个人信息（一周8个面试）

软件测试工程师简历上如何编写专业技能（一周8个面试）

软件测试工程师简历上如何编写项目经验（一周8个面试）

软件测试工程师简历上如何编写个人荣誉（一周8个面试）

软件测试行情分享（这些都不了解就别贸然冲了.）

软件测试面试重点，搞清楚这些轻松拿到年薪30W+

软件测试面试刷题小程序免费使用（永久使用）

---

想象一下，用户在某家银行的旅游门户网站上，突然看到本属于另一个品牌的功能、标识或配色。这不仅仅是一个小故障，而是一个被称为“品牌泄露”的严重问题。

在 Agoda（安可达），我们提供白标服务，允许其他网站或门户（如银行）使用安可达的后端系统提供旅游服务，同时保持自身的品牌标识。每个白标都有独特的需求和定制。然而，当为一个白标设计的功能意外出现在另一个白标或安可达自身平台上时，就会导致我们所说的“品牌泄露”。

潜在的品牌泄露问题包括：

• 跨品牌功能泄露——Agoda 特有的功能出现在白标门户网站中。
• 主题错位——不正确的主题破坏了视觉识别。
• CMS 不匹配— 由于 CMS 应用程序不正确而显示错误的内容。
• 标志/名称混淆——用户看到其他品牌的标志或名称。
• 组件不一致——缺少、重复或不正确的 UI 组件。

这些问题可能会损害用户体验、损害品牌完整性并削弱信任。在本文中，我们将探讨如何利用Playwright的视觉测试功能来检测和防止品牌泄露。读完本文后，大家可以了解如何实施强大的视觉测试策略，以维护特定品牌的定制。

为什么低级别测试无法发现品牌泄露

虽然单元测试 (UT) 和其他低级测试对于确保代码质量至关重要，但它们不足以检测品牌泄漏。这些测试主要关注功能、逻辑和单个组件，但品牌泄漏是 UI 级别的问题，通常涉及多个组件和配置。原因如下：

• 单元测试仅限于单个组件：
• 单元测试在较低级别运行，旨在验证单个组件（例如搜索框或按钮组件）的功能。然而，品牌泄露通常涉及多个组件的协同工作，而单元测试无法完全捕捉这些组件的功能。
• 复杂功能影响多个组件：

  
  例如，结账流程之类的功能通常很复杂，会影响多个需要考虑的组件。低级测试无法有效地模拟这些组件之间的交互。

• 行为测试与功能测试：

  
  我们有多个存储库，这些存储库内的测试专注于行为，这些行为是功能的包装器，而不是直接在组件级别测试功能。

• 模拟行为的挑战：

  
  开发者可以编写模拟行为来模拟原始功能，但几乎不可能覆盖来自白标服务的所有白标的所有配置。这种限制使得确保全面覆盖变得困难。

• 行为在组件间重复使用：

  
  行为通常在多个组件间共享，因此很难精确定位某个行为的所有使用位置。这种复杂性增加了遗漏品牌泄露问题的风险。

出于这些原因，UI 测试或端到端测试至关重要。它们能够提供功能在整个应用程序中运行情况的整体视图，使其成为检测品牌泄露的最佳方法。

Playwright视觉测试概述

为了有效防止品牌泄露，我们不仅需要验证应用程序的运行方式，还需要验证其外观，这就是视觉测试的意义所在。

视觉测试是质量保证的关键组成部分，它确保 Web 应用程序不仅能够正常运行，而且在不同浏览器和设备上也能达到预期效果。在 Agoda，我们使用Playwright来实现这一目标，事实证明，它是一款强大的工具，能够检测出传统测试框架所遗漏的视觉回归问题。

Playwright 视觉测试的主要特点：

• 屏幕截图灵活性：Playwright 可以捕获整页、视口或特定元素的屏幕截图，让测试人员专注于特定区域或评估页面的整体视觉完整性。
• 逐像素比较：Playwright 可以检测到哪怕是最小的视觉差异，确保更新过程中的视觉一致性。
• 阈值定义：测试人员可以定义视觉差异的可接受阈值，减少误报并关注显著的回归。
• 组件遮罩功能：Playwright 可以在整页截图中遮罩已定义的组件。虽然此功能的主要用途是隐藏广告等动态组件，但我们将利用它进行页面布局测试。

这些功能使 Playwright 成为检测品牌泄漏的理想工具，即使是轻微的视觉不一致也可能预示着问题。

我们检测品牌泄露的方法

我们使用视觉测试作为发现品牌泄露问题的最有效方法。通过在受控的 QA 环境中专注于 UI 变更，我们可以确保测试的稳定性和准确性。

测试环境

• QA 环境：所有测试均在 QA 环境中运行，与生产环境隔离。这使我们能够模拟品牌场景，而无需担心实时数据或外部依赖关系。
• 模拟 API：大多数 API 都经过模拟，以确保测试稳定性，并专注于 UI 变化。这使我们能够将 UI 级别的更改与后端的波动隔离开来，因此，只有当渲染输出中出现真正变化时，我们的可视化测试才会失败。

我们想要寻找什么样的错误？

• 组件级泄漏：组件内的品牌泄漏，即视觉元素出现在不应该出现的地方或未能出现在应该出现的地方。
• 页面级泄漏：整个页面的品牌泄漏，其中显示了不属于白标的组件、缺少预期的组件或多次显示了组件。

测试自动化工作流程

我们构建了一个基于Playwright的自动化工作流程，确保快速、可重复且具有品牌意识的UI验证。流程如下：

步骤1：模拟API调用

我们模拟进入测试页面所需的所有关键 API 调用，例如：

• 主页
• 搜索页面
• 属性页
• 预订表格

这确保了一致的测试结果，并允许我们模拟各种没有后端依赖的场景。

步骤2：打开浏览器并导航到测试页面

使用 Playwright，我们启动浏览器会话并以编程方式导航到测试页面。

步骤3：组件截图

我们会截取各个组件（例如，客户详情表单、价格详情面板）的屏幕截图，并将其与特定白标组件的基准屏幕截图（称为“黄金镜像”）进行匹配。黄金镜像会在首次测试运行期间自动生成，并作为后续测试执行的参考。这种精细的方法可确保每个组件的视觉状态都得到独立验证。

注意：全页面视觉测试通常非常不稳定，因为即使是微小的变化，例如单个像素的偏移、字体渲染差异或动态内容，也可能导致整个页面屏幕截图出现差异，从而导致误报和测试失败。这些细小且不相关的变化可能会使识别真正的问题变得困难。因此，我们会比较各个组件的屏幕截图，这是一种更加稳定的方法。这使我们能够根据每个组件的复杂度对其应用差异阈值限制，从而使测试更加可靠且易于维护。

在下面的示例中，我们发现了一个问题，由于错误，白色标签的价格组件布局发生了变化。

预期组件截图

从Playwright组件测试中捕获的图像

步骤4：带组件遮罩的全页面截图

除了组件级测试外，我们还会截取整页屏幕截图，并屏蔽之前识别出的组件。这有助于检测可能影响布局和用户体验的意外更改或新元素。屏蔽功能有助于提高测试的稳定性，让我们只关注组件是否存在，而不是其内容。

在虚拟应用程序中模拟品牌泄露

为了验证我们的视觉测试策略并安全地试验品牌泄漏场景，我们创建了一个虚拟的白标应用程序，在受控环境中模拟现实世界的问题。

我们的虚拟应用（GitHub 链接）演示了白标概念，其中有两家银行：银行 A 和银行 B，每家银行都有独特的品牌、功能和布局。为了模拟品牌泄露场景，我们使用了“simulateLeakage”标志（在 App.tsx 文件中）。设置为 true 时，此标志会引入一些故意为之的错误，例如：

• 标识泄露：两家银行都展示了A银行的标识，尽管B银行应该展示B银行的标识。
• 货币泄漏：两家银行都显示货币A（USD），尽管银行B应该显示货币B（PHP）。
  • 独有组件泄露：原本仅供银行A使用的独有功能组件错误地出现在银行 B 的页面上。

为了发现这些品牌泄露问题，我们利用了 Playwright 的视觉测试功能。通过截取并比较各个组件和完整页面布局的屏幕截图，我们可以检测到由泄露引起的意外视觉变化或不一致之处。

A银行布局（原件）

B 银行布局（原始）

B银行布局（品牌泄露后）

组件截图实用程序（工具）

为了确保白标体验中的品牌一致性，我们实施了一个使用 Playwright 执行组件级视觉验证的实用程序。

此工具会截取特定 UI 组件的屏幕截图，并将其与基准（“黄金”）图像进行比较，以检测视觉回归或意外的样式更改。它旨在在验证特定品牌的 UI 元素时提供精确性、稳定性和灵活性。

该工具使用以下参数运行：

• Playwright页面对象
• 用于识别组件的定位器
• 屏幕截图的名称
• 可选的 maxDiffPixelRatio，定义允许的视觉差异阈值（默认为严格的 0.00）

在底层，它执行一系列步骤：

• 边界框计算：该实用程序检索组件在页面上的位置和大小。它还会考虑滚动偏移量以计算精确的坐标。
• 屏幕截图捕获：捕获组件精确边界框的屏幕截图。
• 视觉比较：使用Playwright将捕获的图像与基线进行比较，
  expect.soft(page).toHaveScreenshot允许根据提供的阈值出现细微的视觉差异。
• 缺少组件处理：如果无法确定边界框（例如，组件未渲染），则测试会提前失败，表明存在渲染错误或品牌配置错误。

这种组件级方法对于发现细微的品牌泄漏问题至关重要，例如：

• 标识或主题不正确
• 组件放错或缺失
• 在不同品牌环境下表现不同的共享组件。

全页截图实用程序（工具）

为了补充组件级视觉测试，我们还通过全页面截图对比来验证整体页面布局。这有助于我们检测并非局限于单个组件的品牌泄露问题，例如缺失部分、重复模块或错位元素等破坏品牌体验的问题。

参数

布局比较实用程序接受以下输入：

• page：代表测试的浏览器上下文的 Playwright Page 对象。
• maskedLocatorList： Playwright Locator 对象列表，用于标识在截取屏幕截图之前需要进行视觉屏蔽的组件。
• screenName：用于生成用于存储和检索屏幕截图的一致文件名的字符串。

工作原理

• 页面准备：页面滚动到顶部并等待domcontentloaded事件触发，确保在截取屏幕截图之前所有 DOM 元素都已加载。
• 参考截图：首先截取一张未加任何遮罩的全页面截图。该截图将作为视觉参考保存，并可附加到测试工件上进行调试。
• 遮罩截图：在视觉上遮罩指定组件后，再截取第二张截图。这些组件通常包含与布局测试无关的动态或品牌无关的 UI 部分。在我们的案例中，所有主要组件均已遮罩，因为我们只关注结构布局的一致性。
• 基线比较：使用屏蔽屏幕截图与基线图像进行比较，expect.soft(fullPageScreenshot).toMatchSnapshot method.比较允许指定的阈值和最大像素差异比，确保细微的差异不会导致测试失败。

我们如何发现品牌泄露

通过结合组件截图实用程序和整页截图实用程序，我们可以检测虚拟应用中的品牌泄露问题：

1. 1.组件级测试：

• 将各个组件（例如，货币、独家功能）的屏幕截图与其基线快照进行比较，以检测视觉不一致。
• 例如，如果独家功能出现在银行 B 的页面上，则测试将失败。

2. 全页布局测试： 

• 将经过遮罩的全页截图与基线图像进行比较，以确保整体布局保持一致。
• 例如，如果两家银行都因泄漏而显示货币 A（美元），则测试将突出显示差异。

这些实用程序提供了一种强大的机制，用于保留特定于品牌的定制并在开发过程的早期捕获意外的视觉变化。

测试文件看起来是这样的：

处理实际的屏幕截图变化

在某些情况下，组件设计可能会发生变化，或者页面中添加了新的 UI 元素。在这种情况下，视觉测试可能会失败——失败的原因并非 bug，而是因为当前的屏幕截图不再与基准线匹配。

为了解决这个问题，我们只需在同一个合并请求中更新黄金屏幕截图：

npx playwright test — update-snapshots

更新后，新的截图将成为未来测试的参考。无需进行其他更改。

结论

品牌泄露在白标服务中是一个严重的问题，但通过正确的工具和方法，可以有效地管理它。由于功能的复杂性及其在组件间的交互，单元测试等低级测试不足以检测品牌泄露。Playwright的视觉测试功能为检测和防止品牌泄露提供了强大的解决方案。通过遵循结构化的测试工作流程，可以确保功能保持特定品牌的特性，维护用户信任和品牌完整性。享受测试！

最后： 下方这份完整的软件测试视频教程已经整理上传完成，需要的朋友们可以自行领取【保证100%免费】

​

​​​