TestFlight：是什么、Beta测试与构建版本管理

什么是TestFlight

TestFlight — 是唯一官方且合法的方式，用于在不在App Store上发布的情况下分发iOS应用程序进行测试。该服务于2014年由Apple在收购同名公司后推出。在TestFlight出现之前，开发者使用Ad Hoc分发，每个季度限制100台设备——TestFlight移除了这一限制，并将过程简化为几次点击。

为什么需要TestFlight

iOS有严格的安全策略：应用程序只能通过App Store或使用特殊证书安装在设备上。TestFlight通过在开发者和测试人员之间充当代理来解决Beta测试问题：Apple检查构建版本是否符合基本要求，之后测试人员通过App Store中的TestFlight应用程序接收应用程序，这不需要信任未签名的文件。

TestFlight vs Ad Hoc vs Enterprise

有三种在App Store之外分发iOS应用程序的方式：Ad Hoc（100台设备限制，需要每台设备的UDID）、Enterprise（无限制的企业内部分发，需要每年299美元的Apple Enterprise证书）和TestFlight（多达10,000名测试人员，免费，无需收集UDID）。TestFlight是Beta测试的最佳选择，Ad Hoc适用于特定设备的测试，Enterprise适用于企业应用程序。

TestFlight如何工作

通过TestFlight发布构建版本的过程包括五个步骤：在Xcode中构建、通过Archive Organizer上传到App Store Connect、Apple处理、邀请测试人员、通过TestFlight应用程序安装应用程序。每个步骤根据项目的复杂程度需要几分钟到一小时不等。

Apple对构建版本的要求

构建版本必须使用分发证书和正确的provisioning profile构建。Apple检查：证书的有效性、bundle identifier的一致性、没有私有API、图标的正确性（1024×1024）以及App Store图标的存在。如果构建版本未通过检查——TestFlight会显示错误并描述问题。

构建版本处理过程

上传后，构建版本通过Apple的自动检查：二进制代码的静态分析、数字签名检查、扫描私有API和恶意软件的使用。处理对于第一个构建版本需要15分钟到2小时，对于后续构建版本通常需要15–30分钟。处理状态显示在App Store Connect的Activity中。

// 在Swift AppDelegate中配置TestFlight
import UIKit

@main
class AppDelegate: UIResponder, UIApplicationDelegate {
    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        // 检查：应用程序是否通过TestFlight安装
        if Bundle.main.appStoreReceiptURL?.lastPathComponent
            == "sandboxReceipt" {
            print("Beta version via TestFlight")
        }
        return true
    }
}

内部和外部测试人员

TestFlight将测试人员分为两组：内部（Internal Testers）和外部（External Testers）。区别在于参与者数量、对构建版本的访问权限以及是否需要Apple审核。正确选择组别可以加快测试过程并遵守App Store政策。

内部测试人员（Internal）

来自Apple Developer Program团队的最多100名参与者。要邀请内部测试人员，只需在App Store Connect中添加其Apple ID——他立即获得对所有构建版本的访问权限。无需Apple审核。非常适合日常冒烟测试和早期阶段的功能检查。

外部测试人员（External）

最多10,000名参与者，不属于开发团队。外部测试人员的第一个构建版本经过基本的Apple审核（通常1–2天）。后续不涉及关键功能的更改的构建版本可以无需重新审核通过。外部测试人员通过电子邮件或公共链接邀请。

如何将构建版本上传到TestFlight

将构建版本上传到TestFlight可以通过Xcode、Application Loader或使用xcrun的命令行完成。最常见的方法——在创建项目存档后通过Xcode Archive Organizer。替代方法——通过Fastlane为CI/CD Pipeline实现自动化。

通过Xcode手动上传

创建存档（Product → Archive），打开Organizer，选择存档并点击Distribute App。选择TestFlight作为分发方法，指定证书和provisioning profile。Xcode将构建版本上传到App Store Connect，处理后即可显示。整个过程对于首次上传需要10–20分钟。

通过Fastlane自动化

Fastlane — 是自动将构建版本上传到TestFlight的最流行工具。fastlane pilot命令无需打开Xcode即可上传构建版本并管理测试人员。Fastlane与CI/CD服务器的集成允许在所有测试通过后自动在TestFlight中发布构建版本。

# Fastfile — 将构建版本上传到TestFlight
default_platform(:ios)

lane :beta do
    # 通过match获取证书
    match(type: "appstore")

    # 构建和签名
    build_app(
        scheme: "MyApp",
        export_method: "app-store",
        workspace: "MyApp.xcworkspace"
    )

    # 上传到TestFlight
    pilot(
        skip_waiting_for_build: true,
        distribute_external: false,
        notify_external_testers: false
    )
end

Fastlane pilot自动将IPA上传到App Store Connect，等待处理（如果skip_waiting_for_build = false）并将构建版本分配给选定的测试人员组。distribute_external: true命令在处理后立即将构建版本发送给外部测试人员。

通过命令行上传

没有Fastlane，可以使用xcrun：xcrun altool --upload-app --file path/to/app.ipa --username YOUR_APPLE_ID --password @keychain:AC_PASSWORD。altool受Apple支持用于CI环境，不需要图形界面。密码通过keychain或app-specific password传递——不要使用明文密码。

在TestFlight中收集反馈和诊断

TestFlight提供多种反馈机制：内置反馈表单、自动收集崩溃日志、使用指标和屏幕截图。团队在App Store Connect中接收所有数据，无需为Beta测试实现第三方SDK。

内置反馈表单

测试人员打开TestFlight应用程序，选择您的构建版本并点击Send Feedback。表单允许发送文本反馈、附加屏幕截图并指定严重程度。所有反馈收集在App Store Connect的TestFlight → Feedback部分。开发者可以回复反馈，测试人员将在TestFlight应用程序中收到通知。

崩溃日志和诊断

当应用程序崩溃时，TestFlight自动收集崩溃报告：调用堆栈、操作系统版本、设备型号和崩溃时间。崩溃日志可在Xcode Organizer（Crashes）和App Store Connect（TestFlight → Crashes）中获取。要获取符号化的崩溃日志，需要将dSYM文件与构建版本一起上传或通过Xcode单独上传。

使用监控

TestFlight显示指标：安装数量、活跃测试人员、会话和崩溃次数。分析每天更新，帮助评估测试人员的参与度。如果一周内没有测试人员打开应用程序——值得重新考虑与组的沟通或构建版本的质量。

从TestFlight到在App Store上发布

TestFlight是在App Store上发布过程不可分割的一部分。通过TestFlight经过Beta测试的同一构建版本可以无需重新构建就发送给Apple审核——只需在App Store Connect中点击一个按钮。这消除了生产构建版本与测试版本不同的风险。

Submit to App Review

在App Store Connect中，选择经过测试的构建版本并点击Submit for Review。Apple使用来自TestFlight的同一构建版本——无需重新上传。审核时间通常为1–3天。如果构建版本被拒绝——修正意见，将新构建版本上传到TestFlight并重复该过程。

发布前的最后一个构建版本

建议在TestFlight中进行最终一轮测试后，在提交审核前等待24–48小时。这段时间允许测试人员发现可能通过自动测试的关键错误。Release candidate（RC）构建版本在TestFlight中——是成熟iOS团队的标准实践。

发布后做什么

在App Store中发布正式版本后，TestFlight构建版本会自动变为对新安装不可用。已经安装Beta版本的测试人员可以在发布后30天内继续使用它，之后应用程序将停止打开。确保测试人员已更新到App Store版本。