AI 安卓自动化用于 App 多语言测试：QA 实战指南

构建一个Android应用程序本地化测试工作流程，该工作流程结合了伪本地化、真实语言检查、RTL审查、OCR、屏幕截图和人工判断，而不必将每个测试乘以每个本地化。

简短的答案：自动化路线，审查语言

可靠的Android应用程序本地化测试工作流程将可重复的设备工作与语言判断分开。自动化语言设置、应用程序启动、导航、等待、屏幕截图、已知状态检查和证据收集。在人类审查下保持翻译质量、语气、文化含义、模棱两可的剪裁和视觉平衡。目标不是在每种语言中运行每项测试。而是创建一个小型、基于风险的矩阵，揭示最有可能触及用户的故障。

这很重要，因为本地化缺陷不仅是不正确的单词。它们包括硬编码字符串、缺少资源、文本扩展、左右向布局错误、日期或货币不正确、键盘不匹配、无法阅读的字体、剪切的按钮和不持久语言设置。一个AI Android自动化工具可以帮助重复可见的路线并收集证据，但它无法决定一个句子是否听起来对当地客户来说听起来很自然。

下面的工作流程将安卓的官方本地化功能与可观察的设备检查相结合。它并不声称莱彩 Flow取代单元测试、Compose测试、Espresso、UI Automator、Appium、一个翻译管理系统或本地语言审查。使用每个层来制作最佳的证据。

从本地化发布矩阵开始，而不是语言列表

支持的语言列表不是测试计划。版本矩阵将语言环境连接到屏幕、设备状况、数据格式、书写方向和使语言环境具有意义的业务风险，这些因素使语言环境具有意义。如果没有这种连接，团队通常会以几种语言打开主屏幕，截图，然后错过结账、搜索、帐户恢复、通知或设置中的失败。

每个版本都选择一个基线语言区、一个扩展量大的语言区、一个紧凑型或复杂脚本语言区和一个RTL语言区。仅在承载重大业务风险的流程中添加特定于市场的语言区。Firebase测试实验室的Android矩阵同样地，将本地化视为与设备模型、Android版本和方向一起的维度；即使在您自己运行检查时，这也是一种有用的规划模型。

在翻译到达之前使用Android伪位置

假定位器是工作流程中最便宜的早期警报系统。Android的伪位置引导描述`en-XA`，它扩展和强调英语文本，以及`ar-XB`，它行使从右向左的行为。它们可以暴露硬编码字符串、断裂字符串拼接、布局压力、双向文本问题以及在翻译器交付最终副本之前未能映象的元素。

• 在`en-XA`并记录每个仍然是普通英语的字符串；它可能是硬编码的或位于本地化资源路径之外。
• 重复同样的旅程`ar-XB`并检查导航顺序、后退箭头、标签、进度指示器、混合数和标点符号。
• 捕获错误、空、权限、升级和确认状态；它们在普通成功路径审查期间不太明显。
• 将伪局部化失败视为可局部化缺陷，而不是证明特定真实翻译是错误的证据。

开发者还可以更早地检查选定的屏幕。Android的本地化文档和编写预览工具支持特定语言的预览，包括RTL示例。这些代码相邻的检查速度快，应该在完整的设备工作流程之前捕获组件级别的问题。

测试用户实际使用的语言路径

如果用户无法选择、保留或重置语言，翻译后的屏幕就不够用了。Android的应用程序内语言指南解释说，Android 13及更高版本为应用程序的首选语言提供了一个集中化的系统设置，而AndroidX在旧版本上支持兼容的应用程序本地化处理。应用程序还可以拥有自己的语言选择器。每个受支持的条目路径都需要进行简单的状态转换测试。

1. 从一个命名的干净状态开始：新安装、升级安装、已登录帐户或恢复备份。
2. 通过预期的系统或 app 内路径选择语言区域，并确认 app 是否会重新启动、重新创建活动或在原地更新。
3. 导航离开设置，并确认目标语言区出现在业务关键屏幕上。
4. 关闭并重新打开应用，然后验证偏好设置是否保持不变。
5. 重置为系统默认设置，并确认不会保留过期的翻译资源。
6. 在较旧的Android版本上，请测试实际的兼容路径，而不是假设Android 13的行为。

设备语言和键盘语言是两个不同的问题。BrowserStack的本地化测试文档请注意，在Android设备上更改语言并不一定会更改键盘语言。在矩阵中保留这种区别，以便避免将文本输入失败误认为是资源故障。

根据风险选择代表性屏幕

不要将每个现有的端到端测试乘以每个本地化。选择屏幕，其中本地化会改变行为、布局、信任或金钱。一个紧凑的集通常包括入职、登录、主页导航、搜索、一个详细页面、一个表单、一个付款或确认面板、设置、通知和最重要的错误状态。

优先考虑具有固定宽度的控件、相邻图标、多个变量、复数规则、动态服务器文本、紧凑型卡片、底部导航和翻译文本，而不是图像。包括一个屏幕，其中包含尽可能逼真的内容，而不是仅包含空的演示数据。如果您的应用程序支持平板电脑、可折叠设备或横向显示，请仅在布局真正发生变化的地方添加它们。

为每个选定的屏幕分配一个所有者和一个原因。例如，结账确认页面存在是为了验证货币、行内包装、按钮标签和法律副本；帐户恢复屏幕存在是为了验证输入方法、错误消息和双向电子邮件地址。这使得故障可以采取行动，而不是产生一堆无法解释的屏幕截图文件夹。

将证据方法与定位缺陷匹配起来

没有单一的定位器或图像技术可以证明定位质量。选择能够支持决定的最小观察。现有的安卓视觉测试指南解释了UI状态、OCR、图像匹配、对象检测和屏幕截图之间的更广泛差异；本地化QA将这些方法应用于特定语言的风险。

在当前的莱彩 Flow合同，OCR返回一个结果集，而不是一个神奇的答案。流程必须在比较文本或位置之前选择相关段落。同样，视觉匹配报告已知状态；它不应被滥用为每个像素或句子都是正确的说法。

在真实的安卓设备上构建可观察到的本地化流程

当团队需要在真实的安卓设备上重复相同的导航并向审查员提供一致的证据时，可观察到的视觉工作流程很有用。莱彩 Flow是内部的一个自动化功能莱彩投屏。 可组织可见步骤，如等待、UI状态检查、OCR、模板匹配、屏幕截图、条件、有限循环和明确停止。 足够的莱彩 Flow指导涵盖产品工作流程。

1. 命名构建、设备、Android版本、语言区、主题、字体大小和初始帐户状态。
2. 打开 app 或设置路径，并在依赖屏幕的观察之前使用明确的等待时间。
3. 一次浏览一个用户级别的阶段，当旅程变得复杂时，将技术查找详细信息保留在可读的子流程中。
4. 在每次破坏性或状态更改操作之前，请检查屏幕状况是否稳定。
5. 捕获所需的屏幕截图和带有语言和屏幕标识符的任何选定的OCR结果。
6. 在导航后验证后条件，而不是假设轻点成功。
7. 当屏幕未知时，请停止使用证据；不要继续点击意外的语言或对话框。

此层与基于代码的测试相辅相成。组件和仪器测试仍然应该拥有资源查找、状态逻辑、可访问性语义和接近应用程序的确定性断言。当支持、本地化或发布审查员需要可重复的路径和可人读取的证据数据包时，可见的流程是最强的。 足够的Android QA烟雾测试工作流程提供一个相关的通用模式。

为RTL和双向内容提供自己的测试通过

RTL不是在LTR屏幕截图清单的末尾添加的项目。使用阿拉伯语或其他支持的RTL语言库运行专用流程，并包含混合方向内容，如电子邮件地址、电话号码、价格、版本字符串、URL、代码和拉丁品牌名称。这些组合会揭示完全翻译的段落可能没有显示的标点符号和排序失败。

• 确认导航、抽屉、标签、进度方向和方向图标仅在它们的含义应该映射时才会映射。
• 检查数字、单位、产品名称和输入游标在 RTL 句子中是否仍然可读。
• 检查空状态、对话框、小食栏、权限说明和表单验证消息中的对齐。
• 测试滑动和后退导航按行为进行，而不是假设每个手势都会与文本方向相反。
• 使用母语评论员来检查标点符号、语法、行尾换行符和文化解释。

使用`ar-XB`早点暴露结构性故障，然后在发布前至少运行一个真实的RTL本地化。伪本地化可以揭示镜像缺陷，但它不能验证生产阿拉伯文本的排版或含义。

测试格式、输入、通知和外部表面

一些最昂贵的本地化失败发生在应用程序主屏幕之外。添加针对日期和时间、小数分隔符、货币放置、地址顺序、测量单位、电话号码、复数形式、键盘输入、剪贴板行为、通知文本、深度链接、网络内容以及旅程所依赖的任何系统对话框的重点检查。

记录每个值的驱动本地化。应用程序语言、系统本地化、帐户国家、服务器偏好、时区和键盘可能存在差异。显示出令人惊讶值的屏幕截图是有用的证据，但错误报告还必须指定这些输入，以便工程人员可以重现不匹配的来源。

将商店列表和促销屏幕截图视为单独的发布表面。它们的文本可能来自不同的存储库，它们的图像可能由不同的管道生成。重复使用相同的屏幕库存和命名方案，但不要仅仅因为商店描述是翻译的就标记应用程序为本地化。

保留人类审查，因为自动化能力较弱

自动化擅长重复路线并检测已知证据。人类仍然更擅长含义、语气、上下文、文化契合度、视觉层次、幽默、模棱两可以及决定换行符是否只是看起来不同，还是实际上会损害理解力。故意构建交接，而不是将手动审查视为意外例外。

• 自动化：语言设置、启动、导航、等待、稳定状态检查、选定文本存在、屏幕截图、文件命名和证据打包。
• 手动审查：翻译含义、自然性、法律细微差别、复杂脚本的可访问性、模棱两可的截断、文化形象和视觉平衡。
• 升级到代码测试：精确的资源映射、复数逻辑、确定性格式化函数和组件语义。
• 升级至设备或框架测试：系统权限、跨应用程序行为、键盘集成和生命周期过渡。

一个有用的停止规则很简单：当可见状态不是批准的状态之一时，收集证据并停止。不要让自动化继续通过未知的同意屏幕、付款步骤、破坏性操作或未翻译的系统路径。 足够的安卓自动化测试工具比较可以帮助将每个断言分配到正确的层。

创建一个证据包，以便发布团队可以采取行动。

没有上下文的通过/失败仪表板会创建另一个调查。每个本地化发现都应确定构建、应用程序包和版本、语言区和地区、Android版本、设备和分辨率、字体缩放、主题、初始状态、屏幕名、预期结果、实际结果以及支持该索赔的屏幕截图或选定的观察结果。

使用稳定的文件名，例如`build-locale-device-screen-state.png`，然后保留一个映射文件到测试矩阵的明细单。将预期视觉变化与缺陷分开：不同的换行符可能是可以接受的，而隐藏的价格、无法触达的按钮、倒置的品牌标志或缺失的错误消息则不可接受。根据用户影响来分配严重性，而不是根据像素差异。

由于当前版本中没有可用的LaiCai管理的设备，本文描述的是基于合同的工作流程，而不是为特定应用程序、设备或语言区声称基准结果。在扩展矩阵之前，请在您的环境中运行一个代表性的试点。

Android本地化QA发布清单

1. 定义支持的语言区域列表、备用语言区域、语言选择路径和高风险市场。
2. 跑步`en-XA`和`ar-XB`在最终翻译到达之前，在代表性屏幕上查看。
3. 验证每个路径都支持的真实的应用程序、系统和应用程序内语言切换。
4. 在小屏幕上覆盖一个扩展量大的语言、一个复杂脚本语言和一个 RTL 语言。
5. 包括错误、空格、加载、确认、权限、升级和通知状态。
6. 检查区域格式、输入方法、字体大小、亮度/暗度主题和语言持久性。
7. 仅在他们能够支持的索赔中使用 UI 状态、OCR、模板匹配、屏幕截图和人工审核。
8. 保存一个命名的证据数据包，并在未识别的状态下停止。
9. 让母语评审员批准含义、语气、标点符号和文化契合度。
10. 将主要自动化 CTA 保留在本地化意识的拥有者页面上，并使用相关指南了解实施细节。

关于作者：BeePOS LLC开发莱彩投屏和它的莱彩 Flow自动化功能。本指南基于当前的Android文档、观察到的本地化测试实践和已发布的莱彩 Flow节点合同。产品问题可以通过以下方式发送LaiCai公司和支持页面。

来源

• Android开发人员：使用伪位置来测试您的应用程序
• Android开发人员：应用程序的语言偏好设置
• Android开发人员：本地化您的应用程序
• Android开发人员：使用可组合预览预览您的UI
• Firebase：使用Test Lab开始对Android进行测试
• BrowserStack：使用App Live进行本地化测试