在写《iOS APP灰度发布方案》时，也仅是刚开始使用TestFlight的灰度方案。是实际操作过程中，TestFlight总体上能满足灰度测试的需求，但并不算一种完美的灰度方案。
TestFlight的局限性
TestFlight的机制实际上是邀请制，向指定用户下发邀请链接（邀请码），用户可以选择参与灰度，也可以选择拒绝，主动权在用户手中，无法精细控制。弥补这一缺陷的方式是加大灰度的用户量，但加到多大才算合适呢？以看川所在团队开发的产品为例，日活近百万，在使用TestFlight的灰度时，实际有效的灰度用户往往才2、3千人，更多的被发起邀请的用户选择忽略邀请。这个数量级可能不足以发现一些隐藏的很深的问题。当然，可以使用激励手段鼓励用户尝鲜，这就是技术之外的问题了。
TestFlight面向的是已经安装过该APP的“老用户”，某些只有新用户才能触发的业务流程是覆盖不到的。看川所在的团队已经在这里踩过一次坑。当我们信心满满的更新一项和新用户有关的功能时，在TestFlight阶段没有收到异常反馈，以为完全没问题了。没料到在AppStore的分阶段的自动更新阶段收到了一些crash报告。尽管这个crash问题影响并不大，但我们还是对这个事件做了一次内部的复盘。这个问题如果能在TestFlight灰度阶段暴露出来，是完全可以避免的，但受限于TestFlight的机制，在加上开发测试阶段并未复现，这个问题被完美的忽略。
更加优秀的方案是什么？
TestFlight并不是完美的灰度方案，尽管它能帮助我们发现绝大多数问题。那么，更加优秀的方案是什么呢？
我们总是要追求完美，但遗憾的是，这个问题至少在我们团队并没有很好的答案（如果你有更优雅的方式，欢迎告诉我）。
我们可以做的，就是优化从产研、测试到交付的流程，尽量在发版之前将问题暴露并解决。这个过程中，可以做的事情很多，比如建立代码评审、性能用量、自动化测试等的标准。每一项都需要花精力去做，虽然很耗时，但从长期来看，对于保证产品的稳定性是非常有益的。
我也注意到，有一些大型的团队，在TestFlight的基础上，也建立了一套通过企业包形式分发的测试渠道。在产品内部测试完成后，将企业安装包通过QQ群、微信群等方式分发给愿意尝鲜的用户，可以通过一些适当的奖励来激发用户测试的积极性。这种形式，因为可以和用户直接交流，可以做到针对性的测试。这种方式，如何保证测试的有效性和企业版不被恶意使用，是需要重点考虑的问题。
不要寄希望通过一种方式解决APP稳定性问题，稳定性的建设应该是贯彻到开发、测试、灰度的流程中。同时，也希望未来Apple能优化TestFlight的使用体验。
留言板