BetaLobby凑齐 12 名测试人员、测满 14 天之后，在信息中心点申请发布正式版，会弹出一份问卷：3 个部分，共 9 个问题。其中 7 题是文本框，每题上限 300 个字符，另外 2 题是单选。
我的应用一开始被拒时，问卷写得很空，基本是「测试人员用了所有功能，一切符合预期」这种话。通过的那一轮，我把每一题都换成了具体的事实。
Google 没有公开问卷的评判标准，下面不是官方答案，只是我的经验。例子都是一个虚构的记账应用，只用来演示写法，不要照抄。
填之前先知道这 4 点
- 关闭表单会丢内容：中途关闭时，后台提示的是关闭并舍弃。建议先在别处写好，再贴进去。可以用我们的免费工具正式版发布权限问卷，9 个问题和后台原文一字不差，字数算法也一致，草稿只保存在你自己的浏览器里
- 最后的按钮叫「应用」：这是 Apply 的直译，点了就是提交，不是保存
- 字数要写够，也要算好：英文的话，300 个字符只有 50 个词左右，写不了几句，所以每句都要有内容。我的建议是每题写到 260 个字符左右。下面的「更具体」示例，对应的英文大约 190～280 个字符
- 用什么语言写：我没在帮助中心看到语言方面的要求。我自己用的是英文
第 1 部分：关于您的封闭式测试
这一部分问的是你实际做过的事，最容易写虚，也最容易对不上。
1您如何招募参与封闭式测试的用户？
您如何招募参与封闭式测试的用户？例如，您是否询问过亲朋好友，或使用了测试服务提供商提供的有偿服务？
如实写渠道和人数。有偿服务这件事也如实写，问题本身就把它列成了一种招募方式，隐瞒或编造反而是最大的风险。
- 太空泛：通过网络招募了测试人员。
- 更具体：通过两个安卓开发者社区和身边同事招募，共 18 人参与，没有使用付费测试服务。其中 5 人平时就有记账习惯，是我的目标用户。
2为应用招募测试人员的难易程度如何？
为应用招募测试人员的难易程度如何？
单选：很难、难、不难也不容易、容易、很容易。这题没有标准答案，按实际感受选就行。
3说明您在封闭式测试期间从测试人员处获取的互动信息
说明您在封闭式测试期间从测试人员处获取的互动信息
下面的提示要求写清楚两件事：测试人员是否用了所有功能，以及使用体验是否和你预期的真实用户一致。如果不一致，要说明区别在哪。
很多人会直接写「全都用了，完全一致」。这其实很难让人相信，真实的测试几乎不会这么整齐。写出哪里和预期不一样，反而更可信。
可以写这三点：
- 哪些功能用得多：大多数人经常用什么
- 哪些功能用得少：哪些只有少数人碰过，或者没人用
- 和预期有什么差别：比如你以为大家会天天用，实际只有头几天用得多；或者某一步很多人都卡住了
如果你不知道测试人员具体做了什么，也很正常。统计信息能看到每天有多少人打开应用，但看不到他们用了哪些功能。可以这样了解：
- 直接问：在测试群里或私信问几个人，用了哪些功能、哪一步卡住了。最好在测试期间就问，别等到填问卷时
- 看应用自己的数据：如果接了 Firebase 这类统计工具，或者服务器上有记录，可以直接看哪些功能有人用
- 看反馈：有人反馈某个功能的问题，至少说明他用过这个功能
如果已经问不到人，也没有数据，就只写你确实知道的，并说明这个情况。你自己在测试时发现的问题也可以写，写明是自己发现的就行。不要为了好看写成所有人都用了所有功能。
- 太空泛：测试人员使用了所有功能，体验符合预期。
- 更具体：大多数人每天记账并查看月度统计，符合预期。只有少数人用了多账本和导出功能，真实用户初期可能也是如此，所以我把这两项放到了设置里。部分测试人员只在头几天记得比较勤。
- 不清楚具体行为时：应用没有接入行为统计，所以我问了 6 位测试人员。他们都用过记账和月度统计，只有 1 人试过导出，和我预期的差不多。有 2 人没找到导出入口，我调整了它的位置。
我自己的应用是开发者组队互相测试的平台，通过的那一轮，这题我写的大意是：有些成员的应用一启动就崩溃，导致打卡失败；还有几位测试人员中途卸载了；我们针对这些情况分别调整了流程。这些都不算好消息，但都是真实发生的事。
4提供您收到的测试人员反馈的摘要
提供您收到的测试人员反馈的摘要。包括您收集反馈的方式。
要写两样东西：收到了什么反馈，怎么收集的。反馈渠道可以是邮件、应用内表单、社群，测试人员也可以通过 Google Play 私下反馈，在监控和改进 > 评分和评价 > 测试反馈里能看到。
所以最好从第一天就把反馈记下来，别等到申请时再回忆。如果确实没收到多少反馈，就照实写，再说明你还做了什么，比如主动问了哪些人、自己发现了什么问题。不要编。
- 太空泛：测试人员反馈很好，没有发现重大问题。
- 更具体：通过应用内反馈表单和测试群收集。主要有三类：两台 Android 12 手机上导出时闪退、记账入口太深、深色模式下图表看不清。也有人希望增加周统计，这项还在评估。
第 2 部分：关于您的应用
这一部分不问测试，问的是你的应用给谁用、有什么用。
5您应用的目标受众群体是哪些人？
您应用的目标受众群体是哪些人？
帮助中心的要求是尽量具体。不要写「所有人」，写清楚是哪些人、在什么情况下会用。
- 太空泛：所有需要记账的用户。
- 更具体：刚开始管理个人开支的年轻上班族，尤其是想每天花几秒钟记一笔、不想学复杂财务软件的人。
6请说明您的应用如何为用户创造价值
请说明您的应用如何为用户创造价值
重点是解决了用户的什么问题，不是罗列功能。按帮助中心的说法，如果是游戏，就写它的独特之处。
- 太空泛：功能丰富，界面美观，使用方便。
- 更具体：很多人记账坚持不下去，是因为每记一笔都要填太多内容。这个应用两步就能记完，每月自动汇总花费去向，让用户不用整理数据也能知道钱花在了哪里。
7您预计应用在第一年的安装量是多少？
您预计应用在第一年的安装量是多少？
单选：0 - 1 万、1 万 - 10 万、10 万 - 100 万、超过 100 万、不知。同样没有标准答案，按实际情况估，确实估不出来就选不知，不用为了好看往高了选。
第 3 部分：您的正式版就绪情况
这一部分最能看出你有没有真的在迭代，也是最需要提前准备的部分。
8您根据封闭式测试期间发现的问题和收到的反馈对应用做出了哪些更改？
您根据封闭式测试期间发现的问题和收到的反馈对应用做出了哪些更改？
写具体的改动，最好能和第 4 题的反馈对应上，也要和测试期间实际发布的版本对得上。没收到反馈也没关系，你自己测出来的问题、发布前测试报告里发现的问题都可以写。
所以测试期间要多发几个有实际改动的版本，每次都记下改了什么。
- 太空泛：修复了一些 bug，优化了用户体验。
- 更具体：修复了 Android 12 上导出闪退的问题；把记账入口移到首页，步骤从四步减到两步；调整了深色模式下的图表配色。测试期间共发布了 4 个版本。周统计还没做，计划放到正式版之后。
9您是如何确定应用已做好正式发布准备的？
您是如何确定应用已做好正式发布准备的？
写你判断的依据，比如主要流程都走通了、测试反馈里的严重问题都修了、最近几个版本没再出现哪些具体的问题。
也可以在最后带一句，说明应用符合 Google Play 在隐私和数据安全方面的政策要求，前提是你确实对照检查过。这只能当补充，主要篇幅还是写测试给你的依据。
不要写「没有任何 bug」，也不要声称做完了其实没做完的事。还有没解决的小问题，直接说明它们不影响主要使用，并写清打算怎么处理，这样更可信。
- 太空泛：应用已经非常完善，可以发布了。
- 更具体：记账、统计、导出这些主要流程在测试人员的设备上都能正常使用，反馈中的闪退已修复，最近两个版本没有新的闪退报告。周统计等非核心需求会在正式版之后继续迭代。应用也符合 Google Play 在隐私和数据安全方面的政策要求。
如果是再次申请
文本框会自动填入你上次的回答。不要直接点下一步，逐题看一遍，把这一轮的情况改进去。
问卷还会多出一个问题，问你这次和上次相比做了哪些改变。可以写换了什么招募渠道、这一轮发了哪些更新。如果你还不确定上次为什么被拒，可以先看「需要进行更多测试」的 5 个原因和对策。
提交前再看一遍
- 每一题都写的是真实发生过的事，没有虚构和夸大
- 第 4 题的反馈和第 8 题的改动对得上
- 第 8 题的改动和实际发布的版本对得上
- 7 个文本框都写够了字数，语法通顺。可以用 AI 检查语法，但别让它替你从零写，很容易编出不存在的事
问卷写得再好，也要有真实的测试撑着。能不能拿到权限最终由 Google 决定，但第 3 题和第 4 题要写的内容，是 14 天里一点点攒出来的。
如果你还在凑 12 名测试人员，可以看看 BetaLobby。它是一个组队互助平台，16 位开发者组成一队，互相测试对方的应用 14 天，每天打卡时会真的打开一次你的应用，你也能看到每天有多少人打了卡，还能收到附带设备信息的反馈。