TestFlight 测试

在正式提审之前，用 TestFlight 做一轮真实设备测试，是降低被拒风险、提升版本质量最有效的手段。本章讲清 TestFlight 的内部测试（Internal）与外部测试（External）的区别、测试组的管理、构建分发与反馈收集，以及外测审核的注意事项。

内测与外测的区别是最该先记住的一件事，因为它决定了谁能装你的构建、多快能装上，以及落地之前 Apple 会不会先看一眼。内测最多覆盖你自己团队的一百名成员，完全不需要审核，因此是现有条件下最快的一轮反馈；外测则可以触达一万名测试者，并且要走一遍 Beta App Review——虽然比正式提审轻，但你的构建和它的描述仍然会被一个人读一遍。接着就落到一个很实际的问题：测试组该怎么组织，才能让团队、你的 Beta 用户和更广的受众各自拿到本来就要给他们测的那个构建，而不是所有人一股脑收到全部内容，同时又能看清每个人的测试资格和公开链接，不至于搞不清谁被邀请到了哪里。

读完这一章，你将能够按场景、人数上限和审核要求区分内部测试与外部测试；能把构建上传到 TestFlight 并分别创建内测和外测测试组；能通过邮件或公开链接邀请测试员，并随时间管理他们的测试资格；能把测试员的反馈和崩溃报告读成一份具体的「提交前问题清单」，而不是一堆含糊的抱怨；还能规划出成熟团队遵循的「内测 → 外测 → 提审」标准发布流程。想要快速拿到内部验证结果，就从内测入手，几分钟就能跑一轮；需要在团队之外拿到真实用户的验证，就盯住外测，并且在向任何人承诺时间之前先记住 Beta App Review 这道审核。每次发布之前，都要把反馈与崩溃那部分再过一遍，因为绝大多数被拒其实是在这里被挡下来的。