把一个 App 从开发阶段推向真实用户,中间隔着一层容易被低估的工作:内测与公测。iOS 和 Android 各有一套术语和规则,而且规则一直在变——比如自 2023 年底起,Google Play 对新注册的个人开发者账号加了一道很多人上手时才撞上的强制门槛。这篇文章把 iOS(TestFlight)、Android 海外(Google Play)和中国 Android 渠道三条线的完整流程、时间节奏和常见坑梳理成一份可直接对照执行的清单,面向独立开发者和小团队。
先把概念对齐
中文里的「内测」「公测」和各平台的官方术语并不是一一对应的,先统一口径,后面才不会混。
| 中文叫法 | 对应阶段 | 典型规模 | 是否过审 |
|---|---|---|---|
| 内测 / Alpha | 闭门可控测试 | 小于 100 人,邀请制 | iOS 内部组免审;Android Internal 免审 |
| 公测 / Beta | 开放或大规模外测 | 数百到上万 | iOS External 需 Beta Review;Android Closed/Open 免审但有门槛 |
| 灰度 | 上线后按比例放量 | 已发布 | 走商店自带的分阶段发布(Phased Release / Staged Rollout) |
核心心智
iOS 把审核挪到了 External(公测)入口,Android 把门槛挪到了 Closed Testing(公测)到 Production 之间。两边都不存在「免审随便发」的捷径,区别只是那道关卡卡在流程的哪一段。
iOS / TestFlight
两类测试组
| 维度 | Internal(内测组) | External(外测组) |
|---|---|---|
| 上限 | 100 人 | 10,000 人 |
| 身份要求 | 必须是 App Store Connect 团队成员 | 任意 Apple ID(邮箱邀请或公开链接) |
| 审核 | 不需要 Beta Review,构建处理完即可安装 | 首次构建必须过 Beta Review;同一 marketing version 的后续构建多数情况免审 |
| 启用速度 | 上传后约 5–30 分钟可装 | Beta Review 通常 24 小时内,节假日可能 1–3 天 |
| 反馈渠道 | TestFlight App 内截图 + 文字 + 崩溃日志 | 同左 |
构建的生命周期
- 每个 build 上传后有效期 90 天,过期自动失效,测试者将无法再下载或启动测试入口。
- 同一天内最多可提交 6 个 build 进入 Beta Review。
- Build number 必须严格递增;marketing version(
CFBundleShortVersionString)一变化就会触发新一轮首个 build 的审核。
公开链接 vs 邮件邀请
| 方式 | 适用 | 注意 |
|---|---|---|
| 邮件邀请 | 知道测试者邮箱、需要追踪反馈来源 | 测试者必须用对应的 Apple ID 接受 |
| 公开链接(Public Link) | 公测、社媒投放、招募陌生用户 | 测试者匿名,反馈里看不到邮箱(除非他们主动填);可设人数上限和设备/系统版本过滤 |
一个稳妥的节奏
Day 0 上传第 1 个 build
→ 加进 Internal Group → 核心成员先跑
→ 当晚或次日修掉明显 bug
Day 1-3 改完上传若干 build,仍只在 Internal
→ 把 1–2 个核心场景跑到没大问题
Day 3-5 把通过的 build 加到 External Group → 提交 Beta Review
→ 等待 24 小时内通过
Day 5+ Beta Review 过了之后开公开链接,开始招公测
→ What to Test 文案后续可改,不需要重传 binary一个省事的点
What to Test(测试须知)不打进 binary,上传后仍可在后台编辑。所以后续想调整测试说明,直接改文案即可,不必重新上传构建。
Beta Review 常见拒绝点
- 缺测试账号:如果有登录功能,必须提供可用的 demo account。
- What to Test 里出现某些 emoji:部分符号(如地球、备忘录一类)会触发审核拒绝,起草时建议先用纯文字。
- 涉及第三方登录但没说明,或登录回调在测试环境里不工作。
- 描述与 App 实际功能严重不符。
- 内购/订阅没有跑通沙盒(Sandbox)流程。
Android / Google Play(海外)
三条测试轨道
Google Play Console 提供三条并行的 testing track,可以同时存在,但同一台设备一次只能加入其中一条。
| 轨道 | 上限 | 是否过审 | 用途 |
|---|---|---|---|
| Internal Testing | 100 名 testers | 几乎无审,几分钟可装 | 团队 QA、冒烟测试 |
| Closed Testing(Alpha) | 通过邮箱列表 / Google Group 控制 | 走完整 Play Review(首次较慢,后续较快) | 真正意义的「内测」,且是 Production 前的强制门槛 |
| Open Testing(Beta) | 不设硬性上限,可在 Play 商店被搜到 | 同上 | 「公测」,任何人都能装 |
Closed Testing:新账号绕不过的门槛
这是一条容易踩空的规则,也是本文最想提醒的一点:自 2023-11-13 之后注册的个人开发者账号,想上架正式版,流程被强制拉长了。
- 必须先跑 Closed Testing。
- 需要至少 12 名测试者连续 opt-in 满 14 天。
- 通过后才能申请 Production access(上架正式版)。
- 这 12 名测试者必须是真实的 Google 账号,并且要显式 opt-in(点链接、接受)。
- 14 天倒计时是连续的:中途有人退出,计数会被重置。
- 组织(Organization)账号不受此限,但建议照做以积累口碑数据。
实际操作上,独立开发者通常要自己手上凑五六个真账号,再通过测试互助社区(如 Reddit 的 r/AndroidBetaTesting、相关 Discord 互测群)把 12 人补齐。
上传方式
- 必须用 AAB(Android App Bundle),Production 不再接受裸 APK。
- 命令行可用
bundletool本地校验;CI 常用 Gradle Play Publisher 或 Fastlane supply。 - 同一个 versionCode 不能重复上传到任何 track。
推荐节奏
新账号:
Internal(跑 1-2 周自测)
→ Closed Testing 开 12 人 opt-in(政策硬门槛)
→ 满 14 天后申请 Production access
→ 通过后才能用 Open Testing 做公测 / 直接 Production
老账号 / 组织账号:
Internal → Open Testing 公测 → Production
(Closed 可跳过,但建议做一轮小规模 Closed 收反馈)中国 Android 渠道(无 Google Play 场景)
第三方分发平台
在没有 Google Play 的场景下,内测阶段最省心的是通用分发平台,一条链接加二维码就能把包发到测试者手里。
| 平台 | 定位 | 适合场景 |
|---|---|---|
| 蒲公英 PGYER | iOS + Android 通用内测分发 | 主力推荐,免费档够用,支持密码、有效期、设备数限制 |
| fir.im / betaqr | 同类老牌 | 接 CI 较成熟 |
| betaqr.com.cn | fir.im 的国内站点 | 网络稳定性更好 |
通用分发平台的典型流程:上传 APK/IPA 后自动生成下载页、二维码和短链;再设置是否需要密码、是否限制设备数、过期时间、是否需要登录;把链接发给测试者后,平台还能统计安装数、设备机型和版本分布。
各大应用商店自家的 Beta 通道
国内主流商店大多有自己的内测/灰度入口,正式上架前可以先跑一轮。
| 商店 | Beta 入口 | 备注 |
|---|---|---|
| 应用宝(腾讯) | 开放平台 → 内测分发 | 可与微信/QQ 生态联动 |
| 华为 AppGallery | AGC → App 上架 → 公测版本 | 海外市场(除美国外)也通用 |
| 小米应用商店 | 开发者站 → 内测发布 | 可与社区联动 |
| OPPO / vivo | 各自开发者后台 → 灰度发布 | 一般支持按机型/地区灰度 |
| 多渠道分发 | 部分分发平台支持「一键打包到多个国内商店」 | 节省重复填资料的时间 |
国内实操上的几条经验
- 早期内测:一条通用分发链接搞定,最省心。
- 公测/上架:用「多渠道分发」一次性提交主流市场。
- 想要接近「App Store 那种 90 天 Beta 体验」的:走华为 AGC 公测版本,最接近规范流程。
- iOS 在中国大陆的特殊情况:TestFlight 的分发域名有时在网络层不稳定(间歇性不通),但装好的 App 本身可正常使用;让测试者切换网络重试,通常能解决安装/更新入口打不开的问题。
跨平台节奏:同一个 App 同时上 iOS + Android
Week 0 冻结主线功能
iOS: 上 TestFlight Internal
Android: 上 Play Internal Testing + 国内通用分发
Week 1 核心 bug 修完
iOS: 提交 External Beta Review
Android(国际): 开 Closed Testing 招 12 人 opt-in
Week 2-3 iOS: External 通过 → 公开链接公测
Android(国际): Closed 满 14 天 → 申请 Production access
国内 Android: 扩大公测范围
Week 4+ iOS: App Store 提审正式版
Android: Production 上架 + 保留 Open Testing 作为持续 Beta
国内: 各大商店上架常见坑
iOS
- 以为 Internal 也要审 → 白等。Internal 不需要 Beta Review。
- Marketing version 频繁跳号 → 每次都要重新过首个 build 的审核。
- What to Test 里塞带特殊符号的 emoji → 被拒。
- 临近 90 天忘了发新 build → 测试者突然集体掉线。
- 推送新 build 前不做沟通/确认 → 对有节奏协作的团队,建议把「推送前确认」固化成流程。
Android(海外)
- 新账号直接申请 Production → 被卡,必须先跑满 Closed 的 14 天。
- Closed Testing 找了熟人但没让他们点 opt-in 链接 → 不计数。
- 测试者中途退出 → 14 天重新计算。
- 同一台设备同时加入多个 track → 只有一个生效,常常导致误判 bug。
国内 Android
- 各家商店的「资质审核」标准不一,营业执照/软著常被卡。
- 部分商店要求隐私政策 URL 不能用第三方在线文档(如某些云文档平台),必须是独立域名的页面。
- 免费档的分发平台对单文件大小和下载次数有限制,做大版本压测前先看清额度。
一份可直接对照的上手清单
- iOS 推送新 build 前,把「团队内确认」当成固定步骤。
- What to Test 起草时先用纯文字,emoji 只用确认安全的。
- 盯住 90 天有效期:每 2–3 周保持一次新 build 上传,避免测试者掉线。
- 做 Android 版前先决定:是否需要 Google Play 海外?决定了走哪条 track 再动手,新账号尤其要把 Closed Testing 的 14 天预留进排期。
- 国内 Android 优先用通用分发平台做内测,正式上架再走多渠道分发。
参考链接
iOS
- TestFlight 总览(官方):developer.apple.com/help/app-store-connect/test-a-beta-version/testflight-overview/
- 邀请外部测试者(官方):developer.apple.com/help/app-store-connect/test-a-beta-version/invite-external-testers/
- TestFlight 产品页:developer.apple.com/testflight/
Android(海外)
- Set up an open, closed, or internal test(官方):support.google.com/googleplay/android-developer/answer/9845334
- 新账号 12 testers / 14 days 政策(官方):support.google.com/googleplay/android-developer/answer/14151465
中国 Android
- 蒲公英 PGYER 官网:www.pgyer.com
- fir.im 国内站:www.betaqr.com.cn