安卓设备实验室自动化：真实设备与模拟器 QA 流程

将少量 安卓手机和模拟器转变为可重复的设备实验室，具有明确的启动状态、可观察的检查、有限的等待、故障证据以及明确的构建与购买规则。

简短的答案：自动化操作循环，而不是货架

当每次运行都从指定状态开始、执行一次有界检查、验证后置条件并留下其他人可以查看的证据时，Android 设备实验室就会变得有用。电话、USB 集线器、支架和标签只是物理层。 Android 设备实验室自动化是一个操作层，它将这些设备转变为可重复的发布、支持和本地化检查。

如果您仍在选择电话、电缆、电源或存储，请从低成本 Android 设备实验室设置指南开始。本文从硬件存在之后开始。它解释了如何结合真实设备和模拟器、定义小型测试矩阵、创建设备运行卡、同步可观察状态、捕获屏幕截图和日志，以及确定托管设备云何时是更好的选择。

目标不是取代单元测试、Compose 测试、Espresso、UI Automator、Appium、Gradle 托管设备或 Firebase 测试实验室。这些工具拥有不同的边界。AI Android 自动化工具在这里最有用，作为操作员、QA 审核人员和支持团队需要理解的实际设备检查的可见工作流程层。

为真实设备和模拟器提供不同的工作

设备实验室不需要对每台设备进行所有测试。仿真器可以快速创建、重置、参数化和并行运行。真实手机会暴露虚拟设备可能无法忠实再现的供应商固件、物理摄像头、蓝牙、生物识别提示、热行为、背景限制、通知传递、USB 状态和输入表面。利用这些差异来划分责任，而不是争论一个通用平台。

实用的入门模式是宽的虚拟层和窄的物理层。跨虚拟配置运行快速确定性检查，然后通过为实际客户风险选择的两到三部真实电话路由一个小型关键包。仅当故障数据显示其他型号、Android 版本、区域设置或供应商行为更改了结果时才展开。

定义一个设备矩阵，每行一个原因

Firebase 测试实验室将测试矩阵描述为所选设备和测试配置的组合。这个想法也适用于当地实验室，但矩阵应该基于风险而不是详尽无遗。每一行都需要一个理由、一个所有者和一个预期的决定。一款仅仅因为可用而存在的手机将悄悄消耗充电、重置和维护时间，而不会提高发布信心。

• 为主要发布路径保留一个当前的 Android 基线。
• 保留一个较旧的受支持 API 级别以实现兼容性和升级行为。
• 仅当其固件、权限、电池策略或客户份额产生明显风险时，才添加一部特定于供应商的真实手机。
• 当布局和可访问性很重要时，添加小屏幕或高字体比例配置。
• 仅将区域设置、主题、方向、网络或帐户状态添加到其结果在该条件下可能发生变化的检查中。
• 淘汰不再发现明显缺陷或支持当前客户群的矩阵行。

命名每行支持的决策：阻止发布、收集审查证据、重现支持案例或探索可疑的设备特定故障。该决定控制行需要多少可靠性、隔离性和报告。与受监督的探索性检查相比，发布阻止程序需要更强的重置和断言规则。

在编写自动化之前创建运行卡

实验室检查的最小有用规格是运行卡。它可以防止隐藏的假设存在于操作员的记忆中，并为自动化提供稳定的契约。在选择节点、选择器或框架代码之前，用可观察的术语编写卡片。

不要将成功定义为一系列点击。定义序列之后必须存在的可见或结构化状态。 UI 布局发生变化；业务后置条件更加持久。登录检查成功是因为存在预期的帐户状态和主界面，而不是因为自动化点击了按钮原来所在的坐标。

重置状态而不删除证据

共享设备的失败方式看起来像是应用程序缺陷：过时的帐户、缓存的同意、待更新、更改的权限、存储空间不足、意外的键盘、打开的系统对话框、通知覆盖或结账时中途留下的上一次运行。仅重置运行卡指定的状态，并在恢复更改之前捕获故障。

1. 在接触状态之前识别设备并构建。
2. 当上一次运行意外结束时捕获当前屏幕。
3. 使用破坏性最小的重置将应用程序返回到声明的启动状态。
4. 确认网络、时间、存储、方向、区域设置、字体比例和所需的权限。
5. 在第一个业务操作之前验证开始状态标记。
6. 如果多次重置失败，则隔离设备；不要将基础设施故障转化为产品错误。

全面擦拭并不会自动变得更安全。它可能会破坏重现缺陷所需的确切状态，并增加设置时间，从而鼓励团队跳过检查。当全新安装、升级安装、登录、注销和恢复帐户路径存在不同风险时，请为这些状态保留单独的配置文件。

同步状态而不是休眠更长时间

Android 的测试稳定性指南警告不要任意睡眠，因为设备性能和异步工作各不相同。对于繁忙的电话来说，固定延迟可能会太短，而对于快速电话来说，固定延迟可能会过慢。首选显式等待有意义的条件，并在该条件从未出现时超时和失败工件。

• 应用程序启动后，等待稳定的 UI 元素或屏幕状态，而不是猜测的秒数。
• 点击后，在发送下一个输入之前验证后置条件。
• 对真正需要民意调查的州使用有限重复；记录超时的最终观察结果。
• 将系统权限对话框、更新提示和 OEM 覆盖视为命名分支，而不是随机噪音。
• 当可见状态超出批准集时停止，尤其是在付款、删除、同意或帐户更改之前。

目前的莱彩 Flow合约遵循这个可视化模型：UI观察、OCR、模板匹配、屏幕截图观察状态；输入节点和指针节点执行一项操作；流节点处理等待、分支、有界循环、子流、返回和停止。将观察、决策和行动分开可以使工作流程更易于审查且更安全地维护。

构建可读的 莱彩 Flow 用于实验室检查

莱彩 Flow 是 莱彩投屏 内部的自动化功能。对于设备实验室运行，请将主流程保持在 QA 审核员可以阅读的级别：准备设备、打开目标、运行关键检查、收集证据并完成。将多步骤技术细节放入小型子流程中，而不是暴露一长串匹配、选择、点击和等待。莱彩 Flow 指南解释了配置文件和流程的组织方式。

1. 读取连接的设备上下文并选择预期的串行别名；不要假设第一个设备是正确的。
2. 在打开或更改应用程序之前确认包和当前的 UI 状态。
3. 当可访问性信息稳定时使用 UI 状态，当可见文本是证据时使用 OCR，并且仅针对经过验证的图像目标进行模板匹配。
4. 在操作和随后的屏幕相关观察之间放置明确的等待。
5. 在更改屏幕或应用程序状态的每个阶段后检查后置条件。
6. 仅当支持指定审核决策时才捕获屏幕截图或录音。
7. 返回清晰的相位结果；当当前观察结果不证明下一步操作合理时，停止运行。

在准备本指南期间，只读来财上下文报告了 73 种可用节点类型和一部已连接的三星 Android 16 手机。这证实了当前的合同和设备感知路径；它不是性能基准。在将配置文件视为发布基础设施之前，请验证您自己的应用程序、设备、资产和运行时支持。

收集失败数据包，而不是红点

失败的检查应该回答运行的内容、运行的位置、系统观察到的内容以及运行停止的原因。 Firebase 测试实验室通过返回测试状态以及可用的日志、屏幕截图和视频来公开有用的模型。本地设备实验室需要同样的规则，即使其存储更简单。

• 运行 ID、时间戳、工作流程版本、构建版本和环境。
• 设备型号、Android 版本、稳定序列别名、屏幕尺寸、区域设置、主题和方向。
• 开始状态，输入夹具标识符，以及最后完成的业务阶段。
• 预期的后置条件和实际选择的 UI、OCR、图像或框架结果。
• 恢复前的屏幕截图，仅在运动重要时进行简短记录，以及有限的相关日志摘录。
• 分类：产品缺陷、测试缺陷、设备基础设施、数据、环境或需要人工审查。

使用稳定的文件名和清单，而不是非结构化的屏幕截图文件夹。在共享之前编辑个人或秘密数据。当故障周围的短暂清理间隔足够时，请勿上传整个设备日志。证据应该减少下一个人的工作，而不会造成新的隐私或保留问题。

选择能为他们赢得设备时间的支票

真实设备的分钟数很少，因为设备需要充电、清理、更新和人工访问。将它们分配给可见或物理行为很重要的工作流程。好的第一个候选者是部署后烟雾检查、权限和系统 UI 路径、相机或蓝牙设置、通知流、本地化证据、特定于供应商的回归以及精确的支持复制。

使业务逻辑、解析、格式化和组件行为在更快速的测试中保持靠近代码。使用真实设备来证明这些测试无法实现的边界：已安装的版本、操作系统、外部应用程序、输入界面、网络转换或人类可见的组合。Android自动化测试工具比较有助于将每个需求分配到适当的层。

由五个可靠旅程组成的关键包比没有人信任的五十个流程更有价值。从一条代表性路径开始，测量重置和分类成本，然后仅在新检查保护特定版本、客户或运营决策时添加覆盖范围。

在扩展实验室之前先对其进行测量

讨论自托管设备场的团队反复返回相同的构建与购买输入：队列行为、峰值并发、等待时间、启动或重置故障、维护工作以及仅出现在物理设备上的缺陷。在购买更多硬件或将所有内容迁移到云之前，跟踪几个发布周期的这些信号。

• 按一天中的时间和工作流优先级进行队列等待。
• 设备利用率以及无法用于充电、更新或维修的时间。
• 按设备划分的启动状态或重置故障率。
• 重新运行是由于自动化不稳定而不是产品变化引起的。
• 从失败到有用分类的中位时间。
• 仅在真实设备、特定供应商或特定 Android 版本上发现的明显缺陷。
• 每次成功运行和每个维护的工作流程的操作员分钟数。

这些是管理指标，而不是虚荣的仪表板。如果队列等待时间很短但维护占主导地位，则托管服务可能会降低拥有成本。如果隐私、本地外围设备、快速交互式调试或重复支持复制比广泛的模型覆盖更重要，那么小型本地实验室可能仍然是正确的重心。

使用混合构建与购买规则

本地实验室和托管实验室是互补的。 Gradle Managed Devices 可以在构建中定义虚拟设备并将其分组以进行测试执行。 Firebase 测试实验室可以跨托管虚拟和物理设备扩展矩阵并返回托管工件。本地池提供即时访问、专有外围设备、监督调试和用于定期操作检查的稳定设备。

明智的混合在托管虚拟基础设施上进行快速框架测试，将选定的兼容性检查发送到托管的真实设备，并为高价值的物理或监督流保留一个小型本地工作台。正确的划分可能会随着并发、隐私和客户设备证据的变化而变化。

Android 设备实验室自动化清单

1. 为每个设备矩阵行分配一个目的和决策。
2. 独立的模拟器、本地真实设备、托管、框架测试和视觉流职责。
3. 创建包含构建、设备、启动状态、输入、后置条件、停止和证据的运行卡。
4. 在第一个业务操作之前验证启动状态。
5. 等待可观察到的情况，而不是增加更长的盲目睡眠。
6. 将观察、决策和设备操作作为单独的可检查步骤。
7. 在重置或恢复更改故障之前捕获证据。
8. 对基础设施、数据、测试、环境和产品故障分别进行分类。
9. 跟踪队列、利用率、重置可靠性、不稳定的重新运行、分类时间和纯物理缺陷。
10. 当证据支持时，使用本地和托管混合策略。

从一部真实的电话、一种模拟器配置和一张关键业务运行卡开始。在添加其他设备或工作流程之前，使该循环可靠且可审查。当可观察的设备实验室层适合您的团队时，请使用 莱彩 Flow探索AI Android 自动化，并将实现细节保留在本地化感知流程指南中。

编者注：BeePOS LLC（莱彩投屏 背后的公司）使用下面链接的官方 Android 和 Firebase 文档、当前只读 LaiCai 产品合同以及公共 QA 讨论来研究本指南。产品功能的识别与中立的工作流程指南分开。问题或更正可以发送至support@laicaiapp.com。

• Android 开发人员：使用 Gradle 托管设备扩展您的测试
• Android 开发者：测试稳定性
• Firebase 测试实验室：Android 测试入门
• Reddit r/QualityAssurance：维护 Android 模拟器基础设施
• Android Developers: UI Automator