测试 Flutter 应用程序的最佳方法是什么

Tom*_*urt 6 unit-testing ui-automation flutter flutter-test flutter-integration-test

我正在开发一个依赖 API 的 Flutter 应用程序。我们正在考虑测试策略,我们想知道哪种方法是最好的方法。

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

  • 单元测试
  • 小部件测试
  • 集成测试(泵小部件新方法)
  • 集成测试(Flutter 驱动程序旧方法)

由于我们的资源有限,我们想知道我们应该首先选择什么。到目前为止,我们在测试方面投入的精力很少。

我们的情况是这样的:

  • 单元测试(50% 覆盖率)
  • 小部件测试(0% 覆盖率)
  • 集成测试(泵小部件新方法 - 0% 覆盖率)
  • 集成测试(Flutter 驱动程序旧方法 - 仅涵盖一些测试场景,主要流程)
  • API 测试:单元测试和功能测试覆盖率为 0%

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

我们想知道我们应该在每个 Flutter 测试类别中投入多少精力,以及关于 Flutter 集成测试,仅使用新方法(泵送每个小部件)进行集成测试是否有意义,或者我们还需要集成测试(颤振驱动程序的老方法)?仅依靠使用泵小部件方法进行集成测试并不能让我们感到非常有信心。

我们正在考虑的一些选择是:

  • 强大的 API 覆盖率(单元测试和功能测试)+ Flutter 单元测试的强大覆盖率 + 使用 flutter 驱动程序方法进行的集成测试很少
  • 测试金字塔方法:大量单元测试 + 使用泵小部件新方法、API 测试和小部件测试进行少量集成测试 + 少量 E2E 测试(可能使用使用 flutter 驱动程序方法或外部自动化框架的集成测试)和手动测试
  • 只需单元测试 + Widget 测试 + 集成即可测试泵送 widget 的新方法,试图在三者中分别实现 100% 的覆盖率。

我们还认为,以新方式(泵送小部件)维护集成测试在某种程度上非常耗时,因为您需要充分了解应用程序的视图和内部结构。对于没有太多 Flutter 开发经验的 QA 自动化人员来说,这可能是一个挑战。

我应该首先涵盖哪个 Flutter 自动化测试类别:单元测试、小部件测试还是集成测试?我应该使用外部自动化框架(例如 WebdriverIO + Appium)吗?

Spe*_*elo 5

首先,此时此刻,我建议从应用程序的角度考虑测试,而不是从 Flutter、React-native 或 Native 的角度考虑,好吧,测试金字塔和测试概念并没有真正与任何开发工具/框架联系在一起,最后应用程序必须优雅地执行其应执行的操作。

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

即使在编写策略之前,也有一些事情需要考虑:

  • 我们什么时候测试?
    • 本地构建和测试。
    • 远程构建和测试(CI/CD 的东西)。
    • 预合并测试(CI/CD 的东西)。
    • 生产前测试(CI/CD 的东西)。
    • 生产监控测试(CI/CD 的东西)。
  • 我们有足够的资源吗?
    • 至少有一名专人负责测试及其任务。
    • 由您的公司或云提供商托管的虚拟机/计算机,用于在 CI/CD 管道中运行测试。

根据我之前的测试经验,当您开始时(覆盖率较低),端到端测试确实显示出更多价值,为什么?

  • 这主要是关于用户的角度。
    • 它会回答诸如“用户是否可以登录我们的应用程序并执行核心任务? ”之类的问题。如果您在发布之前无法回答这个问题,那么您的处境就很脆弱。
  • 涵盖应用程序屏幕和功能如何协同工作。
  • 涵盖应用程序如何与后端服务集成。
    • 好吧,如果 API 有问题,它很可能会在 UI 上可见。
  • 涵盖数据是否以对用户有意义的方式保存
    • 它在数据库上可能是“错误的”,但对于使用它的人来说仍然有意义。
  • 您不需要 50000 次测试来获得良好的覆盖范围,但这种测试的维护成本仍然很高

当你“一无所有”时,金字塔的基础(快速且成本较低的测试)的问题是,你可以进行 50000 个单元测试,但仍然无法回答核心是否有效,为什么?为了让你回答这个问题,你需要接触一个真实的或接近真实的世界,单位不会为你提供它。您实际上只能回答这样的问题:“如果输入无效,它会显示一条奇特的消息。但是用户可以登录吗?”

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

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

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

另一个注意事项是:从不应该链接到任何开发框架(Flutter、react-native 等)的金字塔顶部开始,也将为您提供时间来加快 Flutter 的速度,同时您仍在为e2e 覆盖,例如使用 Appium(SDETS/QA 必须对其有一定的熟悉)之类的东西,可能是一项并行工作。