自打我接触测试以来，就独得各类SDK恩宠，那么SDK是什么呢？由以下SDK逻辑构图可知，它是一种内嵌入各种APP或者Web应用，为第三方开发者提供软件服务的开发工具包，包括SDK接口、开发文档和Demo示例等。于是秉着和用户在一起的宗旨，保障SDK这些内容的质量便成为了QA的工作日常。
其中，Demo是SDK提供方用来示例如何调用接口实现具体功能的工具，可以帮助第三方开发者直观感受SDK的接入效果；QA在测试时也可以借助Demo，采用手工或UI自动化的方式快速有效的覆盖SDK的主流接口和业务场景，但这种方案更适合重UI界面的SDK。对于某些重接口内部逻辑甚至本身无UI界面的SDK而言，SDK接口作为测试的重中之重，仅仅 依赖Demo层面的覆盖是远远不够的，痛点主要集中表现在以下几个方面：
图1 | SDK逻辑架构图
1.Demo开发耗时：精心设计的Demo或许可以最大程度的满足测试所需，但相关功能开发耗时，问题暴露时间滞后；
2. SDK接入测试无法覆盖：直接采用开发提供的Demo进行测试，无法真正理解开发文档，模拟客户接入SDK的全流程；
3. SDK测试环境不纯粹：为方便测试新增的Demo相关配置代码，容易影响SDK本身的测试环境，发现问题定位复杂度增加；
4. SDK测试场景不足：Demo对接口和业务场景的覆盖有限，不能充分覆盖接口的输入输出参数校验以及内部各种异常分支；
5. SDK测试被动：SDK采用To-B形式提供服务，不能与C端客户直接进行交互，具体效果依赖第三方应用，测试比较被动；
6. SDK无法灰度：SDK不可对第三方应用产生侵入，无法通过线上灰度或者崩溃、内存泄漏等工具提前感知召回线上异常；
7. SDK注重质量：SDK质量要求要比第三方应用更高，是所有接入SDK各个B端客户质量要求的总和。
痛定思痛，当基于Demo的UI自动化不能很好的满足项目所需时，我们便自然而然地想到了测试金字塔中端的API测试。SDK是如何进行API自动化测试，又是如何实现持续集成的呢？
01 SDK API自动化
1.1 项目架构
SDK是一种内嵌入第三方应用的软件开发工具包，常见的种类有JSSDK、AndroidSDK、iOSSDK以及微信小程序、百度小程序、快应用等，其SDK API测试项目架构如图2所示：
图2 | SDK API测试项目架构图
在测试初期，我们可以根据官方开发文档借助Demo集成SDK，通过测试框架输出测试用例。当SDK初始化后，调用API接口上传数据到Server服务器，并存储在HBase中供后续数据获取进行断言比对，最终将测试结果输出。在整个自动化测试过程中，底层测试框架决定了上层用例建筑的好坏，面对市面上鱼龙混杂的各类测试工具，我们应该如何选择呢？
1.提供测试框架：适合行为驱动型（BDD）的测试风格，根据业务代码编写测试代码，组织测试用例；
2. 提供断言机制：用于判断测试用例输出结果是否符合预期；
3. 生成测试结果：用例执行结束后可以明确展示测试结果，包括用例执行失败原因；
4. 快速执行用例：支持一键快速执行全部或单个用例，方便测试执行；
5. 支持环境隔离：每一个测试用例运行或环境变量准备的过程，都是相互隔离的，不能相互依赖；
6. 拥有活跃社区：成熟的测试框架和活跃的社区，在后续使用中遇到困难时可以方便快捷的找到解决方案。
基于以上标准，我们便可以为不同的SDK选择适合自身项目的API自动化测试框架。比如AndroidSDK可以根据下图3判断是否依赖android库、是否需要mock、是否使用第三方框架等选择Junit、Mockio、Roboletric、AndroidJunitRunner等测试框架，JSSDK可以选择Jest、Jasmine、Mocha等，iOSSDK可以选择XCtest、Kiwi等测试框架分别实现各端SDK的API自动化测试。
图3 | AndroidSDK API自动化测试框架选型图
1.2 接入测试
接入测试是我们日常SDK测试中最容易忽略的环节，但它带来的问题却不容小觑，主要包括以下几个方面：
1.2.1 接入文档
好的官方接入文档，可以让第三方开发者在不求助技术支持人员的情况下顺利接入产品，提升产品用户体验的同时还能提高产品转化率。在接入测试中，我们要以黑盒测试的思维站在外部客户的角度，判断接入文档是否清晰有效，各个方法是否能达到预期结果，各个字段是否必填描述是否正确等；还要以白盒测试的思维站在内部开发人员的角度，分析各个方法字段是否存在冗余，同步异步回调是否正确，是否满足客户需求等；此外我们还可以提供一些常见的异常接入帮助文档，降低不同客户针对同一问题与技术支持人员之间的重复无效沟通，增强用户体验的同时提高技术支持人员的工作效率。
1.2.2 安全性问题
SDK接入方式的安全性问题也是我们要测试的内容之一，将SDK统一存放在外部公共平台由客户通过代码方式动态加载的方案，明显比SDK放在内部私有平台由技术支持分别向客户提供的方式安全性要差好多。在代码层面，我们要注意提供给外部客户的SDK是否经过混淆、加固，特别注意iOSSDK代码混淆级别是否会对第三方应用上架造成影响从而导致苹果拒审等。
在产品层面，我们要注意productNumber、businessId、secretId、secretKey、token、nonce等参数隔离问题，确保不同产品不被攻击重放信息不被泄露等。针对AppSDK我们还需额外关注新增权限问题，尽量采用最少的的权限获取最大的功效，避免因权限问题导致的第三方应用不兼容缺陷产生。
1.2.3 打包问题
不管是第三方应用还是SDK自身，在打包过程中都存在签名、版本、资源文件等问题需要进行前后交叉兼容测试。在确保SDK发布版本为release的前提下，我们要关注第三方应用分别采用debug、release模式进行签名集成SDK时是否存在冲突，SDK本身是否可以实现多渠道打包以及SDK是否支持中英文包名打包等。
作为技术人员，还应时刻保持信息的敏感度，关注各端系统最新动态，确保SDK与第三方应用之间的compileSdkVersion、buildToolsVersion、minSdkVersion、targetSdkVersion、iOS Deployment Target等版本兼容，避免因官方系统升级而导致的新系统新机型新API批量不兼容的崩溃问题产生。
1.3 接口测试
接口测试是SDK API自动化测试的核心，也是TestSuites的重要组成部分，好的测试用例集能够以最小的成本覆盖最多的业务场景，帮助项目尽早发现问题，缩短项目迭代周期，提高系统健壮性。通常情况下，我们可以采用以下多端通用、SDK专用两种方式进行接口测试用例的设计。
1.3.1 多端通用接口测试场景
图4 | 多端通用接口测试场景
上图中多端通用接口测试场景主要包括入参、出参两大部分，适用于任意接口类型，包括服务端http/https、客户端各端SDK及各类型接口等。入参测试从参数名称、参数数 量、参数取值三个角度出发，采用等价类划分、边界值分析、特殊值校验、所有值遍历等白盒测试思维将所有类型参数进行了划分，在测试时我们可以边review开发代码边理解产品需求，尽可能确保接口入参的精准性。
出参测试可以从请求正常、异常两种响应角度出发，确保各类响应码、响应信息描述在正确且方便问题定位的基础上，增加模糊度以此来降低黑产客户的攻击。此外，我们还需要关注异常捕获、超时重试等机制是否完善，从而提高请求正确率提升用户体验。
1.3.2 SDK专用接口测试场景
图5 | SDK专用接口测试场景
在SDK接口测试过程中，不仅要考虑通用接口测试场景，还要站在不同用户角度尽可能多的覆盖可能发生的各类场景。如图5所示，这类场景包括但不限于SDK上下文实例测试、 产品/业务状态测试、编译打包测试、初始化时机测试、初始化次数测试、本地缓存测试等。如果说1000个读者眼中有1000个哈姆雷特，那么无数个SDK使用者中就会有无数个不同 的使用方式，我们只有在实践中不断积累沉淀，做好各类异常管控措施，才能兜底客户各类异常，为其提供更好的服务。
02 SDK持续集成
SDK API自动化测试到此告一段落，但我们却不能止步于此，我们更加期待的是将SDK API自动化测试真正融入到项目的持续集成方案中去。当开发人员提交新代码走完单元测试后，立即触发Jenkins执行SDK API自动化测试任务进行冒烟回归，测试通过后再触发提测流程通知QA正式进入测试阶段。在测试阶段，QA通过修改编写SDK API测试用例，完成新一轮的功能测试，此外还可以通过SDK API自动化测试的线上配置实现SDK的线上实时监控。SDK持续集成方案如图6所示：
图6 | SDK API自动化测试持续集成方案
2.1 持续执行
SDK API持续集成方案依赖Jenkins进行，当开发人员提交变更代码到仓库生成新的SDK后，可以触发Jenkins自动构建任务执行已有SDK API自动化测试用例进行冒烟自测，确保新版本SDK的主流程功能正常。在任意测试阶段，我们还可以借助Jenkins通过参数化的方式选择Git构建分支、SDK版本池版本等，在自动clean、build之后将Demo安装在目标设备或浏览器，自动执行各类测试用例并将结果输出。此外通过Jenkins定时任务的设置，还可以轻松实现SDK API的线上实时监控测试，第一时间发现线上问题确保线上SDK的稳定运行。
2.2 测试报告
Jenkins任务执行完成后，通过构建日志可以轻松看到单次的测试结果，但每次都需要打开并登录Jenkins，这对定时任务及项目中其他成员而言并不友好。Jenkins团队早已想到这个问题，它丰富的内置插件Editable Email Notification和Allure搭档便可以完美的解决这一难题。通过Editable Email Notification可以在Jenkins任务执行结束后发送指定格式内容且带附件的邮件到指定邮箱，而Allure支持Java、Python、JavaScript、Ruby、Groovy、PHP、Net、SCala等多种语言可以将单次测试报告集成，并以图表形式直观的展现在用户面前。具体接入方式可参考百度，最终示例结果如图7、8所示：
03 总结
上述方法论已在易盾反作弊项目得以落地实施并取得了显著成效，我们通过Jasmine、AndroidJunitRunner、XCTest框架分别实现了反作弊JSSDK、AndroidSDK、iOSSDK的API自动化测试方案，输出近100条场景用例覆盖了反作弊项目的全部主要流程。在去Demo化的基础上实现了SDK打包流程、测试场景的自动化，不仅测试效率提升了99%，还相继发现了 13个crash类、需求类、缓存类等依赖Demo测试难以发掘的缺陷，具体如下图所示。
此外，通过Karma框架集成Jasmine实现了JSSDK在Chrome、Firefox、Safari、Edge、IE及H5等 多浏览器上的一键串行自动化，还通过Total Control实现了AndroidSDK批量连接、安装、执行、卸载等多设备的SDK API自动化运行。SDK API自动化测试相比UI自动化测试而言，更加有效、稳定、实用，是一项值得深入探索的实践。
图9 | AndroidSDK API自动化半年发现的缺陷列表
图10 | AndroidSDK API自动化半年发现的缺陷分布
图11 | SDK回归耗时比较
SDK API自动化测试与持续集成虽然到此告一段落，但未来还有无限可能，例如，如何在SDK自动化测试的基础上，实现客户端专项测试解决性能难题等。欢迎各位看官持续关注并共同探讨SDK测试体系。