1、get和post区别是什么？
答：POST和GET都是向服务器提交数据，并且都会从服务器获取数据。
区别：
（1）传送方式：get通过地址栏传输，post通过报文传输
（2）传送长度：get参数有长度限制（受限于url长度），而post无限制
（3）GET产生一个TCP数据包（对于GET方式的请求，浏览器会把http header和data一并发送出去，服务器响应200返回数据），POST产生两个TCP数据包（对于POST，浏览器先发送header，服务器响应100 continue，浏览器再发送data，服务器响应200 ok返回数据）
（4）get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留
（5）在做数据查询时，建议用GET方式；而在做数据添加、修改或删除时，建议用post方式
2、cookie和session的区别
（1）cookie数据存放在客户的浏览器上，session数据放在服务器上
（2）cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session
（3）session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面应当使用cookie
（4）单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie
（5）可以将登陆信息等重要信息存放为session；其他信息需要保存，可以放在cookie
3、请求接口中常见的返回状态码
答：
1xx -- 信息提示（表示临时的响应。客户端在收到常规响应之前，准备接收一个或多个1xx响应）
2xx -- 成功（表明服务器成功地接受了客户端请求）
3xx -- 重定向（客户端浏览器必须采取更多操作来实现请求。例如，浏览器可能不得不请求服务器上的不同的页面，或通过代理服务器重复该请求）
4xx -- 客户端错误（发送错误，客户端有问题。例如，客户端请求不存在的页面，客户端未提供有效的身份证验证信息）
5xx -- 服务器错误（服务器由于遇到错误而不能完成该请求）
常见的有
（1）200 OK - [GET]：服务器成功返回用户请求的数据
（2）201 CREATED - [POST/PUT/PATCH]：用户新建或修改数据成功
（3）202 Aceepted - [*]：表示一个请求已经进入后台排队（异步任务）
（4）204 NO CONTENT - [DELETE]：用户删除数据成功
（5）400 INVALID REQUEST - [POST/PUT/PATCH]：用户发出的请求有错误，服务器没有进行新建或修改数据的操作
（6）401 Unauthorized -[*] ：表示用户没有权限（令牌、用户名、密码错误）
（7）403 Forbidden -[*] ：表示用户得到授权（与401错误相对），但是访问被禁止
（8）404 NOT FOUND -[*]：用户发出的请求针对得到是不存在的记录，服务器没有进行操作，该操作是幂等的
（9）406 Not Acceptable - [GET]：用户请求的格式不可得（比如用户请求JSON格式，但是只有XML格式）。
（10）410 Gone -[GET]：用户请求的资源被永久删除，且不会再得到的。
（11）422 Unprocesable entity - [POST/PUT/PATCH] 当创建一个对象时，发生一个验证错误。
（12）500 INTERNAL SERVER ERROR - [*]：服务器发生错误，用户将无法判断发出的请求是否成功。
4、怎么设计接口测试用例
通常，设计接口测试用例需要考虑以下几个方面：
（1）是否满足前提条件
有些接口需要满足前提，才可成功获取数据。常见的，需要登录Token
逆向用例：针对是否满足前置条件（假设为n个条件），设计0~n条用例
（2）是否携带默认值参数
正向用例：带默认值的参数都不填写、不传参，必填参数都填写正确且存在的“常规”值，其他不填写，设计1条用例
（3）业务规则、功能需求
这里根据时间情况，结合接口参数说明，可能需要设计N条正向用例和逆向用例
（4）参数是否必填
逆向用例：针对每个必填参数，都设计1条参数值为空的逆向用例
（5）参数之间是否存在关联
有些参数彼此之间存在相互制约的关系
（6）参数数据类型限制
逆向用例：针对每个参数都设计1条参数值类型不符的逆向用例
（7）参数数据类型自身的数据范围值限制
正向用例：针对所有参数，设计1条每个参数的参数值在数据范围内为最大值的正向用例
5、如何分析是前段还是后端的问题
（1）检查接口，前端和后台之间是通过接口文件相互联系的，需要查看接口文件
（2）检查请求的数据是什么，反馈的数据又是什么
（3）根据接口文件，检查数据是否正确。如果发送的数据是正确的，但是后台反馈的数据是不符合需求的，那就是后台的问题；如果前端没有请求接口或请求的时候发送数据与需求不符，那这个时候就是前端的问题了。
（先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题）
6、在手工接口测试或者自动化接口测试过程中，上下游接口有数据依赖如何处理？
答：在工具中可以使用全局变量等方式将需要的数据进行传送
7、依赖第三方数据的接口如何进行测试？
答：可以使用SoapUI等工具直接调用第三方数据接口的webservice，通过返回值来查看第三方数据的接口是否调用正常
也可以利用一些MOCK的工具来模拟第三方的数据返回，最大限度的降低对第三方数据接口的依赖
8、接口测试中，依赖登录状态的接口如何测试？
答：依赖登录状态的接口的本质上是在每次发送请求时需要带上session或者cookie才能发送成功，在构建POST请求时添加必要的session或者cookie
根据网络资料，总结了以下一些常见的接口测试面试题：
- 为什么要做接口测试？
- 接口测试能发现哪些问题？
- 接口测试怎么测？
- 用什么工具测接口？
- WebService接口是如何测试的？
- 没有接口文档如何做接口测试？
- 在接口测试过程中，上下游接口有数据依赖如何处理？
- 依赖第三方数据的接口如何进行测试？
- 当一个接口出现异常时，你是如何分析异常的？
- 如何模拟弱网测试？
- 如何分析一个bug是前端的还是后端的？
为什么要做接口测试
在讨论为什么要做接口测试之前，我们先稍微了解下接口是什么？
接口可以很不准确的理解成是与资源打交道，这个资源可能是本系统的，也可能是其他系统的。
举个例子，假如我们在开发1个bug管理系统，该系统需要拿到公司的所有开发和测试人员的信息，这样开发和测试人员不用注册都可以登录进去了，这应该很好理解。
那么这些人员的信息储存在哪里呢？一般存储在hr系统里。现在的需求更加明确了，我们要到hr系统中去拿到人员信息，获取hr系统中的人员资源。
怎么拿呢？很多种方式，可以直接把hr系统的数据库拷贝一份放到bug管理系统里，不过这样不好，因为数据的同步会有点麻烦；还可以直接连hr系统的数据库去查，这样也不太好，这样我们就需要了解hr系统的数据存储结构和逻辑，一旦hr系统的数据字段发生改变，bug管理系统也要去该，以便同步。
比较好的做法是，hr系统暴露一些接口，通过这些接口去获取人员信息资源，这样bug系统就不需要关心hr系统的数据存储实现了。
这些接口可能是这样的：
- 登录的接口，提供人员的用户名和密码，去hr系统中判断该人员是否存在，如果存在验证用户名和密码，如果验证通过就返回1个token，该token就是这个人员的通行证，通过token可以登录到bug管理系统中去；
- 获取人员信息的接口，返回该人员的职位：测试还是开发，以及用户名，昵称等信息；
综上：接口可以理解成是不同系统或模块之间资源交流方式。
接口测试实际上是黑盒测试，基本的测试思路是根据输入和输出判断被测系统或对象的逻辑。获取人员的信息，我需要把人员的用户名传给hr系统接口，这样hr系统的接口会返回给我用户的一些更加具体的信息。这里的输入是用户名，输出是用户的详细信息。
既然是接口获取和操作资源的方式，而大部分系统和产品中，资源一般都是产品的核心，比如微信核心资源就是通讯录关系链和聊天记录等，因此资源是必测的。
另外接口中大部分的内容是数据，通过数据的对比我们能推测到系统和产品的逻辑，测接口就是测逻辑。
最后接口中的返回相对单纯，不像web页面，html代码中有太多ui的东西，ui最不稳定，变化太快，接口相对稳定一点点，但是里面的干扰信息更少，断言相对容易很多。
请看以下一个案例，如下图一个提现功能
比如这个输入框，平常拿到这个web页面，会对输入框做用例设计：
- 输入一个负数（如：-100），点提交
- 输入金额为0（如：0），点提交
- 输入金额为0-100的数（如：20），点提交
- 输入金额为100（如：100），点提交
- 输入金额大于100（如：108），点提交
- 输入1位小数（如：10.1），点提交
- 输入2位小数（如：10.12），点提交
- 输入3位小数（如：10.123），点提交
按照这个等价类，边界值用例测完，页面上不能输入负数和大于3位数小数点，然后就可以上线了。
然而。。。突然有一天数据库里面插入了一个提现金额为负数（-100），于是整个部门炸锅了，首先找到测试（背锅）去复现问题，测试在页面上反复输入负数，无法提交，认为没问题啊！
首先前端开发对输入框是做了限制的，前端的web开发肯定没问题，这个锅前端开发MM不背。那么如果别人用户不通过你的web页面，直接发请求提交了呢？
纳尼！！！不通过页面也能提交。。。这就是我们接下来要提到的接口测试了。
接口测试能发现哪些问题
这个问题其实回到起来很简单，只要做过接口测试的，总能发现几个BUG吧，把你平常发现的bug说2-3个就可以了。
面试官出这个题，主要是想知道你是不是真的做过接口测试，毕竟现在很多小伙伴简历都是写的假的（你要不写估计面试机会都没有，没办法，为了生存，能理解）
比如上面说的，提现输入框，在页面上输入负数，肯定是无法提交过去（前端页面会判断金额），如果我不走前端，直接用接口工具发请求，输入一个负数过去。
（假设服务端没做提现金额数据判断）
余额=当前余额（100）-提现金额（-100），那么提现-100，余额就变成200了，也就是越提现，余额越大了
可以用接口工具去直接请求接口，也可以fiddler抓包，抓到接口后修改金额为负数
所以，接口测试的必要性就体现出来了：
1.可以发现很多在页面上操作发现不了的bug
2.检查系统的异常处理能力
3.检查系统的安全性、稳定性
4.前端随便变，接口测好了，后端不用变
5.可以测试并发情况，一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
6.可以修改请求参数，突破前端页面输入限制（如金额）
接口测试怎么测
- 通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
-
参数组合：现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传的，type传2的时候是删除商品，
商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。 -
接口安全：
1、绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
2、绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
3、参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
4、密码安全规则，密码的复杂程度校验 -
异常验证：
所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。 -
性能测试
接口并发情况，如上面提到的：一个账号，同时（大于2个请求）对最后一个商品下单，或不同账号，对最后一个商品下单
接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别
用什么工具测接口
- postman： 推荐。基本功能免费。最简单的基于http接口的调试和测试工具;
- jmeter：后置处理器配合断言基本上可以满足接口测试需求，就是测试报告要做二次开发
- 自己撸代码：推荐。配合类似xunit测试框架，基本可以满足一切需求；零基础实现python接口自动化视频教程，一起撸代码吧
- soapui: 收费的；
- insomnia：强力推荐。postman的弱化版，基本功能免费，重要的是工具代码开源，可以自己改；
- paw: 强力推荐。mac上最强，淘宝买个授权好像就百把块钱；
WebService接口是如何测试的
webService接口用SoapUI
没有接口文档如何做接口测试
没有接口文档，那还能咋办，瞎测呗！一个公司的开发流程里面，如果接口文档都没有，是无法展开接口测试的，你都不知道这个接口干什么的，也不知道具体每个字段代表什么意思，那还测啥呢？
--当然，你肯定不能回答面试官不测(心理mmp，脸上笑嘻嘻)，接下来就是扯犊子时间
1.没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）
2.没有接口文档，可以抓包看接口请求参数，然后不懂的跟开发沟通
本题主要靠情商，通俗来说就是忽悠能力，先唬住面试官了再说，进去了也是瞎测测，随时做好背锅的准备
在接口测试过程中，上下游接口有数据依赖如何处理
用一个全局变量来处理依赖的数据，比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数
依赖第三方数据的接口如何进行测试
这个标准答案是：mock
接着面试官会问你，如果mock的，然后你就顺着坑继续挖，搭建mock服务，参考这篇【https://www.cnblogs.com/yoyoketang/p/9348552.html】
当一个接口出现异常时，你是如何分析异常的
1.抓包，用fiddler工具抓包，或者浏览器上f12,app上的话，那就用fiddler设置代理，去看请求报文和返回报文了
2.查看后端日志，xhell连上服务器，查看日志
如何模拟弱网测试
fiddler和charles都可以模拟弱网测试，平常说的模拟丢包，也是模拟弱网测试
如何分析一个bug是前端还是后端的
平常提bug的时候，前端开发和后端开发总是扯皮，不承认是对方的bug
这种情况很容易判断，先抓包看请求报文，对着接口文档，看请求报文有没问题，有问题就是前端发的数据不对
请求报文没问题，那就看返回报文，返回的数据不对，那就是后端开发的问题咯