春节快乐，干货来袭。具备强大功能的第三方SDK，广泛的应用在APP的设计开发阶段，成为整个软件供应链中不可或缺的一部分。但这也同时意味着，一旦处于供应链上游环节的SDK失守，不仅给大量应用带来安全隐患，更会影响无数用户的网络安全。QAPM进入金融行业以来，一直顺应形势加强应用安全防护，不断提高风险控制，与客户共享行业红利。前言
后台都还好，SDK跟着这些金融类产品发布。我们总开玩笑说，一旦出问题，都是“坐牢”的事情，瑟瑟发抖呀。当然，也许“坐牢”不必，但是前一阵某金融行业内部的产品，就在银监会通报批评了，这种情况可以让你的产品自此在金融行业人间蒸发。那么在这里，SDK的质量如何确保呢？
我们的实践
为了确保SDK的质量保证，我们建立了从测试到发布的流水线，最大程度的确保了SDK的质量。下面，我们就来看看具体的流程吧。
SDK自动化测试流水线
1）SDK风险控制
痛点：SDK不简单的，也很复杂，手工测试极为困难，而且难免疏漏，极有可能造成无法挽回的危机。因此，如何打通流水线和WeTest兼容性测试，降低SDK的风险，对SDK进行风险控制，成了我们急需解决的问题。
解决方案：首先是建立SDK发布流水线，在这里，我们将流水线分为测试流水线和正式发包流水线。
整个发布流程我们大体可以总结为以下四步：
1、codedog扫描-增加质量红线，致命和错误问题数小于0，圈复杂度不超过现有标准，否则不通过；
2、编译测试；
3、金刚扫描（0漏洞标准）- 增加人工审核，如发现有漏洞，停止发布；
4、正式发布 - 发布成功后，回写TAG，同步后台最新版本。
其次，在WeTest兼容性测试过程中，我们主要分为以下两个步骤进行：
1）由流水线定时触发构建及wetest测试（中午晚上各一次）
2）查看测试产品的数据是否符合预期（各数据是否正常展示）
综合以上步骤，我们就打通了流水线和WeTest兼容性测试，从而有效地对SDK进行了风险控制。
2）真机测试
痛点：相对于Demo App，真实App场景复杂，难以获取全面且真实的数据反馈，针对iOS和Android端，我们拥有不同的真机测试方式，从而最大程度的确保测试结果的准确性。
解决方案：
iOS：在测试真机数量较少的情况下，借助于腾讯视频App的数据进行测试，通过腾讯视频的NewMonkey流水线打包ipa文件，然后将ipa文件安装到本地的测试机，全功能上报到QAPM，如果没有发现关于QAPM的SDK上报，则表明SDK正常，从而获取真实且全面的测试结果。
Android：Demo App由于数据都是我们制造的，测试时问题都能发现，与真实App的差别在于真实App的场景较为复杂，无法准确获知问题的发生是否与环境有关，比如说手机环境其他应用的cpu占用比较高，导致其自身cpu的时间片获取不到，运行会比较卡顿，这些东西是无法预估的。针对此类问题，我们使用LeapPic进行测试，LeapPic功能丰富，具有我们埋的一些测试点，事件随机发生，理论上能实现全场景覆盖，并且在跑WeTest测试的时候，我们中午以及晚上各进行一次测试，确保真机测试的客观性与准确性。
Android SDK： https://git.code.oa.com/tencent_cloud_mobile_tools/sop_doc/tree/master/私有云/SDK/Android SDK
iOS SDK：
https://git.code.oa.com/tencent_cloud_mobile_tools/sop_doc/tree/master/私有云/SDK/iOS SDK
3) 性能测试
痛点：单台设备的性能无法衡量，不能客观且准确的得出性能测试结果。
解决方案：使用多台设备进行性能测试，获取准确且客观的性能数据。同时，在没有自动化测试的情况下，我们会进行手动测试。为了测出该功能的性能消耗，我们一般会准备不包含该功能的app和包含该功能的app，通过两者之间的性能差值来确定性能消耗，为确保手动测试的性能数据报告的可信程度，会分为两种情况：
1、多设备下的monkey测试
使用apm自身的资源监控能力，这种测试手段由于monkey的场景不确定性，仅用作于参考。
2、单设备的同场景测试
通过WeTest的本地自动化工具和perfdog工具，我们可以针对这两个app的同一个场景进行同样的自动化操作，来查看app的fps、cpu以及内存消耗。
写在最后
新的一年，QAPM将持续为各行业提供更丰富的产品、服务和价值，助力客户实现商业价值。
