接口自动化面试题

知识永远学不完，但多懂一点知识就会让生活更轻松一点！

请求接口中返回状态码以如下数字开头：

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：服务器作为网关或代理，从上游服务器收到了无效的响应。

如何做接口测试的？
接口测试实际跟一般功能测试不同就是测试用例的设计部分。接口测试步骤可概括如下：

1. 获取接口文档。 设计接口测试功能用例（主要从用户角度出发看接口能否实现业务需求，用例设计就是黑盒用例那一套）。
2. 各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选，还有考虑参数有互斥或关联的情况）。
3. 接口返回值各种验证（符合接口文档需求）。 了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/…）。

接口能并发执行吗、安全吗，性能满足要求吗?

可以，采用工具或者自写代码来验证。 发现问题跟功能测试一样，该报 bug 报bug，该跟踪状态的跟踪状态。

你平常做接口测试的过程中发现过哪些 bug?
接口测试中发现的 bug 类型有如下几种：

1. 常规错误，接口没实现，没按约定返回结果，边界值处理出错等。
2. 输入异常值（空值、特殊字符、超过约定长度等），接口抛错，没做封装处理；
3. 输入错误的参数、多输入、少输入参数；
4. 接口可能出现的错误，安全性问题，如明文传输、返回结果含有敏感信息，没对用户身份信息做校验，没做恶意请 求拦截等；
5. 性能问题，如接口并发插入多条相同操作，响应时间过长，接口压测出现瓶颈等。

接口测试怎么测？
接口测试可从以下几个方面入手：

1. 通过性验证：首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否可以返回正确的结果。
2. 参数组合：现在有一个操作商品的接口，有个字段 type，传 1 的时候代表修改商品，商品 id、商品名称、价格有一个是必传的，type 传 2 的时候是删除商品， 商品 id 是必传的，这样的，就要测参数组合了，type 传 1 的时候，只传商品名称能不能修改成功，id、名称、价格都传的时候能不能修改成功。
3. 接口安全： 绕过验证，比如说购买了一个商品，它的价格是 300 元，那我在提交订单时候，我把这个商品的价格改成 3 元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？
4. 绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功
5. 参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的请求，就能获取到你的信息了，加密规则是否容易破解。
6. 密码安全规则，密码的复杂程度校验。
7. 异常验证：所谓异常验证，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参数不填，输入整数类型的，传入字符串类型，长度是10 的，传 11，总之就是你说怎么来，我就不怎么来，其实也就这三种，必传非必传、参数类型、入参长度。
8. 性能测试：接口并发情况，如上面提到的：一个账号，同时（大于 2 个请求）对最后一个商品下单，或不同账号，对最后一个商品下单。接口响应时间，响应时间太长了，肯定需要优化，一般都是毫秒级别。
   null

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. 对于账号密码，这种管全局的参数，可以用命令行参数，单独抽出来，写的配置文件里（如 init）；
2. 对于一些一次性消耗的数据，比如注册，每次注册不一样的数，可以用随机函数生成；
3. 对于一个接口有多组测试的参数，可以参数化，数据放yaml,text,json,excel 都可以；
4. 对于可以反复使用的数据，比如订单的各种状态需要造数据的情况，可以放到数据库，每次数据初始化，用完后再清理；
5. 对于邮箱配置的一些参数，可以用 init配置文件；
6. 对于全部是独立的接口项目，可以用数据驱动方式，用 excel/csv管理测试的接口数据；
7. 对于少量的静态数据，比如一个接口的测试数据，也就 2-3 组，可以写到 py 脚本的开头，十年八年都不会变更的；

总之不同的测试数据，可以用不同的文件管理。

没有接口文档，如果做接口测试？
一个公司的开发流程里面，如果接口文档都没有，是无法展开接口测试的，当然，你肯定不能回答面试官不测。可以这样回答：

1. 没有接口文档，那就需要先跟开发沟通，然后整理接口文档（本来是开发写的，没办法，为了唬住面试官，先说自己整理了）；
2. 没有接口文档，可以抓包看接口请求参数，如果有不懂的及时跟开发沟通；
3. 还有一些接口请求会保存在数据库中，可以请开发协助。

自动化使用的测试框架是什么？
(1)接口自动化测试采用的框架为（python+unittest+requests+ddt+openpyxl+pymysql+logging+HTMLTestRunner+jenkins）：

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 模块通过模糊查找来选择需要执行的测试用例；
持续集成，定时构建，快速反馈。

1.最实用的，学习成本低，容易推广的接口自动化测试框架才是最好的东西
2.没有接口文档照样做接口自动化测试，理解业务是重点
3.熟悉某个功能的数据库表结构非常重要