Android 上的辅助功能测试自动化

Question

我最近开始研究 Android 上的自动化辅助功能测试。网络上没有太多信息。有人探索过这个或者目前正在这样做吗？如果是这样，您能分享您的想法/方法吗？

似乎 Android 的 uiautomator 依赖于辅助功能来工作，但它不支持测试辅助功能。如果它依赖于辅助功能，这是否意味着可访问标签等基本验证是否可以通过使用 uiautomator 执行 UI 测试来完成？

这对我来说是一个新领域，因此任何信息都会有所帮助。

Answer 1

这是对 Android 中的辅助功能测试的精彩介绍。它基本上可以归结为：

• 使用辅助功能扫描仪手动测试您的应用程序是否存在视觉问题
• 打开 TalkBack 并手动测试您的应用以查找听力受损问题
• 要查找字体缩放和布局问题，请使用大文本
• 绝对要进行 lint 检查，但请确保“没有 contentDescription 的图像”设置为 Severity = Error
• 您发现或重复出现的任何/所有可访问性问题，请编写一个 Espresso 测试，以便在将来违反该可访问性问题时失败
• 对于自动化，如果需要听力受损功能，您还需要考虑如何对某些屏幕伪影执行视觉验证和音频分析。

另外，我建议观看GTAC 2015 关于可访问性测试的演示，了解有关该主题的一些精彩背景。

对于检查可访问性的自动化测试，我强烈建议从可以在跨屏幕共享的元素（菜单、布局、主题、自定义控件）中识别的问题开始。虽然它们不会捕获偶尔出现的一次性错误，但它们会解决应用程序中各处发生的问题，如果您愿意的话，可以采用“按数量优先”的方法。

另外，如果您的团队使用 Android Studio，那么您肯定希望推动编写驻留在代码中的 Espresso 测试的能力。质量保证是开发过程的一部分。访问测试所在的子文件夹应该不是问题，除非需要处理一些合法的博洛尼亚。例如，将“androidTest”文件夹拆分为一个子模块，您在其中作为测试人员拥有拉/推权限，但只有应用程序其余部分的读取权限，以便您可以自己编译和运行。如果您正在编写 Appium 测试，那么要求您的开发团队在构建期间将它们作为自己的 BVT/冒烟测试过程的一部分运行可能会更困难，但并非闻所未闻。

至于视觉分析和音频注入/确认，这些是您可能需要使用某些服务或商业工具的高级功能。

祝你好运！