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

目录：导读

SDK是什么

测什么？

功能怎么测

接下来为大家讲述一番我的真实案例

1、做了些什么

2、做的方法

3、做得好的：

4、做得不好的：

5、个人成长：

6、后续学习改进的建议

去年有在跟进一个SDK项目，主要负责iOS端的SDK测试，研发过程曲折，延期上线，测试工作量巨大。收获挺大的，在此跟大家做一些总结分享下，望你我所遇，皆有收获。

SDK是什么

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

测什么？

1. 客户端SDK测试的对象

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

因此测试的主要内容有：

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

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

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

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

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

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

常见的测试类型有：

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

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

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

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

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

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

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

安全性测试

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

功能怎么测

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

了解业务流程，结合API接口文档和开发指南，理顺接口的使用场景和调用关系；
了解SDK协议，理解协议中字段的意义以及服务器端的处理逻辑；
了解各接口或协议返回码，分析对应的场景；
了解开发实现细节，可以绘制成图，便于测试分析和分层验证。

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

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

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

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

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

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

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

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

3、基于代码的单元测试

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

其他测试类型的展开，跟应用层测试类似，就不再重复了。

接下来为大家讲述一番我的真实案例

整个项目的进程大致是：

① 技术背景宣讲->

②技术方案确定->

③开发编码（测试准备并行）->

④部分方案变更->

⑤测试开始测试->

⑥开发bugfix->

重复③④⑤⑥步骤n次（这次的n有点多）->

⑦提供framework包给业务方，配合测试、bugfix->

⑧上线。

在这里不吐槽项目过程的一些问题，仅分析测试在这里做了些什么、做的方法、做得好的、做得不好的、个人成长、后续学习改进的建议。

1、做了些什么

半路进入这个项目（项目已在进程③），负责iOS SDK的测试，快速找pm了解大致的技术方案，根据模块快速的划分测试分工（iOS全职算2个人，实际是3个人部分投入）；
根据sdk的特点，对单测框架选型，最终定了xctest；
根据技术方案制定tc，评审tc;
编写测试demo，画UI，调用sdk的方法，从功能和方法级别对sdk进行测试；
编写性能测试demo，对db性能进行测试；
配合业务测试一起排查问题、解决问题，上线。

2、做的方法

测试框架选型：

详细查看了xctest的说明，结合之前了解的GHUnit、ocMock，再根据项目的特点，纯数据的处理、DB文件的读、写，所以选择了轻量式的跟xcode结合紧密的xctest，基本满足项目的测试需要。

sdk测试方法：

在开发已搭建iOS Application demo的基础下，就直接在demo里编写代码调用framework里的方法，将方法的实际返回显示到界面上。

在测试顺序上，基本从底部->上层->模拟业务方调用的顺序进行测试，首先测试db的功能（C层），满足正常功能（读、写、多线程读写等），再测试oc层dataBase(oc上对C层的方法进行封装，方便上层调用)，再测试OC manager层（有部分业务含义，主要是各种业务表的增、删、改、查方法），最后测试对外暴露的公共接口（读、写）的各种逻辑。利用分层测试的策略，sdk的各个剖面基本都覆盖到了。最后通过模拟业务方调用sdk公共接口，简单的校验了sdk的初始化逻辑和读写逻辑。

3、做得好的：

测试用例对功能级别和方法级别的覆盖率较高，codeReview几乎达到了100%，从方法层面和功能层面保障了sdk的质量，达到之前的预期。

提bug时尽量debug出问题的原因，提供可能的解决方案，帮助提升开发解决bug的效率。

4、做得不好的：

1、花在方法级别的单测时间过长，提供给业务方的时间延后，有些问题在业务接入后才暴露

2、整体面上和细节的考虑不平衡，sdk测试不仅是要保障各个方法、接口正确，还要保障业务复杂场景下的数据正确

3、忙于sdk的测试，未从业务测试角度出发，提供相应的环境切换工具、快速查日志、快速定位问题方法

5、个人成长：

在项目中实战了sdk的测试，sdk要测到什么粒度，各个模块如何平衡，测试主要编写sdk暴露的公共接口的测试，辅助开发进行私有方法和内部方法的单测。
业务测试代码review时更多的是各种UI的绘制，数据model的构造、解析，sdk代码review时看到的实现更底层，比如多线程的调度，提升了代码的深度理解

6、后续学习改进的建议

遵守单测的规范，利用xctest框架，将单测的脚本移植到sdk的工程，引入XcodeCoverage(目前已引入)统计单测覆盖率，并作为开发提测交付物之一，最好是加入到持续集成（目前已引入）
提供帮助业务测试快速查日志、定位问题的方法或工具
后续测试sdk时，不仅要从方法级别、功能级别保障质量，要更多的思考业务场景，尽可能的模拟业务的使用场景，构造复杂的条件（比如多线程、弱网、网络切换）
在技术方案评审阶段，多多思考，否掉不合理的方案，减少开发推倒重新编码的情况，相应的减少测试重复测试。

希望下次在做sdk项目测试时，能汲取此次的经验和教训，更进一步的提升技术能力。