接口测试基础

目录

一、接口及接口测试概念

1、接口

接口的类型

2、接口测试

二、HTTP协议

1、HTTP协议的特点

2、URL格式

3、HTTP请求

4、HTTP响应

三、接口规范

1、传统风格接口

2、RESTful风格接口

四、接口测试流程

1、接口测试流程

2、接口文档解析

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

4、手工测试与接口测试的区别

5、单接口测试（以登录接口用例）

6、业务场景测试

---

学习视频来自于：3天postman接口测试工具视频教程，适合小白观看，高薪必看_哔哩哔哩_bilibili

一、接口及接口测试概念

1、接口

接口是数据交互的通道，在系统或组件之间，完成数据的传递。

接口的类型

按划分形式，大致分为以下三类：

1、按协议分，协议不同，接口类型不同。HTTP、TCP、UDP、IP、FTP、USB....

2、按语言分。Java、Python、PHP、C++....

3、按范围划分，系统之间和程序内部。

• 系统之间：内部系统之间、内部系统和外部系统之间

• 程序之间：方法（函数）和方法（函数）之间、类和类之间、模块和模块之间

#使用接口
def bird():
    something="虫子"
    eat(something)

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

bird()

2、接口测试

概念：测试系统或组件之间交互的数据的正确性，逻辑依赖关系的正确性

接口测试原理：

借助工具、代码模拟客户端向服务器发送请求， 校验服务器回发的响应数据与预期结果是否一致

• 数据（预期结果）来源：用户需求

接口测试的特点

•  接口测试可以提早介入，提前发现bug，符合测试的质量控制前移原则
• 可以发现页面操作发现不了的问题。如：支付密码，输入非数字、特殊字符
• 低成本高收益（接口的一个bug ，可能对应上层界面 N 个bug，接口测试可以实现自动化）
•  不同于传统的单元测试，接口测试站在用户的角度对系统进行全面的测试（用户奇葩的想法在前端页面无法完成，而接口测试可以实现，保证服务器的健壮性）

接口测试的实现方式

• 工具：postman、fiddler、jmeter
• 代码：Python + UnitText框架 + requests框架

什么是自动化接口测试？

利用 工具、代码 代替人工 来判断响应结果与预期结果是否一致（依赖断言）

二、HTTP协议

HTTP协议：（HyperText Transfer Protocol）超文本传输协议。基于请求和响应模式的应用层的协议 。也是目前互联网上广泛使用的一种协议。

1、HTTP协议的特点

• 支持 客户端、服务器模式
• 简单快速 （数据可以直接在URL上携带、传递）
• 灵活（支持的语法格式、数据类型多）
• 无连接（HTTP---B/S，TCP---C/S （C/S连接要3次“握手”，断开连接要4次“挥手”））
• 无状态

2、URL格式

URL：（Uniform Resource Locator）统一资源定位符，是互联网上标准资源的地址。

语法格式：

协议：http 和 https

域名：IP地址

端口号：

• http 协议默认端口：80
• https 协议默认端口：443

资源路径：对应网页的源代码或网络中的一个数据资源。 资源路径可以为空

查询参数：传参给网页源代码。

• 以 ？ 与 资源路径 隔分
• 查询参数可以有多个，之间用 & 隔分。
• 参数参数的语法 k=v 

3、HTTP请求

由客户端发送给服务器；规定了发送给服务器的数据的语法格式

整体格式：http协议由 请求行，请求头，空行，请求体 组成

请求方法：

• POST：新增 ——有请求体（登录、注册主要使用）
• PUT：修改 —— 有请求体
• GET：查询 —— 没有请求体
• DELETE: 删除  —— 没有请求体

协议版本：

• http1.1/http1.2/http2.0 （主要使用 http1.1）

请求头

• 作用：向服务器描述 客户端（浏览器）的基本信息。
• User-Agent：向服务器描述浏览器的类型
• Content-Type：向服务器描述 请求体的数据类型

实践：用Charles抓包验证

Tpshop商城在线网址：http://tpshop-test.itheima.net/

4、HTTP响应

 由服务器回发给客户端；规定了服务器回发给客户端的数据的语法格式

整体格式：

HTTP响应由 响应行（状态行）、响应头、空行、响应体 组成

状态码：针对 http请求，响应的状态

• 1xx： 请求需要进一步访问。
•  2xx：成功。 200 ok
• 3xx： 数据资源需要重定向访问。
• 4xx： 客户端错误。404 Not Found 文件/资源 不存在。 403 Forbidden 文件/资源 拒绝被访问（没有权限）
• 5xx： 服务端错误。

响应体 ：响应体的数据类型，受响应头中 Content-Type 的值影响。 常见的类型：

• json 类型
• 表单 类型
• 图片 类型

三、接口规范

1、传统风格接口

• 使用 GET、POST 实现所有数据的 增删改查操作。
• 针对 用户的某一个操作，URL 不唯一。
• 状态码 统一使用 200

2、RESTful风格接口

• 使用 GET/POST/PUT/DELETE 分别表示 查、增、改、删
• 使用 一个 URL 对应一个唯一的资源。
• 状态码，根据实际操作请求加以区分。

四、接口测试流程

1、接口测试流程

• 需求分析与评审
• 接口文档分析
• 设计测试计划
• 设计接口测试用例并提交评审
• 执行接口测试用例（用工具or代码）
• bug管理与回归
• 生成测试报告
• 接口自动化持续集成（可选）

 什么是接口文档？（由开发人员编写的描述接口相关信息的文档，也叫API文档）

展现形式

• 在线文档 （html）
• 离线文档 （word 、xmind 、pfd 、Excel）

2、接口文档解析

（登录接口为例）

http 请求：

请求行：

• 请求方法：POST
• URL： http://ihrm-test.itheima.net/api/sys/login
• 协议版本：默认 http/1.1

请求头：

• Content-Type : application/json

请求体：

• { “mobile”：“13800000002”, ”password” : ”123456” }

http 应答：

响应行：

• 状态码、状态描述：200 ok

响应头： 无

响应体：

• 第一种情况：{"success":true,"code":10000,"message":"操作成功！","data":"xxx"} 第一种情况
• 第二种情况：{"success":false,"code":20001,"message":"用户名或密码错误","data":null}
• 第三种情况：{"success":false,"code":99999,"message":"抱歉，系统繁忙，请稍后重 试！","data":null}

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

4、手工测试与接口测试的区别

用例设计要点

手工测试：

• 测试页面布局、控件的位置是否精准
• 针对 用户名编辑框中的数据值，展开测试 （正确手机号、手机号有特殊字符、手机号不足11位、手机号超11位、手机号为空...）
• 针对 密码编辑框中的数据值，展开测试 （正确密码、错误密码、密码有特殊字符、密码1位、密码100位、密码为空....）
• 针对 验证码的编辑框中的数据值，展开测试 （正确验证码、错误验证码、过期验证码、验证码为空...）

接口测试：

• 手工页面中的 用户名 编辑框的值，对应 接口中 key 为username 的 value值。针对 username 的值展开测试。
• 手工页面中的 密码 编辑框的值，对应 接口中 key为password 的value值。针对 password 的 value值展开测试。
• 手工页面中的 验证码 编辑框的值，对应 接口中 key为 verify_code的value值。针对verify_code的 value值展开测试。

测试要点 

手工测试，只要测 编辑框中的数据值  

接口测试，除了要 测试参数值 以外，还要对 参数本身 进行测试。

正向：

• 必选参数：只选择所有的必选参数。
• 组合参数：必选参数 与 可选参数，组合测试。
• 全部参数：所有的必选 + 所有 可选

反向：

• 多参：多出 一个或多个 必选参数。
• 少参：缺少必选参数。
• 无参：没有参数。
• 错误参数：修改参数名为 错误名称。

5、单接口测试（以登录接口用例）

手工用例设计八大要素：用例编号、标题、项目描述、优先级、预置条件、测试数据、执行步骤、预期结果

接口测试用例：编号、标题、用例名称、优先级、预置条件、接口名称、测试方法、URL、请求头、请求体（请求数据）、预期结果

（复制粘贴，自己打容易出错） 

单接口用例设计——登录成功

单接口用例设计——用户名相关

单接口用例设计——密码相关

 单接口用例设计——参数相关

6、业务场景测试

业务场景测试用例设计——测试点分析

指导思想：

• 业务场景尽量遵循用户实际使用的场景，按顺序调用接口进行测试。
• 尽量使用最少的测试用例，覆盖最多的业务场景。
• 登录成功 —— 添加员工 —— 查询员工 —— 修改员工 —— 再查询 —— 删除员工 —— 查询 员工列表
• 一般情况下，只需要测试 正向 的业务场景即可！

依赖关系：

• 1. 登录成功返回的 “令牌”， 被 添加、查询、修改、删除 依赖。
• 2. 添加员工成功，返回 员工id， 被 查询、修改、删除 依赖。

业务场景——添加员工

 业务场景——查询、修改员工

业务场景——删除员工、查询员工列表