【腾讯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质量。

有了这个想法