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

Question

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

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

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

Answer 1

这是一个 great introduction到 Android 中的辅助功能测试。它基本上归结为:

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

此外，我建议观看 this presentation from GTAC 2015关于该主题的一些重要背景的可访问性测试。

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

此外，如果您的团队使用 Android Studio，那么您肯定希望能够编写与代码一起驻留的 Espresso 测试。 QA 是开发过程的一部分。除非有一些合法的博洛尼亚需要处理，否则访问测试所在的子文件夹应该不是问题。例如，将“androidTest”文件夹拆分为 submodule作为测试人员，您拥有拉/推权限，但只有对应用程序其余部分的读取权限，因此您可以自己编译和运行。如果您正在编写 Appium 测试，可能很难要求您的开发团队在构建期间将它们作为他们自己的 BVT/冒烟测试过程的一部分运行，但这并非闻所未闻。

至于visual analysis和 audio injection/confirmation ，这些是您可能需要使用某些服务或商业工具的高级功能。

祝你好运!