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

Question

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

flutterunit-testingui-automationflutter-testflutter-integration-test

6

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

根据他们的文档（https://flutter.dev/docs/testing），他们有三个测试级别：

- 单元测试 - Widget测试 - 集成测试（Pump widgets新方法） - 集成测试（Flutter driver旧方法）

由于我们的资源有限，我们想知道我们应该首先选择什么。因为直到现在，对测试只做了很少的努力。

我们的情况如下：

- 单元测试（覆盖率50％） - Widget测试（覆盖率0％） - 集成测试（Pump widgets新方法 - 覆盖率0％） - 集成测试（Flutter driver旧方法 - 仅涵盖少量测试场景，主要流程） - API测试：单元测试和功能测试覆盖率均为0％

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

我们想知道在每个Flutter测试类别中应该投入多少精力，关于Flutter集成测试，仅使用新方法（Pumping every widget）进行集成测试是否有意义，或者我们还需要使用集成测试（Flutter driver old way）？仅依靠使用泵装小部件方法的集成测试并不能让我们感到非常自信。

我们正在考虑一些选项：

1. 强大的API覆盖率（单元测试和功能测试）+强大的Flutter单元测试覆盖率+少量使用flutter driver方法的集成测试 2. 测试金字塔方法：大量的单元测试+较少数量的使用pump widget新方法的集成测试、API测试和小部件测试+较少数量的E2E测试（可能使用集成测试使用flutter driver方法或外部自动化框架）和手动测试 3. 只进行单元测试+小部件测试+使用新方法泵送小部件的集成测试，尝试在这三个领域都达到100%的覆盖率。

我们还认为，以新方法（泵送小部件）维护集成测试有点耗时，因为您需要对应用程序的视图和内部有很好的了解。这对于一个没有太多Flutter开发经验的QA自动化人员来说可能是具有挑战性的。

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

- Tomás Wonderfurt

请编辑问题，将其限制为具有足够细节以确定充分答案的特定问题。 - Community

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Spencer Melo · Accepted Answer

首先，在应用程序的角度考虑测试，而不是Flutter、React-native或Native的角度，测试金字塔和测试概念与任何开发工具/框架都没有真正的关联，归根结底，应用程序必须正常地执行其预定任务。

现在，在策略方面，这取决于很多变量，我将在此回答中仅推出一些，否则我会在这里写一篇文章。

在编写策略之前，有一些东西需要考虑：

- 我们什么时候进行测试？ - 本地构建和测试。 - 远程构建和测试（CI/CD）。 - 撤销合并测试（CI/CD）。 - 预生产测试（CI/CD）。 - 生产监控测试（CI/CD）。

我们是否拥有足够的资源？

至少一个人专门从事测试及其任务。

由公司或云提供商托管的VM/计算机，以在CI/CD流水线中运行测试。

根据我以前的测试经验，当您开始（覆盖率较低）时，端到端测试是显示更多价值的测试类型。为什么？

- 它主要是基于用户视角。 - 它将回答诸如“用户能否登录我们的应用程序并执行核心任务？”这样的问题。如果您无法在发布前回答此问题，那么您就处于脆弱的状态。 - 包括应用程序屏幕和功能如何共同运作。 - 包括应用程序如何与后端服务集成。 - 如果API存在问题，它很可能在UI上可见。 - 涵盖数据是否以对用户有意义的方式持久化存储。 - 您不需要500个测试来获得良好的覆盖范围，但仍然需要花费昂贵的维护费用。

当您没有任何内容时，基础（快速且成本较低的测试）金字塔的问题是，您可以拥有50000个单元测试，但仍然无法回答核心问题。为了回答这个问题，您需要暴露给真实或接近真实的世界，但单元测试并不能提供。你将非常有限地回答诸如：“好吧，如果输入无效，则会显示一条花哨的消息。但是用户能否登录呢？”

基础仍然很重要，测试金字塔仍然是一个非常好的指导方针，但是对于你们这些新手来说，我的建议是尝试获得有意义的端到端用例，并确保它们可以正常工作，每个发布版本的核心应用程序都能按预期工作，这样就可以自信地发布。

随着端到端用例的增加，维护成本也会增加，因此可以将测试金字塔下降一级，原本在端到端上进行的测试现在可以在集成层、组件层等其他层级进行检查。

测试是一个迭代和递增的工作，也会随着团队的成熟而发生变化。试图直接实现近乎完美的测试将会导致许多问题，在最初阶段，尽量编写能提供有意义答案的测试。

另外一个注意点是：从金字塔的顶部开始进行测试并不应该与任何开发框架（如Flutter、React Native等）相链接。这将为你提供时间来了解Flutter，同时仍然贡献于端到端覆盖范围。例如，可以使用Appium（SDETS/QA必须熟悉它）进行并行工作。