Elora blog
接口测试
Elora Rinta!
  2024-04-14 11:16:10   2024-04-20 20:43:02    4.4k Words  16 Mins  

接口

接口是系统或组件（组成某个系统的部件之一）之间的交互点，通过这些交互点可以进行数据的交互。

接口的类型

按划分形式，大致分为3类

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

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

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

    1. 系统之间，内部系统之间、内部系统和外部系统之间

    2. 程序内部，方法（函数）和方法（函数）之间、类和类之间、模块和模块之间

接口测试

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

数据是否正确？逻辑依赖关系是否正确？

原理

模拟客户端向服务器发送请求，服务器接受请求后进行相应的业务处理，并向客户端返回响应数据，检查响应数据是否符合预期。

  • 数据（预期结果）
    • 从用户需求来
  • 怎样校验
    • 借助工具、代码模拟客户端，组织数据（没有前端也可以完成）

特点

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

实现方式

  • 使用接口测试工具实现：JMeter、Fiddler、Postman
  • 通过编写代码来实现：Python+Requests+Unittest
  • 依赖断言去判断

HTTP协议

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

特点

  1. 支持客户端/服务器模式
  2. 简单快速
  3. 灵活
  4. 无连接
  5. 无状态

URL

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

URL格式

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

http：协议

www.itcast.cn：域名（ip），定位网络环境中的一台主机

8080：端口号，在网络主机上定位一个应用。没有指定端口号，默认跟随协议。

news/index.html：资源路径，对应网页的源代码或网络中的一个数据资源。

uid=123&page=1：查询参数，可以有多个，用&分割

  • 端口：
    • http协议默认端口：80
    • https协议默认端口：443
    • mysql默认端口：3306
    • redis缓存数据库默认端口：6379
    • Oracle默认端口：1521
  • 资源路径：
    • 资源路径可以为空（没有），相当于”/“
    • 如果没有查询参数，资源路径从域名（端口）之和
    • 如果有查询参数，资源路径为?之前，域名（端口）之和的所有内容
  • 查询参数：传参给网页源代码

HTTP请求

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

由四部分组成：请求行、请求头、空行、请求体

请求行

  • 作用：指定请求方法、请求资源
  • 语法格式：请求方法（空格）URL（空格）协议版本（\n\r）
  • 请求方法：
    • GET：查询，没有请求体
    • POST：新增，有请求体，登录注册主要使用
    • PUT：修改，有请求体
    • DELETE：删除，无请求体
  • URL：数据资源的定位符。协议://域名:端口/资源路径?查询参数&…
  • 协议版本：
    • http1.1/http1.2/http2.0
    • 主要使用http1.1

请求头

  • 作用：向服务器描述客户端（浏览器）的基本信息

  • 语法：k: v

    • User-Agent：向服务器描述浏览器的类型

      Content-Type：向服务器描述请求体的数据类型

请求体

  • GET、DELETE请求方法没有请求体
  • POST、PUT请求方法有请求体
  • 请求体的数据类型，收请求头中的Content-Type的值影响

HTTP相应

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

组成：响应行（状态行）、响应头、空行、响应体。整体称为响应包/响应报文

响应行

  • 语法格式：响应版本（空格）状态码（空格）状态码描述\r\n
  • 协议版本：http1.0/http1.1/http2.0
  • 状态码：针对http请求响应的状态
    • 第一个数字定义了响应的类别
      • 1xx：指示信息，表示请求已接受，继续处理，请求需要进一步访问
        • 100 Continue
        • 101 Switching Protocols
      • 2xx：成功，表示请求已被成功接受、理解、接受
        • 200 OK
        • 201 Created
        • 202 Accepted
        • 203 Non-Authoritative Information
        • 204 No Content
        • 205 Reset Content
        • 206 Partial Content
      • 3xx：重定向，要完成请求必须进行更进一步的操作
        • 300 Multiple Choices
        • 301 Moved Permanently
        • 302 Found
        • 303 See Other
        • 304 Not Modified
        • 305 Use Proxy
        • 307 Temporary Redirect
      • 4xx：客户端错误，请求有语法错误或请求无法实现
        • 400 Bad Request
        • 401 Unauthorized
        • 402 Payment Required
        • 403 Forbidden（请求的文件/资源存在，但是没有访问权限）
        • 404 Not Found（请求的资源/文件不存在）
        • 405 Method Not Allowed
        • 406 Not Acceptable
        • 407 Proxy Authentication Required
        • 408 Request Timeout
        • 409 Conflict
        • 410 Gone
        • 411 Length Required
        • 412 Precondition Failed
        • 413 Request Entity Too Large
        • 414 Request-URI Too Long
        • 415 Unsupported Media Type
        • 416 Requested Range Not Satisfiable
        • 417 Expectation Failed
      • 5xx：服务器端错误，服务器未能实现合法请求
        • 500 Internal Server Error
        • 501 Not Implemented
        • 502 Bad Gateway
        • 503 Service Unavailable
        • 504 Gateway Timeout
        • 505 HTTP Version Not Supported
  • 状态描述：对状态码的说明

响应头

  • 作用：向客户端（浏览器）描述服务器的基本信息

  • 语法：k: v

    Content-Type：向客户端（浏览器）描述响应体的数据类型

响应体

  • http的响应报文大多数有响应体，重定向没有响应体
  • 响应体的数据类型，受响应头中Content-Type的值的影响
  • 常见的类型：
    • json类型
    • 表单类型
    • 图片类型

传统风格接口

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

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

优点：

  • 对开发的技术要求低。只需要GET、POST方法

  • 代码实现灵活

缺点：相同功能的实现代码不唯一

RESTful风格接口

一种软件架构风格、设计风格，不是标准。提供了一组设计原则和约束条件

REST（Representational State Transfer）的缩写，表现层状态转化。如果一个架构符合REST原则，称它为RESTful架构

  • 使用GET/POST/PUT/DELETE分别表示增、查、改、删
  • 使用一个url对应一个唯一的资源
  • 状态码根据实际操作请求加以区分。（实际操作中都返回200，在响应体中描述成功/失败）

界定RESTful风格接口

  1. 请求方法：使用get、post、delete、put对应查、增、删、改
  2. 数据资源的定位符（url）是否唯一
  3. 在url中不使用动词，替换使用名词。结合请求方法，界定具体操作

RESTful架构特点

  1. 每一个URL代表一种资源
  2. 客户端和服务器之间传递这种资源的某种表现层
  3. 客户端通过四个HTTP动词，对服务器端资源进行操作，实现“表现层状态转化：
  4. 接口之间传递的数据最常用的格式为json

接口测试

流程

  1. 需求分析，依据需求文档
  2. 接口文档解析，一般由开发人员编写接口文档
  3. 设计测试用例
  4. 执行测试用例：工具/代码
  5. 接口缺陷管理与跟踪
  6. 生产测试报告
  7. 接口自动化持续集成（可选），一般是项目发布上线前大批量回归测试使用，或者新版本迭代使用

接口文档

又称API文档，一般由开发编写，用来描述系统所提供接口信息的文档。大家都根据这个接口文档进行开发，并需要一直维护和遵守。

作用：

  • 方便前端和后端在开发的时候进行对接
  • 在人员更迭时，方便新人快速接手项目
  • 方便测试人员编写接口测试用例

展现形式

  • 在线文档（html）
  • 离线文档
    • word
    • xmind
    • pdf
    • excel

结构

  • 基本信息：
    • 接口描述
    • URL：（协议+域名）+资源路径
    • 请求方法
  • 请求参数
    • 请求头
    • 请求体（GET、DELETE没有）
  • 返回结果
    • 状态码、状态描述
    • 响应体

接口文档解析

http请求

  • 请求行

    • 请求方法

      URL

      协议版本：默认http/1.1

  • 请求头

    • Content-Type

  • 请求体

http应答：

  • 响应行
    • 状态码、状态描述
  • 响应头
  • 响应体

接口设计用例

  • 为什么写？
    • 防止漏测
    • 管理当前工作进度，评估工作量

接口测试点

功能测试

  • 单接口功能：手工测试中的单个业务模块，一般对应一个接口。借助工具、代码绕开前端界面，组织接口所需要的数据展开接口测试
    • 登录业务–>登录接口
    • 加入购物车业务–>加入购物车接口
    • 登录业务–>登录接口
    • 订单业务–>订单接口
    • 支付业务–>支付接口
  • 业务场景功能：安装用户实际使用场景，梳理接口业务场景。组织业务场景时一般只做正向测试即可（与手工一致）。一般建议用最少的用例覆盖最多的业务场景。
    • 登录——搜索商品——加购物车——下单——支付

性能测试

  • 响应时长
  • 吞吐量：TPS，单位时间内当前接口能处理的事务数
  • 并发数
  • 服务器资源使用率

安全测试

  • 攻击安全：由专业安全测试工程师完成
  • 业务安全
    • 敏感数据是否加密
    • SQL注入

设计方法与思路

与手工设计相同之处

接口用例设计的测试点与手工页面业务功能的测试点几乎完全一样

  • 手工功能测试用例设计要点

    • 测试页面布局、控件的位置是否精准

    • 针对用户名的编辑框中的数据值展开测试

      ​ 正确手机号、手机号由特殊字符、手机不足11位…

      针对密码的编辑框中的数据值展开测试

      ​ 正确密码、错误密码…

      针对验证码的编辑框的数据值展开测试

      ​ 正确验证码、错误验证码…

  • 接口用例设计要点

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

与手工设计不同之处

  1. 手工测试写入到输入框数据是否正确，接口测试测参数对应的参数值是否正确
  2. 不单单只能对参数值进行测试，还针对参数进行测试
    1. 正向参数
      1. 必选参数：所有的必须（必填）都包含
      2. 组合参数：所有的必选+任意一个/多个可选参数
      3. 全部参数：所有的必选+所有的可选参数
    2. 反向参数
      1. 多惨：多出一个/多个必选参数（可以任意指定）
      2. 少参：缺少一个/多个必选参数
      3. 无参：没有必选参数
      4. 错误参数：参数名输入错误

单接口测试用例

手工测试中每个业务功能，在接口测试中就对应唯一的一个接口。针对 该接口展开测试

接口测试用例文档要素：

编号、标题、用例名称、模块、优先级、预置条件、请求方法、URL、请求头、请求体（请求数据）

登录测试点：

  • 数值正向
    • 登录成功
  • 数据反向
    • 手机号为空
    • 手机号有特殊字符
    • 手机号不足11位
    • 手机号超出11位
    • 手机号未注册
    • 密码错误
    • 密码为空
    • 密码有特殊字符
    • 密码1位
    • 密码100位
  • 参数正向
    • 必选参数（全部参数）
  • 参数反向
    • 多参
    • 少参
    • 无参
    • 错误参数

业务场景功能

对应手工测试的业务流程，即接口调用的先后顺序，按照调用顺序展开接口测试。

  • 业务场景尽量遵循用户实际使用的场景，按顺序调用接口进行测试

  • 尽量设计最少的测试用例去覆盖最多的业务场景

    • 登录成功——添加员工——查询员工——修改员工——再查询——删除员工——查询员工列表

  • 一般情况下，只需要测试正向的业务场景即可。

  • 依赖关系：

    • 登录成功返回的token，被添加、查询、修改、删除所依赖
    • 添加员工成功，返回员工id，被查询、修改、删除依赖

Postman用法

管理用例集

Postman断言

Postman的断言使用js编写，写在Tests标签页里。Tests中的脚本在发送请求后执行，会把断言的结果最终显示在TestResults中

断言响应状态码

Status code: Code is 200

1
2
3
4
5
6
7
8
pm.test("Status code is 200", function () {
    pm.response.to.have.status(200);
});
// pm:Postman的一个实例
// test()：Postman实例的一个方法，有两个参数。
	参数1："Status code is 200" 断言完成后给出的提示信息
    参数2：function(){}匿名函数的调用
    pm.response.to.have.status(200);Postman的响应结果中，有状态码200

断言响应体是否包含某个字符

Response body: Contains string

1
2
3
4
5
6
7
8
pm.test("Body matches string", function () {
    pm.expect(pm.response.text()).to.include("string_you_want_to_search");
});
// pm:Postman的一个实例
// test()：Postman实例的一个方法，有两个参数。
	参数1："Body matches string" 断言完成后给出的提示信息
    参数2：function(){}匿名函数的调用
    pm.expect(pm.response.text()).to.include("string_you_want_to_search");Postman实例预期结果包含"string_you_want_to_search"字符串

断言响应体是否等于某个字符串（对象）

Response body: is equal to a string

1
2
3
pm.test("Body is correct", function () {
    pm.response.to.have.body("response_body_string");
});

断言json数据

Response body: JSON value check

1
2
3
4
5
6
7
8
9
pm.test("Your test name", function () {
    var jsonData = pm.response.json();
    pm.expect(jsonData.value).to.eql(100);
});
// var jsonData = pm.response.json();定义变量jsonData，值为json格式的响应体数据
// pm.expect(jsonData.value).to.eql(100);
	value指的是json中的值的key，eql()为对应的值
    value的值对应：success、code、message、data
    to.eql()的值对应：true、10000、"操作成功"、"7ea56147-acf3-4527-a603-060a8ec52f34"

断言响应头

Response headers: Content-Type header check

1
2
3
4
5
pm.test("Content-Type is present", function () {
    pm.response.to.have.header("Content-Type");
});
// pm.response.to.have.header("Content-Type")
	Postman响应结果中响应头有"Content-Type"

增加value

1
2
3
pm.test("Content-Type is present", function () {
    pm.response.to.have.header("Content-Type","application/json;charset=UTF-8");
});

Postman全局变量&环境变量

  • 全局变量：全局唯一的，不可重复定义的变量
  • 环境变量：
    • 一个变量只能属于某个环境，在某一个环境中变量不可重复定义
    • 在环境与环境之间可以定义重复的变量
    • 一个环境可以包含多个环境变量
    • 常见的环境分类：开发环境、测试环境、生产环境

设置变量

全局变量

  1. 手动设置
  2. 代码设置pm.globals.set("var_name",value);

环境变量

  1. 手动设置
  2. 代码设置pm.environment.set("var_name",value);

获取变量值

全局变量

  1. 请求参数（查询参数、请求头、请求体）中获取：
  2. 代码中获取：var value = pm.globals.get("var_name")

环境变量

  1. 请求参数中获取：
  2. 代码中获取：var value = pm.environment.get("var_name")

Postman请求前置脚本

假设一种场景：调某接口时，要输入时间戳（从1970.1.1 00：00：00~写在所经历的秒数），如果输入的时间戳的绝对值超过标准时间10分钟，不允许调用。

请求前置脚本在http请求发送之前会先执行。书写在“Pre-request Script”。在请求发送之前自动运行其中的代码。

携带时间戳向百度服务器发送请求。

内部过程

Postman关联

用来解决接口和接口之间调用的依赖关系，需要借助全局变量、环境变量来实现关联问题

A接口返回的数据供B接口使用：

  1. 组织A接口http请求数据，发送A接口请求
  2. 获取A接口返回的响应数据，写入全局、环境变量中
  3. 组织B接口http请求，从变量中获取A返回的数据

从天气接口获取城市

测试报告

执行测试

使用newman命令，运行导出的测试集脚本，打开cmd输入：

newman run 测试脚本文件 -e 环境变量文件 -d 测试数据文件 -r html --reporter-html-export report.html

接口测试
2024/04/14/接口测试/
Author
Elora
Published
2024-04-14 11:16
License
 Comments
Comment plugin failed to load
Loading comment plugin
  1. 1. 接口
    1. 1.1. 接口的类型
    2. 1.2. 接口测试
    3. 1.3. 原理
    4. 1.4. 特点
    5. 1.5. 实现方式
  2. 2. HTTP协议
    1. 2.1. 特点
    2. 2.2. URL
      1. 2.2.1. URL格式
    3. 2.3. HTTP请求
      1. 2.3.1. 请求行
      2. 2.3.2. 请求头
      3. 2.3.3. 请求体
    4. 2.4. HTTP相应
      1. 2.4.1. 响应行
      2. 2.4.2. 响应头
      3. 2.4.3. 响应体
    5. 2.5. 传统风格接口
    6. 2.6. RESTful风格接口
      1. 2.6.1. 界定RESTful风格接口
      2. 2.6.2. RESTful架构特点
  3. 3. 接口测试
    1. 3.1. 流程
    2. 3.2. 接口文档
      1. 3.2.1. 展现形式
      2. 3.2.2. 结构
      3. 3.2.3. 接口文档解析
  4. 4. 接口设计用例
    1. 4.1. 接口测试点
      1. 4.1.1. 功能测试
      2. 4.1.2. 性能测试
      3. 4.1.3. 安全测试
    2. 4.2. 设计方法与思路
      1. 4.2.1. 与手工设计相同之处
      2. 4.2.2. 与手工设计不同之处
      3. 4.2.3. 单接口测试用例
      4. 4.2.4. 业务场景功能
  5. 5. Postman用法
    1. 5.1. 管理用例集
    2. 5.2. Postman断言
      1. 5.2.1. 断言响应状态码
      2. 5.2.2. 断言响应体是否包含某个字符
      3. 5.2.3. 断言响应体是否等于某个字符串（对象）
      4. 5.2.4. 断言json数据
      5. 5.2.5. 断言响应头
    3. 5.3. Postman全局变量&环境变量
    4. 5.4. 设置变量
      1. 5.4.1. 全局变量
      2. 5.4.2. 环境变量
    5. 5.5. 获取变量值
      1. 5.5.1. 全局变量
      2. 5.5.2. 环境变量
    6. 5.6. Postman请求前置脚本
    7. 5.7. Postman关联
  6. 6. 测试报告
    1. 6.1. 执行测试
© 2020 - 2024    Elora
Powered by Hexo & Theme Keep
This site is deployed on
Total words 75.1k Unique Visitor Page View
  1. 1. 接口
    1. 1.1. 接口的类型
    2. 1.2. 接口测试
    3. 1.3. 原理
    4. 1.4. 特点
    5. 1.5. 实现方式
  2. 2. HTTP协议
    1. 2.1. 特点
    2. 2.2. URL
      1. 2.2.1. URL格式
    3. 2.3. HTTP请求
      1. 2.3.1. 请求行
      2. 2.3.2. 请求头
      3. 2.3.3. 请求体
    4. 2.4. HTTP相应
      1. 2.4.1. 响应行
      2. 2.4.2. 响应头
      3. 2.4.3. 响应体
    5. 2.5. 传统风格接口
    6. 2.6. RESTful风格接口
      1. 2.6.1. 界定RESTful风格接口
      2. 2.6.2. RESTful架构特点
  3. 3. 接口测试
    1. 3.1. 流程
    2. 3.2. 接口文档
      1. 3.2.1. 展现形式
      2. 3.2.2. 结构
      3. 3.2.3. 接口文档解析
  4. 4. 接口设计用例
    1. 4.1. 接口测试点
      1. 4.1.1. 功能测试
      2. 4.1.2. 性能测试
      3. 4.1.3. 安全测试
    2. 4.2. 设计方法与思路
      1. 4.2.1. 与手工设计相同之处
      2. 4.2.2. 与手工设计不同之处
      3. 4.2.3. 单接口测试用例
      4. 4.2.4. 业务场景功能
  5. 5. Postman用法
    1. 5.1. 管理用例集
    2. 5.2. Postman断言
      1. 5.2.1. 断言响应状态码
      2. 5.2.2. 断言响应体是否包含某个字符
      3. 5.2.3. 断言响应体是否等于某个字符串（对象）
      4. 5.2.4. 断言json数据
      5. 5.2.5. 断言响应头
    3. 5.3. Postman全局变量&环境变量
    4. 5.4. 设置变量
      1. 5.4.1. 全局变量
      2. 5.4.2. 环境变量
    5. 5.5. 获取变量值
      1. 5.5.1. 全局变量
      2. 5.5.2. 环境变量
    6. 5.6. Postman请求前置脚本
    7. 5.7. Postman关联
  6. 6. 测试报告
    1. 6.1. 执行测试