5

我最近开始研究在 Android 上自动进行可访问性测试。网上没有太多信息。有没有人探索过这个或目前正在这样做？如果是这样，你能分享你的想法/方法吗？

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

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

4

2 回答 2

2

这是对 Android 中的辅助功能测试的一个很好的介绍。它基本上归结为：

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

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

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

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

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

祝你好运！

于 2017-01-10T14:37:17.280 回答
1

我完全同意 Paul 的回答，并且他链接到一些非常有用的资源（所以请查看它们！），但如果您正在寻找的只是您建议的基本可访问性测试覆盖率（例如检查可访问标签您所有的组件），您的用例可能适合Continuum for Mobile之类的应用，特别是 Android 变体。一旦发现可以使用自动化工具检测到的更基本的违规行为，您就可以进行更多的手动通过；截至目前，手动测试始终是完全符合可访问性标准的必要条件，但这样的事情会让你更接近。

于 2018-09-20T15:27:52.053 回答