以 K12 产品为例，说说如何组织用户内测活动

 

在产品功能上线前，最后的环节一般是由测试同学撰写产品测试用例，测试通过后部署上线。

但由于测试同学人力有限，对于用户的使用场景、设备类型以及网络情况很难做到全面模拟，难免有所疏漏；遂在产品上线前增加小规模的用户内测环节，对于提高上线后的产品质量，减少 Bug 出现的风险，会有一定的帮助。

那么，如何去组织一场用户内测活动，需要注意的点都有哪些？通过这篇复盘文档，我们从0开始梳理这些问题。

01 回顾目标

回顾历次的用户内测活动，目标一共可以分为以下三种：

1）暴露未测试到的 Bug

如果产品涉及比较大的更新，例如上线全新的功能或是更改大范围的程序代码，此时就需要重点关注在测试过程中出现的 Bug 数量和 Bug 类型，关注是否有影响用户使用的问题出现，以及出现的频率；然后再依据问题的类型和数量去判断优先级，对接产研同学去修复问题，保证最终上线的质量。

2）预知产品上线后可能的风险

通过内测活动，我们需要模拟更多接近真实的使用场景，从而去发现隐藏其中的问题，也可以通过对内测安装包的数据埋点，拿到该功能一部分的用户使用数据，从产品研发的角度，去预知产品上线后可能的风险，从而进行规避，做好应对方案，提升产品的稳定性。

3）收集用户的反馈

内测活动是产品和用户进行沟通的好机会，我们可以借此机会收集用户对于产品和功能的建议或评价，当然不一定局限于每次的重点测试功能，用户对于产品全局的意见统统可以收集，作为后续产品迭代的参考。

02 回顾过程

在确定一场内测活动的目标后，在活动流程中有哪些需要关注的点呢？我从以下5个方面分别来整理一下。

1）人员招募

拿我之前组织过的几次活动来说，因为产品的类型是 K12 学生用户，主要集中于小学年级。

如果直接招募小学年级的学生作为测试用户，一是会影响学生的学习进度，另外如果出现比较严重的产品质量问题，会不利于产品形象的塑造；所以，我们将招募的人群属性定位在小学年龄段的宝妈群体。

那如何去找到这类人群呢？

我们将目标锁定在了一些正规的兼职群、兼职论坛，通过发布任务信息招募用户进群，方便进行后续的任务指导；在这个环节我们还发现，经常参加兼职活动的人会有自己的兼职圈，通过向这些用户借力，可以让我们的招募进度产生裂变的效果。

我们在人员招募和管理时，选择了 QQ 群的方式。因为 QQ 群提供了比较完善的群管理和群文件支持，可以在流程上减少我们的人力。

如果产品是非 K12 类的话，也可以通过正式版本 App 内的弹窗提醒，来招募意向参加内测的用户，引导这些用户主动下载测试版本的 App，配合反馈活动去引导大家充分测试、暴露问题；但此方法对产品类型、用户属性又会有一定的限制，且需要产品研发同学的支持，大家可以按照实际情况进行选择。

2）活动成本

为了激励内测用户更充分的参加活动，我们可以设定一定数量的奖品、奖金等激励方式，如果是社交属性比较强的产品，也可以发放站内勋章、称号等虚拟物品。

激励方式选择的前提是要保证大部分的用户都会喜欢，这样才可以激发用户反馈的动力；如果最后的活动奖励对于用户来说不痛不痒，那活动的效果可能会大打折扣。

由于我们招募的活动用户大部分来源于外部兼职论坛，所以我们就采取最直接的方法——奖金，作为激励方式；奖金发放的标准以参加测试的时长、问题反馈的数量质量为标准，因为所有参与活动的用户都已经添加到QQ群内，所以我们可以通过群红包的形式，来节省我们发放奖金的人力。

通过每次内测活动的人数，我们可以预估活动的成本支出，以此来向 Leader 或者合作的业务部门进行报备；另外，因为发放群红包不能取得发票，所以还需要提前和财税同学来确定流程的合规性。

3）组织测试

接下来就要开始准备测试了，这个环节也是非常重要的一个环节，会直接决定我们的活动目标是否完成。

首先，我们需要和产品研发同学确认测试版本安装包的交付时间。在之前的实操过程中，因为已经在报名时建立了活动群，就可以把安装包发送到群内，引导参与活动的用户下载安装。

在安装过程中需要注意，iOS 用户需要下载官方测试的 Testflight App才能参加测试，Android 用户需要在安装过程中留意手机是否有提醒“跳转到官方市场安装、该版本未通过验证”的提示，需要引导用户跳过这些提示，确保用户安装的是参与活动的版本。

那怎么去引导用户针对新上线的功能进行测试呢？我这里采取了两个办法。

因为是 K12 直播授课类的产品，针对于有关直播才可以测试的新功能，可以协调内部同事通过模拟老师真实的上课情况；在设定好直播时间后，及时的通知内测用户预留时间参加，然后在直播的过程中引导内测用户的操作。这里需要注意的是，如果是通过直播引导用户参与测试，那么要在直播中去描述如何操作、操作产生的结果以及如何去记录问题，方便后续的问题追溯。

除此之外的非直播课功能，可以通过截图标记、录屏或者 gif 图、流程图的形式，做一个功能操作的说明文档，以图文、视频的形式去引导用户操作，从而暴露问题。

4）问题收集

因为内测版本和正式版本的不同，为了避免内测活动对正式版本的反馈数据有影响，所以在问题收集的环节需要选择一个独立的收集用户反馈的入口。

在之前的活动中，我采用的方式都是问卷收集，请参与活动的用户填写自己的账号、遇到问题的时间点以及对应的截图或者复现录屏，再配合产品的埋点数据，已经基本满足定位问题的要求。

收到内测用户反馈的问题后，要对用户描述的问题以及问题的紧急程序进行排序整理。为了计算相同类型的反馈出现的频率，在整理用户反馈时，除了要将用户的基本信息（账号、设备类型等）和反馈信息（问题描述+截图）进行对应外，还可以将用户描述的问题以不同类型的词语代替，以便于最后统计同一问题的量级；对于不理解或者不能确定的反馈内容，需要和用户进行二次确认，切勿进行推测。

5）后续跟进

在整理完用户反馈的问题后，可以将文档发送给负责项目的产品研发同学来进行后续跟进。

在文档中，针对于用户反馈的影响使用的问题，需要评估是否属于 Bug 以及后续的修复计划；针对于用户的需求建议，需要评估后续是否需要迭代以及迭代计划。

03 评估结果

对内测活动的结果分析，有助于我们评估每次活动的效果和质量，有以下两个维度：

• 活动人数：目标招募人数，实际招募人数、内测版本安装人数、问题反馈的人数；
• 反馈质量：活动总反馈数量、有效反馈数量、确定是Bug的反馈数量、确定是需求建议的反馈数量。

通过对比每次活动中的 实际招募人数 → 内测版本安装人数 → 问题反馈的人数中每个环节的转化率，来帮助我们去优化活动的形式；而通过有效反馈数量和活动总反馈数量的变化，可以帮助我们优化内测用户的反馈教育环节，帮助我们获取更高质量的反馈。

04 分析原因

这个环节说两个我曾经在活动中踩过的坑，希望可以帮助大家避雷。

最初，为了激发报名用户对于发现问题的积极性，设置了额外的反馈奖励，并把奖励标准设定成了反馈数量的前三名；前几次活动结束后我们观察数据，发现有效反馈的占比只有 40% 左右，重复反馈和无效反馈的数量会比较多。

于是后面我们就更改了反馈奖励的规则，以“质量 + 数量”为标准，并公开反馈质量较好的反馈，给到参与活动的用户一个正向的促进作用；在后续的内测活动中，有效反馈的占比就可以稳定在 70% 左右。

还有一次 500人+规模的内测活动，我们依然使用 QQ 群这种方式去做 1 对 N 的用户管理与内测教育，但活动人数的增长导致内测教育的难度增加，1 对 N 的模式显然已经不再适用。

在活动结束时为参与用户发放奖励时，也会因为频繁的进行红包交易而被腾讯官方敏感提醒，造成封号风险；针对于这种情况，我们在建立活动群时一定要将备用的管理账号也拉入群内，同时增加内测教育的人力。

从长期来看的话，在历次活动中发掘一部分内测的优质用户，并赋予这些用户推广、管理内测活动的能力，对于释放我们自身的人力也会有很大的好处。

05 总结经验

因为 K12 行业的特殊性，所以我们选择了 QQ 群发放内测包 + 招募外部用户的方式，来对即将上线的新功能进行测试。

内测活动的关键，就是要招募到足够的用户，得到更多的反馈后去支持产品迭代；内测版本对比正式版本，会提前体验新功能，在招募时配上“限量招募”“邀请体验”的字眼，可以助力我们的招募进度。

在内测进行中，要做好对内测用户的功能宣传与反馈教育，设定合适的激励机制从而去得到更多高质量的反馈。

同时，要及时的发掘在内测活动中积极参与且反馈质量较高的用户，将这类用户塑造为我们每次内测活动中的“形象角色”，给到其他参与活动的用户一个正向的积极作用。

 

作者：白说运营

来源：白说运营