封闭式测试期间可以上传更新吗 — 14 天照常计算，上传方法与次数

1. 可以上传 — 14 天不会中断

在封闭式测试期间上传新版本，14 天不会从头开始计算。 Play Console 帮助中心文档对该要求的描述只有“至少 12 名测试人员在过去 14 天内持续选择加入”，并没有把版本数量或是否更新作为条件。 在同一轨道上上传新版本，不会改变测试人员的参与状态。

让 14 天中断的不是更新，而是测试人员流失：测试人员退出测试或卸载应用、被从测试人员列表中移除，或者您新建轨道迁移过去。 详细的计算规则请参阅 14 天从什么时候开始算。

2. 为什么最好上传更新

满 14 天后申请正式版访问权限时，调查问卷的最后一部分会询问您根据封闭式测试的结果对应用做了哪些修改，以及判断已准备好发布的依据是什么。 如果整个测试期间只有一个版本，这道题就没有内容可写。

反之，如果保留了测试期间上传的各个版本以及每个版本修改的内容，就可以直接作为回答的依据。像“1.0.2 缩短了首屏加载时间， 1.0.3 修复了测试人员反馈的登录错误”这样把版本号和修改内容一起写出来，审核人员就能核实。逐题示例请参阅 正式版访问权限调查问卷逐题示例，只有一个版本时会出现的问题请参阅 被拒的 7 个原因。

3. 在 Play Console 中上传的步骤

1. 把应用的 版本代码（versionCode） 改为比上一版更大的数字，构建新的 App Bundle（.aab）。用过的版本代码不能再用。
2. 在左侧菜单中依次前往 测试和发布 → 测试 → 封闭式测试，在测试人员当前所在的轨道上点击 管理测试轨道。
3. 在 版本 标签页中创建新版本并上传 App Bundle，在版本说明中写明这次修改的内容，然后保存。
4. 在左侧菜单的 发布概览 中将所做的更改送审。如果开启了受管发布，审核完成后需要您亲自发布，更新才会推送给测试人员。
5. 审核完成后，测试人员的 Play 商店中就会出现更新。开启了自动更新的设备会自动获取，否则需要测试人员手动更新。

4. 多久一次、更新什么

没有规定的次数。实际操作中，每隔 3～4 天一次，14 天内上传两三次，就足以留下可写进问卷的历史记录。 不需要开发什么大功能，只要是在测试中发现并修正的内容，再小也可以。

• 修复测试人员反映的不便或错误
• 修复只在特定设备或系统版本上出现的问题
• 改善首屏显示缓慢的问题（首次启动慢，测试人员就会少用应用）
• 整理文案、界面布局等测试人员感到困惑的地方

每个版本都在版本说明中用一句话写明修改了什么，日后填写问卷时，这份清单就是答案。 如果在申请前夕大幅修改应用，测试人员就没有时间试用该版本，所以大的改动最好在测试的前中期上传。

5. 更新时把测试搞砸的情况

更新本身不会中断 14 天，但在更新过程中，有些失误会破坏测试。

• 新建了一个轨道来上传。 一旦更换轨道，之前累积的参与就无法延续。更新请上传到当前的轨道。
• 上传到了内部测试轨道。 封闭式测试人员收不到这个版本，而且计入要求的也只有封闭式测试（内部测试、封闭式测试与开放式测试的区别）。
• 上传时顺便清理了测试人员列表。 从列表中移除的账号会立即不再计入人数。测试期间只添加，不移除。
• 上传了首次启动就崩溃的版本。 一打开就闪退的应用很容易被测试人员卸载，卸载后就不再计入人数。 上传之前，请先在自己的设备上确认能否安装和首次启动。

6. 测试人员看不到更新时

• 在 发布概览 中查看更改是否仍在 正在审核的更改 中。审核完成后才会推送给测试人员。
• 如果开启了受管发布，请确认审核完成后您是否已亲自发布。
• 确认上传版本的轨道与测试人员所加入的轨道是否相同。
• 刚发布后，Play 商店可能需要一段时间才能识别到更新。测试人员可以打开应用的 Play 商店页面手动更新。

DUIRE 的测试设备每天都会检查是否有新版本。您只需把新版本上传到 Play Console，设备就会获取并安装，并为每台设备记录何时安装了哪个版本。 这些记录会写进最终报告，成为您填写调查问卷的依据。