先按人员身份划分内部测试与外部测试
团队准备发布一个新构建时，先不要急着复制邀请链接。第一步应确认测试者是否已经是 App Store Connect 用户，以及他是否有权访问这个 App。符合这两个条件的人可以进入内部测试组；客户、社区用户或其他不属于 App Store Connect 团队的人，应按外部测试员处理。两类人员都使用 TestFlight 安装构建，但管理入口和审核节奏并不相同。
Apple 的官方说明给出的规模上限是每个 App 最多 100 名内部测试员和 10,000 名外部测试员。这个数字是容量边界，不等于团队需要一次邀请到上限。更稳妥的做法是按测试目标建组，例如把登录、支付、硬件兼容性分别交给不同小组，并在组名和 What to Test 中写清版本号、关注功能和反馈截止时间。
- 先确认测试者是不是 App Store Connect 用户，并核对其 App 访问权限。
- 按测试目标建组，避免把内部同事和外部受邀者混入同一交接表。
上传构建前准备测试说明与合规信息
TestFlight 流程从可识别的构建和完整测试信息开始。上传之前，建议把版本号、构建号、目标平台、最低系统要求、已知问题和需要重点验证的路径整理成一页记录。App Store Connect 还提供 Beta App Description、What to Test 和反馈联系信息等字段，外部审核与测试员都会依赖这些内容理解构建用途。
如果 App 使用加密功能，还应按 App Store Connect 的提示确认是否需要提供出口合规信息。上传完成并不代表构建立刻可测，团队需要等待处理状态结束，再检查构建是否出现缺失合规信息、处理失败或其他提示。把上传时间、处理结果和负责人写进交接记录，能避免同一构建被多人重复上传。
- 记录版本号、构建号、平台、最低系统要求和已知问题。
- 构建处理完成后再分组，并先解决 App Store Connect 显示的合规提示。
内部测试组的建立与构建分配
内部测试适合让产品、开发、测试或运营同事先验证关键路径。在 App Store Connect 的 TestFlight 标签页创建 Internal Testing 组后，可以从符合条件的 App Store Connect 用户中选择测试员。Apple 列出的可执行相关操作角色包括 Account Holder、Admin、App Manager、Developer 或 Marketing；实际能否看到某个 App，还取决于该用户的内容访问权限。
内部组可以启用自动分发，也可以手动添加构建。自动分发适合固定的核心回归组，手动添加则适合需要逐批放量的功能。由 Xcode Cloud 创建的构建需要手动加入测试组。若上传时把构建标记为 TestFlight Internal Only，它就只能用于内部测试，之后不能拿同一构建转给外部测试员或客户，因此上传前应把用途写进发布清单。
- 固定回归组可考虑自动分发，敏感功能或分批验证建议手动添加。
- TestFlight Internal Only 是构建级边界，选择前先确认是否还需要外部测试。
外部测试组的邀请顺序与入口
外部测试员不是 App Store Connect 用户。Apple 当前流程要求先有内部测试组，再创建 External Testing 组。建组后选择平台、版本和具体构建，填写 What to Test，并决定获批后是否自动通知测试员。若不启用自动通知，构建通过 TestFlight App Review 后还要由负责人手动开始分发。
邀请方式可以是逐个录入邮箱，也可以共享公开邀请链接。邮箱邀请便于确认具体人员，适合受控的合作方测试；公开链接适合更广的招募，但需要妥善设置人数和准入标准。Apple 支持为公开链接设置设备与系统条件，团队仍应在对外说明中写清测试目的、数据处理方式、反馈渠道和停止测试的安排。
- 外部组先添加构建和 What to Test，再选择邮件邀请或公开链接。
- 公开链接应设置合适的测试员数量与设备、系统条件。
理解 TestFlight App Review 的真实边界
内部测试与外部测试最容易混淆的地方是审核。Apple 的 TestFlight 概览说明：当 App 的首个构建加入外部测试组时，该构建会被送交 App Review；首个构建需要完整审核。审核通过后，外部测试才能开始。内部测试并不等于 App 已通过外部测试审核，也不能据此向外部人员承诺可立即加入。
同一版本后续提交的构建可能不需要完整审核，但这里的关键词是“可能”。团队仍应以 App Store Connect 显示的构建状态为准，并为审核等待预留时间。若功能、元数据或合规信息发生明显变化，也不要假设后续构建一定跳过审核。发布排期可以把“已上传”“处理中”“等待审核”“可开始测试”列成独立状态，减少口头沟通造成的误判。
- 首个外部测试构建按完整审核安排时间，不以内部测试结果代替审核状态。
- 后续构建是否需要完整审核，以 App Store Connect 当时状态为准。
邮件邀请与公开链接的使用边界
邮件邀请适合名单明确的测试。负责人可以按小组导入地址，并跟踪测试员是否接受邀请。测试员需要安装 TestFlight，再从邀请邮件进入并接受测试。公开链接减少了名单维护工作，但链接可能被转发，因此不应把它当作身份验证机制，也不要在链接页面暴露未准备公开的业务资料。
使用公开链接时，可以在 App Store Connect 设定可接受邀请的人数上限，以及设备和操作系统等测试条件。达到组的限制或停止招募时，应及时关闭链接。若测试需要签署保密协议、限定客户组织或核验特定账号，建议使用受控名单和独立的身份确认流程，而不是仅依赖公开链接。
- 名单明确、需要追踪接受状态时优先使用邮件邀请。
- 公开链接可能被转发，不能替代业务侧的身份核验和保密安排。
用 90 天期限管理构建轮换
Apple 说明单个 TestFlight 构建最多可测试 90 天。这个期限从构建可测试的生命周期角度限制了长期使用，因此 TestFlight 更适合作为持续迭代的 Beta 测试渠道，而不是把一个构建长期留给用户。项目排期中应记录每个活跃构建的上传时间、可测试状态和预计到期日。
准备替换构建时，先确认新构建已完成处理和必要审核，再通知测试员更新。测试组里可以保留清晰的版本说明，指出哪些问题已经修复、哪些数据需要重新验证。接近到期日才临时上传，会把构建处理、审核和测试窗口挤在一起；建议在关键测试结束前预留一个轮换周期，并保留旧构建的结果记录。
- 为每个活跃构建记录预计到期日和替换负责人。
- 新构建可测试后再发更新通知，并保留旧构建的反馈归档。
一份可交接的 TestFlight 发布检查表
交接前可以按固定顺序核对：确认测试目标与人员类型；上传正确的版本和构建号；补齐测试说明与合规信息；等待处理完成；先建立内部组并完成核心回归；如需外部测试，再创建外部组、添加构建并提交审核；审核通过后才发送邮件或开放公开链接。每一步都应记录操作人和状态，而不是只写“已发 TestFlight”。
测试进行中还要维护人员名单、公开链接状态、崩溃与反馈记录，以及构建到期日。停止某个构建或结束一轮测试时，及时关闭不再使用的入口并向测试员说明下一版本安排。若 App Store Connect 的页面文字与团队旧文档不一致，应回到 Apple 官方帮助页核对，再更新内部流程。
- 交接记录至少包含构建号、组名、审核状态、邀请方式、负责人和到期日。
- 结束测试时关闭不再使用的邀请入口，并归档反馈与崩溃信息。