应用卡在封闭测试：14 天规则详解
多数「卡住」的封闭测试并不是 Google 处理慢，而是 14 天计时悄悄重置了。如果测试两周后 Play Console 仍显示几天、甚至 0 天，原因基本就是下面这几种。
看起来「卡住」的四种情况
- 计时没在走：某一天参与人数低于最低值，14 天窗口已经重新开始
- 测试者悄悄离开：退出了测试，或卸载后再没有回来
- 你在等审核，而不是在等测试：版本审核、生产权限审核与 14 天计时是三件独立的事
- 申请入口还没出现：只有满足要求后，Play Console 才会开放生产权限申请
计时规则
- 第 1 天是测试者全部完成加入并安装的那天，不是发布测试的那天
- 14 天中的每一天都必须满足最低参与人数
- 人数低于最低值，窗口会从零重新开始
什么会重置或阻断计时
- 测试者退出（最常见的原因）
- 测试者卸载应用且不再安装
- 测试者从未打开应用——Google 期待真实使用而非只安装
- 采用「慢慢攒人」的方式，前几天人数一直低于最低值
- 14 天未完成就申请生产权限
退出 vs 卸载：哪个才真正致命
Google 统计的是「当前仍在测试中的测试者人数」。退出测试会立刻让这个数字减一，所以一次退出就可能让整个窗口回到原点。
而保持加入但不再打开应用是更隐蔽的问题：人数看起来达标，但申请时整个测试的活跃度会显得很单薄。要求的是周期内持续使用，而不是挂一个两周的安装。
计时重置后的补救清单
- 先确认还有哪些测试者仍在测试中，再决定补多少人
- 补到最低线以上——12 名的要求按 15 人执行
- 给测试者一个统一渠道，并让他们在周期内大部分日子都打开应用
- 逐个确认测试者能正常从测试链接安装（地区、设备、Google 账号都可能出问题）
- 重新开始 14 天，并在末尾加 2 天缓冲，避免再次被末尾掉线击穿
为什么我们把安装保持到 16 天
14 天是最低要求，而第 13 天的一个退出就可能让你回到第 1 天。因此我们的任务在 14 天活跃测试之后，还会让所有测试者额外保持安装 2 天，合计 16 天。
如果周期最后阶段出现任何意外，这 2 天兜底依然覆盖 Google 的 14 天要求，你的生产权限申请不会因此受影响。
FAQ
查看全部常见问题为什么一直显示 0 天？
只有在参与人数不低于最低值的那些天，14 天窗口才会推进。如果人数曾经低于最低线，或者测试在人数没凑齐时就开始了，计时就会重置。请先看 Play Console 里的测试者名单，而不是轨道日期。
14 天从发布测试开始算吗？
不是。从满足最低人数的测试者加入并安装那天开始算。如果是陆续招募，最后一名测试者加入的当天开始计时。
如果测试者第 10 天卸载了怎么办？
需要补位，让参与人数在剩余天数里始终不低于最低值。因为 14 天必须连续，建议多招募几名作为缓冲。
卸载应用会重置计时吗？
直接触发重置的是退出测试（opt-out），而卸载的人通常在不久后也会退出。两种情况都会让「当前测试者人数」下降，而人数下降就是 14 天重新开始的原因。
可以在周期中途增加测试者吗？
可以随时增加，但 14 天只有在每一天都保持最低人数时才算完成。中途加人无法补回已经损失的日期。
第 15 天可以提交申请吗？
建议在 14 天连续完成、且 Play Console 显示要求已满足后再申请。如果不确定，就用那 1 天缓冲——申请被拒损失的时间远不止一天。
16 天是 Google 的要求吗？
不是。Google 要求 14 天，额外的 2 天是我们自带的兜底保障，不额外收费。
封闭测试托管服务 · $10 全包
15 名真人测试者、14 天活跃 + 2 天兜底、第 10 天前交付测试报告。