方法二：接口层触发宿主下载
实践结论：对他人影响较大，不适合。
说明：配置过程可行，但有个问题是接口配置后是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。