作者：张佳

团队：腾讯移动品质中心 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，获取更多测试干货！