客户端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接口进行测试

常见的测试类型有:

功能测试

保证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、基于代码的单元测试

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

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

行动吧,在路上总比一直观望的要好,未来的你肯定会感 谢现在拼搏的自己!如果想学习提升找不到资料,没人答疑解惑时,请及时加入扣群: 320231853,里面有各种软件测试+开发资料和技术可以一起交流学习哦。

最后感谢每一个认真阅读我文章的人,礼尚往来总是要有的,虽然不是什么很值钱的东西,如果你用得到的话可以直接拿走:

这些资料,对于【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴上万个测试工程师们走过最艰难的路程,希望也能帮助到你!

  • 11
    点赞
  • 10
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
对于restsdk服务器测试,我们通常会采取以下步骤: 1. 安装和配置restsdk服务器:首先,我们需要在服务器上安装并配置restsdk,确保其能够正常运行。这包括下载并安装所需的软件和依赖项,并设置服务器的环境变量等。 2. 编写测试用例:根据需求和服务器的接口规范,我们需要编写一系列的测试用例来验证服务器的功能和性能。这些测试用例应该涵盖各种情况,包括正常输入、异常输入、并发访问等。 3. 执行测试用例:通过使用自动化测试工具,如JUnit或Postman等,我们可以执行编写的测试用例。这些工具可以模拟客户发送请求到服务器,并检查响应是否符合预期。我们可以使用不同的测试数据和参数来覆盖服务器的各种情况。 4. 分析测试结果:一旦测试用例执行完成,我们需要对测试结果进行分析。我们应该检查每个测试用例的通过与否,并记录失败的用例。根据失败的原因,我们可以定位和修复服务器中的问题。 5. 优化和重复测试:根据测试结果和反馈,我们可以优化服务器的性能和功能。优化可能包括调整服务器的配置、优化网络传输等。然后,我们可以重复执行测试用例,确保服务器在改进后是否满足了预期的性能和功能要求。 通过以上步骤,我们可以全面地测试和评估restsdk服务器的功能和性能。这有助于发现和解决潜在的问题,并确保服务器能够正常运行和满足用户的需求。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值