在过去四年多的时间里，我们团队一直在开发大型 Flutter 项目，并且始终讨论移动 UI 测试自动化的话题。在我们的第一个应用中，我们每个月发布一次更新，后来逐渐过渡到每两周发布一次更新。至少每晚进行一次功能应用测试的自动化，有助于更快、更自信地发布应用。团队和业务都清楚这一点的重要性。
我们的第一个 Flutter 应用采用了Flutter 集成测试，并结合了 Github Actions 和 Firebase 测试实验室。然而，我们在使用 Flutter 集成测试时的体验并不是很顺利。此外，其在覆盖 WebViews 或原生视图方面的限制可能会带来重大问题。
另一个 Flutter 团队在不同的项目上使用了 Patrol。在这两种情况下，主要是开发人员编写这些测试，但 QA 人员希望能够拥有更多的控制权。
我们最新的 Flutter 项目有一个更复杂的设置。团队一直在开发一个白标框架，同时构建几个完整的 Flutter 应用，并将一些 Flutter 功能集成到现有的原生应用（iOS + Android）中。这些现有的原生应用已经实现了自动化运行，因此去年我们进行了调查，以确定哪种自动化工具最适合我们的完整 Flutter 应用。
我们考虑的工具
下表提供了所考虑工具的简要概述。请注意，某些工具的已知限制在表中未显示。
我发现一个非常有趣的事实是，Maestro 以前被称为 Conductor，而 Patrol 之前的名称是 Maestro！你可以在 Maestro 仓库中查看这次重命名和在 Patrol 仓库中的这次重命名。
值得注意的是，基于提供的语义信息对 Flutter 视图进行黑盒测试。默认情况下，这些信息包含在显示文本的小部件中。然而，你可以使用 Flutter 的语义小部件将语义信息附加到任何小部件上。
此外，长期存在的 accessibility-id 问题最终在 Flutter 3.19 版本中得到解决，多亏了 Bartek Pacia！结果是，Semantics 小部件的新 accessibility identifier 属性现在已传播到原生的可访问性层次结构中。
我们认为重要的事项
我们特别关注以下几个方面：
- 成熟度和可维护性
- 黑盒测试
- 检查工具
- 与我们 QA 技能的兼容性
我们的选择
鉴于 WebdriverIO 是一款成熟的工具，已被用于我们的原生应用，并且我们的 QA 们已经熟悉，技术上能够覆盖完整的 Flutter 应用和添加到应用的 Flutter 应用，我们决定扩大其使用范围是显而易见的。这一选择也加强了我们关注应用中 Semantics Tree 的动力，因为它们不仅对残疾人至关重要，还是桥接 UI 测试自动化工具的桥梁！
额外福利：Maestro 易用性的演示
尽管我们没有为最新的 Flutter 应用选择 Maestro，但我对其速度和易用性印象深刻。
因此，为了给你展示它的功能，我重新启动了我 5 年前开始的第一个 Flutter 宠物项目，决定自动化一个测试案例。该项目是 MemMe，一个设计简洁的抽认卡应用，旨在简化记忆过程。
我使用仅一个命令安装了 Maestro，并开始使用 Maestro Studio 进行实验。我编写了以下流程来测试向新安装的应用中添加新闪存卡的案例。这个过程写起来快速而愉快，以至于我甚至在喝完一杯茶之前就完成了测试！
appId: com.pasul.memme
---
- launchApp
- tapOn: Add
- tapOn:
id: "help_button"
- tapOn: Close
- tapOn:
id: "card_side_text_form"
- inputText: "# When *Flutter 1.0* was released?"
- tapOn:
id: "tab_bar_back_side_tab"
- inputText: "# It was in December **2018**!"
- tapOn:
id: "preview_button"
- tapOn:
id: "flippable_card"
- tapOn:
id: "save_button"
- tapOn:
id: "catalog_tab"
- assertVisible: "# When *Flutter 1.0* was released?
# It was in December **2018**!"
下面的动画演示了测试流程的运行。顺便说一句，这段视频是使用 Maestro 中的内置功能录制的。
结论
不要犹豫投入时间探索移动 UI 测试自动化的世界。凭借正确的工具和理解，这种投资可以显著提高你交付高质量、可靠应用的能力。这通常是一项值得的投资。
