转载请注明出处❤️

作者：测试蔡坨坨

原文链接：caituotuo.top/7bc8d1c8.html

你好，我是测试蔡坨坨。

众所周知，在云产品和SaaS蓬勃发展的当下，企业中有许多系统和环节都是依赖于第三方提供的服务或应用，而不必自己去搭建和实现，从而节省人力和物力，避免重复造轮子。

第三方应用可以通过厂商提供的API或SDK等形式集成。

对于测试同学来说，API测试，也就是所谓的接口测试，应该是再熟悉不过了，但对于SDK的了解以及测试可能就没有API那么熟悉了。

所以，今天我们就来聊一聊什么是SDK，以及SDK如何测试。

什么是SDK

SDK的全称是Software Development Kit（软件开发工具包），通常包括SDK接口、开发文档和Demo示例等。

API的全称是Application Program Interface（应用程序接口），就是软件系统不同组成部分衔接的约定。

API和SDK的区别

常见的API形式有http协议请求接口、websocket协议请求接口等，而SDK可能是xxx.jar、xxx.war、xxx.py、xxx.framework、xxx.a、xxx.aar、xxx.so等。

通俗地说，API可以比作房门钥匙，在一个房子里，每个房间有不同的用途和资源，想要获取相应房间的资源，我们需要先用钥匙打开房间门，比如去书房拿书、去卧室拿枕头，都需要先找到相应的房间钥匙，而拿书和拿枕头的过程，就是调用API的过程，也就是钥匙开门的过程。

SDK相当于一个大的工具包，把这些钥匙都串在一块儿，将API集合到一起，拥有SDK，便可以在该房子里畅通无阻，想要哪个房间的资源，就调用相应的方法。

两者的区别就是，API是一个确定的功能，明确了它的作用，而SDK是很多方法的集合体，只要引入SDK工具包，无论想实现什么，SDK里总有能实现的方法。

简单来说，SDK=放着你想要的软件功能的工具包，API=SDK上唯一的接口。

API举栗：

http接口文档：

1
2
3
4
5
6
7

名称: 全国高校信息查询接口
描述: 用于查询全国高校信息
Host: www.iamwawa.cn
Request URL: /home/daxue/ajax
Request Method: POST
Content-Type: application/x-www-form-urlencoded
headers: user-agent:Chrome

调用：

调用http接口的方式有很多，比如postman、apifox、jmeter、python requests、java httpclient等。

SDK举栗：

腾讯云短信xxx.py包：

调用：

通过编写代码调用SDK工具包。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# -*- coding:utf-8 -*-
# 作者：测试蔡坨坨
# 时间：2020/12/3 16:46
# 功能：发送短信SDK

from django.conf import settings
from qcloudsms_py import SmsSingleSender
from qcloudsms_py.httpclient import HTTPError


def send_sms_single(phone_num, template_id, template_param_list):
    """
    单条发送短信
    :param phone_num: 手机号
    :param template_id: 腾讯云短信模板ID
    :param template_param_list: 短信模板所需参数列表，例如:【验证码：{1}，描述：{2}】，则传递参数 [888,666]按顺序去格式化模板
    :return:
    """
    appid = settings.TENCENT_SMS_APP_ID  # 自己应用ID
    appkey = settings.TENCENT_SMS_APP_KEY  # 自己应用Key
    sms_sign = settings.TENCENT_SMS_SIGN  # 自己腾讯云创建签名时填写的签名内容

    sender = SmsSingleSender(appid, appkey)
    try:
        response = sender.send_with_param(86, phone_num, template_id, template_param_list, sign=sms_sign)
    except HTTPError as e:
        response = {'result': 1000, 'errmsg': "网络异常发送失败"}
    return response

SDK层级结构及测试

如果把SDK想象成一个洋葱，你认为它是一个什么样的层级结构？

• 代码层

  最里面的一层就是代码层，代码层是SDK的基石，决定了后面的走向。

  那么基于代码层，我们可以去做哪些测试呢？

  • 首先是单元测试，这个主要是针对开发同学需要关注的场景，需要对一些具体的业务逻辑进行单元测试，这部分可能测试同学会使用的比较少，单元测试一般会用到Junit单元测试框架、Mockito Mock框架、Jacoco代码覆盖率统计工具等，对于编程语言的了解程度还是有比较高的要求，如果测试同学对于语言比较了解的话，也可以考虑自己写单元测试。

  • 其次，基于代码的话，我们还可以写一些接口测试，接口测试的语言能力要求相对于单元测试来说会稍微低一点。业务代码最终使用的是SDK提供的接口，内部实现的黑盒就可以让开发去保证质量，从测试的角度，我们只需要测试它的公开接口，保证这些公开接口没问题，而且这种也是性价比比较高的方式。

    针对于代码层级的接口测试，通常我们会选用原生的语言去实现，比如这个SDK是用Java写的，那么我们就用Java去写用例，这一点与下面要说的二进制产物层级的接口测试会有一些区别。

  • 除了单元测试和接口测试以外，还有一些可以做的代码层测试，比如静态代码扫描，现在还是有挺多静态代码扫描工具的，例如：SonarQube、Scanmycode、Checkstyle、FindBugs、PMD、Jtest Pyflakes、Pylint、pep8、FxCop、StyleCop等，其原理就是在写完代码以后，不需要编译或者构建，直接用扫描工具对代码进行扫描，找出来里面存在的语义缺陷或者安全漏洞，这种扫描一般扫的是代码的问题。

  • 另外我们还可以用一些脚本去检测代码中的敏感信息，比如：硬编码域名信息、使用了一些不可商用的开源库的License、海外版本的App中有中文（有可能影响上线海外App应用商店），像这些都有安全审计的风险，都可以用代码扫描的方式进行检测。

    并且这些扫描可以做成增加扫描的形式，就不用每次都全量扫描，从而加快执行速度。

• 二进制产物

  代码层再向外一层就是二进制产物层。

  基于二进制产物，可能是xxx.jar、xxx.war、xxx.py等工具包，对于这样的二进制产物，我们可以测试什么呢？

  • 因为从代码到二进制产物，其实已经完成了构建的过程，也就是说它可以直接被运行和调用。因此我们可以做一些接口测试，与代码层的接口测试有点不一样的是，代码层的接口测试一般推荐使用原生语言进行测试，但是在二进制产物层的接口测试，我们还可以使用其他的语言，比如：要在Python中调用xxx.jar包，就可以借助Jpype来实现，从而在Python项目中也可以调用Java类和方法。
  • 如果在SDK中调用了一些高敏感的API，我们在这个层级也可以用一些工具进行扫描和拦截。
  • 包大小的检测，SDK包的大小会直接影响用户的下载和使用率，也是一个非常重要的指标，有数据表明，apk的包体积每上升6M，下载转化率就会降低1%，接近20%的用户都会因为存储空间有限而卸载应用。

• Demo

  再向外我们来到了Demo层。

  一般是进行功能测试和性能稳定性等专项测试。与其他需求测试一样，需要进行测试排期，分配人员和时间，走提测流程的。

• 集成应用

  最外层就是SDK测试完成后，还需要基于集成包进行的测试，SDK本身没有问题，不代表它接入到其他业务系统就没有问题，很多SDK的问题其实都是出现在业务的配合上，比如SDK的某一个功能设计者设计它的时候希望它是一个调用频率很低频的操作，但业务在实际调用的时候做成了比较高频的调用，那这种情况就会产生一些性能问题，像这种可能就是在集成的阶段才会发现。

  除此之外，还有对鉴权的测试，SDK通常会有一套鉴权和调用系统，在结合业务的时候，业务系统也会有一套鉴权机制，那么两者之间建立的对应关系有没有问题。

  再有就是UI规则，比如说业务系统本身有一套UI规则，与SDK不一致，还有就是SDK与业务系统之间的信息传递，这些都是比较常见的问题。

  集成应用的测试一般会跟着版本走，SDK测试得差不多了，才会进行集成应用的测试，太早的话可能SDK都还没测完，太晚的话出现问题可能来不及改，根据业务发版周期选择合适的测试时间。

从SDK的层级体系来看，其实是一个从内到外、从白盒到黑盒过渡的一个测试体系。

Demo阶段的SDK如何测试

Demo阶段的SDK测试，简单来说就是对提供给其他开发者的工具包里面的内容进行测试。

而SDK通常包含SDK接口、开发文档和Demo示例等。

因此，测试的主要内容就有SDK接口文档、日志、Demo。

测试类型有功能测试、性能测试、兼容性测试、稳定性测试、网络相关测试、安全性测试等。

并且最终还可以实现SDK的自动化测试。

SDK接口文档测试

主要检查文档是否完整、正确、清晰，比如：接入指南是否包含了环境依赖说明、集成方法说明、调用方法说明，接口文档的方法、参数名称、参数类型、参数描述、是否必填、示例、返回值等。

日志测试

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

Demo测试

Demo是SDK提供方用来演示如何调用接口实现具体的功能，可以让其他开发者直观地感受SDK的接入效果，可以较明确的知道接入这个SDK做出来的产品效果如何，因此也是我们测试的重点，应该尽可能多的覆盖各种业务场景。

功能测试

保证SDK接口功能的正确性和完备性，客户端SDK接口测试跟服务端接口测试类似，包括场景覆盖和接口参数覆盖，主要测试各种参数组合下的返回值，数据是否缓存与存储，是否有回调，对于请求成功或失败都能按预期进行处理。

性能测试

保证SDK接口满足特定的性能需求，比如：资源占用、响应时间等。

兼容性测试

保证SDK兼容特定的设备平台，并与其他软件兼容。

稳定性测试

测试业务场景在一定压力下，持续运行一段时间，接口功能和设备资源占用有无异常。

网络相关测试

不同网络类型，不同网络环境下，SDK接口都能较好的处理，比如弱网测试。

安全性测试

对隐私数据的保护，访问权限的控制，用户服务的鉴权等。

自动化测试

与接口自动化测试类似，我们可以将Demo测试写成自动化脚本的形式，比如使用TetsNG框架并持续集成到Jenkins，方便快速回归。