【接口测试】基础知识-优快云博客

概念

对系统或组件之间的接口进行测试。校验传递的数据正确性和逻辑依赖关系的正确性！

原理

针对的测试目标 —— 服务器

怎么测：模拟客户端向服务器发请求

用什么测：

工具：fiddler、postman、jmter
代码：python + UnitTest框架 + Requests框架
测什么：测试服务器针对客户端请求，回发的响应数据是否与预期结果一致！
如何判断结果是否一致： 1.人眼对比；2.断言

特点

符合质量控制前移的理念
可以发现一些页面操作发现不了的问题
接口测试低成本高效益（接口可以实现自动化）
接口测试是从用户的角度对系统进行检测

接口自动化的定义

使用工具、代码代替手工，模拟客户端发送请求给服务器，通过断言自动判断预期和实际结果是否一致

HTTP协议超文本传输协议

概念

（HyperText Transfer Protocol）超文本传输协议，是一个基于请求与响应模式的、应用层的协议，也是互联网上应用最为广泛的一种网络协议。

特征

1. 支持客户端、服务器模式

2.简单快捷

3.灵活

4.无状态

5.无连接

URL 统一资源定位符

格式

⁕资源路径：标识网络资源（文件、图片、音视频、变量...）

⁕查询参数：传递给资源路径对应的数据。

http请求

作用：客户端(app、浏览器)，发送请求给服务器时使用的协议 —— http请求协议。

请求行

- http 请求方法：大小写均可。
- GET：查询。 —— 没有请求体
- POST：添加。（登录、添加时常用）
- put: 修改。
- delete: 删除。 —— 没有请求体

请求头：语法格式为键值对

1.User-Agent：描述请求发送端的浏览器类型。
2.Content-Type：描述请求体的数据类型！
- application/json： JSON数据格式
- application/x-www-form-urlencoded： form表单数据

请求体

- GET和DELETE 没有
- PUT 和POST有 - 数据类型受 Content-Type 值影响。

http响应

状态行/响应行

协议版本
状态码：状态码有三位数字组成，第一个数字定义了响应类别

1××：指示信息-表示请求已接收，等待继续处理

2××：成功-表示请求已被成功接收，理解，接受。常见：200、201

3××：重定向-待访问的资源，需求重新指定路径访问。

4xx：代表客户端错误。常见：404、 403 5xx：服务器端错误-服务器未能实现合法的请求。

协议码描述

一般与状态码唯一对应

200-ok； 404- file not found；403-没有权限

响应头

语法格式：k：v

Content-Type：值为响应体的数据类型。

Content-Length: 响应体的大小。可以不写，浏览器会自动求取。一旦写，必须准确

响应体：绝大多数不为空。（请求成功：回发数据，失败：回发错误信息）

传统风格的接口

格式：操作-请求方式-URL-状态码

特点

- 请求方法，只使用 get 和 post 即可。

- URL 不唯一。同一个操作可以对应不同的 URL

- 状态码的使用较单一。200 最常见。

RESTful接口

操作-请求方式-URL-状态码

特点：

1. 每一个URL代表一种资源；

2. 客户端和服务器之间，传递这种资源的某种表现层； - 表现层：资源的不同表现形式（如：图片、文字表现同一个资源对象）

3. 客户端通过四个HTTP动词（GET、post、delete、put），对服务器端资源进行操作，实现"表现层状态转化"；

4. 接口之间传递的数据最常用格式为JSON。

接口测试流程

工作场景

1. 分析需求，产生需求文档（产品）。以下都是测试的工作

2. （开发产生接口文档）解析接口文档。

3. 产生接口测试用例（送审）。

4. 执行测试用例

- 工具：postman、jmeter、fidller

- 代码：python + Requests +UnitTest

5. 提交、跟踪缺陷。

6. 生成测试报告。

7. （可选）接口自动化持续集成！

接口文档

作用

1. 能够让前端开发与后台开发人员更好的配合，提高工作效率。（有一个统一参考的文件）

2. 项目迭代或者项目人员更迭时，方便后期人员查看和维护

3. 方便测试人员进行接口测试

展现形式

- word 文档形式

- Excel 表格式形式

- pdf 文档形式（√）

文档中每个接口信息的结构

基本信息

资源路径（协议和域名在 “系统信息”中）
请求方法
接口描述

请求参数

请求头
- Content-Type。描述请求体的数据类型！
-Authorization：TOKEN。用户登录时会生成唯一标识的令牌，由bearer+空格+{{data}}组成。而TOKEN为令牌名。（每次登录令牌都会变的）

请求体：
- 实现该接口使用的数据及对应类型。

返回数据

状态码（状态行）
错误码（自定义状态码：码值和描述信息）

测试的任务

从文档中提取出HTTP请求报文所需信息，按fiddler工具格式依次填入请求信息，并返回响应信息。比较返回信息和文档中的预期结构是否一致，编写测试报告

接口测试用例

作用

1. 防止测试点漏测。条理清晰

2. 方便分配工作，评估工作量和时间

测试角度

功能性测试

业务场景功能

按照用户实际使用场景，梳理接口业务场景。

组织业务场景时，一般只需做正向测试即可（与手工一致）。

一般建议用最少的用例覆盖最多的业务场景。

单功能：借助工具、代码。绕开前端界面，组织接口所需要的数据，展开接口测试--》手工测试中的单个业务模块，一般对应一个接口。
- 登录业务 ——> 登录接口
- 加入购物车业务 ——> 加入购物车接口
- 订单业务 ——> 订单接口
- 支付业务 ——> 支付接口

性能测试

响应时长
吞吐量
并发数
服务器资源使用率

安全测试

攻击方向-与测试无关
业务安全-测试方向
敏感数据是否加密，如密码
SQL注入

浏览器的开发者工具

可以看到请求，响应报文，以及数据的传输内容

功能性测试用例设计思路

业务场景功能用例设计

以“员工管理“业务场景为例--》员工管理列表；员工的增删改查

正向测试：登录 —— 添加员工 —— 查询员工 —— 修改员工 —— 再次查询 —— 删除员工 —— 查询员工列表

单功能用例设计（测试数值和参数的正确与否）

参数值：和功能测试相同，分别从正向和反向方面测
参数
正向

必选参数：所有的必选（必填）都包含。

组合参数：所有的必选 + 任意一个或多个可选参数。

全部参数：所有的必选 + 所有的可选参数

反向

多参：预期结果为正确，因为后端会自动忽略多余的参数

少参：缺少一个或多个必选参数。

无参：没有必选参数。预计结果为稍等繁忙，而不是用户名或密码错误

错误参数：参数名输入错误。

接口用例字段

编号，用例名，模块，优先级，预设条件，请求方法，URL，请求头，请求体（将请求的数据输入数据库），预设条件（若文档中结果不全，则查看浏览器的开发则工具）

postman接口请求