iOS TestFlight的局限性及改进措施 / 2020-05-26

这是对之前文章《iOS APP灰度发布方案》的补充,主要介绍TestFlight方案的局限性以及改进措施。

在写《iOS APP灰度发布方案》时,也仅是刚开始使用TestFlight的灰度方案。是实际操作过程中,TestFlight总体上能满足灰度测试的需求,但并不算一种完美的灰度方案。

TestFlight的局限性

TestFlight的机制实际上是邀请制,向指定用户下发邀请链接(邀请码),用户可以选择参与灰度,也可以选择拒绝,主动权在用户手中,无法精细控制。弥补这一缺陷的方式是加大灰度的用户量,但加到多大才算合适呢?以笔者所在团队开发的产品为例,日活近百万,在使用TestFlight的灰度时,实际有效的灰度用户往往才2、3千人,更多的被发起邀请的用户选择忽略邀请。这个数量级可能不足以发现一些隐藏的很深的问题。当然,可以使用激励手段鼓励用户尝鲜,这就是技术之外的问题了。

TestFlight面向的是已经安装过该APP的“老用户”,某些只有新用户才能触发的业务流程是覆盖不到的。笔者所在的团队已经在这里踩过一次坑。当我们信心满满的更新一项和新用户有关的功能时,在TestFlight阶段没有收到异常反馈,以为完全没问题了。没料到在AppStore的分阶段的自动更新阶段收到了一些crash报告。尽管这个crash问题影响并不大,但我们还是对这个事件做了一次内部的复盘。这个问题如果能在TestFlight灰度阶段暴露出来,是完全可以避免的,但受限于TestFlight的机制,在加上开发测试阶段并未复现,这个问题被完美的忽略。

更加优秀的方案是什么?

TestFlight并不是完美的灰度方案,尽管它能帮助我们发现绝大多数问题。那么,更加优秀的方案是什么呢?

我们总是要追求完美,但遗憾的是,这个问题至少在我们团队并没有很好的答案(如果你有更优雅的方式,欢迎告诉我)。

我们可以做的,就是优化从产研、测试到交付的流程,尽量在发版之前将问题暴露并解决。这个过程中,可以做的事情很多,比如建立代码评审、性能用量、自动化测试等的标准。每一项都需要花精力去做,虽然很耗时,但从长期来看,对于保证产品的稳定性是非常有益的。

我也注意到,有一些大型的团队,在TestFlight的基础上,也建立了一套通过企业包形式分发的测试渠道。在产品内部测试完成后,将企业安装包通过QQ群、微信群等方式分发给愿意尝鲜的用户,可以通过一些适当的奖励来激发用户测试的积极性。这种形式,因为可以和用户直接交流,可以做到针对性的测试。这种方式,如何保证测试的有效性和企业版不被恶意使用,是需要重点考虑的问题。

不要寄希望通过一种方式解决APP稳定性问题,稳定性的建设应该是贯彻到开发、测试、灰度的流程中。同时,也希望未来Apple能优化TestFlight的使用体验。

其它文章

iOS APP灰度发布方案
iOS Appium自动化测试框架原理简析
iOS DeviceCheck详解
iOS 13 Scene Delegate and multiple windows