1 背景

iOS 应用版本灰度测试是一个越来越令人头疼的一件事。

在 iOS9.0 之后，iOS 越狱设备越来越少，想要找到参与灰度测试的越狱用户越来越难。现在苹果企业签名的包外发控制越来越严格，这条路也很难走了。

因此，只能走苹果官方推荐的方式，通过 TestFlight 进行邀请测试。

关于 TestFlight 使用方法，已经有很多人总结过了，这里不赘述。比如：

iOS 平台如何使用 TestFlight 进行 Beta 测试

TestFlight 的测试分为“内部测试”和“外部测试”，“内部测试”能邀请的人数比较少，只有 25 人，适用于内部测试人员测试功能，“外部测试”可以邀请 2000 人，适用于发布正式版之前进行灰度测试。本文主要描述的是“外部测试”的方案。

 

2 TestFlight 标准流程

收集外部测试用户的邮箱（这个邮箱不一定是 Apple ID 邮箱）。

提交 TestFlight 测试版本，等待审核通过。

审核通过后，在 TestFlight 中导入灰度用户名单。

等待用户接收邀请测试的邮件，并预先到 AppStore 安装 TestFlight。

用户点击邮件中的 Start Testing 打开有“邀请码”的页面，复制 8 位大写英文字母的“邀请码”。。

用户打开 TestFlight（需要登录 Apple ID），点击下方的 Redeem ，将“邀请码”粘贴到输入框中，点击右上角的 Redeem ,即可开始下载测试的 App 。

流程中一个很重要的点是“邮箱”，这是苹果连接用户的唯一媒介。在现实中，收集用户邮箱不是一件很容易的事情，很难在短时间内联系到大量的用户，并提供邮箱，或者有些人很少打开邮箱，或者在手机上不方便打开邮箱。导致灰度测试效果不好，即使费时费力搜集了用户的邮箱，转化率也可能不高。

思考：有没有办法简化“邮箱”这一步呢？

3 TestFlight 优化流程

从上述流程中可知，邮箱不一定是 Apple ID 邮箱，只要能接受苹果发出的 TestFlight 的邮件就可以，用户收到邮件后，是通过点击邮件中的链接来获取到“邀请码”的，为这个优化留下了可能性。

优化目标：用户可以直接拿到“邀请码”，直接在 TestFlight 输入邀请码后下载 App。

3.1 准备 2000 个内部邮箱，用来接收 TestFlight 的邀请邮件

可以通过某些途径，在内部准备好 2000 个邮箱，什么 QQ邮箱、163邮箱、126邮箱、新浪邮箱、hotmail、gmail 等等一批免费邮箱，而且每个邮箱都还能设置几个不同名的账户，比如一个 QQ 号排除手机号之外就可以有 4 个邮箱名（[email protected], [email protected], [email protected], [email protected]）。所以要准备 2000 个邮箱账号也不是特别难的事情。不过为了方便自动化，*好还是申请单独某个类型的邮箱好一点，后面会说到。

3.2 提取邀请邮件中的邀请链接

收到的“邀请邮件”中有个 Start Testing 的按钮，点击之后打开一个有“邀请码”的页面。

如果要一封一封邮件点开来查看邀请码，那确实也太费人力了，这里能否开发一个自动化工具来查看邮件呢？应该也不是特别难的事情，苹果的邮件格式基本上是固定的，这个自动化工具开发好之后是一劳永逸的事情。

Start Testing 打开的链接格式大概是这样的：

https://beta.itunes.apple.com/v1/invite/1ae8b3e5f47847d7a6a798222e2a2ef96fd24005bce24ff8a4de5bd41c5dc882460c5711?ct=TencentTechnologyShanghaiCoLtd&advp=10000&platform=ios

打开链接之后，Chrome 可以通过开发者工具查看页面元素，如此可以开发一个自动化提取“邀请码”的工具。

3.3 优化后的流程

提交 TestFlight 测试版本，等待审核通过。

审核通过后，在 TestFlight 中导入事先准备的 2000 个邮箱账号。

等待接收邀请测试的邮件，待接收到之后，通过自动化工具提取邀请链接，并保存。

通过自动化工具打开邀请链接提取“邀请码”。

将邀请码直接发放给灰度测试用户。

用户打开 TestFlight（需要登录 Apple ID），点击下方的 Redeem ，将“邀请码”粘贴到输入框中，点击右上角的 Redeem ,即可开始下载测试的 App 。

3.4 优化后的流程优点分析

免去了前期收集用户邮箱的困难，而且每次的版本灰度测试，每个 App 的版本灰度测试，都要做一遍这个事情，消耗大量的运营精力，而且效果可能还不是很好。

有时候可能不一定一开始就能收集到那么多的用户，可能是一批一批地邀请用户，也免去了每次去 iTunes Connect 添加邮箱的麻烦。

2000 个测试名额，可以*大化地利用，按需分配邀请码，而不是添加了一堆不参与测试的用户邮箱。

一套方案，可以多个项目使用，甚至可以推广至全公司。*终做出一个自动化的工具或框架，任意App可以接入，也不需要理解太多细节。

上面优化后的流程中的第 4 点，是打开邀请链接之后提取“邀请码”出来，*后直接分配“邀请码”给用户，但是这里有一个坑，“邀请码”只有两个小时有效期，如果我们把邀请码提取出来了，必须在两个小时之内，发放给用户，并且在 TestFlight 中激活使用，否则“邀请码”会过期。不过过期之后，重新打开邀请链接，会生成新的“邀请码”。

另一个方案是直接把“邀请链接”发放给用户，让用户在开始体验 App 时，点开链接提取“邀请码”。

这两种方案各有利弊，发放“邀请码”给用户的方式，减少用户的学习成本。而且可以更加*大化地利用测试名额，*次发放“邀请码”之后，如果两个小时之内用户没有使用。那么该邮箱的名额不会浪费，可以重新通过自动化工具提取“新的邀请码”，发放给第二批用户。