Internal Testing：本质、工作原理以及如何设置测试轨道

什么是 Internal Testing？

Internal Testing 是 Google Play Console 和 TestFlight 中的一个测试轨道，旨在在开发团队成员之间分发构建包。与开放式 Beta 测试不同，Internal Testing 的访问权限仅限于开发人员帐户所有者批准的电子邮件地址列表。

主要优势是构建包送到测试人员的最短交付时间。在 Google Play 中，Internal Testing 无需审核 — 构建包在上传后 5–15 分钟内出现在参与者面前。在 App Store 中通过 TestFlight，构建包也在没有预先 App Review 的情况下交付，但会经过自动检查以确保符合基本安全要求。

Internal Testing 与其他轨道的区别

Google Play 中有三个测试轨道：Internal Testing、Closed Beta (Open Beta) 和 Production。Internal Testing 是最快且参与者数量最受限的（最多 100 人）。Closed Beta 允许最多 10 000 名参与者，需要设置测试页面。Production 是最终阶段，需要完全审核。

何时使用 Internal Testing

Internal Testing 用于在构建包传递到 Beta 轨道之前进行初步检查。开发人员为 QA 团队上传每日构建包，检查新 SDK 的集成，测试不同操作系统版本的兼容性，并在外部测试人员看到构建包之前发现回归错误。

Google Play 中的 Internal Testing

在 Google Play Console 中，Internal Testing 是一个单独的轨道，位于 Release → Testing 部分。要添加测试人员，只需输入其电子邮件地址 — 参与者将收到邀请和通过 Google Play 加入的链接。构建包通过与生产版本相同的界面上传。

Internal 轨道中的发布流程

开发人员将 App Bundle 或 APK 上传到 Google Play Console 的 Internal Testing 部分。系统检查基本要求：签名、代码版本和 API 兼容性。经过 5–15 分钟的处理后，构建包可供测试人员使用。状态可在控制台中跟踪：Draft、In Review、Ready to Test。

// Fastlane — 在 Internal Testing 轨道中发布
lane :internal_testing do
    gradle(task: ":app:assembleRelease")
    
    upload_to_play_store(
        track: "internal",
        release_status: "completed",
        rollout: 1.0
    )
    
    slack(
        message: "Build uploaded to Internal Testing"
    )
end

管理测试人员

参与者添加通过 Google Play Console 的 Testers 部分完成。可通过 CSV 文件进行批量上传。每个测试人员都会收到包含邀请和安装说明的电子邮件。要撤销访问权限，只需从组中删除参与者 — 已安装的应用程序继续运行，但不再收到新的更新。

App Store 中通过 TestFlight 进行的 Internal Testing

在 Apple 生态系统中，Internal Testing 的角色由 TestFlight 扮演 — 一个用于分发 Beta 版本的平台。TestFlight 支持最多 100 名内部测试人员，通过 App Store Connect 中的电子邮件添加。发布构建包无需经过完整的 App Review，但构建包会自动检查是否符合最低要求。

TestFlight Internal Testing 的特点

与 Google Play 中 Internal Testing 完全不需要审核不同，Apple 会执行自动基本审查。审查需要 30–60 分钟，包括扫描二进制代码以查找恶意 API 和遵守基本要求。审查成功后，构建包将在 24 小时内可供测试人员使用。构建包的有效期为 90 天。

在 App Store Connect 中设置 Internal Testing

在 App Store Connect 中，Internal Testing 在 TestFlight → Internal Testing 部分进行设置。帐户所有者通过电子邮件添加测试人员并分配角色。通过 Xcode 或 Transporter 上传构建包后，系统会通知参与者新版本的可用性。测试人员通过设备上的 TestFlight 应用程序安装应用程序。

如何设置 Internal Testing 轨道

为两个平台设置 Internal Testing 需要 10 到 30 分钟。以下是 Google Play 和 App Store 的分步说明。该过程不需要更改应用程序代码 — 只需一次开发人员控制台配置即可。

与 CI/CD 系统集成

两个商店都支持通过 API 在 Internal Testing 中发布。自动化使用 Gradle Play Publisher（Google Play）和 Fastlane（两个平台）。CI/CD 流水线可以在每次成功通过单元测试和 UI 测试后将构建包上传到 Internal 轨道。

设置测试帐户

对于需要身份验证的应用程序，需要准备测试帐户并将其交给 QA 团队。帐户应有权访问测试环境（staging/development），且不应影响生产数据。建议为 Internal 轨道创建单独的 Firebase 配置。

使用 Internal Testing 的 QA 工作流程

Internal Testing 在通过 CI 中的自动检查后嵌入到 QA 流水线中。开发人员或 DevOps 工程师将构建包上传到 Internal 轨道，之后 QA 工程师收到通知并通过应用商店在测试设备上安装更新。

最佳发布频率

建议每天或在代码库发生重大更改后将构建包发布到 Internal Testing。QA 团队测试关键场景：身份验证、主要用户流程、API 集成和本地存储操作。回归测试每第三或第四个构建包执行一次。

反馈收集工具

要收集错误报告，请使用与跟踪系统的集成：Jira、YouTrack、Trello 或 GitHub Issues。测试人员发送屏幕截图、日志和重现步骤。TestFlight 内置支持在摇动设备时收集屏幕截图和日志 — 数据通过 App Store Connect 发送给开发人员。

与 CI/CD 流水线集成

要在 Internal Testing 轨道中自动发布构建包，请配置 CI/CD 流水线。在通过单元测试和 UI 测试后，脚本将构建包上传到 Internal 轨道并向 QA 团队发送通知。Fastlane 提供了现成的 upload_to_play_store 操作，参数为 track: internal。对于 iOS，使用 Fastlane Pilot 上传到 TestFlight。

Internal Testing 的限制

Internal Testing 对参与者数量有严格限制：Google Play 中最多 100 人，TestFlight 中最多 100 名内部测试人员。Google Play 还限制了组数量 — Internal 轨道最多 1 个组。App Store 不限制构建包数量，但每个构建包的有效期为 90 天。

平台之间的限制差异

Google Play 不限制上传到 Internal 轨道的构建包数量，但 90 天不活动后，轨道可能会自动暂停。TestFlight 有更严格的限制：最多同时 30 个活跃构建包，最多 10 000 名外部测试人员（非 Internal）。要解除限制，需要参与 Apple Developer Enterprise 计划。

从 Internal 迁移到 Open Beta

构建包在 Internal 轨道上稳定后，将转移到 Closed 或 Open Beta 以在外部受众中进行测试。Google Play 允许复制轨道设置并转移构建包而无需重新上传。TestFlight 需要创建单独的外部轨道并添加新的测试人员组。

Internal Testing 轨道的安全性

Internal 轨道中的构建包受保护免受外部访问：只有通过 Google Play Console 或 App Store Connect 授权的参与者才能下载应用程序。即使知道应用程序链接，外部人员也无法安装构建包。这确保了开发阶段新功能的机密性和知识产权的保护。