哪种是测试 Flutter 应用程序的最佳方法

Posted 2023-02-19

【中文标题】哪种是测试 Flutter 应用程序的最佳方法

【英文标题】：Which is the best approach for testing Flutter Apps

【发布时间】：2021-10-30 20:48:13

【问题描述】：

我正在为一个依赖 API 的 Flutter 应用程序工作。我们正在考虑一种测试策略，我们想知道哪种方法最好。

根据他们的文档 (https://flutter.dev/docs/testing)，他们有 3 个级别的测试：

单元测试 小部件测试 集成测试（Pump 小部件新方法） 集成测试（Flutter 驱动程序旧方法）

由于我们的资源有限，我们想知道我们应该先拿什么。从那时起，很少有人在测试上投入精力。

我们的情况如下：

单元测试（50% 覆盖率） 小部件测试（0% 覆盖率） 集成测试（泵小部件新方法 - 0% 覆盖率） 集成测试（Flutter 驱动程序旧方法 - 仅涵盖少数测试场景，主要流程） API 测试：单元测试和功能测试的覆盖率为 0%

而且我们没有使用任何测试自动化框架，例如 WebdriverIO + Appium。

我们想知道我们应该在每个 Flutter 测试类别中投入多少精力，以及关于 Flutter 集成测试，是否只使用新方法（Pumping every widget）进行集成测试是否有意义，或者我们也会需要集成测试（Flutter 驱动程序旧方式）？仅仅依靠使用泵小部件方法进行集成测试并不会让我们感到非常自信。

我们正在考虑的一些选项是：

强大的 API 覆盖率（单元测试和功能测试）+ 强大的 Flutter 单元测试覆盖率 + 使用 Flutter 驱动程序方法的集成测试很少 测试金字塔方法：大量单元测试 + 使用泵小部件新方法、API 测试和小部件测试的较少量集成测试 + 较少量的 E2E 测试（可能使用使用 Flutter 驱动程序方法或外部自动化框架的集成测试）和手动测试 仅单元测试 + 小部件测试 + 集成测试抽水小部件的新方法，力求在三者中实现 100% 的覆盖率。

我们还认为，以新方式（抽取小部件）维护集成测试在某种程度上非常耗时，因为您需要很好地了解应用程序的视图和内部结构。对于没有太多 Flutter 开发经验的 QA 自动化人员来说，这可能具有挑战性。

我应该首先涵盖哪些 Flutter 自动化测试类别，单元测试、小部件测试还是集成测试？我应该改用 WebdriverIO + Appium 等外部自动化框架吗？

【问题讨论】：

请编辑问题以将其限制为具有足够详细信息的特定问题，以确定适当的答案。

【参考方案1】：

首先，此时，我建议从应用程序的角度考虑测试，而不是从 Flutter、React-native 或 Native 的角度考虑，好吧，测试金字塔和测试概念与任何开发工具/框架都没有真正的联系，最终，应用程序必须优雅地做它应该做的事情。

现在，关于策略主题，取决于很多变量，我将只推送一些到这个答案，否则我会在这里写一篇文章。

有一些事情需要考虑，甚至在编写策略之前：

我们什么时候测试？ 本地构建和测试。 远程构建和测试（CI/CD 内容）。 合并前测试（CI/CD 内容）。 生产前测试（CI/CD 内容）。 生产监控测试（CI/CD 的东西）。 我们有足够的资源吗？ 至少一个人专门负责测试及其任务。 由贵公司或云提供商托管的 VM/计算机，用于在 CI/CD 管道中运行测试。

根据我之前的测试经验，当您开始时（覆盖率低），端到端测试确实显示出更多价值，为什么？

主要是关于用户的观点。 它将回答诸如“用户甚至可以登录我们的应用程序并执行核心任务吗？”如果您无法在发布之前回答这个问题，那么您就处于脆弱的境地。李> 介绍应用程序屏幕和功能如何协同工作。 涵盖应用程序如何与后端服务集成。 好吧，如果 API 有问题，它很可能会在 UI 上显示。 涵盖数据是否以对用户有意义的方式保存 它可能在数据库上“错误”，但对于谁使用它仍然有意义。 您不需要 50000 次测试来获得良好的覆盖率，

但这种测试的维护成本仍然很高

。

当您“一无所有”时，金字塔的基础（快速且成本较低的测试）的问题是，您可以进行 50000 个单元测试，但如果核心工作仍然无法回答，为什么？要回答它，您需要接触真实或接近真实的世界，单位不为您提供。你真的只能回答这样的问题：“如果输入无效，它会显示一条花哨的消息。但是用户可以登录吗？”

基础仍然很重要，测试金字塔仍然是一个非常好的用于指导的东西，但我现在对你们的想法，当你们开始时，尝试获得有意义的结束-最终案例，并确保它们正常工作，确保应用程序的核心在每次发布时都在那里，按预期工作，充满信心地发布真的很好。

在某个时候，端到端的数量会增加，并且您会开始看到维护它的成本，因此您可以开始在金字塔的下方向下移动，在 e2e 上进行检查, 现在可以在集成级别、小部件级别等。

测试也是一个迭代和增量的工作，它会随着团队的成熟而改变，试图用它来接近完美的世界，会导致很多有问题的版本，我的总体观点是，首先，尝试进行能够给出有意义答案的测试。

另一个注意事项是：从金字塔的顶部开始，不应该链接到任何开发框架（Flutter、react-native 等）也将让您有时间熟悉 Flutter，同时您仍在为 e2e 覆盖做出贡献，例如使用 Appium（SDETS/QA 必须对它有一定了解）之类的东西，可能是一项并行工作。

【讨论】：

您认为在 Flutter 中实现自动化测试的最佳方法是什么？示例 integration_test 包或带有 flutter_gherkins 包的颤振驱动程序。