针对测试环境测试应用的最佳方式

时间:2016-05-31 12:19:38

标签: android ios testing release

不确定这是否是正确的论坛并努力表达这些问题,但这里有:

我们有一个流程,我们会定期发布testflight应用版本,以便在我们的应用中测试新功能和修复。我们总是将这些构建指向我们的生产环境(API,数据库等)。这会导致我们遇到一些问题:

  • 我们经常尝试测试尚未发布的内容(即后端内容可能尚未更新)
  • 当我们将代码从我们的后端测试环境移动到我们的生产环境时,它可能没有经过测试,因为应用程序从未指向那里。
  • 我们看不到真正的制作用户看到了什么,因为我们总是使用更高级的版本。

我确信有很多方法可以做得更好但是我们未来的一个关键要求是能够发布我们的应用程序的版本,指向我们的测试环境,以便我们能够正确地测试结果 - 结束,以帮助缓解上述问题。与此同时,我们还需要我们的应用程序版本指向生产,因为我们每天都在使用该应用程序。

我能提出的两个显而易见的选择是:

选项1 - 拥有单独的测试和制作应用

我的意思是我们发布了两个带有两个独立的包ID和名称的应用程序(如app_test和app_prod)。然后,您可以同时在手机上加载这两个应用。

选项2 - 相同的应用程序构建为测试或prod

这基本上是我发布指向生产或测试的相同应用程序的地方。您一次只能在手机上拥有一个或另一个。

选项1 感觉是正确的做法,但我遇到了很多问题:

  • 推送和配置证书的配置将更加复杂

  • 如果您有两个正在运行的应用,则很难理解并在手机上调试入站推送通知

  • 我们需要向应用商店提交第二个应用,或者我们需要使用第三方发布工具,例如hockeyapp或其他任何内容。

  • 我们的半自动构建过程需要重新加工以支持多个捆绑ID和内容

选项2 另一方面也存在问题:

  • 您一次只能在一台设备上拥有测试或制作应用。这意味着我们需要从

  • 获得更多设备进行测试
  • 存在向我们的生产用户发布指向测试环境的应用程序的风险。

我想第三种选择是能够重新配置应用程序以使用任一环境(通过隐藏的开发菜单或其他东西)。这涉及我们关于缓存设置但可能可以解决的问题。我想这也意味着我们一次只能在设备上运行一个版本的应用程序。

无论如何,这是一个非常开放的建议问题。我真的很想知道其他人在测试应用程序时正在做些什么。我已经阅读了一些内容并与一些人交谈以获得输入(这是导致我进入上述两个选项的原因)但是会感激更多的输入和建议。你怎么解决这个问题?也许我只是从完全错误的角度接近这个!

0 个答案:

没有答案