一、请求接口中常见的返回状态码
请求接口中返回状态码以如下数字开头:
1xx– 信息提示(表示临时的响应。客户端在收到常规响应之前,准备接收一个或多个 1xx 响应)。
2xx – 成功(表明服务器成功地接受了客户端请求)。
3xx – 重定向(客户端浏览器必须采取更多操作来实现请求。例如,浏览器可能不得不请 求服务器上的不同的页面,或通过代理服务器重复该请求)。
4xx – 客户端错误(发送错误,客户端有问题。例如,客户端请求不存在的页面,客户端 未提供有效的身份证验证信息) 。
5xx-服务器错误,服务器在处理请求的过程中发生了错误。
常见的返回码有:
- 200 OK - [GET]:服务器成功返回用户请求的数据。
- 201 CREATED - [POST/PUT/PATCH]:用户新建或修改数据成功。
- 202 Aceepted - []:表示一个请求已经进入后台排队(异步任务)
- 204 NO CONTENT - [DELETE]:用户删除数据成功
- 400 INVALID REQUEST - [POST/PUT/PATCH]:用户发出的请求有错误,服务器没有进行 新建或修改数据的操作。
- 401 Unauthorized -[] :表示用户没有权限(令牌、用户名、密码错误)。
- 403 Forbidden :表示用户得到授权,但是访问被禁止。
- 404 NOT FOUND:用户发出的请求针对得到是不存在的记录,服务器没有进行操作, 该操作是幂等的。
- 500 INTERNAL SERVER ERROR :服务器遇到错误,无法完成请求。
- 502:服务器作为网关或代理,从上游服务器收到了无效的响应。
二、请问你们公司是如何做接口测试的?
接口测试实际跟一般功能测试不同就是测试用例的设计部分。接口测试步骤可概括如下:
①获取接口文档。
②设计接口测试功能用例(主要从用户角度出发看接口能否实现业务需求,用例设计就是黑盒用例那一套)。
③各种入参验证(正常情况,异常情况包括输入参数个数不对,类型不对,可选/必选,还有考虑参数有互斥或关联的情况)。
④接口返回值各种验证(符合接口文档需求)。
⑤了解接口实现逻辑,实现逻辑覆盖(语句/条件/分支/判定/…)。
⑥接口能并发执行吗、安全吗,性能满足要求吗?
⑦采用工具或者自写代码来验证。
⑧发现问题跟功能测试一样,该报 bug 报 bug,该跟踪状态的跟踪状态。
三、你平常做接口测试的过程中发现过哪些 bug?
接口测试中发现的bug类型有如下几种:
-
常规错误,接口没实现,没按约定返回结果,边界值处理出错等。输入异常值(空值、特殊字符、超过约定长度等),接口抛错,没做封装处理;输入错误的参数、多输入、少输入参数;
-
接口可能出现的错误,安全性问题,如明文传输、返回结果含有敏感信息,没对用户身份信息做校验,没做恶意请 求拦截等;
-
性能问题,如接口并发插入多条相同操作,响应时间过长,接口压测出现瓶颈等。
四、接口测试怎么测?
接口测试可从以下几个方面入手:
-
通过性验证:首先肯定要保证这个接口功能是好使的,也就是正常的通过性测试,按照接口文档上的参数,正常传入,是否可以返回正确的结果。
-
参数组合:现在有一个操作商品的接口,有个字段type,传1的时候代表修改商品,商品id、商品名称、价格有一个是必传的,type传2的时候是删除商品,
-
商品id是必传的,这样的,就要测参数组合了,type传1的时候,只传商品名称能不能修改成功,id、名称、价格都传的时候能不能修改成功。
-
接口安全:
1、绕过验证,比如说购买了一个商品,它的价格是300元,那我在提交订单时候,我把这个商品的价格改成3元,后端有没有做验证,更狠点,我把钱改成-3,是不是我的余额还要增加?
2、绕过身份授权,比如说修改商品信息接口,那必须得是卖家才能修改,那我传一个普通用户,能不能修改成功,我传一个其他的卖家能不能修改成功
3、参数是否加密,比如说我登陆的接口,用户名和密码是不是加密,如果不加密的话,别人拦截到你的请求,就能获取到你的信息了,加密规则是否容易破解。
4、密码安全规则,密码的复杂程度校验。
- 异常验证:
所谓异常验证,也就是我不按照你接口文档上的要求输入参数,来验证接口对异常情况的校验。比如说必填的参数不填,输入整数类型的,传入字符串类型,长度是10的,传11,总之就是你说怎么来,我就不怎么来,其实也就这三种,必传非必传、参数类型、入参长度。
- 性能测试:
接口并发情况,如上面提到的:一个账号,同时(大于2个请求)对最后一个商品下单,或不同账号,对最后一个商品下单。
接口响应时间,响应时间太长了,肯定需要优化,一般都是毫秒级别。
五、Session与Cookie有什么区别?
Session与Cookie的区别可概括为如下几点:
① 保存位置。SESSION 数据保存在服务器端,Cookie 数据保存在客户端浏览器
② 保存方式。SESSION 默认被存在在服务器的一个文件里,可以手动设置放在文件、数据库、或内存中;Cookie 默认保存在客户端内存中,如果设置了过期时间就保存在硬盘中。
③ 依赖关系。SESSION 依赖 Cookie 来识别 session_id,如果浏览器禁用了 Cookie,SESSION 也会失效,此时可以通过 url 传递 session_id。
④ 安全性。因为 SESSION 数据保存在服务端,所以 SESSION安全性比Cookie 高。
⑤ 尺寸大小。SESSION 基本上没有大小限制,COOKIE 保存的内容比较小,具体由浏览器决定。
⑥ 服务器性能。SESSION 对服务器的压力会更大一些,而 Cookie 放在客户端,所以对服务器基本没影响。
六、get 和 post 区别是什么?
get 和 post 区别可概括为如下8个方面:
(1) 提交数据的形式:
-
GET方法一般是指获取服务器上的数据,通过地址栏传输,请求参数(query string查询字符串)直接跟着URL后,以?分割URL和传输数据,参数之间以&相连(?name=coco&pwd=123)的形式,直接可以放到浏览器地址栏里,如登录就是采用GET方法(name=coco&password=123&verify=%E4%BD%A0%E5 %A5%BD)。如果数据是英文字母/数字,原样发送,如果是空格,转换为+,如果是中文/其他字符,则直接把字符串用BASE64加密,得出如:%E4 %BD%A0%E5%A5%BD,其中%XX中的XX为该符号以16进制表示的ASCII。
-
POST方法是指客户端给服务器上提交表单数据,通过报文传输,会把数据放到请求数据字段中以&分隔各个字段,请求行不包含数据参数,地址栏也不会额外附带参数,所以POST是通过表单提交的,请求参数放在body中,如网页上的新用户的注册、调查问卷和答题就是采用POST方法。
(2) 提交数据的大小/长度:
-
GET是直接在浏览器地址栏输入,直接影响到了URL的长度,但HTTP协议规范中其实是没有对URL限制长度的,限制URL长度的是客户端或服务器的支持的不同所影响:比如IE对URL长度的限制是2083字节(2K+35)。对于其他浏览器,如Netscape、FireFox等,理论上没有长度限制,其限制取决于操作系统的支持。由于浏览器有限制,一般整个URL的长度可以很长,但是不能超过2049KB的大小限制,而POST没有大小限制。
-
POST方式HTTP协议规范中也没有限定,起限制作用的是服务器的处理程序的处理能力。所以大小的限制还是得受各个web服务器配置的不同而影响。
(3) 提交数据的安全性:
-
由于GET的参数是在浏览器地址栏URL直接拼接,用户名和密码将明文出现在URL上,暴露在互联网中,安全性差,不能用来传递敏感信息。
-
POST请求参数放在Body里,是通过表单数据提交,POST比GET方式的安全性要高;
(4) 编码方式:
-
GET的参数只能支持ASCII;
-
POST没有限制,也允许二进制数据;
(5) 请求方式:
-
GET是获取指定的资源 ;
-
POST是向指定的资源提交要被处理的数据 ;
(6) 请求体:
-
GET没有请求体;
-
POST有请求体;
(7) 效率方面:
- GET产生一个TCP数据包;
- POST产生两个TCP数据包,POST需要两步,时间上消耗要多一点,GET比POST更有效;
(8) 请求过程:
- 对于GET方式的请求,浏览器会把http header和data一并发送出去,服务器响应200(返回数据)
- POST方式的请求,浏览器先发送header,服务器响应100 continue,浏览器再发送data,服务器响应200 ok;
七、测试的数据你放在哪?
测试数据到底该怎么放,这个是面试官最喜欢问的一个题了,似乎仁者见仁智者见智,没有标准的答案,有的人说放excel,也有的说放.py脚本,也有的说放ini配置文件,还有放到json,yaml文件,txt文件,甚至有的放数据库,五花八门,一百个做自动化的小伙伴有100个放的地方。
这里总结下测试的数据到底该怎么放?
首先测试的数据是分很多种的,有登录的账户数据,也有注册的账户数据,还有接口的参数,还有邮箱配置的数据等等,所以这个题不能一概而论给答死了。要不然就是给自己挖坑。
以下两个大忌不能回答:
-
测试的数据是不能写死到代码里面的,这个是原则问题,也是写代码的大忌(你要是回答写在代码里面,估计就是回去等通知)。
-
测试数据放到.py的开头。(这种其实很方便,对于少量的,固定不变的数据其实是可以放的,但是面试时候,千万不能这样说,面试官喜欢装逼的方法。)
测试数据存放总结:
1.对于账号密码,这种管全局的参数,可以用命令行参数,单独抽出来,写的配置文件里(如ini);
2.对于一些一次性消耗的数据,比如注册,每次注册不一样的数,可以用随机函数生成;
3.对于一个接口有多组测试的参数,可以参数化,数据放yaml,text,json,excel都可以;
4.对于可以反复使用的数据,比如订单的各种状态需要造数据的情况,可以放到数据库,每次数据初始化,用完后再清理;
5.对于邮箱配置的一些参数,可以用ini配置文件;
6.对于全部是独立的接口项目,可以用数据驱动方式,用excel/csv管理测试的接口数据;
7.对于少量的静态数据,比如一个接口的测试数据,也就2-3组,可以写到py脚本的开头,十年八年都不会变更的;
总之不同的测试数据,可以用不同的文件管理。
八、没有接口文档,如果做接口测试?
一个公司的开发流程里面,如果接口文档都没有,是无法展开接口测试的,当然,你肯定不能回答面试官不测。可以这样回答:
-
没有接口文档,那就需要先跟开发沟通,然后整理接口文档(本来是开发写的,没办法,为了唬住面试官,先说自己整理了);
-
没有接口文档,可以抓包看接口请求参数,如果有不懂的及时跟开发沟通;
-
还有一些接口请求会保存在数据库中,可以请开发协助。
九、自动化使用的测试框架是什么?
(1) 接口自动化测试采用的框架为(python+unittest+requests+ddt+openpyxl+pymysql+logging):
-
python:入门简单,语法简洁。
-
unittest :定义一个测试用例类,具体的方法来维护测试用例的生命周期,测试场景行为, 测试用例 前置场景,行为,期望结果,实际结果,断言方法,Setup teardown 方法。
-
requests:接口调用 ,支持 http 请求的库,API 简洁,提供不同的 http 请求方法,支持 session,cookies。
-
ddt :数据驱动,ddt 类装饰器,data 测试方法装饰器 unpack 解包可迭代的数据类型。
-
openpyxl:数据管理 excel 管理数据,使用 openpyxl 模块来进行 excel 数据的读和写 (excle,csv, json, yaml, txt 都可以管理测试数据)。
-
pymysql:数据库交互,数据校验。
-
eval,json:数据格式的转换 Eval 将 python 支持的格式转换成对应的格式。
-
logging:日志处理, 统一日志输出格式,渠道,级别,执行结果的记录,便于定位问题。
-
jenkins:持续集成。
(2) 框架设计思路:数据驱动+结构分层(可读性,可维护性,可扩展性)。
-
数据驱动:将维护数据与代码分离,接口调用行为一致,针对不同的参数组合驱动不同的测试场景,减少代码冗余。
-
结构分层:数据层+用例层+逻辑层。
-
数据层:测试数据的支撑 data.xls。
-
用例层:用例的执行 test_register.py test_recharge.py。
-
逻辑层:公用的方法的封装与提取 excle_handler.py mysql_excle_handler.py http_requests.py logger.py 等模块。
(3) 框架设计步骤:
-
准备测试数据:EXCEL 表准备测试用例—excel 数据的读取—参数值的替换 。
-
发起请求:请求方法(get/post 方法进行封装—URL 的拼接)。
-
断言:解析返回值 code,status,msg 信息断言。
(4) 此套测试框架好处:
-
自动化测试用例和手工测试用例的完美结合,减少重复工作;
-
配置灵活,可以自主切换测试环境,执行测试用例;
-
常用功能进行封装,逻辑清晰,易于维护;
-
统一执行入口,管理测试用例集:
-
run.py 模块通过模糊查找来选择需要执行的测试用例;
-
持续集成,定时构建,快速反馈。
…
最后:【自动化面试/视频资源】赠上
-事必有法,然后有成-
公众号:伤心的辣条,获取资源包
完成这样一个体系的构建。可以说,这个过程会让你痛不欲生,但只要你熬过去了。以后的生活就轻松很多。正所谓万事开头难,只要迈出了第一步,你就已经成功了一半,古人说的好“不积跬步,无以至千里。”等到完成之后再回顾这一段路程的时候,你肯定会感慨良多。
公众号:伤心的辣条,专注测试人技术分享。
资源包暗号:资料
事必有法,然后有成。最后祝大家拿到满意的offer ~
如果文章对你有帮助,麻烦伸出发财小手点个赞,感谢您的支持,你的点赞是我持续更新的动力。