Closed 和 Open Beta — 这是什么，应用程序的 Beta 测试如何运作

什么是应用程序的 Beta 测试

Beta 测试 是在正式发布前在真实用户身上检查应用程序的阶段。与由开发人员和 QA 工程师进行测试的 Internal Testing 不同，Beta 测试在外部受众中进行，这些受众在真实条件下、在自己的设备上、使用自己的数据和场景来使用应用程序。

Beta 测试分为两种类型：Closed Beta（封闭式）和 Open Beta（开放式）。在 Google Play 中，两种轨道都可通过开发者控制台访问，在 App Store 中 — 通过 TestFlight。主要区别在于访问方式：Closed Beta 需要邀请，Open Beta 可通过公开链接或商店搜索访问。

为什么需要 Beta 测试

根据 Google Play Console 的研究，Beta 测试可以发现多达 40% 在 Internal Testing 阶段未发现的关键错误。真实用户使用不同的设备型号、操作系统版本和网络条件，这些无法在测试环境中重现。Beta 测试还收集关于 UX/UI 和新功能的定性反馈。

管道中的 Beta 测试阶段

典型的管道如下：Internal Testing → Closed Beta → Open Beta → Production。在 Internal 轨道上稳定后，构建发布到 Closed Beta 供有限的外部受众使用。收集反馈并修复错误后 — 在 Open Beta 中向所有人开放。最终的生产发布在确认 Open Beta 稳定性后进行。

Closed Beta：特点和设置

Closed Beta 是一种通过邀请访问的测试轨道。开发人员设置电子邮件地址列表或创建 Google Group，其成员可访问 Beta 版本。在 Google Play 中，Closed Beta 支持最多 10,000 名测试人员，大大超过了 Internal Testing 的 100 人限制。

在 Google Play 中设置 Closed Beta

要创建 Closed Beta 轨道，请转到 Google Play Console → Release → Testing → Closed Beta。创建测试人员组并指定添加方式：通过电子邮件、Google Group 或邀请链接。上传构建并由 Google Play 检查后，系统会向组成员发送邀请。

// Fastlane — 在 Closed Beta 轨道中发布
lane :closed_beta_release do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "beta",
        release_status: "draft",
        rollout: 1.0
    )
    
    promote_to_play_store(
        track: "beta",
        release_status: "completed"
    )
end

在 Closed Beta 中管理版本

Closed Beta 轨道使用单独的代码版本号。建议分配不与 Internal Testing 和 Production 重叠的 versionCode 范围。例如，对于版本 2.4.0：Internal → versionCode 24000，Closed Beta → 24001，Open Beta → 24002，Production → 24003。这可以防止在轨道之间提升构建时发生冲突。

Open Beta：公开测试

Open Beta 是无需邀请即可供所有用户访问的轨道。在 Google Play 中，Open Beta 在商店中显示为带有 Beta 标签的单独应用程序卡片。任何用户都可以通过公开链接或在 Google Play 中找到应用程序并点击 Become a Tester 来加入测试。

Open Beta 的优势

Open Beta 为测试提供最大的受众覆盖。与样本由开发者确定的 Closed Beta 不同，Open Beta 吸引具有不同设备、习惯和场景的用户。这提供了发布前应用程序稳定性的最完整图像。反馈收集通过 Google Play Rating 和应用程序内问卷进行。

Google Play 中 Open Beta 的限制

Open Beta 适用于任何开发者帐户，但在发布前需要通过审核。Google Play 检查构建是否符合基本要求，就像生产发布一样。批准后，轨道在商店中发布，任何用户都可以订阅。Open Beta 可以随时取消，不会丢失当前安装。

通过 TestFlight 在 App Store 中进行 Beta 测试

在 Apple 生态系统中，外部 Beta 测试通过 TestFlight External Testing 进行。外部测试人员的最大数量为 10,000 人。与 Google Play 不同，TestFlight 不支持在商店中显示的完整 Open Beta — 访问仅通过邀请链接或 Apple 公开页面分发。

TestFlight External Testing 流程

要在 TestFlight External Testing 中发布构建，开发者通过 Xcode 或 Transporter 上传 IPA，然后开始 Beta App Review。Apple 检查构建是否符合基本要求 — 与完整的 App Review 不同，检查需要 1–2 天。批准后，构建可通过链接分发，最长 90 天。要延长有效期，需要上传新构建。

通过 TestFlight 收集反馈

TestFlight 内置支持收集屏幕截图和设备日志。当设备被摇动时，测试人员通过 App Store Connect 向开发者发送报告。每份报告包含堆栈跟踪、屏幕截图、构建版本和设备信息。这简化了错误的复现和修复，无需与测试人员长时间通信。

在 Google Play Console 中设置 Beta 轨道

Closed 和 Open Beta 的设置是在 Google Play Console 的 Release → Testing 部分完成的。该过程需要 15–30 分钟，并且需要在首次使用前进行一次轨道配置。让我们来看看两种 Beta 测试类型的分步说明。

在 Closed Beta 中发布

在 Google Play Console 中，创建测试人员组并将构建上传到 Closed Beta 轨道。系统将检查基本要求，并在 5–15 分钟后构建将对组成员可用。成员会收到包含邀请和通过 Google Play 安装说明的电子邮件。

在 Open Beta 中发布

选择 Open Beta 轨道并上传构建。与 Closed Beta 不同，Open Beta 需要经过审核（如同生产发布），需要 24–48 小时。批准后，应用程序卡片会出现在 Google Play 中，带有 Beta 标签。用户可以通过 Become a Tester 按钮加入测试。

Beta 测试的最佳实践

Beta 测试的有效性直接取决于过程组织的质量。以下是根据大型开发人员经验和 Google Play Console 推荐的经验证实践。遵守这些规则可将错误检测率提高 40–60%。

• 从 Closed Beta 开始，面向 100–500 人的可信受众
• 收集稳定性指标：ANR、崩溃、冻结频率
• 使用内置工具收集反馈（Firebase、Crashlytics、TestFlight）
• 在 Open Beta 之前在 Closed Beta 中对新功能进行 A/B 测试
• 设置测试持续时间：封闭测试 7–14 天，开放测试 14–30 天

反馈和指标分析

Beta 测试完成后，收集所有报告，按优先级分类错误并移交给开发。在 Open Beta 中发现的错误必须在生产发布前修复。参与 Beta 测试的用户通常在正式启动后成为第一批活跃用户。

与 Beta 测试人员的沟通

让测试人员了解更新情况。使用 Google Play 和 TestFlight 的内置通知来宣布新构建。维护包含修复和新功能描述的变更日志。在 Resolution Center（TestFlight）或应用程序页面（Google Play）上回复反馈 — 这可以提高测试人员的参与度。

Beta 测试有效性指标

评估 Beta 测试的关键指标：活跃测试人员数量、报告错误的百分比、首次报告的平均时间和覆盖率（Coverage Rate）— 测试覆盖的设备和操作系统版本的百分比。如果覆盖率低于 40%，通过有针对性的邀请发送添加缺少配置的测试人员。