一、为什么要做接口测试
对于为什么要做接口测试，我们举一个工作中的例子来看这个问题。
现在有这么一个需求：
一、需求背景
由于业务需求，需要对服务端下发给客户端的数据，针对客户端的版本号进行控制。
二、具体需求
客户后台配置数据的列表增加“数据可见显示的最低版本号”入口。配置之后，客户端的版本号需要大于此条数据配置的版本号，才能展示。
如果是通过客户端测试这个功能：
我们需要准备 一个大于限制版本的客户端，一个等于限制版本的客户端，一个小于限制版本的客户端。
这里已经需要准备三个客户端版本。如果还要测试异常情况，比如版本号为空，这种客户端准备起来则更加复杂。
如果是直接通过接口请求测试这个功能：
那我们只需要改变几次参数就可以达到客户端测试的效果。
而且所用的时间则快了好几倍，并且测试异常的情况也容易许多。
所以对于“为什么要做接口测试”这个问题，有下面几种原因：
1.部分客户端的功能是在接口已经完成的基础上开发，越底层发现bug，bug的修复成本是越低。
2.大部分的系统前后端架构是分离，客户端进测时间与服务端进测时间不一样。
3.通过客户端测试接口，不能满足异常情况的测试需求。例如需要在请求参数中传递一个空值进行验证，但客户端可能已经在前端做了对空值的限制，所以这种情况只能通过直接发送接口请求进行测试。
二、接口功能测试原理
接口测试原理：
接口测试的主要的目的，是为了测试服务器能够返回符合预期的结果。所以接口测试的原理是模拟客户端向服务器发送请求，服务器接收请求并处理后向客户端返回响应内容，客户端接收响应的过程。
三、接口测试方法
接口测试流程：
1.根据接口文档、需求文档确认待测接口测试点
2.根据测点制定测试用例
3.根据接口文档在postman中添加接口
4.开始测试线接口测试
5.测试线bug提交、跟踪、关闭
6.测试线测试完毕之后，接口上线
7.线上验证完毕，测试完成
在这些流程之中，测试点的提炼和测试用例的编写是最核心的技能，也是难点。
（1）、测试点的提炼要从几个方面判断：
根据接口的业务逻辑：
1.接口功能是否符合需求文档。（常用方法：边界值、等价类）
2.返回的response的数据格式、参数名、参数类型是否与接口需求文档定义一致。
3.接口数据的增删改查
4.新旧版本兼容性测试
5.默认值测试（例如：某参数在后台设置界面为非必填，但接口会一致下发该字段，这时候就会需要一个默认值，保证接口数据正常。）
接口逻辑：
接口是否有依赖业务。（例如：比如修改密码的接口，必须要在用户登录的情况下才允许请求）
异常测试：
1.不传必填参数
2.传递错误参数类型
3.参数值为空
4.参数值错误
（2）、接口测试用例
确定测试点之后，根据测试点设计测试用例。接口逻辑相对较少，用例设计相对简单，具体会放在实例中介绍。
