一、接口测试流程
1、需求讨论
2、需求评审
3、场景设计
4、数据准备
5、测试执行
二、分析接口文档元素
1、接口名称
2、接口地址
3、支持格式
4、请求方式
5、请求参数（参数名称、类型、是否必填、参数说明等）
6、返回参数（返回码、返回值信息、返回JSON串信息）
三、如何设计接口测试用例
3.1、为什么要设计测试用例
1、理清思路、避免漏测
2、提高测试效率
3、跟进测试进度
4、体现任务工作量
5、跟进重复性工作
3.2、设计接口测试用例从哪些方面考虑
1、功能
功能是否正常
功能是否按照接口文档实现
正常场景
异常场景
2、逻辑业务
是否依赖业务、比如是否登录成功
3、异常测试
（1）参数异常
关键字参数、参数为空、多参数、少参数、错误参数
覆盖所有的必选参数，组合可选参数，参数有、无或为null，参数的顺序、个数、类型
参数类型数值大小、输入的数值范围，参数字串长短，参数包含特殊字符
（2）数据异常
关键字数据、数据为空、长度不一致、错误数据
4、安全
Cookie
header
唯一识别码
四、常用的接口测试用例覆盖方法
1、必须参数覆盖
对于接口的参数，接口文档一般都会说明哪些是必需的，哪些是非必需的。
对于必需的参数，一定要测试传参数和不传参数接口是否报错。
2、必须参数各种情况覆盖
传非法的字符，特殊的字符，空值，超过边界的参数是否报错？错误信息是否正确？
3、非必须参数覆盖
一般接口对于非必需参数都不会做非正常性传值的判断，所以要测试合法的参数值，接口返回的内容是否正确。
如果有接口文档说明对非必需参数做了非正常的验证的话，也要对其进行验证。
4、参数组合覆盖
有些参数需要相互配合着才起作用，如“offset”和“count”组合起来进行翻页，这个时候要组合起来进行测试。
5、业务逻辑相关覆盖
有些接口与业务逻辑关联密切，单独从接口角度测试，可能会遗漏掉一些因业务逻辑而产生的bug。
所以如果和业务逻辑相关，也要考虑到业务逻辑相关的测试用例。
五、接口测试接口优先级
1、优先级 - 针对所有接口
（1）暴露在外面的接口，因为通常该接口会给第三方调用
（2）供系统内部调用的核心功能接口
（3）供系统内部调用非核心功能接口
2、优先级 - 针对单个接口
（1）正向用例优先测试，逆向用例次之(通常情况，非绝对)
（2）是否满足前提条件 > 是否携带默认参数 > 参数是否必填 > 参数之间是否存在关联 > 参数数据类型限制 >参数数据类型自身的数据范围限制
六、接口测试的设计思路分析
1、是否满足前提条件
有些接口需要满足前置条件，才可成功获取数据。如常见的需要登陆Token。
逆向用例：
针对是否满足前置条件（假设为n个条件），设计0~n条用例
2、是否携带默认值参数
正向用例：
带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其它不填写，设计正向用例
3、业务规则、功能需求
根据实际情况，结合接口参数说明，可能需要设计n条正向用例和逆向用例
4、参数是否必填
逆向用例：
针对每个必填参数，都设计1条参数值为空的逆向用例
5、参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
逆向用例：
根据实际情况，可能需要设计0~n条用例
6、参数数据类型限制
逆向用例：
针对每个参数都设计1条参数值类型不符的逆向用例
7、参数数据类型自身的数据范围限制
正向用例：
针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
逆向用例：
针对每个参数（假设n个），设计n条每个参数的参数值都超出数据范围最大值的逆向用例
针对每个参数（假设n个），设计n条每个参数的参数值都小于数据范围最小值的逆向用例
总结：
以上几个方面考虑全的话，基本可以做到如下几个方面的覆盖：
（1）主流程测试用例：正常的主流程功能校验
（2）分支流测试用例：正常的分支流功能校验
（3）异常流测试用例：异常容错校验
七、接口测试返回结果的比较
目的：
验证代码正常
验证代码正确
1、比较返回码
2、比较返回值的完整性，即返回的key全不全
3、比较key的value数据类型
4、比较key对应的value值（也包括验证业务相关数据的value值）
最后感谢每一个认真阅读我文章的人，礼尚往来总是要有的，这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：
这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你！
