1.测试模型
单元测试并非测试工程师的本职工作，它属于开发工程师的工作，开发进行单元测试的情况我们不知道，为了确保系统尽可能没有Bug，于是接口测试在测试工程师这里就变得由为重要了。实际工作中为菱形模型。
接口测试能更早的进入系统测试，当接口完成之后就可以编写接口测试用例。
2.外部接口和内部接口
内部接口就是系统内部调用的接口。比如你在网上购物时，要先登录系统，然后将商品加入购物车，再接下来支付订单。那么，从添加商品到购物车，再到支付订单，这一长串的流程之间，就是通过系统内部接口来完成的。
外部接口相对于内部接口而存在的一个概念，比如你在购物后点击付款时，页面会跳转到支付系统，等你完成支付流程后，再跳转回订单页，在这样的流程中，都会涉及系统对外的接口，还有，比如说付款工程的支付接口、配送过程的物流接口等等。
3.设计接口测试用例
需要清楚的三点：
-
，参数的含义以及来源
你也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到的？还是 JS 生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个字段？ -
参数的作用域
参数的作用域指的是这个参数在这个接口中是做什么用的，它在哪一个访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验证用户权限吗？它的验证算法是什么？ -
返回值的含义
当你需要和这个接口产生交互的时候，就可以快速地拿到对应参数的含义，完成业务逻辑上下文的参数串联了。
4.对于有接口文档，进行接口测试
post请求 url
请求头
直接在接口工具上面输入接口信息即可
5.对于没有接口文档，进行接口测试
先抓包，可以用浏览器抓包，页面上右键-检查，然后点Network就可以看到抓包的信息，然后再填到接口工具，比如postman。
-
post请求
1)头部信息
需求关注的请求头：Cookie，Content-Type，Blade-Auth，Authorization，token。有这些值的话需要填到postman的请求头上去。
HOST，它表示指定访问的服务器域名；
Connection 的值为 keep-alive，这表示需要持久连接;
Accept，它表示客户端可以接受的内容类型为 application/json, text/plain, / ；t
User-Agent，它说明请求是从什么浏览器发出去的；
Sec-Fetch-Site 和 Sec-Fetch-Mode，它们是 JS 中对跨域的一些设置；
Accept-Encoding 设置为 gzip、deflate、br，这表示可以支持的 Web 服务器返回内容压缩编码类型；
Accept-Language，它表示接受的语言。
2）入参
3）出参
{
“code”: 200,
“success”: true,
“data”: {
“link”: “pig/count/video/20230206/17/3af76f7e84319f66f1c6260dc27a82c3.mp4”,
“name”: “pig/count/video/20230206/17/3af76f7e84319f66f1c6260dc27a82c3.mp4”,
“originalName”: “5.mp4”,
“attachId”: “f7cd00b1516974d42232cb12c24175b2”
},
“msg”: “操作成功”
}
4）后置处理
下个接口的入参需要用到上个接口的出参的值，写js脚本提取上个接口出参的值，然后赋值给全局变量。下个接口入参值使用{{name}}接口关联起来了。
5）前置处理
是在执行该接口之前需要执行的脚本，比如密码被加密了，在执行接口前需要解密，然后再请求。又比如在跳转其他url
-
get请求
6.怎么形成接口自动化测试
我们将接口抓包之后，在postman上将单个接口都跑通了，一个url算一个接口，然后将多个单接口组合起来形成业务流程接口。
比如生猪点数这个业务流程，是由上传文件接口+点数接口+查询结果接口组合的。为什么要组合呢，是因为传进去的参数不同，返回的结果不同，再加上接口之间是关联的，所有需要做成业务流程接口，然后就可以实现接口自动化测试了。
7.为何还要测试脚本，开发测试框架
现在接口测试工具很多，也很方便使用，为什么还要写测试脚本，写起来困难，而且没接口测试工具看起来更直观。
接口测试工具的缺点：随着你的接口测试项目逐渐增加，你会发现越来越难以管理它的脚本，如果你接到了一个它无法完成的接口类型的测试任务，就不得不再去寻找另一个工具。所以，开发你自己的测试框架非常重要。
Python写接口测试脚本见我另外一篇博文接口自动化测试
在写脚本的过程中，还可以结合接口测试工具生成的脚本，然后修改放到自己的测试框架中。
