接口自动化测试基础01- 概念

一、接口测试概述

接口测试是对系统或组件之间的接口进行测试，主要校验数据的交换、传递和控制管理过程，以及相互逻辑依赖关系。 而接口自动化测试是让程序代替人为对接口项目进行自动化验证测试的过程

接口测试的意义：

1. 越底层发现bug，它的修复成本是越低的。

2. 前端随便变，接口测好了，后端不用变。前后端是两拨人开发的。

3. 检查系统的安全性、稳定性，前端传参不可信；

4. 如今的系统复杂度不断上升，传统的测试方法成本急剧增加且测试效率大幅下降，接口测试可以提供 这种情况下的解决方案。

5. 接口测试相对容易实现自动化持续集成，且相对UI自动化也比较稳定，可以减少人工回归测试人力成 本与时间，缩短测试周期，支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。

6. 现在很多系统前后端架构师分离的，从安全层面来说：.

        a. 只依赖前端进行限制已经完全不能满足系统的安全要求（绕过前端实在太容易），需要后端同样进行控制，在这种情 况下就需要从接口层面进行验证。.

        b. 前后端传输、日志打印等信息是否加密传输也是需要验证的，特别是设计到用户的隐式信息，如身份证，银行卡等。

二、HTTP和HTTPS协议

2.1 HTTP请求和响应

*  请求：由客户端发送，用来触发一个服务器上的动作

   请求由三个部分组成：请求行、请求头、请求体

1. 请求行： 位置是在第一行，包含: 请求方式、请求地址 、协议及版本

2. 请求头： 位置是在第一行之后，到空行之前

3. 请求体： 位置是在空行之后，添加用户在接口中定义的接口请求数据。

*  响应：来自服务器的应答

   响应也由三个部分组成：状态行、响应头、响应正文

1. 响应行：位置是在第一行，包含协议及版本、响应状态码、状态消息

2. 响应头：位置是在第一行之后，到空行之前，告诉客户端服务器相关信息，如web服务器类型等

3. 响应体：位置是在空行之后，如登录成功

HTTP请求方法get和post

GET和POST的区别：

(1) GET提交的数据会放在URL之后，以问号(?)分割URL和传输数据，参数之间以&相连，如 EditPosts.aspx?name=test1&id=123456。POST方法是把提交的数据放在HTTP包的Body中。

(2) GET提交的数据大小有限制（因为浏览器对URL的长度有限制），而POST方法提交的数据大小没有限制。

(3) GET方式需要使用 Request.QueryString 来取得变量的值，而 POST 方法通过Request.Form来获取变量的值。

(4) GET方式提交数据会带来安全问题，比如一个登录页面通过 GET 方式提交数据时，用户名和密码将出现在URL上，如果页面可以被缓存或者其他人可以访问这台机器，就可以从历史记录获得该用户的账号和密码。

(5) GET请求只能进行url编码，而POST支持多种编码方式。 对参数的数据类型，GET只接受ASCII字符，而POST没有限制。

一般情况下：get：用于查询，如搜索商品 ; post：用于提交数据，相对比较安全，如登录、注册

三、接口测试流程及用例编写

基本上自动化的目的是为了释放人力，需求分析和用例分析本质上和功能测试是一样的，只是会基于优 先级和提升测试效率的目的，来选择接口自动化用例。

3.1 接口测试流程

1. 拿到接口API文档或者通过抓包工具获取，熟悉接口业务、接口地址、鉴权方式，入参，出参，编码的方式

2. 编写接口用例以及评审

1) 通过性验证： 首先肯定要保证这个接口功能是好使的，也就是正常的通过性测试，按照接口文档上的参数，正常传入，是否 可以返回正确的结果。

2) 参数组合： 现在有一个操作商品的接口，有个字段type，传1的时候代表修改商品，商品id、商品名称、价格有一个是必传 的，type传2的时候是删除商品，商品id是必传的，这样的，就要测参数组合了，type传1的时候，只传商品名 称能不能修改成功，id、名称、价格都传的时候能不能修改成功。

3. 接口安全： 　　

1)绕过验证，比如说购买了一个商品，它的价格是300元，那我在提交订单时候，我把这个商品的价格改 成3元，后端有没有做验证，更狠点，我把钱改成-3，是不是我的余额还要增加？ 　　

2)绕过身份授权，比如说修改商品信息接口，那必须得是卖家才能修改，那我传一个普通用户，能不能修改成功，我传一个其他的卖家能不能修改成功 　　

3)参数是否加密，比如说我登陆的接口，用户名和密码是不是加密，如果不加密的话，别人拦截到你的 请求，就能获取到你的信息了，加密规则是否容易破解　　

4)密码安全规则，密码的复杂程度校验 

4. 异常验证：

参数异常，也就是我不按照你接口文档上的要求输入参数，来验证接口对异常情况的校验。比如说必填的参 数不填，输入整数类型的，传入字符串类型，长度是10的，传11，总之就是你说怎么来，我就不怎么来，其实 也就这三种，必传非必传、参数类型、入参长度。

5. 根据业务逻辑来设计测试用例：

根据业务逻辑来设计的话，就是根据自己系统的业务来设计用例，这个每个公司的业务不一样，就得具体的看自己公司的业务了，其实这也和功能测试设计用例是一样的。

举个例子，拿bbs来说，bbs的需求是这样的：

1)、登录失败5次，就需要等待15分钟之后再登录

2)、新注册的用户需要过了实习期才能发帖

3)、删除帖子扣除积分

4)、 像这样的你就要把这些测试点列出来，然后再去造数据测试对应的测试点。

3. 使用接口测试工具Postman等执行接口测试

4. 使用工具或者自动化框架进行自动化用例覆盖

5. 输出测试报告并且发送邮件

cookie、session、token解析

Cookie：

Cookie 是储存在客户端的一串字符，一般说来大小不超过4kb。比如我们常见的记住密码功能，或者一 些基于之前输入的提醒和默认配置，就是通过Cookie来实现的。

Cookie由服务器生成，发送给浏览器，简单说来就是一种本地存储方法。但是这里存储的信息常用来进行鉴权操作（状态信息）

如果是短期的，那么这些信息会被存储在内存中，如果是长期则会存储在硬 盘上。、

问题：单纯的采用Cookie来认证身份会带来一个比较麻烦的问题，就是伪造比较容易。

原因：因为浏览器把cookie以kv（键值，比如 name:hami）形式保存到客户端上的某个目录下的文本文 件内，下一次请求同一网站时会把该cookie发送给服务器。当然浏览器也加入了一些限制确保cookie不会 被恶意使用，同时不会占据太多磁盘空间，每个域的cookie数量是有限的。虽然这样处理，Cookie中必 然要带有身份信息，服务器也要解析这个身份信息，所以必然要在原理上支持双向的编码和解码，那么 这个信息很容易被破解和进一步伪造。

Session：

 

1. 首先用户登录，server 会为用户生成一个 session，为其分配唯一的 sessionId，这个 sessionId 是与某个用户绑定的，也就是说根据此 sessionid（假设为 abc） 可以查询到它到底是哪个用户，然后将此 sessionid 通过 cookie 传给浏览器
2. 之后浏览器的每次添加购物车请求中只要在 cookie 里带上 sessionId=abc 这一个键值对即可，server 根据 sessionId 找到它对应的用户后，把传过来的商品 id 保存到 server 中对应用户的购物车即可

可以看到通过这种方式再也不需要在 cookie 里传所有的购物车的商品 id 了，大大减轻了请求的负担！

另外通过上文不难观察出cookie是存储在client的，而session保存在server，sessionId 需要借助 cookie 的传递才有意义。

Token：

可以看到 token 主要由三部分组成

1. header：指定了签名算法
2. payload：可以指定用户 id，过期时间等非敏感数据
3. Signature: 签名，server 根据 header 知道它该用哪种签名算法，再用密钥根据此签名算法对 head + payload 生成签名，这样一个 token 就生成了。