前言

最近在找工作，因为是做纯服务端测试的，所以面试过程中面试官难免会问，怎么设计接口测试用例，怎么做接口自动化测试？会象征性的考一下基本功。

下面就接口测试，或者说服务端测试，梳理一下我的思路吧~

一、什么是接口

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中加用例，而用例里基本上就实现断言就行。

如果还想加一些日志，或者需要查库做断言等等，可以再优化下。

码字不易，转载请注明出处，谢谢~

---

学习资源分享

最后感谢每一个认真阅读我文章的人，看着粉丝一路的上涨和关注，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走

这些资料，对于想【进阶测试开发】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。希望对大家有所帮助…….