要点
- PWA 不是简单的网站：它们拥有特定的视觉状态（离线、独立模式、安装、启动画面），而标准 Web 测试会忽略这些状态
- 已安装的 PWA 的用户体验按原生应用的标准来评判，而非网站标准
- 视觉测试必须覆盖在线和离线模式之间的转换、独立模式渲染，以及启动画面和安装提示等特定元素
- 如果没有这些状态的视觉覆盖，你交付的看起来像原生应用，实际上却是一个有问题的网站
W3C 将渐进式网络应用（PWA）定义为*"一种使用现代 Web 技术——特别是 Service Workers、Web App Manifest 和 HTTPS——为用户提供可靠、快速和引人入胜的体验的 Web 应用程序，可直接从浏览器使用或在设备上安装后使用，体验可与原生应用相媲美"*（W3C，Web App Manifest 规范）。
这个定义在技术上是准确的。但它忽略了关键点：从用户角度来看，已安装的 PWA 不是网站，而是一个应用。它出现在 dock、任务栏和应用切换器中。它有自己的启动画面、自己的窗口、以及网络断开时的自有行为。
这正是问题所在。如果用户将你的 PWA 视为应用，他们就会按照应用的标准来评判它。但如果你只把它当作简单网站来测试，你就会让整个类别的视觉缺陷从裂缝中溜走。
PWA 拥有网站没有的视觉状态
在线状态：伪装的朋友
在线状态是每个人都会测试的。你的 PWA 在浏览器中，有稳定的网络连接，行为完全像一个普通网站。一切正常运行，一切正常显示，数据正常加载。
陷阱在于认为测试这个状态就足够了。这就像只在办公室 Wi-Fi 下测试移动应用就认为覆盖充分一样。在线状态是起点，不是终点。
离线状态：真正的成熟度考验
当 PWA 失去网络连接——或者用户在飞行模式下打开它——Service Worker 接管控制。缓存的页面从本地存储提供。未同步的数据在本地管理。需要网络的功能优雅降级。
从视觉角度来看，离线状态是一个雷区。以下是可能出错的地方，也是系统性地被忽略的地方：
未缓存的页面显示错误页。如果你的缓存策略没有覆盖所有路由，用户会看到空白页、浏览器错误或 fallback 页面。你设计过那个 fallback 页面吗？你视觉测试过它吗？在所有 viewport 上？
图片无法加载。你的缓存包含 HTML 和 CSS，但未缓存的图片显示破损的占位符、断裂链接图标，或更糟——破坏布局的空白空间。视觉测试是验证离线状态视觉可接受性的唯一可靠方式。
动态组件降级。需要实时数据的图表、新闻动态、嵌入式聊天——在离线模式下，这些组件必须显示明确且视觉一致的降级状态。不是无限旋转的加载器，不是空容器，不是技术错误消息。
网络状态指示器出现（或不出现）。如果你的 PWA 在页面顶部显示"您已离线"横幅，该横幅就是用户体验的一部分。它的外观、位置以及与布局其余部分的交互必须进行视觉测试。
启动画面：最初的毫秒很重要
当用户启动已安装的 PWA 时，他们看到的第一个画面不是你的主页。而是启动画面，由浏览器根据 Web App Manifest 数据（名称、图标、背景色）自动生成。
这个启动画面通常是设计中的"被忽视的孩子"。这是一个错误。它定义了每次启动时你的应用给人的第一印象。如果图标像素化、背景色与应用主题不匹配、文本被截断，用户会立即感受到一种割裂感，削弱信任。
启动画面特别棘手，因为它的外观取决于浏览器和操作系统。Android 上的 Chrome 生成的启动画面与 iOS 上的 Safari 不同。期望的图标尺寸不同。边距和居中处理方式也不同。你需要在目标平台上进行视觉截图。
安装提示：转化时刻
安装提示——邀请用户"添加到主屏幕"的横幅或弹窗——是一个关键的转化时刻。它相当于应用商店中的"下载"按钮。它的视觉外观直接影响安装率。
许多 PWA 使用自定义提示（通过拦截 beforeinstallprompt 事件）而非浏览器的原生提示。这个自定义提示是你应用的一个组件。它必须像任何其他组件一样进行视觉测试——在所有 viewport、所有主题、所有上下文中。
但原生提示因浏览器和版本而异。你无法控制其外观，但你可以控制其周围发生的事情：背景中的页面内容、元素的定位、提示将内容向下推时的行为。所有这些都值得视觉验证。
独立模式：没有浏览器 chrome 的界面
当你的 PWA 已安装并从主屏幕启动时，它以"standalone"模式打开：没有地址栏、没有标签页、没有浏览器导航按钮。应用占据所有可用屏幕空间（系统状态栏除外）。
这种环境变化有直接的视觉影响。
可用空间改变。没有地址栏，你的应用在高度上多出 50 到 80 像素。如果你的布局基于固定高度或 viewport 计算（100vh），standalone 与浏览器模式下的渲染可能明显不同。
安全区域发挥作用。在带有刘海或灵动岛的设备上，standalone 模式下的安全内容区域不同。定位在屏幕顶部或底部的元素（固定头部、导航栏、FAB）如果 safe area 处理不当，可能会被部分遮挡。
导航改变。没有浏览器的"后退"按钮（特别是在 iOS 上），你的应用必须提供自己的导航。如果用户在某个页面上无法返回，这就是一个重大的 UX 缺陷——视觉测试可以通过验证导航元素的系统性存在来检测它。
与系统状态栏的交互。你的状态栏颜色（在 manifest 中或通过 theme-color 元标签定义）必须与头部协调。白色头部配黑色状态栏会造成不美观的视觉断裂。
标准 Web 测试的问题
它们只测试一种状态
绝大多数测试套件——包括视觉测试——只测试浏览器中的在线状态。它是默认状态，最容易设置，也最稳定。但它也是最像普通网站的状态。
如果你只测试这个状态，你测试的是 PWA 最不严苛的版本。你在验证应用在理想条件下的运行。这是必要的，但不够。
它们忽略了 PWA 的生命周期
PWA 有网站没有的生命周期。安装、Service Worker 更新、后台同步、离线期后重新上线——每个转换都可能触发意外的视觉状态。
当 Service Worker 在用户使用应用时更新，可能出现"新版本可用——重新加载"横幅。该横幅的外观、位置、与内容的交互——所有这些都必须测试。
当应用在离线期后重新上线，数据同步。同步期间，界面可能显示加载状态、进度指示器、数据冲突。这些瞬态视觉状态经常被忽略，也经常是坏的。
它们无法重现独立模式上下文
在浏览器中全屏打开 PWA 与在独立模式下打开它不同。尺寸不同，safe area 处理不同，overscroll 行为不同。在 Chrome DevTools 中用模拟 viewport 运行的测试无法忠实重现已安装 PWA 的真实环境。
如何正确地对 PWA 进行视觉测试
绘制你的视觉状态图
在配置测试之前，明确列出 PWA 的所有视觉状态。至少应覆盖：
浏览器模式下的在线状态。这是你的标准 Web baseline。每个页面，每个 viewport。
独立模式下的在线状态。相同的页面，但在安装上下文中。检查与缺少浏览器 chrome 相关的布局差异。
离线状态——已缓存的页面。当用户在无连接时访问缓存中的页面，他们看到什么？数据完整吗？图片存在吗？
离线状态——未缓存的页面。当用户在无连接时访问未缓存的路由，fallback 页面视觉上是否正确？它是否提供回到缓存内容的路径？
从在线到离线的转换。离线横幅是否正确出现？动态组件是否优雅地视觉降级？
从离线到在线的转换。重新同步是否可见？更新的数据是否无视觉伪影地显示？
启动画面。在目标平台（Android Chrome、iOS Safari、Samsung Internet）上，启动画面视觉上是否正确？
安装提示。你的自定义提示（如果有的话）在所有上下文中视觉上是否正确？
自动化网络状态变化
要测试离线状态，以编程方式模拟网络丢失。Chrome DevTools Protocol 允许模拟离线，Playwright 等工具原生支持网络条件操控。
典型序列：在线加载页面，视觉验证，切断网络，重新加载或导航，视觉验证离线状态。该序列必须自动化且可重复。
无需物理设备测试独立模式
使用 Chrome 的"app"启动选项（无浏览器 chrome 的窗口）是最务实的方法。它与真正安装的 PWA 不完全相同，但足够接近以检测与缺少地址栏相关的布局回归。
对于 safe area，视觉验证使用 env(safe-area-inset-top) 或 env(safe-area-inset-bottom) 定位的元素，使用与目标设备匹配的值。
iOS 特殊性：另一个世界
明确地说：iOS 上的 Safari 是 PWA 问题最多的浏览器。而它可能是对你的用户最重要的平台。
尽管自 iOS 16.4（为 PWA 引入了推送通知）以来取得了重大进展，Safari 在 PWA 支持方面仍然落后于 Chrome。启动画面处理方式不同。独立模式有特定行为。Viewport 和 safe area 处理更严格。
这意味着你的视觉测试必须将 Safari iOS 作为明确目标，而非事后补充。同一 PWA 在 Chrome Android 和 Safari iOS 之间的渲染差异往往是实质性的和令人惊讶的。
根据 StatCounter 2025 年的数据，Safari 约占全球移动浏览器市场的 27%。忽略其 PWA 特殊性意味着忽略你四分之一的潜在用户。
Delta-QA 为 PWA 带来什么
Delta-QA 通过其 no-code 方法大大简化了 PWA 视觉测试。你不需要编写脚本来模拟 PWA 的不同状态——你可以可视化地配置场景。
Delta-QA 在不同 viewport 上测试的能力对 PWA 特别相关，PWA 必须在独立模式的智能手机屏幕和浏览器中的桌面屏幕上同样良好地工作。一个工具覆盖整个范围。
由于 PWA 更新频繁（更新是透明的，无需通过应用商店），测试节奏必须很高。将 Delta-QA 集成到你的 CI/CD pipeline 中，确保每次部署在到达用户之前都经过视觉验证。
常见问题
标准视觉测试对 PWA 来说不够吗？
不够。标准视觉测试覆盖浏览器中的在线状态。对于 PWA，这对应于真实用户体验中最不具代表性的状态。离线状态、独立模式、启动画面、安装提示——这些是 PWA 特有的视觉状态，标准 Web 测试会忽略它们。如果你只测试在线状态，你就把大多数 PWA 视觉风险留在了覆盖范围之外。
如何在自动化测试中模拟离线状态？
你可以使用 Chrome DevTools Protocol (CDP) 功能以编程方式模拟网络丢失。Playwright 等测试框架为此提供了原生方法。典型序列：正常加载页面，通过 API 切断网络，然后导航或重新加载以观察离线行为。在每个步骤截图进行视觉测试。
我的 PWA 需要支持离线才能证明特定的视觉测试合理吗？
即使你的 PWA 不支持离线工作（"network only"策略），你也需要测试网络不可用时会发生什么。用户会看到某些东西：空白页、浏览器错误或你的 fallback 页面。无论是什么，该视图都是用户体验的一部分，值得进行视觉测试。
测试 PWA 和测试原生移动应用有什么区别？
测试原生应用需要每个平台特定的模拟器或物理设备（iOS Simulator、Android Emulator）。PWA 测试在很大程度上可以用配置了正确 viewport 的桌面浏览器进行，使其更易访问且更快。然而，某些方面（启动画面、safe area、iOS 上的独立模式行为）需要在真实或接近真实的环境中验证。
没有物理设备如何测试启动画面？
没有设备或模拟器无法测试真实的启动画面，因为它是由浏览器在已安装的 PWA 启动时生成的。但是，你可以测试其组件：视觉验证 manifest 图标在所有所需尺寸上是否正确，背景色是否一致，apple-touch-startup-image 资源（用于 iOS）是否存在且质量良好。
在有应用商店的 2026 年，PWA 还有意义吗？
绝对有。根据 web.dev (Google) 的研究，PWA 的转化率比标准移动网站高 36%，主要得益于加载速度和离线体验。随着 iOS 上 PWA 支持的持续改善以及欧盟对 iPhone 上第三方浏览器的开放（Digital Markets Act），PWA 在 2026 年比以往任何时候都更有意义。
延伸阅读
你的用户不会区分 PWA 和原生应用。他们看到主屏幕上的图标，点击它，期望一切正常运行——无论有无网络，无论有无浏览器栏，配上专业的启动画面和流畅的过渡。
如果你开发了 PWA 却像网站一样测试它，你就背叛了提供"添加到主屏幕"选项时做出的承诺。PWA 是应用。像应用一样测试它们。