使用屏幕截图来显示全屏外观，使用 OCR 来显示可见文本，使用图像匹配来显示已知的视觉目标。最强大的 Android 视觉测试将一项集中的断言与稳定的计时和失败证据结合在一起。
简短的答案：测试必须保持真实的事情
当整个屏幕、组件、间距、颜色或排版必须保持视觉一致时，请使用屏幕截图测试。当要求涉及人们可以看到的单词时，尤其是本地化或动态呈现的文本，请使用 OCR。当已知的图标、按钮、徽章或插图必须出现时，即使没有可靠的 UI 标识符，也可以使用图像匹配。
当需求是语义时，从 UI 选择器或辅助功能状态开始：控件存在、已启用、已选择或公开稳定标签。仅当目标属于视觉类并且可能对一个模板的大小或位置更改过多时才添加对象检测。这些方法是层，而不是竞争的测试框架。
- 询问什么证据可以让审阅者相信该要求已通过。
- 选择最窄的可靠信号，而不是默认比较每个像素。
- 在观察之前稳定屏幕，然后在断言失败时保存工件。
Android视觉测试方法比较
| 方法 | 最适合 | 主要弱点 | 有用的证据 |
|---|---|---|---|
| UI 或辅助功能状态 | 控件、标签、启用状态、选择、导航结构 | 自定义渲染或不可访问的元素可能对 UI 树不可见 | UI 层次结构、选定的属性、屏幕截图 |
| 屏幕截图或黄金图像 | 布局、间距、颜色、排版、组件外观 | 动态数据、动画、设备差异和渲染更改可能会产生嘈杂的差异 | 当前图像、批准的基线、视觉差异 |
| 光学字符识别 | 可见文本、本地化、收据、状态消息、呈现为像素的值 | 识别质量取决于裁剪、比例、对比度、语言数据、旋转和分割 | 源作物、识别的文本、置信度或结果列表 |
| 模板匹配 | 已知的图标、按钮、徽章、缩略图或小的稳定区域 | 主题、规模、压缩和重新设计可能会使模板失效 | 模板、搜索区域、最佳匹配、得分、屏幕截图 |
| 物体检测 | 当位置或大小发生变化时，其类别保持有意义的视觉对象 | 需要兼容的模型、标记的类、阈值和模型验证 | 模型版本、类别、边界框、分数、截图 |
Android 的官方屏幕截图测试指南描述了将当前渲染与批准的参考图像进行比较。 Appium 的图像插件公开了特征匹配、模板匹配和相似度比较。 OpenCV 记录了在图像上滑动模板的机制，而 Tesseract 记录了 OCR 预处理和页面分割的重要性。工具不同，但测试设计问题保持不变：什么观察结果证明了这一要求？
通过四个问题选择正确的断言
1. 需求是语义的还是视觉的？
如果测试显示“提交按钮已启用”，请首先检查 UI 状态。如果显示“字体更改后提交按钮未被裁剪”，请使用屏幕截图或重点目视检查。语义查询通常更容易维护，但它不能证明外观。
2. 确切的文本重要吗？
当需要面向用户的字符串并且文本无法通过 UI 树可靠地公开时，请使用 OCR。将识别限制在最小的有意义区域，选择正确的语言，然后比较标准化结果。保留屏幕截图，因为单独正确的 OCR 字符串无法显示截断、重叠或对比度差。
3.是否有一个稳定的视觉目标？
对已知图标或小控件使用模板匹配。紧密裁剪模板，在感兴趣的区域内搜索，并根据真实的正样本和负样本设置阈值。一个通用的阈值很难在不同的主题、分辨率和压缩的远程流中站稳脚跟。
4. 整个构图必须保持一致吗？
当许多元素之间的关系很重要时，请使用屏幕截图比较。控制字体、区域设置、设备配置、系统栏、时间、网络数据、动画和种子内容。如果无法控制这些输入，请屏蔽或裁剪动态区域，而不是接受永久的噪声测试。
构建一个有效失败的视觉测试
- 在授权设备或模拟器上将应用程序置于指定的启动状态。
- 等待稳定的情况，而不仅仅是固定的延迟。 UI Automator 提供稳定的等待，并且特定于应用程序的就绪信号甚至更好。
- 捕获包含所需证据的最小源区域。
- 运行一项主要断言：UI 状态、OCR、模板、检测或屏幕截图比较。
- 在采取下一步操作之前保存源图像和结构化结果。
- 出现故障时，停止或遵循经过审查的恢复路径。不要仅仅为了让测试继续进行而点击附近的相似者。
当目视检查授权转换时，它会变得更安全。观察当前状态，做出断言，仅在成功后执行允许的操作，并验证后置条件。这与图像识别自动点击指南中描述的设计原理相同：识别并不能证明工作流程已完成。
对于真实设备工作，用于移动应用程序测试的Android 屏幕镜像在设计测试时为审阅者提供实时视图。Android 自动化 QA 冒烟测试指南解释了如何保持重复检查的范围和可重复性。
三个实用的Android视觉测试场景
结帐屏幕上的本地化质量检查
使用 UI 状态导航到结账屏幕，使用 OCR 确认本地化的总计和操作标签，并使用聚焦屏幕截图来显示字符串没有被剪切或重叠。使用受控测试数据运行每个语言环境。单独的全屏像素比较对于翻译后的字符串长度过于敏感，而单独的 OCR 会错过布局损坏。
检查重新设计的工具栏图标
在小工具栏区域中使用接受图标的模板。当同时支持浅色和深色主题时，保留单独的模板。当匹配失败时，附上工具栏裁剪和最佳候选得分。如果故意重新设计图标，请检查并替换模板，而不是降低阈值，直到任何形状通过。
部署后的真实手机冒烟测试
从已知的帐户和应用程序状态开始，等待登陆屏幕，断言其身份，执行一项允许的操作，并验证下一个指定状态。每次失败时捕获屏幕截图。设备密度、权限对话框、键盘、通知和系统更新是真实手机环境的一部分，因此测试应该报告它们而不是隐藏它们。
常见误报故障及预防方法
| 症状 | 可能的原因 | 更好的反应 |
|---|---|---|
| 屏幕截图差异每次运行都会改变 | 时钟、动画、广告、种子数据、键盘、系统栏或网络内容 | 冻结输入，等待稳定，仅裁剪或遮盖动态区域 |
| OCR 返回看似合理但错误的文本 | 错误的语言、低对比度、微小的裁剪、旋转、噪音或不合适的分割 | 保存作物，提高比例和对比度，精心选择语言和分割 |
| 模板匹配仅适用于一部手机 | 不同的密度、主题、缩放、纵横比或压缩 | 使用感兴趣的区域和经过验证的模板来支持视觉变体 |
| 找到了正确的图像，但点击失败 | 匹配坐标未转换为当前屏幕或覆盖块输入 | 将识别与动作分开并验证下一个状态 |
| 测试在错误的屏幕上继续 | 无后置条件或失败边缘 | 指定预期状态并在当前屏幕超出审查路径时停止 |
| 对象检测器发现错误的类 | 模型或标签不适合应用程序域，阈值未验证 | 使用兼容的模型，记录版本和评分，测试负样本 |
关于 Android 回归测试的社区讨论通常会回到相同的维护成本：设备矩阵、不稳定的时序、基线审查和内容发生变化的屏幕。这些并不是放弃视觉测试的理由。它们是明确测试环境、可接受的方差和故障工件的原因。
莱彩 Flow 如何适应视觉测试
莱彩 Flow是 莱彩投屏 内部的自动化功能。流程可以结合屏幕截图捕获、UI 检查、OCR、模板匹配、对象检测、条件、操作以及明确的成功或失败转换。这使得测试人员可以将屏幕建模为一种状态，而不是将识别视为一种孤立的技巧。
使用莱彩 Flow Inside，部署后可以在电话上通过莱彩 Android Agent运行兼容的Profile。兼容性仍然取决于该配置文件使用的每个节点和资产。本地OCR使用Tesseract；模板匹配使用选定的图像资源和可配置的分数；兼容的本地检测使用受支持的模型。网络节点或远程模型仍然需要其自己的网络依赖性。
这并不意味着每个视觉测试都自动可靠。团队仍然需要代表性基线、模板、OCR 区域、模型、阈值、负面案例和后置条件。价值在于可以在一个工作流程中审查这些决策和转换。AI Android 自动化指南提供了更广泛的创作和真实设备执行视图。
视觉测试失败的最小证据包
- 测试名称、应用程序版本、设备型号、Android 版本、区域设置、主题和方向。
- 断言使用的源屏幕截图或裁剪区域。
- 预期的基线、模板、文本、类或 UI 属性。
- 观察到的差异、OCR 结果、边界框、匹配分数或 UI 值。
- 先前指定的状态、尝试的操作、预期的下一个状态和停止原因。
- 资产、模型或基线版本，以便审阅者可以重现决策。
没有此上下文的通过/失败标签会迫使下一个人重现整个运行。紧凑的证据包将失败转变为可审查的决策：修复产品、稳定测试、更新已批准的视觉资产或拒绝不受支持的设备配置。
Android 视觉测试常见问题解答
每个 Android UI 测试都应该包含屏幕截图吗？
不可以。当外观很重要或故障工件对审阅者有帮助时，请使用屏幕截图。语义断言通常更适合 UI 树可靠公开的行为。
OCR 比图像匹配更好吗？
OCR 回答有关可见文本的问题。图像匹配回答有关已知视觉模式的问题。如果要求包括标签及其外观，请使用 OCR 加上重点屏幕截图或模板检查。
截图测试可以在真实的 Android 手机上运行吗？
是的，但真实设备比受控的主机端渲染器或模拟器引入更多变化。记录设备配置，稳定系统 UI 和数据，并设置对您实际支持的设备矩阵的期望。
我什么时候应该使用对象检测？
当有意义的对象类移动或缩放超出稳定模板的容差时，并且仅当兼容模型已在应用程序的真实图像上得到验证时，才使用它。不要仅仅因为听起来更先进就添加检测器。
选择技术之前先选择证据
可靠的 Android 视觉测试始于一句话：审核者必须能够证明什么？选择用于语义的 UI 状态、用于合成的屏幕截图、用于文本的 OCR、用于已知视觉目标的模板匹配以及用于具有可变几何形状的经过验证的类的对象检测。
然后使观察成为状态转换的一部分：稳定、捕获、断言、仅在成功后才采取行动、验证后置条件并保留失败证据。这种设计比一组断开连接的视觉调用更容易理解，并且在应用程序或设备发生变化时更容易维护。