赞
踩
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个bug管理系统,该系统需要拿到公司的所有开发和测试人员的信息,这样开发和测试人员不用注册都可以登录进去了,这应该很好理解。
那么这些人员的信息储存在哪里呢?一般存储在hr系统里。现在的需求更加明确了,我们要到hr系统中去拿到人员信息,获取hr系统中的人员资源。
怎么拿呢?很多种方式,可以直接把hr系统的数据库拷贝一份放到bug管理系统里,不过这样不好,因为数据的同步会有点麻烦;还可以直接连hr系统的数据库去查,这样也不太好,这样我们就需要了解hr系统的数据存储结构和逻辑,一旦hr系统的数据字段发生改变,bug管理系统也要去该,以便同步。
比较好的做法是,hr系统暴露一些接口,通过这些接口去获取人员信息资源,这样bug系统就不需要关心hr系统的数据存储实现了。
这些接口可能是这样的:
综上:接口可以理解成是不同系统或模块之间资源交流方式。
接口测试实际上是黑盒测试,基本的测试思路是根据输入和输出判断被测系统或对象的逻辑。获取人员的信息,我需要把人员的用户名传给hr系统接口,这样hr系统的接口会返回给我用户的一些更加具体的信息。这里的输入是用户名,输出是用户的详细信息。
既然是接口获取和操作资源的方式,而大部分系统和产品中,资源一般都是产品的核心,比如微信核心资源就是通讯录关系链和聊天记录等,因此资源是必测的。
另外接口中大部分的内容是数据,通过数据的对比我们能推测到系统和产品的逻辑,测接口就是测逻辑。
最后接口中的返回相对单纯,不像web页面,html代码中有太多ui的东西,ui最不稳定,变化太快,接口相对稳定一点点,但是里面的干扰信息更少,断言相对容易很多。
请看以下一个案例,如下图一个提现功能
比如这个输入框,平常拿到这个web页面,会对输入框做用例设计:
按照这个等价类,边界值用例测完,页面上不能输入负数和大于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个请求)对最后一个商品下单,或不同账号,对最后一个商品下单
接口响应时间,响应时间太长了,肯定需要优化,一般都是毫秒级别
webService接口用SoapUI
没有接口文档,那还能咋办,瞎测呗!一个公司的开发流程里面,如果接口文档都没有,是无法展开接口测试的,你都不知道这个接口干什么的,也不知道具体每个字段代表什么意思,那还测啥呢?
--当然,你肯定不能回答面试官不测(心理mmp,脸上笑嘻嘻),接下来就是扯犊子时间
1.没有接口文档,那就需要先跟开发沟通,然后整理接口文档(本来是开发写的,没办法,为了唬住面试官,先说自己整理了)
2.没有接口文档,可以抓包看接口请求参数,然后不懂的跟开发沟通
本题主要靠情商,通俗来说就是忽悠能力,先唬住面试官了再说,进去了也是瞎测测,随时做好背锅的准备
用一个全局变量来处理依赖的数据,比如登录后返回token,其它接口都需要这个token,那就用全局变量来传token参数
这个标准答案是:mock
接着面试官会问你,如果mock的,然后你就顺着坑继续挖,搭建mock服务
1.抓包,用fiddler工具抓包,或者浏览器上f12,app上的话,那就用fiddler设置代理,去看请求报文和返回报文了
2.查看后端日志,xhell连上服务器,查看日志
fiddler和charles都可以模拟弱网测试,平常说的模拟丢包,也是模拟弱网测试
平常提bug的时候,前端开发和后端开发总是扯皮,不承认是对方的bug
这种情况很容易判断,先抓包看请求报文,对着接口文档,看请求报文有没问题,有问题就是前端发的数据不对
请求报文没问题,那就看返回报文,返回的数据不对,那就是后端开发的问题咯
感谢每一个认真阅读我文章的人!!!
作为一位过来人也是希望大家少走一些弯路,如果你不想再体验一次学习时找不到资料,没人解答问题,坚持几天便放弃的感受的话,在这里我给大家分享一些自动化测试的学习资源,希望能给你前进的路上带来帮助。
我们学习必然是为了找到高薪的工作,下面这些面试题是来自阿里、腾讯、字节等一线互联网大厂最新的面试资料,并且有字节大佬给出了权威的解答,刷完这一套面试资料相信大家都能找到满意的工作。
视频文档获取方式:
这份文档和视频资料,对于想从事【软件测试】的朋友来说应该是最全面最完整的备战仓库,这个仓库也陪伴我走过了最艰难的路程,希望也能帮助到你!以上均可以分享,点下方小卡片即可自行领取。
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。