TestFlight 怎么使用？iOS App 内部测试、外部测试与 Beta Review 完整指南
iOS App 开发完成以后，通常不会直接提交 App Store 正式审核。
在真正发布之前，开发团队往往需要先进行：
内部测试。
客户测试。
小范围用户测试。
Beta 测试。
Apple 为开发者提供的官方测试工具就是：
TestFlight。
通过 TestFlight，开发者可以把 App 的测试版本发送给团队成员或者外部测试用户，在正式上线之前提前发现崩溃、功能异常、UI 问题以及业务流程问题。
Apple 当前允许每个 App 添加最多 100 名内部测试人员，以及最多 10,000 名外部测试人员。测试 Build 最长可以测试 90 天。
一、什么是 TestFlight？
TestFlight 是 Apple 官方提供的 Beta App 测试平台。
开发者将测试版本上传到 App Store Connect 后，可以通过 TestFlight 把测试版本分发给指定用户。
测试人员不需要开发者手动收集设备 UDID，也不需要单独制作普通 Ad Hoc Provisioning Profile。
用户只需要安装 TestFlight App，然后接受邀请，就可以安装测试版本。
所以 TestFlight 是 iOS App 正式上架之前非常常见的一步。
二、TestFlight 和正式 App Store 上架有什么区别？
TestFlight 是：
测试。
App Store 是：
正式发布。
TestFlight 中的 App 主要面向测试人员。
正式发布以后，则面向 App Store 用户。
两者流程不同。
例如外部 TestFlight 测试可能需要进行 TestFlight App Review，但这并不等于正式 App Store Review。
即使 TestFlight 测试版本通过，正式提交 App Store 时仍然需要按照正式审核流程处理。
三、上传 TestFlight Build 前需要什么？
通常需要先完成：
Apple Developer Program 会员。
App Store Connect 中创建 App。
Bundle ID。
Certificates。
Provisioning Profiles。
Xcode 签名。
然后使用：
Xcode。
Transporter。
或者其他 Apple 支持的上传方式。
把 Build 上传到 App Store Connect。
这和我们第6天已经写过的：
Certificates、Identifiers、Profiles
正好可以形成内链。
四、Build 上传以后在哪里看？
登录 App Store Connect。
进入：
Apps → 选择对应 App → TestFlight
就可以看到上传的 Build。
Build 完成处理以后，就可以用于后续内部测试或外部测试。
Apple 官方说明，一个 TestFlight Build 最长可供测试 90 天。
超过有效期以后，需要重新上传新的 Build。
五、什么是内部测试？
内部测试也就是：
Internal Testing。
主要用于开发团队内部测试。
内部测试人员必须是 App Store Connect 中拥有相应访问权限的用户。
Apple 当前最多支持 100 名内部测试人员。
例如：
Account Holder。
Admin。
App Manager。
Developer。
Marketing。
这些相应角色可以被加入内部测试。
六、内部测试适合什么场景？
例如：
开发人员测试新版本。
公司产品经理测试。
设计人员检查 UI。
运营人员检查文案。
公司内部 QA 测试。
客户公司内部人员测试。
内部测试最大的特点就是：
速度比较快，适合开发团队快速迭代。
如果每天都有新版本，内部测试通常是非常实用的方式。
七、怎么添加内部测试人员？
大致流程是：
进入 App Store Connect。
选择 App。
进入 TestFlight。
创建 Internal Testing Group。
添加 App Store Connect 用户。
再把 Build 加到这个 Group。
测试人员会收到邀请，然后通过 TestFlight 安装 App。
开发团队还可以设置新 Build 自动分发给内部测试组。
这样更新测试版本会更加方便。
八、什么是外部测试？
如果测试人员不是你 App Store Connect 团队中的用户，就属于：
External Tester。
Apple 当前允许每个 App 最多邀请 10,000 名外部测试人员。
这非常适合：
真实用户测试。
客户测试。
海外用户测试。
产品公测。
不同设备测试。
更大规模 Beta 测试。
九、外部测试和内部测试最大的区别是什么？
一个重要区别是：
外部测试的 Build 可能需要经过 TestFlight App Review。
Apple 官方说明，把 App 的第一个 Build 添加到外部测试组时，该 Build 会送交 App Review，以确认符合相关审核要求。
所以外部测试通常不像内部测试那样上传后直接就能给所有人使用。
十、外部测试需要填写什么资料？
如果准备把 App 分发给外部测试人员，需要提供 TestFlight 测试资料。
例如：
Beta App Description。
Feedback Email。
测试说明。
App Review 需要的信息。
Apple 官方说明，向外部测试人员分发时，需要提供额外的 TestFlight Test Information。
其中 Beta App Description 是必填项。
所以不要等到提交外部测试时才临时写资料。
十一、测试账号要不要提供？
如果 App 需要登录才能使用，那么建议准备审核可以使用的测试账号。
例如：
用户名。
密码。
登录步骤。
特殊验证码说明。
测试环境说明。
否则审核人员如果无法进入 App 的主要功能，就可能无法完成 TestFlight Review。
这一点和正式 App Store Review 也很类似。
十二、怎么邀请外部测试人员？
外部测试常见有两种方式：
Email 邀请。
Public Link。
Apple 当前支持通过电子邮件或者公开邀请链接邀请外部测试人员。
如果测试用户数量少，可以直接使用邮箱。
如果需要大量招募测试用户，则 Public Link 会方便很多。
十三、Public Link 是什么？
Public Link 就是一个公开 TestFlight 邀请链接。
例如你可以把链接发送给：
客户。
社群成员。
测试团队。
论坛用户。
用户点击以后，就可以按照 TestFlight 流程加入测试。
Apple 还允许针对 Public Link 设置一定的测试人员条件，例如设备或平台条件。
十四、Public Link 能限制人数吗？
可以。
创建 Public Link 时，开发者可以设置 Tester Limit。
当前上限仍然是外部测试人员总数范围内的 10,000 人。
这样可以避免链接被大量传播以后测试人数失控。
十五、TestFlight Build 可以用多久？
目前每个 TestFlight Build 最长可以测试：
90 天。
所以 TestFlight 并不是长期替代 App Store 发布的方式。
如果 90 天后仍然需要继续测试，就需要提供新的 Build。
十六、TestFlight 可以查看测试反馈吗？
可以。
测试人员可以通过 TestFlight 提交反馈。
Apple 当前允许开发者在 App Store Connect 中查看：
截图反馈。
崩溃相关反馈。
普通文字反馈。
这也是 TestFlight 非常实用的地方。
开发团队可以在正式上架前集中处理真实用户反馈。
十七、还能看到测试人员数据吗？
可以。
App Store Connect 可以显示一定的 Tester Metrics。
例如：
测试邀请状态。
安装情况。
Sessions。
Crashes。
Feedback。
设备。
OS。
Apple 说明，相关测试指标可能需要一定时间才会出现在后台。
这对判断某个测试版本是否稳定非常有价值。
十八、TestFlight 能不能测试内购和订阅？
可以。
TestFlight 也支持对 Subscription 和 In-App Purchase 等场景进行测试。
Apple 对 TestFlight 中的订阅续订周期进行了加速处理，方便开发者更快测试订阅逻辑。
如果你的 App 有：
会员。
订阅。
内购。
付费功能。
建议在正式上架之前把相关流程完整测试。
十九、测试完成后能不能停止某个 Build？
可以。
开发者可以在 App Store Connect 中选择：
Expire Build。
Build 被停止以后，内部和外部测试人员就不能继续安装这个版本。
如果发现某个 Build 存在严重 Bug，就可以及时停止测试。
二十、TestFlight 通过是不是代表 App Store 一定过审？
不是。
这一点一定要分开。
TestFlight App Review ≠ App Store 正式审核。
测试版通过，只代表这个 Build 可以按照 TestFlight 的流程进行外部测试。
正式 App 上架仍然需要提交 App Store Review。
所以不能宣传：
“TestFlight过了，正式审核就一定过。”
两者不是同一件事。
二十一、建议的 TestFlight 测试顺序
一个比较清晰的流程是：
第一，开发完成基本功能。
第二，上传 Build。
第三，先做 Internal Testing。
第四，修复明显 Bug。
第五，准备 TestFlight 测试资料。
第六，创建 External Testing Group。
第七，提交需要的 TestFlight Review。
第八，邀请真实外部用户测试。
第九，收集 Crash 和 Feedback。
第十，修复以后再准备正式 App Store 提交。
这样比开发完成后直接提交正式审核更稳妥。
二十二、这篇文章在我们矩阵里的作用
前面我们的 Apple / iOS 内容已经覆盖了：
开发者账号。
D-U-N-S。
团队权限。
证书签名。
App Transfer。
App Privacy。
现在加入：
TestFlight。
整个链路就继续向“正式上架前测试”推进。
目前可以形成：
Apple Developer账号 → Certificates → Build → TestFlight → App Privacy → App Store Review → App发布
这就是我们想要的主题矩阵。
总结
TestFlight 是 iOS App 正式发布以前非常重要的测试工具。
最需要理解的是三个概念：
Internal Testing：内部团队快速测试。
External Testing：面向外部用户的大规模测试。
TestFlight App Review：部分外部测试版本需要经过的审核流程。
通过 TestFlight 提前测试功能、崩溃、登录、订阅和实际用户体验，可以减少正式上架以后才发现问题的概率。
