接口测试基础学习

1.接口

概念：指系统或组件之间的交互点，通过这些交互点可以实现数据的交互。（系统与系统之间、组件与组件之间，数据传递交互的通道）

接口的类型

按协议划分：HTTP、TCP、IP
按语言划分：C++、java、php…
按照范围划分：系统之间的接口和程序内部的接口

• 系统之间的接口：多个内部系统之间的交互，内部系统与外部系统之间的交互
• 程序内部的接口：方法与方法之间，函数与函数之间，模块与模块之间的交互

# 接口
def eat(something):
	print(f'小鸟在吃{something}')

# 使用接口，传递数据
def bird():
	eat('虫子')

bird()

2.接口测试

接口测试：是对系统或组件之间的接口进行测试，主要是校验数据的交换、传递和控制管理过程，以及相互逻辑依赖关系

2.1 接口测试原理

接口测试，主要针对的测试目标 – 服务器
模拟客户端向服务器发送请求，服务器接收请求后进行相应的业务处理，并向客户端返回响应数据，检查响应数据是否符合预期。

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

用什么测？

• 工具：fiddler、Postman、JMeter
• 代码：Python+UnitTest框架+Requests框架

测什么？
测试 服务器针对客户端请求，回发的响应数据是否与预期结果一致----人眼对比、断言

2.2 接口测试的特点

• 接口测试可以提前介入，提早发现Bug，符合质量控制前移的理念
• 可以发现一些页面操作发现不了的问题
• 接口测试低成本高效益（底层的一个Bug能够引发上层8个左右Bug，接口测试可以实现自动化）
• 不同于传统的单元测试，接口测试是从用户的角度对系统进行全面的检测

2.3.接口自动化测试

借助工具、代码，模拟客户端向服务器发生请求，借助断言自动判断 预期结果和实际结果是否一致！

3.HTTP协议

协议：就是规则 要求通信的双方必须严格遵守！

HTTP协议介绍

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

IP：在网络环境中唯一标识一台主机
TCP：端口 唯一找到一个应用

HTTP协议特点

• 支持客户端/服务器（C/S）模式
• 简单快速
• 灵活
• 无连接：IP+端口
• 无状态

URL

URL：（Uniform Resource Locator）统一资源定位符，是互联网上标准资源的地址。HTTP使用URL来建立连接和传输数据。（在网络环境中，唯一的定义一个数据资源）

⭐URL格式

http://www.itcast.cn:8080/news/index.html?uid=123&page=1

• 协议：”http“，常见的协议有HTTP，HTTPS、FTP等，规定数据传输的方式
• 域名（IP）：”www.itcast.cn“，也可使用IP地址作为域名使用，在网络环境中 唯一标识一台主机 – 用 ：//与协议隔分
• 端口 port：”8080“，端口可以省略，默认端口（HTTP:80，HTTPS:443），范围（0~65535），在网络主机上 唯一标识一个进程（运行起来的应用程序） – 用 : 与域名隔分
• 资源路径：”/news/index.html“，标识网络资源（文件、图片、音视频、变量等） – 用 / 与端口隔分
• 查询参数：”uid=123&page=1“，可以允许有多个参数，多个参数之间用&连接（键值对形式 k=v），传递给资源路径对应的数据 – 用 ？与资源路径隔分

HTTP请求

称呼方式：http请求包 or http请求报文
客户端（app、浏览器），发送请求给服务器时，使用的协议–http请求协议。
作用：规定 发送给服务器的数据传输的语法格式。

⭐整体格式

• 请求行：http请求第一行。请求方法 （空格） URL （空格） 协议版本（HTTP/1.1）
• 请求头：语法格式：K:V 键值对组织数据 User-Agent：描述 请求发送端的 浏览器类型；Content-Type：描述 请求体的数据类型
• 空行：代表HTTP请求头结束
• 请求体：请求发送时携带的数据。数据类型受 Content-Type 的值影响 post和put有请求体，get和delete没有请求体

http请求方法：

• GET：查询
• POST：添加 （常用在登录）
• PUT：修改
• DELETE：删除

Content-Type：请求体的数据类型，常见类型：

• text/html：HTML格式
• text/plain：纯文本格式
• image/jpeg：jpg图片格式
• application/json：JSON数据格式
• application/x-www-form-urlencoded：form表单数据被编码为key/value格式发送到服务器
• multipart/form-data：在表单中进行文件上传时使用

fiddler抓包验证

准备好网址，先把fiddler抓包工具清空一下，然后发送请求，第一条选择Raw

使用fiddler抓包工具访问www.jd.com

HTTP响应

称呼方式：http响应包 or http响应报文
服务器端，针对客户端发送的http请求，回发响应数据。–http应答
作用：规定 回发给客户端的数据组织格式

⭐整体格式

• 响应行（状态行）：协议版本 状态码 状态描述
• 响应头：语法格式：K:V Content-Type：响应体的数据类型；Content-Length：响应体的大小，可以不写，浏览器自动求取，一旦写，必须准确
• 空行：代表响应头结束
• 响应体：绝大多数不为空，回发给客户端的数据（请求成功：回发数据，请求成功：回发错误信息），数据类型受 Content-Type 值影响，常见的有html网页、XML、JSON。在测试中，就是“实际结果”

状态码：由三位数字组成，第一个数字定义了响应的类别

• 1xx：指示信息–表示请求已接收，继续处理
• 2xx：成功–表示请求已被成功接收、处理 常见：200、201
• 3xx：重定向–要完成请求必须进行更进一步的操作
• 4xx：客户端错误–请求有语法错误或请求无法实现 常见：404（请求文件不存在）、403（请求文件存在，无访问权限）
• 5xx：服务端错误–服务器未能实现合法的请求

状态码描述：一般与状态码 唯一对应。200–ok；404-- file Not Found

传统接口风格

对用户进行操作的相关接口，包括增删改查。
特点：

• 请求方法，只使用get和post
• URL不唯一，同一个操作可以对应不同的URL
• 状态码的使用较单一，200最常见

RESTful接口风格

一种软件架构风格、设计风格，而不是标准，只是提供了一组设计原则和约束条件。
REST：即（Representational State Transfer）的缩写，译为“表现层状态转化”。如果一个架构符合REST原则，就称它为RESTful架构。

特点：

• 每一个URL代表一种资源
• 客户端和服务器之间，传递这种资源的某种表现层。表现层：数据的不同表现形式（如：图片、文字表现同一个数据对象 ）
• 客户端通过四个HTTP动词（get、post、put、delete），对服务端资源进行操作，实现“表现层状态转化”
• 接口之间传递的数据最常用的格式为JSON

接口测试流程

1、需求分析：产品经理—需求文档
2、接口文档解析：一般由开发人员编写接口文档（API文档）
3、设计接口测试用例（送审）：根据接口文档
4、执行测试用例：接口测试工具（fiddler、postman、jmeter）、代码（python+Requests+Unittest）
5、接口缺陷管理与跟踪（提交、跟踪缺陷）
6、生成测试报告
7、接口自动化持续集成（可选）

接口文档

又称API文档，一般由开发人员编写，描述接口信息的文档。开发团队按接口文档进行开发工作，并要一直维护遵守。
作用：

• 能够让前端开发人员与后台人员更好的配合，提高工作效率
• 项目迭代或者项目人员更迭时，方便后期人员查看和维护
• 方便测试人员进行接口测试

展现形式：

• word 文档形式
• excel 表格形式
• pdf 文档形式

⭐结构：

• 基本信息：资源路径（协议和域名在“系统信息”中）、请求方法、接口描述
• 请求参数：请求头（Content-Type：描述请求体的数据类型）、请求体（实现该接口使用的 数据及对应类型）
• 返回数据：操作成功响应状态码 200、错误码（码值、描述信息）

接口文档解析

接口文档解析本质：从接口文档中，找出 http请求所需要的 数据信息，对应响应结果的 预期结果，主要包括：请求方法、URL、请求头、请求体、响应状态码、描述信息

fiddler操作 – 先点击composer，依次填入 请求方法、URL、请求头、请求体

接口用例设计

为什么写？
1）防止测试点漏测，条理清晰
2）方便分配工作，评估工作量和时间

接口测试的测试点（测试维度）

浏览器的开发者工具

功能测试

单接口功能

手工测试中的单个业务模块，一般对应一个接口。
借助工具、代码，绕开前端界面，组织接口所需要的数据，展开测试。

• 登录业务 —>登录接口
• 加入购物车业务 —>加入购物车接口
• 订单业务 —>订单接口
• 支付业务 —>支付接口

业务场景功能

按照用户实际使用场景，梳理 接口业务 场景。
组织业务场景时，一般只需做 正向 测试即可（与手工一致）。
一般建议用最少的 用例 覆盖最多的业务场景：

• 登录 – 搜索商品 – 加购物车 – 下单 – 支付 – 评价

性能测试

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

安全测试

攻击安全：由专业安全测试工程师完成
业务安全：

• 敏感数据是否加密
• SQL注入
• 其他

⭐接口测试用例设计方法与思路

与手工设计相同之处

手工测试对应的功能测试点，与接口测试对应的功能完全一致。
针对每个输入框，对应参数值（正向、反向）

与手工设计不同之处

（1）手工测试，测写入到输入框中的数据是否正确；接口测试 测参数对应的参数值是否正确
（2）接口测试，不单单针对 参数值（eg：具体手机号值） 进行测试，还可以针对 参数本身（eg：username）进行测试

a.正向参数：

• 必选参数：所有的必选（填）都包含
• 组合参数：所有的必选+任意一个或多个 可选参数
• 全部参数：所有的必选+所有的 可选参数

b.反向参数：

• 多参：多出一个或多个 必选参数（可以任意指定）
• 少参：缺少一个或多个 必选参数
• 无参：没有 必选参数
• 错误参数：参数名 输入错误

单接口测试用例

手工 测试用例文档 8大要素：
编号、用例名称（标题）、模块、优先级、预置条件、测试数据、操作步骤、预期结果
接口 测试用例文档 10要素：
编号、用例名称（标题）、模块、优先级、预置条件、请求方法、URL、请求头、请求体（请求数据）、预期结果

⭐登录接口

登录模块的接口测试用例测试点：
（1）数值
正向：登录成功
反向：

（2）参数（接口测试特有）
正向：

反向：

业务场景测试用例

用户怎么用，怎样设计业务
用最少的测试用例，尽量覆盖最多的接口

分析测试点

针对“员工管理”业务场景：

• 登录–添加员工–查询一个员工–修改员工–再次查询–删除员工–查询员工列表

员工添加

分析接口文档

• 请求方法：post

• URL：{协议+域名}/api/sys/user

• 请求头：Content-Type：application/json；Authorization：Bearer f5…（具体数据来源 登录成功返回的 响应体中的data值）

• 请求体（请求数据）
  

• 预期结果：状态码：200；
  

Body

员工查询

解析接口文档

• 请求方法：get
• URL：{协议+域名}/api/sys/user/:target
• 请求头：Content-Type：application/json；Authorization：Bearer f5…（具体数据来源 登录成功返回的 响应体中的data值）
• 请求体：无
• 返回数据：状态码：200；{“success”:true, “code”:10000, “message”:“操作成功！”, “data”:“所查询的员工的详细信息”}

员工修改

返回数据中的id，代表 修改员工的id（是一个会变化的数据）

员工删除

查询员工列表