引言

随着 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，获取更多测试干货！