接口测试面试题汇总

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

根据⽹络资料，总结了以下⼀些常见的接⼝测试⾯试题：

1. 为什么要做接⼝测试？

2. 接⼝测试能发现哪些问题？

3. 接⼝测试怎么测？

4. ⽤什么⼯具测接⼝？

5. WebService接⼝是如何测试的？

6. 没有接⼝⽂档如何做接⼝测试？

7. 在接⼝测试过程中，上下游接⼝有数据依赖如何处理？

8. 依赖第三⽅数据的接⼝如何进⾏测试？

9. 当⼀个接⼝出现异常时，你是如何分析异常的？

10. 如何模拟弱⽹测试？

11. 如何分析⼀个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个请求）对最后⼀个商品下单，或不同账号，对最后⼀个商品下单

接⼝响应时间，响应时间太长了，肯定需要优化，⼀般都是毫秒级别⽤什么⼯具测接⼝

：推荐。基本功能免费。最简单的基于http接⼝的调试和测试⼯具;

：后置处理器配合断⾔基本上可以满⾜接⼝测试需求，就是测试报告要做⼆次开发

⾃⼰撸代码：推荐。配合类似xunit测试框架，基本可以满⾜⼀切需求；

: 收费的；

：强⼒推荐。postman的弱化版，基本功能免费，重要的是⼯具代码开源，可以⾃⼰改；

: 强⼒推荐。mac上最强，淘宝买个授权好像就百把块钱；

WebService接⼝是如何测试的

webService接⼝⽤SoapUI没有接⼝⽂档如何做接⼝测试

没有接⼝⽂档，那还能咋办，瞎测呗！⼀个公司的开发流程⾥⾯，如果接⼝⽂档都没有，是⽆法展开接⼝测试的，你都不知道这个接⼝⼲什么的，也不知道具体每个字段代表什么意思，那还测啥呢？

--当然，你肯定不能回答⾯试官不测(⼼理mmp，脸上笑嘻嘻)，接下来就是扯犊⼦时间

1.没有接⼝⽂档，那就需要先跟开发沟通，然后整理接⼝⽂档（本来是开发写的，没办法，为了唬住⾯试官，先说⾃⼰整理了）

2.没有接⼝⽂档，可以抓包看接⼝请求参数，然后不懂的跟开发沟通

本题主要靠情商，通俗来说就是忽悠能⼒，先唬住⾯试官了再说，进去了也是瞎测测，随时做好背锅的准备

在接⼝测试过程中，上下游接⼝有数据依赖如何处理

⽤⼀个全局变量来处理依赖的数据，⽐如登录后返回token,其它接⼝都需要这个token,那就⽤全局变量来传token参数

依赖第三⽅数据的接⼝如何进⾏测试

这个标准答案是：mock

接着⾯试官会问你，如果mock的，然后你就顺着坑继续挖，搭建mock服务，参考这篇

当⼀个接⼝出现异常时，你是如何分析异常的

1.抓包，⽤fiddler⼯具抓包，或者浏览器上f12,app上的话，那就⽤fiddler设置代理，去看请求报⽂和返回报⽂了

2.查看后端⽇志，xhell连上服务器，查看⽇志

如何模拟弱⽹测试

fiddler和charles都可以模拟弱⽹测试，平常说的模拟丢包，也是模拟弱⽹测试

如何分析⼀个bug是前端还是后端的

平常提bug的时候，前端开发和后端开发总是扯⽪，不承认是对⽅的bug

这种情况很容易判断，先抓包看请求报⽂，对着接⼝⽂档，看请求报⽂有没问题，有问题就是前端发的数据不对

请求报⽂没问题，那就看返回报⽂，返回的数据不对，那就是后端开发的问题咯