在 Fresco，我们致力于在保持高质量标准的同时提高工作流程的效率。早期，我们使用了自动化的端到端测试，希望能够帮助我们更快、更有信心地发布产品。然而，我们面临了不可靠的测试结果、高昂的维护成本，并且不得不手动重复检查所有内容，这违背了自动化的初衷。

面对这些问题，我们关闭了自动化测试，完全依赖手动测试。虽然这为我们提供了所需的准确性，但随着应用程序的增长，这种方式变得不可持续。因此，我们决定再次尝试自动化，但这次不同了。

在这篇文章中，我将分享我们重新尝试自动化端到端测试的历程，包括遇到的挑战、学到的经验，以及让我们的测试变得更加可靠和有效的新解决方案。

测试回顾

软件工程师应该定期验证他们正在构建的应用程序是否按预期工作。这意味着要检查新功能、修复的 bug 或改进是否导致了问题或中断。这种验证通过不同类型的测试来完成，通常根据测试金字塔进行分布。

​

测试金字塔 通常分为三个层次，从下到上依次为：

• 单元测试：验证代码库的大部分内容，并检查特定组件的独立功能。因此，它们是最具成本效益的测试类型，但范围有限。
• 集成测试：验证服务或组件之间的输入、输出和交互。相比于单元测试，集成测试需要更多的设置工作和运行时间，但覆盖范围更广。
• 端到端（E2E）测试：在最高层次验证整个应用程序的流程，模拟从头到尾的真实用户场景。它们执行最慢，实施最复杂，并且需要一个完全工作的环境来运行。

金字塔强调应有大量的单元测试、较少的集成测试以及最少的端到端测试。

单元测试和集成测试更容易实现自动化，通常在代码库引入新更改时会自动运行。

端到端测试（本文的重点，后文为了简化称为“测试”）由于复杂性，通常由专门的团队手动执行。这也是 Fresco 当前的情况，然而，情况并非总是如此。

历史和产品背景

在 Fresco，我们的目标是通过解锁智能厨房电器的全部潜力，使家庭烹饪变得轻松和充满回报。从技术角度来看，这意味着我们的应用程序必须与这些电器交互（连接、发送和接收消息），而测试这些场景需要一个真实的移动设备和电器。

几年前，我们实施了一套自动化测试套件，运行在我们办公室的物理移动设备上。这是必要的，因为办公室内有测试用的电器设备，供我们测试与应用程序的交互。然而，这带来了几个问题，包括：

• 连接不稳定。
• 设备的物理干扰。
• 测试设备与设备断开连接。
• 测试框架（Appium）的不稳定性。

这些问题导致我们对测试套件失去信任，最终忽视其结果，并手动重新测试每个场景。随着时间的推移，我们逐渐停止了自动化测试，完全依赖手动执行。

虽然维护自动化套件是工程师的责任，但手动测试将工作量分散到公司内的各个团队，因为 Fresco 的任何同事都可以手动执行测试场景。

和软件中的所有东西一样，手动测试也有一些限制，例如：

• 容易出错：测试人员可能会遗漏缺陷或在执行测试用例时犯错，导致 bug 或安全漏洞未被发现并发布到生产环境。
• 效率低下：重复相同的步骤需要时间，通常比机器执行同样的任务花费更多时间。这还可能导致无聊和疲劳，增加遗漏缺陷的可能性。
• 扩展成本高：随着产品的发展和测试数量的增加，需要更多的时间和测试人员来执行测试用例。

我们还发现，虽然手动测试在测试更复杂的场景（如设备配对）时给了我们更多的信心，但它降低了我们在更简单和定义明确的场景（如身份验证）中的效率。

当前流程

在每个冲刺的最后，会有一个新版本提供给公司所有员工，供他们测试工程师在此期间完成的最新功能、bug 修复和改进。事实上，每当新代码添加到代码库时，我们都会发布一个新版本的应用程序，这得益于我们自动化的 CI/CD 流程，但这是另一个博客文章的话题。不同的是，在冲刺结束时发布的版本可能会被推向生产环境，供所有用户使用。

拿到新版本后，我们的同事戴上“测试员的帽子”，手动运行一系列脚本化测试，针对我们的应用程序检测可能的回归或新 bug。

大处着眼，小处着手

我们希望通过减少大部分手动工作来改善这种情况。但我们也想避免回到之前成本高昂且不可靠的测试结构。

经过讨论，团队决定采取迭代（Plan-Do-Check-Act，计划-执行-检查-行动）的方法。计划是估算实现当前所有测试场景所需的工作量，并按复杂性对其进行排序，从较简单的场景开始，最终处理最复杂的场景。

然后，我们会在一个“实施周期”中实现前两个或三个场景。在这个周期结束时，参与此工作的工程师必须正式评估整体实施体验。以下是我们认为需要不断检查的一些关键问题：

• 所有选定的场景都成功实现自动化了吗？如果没有，哪些没有？为什么？
• 在编写测试之前是否需要进行任何准备工作？
• 是否遇到任何意外情况，这些情况会影响未来场景的自动化？
• 实现的场景是否显示出不稳定性？
• 从 0（非常简单）到 5（非常困难），实现这些场景的难度是多少？
• 有没有任何理由现在不继续自动化？

如果对这些问题的回答表明一切按计划进行，我们将挑选下一个场景继续自动化并重复这一过程。然而，如果问题表明计划没有按预期进行，我们将暂停自动化过程，并与整个移动团队讨论下一步。接下来的步骤也可能包括停止自动化过程。

这种方式允许我们以小幅增量工作，定期获得反馈并根据需要进行调整。它还防止了我们在这个项目上投入过多，最终发现我们回到了之前的问题状态。

有了明确的策略后，是时候选择合适的工具了。于是，我们开始调查和测试市场上不同的框架。

测试工具的选择

调查和测试包括在每个框架中实现两个测试场景。选择的场景是：

• 使用现有用户登录：这个简单的场景有助于确定框架的设置和使用难度。
• 通过电子邮件注册新用户：此场景需要更多的交互和电子邮件验证步骤，要求执行应用程序之外的操作。目的是评估框架在更复杂场景中的表现。

此概念验证（PoC）的预期输出是确定是否有工具适合我们的需求，如果有，哪一个是我们更愿意投资时间的。目的是不是选出“最好的”，而是确定哪个工具更适合我们的具体情况（团队规模、技能、时间、预算、场景等）。

经过这次实验后，我们的工程师编写了一份各框架的优缺点清单。以下是我们对每个工具的总结：

​​

                                    实验框架的总结

团队决定使用 Maestro 工具，尽管它相对较新，但总体上 PoC 的实现体验比其他工具更好。虽然我在总结中没有明确提到安全性，但它在实验中得到了考虑，我们发现 Mobile.dev 公司通过了 SOC 2 认证，这增加了我们对这一决定的信心。

有了正确的计划和工具后，我们可以开始实施了。然而，我们并没有立即开始自动化。

准备工作

在 Maestro 框架中，测试场景称为“流程”（flows）。以下是一些我们的流程示例：

• 登录和注册。
• 搜索食谱。
• 将食谱保存到“我的食谱”中。

然而，并不是所有的工作都与流程相关。有时，在实现流程之前，我们需要做一些准备工作。例如：

• 创建存储自动化代码的仓库。
• 设置 CI/CD 任务以运行场景。
• 设置结果发布到正确的渠道。
• 在 iOS 和 Android 项目中创建无障碍标签，Maestro 将使用这些标签来引用自动化中的视图。
• 实现流程可能需要的脚本。
• 设置测试凭据。
• 编写带有入门说明的文档，帮助其他工程师快速上手。

我们将这些类型的工作称为“支持工作”，以明确是否需要在实施流程之前进行任何准备工作。这有助于减少在实施阶段出现的未计划工作量，使任务更小，估算更精确。

一旦支持工作完成，我们终于可以开始自动化场景了。

目前的进展

在撰写这篇文章时，我们大约有十个场景已实现自动化，并在每次发布之前运行。

好的方面：

• 我们正在发现 iOS 和 Android 之间非故意的差异。
• 跨平台工程师之间的协作有所增加。
• 我们没有遇到框架的不稳定性。
• 编写流程相对容易。

不太好的方面：

• 一些场景需要与第三方服务交互的自定义脚本，这些服务可能不稳定，导致流程失败。
• 不断重构流程以避免代码重复，因为一些流程依赖于其他流程中的相同操作。
• 在开发过程中，可能需要同时打开 Android Studio、XCode、一个 Android 模拟器和一个 iOS 模拟器。这会消耗大量的内存和 CPU，减慢工程师的工作效率。可能还需要第三个 IDE（或文本编辑器）来编辑包含流程的 YAML 文件。
• 工程师是唯一负责保持这个结构正常运行的人。

即使面临这些挑战，团队仍然认为应该继续自动化。但这些并不是唯一的挑战。

未来的道路

如前所述，一些场景需要物理移动设备和电器。我们仍然需要在自动化过程中克服这一挑战，因为测试运行在云环境（Maestro 云服务）中，没有物理设备。

在我们进行研究时，没有考虑任何 AI 工具作为选项。然而，我们现在看到市场上有一些新工具，可能适合我们。

虽然自动化进展顺利，但我们认为现在还不是移除手动测试的时机。一旦更多的场景被实现，并且我们对自动化套件的信心增加，我们就可以开始逐步淘汰手动测试，确保不因为取消手动测试而降低应用程序质量。在此之前，我们将继续自动化我们的场景，编写流程，处理支持任务，评估结果，并根据需要调整计划。

结论

这个项目正在进行中，随着我们不断改进方法，有着巨大的发展潜力。我们做出的决定基于我们当前的理解，但它们绝不是最终的。我们不断学习并调整策略，以确保它与我们的目标一致：交付高质量的应用程序，并帮助数百万家庭厨师获得更好的烹饪结果。

希望这次讨论为您的自动化旅程提供了宝贵的见解并激发了新的想法。无论您是刚刚开始还是已经深入自动化，记住灵活性和持续学习是关键。