前言
最近在找工作，因为是做纯服务端测试的，所以面试过程中面试官难免会问，怎么设计接口测试用例，怎么做接口自动化测试？会象征性的考一下基本功。
下面就接口测试，或者说服务端测试，梳理一下我的思路吧~
一、什么是接口
Q：什么是接口？
A：举个例子吧，渴了想喝水，旁边刚好有个饮水机，水龙头就是一个接口
那么在程序中道理也是一样的，你在应用程序上买衣服、订餐、租房子、订机票这些衣食住行，其实都在访问对应程序的接口。
以我下面要举的例子说明：
有个登录页面，你要登上网站，就需要输入你的账号密码，把账号密码作为请求参数打登录接口，这时客户端会给服务器发个登录请求，服务器鉴权和校验通过之后，就登上去了。
到这里就完成了一次接口的请求，或者说跑完了一条接口测试用例。
二、常见的接口请求类型有哪些？
常用的接口请求类型有：post get put delete
平常面试会问到get和post的区别，不懂百度一下
那么，要设计接口测试用例，首先需要接口契约，也就是接口文档。
接口文档长啥样，看下面~
三、接口文档范例
测试功能为登录页面：https://xxx/account/signin（url我打码了）
接口地址：https://xxx/account/signin（想了想接口也打码吧，毕竟是要收费的）
请求方式：POST
接口描述：某网站登录接口
【接口入参】
【接口返回】
【接口请求示例】
{
"account": "1801367@qq.com",
"password": "191004"
}
【接口返回示例】
{
"code": 0,
"msg": "",
"data": {
"name": null,
"avatar": null,
"id": "7",
"account": "18067@qq.com",
"role": 3
}
}
了解了接口契约，怎么设计接口测试用例呢，请继续往下看。
四、怎么设计接口测试用例
首先你得有个框架
测接口也测了好几年了，梳理一份用例模板，简单参考下，不全的欢迎补充~
所以基于这套模板，我们可以设计一下接口契约中的登录接口的用例
五、基于登录接口设计测试用例
1.参数校验
-
account
- 必填：不填，空字符串，传null，不传该字段
- 字符串类型：传int型或其他类型
- 长度校验：假如范围[1-20]，小于1、大于20，在1-20范围内，传超长
- 枚举：无
-
password
- 必填：不填，空字符串，传null，不传该字段
- 字符串类型：传int型或其他类型
- 长度校验：假如范围[1-20]，小于1、大于20，在1-20范围内，传超长
- 枚举：无
2.参数组合
- 账号密码正确，登录成功，返回数据拿到用户角色及用户信息
- 账号错，密码对，登录失败，code1
- 账号对，密码错，登录失败，code1
- 账号错，密码错，登录失败，code1
3.业务逻辑
- 数据流转：登录账号为数据库成员，登上去后接口返回data为数据库查到的数据
- 权限：管理员账号、普通用户账号、运营账号
- 账号类型：qq邮箱、企业邮箱或其他类型邮箱，正常登录，手机号不支持
- 多端登录是否有逻辑处理，要不要限制有最多几个用户登录
4.安全性
- 密码明文可见
- 抓包不能抓到
- 登录鉴权，前端和服务端都要做
- token时效性
- sql注入
5.性能
- 响应时间200ms
- 并发数（登录我感觉没必要考虑高并发，具体业务场景具体分析）
6.日志
- 测接口时，关注日志
7.监控
- 接口功能上线了，要关注下业务请求和各种异常监控
六、接口测试常用什么工具
- postman
- jmeter
- linux命令 curl 发一个接口请求
- python、java写脚本
以上都可以，第四个用于做接口自动化测试
七、接口自动化测试思路
第一步：把手工case通过写代码的方式，转成自动化测试的case，设置case的断言，然后去跑这批case让他自动执行，先让代码可以粗陋的跑起来
第二步：减少重复性代码，把测试数据整合做成参数化读取，进行数据驱动
第三步：优化代码可读性，抽离通用模块
八、接口自动化测试实战演练
完成第一步，很简单，写出来一个，其他的复制粘贴，改断言，改参数
那么问题是什么？
- 新增一条用例，我要在代码里改一条，参数也放在代码里，看起来累，改起来也很累。
完成第二步，把用例放在excel中，通过pytest自带的装饰器进行参数化
这里解决了第一步改参数的问题，但是这里依然存在问题
- 代码重复量大，后面再增加一条用例，那块重复的要再写一遍
- 获取excel数据的方法放在测试用例中，代码可读性差，我们的测试用例最好不要包含前置条件。
完成第三步，提取读excel数据部分，放在单独的文件中，把参数转换和发起请求这部分提起来。
同时优化了一下获取excel数据部分，上一步我们是读区域，这样可扩展性差，如果后期我要在excel里加用例，就需要改这块的区域，所以让他直接读这一列，这样后期随便加不影响。
这样看着就清爽多了，加用例，只需要改excel，然后在testcase中加用例，而用例里基本上就实现断言就行。
如果还想加一些日志，或者需要查库做断言等等，可以再优化下。
码字不易，转载请注明出处，谢谢~
阅完可以留个小心心，关注一下，还有公众号，谢谢~
说明一下文中用到的示例是「灵题库」的接口，有前端刷题需要的可以关注下
