接口测试理论、HTTP协议（URL、HTTP请求、HTTP响应）、接口规范、接口测试流程、API文档接口测试理论HTTP协议接口规范接口测试流程接口文档(API文档)接口测试用例设计

104 阅读 0 评论 69 点赞

我是靠谱客的博主缓慢老师，最近开发中收集的这篇文章主要介绍接口测试理论、HTTP协议（URL、HTTP请求、HTTP响应）、接口规范、接口测试流程、API文档接口测试理论HTTP协议接口规范接口测试流程接口文档(API文档)接口测试用例设计，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

文章目录

接口测试理论
HTTP协议
- HTTP协议介绍
接口规范
接口测试流程
接口文档(API文档)
接口测试用例设计
- 接口测试测试点
- 接口用例设计方法与思路

接口测试理论

接口：
- 分类
  - 硬件接口
  - 软件接口(软件测试讨论的主体)
- 概念：（数据交互的通道）
  - 是指系统或组件之间的交互点，通过这些交互点可以实现数据的交互
接口类型：
- 系统之间的接口：如淘宝系统与支付宝系统
- 系统内部的接口：如淘宝登录系统与订单之间的交互
- 注意：对于测试而言，不需要区分系统之间的接口与系统内部的接口
接口测试：
- 针对接口进行测试，主要是测试数据的传递、交互、控制管理过程以及接口之间的依赖
原理：
- 模拟客户端建立连接
- 发送请求
- 服务器处理请求并响应
- 校验响应数据
特点：
- 测试可以提前介入，修改bug成本低，符合质量前移的理念
- 可以发现一些页面发现不了的问题
- 低成本高效益
- 接口测试不同于单元测试，是站在用户的角度针对整体业务进行测试
实现方式：
- 通过工具实现
  - Postman（当前接口测试阶段学习）
  - Jmeter（后面性能测试阶段学习）
- 通过代码实现
  - Python + Requests
接口自动化测试概念：
- 针对接口进行测试，用工具或代码代替人进行测试的一种活动
提示：概念需要大家理解（切忌死记硬背）

接口测试原理就是模拟客户端发送请求，检查服务器响应
接口测试可以让测试提前接入
接口测试可以发现页面操作发现不了的问题
接口测试比起功能测试低成本、高效益
接口测试从用户角度对系统进行全面检查
接口自动化测试就是让工具或代码代替人工对接口项目进行测试

HTTP协议

HTTP协议介绍

介绍：超文本传输协议，一种互联网上广泛使用的方式
特点：
- 基于客户端与服务器模式
- 简单快速
- 灵活
- 无状态
- 无连接
URL格式解析(重点)
- 说明：统一资源定位符
- 格式：协议、域名端口号、资源路径、参数
  - 示例：http://www.itcast.cn:8080/news/index.html?uid=123&page=1
  - 协议：HTTP、HTTPS、FTP、SMTP、POP3、IMAP等
  - 域名：可以是域名，也可以是ip地址
  - 端口号:默认的端口号可以省略
    - http默认是在80端口
    - https默认是在443
  - 资源路径：
    - 图片、视频、音频、链接、接口等
  - 参数部分：内容不会被系统解析
    - ?：隔离url主题与参数部分的内容
    - &：存在多个参数时，使用&进行拼接
HTTP请求
- 组成：请求行、请求头、请求体
  - 请求行：
    - 位置：第一行信息
    - 内容：
      - 请求方式
      - 资源路径
      - 协议及版本
  - 请求头
    - 位置：第一行之后，空行之前的内容
    - 内容：
      - 主要是以键值对的形式存在
      - 重点掌握：Content-type=application/json
  - 请求体
    - 前提：get请求没有请求体，一般请求体在post和put请求方式中使用
    - 位置：空行之后的内容
    - 内容形式：json、html、text等
请求方式说明
- get：查询数据
- post：新增数据
- put：修改数据
- delete：删除数据
HTTP响应
- 组成：状态行、响应头、响应体
  - 状态行
    - ：位置：第一行信息
    - 内容：
      - 状态码：
        2xx：请求成功
        5xx：服务端存在问题
        4xx：客户端存在问题(401:用户名或密码不对；403：未授权)
        3xx：重定向
  - 响应头：
    - 位置：第一行之后，空行之前的内容
    - 内容：键值对形式存在，用于描述服务器相关信息
  - 响应体
    - 位置：空行之后的内容
    - 响应数据：xml、json、html等

接口规范

传统接口风格(了解)
1. 不同的公司、不同的项目、不同的开发之间开发的接口风格差异很大
2. 请求方式一般只用get和post
3. 响应状态码只用200表示处理成功
RESTful接口风格(规范)
示例：
- URL：协议://域名:端口号/资源路径/{资源集合}/{指定资源}
- 请求方法：get、post、put、delete
- 状态码：200、201、204
重点：
- 请求方法与状态码的对应
  - 查询操作：请求方法【get】响应状态码【200】
  - 新增操作：请求方法【post】响应状态码【201】
  - 修改操作：请求方法【put】响应状态码【201】
  - 删除操作：请求方法【delete】响应状态码【204】

接口测试流程

需求分析
API文档（接口文档）解析
设计测试用例
搭建工具或代码所需环境
搭建项目结构
执行测试用例
使用工具
使用代码
缺陷跟踪与管理
生成测试报告
实现持续集成(可选)

接口文档(API文档)

什么时API文档？
- 接口文档，是一个描述接口信息(请求：请求方式、path、请求参数等；响应：状态码、响应数据等)的文档
为什么要写API文档？
- 便于前端开发和后端开发更好的协作
- 项目更迭或项目人员迭代时，能更好的上手维护
- 便于测试尽早地介入
接口文档
包含的内容如下：
- 编写：开发人员
- 内容：基本信息、请求参数、响应数据
  - 基本信息：接口名称、请求方式、接口地址(path)、接口描述
  - 请求参数：
    - 请求头（headers）
    - 请求体（body）
      - 前提：post和put是有请求体
      - 内容：参数名称、参数类型、是否必填、示例、备注等
  - 响应数据
    - 状态码
    - 响应数据：参数名称、参数类型、是否必填、示例、备注等
      API文档解析

接口测试用例设计

功能测试用例模板
- 用例编号
- 用例标题
- 测试项目
- 用例级别
- 预置条件
- 测试输入
- 执行步骤
- 预期结果

接口测试测试点

功能测试（当前测试的核心重点）
- 单接口测试
- 多接口测试（业务场景测试）
性能测试
安全测试
- 敏感数据是否加密
  - 敏感数据是否遮挡
  - 敏感数据是否可以被复制
  - 敏感数据是需要加密的
  - 敏感数据加密需要一定的难度
- SQL注入
- 其他

接口用例设计方法与思路

单接口测试用例
- 正常测试
  - 全部必填参数
  - 全部参数(必填+非必填)
  - 参数组合(必填+部分非必填)
- 异常测试
  - 数据异常：长度、类型、是否为空、不满足业务(与功能测试一模一样)
  - 参数异常：多参、少参、无参、错误参数等(接口测试新出现的测试点)
  - 业务异常：关注业务上的异常(各种异常状态码测试)
业务场景测试（多接口测试）
- 将多个业务场景涉及的接口进行组合测试
- 注意：接口调用的先后顺序即可
接口测试用例模板
- ID
- 模块
- 用例标题
- 接口名称
- 请求
  - 请求URL(接口地址)
  - 请求方法
  - 请求头
  - 请求数据类型
  - 请求体(请求参数)
- 预期结果(响应)
  - 响应状态码
  - 响应数据