引言
随着TBS的迅猛发展，接入方越来越多。那么TBS内核发布时，如何在有限的时间人力下，合理评估对线上众多合作方版本的影响？来看看我们TBS测试是如何完成这项“不可能的任务”的。
先上个TBS三方下半年的测试效果数据：我们在测试人力投入不变的前提下，顺利完成4个TBS大版本的发布，有效保证了线上合作方的版本质量。
回首曾经——那些年的测试苦恼TBS，即腾讯浏览服务(TencentBrowsingService)的简称。
随着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就突飞猛进上升到百万量级，测试要特别北京治疗白癜风选择哪家好青海治疗白癜风的医院