接口定义：
接口泛指实体把自己提供给外界的一种抽象化物（可以为另一实体），用以由内部操作分离和外部沟通交互的方式。接口通俗可称为连通和对接，人和人的沟通，人和设备的沟通，设备和设备的沟通。接口通常分为两种，硬件接口和软件接口。电脑等信息机器硬件组件间的接口叫硬件接口。电脑等信息机器软件组件间的接口叫软件接口，我们所涉及的既是软件接口。
接口测试概述：
接口测试（interface testing）的目的是测试对外提供的服务是否可用，测试的重点是检查数据的交互，管理和同步过程，提高测试质量和测试覆盖，更准确的重现软件缺陷和定位问题。由于平台服务器是通过接口来与客户端交互数据提供各种服务，因此服务器测试工作首先需要进行的是接口测试工作。测试人员需要通过服务器接口功能测试来确保接口功能实现正确，那么其他测试人员进行客户端与服务器结合的系统测试过程中，就能够排除由于服务器接口缺陷所导致的客户端问题，便于开发人员定位问题。
接口测试的方向分为模块接口和系统接口。系统接口测试的对象是基础建设交换机、路由器和服务器之间的对接接口，目前我们还未涉及到。我们目前主要做的是模块接口测试，业务接口功能。即API（Application Programming Interface,应用程序编程接口）是一些预先定义的函数，目的是提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源码，或理解内部工作机制的细节。
接口测试的原理是通过测试程序模拟客户端向服务器发送请求，服务器接收到请求后对相应的请求做出处理，计算得出结果后，再把结果发送给客户端，客户端可以接收到返回数据这一个过程。
接口测试范围：
根据服务器的测试需求，接口测试范围主要分为：
1、新增接口的测试；
2、新增业务功能接口测试；
3、整个服务器的接口测试。所需测试的接口依次增多，在测试时间足够的条件下，当然需要对所有接口进行测试用例的遍历，但如果测试较短的情况下，则应该首先根据用户的典型操作对测试接口进行优先级划分，对调用频繁接口需要优先进行测试。
接口测试的内容：
接口测试主要包括两项内容:
1. 接口功能测试
1) 调用对应接口，可以正确访问，能够达到该接口所定义的功能。
2) 请求方式对应测试。
3) 参考接口定义文档，检查接口返回参数，必要参数返回正确：返回值，状态值；数据对象；返回对象参数，字段；数据同步，数据与实际或是设置相符。
4) 输出结果json格式是否正确
2. 接口逻辑测试
接口需求文档为主参考
1) 根据接口定义文档，检查接口参数对应关系，关联关系，比如hasmore=1那么relatedValue须有值。
2) 接口请求逻辑测试，根据业务逻辑、输入参数、输出值的描述，请求对应数据，对正常输入情况下所得的输出值是否正确的测试，也就是测试对外提供的接口服务是否正常工作。例如请求更多主播列表sorttype ；排序方式分类（人气、最新）；type 对应sorttype为非排序方式时的类型（电台、分类）；id对应type为分类时的分类id。
3) 对不符合逻辑的输入是否有相应提示。
4) 接口下发逻辑，根据请求，下发对应数据，例如请求更多主播列表，优先判断参数。详见附录2
3. 模块接口交互测试
见附录1接口依赖关系检查
1) 不同接口之间的关联关系，请求另一个接口，与本次请求接口返回参数的关联。
2) 各个模块连接集成起来的时候，穿越模块接口的数据会不会丢失。
3) 各个子功能组合起来，能否达到预期要求。
4) 一个模块的功能是否对另外一个模块的功能产生不利的影响。
5) 全局数据结构是否有问题。
4.接口异常测试
模块接口测试是为了保证数据的安全及程序在异常情况下的逻辑的正确性而进行的测试。测试接口在参数合法及非法、异常情况下能否达到预期效果
接口异常测试的主要包括以下四个方面：
1） 空值、（Null）输入，空字段和空参数，检查模块接口对空值（Null）的反应能力。
2） 特殊字符，如：<、>、&、=、%、空格等。重点是&、=、空格，这些字符在post、get请求中是关键字，如果没有进行转义，就会报错
3） 字符串长度超长，会有何结果。
4） 异常的测试，制造一些异常的测试场景，例如：不登陆、id不存在、漏传参数等，测试异常描述是否清晰。
5） 参数的个数设计与模块接口参数的个数不一致时，检查模块接口的反应能力。包括以下两种情况：
l 模块接口参数的个数不一致（或多于原设计的参数个数，或少于原设计的参数个数）；
l 模块接口参数的类型不一致（字符型和数值型混用）。
5.接口压力测试
1) 对于一些接口，需要进行多线程（收、发）测试。
2) 压力及性能测试。
附录1：接口依赖关系检查
以上策略只谈到单个接口的测试方法，对于用户来说，一个操作可能会造成服务器调用多个接口来进行完成，因此还需要从业务处理的角度，对各种业务操作所涉及的多个接口之间依赖调用进行测试。
接口依赖关系检查主要是通过接口的输出值为另一接口的输入值来实现的，因此在进行接口测试之前，需要分析所测试接口的输入值是通过客户端还是其他接口输出来获取的，在设计测试用例时，加入接口的依赖关系说明以便于测试。
附录2：接口输入/输出验证
服务器接口功能测试类似于单元测试，在设计测试用例时，侧重点在于接口模块输入/输出项的正确性验证，根据接服务器接口处理方式，对各种接口进行分类：
第一类：条件判断接口
这类接口在接收到请求数据后，会根据输入参数进行条件判断，然后返回相应结果码，通常涉及条件判断的接口有：用户鉴权接口、升级状态上报、密码修改/重置等接口。因此输入/输出项验证的侧重点主要集中在：
1）判断条件的验证
要对判断条件进行验证，则需要知道接口是根据哪些输入项来进行判断的，以密码重置接口为例：
找回密码接口
『接口功能』：用户登录之后发起找回密码操作，用户输入手机号、验证码和新密码后，向平台服务器发送请求，服务器新密码设置为用户当前密码，供用户以后登录使用。
『接口方向』：客户端—>服务器
『遵循协议』：HTTPS，请求消息使用Post方式
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
type |
|
|
用户类型 |
|
Uid |
|
|
用户ID |
|
username |
|
|
手机号 |
|
password |
|
|
新密码 |
响应消息（sendMessageRes）
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
code |
|
5 |
结果返回码，返回10000表示处理成功 |
|
status |
|
|
1，设置成功；0设置不成功 |
此接口根据输入的type、username以及公共参数，来进行数据正确性的判断（是否为已注册的用户，是否为正确的用户，是否为各项信息匹配的用户），设计接口测试用例时，应该首先对接口的判断参数进行验证，这些输入项不能为空，然后利用等价类划分、边界值方法来根据type、username输入项设计各种合法的数据，验证接口是否可以正常处理。
2）异常数据的响应
只考虑正常情况，而不考虑异常场景是无法保证接口功能运行正常，对于密码重置接口，用户ID不存在、不合法，手机号、邮箱输入格式错误、用户邮箱信息不存在或未激活就是测试时需要考虑的异常场景，设计这类输入值，并且检查接口返回的响应码，响应码的正确才能保证客户端根据异常情况来显示相应的提示信息。简而言之，条件判断的接口其测试策略就是根据判断条件来设计各种输入值来检验接口的功能。
第二类：数据查询接口
这类接口接收到请求数据后，首先会验证请求是否合法，然后会根据请求项查询数据库相应表中数据返回给客户端，通常涉及数据查询的接口有：用户基本资料、关注粉丝列表、积分、专辑资料等接口。以用户资料查询接口为例：
用户资料查询接口
『接口功能』：用户客户端登录后，可以查询自己资料信息，包括头像、昵称、性别、地区、介绍等。
『接口方向』：客户端—>服务器
『遵循协议』：HTTP+XML，请求消息使用GET方式
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
uid |
|
|
用户ID号 |
响应消息（sendMessageRes）
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
Resultcode |
|
|
状态码 |
|
uid |
|
|
用户ID |
|
avatar |
|
|
头像 |
|
status |
|
|
状态是否冻结 |
|
nickName |
|
|
昵称 |
|
|
|
|
邮箱 |
|
gender |
|
|
性别 |
|
birthday |
|
|
生日 |
|
address |
|
|
地址 |
|
intro |
|
|
介绍 |
|
isAnchor |
|
|
是否是主播 |
|
score |
|
|
积分 |
|
fansNum |
|
|
粉丝数 |
|
followedNum |
|
|
关注数 |
|
…… |
|
|
此接口首先会根据接口定义断请求是否合法，然后根据请求参数中的uid来查询数据库表中相应数据。除了象条件判断接口一样根据判断项请求参数uid设计合法/不合法和正常/异常测试值之外，还需要结合数据库来对查询结果进行验证:
1）是否根据正确的关联数据表进行查询，信息是否都匹配；
2）验证查询结果是否从数据表中正确项中获取，涉及到多表联合查询时，不同表中的相同项设计不同测试数据进行验证；
3）修改查询结果在数据库中对应项中的数据，使其为空值或客户端相应项的范围值的最大和最小值，查看接口输出以及客户端展示是否正确。
第三类：逻辑运算接口
这类接口在收到请求数据之后，会进行一系列逻辑运算，然后根据处理结果更新数据库中的数据，通常涉及逻辑运算的接口有：热门主播、人气主播、各种数据报表等接口。以最新入驻接口为例：
更多主播列表接口
『接口功能』：根据客户端请求类型，分人气、最新、分类等排序的请求，服务器根据字段查询主播数据库，按规则排序返回给客户端数据。
『接口方向』：客户端—>服务器
『遵循协议』：HTTPS+XML，请求消息使用GET方式
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
id |
|
|
分类id（ 否(当type为2时必传 其他可不传)） |
|
type |
|
|
主播类型（否1 电台主播 2 类型主播(情感/娱乐/新闻等)） |
|
sorttype |
|
|
排序方式（否 1 人气主播 2 最新入驻） |
|
pagenum |
|
|
当前页 |
|
pagesize |
|
|
每页条数 |
响应消息（sendMessageRes）
|
参数名称 |
参数类型 |
参数长度 |
说明 |
|
resultCode |
|
|
结果返回码，返回10000表示处理成功 |
|
haveNext |
|
|
是否有下页 |
|
nextPage |
|
|
下页页数 |
|
havePre |
|
|
是否有上页 |
|
prePage |
|
|
上页页数 |
|
currentPage |
|
|
当前页 |
|
count |
|
|
总个数 |
|
sumPage |
I |
|
总页数 |
|
pageSize |
|
|
每页个数 |
|
dataList |
|
|
主播对象 |
此接口比数据查询接口又更加复杂，除了用条件判断和数据查询类接口的策略对此接口进行测试用例设计之外，还需要验证对接口的算法规则进行检查，因为此接口涉及通过对相关数据表中的数据进行查看方式，再根据主播信息计算排序然后将数据下发，接口算法规则验证包括：
1）人气主播判断是否使用了sorttype参数，其他参数是否影响，计算规则是否正确为粉丝数倒序；
2）最新入驻判断是否使用了sorttype参数，计算规则是否正确为按主播注册数据倒序；
3）类型主播查询，是否是按正确类型分类；
4）类型主播排序计算，是否正确为粉丝数倒序。
逻辑运算接口由于还涉及插入或更新数据库操作，因此测试时还需要考虑数据库特性，如数据精度问题，在MySQL数据库中，如果是浮点型数据，存入时会有精度误差（131072.32插入float(10,2)类型的数据会变为131072.31），因此对于需要用于金额计算、数据统计、成绩比较的数据，最好使用定点型。
接口测试方法分享到此，如有更新及时补充，剩下及时用工具来执行测试了。