当你的封闭式测试已有至少 12 名测试人员连续 14 天选择加入后，Play Console 信息中心就会解锁 申请正式版。点击后会打开一份简短的表单。它看起来像走个过场，但正是在这一环节，由人工审核人员判断你的测试是否真实、应用是否已准备就绪，而回答质量差是开发者被要求继续测试的常见原因。
本文逐一讲解这些问题、每个问题真正想问什么，以及如何用具体内容来回答。Google 会不时调整措辞，所以请把下面的问题文本看作意思相近的转述，而不是逐字照搬。
申请之前
好的回答是根据笔记写出来的，而不是凭记忆；我们的 14 天封闭式测试逐日计划 告诉你测试过程中该记些什么。打开表单之前，先整理好：
- 你如何 招募 测试人员，邀请了多少人、实际有多少人选择加入。
- 测试人员 做了什么：用了哪些功能，大概多久用一次。
- 你收到的每一条 反馈 以及来源（反馈邮箱、表单、聊天、Bug 报告）。
- 测试期间发布的 更新，包括版本号以及每次改了什么。
- Android vitals 中的崩溃和 ANR 数据，以及 预发布报告 标出的任何问题。
第一部分：关于你的封闭式测试
为你的应用招募测试人员容易吗？
这是一道选择题，选项从非常容易到非常困难。没有标准答案；如实选择即可。有些表单会接着要求你描述如何招募测试人员，所以要准备好说明你的渠道：朋友和同事、开发者社区、你自己的邮件列表，或测试服务。
描述封闭式测试期间测试人员的参与情况
审核人员想看到测试人员确实用过应用、而不只是选择加入的证据。描述用了哪些功能、使用频率、用的是哪类设备，以及你在分析数据或 Android vitals 中看到的值得一提的情况。
较弱的回答：“测试人员用了应用，而且很喜欢。”
以一款习惯打卡应用为例，较强的回答：“15 名测试人员选择加入，其中 14 人坚持完成了整个测试。大多数人每天打开应用记录习惯；提醒和连续打卡页面使用最多。测试人员使用了五个品牌的手机，系统版本从 Android 10 到 15，其中包括两台平板电脑。Android vitals 在第一周记录到两次崩溃，都发生在 Android 10 上，我们已在 1.0.2 版中修复。”
概述你收到的反馈以及收集方式
先说明渠道，再把反馈按主题归类。正面和负面反馈都要提到；一次没人发现任何可改进之处的测试，不如一次发现了几个真实问题的测试可信。
示例：“我们通过测试轨道上设置的反馈邮箱，以及版本说明中附带的一份简短表单收集反馈。测试人员报告手机重启后提醒不再触发、深色主题下统计页面的文字对比度偏低，并希望增加每周总结。他们认为新手引导很清楚。”
第二部分：关于你的应用或游戏
你的应用面向哪些受众？
具体说明应用是给谁用的、为什么。“所有人”不是受众。示例：“想养成喝水、阅读等日常小习惯的成年人，他们偏好不需要注册账号、没有社交功能的简单应用。”
描述你的应用如何为用户提供价值
用两三句话说明要解决的问题，以及应用如何解决它。点明它为什么不只是网站或模板的一层简单套壳，因为功能极少的应用在 Google Play 上属于政策关注点。
你预计第一年会有多少次安装？
这里是选择一个区间。根据你的推广计划选一个现实的区间。夸大没有任何好处，对第一个应用来说，保守的估计完全正常。
第三部分：正式版发布准备情况
根据封闭式测试中了解到的情况，你对应用做了哪些更改？
这往往是最重要的一个回答。Google 想看到测试让应用发生了变化。列出带版本号的具体改动，并把每项改动和促成它的反馈或数据对应起来。
示例：“1.0.2 版修复了 Android vitals 中发现的两次 Android 10 崩溃。1.0.3 版在设备重启后重新安排提醒，并提高了深色主题下的文字对比度，这两项都是测试人员报告的。我们还新增了一个每周总结页面，这是好几位测试人员提出的需求。”
如果测试期间你一次更新都没发布，这里就几乎没什么可写的。这就是为什么我们建议每次封闭式测试期间都至少发布一次更新，哪怕只是很小的更新。
你是如何判断应用已经可以发布到正式版的？
给出标准，而不是感觉。例如：最近一周没有未处理的崩溃报告，所有报告的 Bug 都已修复或有意排期，主要流程已在多种 Android 版本和屏幕尺寸上测试过，商品详情和数据安全信息都已填写完整。
该做与不该做
| 该做 | 不该做 |
|---|---|
| 用数字说话：测试人员、天数、版本、设备 | 只写一句话的回答 |
| 提到你发现并修复的真实问题 | 声称测试人员什么问题都没发现 |
| 描述反馈是如何收集的 | 在每个输入框里粘贴同一段笼统的回答 |
| 让回答与 Play Console 中的数据保持一致 | 编造并未发生的参与情况或反馈 |
| 把笔记留着给下一个应用复用 | 照抄回答模板而不做任何调整 |
在这里诚实很重要。Google 能看到你的测试轨道、测试人数和 Android vitals 数据，与数据不符的回答是没有说服力的。
提交之后
Google 表示通常会在 7 天内审核完申请，但也可能更久。你会收到一封电子邮件，Play Console 中也会有一条消息。如果获批，你就可以创建正式版，最好采用分阶段发布。如果没有获批，消息会说明需要更多测试，你可以稍后再次申请；我们的 正式版访问权限被拒后怎么办 介绍了后续步骤。
等待期间，除非确实有错误，否则不要急着修改商品详情或各项声明。审核人员会把你写的内容和他们看到的情况进行对比，前后一致更容易获批。如果提交后发现回答中有错误，把更正记下来，万一需要再次申请时可以用上。
等待期间让封闭式测试继续进行。如果测试人员在审核期间流失，万一 Google 要求更多测试，你能展示的内容就会更少。
让回答变得容易写
最好的回答，来自一次产出了可汇报内容的测试：稳定的使用、几个 Bug、一些反馈以及一两次更新。如果你现在正在规划测试，请阅读 如何设置封闭式测试 和 去哪里找 12 名测试人员。
使用 TesterBie，真实 Android 手机会在 14 天里每天使用你的应用，崩溃和异常页面会连同手机型号、Android 版本和截图一起报告，控制面板还会保留每日活动记录。测试结束时，你会收到一份报告和回答这些问题的建议，让你的回答基于真实发生的情况。查看套餐。
常见问题
正式版访问权限申请问题必须用英文回答吗？
Google 并不要求使用英文，但清晰的英文是最稳妥的选择，因为任何审核人员都能轻松读懂。
可以使用在网上找到的回答模板吗？
模板只能用来参考结构。审核人员见过大量雷同的回答；请写你自己的测试人员、反馈和改动，并让细节与 Play Console 中的数据保持一致。
Google 审核正式版访问权限申请需要多长时间？
Google 表示审核通常需要 7 天或更短时间，但有些会更久。你会通过电子邮件和 Play Console 收到通知。
如果申请被拒会怎样？
Google 会告诉你需要更多测试。让封闭式测试继续进行，保持至少 12 名积极参与的测试人员，发布改进，等 Play Console 允许时用更具体的回答再次申请。