Python接口测试实战：从基础原理到安全验证全流程解析

山间有风

发布时间：2026-10-16 | 2人浏览过

原创

本文详解利用Python进行接口测试的核心流程。从GET与POST请求的模拟实现入手，深入解析urllib库的使用及Cookie会话保持技术。系统梳理HTTP、RESTful、Web Service等常见接口类型，涵盖Content-Type、状态码及安全验证（Token、签名）等关键知识点，并提供从文档分析到用例执行的完整实践指南。

前言

接口测试相比常规功能测试，逻辑更为直接。当前招聘市场普遍要求候选人具备接口测试经验，不少开发者对此概念存在疑惑。简而言之，接口测试旨在通过构造多样化的入参并验证对应的出参，来判定接口是否满足既定的功能性与安全性标准。

之所以认为接口测试比功能测试更简单，是因为功能测试需涵盖前端UI交互、页面跳转及按钮点击等复杂环节，而接口测试直接基于接口规范文档中的调用地址与请求参数，拼接报文后发送请求并校验返回结果。由于无需处理页面交互，仅需关注入参与出参的逻辑对应，因此操作相对简化。

近期在实施接口测试时，发现原公司方案依赖Postman。受限于网络环境，仅能使用离线版Postman逐一访问冗长的接口列表，效率低下。为此，计划利用Python编写一套自动化测试脚本，配置接口列表后逐条执行并输出详细日志，以提升测试效率。

接口测试的坑

第一个坑：

POST 和 GET----GET一般用于获取/查询资源信息，而POST一般用于更新资源信息|Get是向服务器发索取数据的一种请求，而Post是向服务器提交数据的一种请求。

熟悉接口测试或前端开发的开发者清楚，接口访问方式存在差异，这也是Postman支持设置POST和GET方式的原因。使用Python模拟这两种访问方式是测试的核心。首先介绍GET方式，其实现较为简单：将接口URL直接放入浏览器地址栏并回车即可完成一次GET请求。因此，使用Python访问指定URL即可模拟GET测试。

 import urllib2
 url_save = 'http://www.baidu.com/'
 try:
 s_save = urllib2.urlopen(url_save).read()
print s_save  
except urllib2.HTTPError, e:
 print e.code
 except urllib2.URLError, e:
 print str(e)

如上所示就完成了一次GET请求，调用urllib2库，然后将一个字符串形式的URL传给urllib2.urlopen函数，最后使用read（）方法将GET回来的数据存储起来。

然后说说POST。其实在python的urllib2库中，我们刚刚所使用的urlopen函数还有其他几样不是必选的入参，因为这些入参给定了初始化的值：

def urlopen(url, data=None, timeout=socket._GLOBAL_DEFAULT_TIMEOUT,
 cafile=None, capath=None, cadefault=False, context=None):

如上代码，urllib库有一个很智能的毛病。data不给值，访问方式就是GET，data给了值，方式就会变成POST；所以模拟POST 方式的代码如下：

import urllib 
import urllib2 
url = 'http://www.example.com' 
# values的形式：name：value
values = {'**' : '***', 
          '**' : '***', 
          '**' : '***' } 
#使用urllib.urlencode函数对values字典进行处理，最终形式为：**=***&**=***
data = urllib.urlencode(values) 
#如果对data顺序有要求，建议自己拼接data
req = urllib2.Request(url, data) 
response = urllib2.urlopen(req) 
the_page = response.read()

就像如上代码，把POST方式所需要的数据写到data参数中去，POST方式就模拟成功了。

第二个坑：cookie的使用

用python获取cookie所需要的库叫做cookielib。获取cookie的例子：

# 这里有四种CookieJar，CookieJar是最原始的
cookie_use = cookielib.CookieJar()
 handler = urllib2.HTTPCookieProcessor(cookie_use)
 # 使用绑定好CookieJar的handler创建一个opener
 opener = urllib2.build_opener(handler)
 # 将opener安装到urllib2中
 urllib2.install_opener(opener)
# 使用安装好的urllib2访问某一网站获取cookie
 urllib2.urlopen('https://....../login')
 #这个时候cookie已经被CookieJar获取到了
 print cookie_use

在下一步，将获取到的cookie绑定到opener头中：

'''
  将获取到的cookie绑定到opener，上一步获取的cookie并不满足如下格式，
需要自己进行字符串的切片和拼接 
 '''
opener.addheaders.append(('Cookie', 'name=***&888=888'))

现在的opener就可以用来访问任意需要登录的网站了！

功能:功能实现,实现与设计一致, 接口通过性测试

健壮性: 边界值,容错性
性能: 并发及压测
稳定性: 长期运行的稳定性
安全性: SQL注入, session依赖, 数字签名, http接口的安全性

接口类型

常见接口种类：

Http/Https接口: 通过http/https协议传送接口数据(通常按字符串/二进制传输), 如常见的网页表单, https安全性更好
RESTful Api: REST表述性状态传递. 一种设计风格,基于http/https协议, 把一切接口视为资源, 接口要分版本,在统一的域名下管理, 不同的方法(get/post..)做不同的事,通常请求及响应使用json格式
Web Service: SOAP简单面向对象协议, 基于http实现的一种RPC方案.接口返回一些对象,可以直接通过操作对象,实现我们需要的业务处理.使用xml格式传输数据
RPC接口: RPC为远程方法调用, 有不同的实现方案,基于TCP/Http协议的都有. RPC可以想我们本地导入和调用对象一样使用. Dubbo接口也是一种RPC接口.

常见接口数据类型：

请求数据类型(Content-Type):application/x-www-form-urlencoded: 常规只有文本的网页表单application/json: RESTful Api常用格式, 结构清晰, 含有多层嵌套multipart/form-data: 既有文本,又有上传文件或富文本框的混合数据表单text/xml: xml格式, RPC接口常用格式
响应数据类型string/html: 返回字符串或网页源码json: RESTful Api常用响应格式, 结构清晰xml: RPC接口常用格式

常见接口安全验证方式：

Auth_1.0/Auth_2.0: 通用接口授权方式
Session依赖: 需要登录之后才能进行接口操作
Token验证: 先要使用自己的appid/appsecret通过获取token接口验证身份获取一个token(令牌,有一定有效期), 然后带着token访问接口
数字签名: 将原本的参数按一定规则进行组合,配合时间戳或appsecret, 通过加密算法生成一个签名sign, 携带签名进行接口请求

常见接口请求方法：

GET: 获取资源
POST: 修改资源
PUT: 上传资源
DELETE: 删除资源
HEAD: 只请求页面首部
PATCH: 补丁
OPTIONS: 运行客户端查看服务器性能
......

常见状态码(RESTful规范)：

200系: 成功200 OK - [GET]：获取资源成功201 CREATED - [POST/PUT/PATCH]：创建/修改成功202 Accepted - [*]：任务接受204 NO CONTENT - [DELETE]：删除成功
300系: 重定向301 Moved Permanently: 永久重定向302 Found: 临时重定向
400: 资源错误400 INVALID REQUEST - [POST/PUT/PATCH]：用户请求错误401 Unauthorized - [*]：没有权限(鉴权失败, 接口层)403 Forbidden - [*] 资源禁止访问(服务器层,没有访问权限)404 NOT FOUND - [*]：资源不存在405 Method Not Allowd: 访问的方法不允许, 如用POST访问只支持GET请求的接口406 Not Acceptable - [GET]：用户请求的格式不可得(比如用户请求JSON格式，但是只有XML格式)410 Gone -[GET]：资源被永久删除422 Unprocesable entity - [POST/PUT/PATCH] 当创建对象时，发生验证错误
500系: 服务器内部错误(接口崩溃或有Bug)500 INTERNAL SERVER ERROR - [*]：服务器发生错误

接口业务类型：

返回数据型接口: 只从数据库读取数据
业务操作型接口: 需要写数据库(接口测试需要要涉及参数化或环境清理)

快速上手接口测试

获取接口文档：

Wiki
Word文档
Postman导出
抽象接口定义
接口管理平台

接口文档分析

功能分析: 是否能满足业务(是否缺少某个前端需要的参数), 是否能满足所有业务场景(是否有漏开发接口, 比如只开发了单品接口,没开发套餐接口)
设计分析: 是否有不规范字段(如,nickname, passwd);不规范格式(如,sex,用男,女而不是1,2);是否有易混淆字段(如,amount和total);是否有单词拼错;是否有和数据库字段对应但名称不一样的(易错)
接口分析: 协议类型(http要考虑安全);请求方法(是否规范);请求编码格式(表单/Json/xml, 很多接口文档不声明,导致测试调试不通);接口授权方式;接口业务类型(关系到是否需要做参数化或环境清理); 返回值类型及结构(关系到怎么断言)
接口依赖: 需要什么环境准备和业务场景, 依赖那些接口, 有那些动态数据, 预备环境怎么保障
参数分析: 各个参数的参数类型,组成规则,是否允许不传,是否可以为空, 是否允许多传参
业务分析: 如price字段必须和数据库中的商品的price字段一致,才能校验通过
非功能性: 接口的技术实现方案是否合理, 能否满足高并发的性能要求, 边界值/极限值的处理是否合适, 是否前后端都有数据格式校验等(如精确度为秒级的订单号生成器,在高并发下会导致生成同一订单号的问题)
其他: 如反爬,对headers的一些限制和校验, ip等限制