Flutter 端到端测试使用 Patrol

在当今快节奏的开发环境中，快速且高质量地交付新功能和增强功能对于保持竞争优势至关重要。对于AlloFresh来说，每两周一次的应用更新对于满足客户满意度和跟上市场趋势至关重要。然而，确保这些更新符合我们的高质量标准是一个重大挑战。

为了解决这一挑战，我们仔细研究并评估了各种测试框架，最终选择了Patrol作为我们Flutter端到端测试的解决方案。在本文中，我们将介绍我们选择测试框架时的需求与标准、实施过程以及对我们组织的积极影响。

需求识别

回归测试是每个发布周期中至关重要但耗时的过程。随着功能的逐步增加，资源有限，手动回归测试的时间不断延长，导致效率低下，并对发布质量构成风险。

在这种情况下，我们意识到有必要通过编程优化回归测试过程，使其能够执行重复性测试，简化测试流程，确保我们的更新能够快速且高质量地交付。

寻找合适的解决方案变得至关重要，以保持我们在市场中的竞争优势。

选择框架

我们的条件是：

我们有几十位应用工程师
我们只有七位测试工程师，分布在三个团队中
AlloFresh应用是使用Flutter构建的，并部署在iOS和Android平台上
有单元测试和小组件测试，但缺少端到端（E2E）测试
新功能和回归测试是手动进行的，完成整个回归测试需要三天时间

我们对测试框架候选者的基本期望：

框架应尽可能与应用开发语言接近，这将有助于与应用工程师的支持与合作
能够与应用小组件交互，如执行操作、获取属性、对屏幕/小组件状态进行断言
有良好的报告输出
社区支持

在评估了多个流行的测试框架后，我们选择了Patrol，因为它能够无缝集成到Flutter中，易于使用，并且具有全面的测试能力和文档。Patrol脱颖而出的原因在于：

它允许我们在模拟器上编写并运行Flutter端到端测试
其代码库扩展了Flutter的测试包，增加了代码维护性和可扩展性
相比于Flutter测试，Patrol的小组件查找器使用更加简洁、简单
具有智能的“pump-and-wait”机制，执行更智能的测试动作
提供了多种pump函数的选项
原生交互功能使其非常适合我们的自动化需求，增强了我们的测试策略
支持与BrowserStack集成，这也是我们最初的计划之一

此外，Patrol由技术咨询公司LeanCode开发，并由专职工程师积极维护。Patrol的支持非常活跃，在GitHub的issues部分以及Discord频道中，问题和贡献得到积极回应。这种活跃的维护和支持社区使我们对选择Patrol充满信心，并确保了我们在成功实施框架时拥有所需的资源。

实施过程

Patrol提供了详细的安装步骤，以下是我们遵循的关键步骤：

Patrol的设置

按照官方文档中的步骤操作，我们通过将Patrol与现有的Flutter主仓库集成，确保了框架的兼容性。

首先，将Patrol添加为pubspec配置中的依赖项，并安装patrol_cli，以便通过终端与Patrol命令交互。
针对特定平台（如Android）设置本地配置。
通过模拟器与应用程序的第一个屏幕进行交互，运行简单测试，确保Patrol成功配置。

测试脚本开发

我们创建了一套涵盖关键用户旅程和功能的测试脚本，依赖页面对象模型结构作为测试设计模式。

├── ...
├── build/
│   └── app/
│       └── outputs/
│           ├── app.apk
│           └── test_suite.apk
├── integration_test/
│   ├── helper
│   ├── step_definitions
│   ├── suites
│   └── .patrol.env
├── pubspec.yaml
└── ...</span>

Patrol提供了直观的方式来使用其属性访问小组件查找器，并且与Flutter的断言方法非常适配。Patrol动作使用简单的语法和智能机制，内置的小组件pump确保每个场景步骤都能安全加载UI帧。

```span< await $.enterText( $(KeyUser.voucherSearchField), voucherCode ); await $.tap( $(KeyUser.voucherSearchButton), ); }


如上面步骤定义方法的代码示例所示，我们有一个通过输入优惠码搜索优惠券的方法。使用Patrol语法进行小组件查找和操作，该方法包括（1）通过查找器和参数输入文本，以及（2）点击搜索优惠券按钮。

#### 测试报告

我们还独立添加了收集和处理测试运行结果数据的功能，可以通过Grafana进行可视化显示。通过一个仪表盘，我们可以监控测试运行的成功率，以及每个场景的测试持续时间、每个场景的失败测试数量以及失败场景时出现的错误列表。

### 培训与应用

为了确保顺利应用，我们在实施的同时为测试工程师举办了培训课程。首先，我们介绍了Dart和Flutter的基础知识，这是新接触Flutter的测试工程师所需的基础，然后深入讲解Flutter中的测试，重点是小组件、操作、断言和pump机制。这些课程通过创建一个简单的测试脚本在准备好的演示应用上进行，帮助所有测试工程师自信地参与Flutter测试自动化。

### CI/CD的实施

在本地机器上成功执行一系列场景后，我们需要通过设置CI/CD流程来确保测试结果的一致性和可靠性。首次尝试时，我们将测试框架从GitLab仓库设置到自有的MacMini服务器上，然后创建了一个简单的GitLab CI任务，在指定的事件和时间表上运行端到端测试。

我们还成功地将测试运行集成到BrowserStack中。多亏了Patrol的脚本能力，我们可以自动构建并上传应用和测试套件，然后通过BrowserStack API执行测试运行。目前配置中，BrowserStack成为我们执行测试的主要平台，MacMini作为备用选项。

我们计划根据应用发布日程执行端到端测试：

```Flutter
+----------+---------+---------+---------+---------+---------+---------+---------+
| Sprint   | Mon     | Tue     | Wed     | Thu     | Fri     | Sat     | Sun     |
+----------+---------+---------+---------+---------+---------+---------+---------+
| Week n-1 | ...     | ...     | ...     | ...     | Code    | Pre-reg | Pre-reg |
|          |         |         |         |         | freeze  |         |         |
+----------+---------+---------+---------+---------+---------+---------+---------+
| Week n   | Reg day | Reg day | Reg day | Nightly | Nightly | Nightly | Nightly |
|          | Nightly | Nightly | Nightly | test    | test    | test    | test    |
|          | test    | test    | test    |         |         |         |         |
+----------+---------+---------+---------+---------+---------+---------+---------+
| Week n+1 | Nightly | Nightly | Nightly | Nightly | Nightly | Pre-reg | Pre-reg |
|          | test    | test    | test    | test    | test    | test    | test    |
|          |         |         |         |         | Code    |         |         |
|          |         |         |         |         | freeze  |         |         |
+----------+---------+---------+---------+---------+---------+---------+---------+

预回归测试（回归日前的周六和周日）：在重大发布前夕，我们进行预回归测试，运行针对代码冻结时产生的特定应用版本的Flutter端到端自动化测试。
回归测试日（周一至周三）：这些日子专门用于回归测试。除了手动测试未自动化的场景外，我们还会复查预回归测试结果中的自动化场景，确保所有场景按预期通过。如果有失败的测试，我们会手动重新测试该场景，并随后进行不稳定测试的分类。
夜间测试：这些日子专注于夜间自动化测试，全面检查应用的功能，捕捉在特性开发期间可能遗漏的问题。持续的测试有助于及时发现和解决问题。

成果与影响

实施Patrol后，我们的测试活动开始发生转变。以下是我们观察到的一些初步好处：

增加了测试覆盖面：有了自动化测试，我们开始扩展测试覆盖面，降低了未发现问题的风险。
加快了发布周期：自动化回归测试减少了手动回归测试的时间，使我们能够更频繁且更有信心地发布更新。实施测试框架后，我们开始分阶段自动化回归测试场景，一旦所有可自动化场景完成转换，我们就会转向下一个团队的场景。

持续集成：除了用于回归测试，我们还在每次代码提交前运行测试，提早发现问题，防止漏洞累积，使问题更容易修复。工程师能够及时收到代码更改的反馈，帮助他们在问题升级前解决，进而提高代码质量。夜间测试还确保定期测试整个代码库，帮助识别和解决最近更改或集成引发的问题。
共享测试功能：除了在移动操作系统上运行端到端测试外，我们的应用工程师还使用Patrol编写小组件测试。
增强了团队协作：测试库和应用开发使用相同的语言，大大增强了团队协作。应用工程师现在积极参与测试框架的功能改进，这种共享的知识不仅在编写小组件测试时有帮助，也使他们能够为改进框架设计提供有价值的建议。结果是，我们培养了一种质量与团队合作的文化，每个人都参与到维护和改进测试流程中。

虽然我们仍在不断维护和优化我们的测试框架，但这些早期成果是令人鼓舞的，已经对我们的开发工作流程产生了积极影响。我们致力于持续改进，最终目标是在一天内完成整个回归测试。

总结

Patrol框架在我们Flutter端到端测试中的实施对AlloFresh来说是一次变革。它不仅提高了我们发布的质量，还提升了我们团队的生产力和协作力。

‍