客户端SDK测试是什么？如何测？

01、是什么

客户端SDK是为第三方开发者提供的软件开发工具包，包括SDK接口、开发文档和Demo示例等。SDK和应用之间是什么关系呢？以云信即时消息服务为例，如下图所示，应用客户端通过调用云信SDK接口，进行消息等数据查询存储等操作，或通过协议与云信服务器间进行通信。

02、测什么

1. 客户端SDK测试的对象

客户端SDK测试，就是对提供给开发者的工具包里面的内容进行测试

因此测试的主要内容有：

• SDK接口和文档
  SDK接口是测试的主要对象，也是核心的内容

• SDK日志
  对开发者来说，SDK接口里面的具体实现是透明的，当上层调用时遇到问题，只能依赖SDK打印的日志来定位分析。所以SDK日志是否完备，是否有助于解决问题，对应用开发者和SDK提供方来说都很重要

• Demo或行业解决方案
  Demo是SDK提供方用来示例如何调用接口实现具体的功能，也可以作为开发者直观感受SDK接入效果。行业解决方案类似Demo，但是，比Demo更加像一个产品，具有比较完整和典型的行业应用场景。可以让行业开发者比较明确知道，接入这个SDK做出来的产品效果如何

• 其他周边
  比如UIkit等，可能只是在SDK开发中的附带输出，但对有的开发者来说能极大降低接入成本

2. 客户端SDK接口测试类型

客户端SDK根据需求和开发平台不同，可能需要选择不同的测试类型对SDK接口进行测试

现在我也找了很多测试的朋友，做了一个分享技术的交流群，共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源，没人解答问题，坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化，性能，安全，测试开发等等方面有一定建树的技术大牛
分享他们的经验，还会分享很多直播讲座和技术沙龙
可以免费学习！划重点！开源的！！！
qq群号：691998057【暗号：csdn999】

常见的测试类型有：

• 功能测试
  保证SDK接口功能正确性和完备性。客户端SDK接口测试跟服务端接口测试类似，包括场景覆盖和接口参数覆盖

  主要测试各种参数组合下的返回值，考虑数据是否缓存与存储，是否有回调，对于请求成功或失败都能按预期进行处理

• 性能测试
  保证SDK接口满足特定的性能需求，比如资源占用、移动设备耗电量等。在云信IM登录的场景，登录时可能收到大量同步数据包和离线消息包，那么对这些数据包的解析以及本地储存的性能就要进行保证，否则可能出现登录响应很慢甚至卡住的问题，所以测试时就需要考虑这个场景的性能

• 兼容性测试
  保证SDK兼容特定的设备平台，并与其他软件兼容。兼容设备平台的工作量通常是比较大的，先根据产品需求和市场现状对需要适配的设备平台做分析，再根据需要覆盖的机型、系统版本、分辨率等进行优先覆盖排序

  移动端SDK兼容性测试需要考虑下对模拟器的支持，因为很多开发者可能就是先在模拟器上开发。客户端SDK覆盖多平台设备的，还要考虑多端消息数据包的互通

• 稳定性测试
  考察业务场景在一定压力下，持续运行一段时间，接口功能和设备资源占用有无异常。比如云信实时音视频通话场景中，要保证多人长时间通话且不断有人进出时的接口功能和设备资源占用无异常

• 网络相关测试
  保证在不同网络类型，不同网络环境下，SDK接口都能较好的处理。在涉及到多媒体资源或音视频通信，弱网下测试的需求较多，并且弱网下的处理通常需要反复优化和对比，不仅是新老版本效果对比，还包括竞品的效果对比测试

• 安全性测试

  对隐私数据保护，访问权限的控制，用户服务鉴权等，SDK接口的安全性问题也是比较突出。安全性很多是在架构设计和开发设计中就考虑进去，但是最好还是有专门的安全性测试

03、功能怎么测

上述诸多测试类型中，功能测试先行。在进行客户端SDK测试前，需要全面的了解测试对象的细节：

• 了解业务流程，结合API接口文档和开发指南，理顺接口的使用场景和调用关系；

• 了解SDK协议，理解协议中字段的意义以及服务器端的处理逻辑；

• 了解各接口或协议返回码，分析对应的场景；

• 了解开发实现细节，可以绘制成图，便于测试分析和分层验证。

对客户端SDK进行测试，可以采用的分层测试方式由上至下依次有：基于Demo和解决方案->基于接口调用->基于代码。

1、基于Demo和解决方案的测试

大多客户端SDK在提测时，都会有对应的Demo或者解决方案提交给测试，因此可以覆盖到该Demo或解决方案对应的接口或业务场景。而且测试人员可以比较直观的看到界面表现，上手快，所以在客户端SDK测试中比较常用，也是比较有效的。

但这种测试方式的缺点也很多，Demo对接口和业务场景覆盖比较有限，对接口的输入输出参数不能全覆盖，发现问题时定位复杂度增加。精心设计的Demo以及多解决方案的形式或许可以最大程度满足测试需要，但是需要较大的Demo开发测试投入，也使得问题暴露的时间大大滞后。基于Demo和解决方案的测试，可以是手工的也可以是UI层自动化测试。

2、基于接口调用的自动化测试

基于接口调用的测试，包括对单个接口的测试，也包括业务场景的覆盖。这种测试方式直接有效，需要一定开发基础

目前，我所在项目组的同事也有一些实践，以云信iOS SDK测试为例，最小回归测试对应接口也已经自动化，测试工程基本结构如下：

基于接口调用的自动化测试，需要有产品的思路、开发的知识和测试的思维，做起来有难度。但是因为SDK接口通常比较稳定，所以一旦实现并投入使用，测试效率和质量的收益都很大，值得拥有。

3、基于代码的单元测试

单元测试是为开发代码质量保驾护航的一个重要环节，在测试左移推进的道路上，大家越来越意识到单元测试的重要价值。特别是在一些核心业务上，值得开发同学投入精力去做。

其他测试类型的展开，跟应用层测试类似，杭研QA白皮书介绍的方法、工具基本能满足测试需求，就不再重复了。

END今天的分享就到此结束了~！点赞关注不迷路！