Google Play 灰度/beta/alpha 测试方案以及常见问题

Posted 2023-02-24 danhuang

当你想灰度一些新版本进行一些测试的时候，你可以选择 Google Play 的方案，但是 Google Play 的测试方案很多对我们来说都是黑盒，需要摸索，而经过接近一年的试验，我们也渐渐摸索出了 Google Play 灰度的一些经验，在这分享给大家。

建议的测试流程

假设我们有一个比较重大的新版本即将发布，那么我们应该选择怎么样的过程呢？下面是我的一个建议流程，可供大家参考下。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

内部测试

内部也需要分为内部团队成员，也可以分为邀请的外部该部分用户的群体来进行内部体验。

如果是自己内部团队的，可以使用内部的 APK 直接安装体验。但是如果这时候用户群体来自使用该 APP 的外部用户，那么我们就需要应用到 Google Play 的 alpha 渠道了。
在 Google Play 上也叫做内部测试，具体方法，大家可以参考其流程操作就行了。

在内部测试基本没有问题后，我们就可以放开部分给到外部去测试体验，接下来就进入外部测试流程。

外部测试

外部测试是指，我们需要把这个提供给到真实用户去使用，然后观察真实用户的数据进行一定的反馈测试。
这里我们分位 2 种情况，1 种是用户主动加入测试计划的，还有 1 种是用户被动加入测试计划的。

在前期我们不希望影响到大部分用户，因此我们需要选择第一种方案，让用户主动加入我们的测试计划。

beta 测试计划

该功能在 Google Play 中叫做开放式测试。如果你希望做该项测试，那么你可以在自己的应用内部，灰度发送通知给到你希望其进行开放性测试的用户群体。
这样做的好处有：

1. 可以选择相应的群体进行测试，比如这次改版影响最大的是主播，为了避免影响主播的用户体验问题，首先进行开放性提醒主播进行测试计划；
2. 避免影响较多用户，只针对部分用户进行测试，由于需要主动加入测试计划，因此对整体的用户影响较小；
3. 可随时关闭测试，如果发现问题，可随时关闭 beta 版本，让用户升级回到最新的正式版本；

灰度分阶段测试

在以上流程都测试通过，没有发现版本和数据问题时，我们就可以进行灰度测试了，Google Play 上叫做分阶段发布应用更新，这个在我们发布新版本的时候经常会应用到。
我们可以分 5%、10%，100% 阶段去观察整体的数据情况。

常见的问题

灰度测试的用户，假设我们在多个版本都是灰度 5%，那么这 5% 的用户是否会是同一批次用户群体的呢？
是同一批次用户群体，Google Play 的灰度机制，会覆盖上一个版本灰度的用户，假设我们目前的正式版本是 2.0.0，接下来我们需要测试 3.0.0 版本的情况，我们对 3.0.0 进行了灰度 5% 的用户。这是很好就是 95% 的用户可下载 2.0.0 版本，5% 的用户可下载 3.0.0 版本。
接下来我们发现，3.0.0 存在严重的问题，或者数据还没有达到正常的标准，这时候我们又更新了一个灰度版本 3.0.1 ，那么关闭了 3.0.0 继续灰度 3.0.1 的 5%，这 5% 和上一批 3.0.0 版本的 5% 是同一批用户，假设我们灰度 3%，那么这 3% 也是 5% 的子集。
而如果我们又新增了 3.0.2 ，并且加大了灰度 10%，那么 10% 将包含 5% 的用户，并新增了 5% 的用户。

涉及到多地区时，假设我只想在某个地区进行测试，应该如何操作？
Google Play 的灰度机制可以支持按国家/地区进行灰度测试，因此如果只希望某个地区是没有问题的。

出现不可逆灰度时，解决这类异常情况？
由于一般都是大版本才会走这种策略，这种策略在不删档时，会出现一些问题，就是用户无法回到旧版本，因为数据不可逆。而这时候假设，用户 A 在某些情况下使用到了新版本 3.0.2 ，但是在 Google Play 上一直显示的还是旧版本 2.0.0，导致后面下载到旧版本时，尝试使用部分功能时异常，并提示其前往升级，但是一去到 Google Play 又无法下载到灰度版本。
这种情况的处理办法就是另外创建一个 beta 版本，将 beta 版本升级为 3.0.2 ，然后告知这批用户可加入 beta 计划进行下载新版本，从而不影响正常使用。

这个知识点非常重要，划重点，因为在灰度过程中，我们往往会遇到这类反馈，而这种解决办法就是借助了 Google Play 的开放性测试的 beta 渠道方案。

业务测试结束了，我们在测试某个国家/地区的时候发现可以全量了，但是此时是灰度某个地区，是否可以直接修改为全量呢？
是可以的，如果你发现该版本在某个地区灰度没有问题后，接下来想直接全量，是可以直接操作，不需要经过审核的。

一个设备多个 Google Play 账号，如果触发了灰度机制，那么应该会如何显示呢？
假设一种场景，我 Google Play 上登录了多个账号，因为灰度机制，我有一个账号在灰度里面，另外几个不在灰度里面，那么在 Google Play 上将会显示哪个版本呢？
这时候 Google Play 会显示最新版本，假设灰度的是最新版本，那么会显示灰度版本，假设 beta 是最新版本会显示 beta 版本，如果正式版本是最新版本，那么会显示正式版本。并且 Google Play 会附带提示信息，xxx 号已经在 beta 计划里或者其他测试计划里。

Google Play 灰度是按照设备维度还是账号维度？
从其官网提供的信息，以及实际操作来看，都是以账户维度来灰度的。但是有个冲突的点，就是上面我提到的，如果该设备上登录多个账号，只要一个账号在灰度里面，并且灰度是最新版本，那么其他账号也是可以看到最新版本的，但是这类情况较少。

发现实际下载的 3.0.2 版本的用户多过 2.0.0 的灰度版本的比例数据，这是什么原因呢？
主要是因为 Google Play 的灰度只能反应 Google Play 商店的情况，还存在很多用户将 APP 爬取转化为 APK 放到了其他网站提供下载，包括国内的一些商店比如 oppo、vivo 都会主动爬取最新包，从而影响了整体的量比。
如果希望区分 Google Play 下载的用户和其他来源，应该怎么办呢？
可以应用 android 的安装器获取安装来源，从而来区分。

为什么在 Google Play 商店能看到很多旧版本的下载数据，按理应该都看到最新版本才对，或者只有 3.0.2 和 2.0.0 怎么会有其他版本的数据呢？
在 google play console 上还是能看到很多旧版本的下载数据，但是这个数据又完全来自于 google play，而不是统计了非 google play的数据。看到这些异常情况以后，我特意去查了下这种情况出现的原因，然后发现一篇文章说明：https://android-developers.googleblog.com/2018/10/offline-p2p-installs-beta.html
主要的意思是存在离线共享的情况，这种离线共享也会归属在 google play，而离线共享在 google play上的应用还比较多，可以将旧版本共享给其他用户，比如说 SHAREIt、Files Go以及Xender。