接口自动化面试题

Hi，大家好，正值“金三银四”升职加薪的黄金季。如果你在公司是加班时的超人，加薪时的隐形人。

面对跳槽机会，你动心吗？假如发展空间受限而此时恰好有很好的机会，积极投入到找工作的新大军不失为当前的一种选择；

今天分享一波接口自动化面试题为你助攻，祝加薪成功！

请求接口中常见的返回状态码

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

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. 各种入参验证（正常情况，异常情况包括输入参数个数不对，类型不对，可选/必选，还有考虑参数有互斥或关联的情况）。
  4. 接口返回值各种验证（符合接口文档需求）。
  5. 了解接口实现逻辑，实现逻辑覆盖（语句/条件/分支/判定/…）。
  6. 接口能并发执行吗、安全吗，性能满足要求吗?
  7. 采用工具或者自写代码来验证。
  8. 发现问题跟功能测试一样，该报 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 的区别可概括为如下几点：

  1. 保存位置。SESSION 数据保存在服务器端，Cookie 数据保存在客户端浏览器
  2. 保存方式。SESSION 默认被存在在服务器的一个文件里，可以手动设置放在文件、数据库、或内存中；Cookie 默认保存在客户端内存中，如果设置了过期时间就保存在硬盘中。
  3. 依赖关系。SESSION 依赖 Cookie 来识别 session_id，如果浏览器禁用了 Cookie，SESSION 也会失效，此时可以通过 url 传递 session_id。
  4. 安全性。因为 SESSION 数据保存在服务端，所以 SESSION 安全性比 Cookie 高。
  5. 尺寸大小。SESSION 基本上没有大小限制，COOKIE 保存的内容比较小，具体由浏览器决定。
  6. 服务器性能。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 模块通过模糊查找来选择需要执行的测试用例；
  • 持续集成，定时构建，快速反馈。


我是 CoCo，计算机科学与技术专业，目前坐标深圳。

我兴趣趣广泛，钟 爱技术。擅长功能测试、接口测试、APP 测试、Web 测试、专项测试、 自动化测试。

熟悉 Python/Java/HTML/CSS/JS 语言，从事过电商项目、 金融项目、音视频项目、新浪微博等项目。

好消息！我在 Boss 直聘开了一个圈子，我会定期分享优质资源、写优质回答和文章，当然如果你想直接问我问题，我也会在这里回复你。

适合对象：测试小白，准测试工程师，Python 自动化测试工程师，Java 自动化测试工程师等，测试开发工程师等。

好消息！好消息！

独学而无友，则孤陋而寡闻，快来加入吧圈子入口

  • 面试题
  • 接口自动化
文章为作者独立观点，不代表BOSS直聘立场。未经账号授权，禁止随意转载。