苹果的TestFlight应用程序在Android上不适用。 在Android上，官方的最接近的替代品是 不 Google Play Console测试跟踪 , 而苹果的TestFlight iOS模型支持100名内部测试者 10,000名外部测试者, , 需要对外部构建进行审查，这可能需要约48小时 , 并在90天后过期 90 天.
如果您刚刚从iOS转移到Android，这通常是Android发布过程感到奇怪地分散的时刻。iPhone上，“将其发送到TestFlight”是一个明确的指令。Android上，答案取决于您需要什么：快速内部构建循环、受管理的公共测试版或在发布后立即修复正在运行的应用程序而不必再次等待商店。
这意味着什么。Android beta测试不是围绕一个单一的品牌应用程序。它是围绕 分发路径。一些团队完全在Google Play Console内部。其他团队使用Firebase App Distribution以更快的方式将测试者传递给他们，甚至没有触摸Play轨道。并且，如果您正在发布一个Capacitor应用程序，那么beta工具无法解决的另一个发布后问题就是：在应用程序已经进入生产环境后，如何推送紧急的Web资产修复。
目录
- Android 有 TestFlight 吗？
- Android是否有TestFlight?
- 轨道与真实发布工作的映射
- Firebase App Distribution加速迭代
- Firebase比Play轨道更好在哪里？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？？
- Android Beta 分发选项比较
- 传统Beta 分发的局限性
- 超越Beta 测试的Capgo 实时更新
- 构建您的现代Android 发布工作流
Android 有 TestFlight 吗?
没有。 苹果并没有为 Android 开发 TestFlight 原生应用如果您正在寻找 TestFlight 应用的 Android 版本，那么您不会找到它。Google 的第一方路径是 Google Play Console, 在这里测试通过 内部、封闭和开放测试轨迹 而不是一个单独的 TestFlight 风格的应用，正如本文中对 Android 测试 TestFlight 替代方案的概述.
这个问题为什么会反复出现是历史原因，而不是用户错误。苹果在收购 TestFlight 之前，它是一个跨平台工具。到 2013 年 5 月，开发者已经上传了 15,000 个 Android 应用 到该服务中，这是一个有用的提示，表明 iOS 和 Android 之间的工作流程需求已经存在很长时间，如 TechCrunch 对 TestFlight Android 扩展的报道.
实用规则: On iOS, 想到“TestFlight app”。在 Android 上，想到“发布策略”。
在 Android 上，发布策略的选择会影响您的发布计划。您可以选择 Google Play 管理的发布轨迹、直接向测试者分发、或将本地或仪器测试作为您的工程流程的一部分。没有一个单一的入口点来处理所有这些。
如果您的团队想要了解超出 Google 默认设置的更多工具，这个关于 移动应用发布替代方案 的总结是一个有用的参考。重要的是要记住：停止寻找 Android 上的 TestFlight 克隆，开始选择与您的发布阶段匹配的 Android 工作流。
Google Play Console 测试轨迹解释
Google Play Console 是 Android 官方的 beta 发布解决方案。它不是“一个用于测试者的应用”，而是“一组受控的车道”内您的发布管道。这种方式更灵活，但也意味着您需要明确地指出谁应该获得哪个版本以及为什么。
Google 的发布哲学也比许多团队预期的更注重测试。Google 强调在发布前应持续进行应用测试，因为这使得 快速反馈, 早期失败检测和更安全的重构成为可能，正如 Apple 的 TestFlight 文档页面，与现代团队如何结构预发布测试形成对比。
信任的圆环
理解Play跟踪的最干净的方法是想象 信任的圆环.
- 内部测试 是你的最紧密的圆环。使用它时，工程师、QA和产品需要快速验证一个构建。
- 关闭测试 扩大圆环到选择的外部用户。想想客户利益相关者、试点客户或支持主导的beta小组。
- 开放测试 是公众面向的beta通道。它适用于在你感到舒适地暴露应用程序给更广泛的观众时，收集广泛反馈。
- 生产 是live发布路径，而不是beta测试轨道，但它属于同一思维模型，因为在轨道之间的推广是发布系统的一部分。
这篇文章是关于 Google Play阶段发布 值得与测试轨道一起阅读，因为发布控制和测试纪律紧密相关。
如何将轨道映射到实际发布工作
iOS团队经常犯的错误是将所有三个Android轨道视为“beta”的不同标签。它们不是。每个轨道都解决了不同的运营问题。
内部测试
在速度比完美性更重要的情况下使用内部测试。您有一个候选构建并希望快速获得答案：登录是否正常工作，是否触发分析事件，是否修复了启动问题，发布变体是否像调试一样行为。
此轨道是Android中最接近快速TestFlight内部传递的内部测试。它不是为了广泛的发现。它是为了在外部用户接触应用之前获得信心。
封闭测试
封闭测试是大多数严肃的Android beta程序应该花费时间的地方。您控制受众，保持应用远离公共路径，并可以根据客户类型或功能暴露度分段反馈。
封闭测试适用于以下情况：
- 您需要保密性： 企业试验、合作伙伴预览或为客户工作。
- 您想要更清晰的反馈： 通常一个较小的邀请组会比公众测试群报告更清晰的问题。
- 您正在验证商业工作流程： 适合此类的B2B应用、现场应用、医疗保健工作流程和内部公司工具。
关闭测试通常是Android团队想要真实世界使用而不受公众商店噪音影响的最佳选择。
公开测试
公开测试有用时您想要广泛的设备覆盖和更多的使用模式。它还创建了一个更柔和的发布路径，因为用户知道他们正在选择一个beta体验。
什么不起作用的是使用公开测试太早。如果您的崩溃率仍然不稳定、您的引导程序每天都在改变、或您的支持团队还没有准备好处理 incoming报告，公开测试会放大混乱而不是洞察。
一个实际的进展看起来像这样：
- 从内部测试开始 用于发布候选版本检查。
- 推送到封闭测试 用于信任的外部验证。
- 移动到开放测试 只有当应用程序足够稳定时才能从规模中受益。
- 将应用程序发送到生产环境 Firebase App Distribution for Faster Iteration
如果Play Console是您的正式发布通道
Firebase App Distribution 是团队想要直接将Android构建推送到测试者而不围绕Play track管理的每个迭代的更快侧门。 来自https://firebase.google.com/docs/app-distribution的截图
当团队仍在快速移动时，为了避免基于商店的beta发布，通常我会选择这个选项。如果产品、QA和工程团队正在同时修复登录、注册或崩溃回归问题，Firebase通常比Play发布更方便。
Firebase比Play发布更强大的地方在哪里
Firebase App Distribution在以下情况下非常强大： 迭代速度.
以下是适合它的几种情况：
- 预发布验证： 您希望在提交到任何商店发布之前，让人们使用真实的发布版本。
- CI/CD驱动的测试： 您的管道可以在合并、分支切换或发布候选人标记后生成并传递构建。
- 短反馈循环： 内部测试者不需要每次发布候选人时都进行更正式的注册流程。
团队通常喜欢的是直接性。上传构建，分享给测试者，获取反馈，重复。每次传递都有较少的政策权重。
如果您想看到流程的实时演示，以下是一个有用的产品教程:
Firebase 不足够
Firebase 不是 Play Console 的完全替代品。它是一个 更快的预发布通道,而不是整个 Android 发布系统。
当您需要以下功能时，它就会开始不足:
- 在 Google Play 商店中显示 beta 版本: 您希望在生产发布路径中管理 beta 版本的同一位置。
- 公众招募: 您从邀请测试转向更广泛的公众访问。
- 运营连续性: 发布经理、支持和产品团队都希望从测试到生产有一个单一的路径。
不是“Play Console 或 Firebase？”最成熟的团队最终会使用两者，但在不同的时间点。
实践上的分离是简单的。使用 Firebase 时，建造速度快，受众受控。使用 Play tracks 时，发布管理比原始迭代速度更重要。
比较 Android Beta 分发选项
一旦您停止寻找 Android 上的 TestFlight 应用程序，决策就变得简单了。您不在选择相同工具之间。您在选择之间 管理发布轨道 和 快速构建分发.
对于 iOS 开发者，苹果的约束是一个有用的参考点。TestFlight 支持每个应用程序 100 个内部测试者 和 10,000 个外部测试者 外部 beta 检查大约需要 48 小时，每个版本在发布后 90 天，根据 Android开发者测试试验。 Android并没有直接遵循这些约束，因为其工作流程基于跟踪而不是应用
Android Beta测试方法比较
| 功能 | Google Play跟踪 | Firebase应用分发 |
|---|---|---|
| 主要角色 | 官方Android beta和预生产发布管理 | 快速直接构建与测试者共享 |
| 最佳匹配 | 需要清晰的测试到生产路径的团队 | 需要在正式发布前快速迭代的团队 |
| 测试者访问模型 | 通过内部、封闭或开放测试轨迹进行管理 | 通过邀请或共享访问流程直接分发给测试者 |
| 到生产的路径 | 原生到Play发布流程 | 与商店发布管道分离 |
| 运营开销 | 更结构化 | 轻便的日常构建交接 |
| 适合公众测试版 | 强大 | 与商店注册相比有限 |
| CI/CD的有用性 | 很好，尤其是发布推广 | 频繁候选交付非常好 |
| 最佳用例 | 需要管理和推广控制的测试版计划 | 快速QA、利益相关者审查和内部验证 |
如果您正在评估更广泛的发布工具栈，这个概述 应用程序更新管理工具 添加一些有用的上下文，说明beta版本如何与更广泛的发布工具链融合。
如何选择而不使其过于复杂
简言之：
选择 Google Play Tracks 如果您的主要关注点是发布管理。您关心的是用户分段、生产进程和保持beta活动在官方应用商店工作流中。
选择 Firebase App 分发 如果您的主要关注点是速度。您需要将大量候选版本推送到受控组中，并且不希望每次都涉及Play Console。
使用两者，如果您的团队有不同的预发布阶段。许多团队都是如此。
- 早期周期： Firebase用于快速轮换。
- 稳定性： 关闭外部测试的Play轨道。
- 预发布或广泛的测试版： 打开Play轨道。
- 发布： 通过Play进行生产发布。
这通常是Android的思维模型，清晰地取代了TestFlight。
传统Beta分发的局限性
Beta测试有帮助。它并不能避免生产中的现实。
移动发布工作的不舒服部分是，即使经过了卓越的QA，谨慎的闭合测试和分阶段发布，一个bug仍然可以在生产中溜过去。有时它只在特定的客户配置下出现。有时它需要生产数据，一个活跃的后端行为，或者一个测试者无法复制的使用模式。
Beta测试降低了风险，但并不能完全消除它
传统的beta分发解决了 发布前的 问题。它为团队提供了一个更安全的环境来验证二进制文件、权限、流程和兼容性。
它并没有解决 发布后的 问题。一次应用程序发布后，正常的修复路径通常意味着构建一个新的二进制文件，通过商店流程提交它，并等待用户接收或安装更新。
这段延迟是团队感到脆弱的地方。
实际上，发布后
问题并不是仅仅是一个bug。它变成了一个运营问题。
- 支持团队首先感受到: 用户在工程团队能够发布修复之前就遇到了问题。
- 产品失去了控制： 与二进制发布速度相关的消息、UI调整和小逻辑修正。
- 发布经理失去选项： 即使是微小的非本地更改仍然等待着相同的商店交付路径。
如果您正在使用Capacitor或混合应用，那么这种差距尤其令人沮丧，因为许多紧急修复存储在web资产中，而不是本地code。本指南介绍了 遵守政策的OTA更新在beta工作流中的指南 因为它处理了beta工具处理得不好的部分：在用户手中已经有二进制文件的情况下进行受控更新。
简单的真相是：beta测试降低了发布失败的概率。它并没有给你一个快速恢复的通道，当生产仍然崩溃时。
Capgo Live Updates之外的Beta测试
对于 Capacitor应用，有一个单独的工具类别来解决生产恢复差距：web资产的实时更新。这不是Play跟踪或Firebase的替代品。它解决了一个不同的问题。
Live Update解决了什么问题
如果您的Android应用程序包含Web层，那么您不总是需要发布完整的二进制版本来修复生产问题。一些问题存在于 JavaScript、HTML、CSS、复制、配置或捆绑资产. 对于这些情况，一个 live update 系统可以缩短恢复路径。
__CAPGO_KEEP_0__ Capgo用于应用商店安全的OTA更新, which publishes signed web bundles to targeted channels and applies updates on next launch for Capacitor apps. That means teams can push non-binary fixes without routing every change back through the full app store cycle.
__CAPGO_KEEP_0__
- 用于应用商店安全的OTA更新 ,它发布了签名的Web捆绑包到目标通道并在下次启动时应用更新。对于
- __CAPGO_KEEP_0__ 应用程序，这意味着团队可以推送非二进制修复，而不需要将每个更改重新路由回完整的应用商店周期中。
- 针对受众的补丁： 不改变对所有人的体验的情况下，为特定客户提供的工作-around。
在 Android 工作流程中的位置
正确的思维方式是 互补层.
使用 Google Play Console 测试或分发 Android 二进制文件。使用 Firebase 时需要更快的预发布迭代。使用 live update 路径时，二进制文件已经在生产中，修复存储在 web 层。
这种 combination 给你更多的风险控制权：
- 预发布的信心 通过 beta 测试。
- 商店管理的发布纪律 通过 Play。
- 发布后的恢复 为了解决web资源问题而不必等待另一个二进制周期。
如果您的应用程序具有显著的web层，仅将beta测试作为整个发布策略会在事故最昂贵的位置留下一个空白。
这种权衡也很重要。实时更新并不会取代nativecode发布。如果bug位于Kotlin、权限清单、nativeSDK或二进制打包中，您仍然需要标准的商店路径。但是，对于生活在native shell之上的问题类别，这给团队提供了一个更快的响应选项。
构建您的现代Android发布工作流程
实用Android工作流程不会复制iOS。它使用Android工具来做它们擅长的事情。
使用 Firebase App 分发 当工程师和QA需要快速构建轮换时使用它。它保持了反馈循环短，而特性仍在移动，发布候选人不稳定。
将稳定的候选人移到 Google Play 封闭测试 当您希望外部验证具有更结构化的时使用它。这通常是适合于利益相关者、试点客户和严重的beta用户的清洁注册路径。只有当应用程序足够稳定以从更广泛的曝光中受益时才扩展到公开测试。
对于 Capacitor 应用, 保持一个 live update 路径，以便于发布后修复不需要原生更改的 bug。这样就能填补“我们测试过了”和“生产环境仍然意外我们”的差距。
一个简单的“什么时候使用什么”规则是有效的：
- Firebase 用于快速内部迭代
- 内部或封闭测试 用于管理的 Android beta 测试
- 公开测试 用于更广泛的预发布
- Live 更新 用于非二进制发布后修复
这就是现代 Android 测试飞行的答案。没有苹果的 TestFlight 应用，但有一个成熟的发布堆栈，一旦你不再期望一个工具能做所有工作。
如果您的团队发布Capacitor应用并需要更快的方式来交付发布后Web修复 Capgo 值得与Play Console和Firebase一起评估。它不会取代Android beta测试。它覆盖了那些工具留下的部分，一旦应用已经上线。
