假设测试对移动应用程序需要花费多长时间？ 让我们数一下：
- 针对不同用户组以不同模式工作的应用程序的开发。
- 测试结果。
- 将应用程序放入应用商店并等待批准。
- 等待用户更新应用程序。 在2019年，大多数人都启用了自动更新功能，但并非所有人都有。
- 收集和分析统计数据。
- 将应用程序带入胜出假设的状态，同时开发以下内容...
如果您的开发人员使用两周的迭代来开发Scrum，这通常意味着测试假设需要一个月的时间。 使用其他方法，可以缩短此期限，但不会明显缩短。
这种情况使得无法实现“每周5个假设”的节奏，这是许多产品团队所追求的。
下面，我将告诉您如何加快和改进此过程，并指出可以使用的许多现成的解决方案。
走吧
打开和关闭
在深入研究细节之前，您需要输入一个附加术语-Feature标志（功能切换）模式 。
对于没有技术背景的读者，可能需要澄清以下内容：
开发某些新功能时，程序员在应用程序代码中引入了一个“开关”以激活该功能。 通常，此解决方案用于保留通用程序代码中未完成的功能，但是，当然，它也可以用于检验假设。
要在测试实验中使用Feature标志模式，您将需要：
- 全面开发的功能可用于实验。
- 它的开关处于默认状态“关”。
- 来自服务器的远程开关控制。
问题是，如果在进行A / B测试之前仍需要开发该功能，可以节省多少时间？ 让我们尝试分析实验的各个阶段：
我们在这里看到什么？
首先，使用Feature标志，我们可以在完全测试错误之前将应用程序上载到应用程序商店。 我们只需要确保在关闭新功能时，应用程序的行为就与以前一样-可以使用先前编写的自动测试来完成。 其余的可以在应用程序在用户之间分发时进行测试。
其次，实验完成后，您可以使用Feature标志来启用/禁用所有用户的功能，直到准备好下一个版本为止，该版本将不再使用。
正是基于这一原则， Apptimize服务起作用 ，为A / B测试提供了现成的系统。
分析
要进行实验，您需要做几件事：
- 如果实验并不适合所有人，请选择一个用户群。
- 选择观众人数。
- 不仅要收集经过实验验证的数据，还要收集数据。 将需要其余业务指标，以确保实验不会破坏其他指标。
- 收集并分析结果。
如果您不使用Apptimize的现成解决方案，则最简单的方法是将Google Analytics（分析）用于Firebase进行分析，并使用Firebase Remote Config来设置单独的配置（细分和测试）。 这些工具旨在协同工作。
因此，您需要：
- 使用Google Analytics for Firebase跟踪业务指标。
- 使用Firebase远程配置来管理功能标记。
- 使用Firebase远程配置指定段和实验参数。
- 使用分析中Firebase远程配置中的键来分析Google Analytics（分析）中的数据。 这些工具“开箱即用”提供此功能。
我们将进一步优化
我们研究了如何缩短移动应用程序的假设测试周期，减少测试时间和传播实验结果的时间。 但是这种方法不允许浪费时间来批准和分发应用程序。 这种方法“每周5个假设”的目标仍然不太现实。
为了加快实验速度，您需要能够开发和发送新功能，而不必更新应用程序。 要实现此目的，必须使用动态用户界面。 但是，这种方法存在以下问题：
一方面，根据从外部接收的设置，接口的结构存在技术限制。 大多数移动开发框架在不可能或非常困难的地方使用声明性方法。
另一方面，应用程序商店策略禁止下载和执行任意代码，因为它可用于违反应用程序商店规则的功能。
另一个限制是从Firebase远程配置传输的数据量。 它不能用于传输整个接口。 最好仅在其中存储接口的特定版本的“密钥”，并且在更改此代码时，请从第三方服务加载接口。 就其本身而言，它不限制移动开发框架的选择，但需要额外的实现工作。
最佳解决方案是一种方法，其中仅动态构建用户界面，而业务逻辑保持固定。 由于绝大多数产品实验都与界面有关，因此您可以保持较高的工作节奏。 同时，根据上述带有标志的过程，可以并行执行需要优化业务逻辑的实验。
从技术上讲，这种方法最容易在具有以下特征的框架中实施：
- 默认情况下，不使用声明性方法的反应性，高性能用户界面。
- 支持Google Analytics for Firebase和Firebase远程配置。
- 需要跨平台的解决方案来总体上加快开发速度。
最好，Flutter框架满足这些条件。 作为这种方法的概念验证，对他来说，有一个库可以让您创建动态接口 。
使用Flutter，Google Analytics for Firebase和Firebase Remote Config创建的动态界面，您可以开发可与网站进行比较的应用程序，并轻松进行假设测试。