TBS 主线众测实践之路

作者：芦世先

团队：腾讯移动品质中心TMQ

导读

TBS（腾讯浏览服务）是基于X5内核，给APP在展示web页面时提供的相关的浏览服务，主要包括渲染，排版，网络，安全等方面的能力。TBS作为一个典型的SDK类产品，将TBS SDK内置于合作APP（简称宿主）当中，然后通过TBS SDK动态的加载TBS内核，来给合作APP提供浏览服务。

图1-TBS架构简图

随着业务的扩张，TBS从原来主要服务于微信，手Q等业务，迅速扩张到同时服务于，例如唯品会，京东等，多家应用，PV量巨大。无论是服务APP，还是定制技术需求量，测试任务，和质量要求都出现暴增，测试面临极大挑战。

如何更好的响应业务需求，提供良好的质量保障，TBS测试除了通过测试优化等多种手段，提升内部测试效率之外，也一直在寻求不增加测试人力的情况下，其他提升效率的方法。

考虑到TBS用户量巨大，用户使用场景千变万化，手机移动网络复杂多变，Android平台本身碎片化严重，单纯依靠测试内部的实验室环境，很难覆盖用户的真实使用情况，这个时候众测进入了我们的视线。

企鹅众测平台利用腾讯海量用户的优势召集了成千上万的真实用户来参与测试，通过tesly.oa.com平台一键发布测试任务，每日有数千个专家用户参与测试，能够覆盖覆盖全国33省368个地区、国内所有运营商网络，以及5000余款Android独立机型。通过需求沟通、任务分发、反馈收集、反馈跟进、任务报告的形式实现闭环。

结合企鹅众测的优点，以及TBS项目的自身特点，我们进行了深入的分析，探索众测在TBS主线测试上的应用。

测试分析

TBS的测试特点分析：

1）测试复杂度：TBS是一个典型的SDK技术型产品，多数需求和功能都是技术型需求，例如提供一些宿主定制的接口或者底层能力，因此并不是所有功能都能以UI的形式让用户感知到，此外有些需求还需要跟开发多次沟通才能梳理清晰。

2）条件门槛：此外由于TBS内核动态加载，以及云控等能力，又涉及到后台配置等复杂操作，考虑到产品安全性等，这些后台配置操作需要具备相关权限的人员才能进行配置。

3）覆盖度：由于TBS是服务于多个宿主的产品，难免出现宿主定制化功能，因此除了常规的ROM，或者机型的兼容性测试以外，还会涉及到宿主兼容性测试，甚至有个别需求，需要项目人员自己编写demo来调用相关接口进行测试。

总体来看，TBS功能测试难度较高，所需要具备的测试条件也较为复杂，覆盖度也根据需求特点呈现较多变化。

众测特点分析：

1）覆盖度：众测无论在网络，机型还是ROM，用户操作方式，应用类型等方面的覆盖度都是惊人的

2）时效性：由于众测任务发布和结果收回需要经过需求沟通、任务分发、反馈收集、反馈跟进等环节，需要一定耗时，因此不适合时效性特别高的测试。

3）复杂度：TBS的多数需求都为技术类需求，需要具备较深的知识基础，和较好的技术理解能力，考虑到培训成本，沟通成本的等因素，因此这类需求不太适合发布众测。

TBS测试类型分析：

结合TBS整个项目周期中的不同测试类型，从多个维度分析不同类型测试的相关诉求，来判断哪些适合使用众测。

表1-TBS各类测试特征表

从表1中可以看出，时效性要求不高，耗时较长，用例相对稳定，测试门槛不太高，另外不需要后台配置的测试，比较适合发布众测，并且众测也能够发挥较多自身的优势。

结合这些分析，我们决定在集成测试上，来尝试使用众测。

是否所有集成测试用例，都适合发布众测呢？我们先对集成测试用例结构进行如下分析：

表2-TBS集成用例结构分析

表中宿主1、宿主2、和宿主3分别代表了TBS用户量Top的三个宿主，也是我们TBS主线测试覆盖的常规宿主，结合表2中的集成用例结构分析，我们X5核心功能和三个宿主的自有业务，由于用例较为固定，不涉及需求沟通和后台配置，此外测试难度中等，因此适合发布众测。

众测发布策略分析：

通过表2中我们需要众测的用例内容分析，我们梳理出如下的众测发布策略。

图2-众测发布策略

通过对众测发布的原则，如何保证结果可靠性，兼容性覆盖三个方面的分析后，我们明确了众测发布策略如下：

扫除障碍——众测指导书

有了明确的众测发布策略之后，我们再逐步梳理众测过程中可能遇到的问题，并提前扫除障碍，形成有效的众测指导书，提升整体效率，主要分为以下4步。

安装指南：扫描二维码安装

提供TBS安装包的二维码给众测用户，用户扫描二维码即可安装TBS，用这种方法降低用户的安装难度（原来的方法中，用户共计需要操作10步才能安装成功），并且扫描二维码的方法帮我们避免的安装包外泄的风险，因为用户唯一接触到的就是二维码，而不是安装包本身。

调试工具

TBS安装后，普通用户无法通过简单的查看设置等方法查看TBS的版本号、是否安装成功等，可是通过adb查看日志文件的方式又较为复杂，因此我们提供了调试工具，方便用户查看TBS安装是否成功，版本号是否正确。

另外用户在测试过程中，有可能存在需要清除当前TBS，再重新安装另外一个版本的情况，因此debugtbs也提供了清除TBS内核的快捷方法，一键清除。

问题定位：对比系统内核

如果测试过程中发现bug，为了进一步帮助开发确定是宿主问题，还是TBS问题，或者是系统内核共有问题，还需要对比系统内核。debugtbs提供了在TBS内核和系统内核之间切换的快捷方法。

此外我们对安装指南，调试工具和内核切换等使用方法进行整理，形成了《TBS内核集成用例众测任务指导书》随众测任务一起发布给用户，方便学习和操作。

详情纪录：用例详情

为了方便的纪录每条用例的执行详情和测试条件及测试结果等信息，我们也制定了详细的表格，引导众测用户进行结果纪录，主要涉及到如下几项：测试结果、系统内核表现、测试机型、测试ROM、测试宿主及版本号、问题描述、现象截图\录屏、测试网络。具体用例情况如下图3所示：

图3-众测用例详情纪录

TBS集成用例众测三部曲

有了这些准备工作之后，我们基本上可以顺利的开展集成用例众测任务了。

但是因为TBS用户量巨大，产品质量稍微有一些疏漏，可能就会给大量用户带来影响，而对于众测用户在TBS集成用例上的执行效果和效率，我们都还缺乏第一手的资料，因此我们采用了如下图4几次逐渐夯实基础，让实际效果更加可靠和扎实。

图4-TBS集成用例众测三部曲

实际收益

通过我们的逐步摸索和尝试，最终可以完全放心的按照最初设定的TBS众测策略发布众测任务，并且获得值得信赖的结果，与此同时，在效率和质量方面，我们也有明显的收益。

在人力节约，覆盖度提升，以及发现更多的问题方面，众测都有很好的表现。然而我们在众测上的使用成本却很低：每次任务发布+审核总共投入1.5小时。

真正的：低投高产。

图5-TBS集成用例众测效果

思考和总结

以上是我们在TBS主线上探索众测使用方法的一些思路和方法，后面我们也希望继续探索出更多提升整体工程效率的方法，并且能够更好的使用众测平台。

（1）更快：当前当前众测集成任务发布到收回结果：历时3天2晚，后续探索能否做到更快的相应；

（2）更多：除了集成测试以外，探索更多的众测使用场景，来更好的服务项目。

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