接口自动化学习(13)

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

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

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 模块通过模糊查找来选择需要执行的测试用例；

• 持续集成，定时构建，快速反馈。