【腾讯TMQ】TBS三方SDK自动化探索

作者：张佳

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

【导读】

对于非宿主的合作伙伴来说，在TBS接入环节，“共享和下载内核”的能力是最重要的，它从根本上决定着APP是否能够使用预期的X5内核提供服务。一旦出现问题，会导致无法加载X5内核或者优化策略失效，从而降低X5占比。但面临的一个问题是，SDK是跟随TBS版本持续优化的，每次SDK发布，都会有大批小伙伴更新apk来提测。

【测试时机】

SDK发布后，会有合作方陆续接入新SDK提测，比如：

2.4 SDK发布：某某视频+2.4SDK，某某会+2.4SDK、某某输入法+2.4SDK、某某宝+2.4SDK 等 ；

2.5 SDK发布：某某直播+2.5SDK，某二次封装SDK+2.5SDK、某东+2.5SDK、某某音乐+2.5SDK等 ；

3.1 SDK发布：某某新闻+3.1SDK，某某音乐+3.1SDK、某某微信+3.1SDK 等。

【测试内容】

上面可以看到，每次更新接入新SDK的小伙伴还是比较多的，而我们主要测试两个功能点：

（1）接入是否成功 ；

（2）接入后的SDK逻辑是否符合预期 。

具体表现为，新的SDK在各种场景下是否能正常使用到内核，比如：

首次安装三方，能共享宿主已有的内核 ；

共享A宿主内核后，若宿主升级到更高版本，三方能跟随升级；

已共享A主内核后，若B宿主升级到更高版本，三方能跟随B升级 ；

下发强制下载后，三方能走强制下载 ；

强制下载后，若宿主有更高版本，三方能跟随升级，等等。

怎么样？

有没有蒙圈，but这还只是一小部分%>_<%！

【人工测试】

合作方的接入时间是不定期的，一般来说。

步骤一：模拟三大宿主场景 。

（1）后台配置宿主内核版本 ；

（2）宿主下载、安装 ；

（3）确认宿主下载成功 。

步骤二：配置三方后台 。

第三步：结果检查 。

（1）读取三方内核版本号；

（2）判断是否符合预期。

【自动化的思考】

1、是否重要？

是。前面有介绍，一旦SDK逻辑出问题，会导致TBS使用异常，X5占比降低。

2、是不是重复工作？

用例可复用。因为对于同个版本的SDK，不同app的接入逻辑是一致的，可复用（有人会问那为什么每个app都要测一遍？因为人家的接入对我们是不可见的，只有个打包的apk给过来，到底SDK的调用对不对，有没有问题，是未知的）。

3、结果是否可判断？

是的。三方内核版本号保存在合作方目录下，可读取后跟预期结果对比。

【自动化过程分析】

我们对人工测试的各个步骤进行分析，统计上看，人工测试最大部分耗时集中在：

宿主环境模拟耗时占比：70%以上 。

宿主环境作为三方共享的前提条件，是非常重要的，一旦条件不符合预期，直接影响后面的测试结果。

方法一：模拟测试过程，后台配置—>宿主下载—>宿主安装—>共享检查。

实践结论：失败率高，不可行。

说明：出于用户的流量考虑，TBS宿主在逻辑上有后台流控，异常保护等诸多限制，反复测试情况下，经常出现无法下载、安装失败等问题，导致宿主环境异常，无法成功安装预设内核。

方法二：接口层触发宿主下载

实践结论：对他人影响较大，不适合。

说明：配置过程可行，但有个问题是接口配置后是UI不可见的，校验比较麻烦，还有一点，测试环境是三地共用的，不可见的配置有可能干扰其他同学的测试。

方法三：宿主环境MOCK化。

实践结论：可行 。

说明：首先将高中低三个待测内核下载到本地，并拷贝出来备份，在需要某个环境时push进宿主目录下，跳过“配置-下载-安装”环节，直接模拟安装成功后的宿主环境。

【三方配置方式】

解决了宿主的环境模拟问题，我们再来看看看三方如何配置环境。由于三方的后台环境是基于终端的定制需求，因此我们三方测试时，实际要关注两方面：

第一，后台下发是否正常。后台需要结合终端上报的情况，和预设的后台配置，下发预期的内核版本号给终端。

第二，终端根据后台返回的结果，是否能够共享或下载指定内核并调起使用。

考虑到以上因素，我们选用UI自动化的测试方式，优点在于兼顾后台和终端，并且通过记录tbslog方便隔离分析。

我们用的是chrome driver，在测试页面导入预设配置，并且对配置结果截图校验。

【自动化测试结果】

以下以“某某新闻”为例，我们来看看测试效果。实际中，可以利用夜间时间跑自动化，大大提高了测试效率。

【持续优化】

1、重跑机制：考虑到环境的不稳定性，我们对fail用例设置重跑逻辑，即fail后自动重跑2次，以此规避异常环境干扰；

2、实时报告机制：这是听了组内google分享的心得，不用等所有用例跑完再邮件同步结果，一旦出现fail立即报告，这在调试阶段非常有效，可快速发现脚本适配等问题；

3、监控弹框：对常见文字用Watcher批量监控，比如“是否更新”、“是否反馈”，排除APP自身弹框干扰。

【时间投入分析】

1、不同app进webview的场景不同，要花时间做适配；

2、某些app可能出现弹框提醒等提示，影响脚本运行，要做定向处理（由于弹框文字不确定，目前只能对常用的做处理，无法全面规避）；

3、日常维护和问题解决跟进。

另外：某些插件化和内置等特殊形式的SDK测试不适用。

【思考和总结】

1、做前思考：自动化是手段，不是目的，做之前多想想是否适合做自动化，投入产出如何，想清楚了再动手做；

2、过程PK：当一种方式难以实现时，集思广益，尝试其他的方法，综合考虑寻求最优方案；

3、持续优化：先跑起来，在过程中发现问题、解决问题 ；

4、数据积累：自动化的前期投入往往比较高，注意在应用中收集数据，发挥最大价值。

最后，附上TBS的SDK官网 http://tbs.sparta.html5.qq.com/tbs/sdk.html。

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