更多移动技术文章请关注本文集：知乎移动平台专栏

前言

内测和灰度是客户端版本迭代流程中的两个重要阶段。在这两个阶段，客户端的新功能会被真实的用户使用到。通过用户的反馈，我们往往能够发现在产品设计、开发、测试中没有发现过或被忽视的各种问题。内测和灰度的用户反馈能够更有效地帮助我们改善产品设计和提升产品质量。本文将会介绍内测和灰度的一些基本概念，以及我们在知乎是怎么做内测和灰度的。

什么是内测和灰度？

内测

在我们开发完某个新功能并通过测试之后，有时需要邀请部分用户试用，收集一些意见和建议，对产品进行进一步的优化。在某些情况下，内测用户的反馈可能会影响到整个产品的决策。

内测用户有两个来源：一是知乎的内部员工，内部员工在研发过程中更容易下载并使用到内测版本，同时会更加积极地使用并进行反馈；二是外部用户，我们会精心挑选反馈意愿强烈的热心用户，发送私信邀请他们进行内测。内测用户数量不需要太多，能够有一些有效的反馈就达到了我们的目的。在早期，无论是知乎内部员工还是有意愿参加内测的用户，数量都是比较少的。

灰度

随着知乎客户端功能越来越复杂、迭代周期越来越短、用户量越来越大，测试难以覆盖到所有使用场景，即使新版本通过测试，直接对所有用户进行发布仍然存在一定的质量风险。同时，由于客户端发布之后无法像 web 端或后端服务一样快速回滚，质量风险有时是我们无法承受的。这就需要灰度发布来帮助我们降低相应的风险。

灰度发布是指在正式上线前，只给小部分用户发布新版本，而剩余用户不受影响继续使用旧版本，如果新版本没有问题则进行全量发布，有问题则修复问题并重新灰度。一般来说，灰度发布的用户数量相对于内测用户较大，这些被灰度到的用户可能对自己所使用的是灰度版本并不知情。

比较

以上介绍了内测和灰度的一些基本概念，二者的一些差异如下表所示：

image.png

在知乎我们怎么做内测和灰度？

无论是内测和灰度，我们都面临三个问题：如何让用户下载内测/灰度版本？如何持续让用户使用最新的内测/灰度版本？如何收集用户反馈？
第三个问题将在后文中详细说明，对于前两个问题，内测和灰度分别有不同的方案，而在 iOS 和 Android 这两个平台上，方案也有些区别。

内测

iOS 和 Android 客户端的内测方式是完全一样的，在版本新功能开发完成并经过测试后，我们会把安装包发布到 知乎内测平台 上供用户下载（目前仅支持知乎 iOS 的内测版本下载），而未经过充分测试的安装包只会发布在内网，供内部员工试用。

image.png
在内测用户的邀请策略上，我们经历了两个阶段：

• 邮件邀请内部员工 + 私信邀请外部用户
• App 内邀请内部员工 + 线下活动邀请外部用户

在刚开始做内测时，我们很容易想到「邮件+私信」的邀请方式，邮件会发给公司全员，收到私信的用户也是经常通过各种渠道向我们提交反馈的热心用户，即便如此，内测用户的数量也是很难做上来的，仅靠邮件和私信的转化率比较低。

在这一阶段，内测用户的流失也是个很令人头疼的问题，无论是内部员工还是外部用户，流失率一直都很高，提交反馈的意愿也在慢慢降低。为此，我们曾组织过一个名为「Bugday」的活动，以月为单位给积极反馈的员工发放各种小礼品，在一定程度上提高了大家使用和反馈的积极性。我们也想过把「Bugday」推广到外部用户，但由于运营和公关上的一些考虑没能成行。

一波接一波的私信邀请后，可用的目标用户池越来越小，转化率也越来越低，内测用户数到达 1000 人 的峰值之后，拉新的速度开始赶不上流失的速度，内测用户数慢慢变少了。与此同时，知乎的业务线慢慢扩张，诞生了一批更加细分，用户基数相对于整个知乎社区较小的业务，邮件+私信获取到的用户往往与这些业务的目标用户不匹配。于是这些业务选择了通过线下活动获取内测用户的方式，通过盐 Club 、Open Day 、用户沙龙等线下活动形式邀请用户使用内测版本并收集反馈。

那么对于内部员工呢？随着知乎的壮大，员工人数也越来越多，逐渐成为一个丰富的内测用户资源池，我们借鉴了 Facebook 的先进经验，给办公室内的市场版 App 弹出下图所示的弹窗，邀请并鼓励内部员工参与内测，这样相比于邮件邀请更为高效，再次强调一下这个弹窗仅限于 办公室内的市场版 App ，外面的用户不会受到打扰。其实，这里所说的内测并不太准确，我们现在本质上是把办公室用户作为灰度用户的补充，严格来讲目前并不存在员工内测，只有对内部员工发灰度。

image.png

灰度

由于苹果的限制，iOS 灰度的实现与 Android 有很大的区别，在这里我们分别介绍。

Android

对于 Android 我们使用 应用内更新 的方式给用户下发灰度包，当 App 启动或从后台切换到前台时，客户端询问后端是否有可用的灰度版本，若有可用的灰度版本，则客户端以弹窗的方式提示用户可以更新。灰度用户量可以通过后端开关开启的时间长度来控制，应用内升级的速度很快，很容易就能获得大量灰度用户。后端开关开启时，用户也可以通过点击「设置 -> 检查更新」升级到灰度版本。

iOS

由于苹果只允许用户在 App Store 内下载 App ，无法使用应用内更新的方式进行灰度。虽然苹果官方提供了 Testflight 供开发者用于内测，但在几年前 Testflight 并不成熟，在使用上也存在诸多限制，所以在早期我们并没有做 iOS 的灰度，或者说是用内测的方式代替灰度，用户量最多达到 1000 左右，这是 iOS 灰度的第一个阶段。期间我们考虑过扩大内测版的用户量，继续将内测当做灰度，但内测包自身其实存在着各种问题：

• 用户可以同时安装内测版和市场版：若同时安装两个版本的 App ，在内测版中使用 URL Scheme 跳转会跳到市场版中，给用户造成困惑，同时存在两个版本的 App 用户更容易卸载掉内测版；
• 内测版部分功能缺失：由于微博方面的限制，我们没有在内测版支持微博登录和分享；
• 政策风险：苹果理论上不允许开发者将内测版的企业包给到用户安装，曾经有其他公司因此被威胁下架。
  由于内测包的这些缺陷，我们最终还是尝试使用 Testflight 作为灰度的方式，邀请方式仍在采用私信邀请，试用期间我们体验了用户安装成本高、审核时间长、灰度用户人数限制等问题，而其中最令人头疼的还是用户安装灰度版的成本很高，Testflight 要求接受内测邀请的用户提供邮箱地址，在用户收到 Testflight 的邀请邮件后，再到 Testflight 的 App 中输入邀请码从而获得内测资格并安装灰度版，由于安装流程过于漫长和复杂，很多用户在中途就放弃了。在我们改用 Testflight 之后，灰度用户数量并没有明显增加，保持在 1200 人左右，以上是 iOS 灰度第二个阶段。
  随着时间的推移，苹果对 Testflight 做了一些优化，同时我们也发现存在一种免邮件的邀请方式，于是形成了第三阶段的灰度方案。首先我们会注册多个邮箱并将这些邮箱注册到 Testflight 后台，随后 Testflight 后台会自动给这些邮箱发送邀请码，我们再从邮箱中爬出这些邀请码，存储到数据库中，当市场版的用户做了收藏、点赞等正向操作时，客户端会认为该用户是灰度版本的潜在用户并请求一个邀请码，收到邀请码之后会引导用户更新到内测版。由于 Testflight 对用户有数量限制，我们会定期清理过期和无人使用的邀请码，保证数据库中有足够多可用的邀请码。

下表对 iOS 灰度这三个阶段做了一些比较：

image.png
另外，App Store 本身也有对于灰度的支持，对于一些风险比较大的版本，我们有时会使用这种发布方式。

如何收集反馈

用户开始使用灰度版之后，我们会通过 Fabric 收集用户遇到崩溃，用户也可以通过摇一摇将自己遇到的问题提交到我们的反馈收集平台。
我们也做了一些周边工具，如崩溃监控和报警、一键提交反馈到 jira 等功能，帮助我们提高收集用户反馈的效率。

未来的改进方向

以上是我们在知乎进行的内测和灰度的实践，通过几年的摸索和持续迭代，内测和灰度有效帮助我们提高了知乎客户端版本质量。同时我们还有一些有待改进的地方希望在今后持续优化，可优化的点包括但不限于：

• 更高质量：提供更高质量的灰度包给到用户，把灰度当做全量发布前的一种验证手段，而不是寄希望于让用户在灰度期间发现前期没有发现的问题
• 更少次数：减少灰度发布的次数，减少用户流失
• 更多维度：支持给特定的机型、系统、地区、特征的用户下发灰度包，使得灰度更加精确

One more thing

如果您对知乎 iOS 的新功能感兴趣，欢迎访问 知乎内测平台 下载并试用内测包，介四里没有丸过的船新版本，可以体验到还没有发布到 App Store 的新功能。

欢迎有志于质量保障工作的知友们加入知乎 QA 团队，与知乎一起发现更大的世界，详细职位可以参见 这里，期待知友们的加入 ~

关于作者

王守宇，知乎资深 QA 工程师，目前专注于质量保障，工程效率，DevOps 领域