【Google Play 上架】内部 / 封闭 / 开放测试全解 — “只跑一个就能上架”？不行！

Google Play 上架流程详解

原创于 2025-10-02 17:21:02 发布 · 1.4k 阅读

6 ·

CC 4.0 BY-SA版权

文章标签：

#Godot #游戏 #google play #应用商店 #创业创新

Godot游戏开发专栏收录该内容

8 篇文章

订阅专栏

在准备把游戏或应用发布到 Google Play 时，经常会疑惑“内部测试 / 封闭测试 / 开放测试有什么区别，是不是选一个就能上架”。事实并非如此。特别是自 2023 年 11 月 13 日 起，对个人开发者账号有了更严格的新规：必须先通过封闭测试（Closed testing） 才能申请进入生产发布（Production release）。
下面我从官方政策、三种测试轨道特点、流程演练、注意事项与实践经验几个方面展开。

一、政策要求：封闭测试是新的门槛

从 Google Play 官方文档可以看到，针对在 2023‑11‑13 后创建的 个人开发者账号（Non‑organization / Individual account），上架之前必须进行一次封闭测试，且满足以下要求：该封闭测试中至少有 12 位测试者 已经 连续 14 天 保持已加入状态（opt-in）不脱离。只有满足这个条件，才能在 Play Console 上点击 “申请生产发布 (Production access)” 并填写测试情况、准备发布。

“You must run a closed test for your app with a minimum of 12 testers who have been opted-in for the last 14 days continuously.”
“Developers with personal accounts created after November 13, 2023, must meet specific testing requirements before they can make their app available on Google Play.”

也就是说：

内部测试 (Internal) 和开放测试 (Open) 虽然在调试阶段有用，但 不能替代 这个封闭测试的硬性要求；
就算你做了内部测试、做了开放测试，也必须有一个合格的封闭测试作为“通行凭证”；
在申请生产发布时，Google 控制台会要求你填写关于封闭测试的情况，包括测试人数、持续天数、测试覆盖、用户反馈等。

因此，不是三选一，而是 **三者可能都做，但 封闭测试必须做且达标 是前提。

二、三类测试轨道的定位与对比

下面是内部 / 封闭 / 开放三类测试的主要区别、适用阶段与限制。

测试轨道	特点 / 适用场景	限制 / 注意事项
内部测试 (Internal Testing)	* 快速分发给内部团队 / QA /核心测试人员用 * 发布速度快，几分钟内可见 * 最多支持 100 位测试者 * 不需要满足封闭测试人数天数要求	不计入封闭测试门槛；不对外公开；测试者为指定邮箱清单 Google 不会把这个作为上架审核的测试依据
封闭测试 (Closed Testing / Beta / 白名单测试)	* 面向选定的一批测试用户做中期测试 * 必须满足 12 位测试者（或以前是 20 位）连续 14 天的要求 * 其结果是上架生产必需的前置条件	测试期间 Google 会有审核 / 合法性校验测试者必须持续保留 opt‑in，不能中途退出测试版本不对大众公开
开放测试 (Open Testing / 公测)	* 面向更广泛用户群体开放测试 * 任何用户都可以加入并给反馈 * 可收集更多真实环境下的问题	不能够替代封闭测试要求只有在你已获得生产发布权限时才可使用开放测试路径评论可能公开给你，但产品版本不会正式公开测试版本仍有“测试标签”标识

这三者通常是逐步推进的：先内部 → 再封闭 → 再开放 → 最终生产。但关键的是，无论是否开启内部或开放测试，封闭测试合格是个人账号获得 Production 权限的前提。

三、流程演练：如何按步骤上架

下面以一个新游戏 / 应用上架流程为例，说明如何合理安排三类测试及如何满足封闭测试要求。

步骤 0：准备基本信息与 App Bundle / APK

在 Play Console 中填写应用基础资料（包名、图标、应用描述、隐私政策、内容评级等），同时准备好可上架的应用包（.aab / .apk）。

步骤 1：内部测试发布

在 “内部测试”轨道 (Internal testing) 新建一个 release，并添加测试人员邮箱（上限 100 位）
上传应用包并发布，让内部测试团队快速体验和初步回归（冒烟测试 / UI 检查）
利用内部测试阶段修复明显问题

这一步是可选的，但推荐走，以更早发现问题。

步骤 2：启动封闭测试（Closed testing）

在 Play Console 的 “Testing → Closed testing” 新建或管理封闭测试轨道
邀请至少 12 位真实用户（或更多、安全冗余）加入测试组（通过邮箱或邀请链接加入 opt-in）
发布测试版本给这些用户
关键要求：这 12 位用户必须在测试阶段连续 14 天 保持已加入状态，不能中途退出。

提示：14 天通常从满足 ≥12 位测试者加入后开始计算。中途不建议频繁移除测试者，以免断计时。

在测试期内，你应积极收集反馈、修复缺陷、打补丁版本、优化体验。

步骤 3：在封闭测试合格后申请生产发布

当封闭测试已满足至少 12 位测试者连续 14 天的要求后，在 Play Console 的 Dashboard 或 Production Release 页面，会出现 “申请生产发布 (Apply for Production)” 选项
填写关于封闭测试的问答，例如“测试覆盖情况、测试者反馈、是否修复已知问题”等
提交后 Google 会对你的应用进行审核，一旦通过，即可将应用发布到 Production 轨道。

在此之后，你可以根据需要开启 开放测试 (Open testing)，将测试版向更广范围用户开放，继续迭代，但这不是上架的必须条件。

步骤 4：后续版本 / 更新

对于后续更新，你可以先在内部 / 封闭 / 开放轨道做测试，再推广到生产
不必每次都重新做 14 天封闭测试 —— 只要你已经获得 Production 权限后，更新流程会相对宽松
但对于新功能、重大版本，仍建议多做测试验证风险。

四、常见疑问 & 实践经验

下面是一些常见疑问与实操经验分享：

问题	解答 / 建议
内部测试是否算作封闭测试？	不算。内部测试是供开发 / QA 内部使用的轨道，不计入封闭测试的 12 人 / 14 天要求。
开放测试能否代替封闭测试？	不能。开放测试虽可提前公开给用户试用，但不能作为封闭测试的替代，不能满足上架门槛。
如果测试用户退出怎么办？	如果测试者中途退出，则这个用户不再算作连续 opt-in，可能中断 14 天计算。建议在测试中期避免频繁更换测试者。
测试人数过 12 有用吗？	有冗余是好的。如果某位测试中途退出，仍可保持 ≥12 人。
对于组织账号 / 老账号是否受此规则限制？	新政策主要针对个人开发者账号在 2023‑11‑13 之后创建的账号。组织账号或较早创建账号可能不受此限制，具体以 Play Console 上实际提示为准。
测试者是否必须活跃使用？	测试者需“已 opt-in 连续 14 天”，但 Google 并不严格要求每天活跃使用。但在审核时 Google 可能会看测试覆盖、反馈情况、异常使用行为等作为判断依据。
審核 / 发布时间要多久？	封闭测试版本也会有审核周期（Google Play 对测试轨道会有校验），生产发布审核通常也可能几天。
能否跳过封闭测试直接上架？	对于新个人账号不能跳过。从政策来看，必须先通过封闭测试这一关才放开 Production 发布。