【腾讯TMQ】有众测、不忐忑 ——记TBS内核测试优化之路

引言

随着TBS的迅猛发展，接入方越来越多。那么TBS内核发布时，如何在有限的时间人力下，合理评估对线上众多合作方版本的影响？来看看我们TBS测试是如何完成这项“不可能的任务”的。

先上个TBS三方下半年的测试效果数据：我们在测试人力投入不变的前提下，顺利完成4个TBS大版本的发布，有效保证了线上合作方的版本质量。

回首曾经——那些年的测试苦恼

TBS，即腾讯浏览服务 (Tencent Browsing Service) 的简称。

随着TBS的发展壮大，陆续有多家APP跟我们合作，发布了TBS版本的APP，使用TBS内核为其提供浏览服务。

那么问题来了，对于这些合作应用，在TBS内核发版时，我们如何确保各家的线上版本不受影响呢？

项目初期，我们采用的是“头部覆盖”方式，即重点对PV排名top的应用进行测试。在当时来看，由于接入个数不多，这种方案的效果还是不错的。但是随着越来越多的APP接入，下半年合作APP发展到上千家，总PV达到几亿。此时无论是三方个数还是量级，显然我们原有的“头部覆盖”方式已不能满足需求，而另一方面，线上非头部三方，因为TBS内核更新导致的问题扑面而来，让我们陷入了深深的苦恼。

更要命的是，通常定义，一个常规APP的“bug影响人数”是这个功能的统计人数，可对于TBS这种合作类产品，一旦出现线上问题，很可能对合作关系造成严重影响，“下架”成了我们不得不面对的问题。从某种意义上来说，我们TBS三方“bug影响人数”就是所有用户量。

于是我们TBS测试面临一个巨大的考验：每次TBS发版，高PV的好几十个三方APP都要测试到，以现有的时间和人力，怎么看都是个不可能完成的任务。

1、APP个数多。目前线上三方APP 上千家，其中重要的近百家 。在有限的时间人力下，如何确保这么多线上APP不受影响？

2、硬件覆盖度：机型、系统、各种网络情况 。如何对被测应用覆盖各种环境？

3、场景宽泛：某些应用场景很分散，比如购物类APP，包含的子页面不计其数 。如何覆盖到足够多的场景？

4、接入场景变更：线上版本的更新不可控，我们预知的TBS场景可能会随着合作方发版而有所变更。 如何实时更新TBS场景？

5、问题影响大：一旦出现问题会导致合作关系破裂，TBS被下架，PV严重受影响，尤其是PV高的合作方，伤不起。

初遇众测——可行性分析

企鹅众测，是基于真实用户测试的平台。众测团队接到移动APP研发团队的测试需求，一键发布众测任务，成千上万的用户同时帮产品做测试，并且覆盖全国各地用户，多种机型及网络环境。BUG探索、产品调研、数据收集、产品评测，四大类业务模块满足多种需求，多维度的用户信息帮助问题快速解决。

初遇众测，是被众测真实的用户群体所吸引。试想在TBS内核发布前，我们将无法覆盖的app以并行任务形式发放给众测用户，让他们帮助我们一起为内核质量把关，这样就能从时间和人力上减少发布风险，确保线上app质量。

有了这个想法，我们结合T实际情况，先从如何测TBS着手，反复思考最优方案，开始摸索TBS三方的众测模式。

一些方案的思考和落地，给同类型产品同学参考：

Q1：如何让用户共享到待发布内核？

解决方案：

设想1：在正式环境后台添加imei——风险较高，不可行 ；

设想2：参考宿主，扫码或网址方式添加内核——大部分三方没有入口，不可行 ；

设想3：使用Demo共享，由于Demo优先级最高，可以忽略其他影响。

Q2：TBS在终端是无法感知的，那么如何让用户有意识的去测TBS？

解决方案：

设想1：不区分，只要有问题都提上来——我们的核心目标是发现TBS问题，如果这样，审核成本过高而受益有限，不符合预期；

设想2：收集准确的TBS场景，告诉用户——合作版本的接入场景随时会变动，没法控制，不可行；

设想3：在内核打标识，比如下图的“网格线“”，以此通过页面渲染的展现效果，让用户方便的区分哪些页面跟TBS有关。这种偏主观的测试方式刚好可以发挥用户的能动性，达到测试场景充分的效果。

Q3：用户如何分辨反馈的问题是否跟TBS有关？

解决方案：最直接的办法是跟一个不接入TBS的合作版本对比，但是如何做到呢？

设想1：合作方重新打包不带TBS的版本供测试——对合作方依赖性强，不可行；

设想2：参考我们自己测试的办法，卸载本地共享到的宿主内核——用户操作太复杂，不可行；

设想3：，我们正好利用内核“可升不可降”的逻辑，只要保证被测demo包的版本号最高，那么卸载demo后三方只能使用sys，刚好与我们对比的条件符合。

联手众测——如何提测

1、发布策略

【策略一】头部应用的优先级划分：目前线上三方10W以上有近百家，我们对这些APP从“合作关系”、“PV量级”、“场景广度”、“金钱关联度”几个维度综合考虑，进行优先级划分。原则上优先级高的应用放在前期测试，最大程度减少发布风险。

（1）合作关系：不同合作方出现问题的风险是不同的。一般来说内部应用相对比较缓和，而外部应用由于自身利益考虑，对线上问题比较敏感，随时可能回退版本，下架TBS。因此，我们的策略是：合作关系越脆弱，优先级越高。

（2）PV量级：合作APP的使用人数，我们是通过上报监控来获取这部分数据的。一般来说，量级越大，说明使用人数越多，重要度也越高。

（3）场景广度：某些APP的接入场景很宽泛，涉及的页面特别多，单凭人工测试难以覆盖，可能存在遗漏导致的测试风险。

（4）金钱关联度：接入场景涉及购买、支付的APP，一旦TBS出现问题，会直接影响合作方KPI，处于对方角度，这类要特别小心。

【策略二】众测可操作性分析：我们将待轮询的APP，根据其特点，分别以“人工轮询”和“众测轮询”方式操作。经验上，功能型和游戏类APP，使用门槛较高（比如账号级别、基本使用规则等），因此我们列为“人工轮询”类。而大多数浏览型APP，偏向于页面浏览覆盖，用户上手成本较低，有一定趣味性，适合众测，我们归为“众测轮询”类。

这部分内容是比较通用的，一般来说不用发布前频繁更新，但要注意，社会热点、运营活动等因素影响下，某些APP的PV排名可能会有剧烈变化，比如前一阵直播比较火，虎牙直播的PV就突飞猛进上升到百万量级，测试要特别关注。

2、众测发布流程

第一步，进行发布前Check，准备好以下资源：

TBS demo网格线包：准备待测内核的demo包，要求内核渲染有网格线标识，方便用户识别 。

demo版本号检查：为了方便对比，demo包需要比线上内核版本号高，避免卸载demo后，共享线上内核，无法使用sys；

线上TBS场景review：检查待测线上版本的最新TBS接入场景，供众测用户测试参考；

准备相关截图：为了保证测试效果，需要对操作步骤截图指引；

确认反馈方式：本次测试的要求，如果有预埋上报log可不做要求，其他情况一般要提供截图、视频、或者logcat等信息，便于后期验证和跟进；

预期反馈描述：明确反馈问题类型，比如TBS三方主要是显示和功能问题，尽量避免需求建议吐槽等无关反馈；

设计反馈分类：要求用户对比sys，以此区分APP问题还是TBS问题，达到初筛的目的。

第二步，自助在众测官网提测。

众测发布入口tesly.oa.com/access 接口人：黄天化（化名）上传相关内容，我们就可以直接提交众测申请，等待发布了，提交成功后有邮件同步。

3、众测发布后关注

由于TBS的特殊性，线上APP版本有可能实时更新导致场景变化，如果出现，要及时修改任务内容（主要是TBS场景参考部分），避免众测用户扎堆反馈场景失效，干扰测试结果。

案例：2.4版本的墨迹天气，首页人物右侧的“红包”logo，点击进去是TBS场景，于是把这个场景写进提测内容，要求众测用户进行测试，但是任务发布后，墨迹天气的后台临时把这个场景去掉了，因此很多众测用户反馈找不到我们指定的测试场景。后来通过对线上任务的变更，修改了这个问题。后续我们提测时，也注意对不确定的场景不做指定，仅做参考。

收到众测反馈——如何审核

有意向使用众测的同学，可能最担心的一个问题就是“审核成本”。面对大批的众测用户反馈，如何在有限的时间内去找到我们最关注的内容？我们TBS通过持续的优化改进、以及众测同学的功能配合，已经小有成效。

1、审核利器

利器一：预分类设计

通过对提测任务时的分类设计，快速区分几大类问题，让用户帮我们找到重点问题。

始终无网格线：即调起问题，始终没有调起TBS，属于TBS的调起和加载问题 。

非网格线页面反馈：即APP自身问题，与TBS无关，整体优先级低。
网格线页面反馈，且卸载demo不存在：即TBS存在，sys不存在的问题。与我们的内核关系密切，优先级最高，重点验证 。

网格线页面反馈，且卸载demo也存在：即sys共有问题，优先级低，仅对严重影响体验的反馈做跟进，同步合作方。

利器二：军团的长期培养

“军团”是众测为长期任务培养的固定用户群体，也是众测服务的亮点之一 。

文档学习：我们结合TBS三方特点，以任务的方式对军团发布学习文档，并辅助以考题检验军团学习成果，提升TBS三方测试军团的TBS基础技能，从而提升反馈有效率，减少无效、无关反馈。

团长审核：要求团长对军团反馈的问题做验证和筛选，标注“重点关注”，减少我们的审核投入。

团长复现：团长用自己手机对重点问题做复现，二次确认复现概率
输出报告：团长汇总输出众测结果，给到提测方。

利器三：结果可靠性保证

我们通过以下几方面来保证众测结果的可靠性：

抽查制度：团长对测试结果抽样检查，一旦发现与反馈不符，有严格的惩罚机制 ；

用户星级：对用户TBS测试能力关联反馈质量，划分级别 ；

自动检测：以SDK形式嵌入APP中，自动收集用户的测试内容。目前未做，主要原因是合作方出于安全性考虑，比较难接受，后续打算在内部APP上做个尝试；

线上反馈重合度：正式发布后，结合线上反馈对测试内容进行review分析。

利器四：合理利用测试结果

反馈关联性：用户的反馈一定程度上反映了用户的实际使用场景，结合反馈问题的分布情况，强化某些TBS场景用例的测试优先级，建立“高危场景区”，有利于在有限时间抓住测试重点，更好的保障产品质量。

兼顾正向反馈：要求用户逐条反馈，其中也包括正向反馈，这样更合理的整体评估用户对单个场景的覆盖度。

内核能力风险评估：创建评估内核能力的7个维度：调起、显示、功能、搜索、下载、视频/音频、购买、，让用户基于从纯APP使用者的角度，发挥主观能动性，自选APP场景，整体评估TBS内核能力，更适合评估内核能力风险。

2、审核基本流程

第一步：通过预设分类，用网格线标识区分TBS相关场景、用sys对比方式排除系统问题，方便的筛选出真正和TBS有关的反馈，大幅提升测试效率。

第二步：团长验证，同步结果。要求帮派团长基于上述原则，对帮派反馈逐个进行验证，标注“重点关注”。

第三步：我们只要检查验证测试单里的最核心问题高效的完成众测任务。

审核原则：网格线页面的显示、控件功能，不关注需求优化 。

随机问题处理：严重影响体验的，先尝试优测同机型复现 http://utest.qq.com/，如果仍然无法复现，联系用户配合验证。

**
非网格线反馈**：仅关注闪退、崩溃等严重问题，其他不关注。

网格线反馈，卸载demo不存在的：重点验证，转tapd区。

网格线反馈，卸载demo也存在的：判定为APP自身问题，转合作方接口人跟进。

测试效果

可见，通过众测平台的利用，下半年我们在TBS三方测试人力不变的客观条件下，取得了了以下几方面效果：

1、 头部APP的覆盖：从原有的内核发布测试5个APP，发展到“三周轮询制度”，累积可覆盖31个头部应用，覆盖个数是上半年的6倍；

2、 硬件覆盖的提升：从原来人工测试覆盖3台机器，到下半年利用众测，可覆盖30种以上硬件；

3、 测试效率提升：上半年纯人工测试5h/APP，下半年通过任务发布的优化、审核方式的优化、以及军团的培养，成功减少到1.5h/APP,测试效率提升3倍以上；

4、 内核发布的风险评估：有轮询数据支撑，提前评估已知问题影响，更加可靠的评估发布风险；

5、 线上反馈减少：下半年没有出现因为内核发布导致的线上版本严重问题，头部应用反馈呈收敛趋势。

小结和展望

以上是我们TBS三方下半年测试的一些尝试和经验小结。目前还有一些优化方案在进行中，。

1、 合作方发版跟进：发布长期众测任务，帮派自主跟随合作方发版节奏，遇到问题反馈，以此避免合作方发版和线上内核的适配问题；

2、 自动化的结合：每日监控头部应用的核心场景，快速发现问题，解决问题；

3、 “TBS三方测试白皮书”的推广：目前先在帮派内部推广，加强用户TBS基础知识、标准化反馈排查流程，以此提升众测反馈有效率，减少测试后期审核投入。后续，希望能挂在TBS官网，作为指导文档，助力合作方自主接入。

最后，给和我们一样有发布前风险评估苦恼的小伙伴们做个推荐：

有众测、不忐忑！ 众测，你值得拥有! http://tesly.oa.com

关注微信公众号腾讯移动品质中心TMQ，获取更多测试干货！

版权所属，禁止转载