一天上手接口自动化：Python+Requests+Pytest实战指南

1. 为什么我用一天就能让你上手接口自动化

先说实话：网上讲接口自动化的教程多到能堆满一个书架，但大部分人看完还是不会写。原因很简单——教程把简单的东西讲复杂了。什么框架分层、数据驱动、关键字驱动、pytest插件体系，一套组合拳下来，新手直接劝退。

我的做法不一样。我带过十几个从零基础转到测试开发的人，总结出一条规律：只要抓住请求构造、断言设计、数据管理、报告输出这四根柱子，接口自动化当天就能跑起来。剩下的全是优化，不是必需品。

先说清楚这篇文章能帮你搞定什么：你会用Python写出一套能实际跑通的接口自动化脚本，从最简单的单接口验证，到多接口串联、依赖数据传递、测试报告生成，全部手把手过一遍。学完你就能直接接到公司项目里用，而不是停留在"看过教程但写不出来"的状态。

这篇文章适合谁？三种人：

• 手工测试做了几年，想转自动化但一直没找到切入点的
• 会用Postman调接口，但不知道怎么把用例沉淀成代码的
• 刚入行不久，简历上写着"熟悉接口自动化"，实际心里发虚的

一天时间怎么分配？上午两小时搞定环境准备和Requests库核心用法，这两件事是地基。中间三小时死磕断言设计和数据参数化，这是接口自动化真正的灵魂——大部分人的脚本挂在公司项目上，不是请求写错了，而是断言太弱、数据写死。下午两小时搞定pytest组织和报告生成。最后留一小时，我带你把最常见的坑全部踩一遍。

这种节奏不是我拍脑袋定的。接口自动化的学习曲线有个特点：前期环境安装和Requests上手非常顺，真正劝退人的是中期的断言设计和后期pytest工程化。所以我把重点压在中间，你跟着走完一遍之后，回头看会发现所有东西都串起来了。

还有一点得说实话：网上那些卖课的动不动就"两周精通"，真没必要。接口自动化的核心就那点东西，比UI自动化简单太多了。没有浏览器驱动、没有元素定位、没有等待策略，本质就是"发请求、验响应"，只要你想明白这两件事，一天真的够用。剩下的事情——封装、CI集成、数据隔离——都是在实战里慢慢加的，不是第一天就该背下来的东西。

2. 环境准备最容易翻车的三个细节

2.1 Python版本和安装路径，别在这种小事上卡壳

如果你还没装Python，直接去官网下载3.10或3.11的稳定版，别追新，也别用老掉牙的2.x。这里有个最常见的坑：安装的时候Windows用户一定要勾选"Add Python to PATH"，我见过太多人栽在这上面，装完了在命令行敲python直接弹Microsoft Store，就是因为没勾这个选项。

装完验证一下，命令行执行：

python --version pip --version

两个都能正常输出版本号，说明环境没问题。如果python命令报错，试试python3，Mac和Linux用户经常遇到这种别名问题。再不行就把Python的Scripts目录加到环境变量里去。

然后是虚拟环境。这一步很多人嫌麻烦跳过，结果就是项目依赖一团乱麻。我建议直接从第一天就用虚拟环境，养成习惯：

# 创建虚拟环境 python -m venv venv # Windows激活 venv\Scripts\activate # Mac/Linux激活 source venv/bin/activate

看到命令行前面多了个(venv)就说明激活成功了。在这个环境里装的东西不会污染全局，换项目也不怕依赖冲突。

2.2 编辑器选VS Code还是PyCharm，我推荐你听我的

编辑器这块我不搞"都行"那套暧昧态度。新手和追求轻量的人直接用VS Code，装一个Python扩展就够了，启动快、配置简单，写接口自动化脚本绰绰有余。PyCharm虽然强大，但社区版够用、专业版收费，而且对老电脑来说启动是真的慢，没必要第一天就把性能消耗在这种地方。

VS Code装完Python扩展后，记得选一下解释器：按Ctrl+Shift+P输入"Python: Select Interpreter"，选你刚建好的虚拟环境。这步不做，你后面装了一堆库但代码里import全标红，还以为自己装错了。

当然，写代码不是重点，重点是能跑。VS Code里配置好之后直接右键Run Python File就能看到输出，效率够用。

2.3 Requests库和pytest，先装上再聊别的

接口自动化最核心的两个库是requests和pytest。一个管发请求，一个管组织用例。验证性安装：

pip install requests pytest pytest-html

看到Successfully installed就完事了。这里插一句，pytest-html用来生成报告，后面会用到，现在一起装好省得再跑一遍。

装完可以做个烟雾测试，命令行进入Python交互模式：

import requests import pytest print(requests.__version__) print(pytest.__version__)

不报错就说明环境全通了。到这里，你其实已经完成了第一天任务的十分之一——剩下的全是写代码。

3. Requests发请求的核心套路，翻来覆去就这几个方法

3.1 GET和POST单独拎出来说，因为日常用的就这俩

接口自动化里90%的请求是GET和POST。GET从语义上是查数据，POST在语义上是提交数据，但实际工作中很多项目不讲究RESTful规范，GET和POST乱用的情况太常见了。所以你别纠结语义，按接口文档写就行。

GET请求的最简形式：

import requests resp = requests.get("https://httpbin.org/get", params={"key": "value"}) print(resp.status_code) print(resp.text)

POST请求的最简形式：

import requests resp = requests.post( "https://httpbin.org/post", json={"username": "admin", "password": "123456"} ) print(resp.status_code) print(resp.json())

两段代码放在一起对比，你会发现结构完全一样：方法名对应HTTP动词，第一个参数是URL，第二个参数传参。requests库最大的特点就是把HTTP请求封装得极其简单，你不需要关心底层的socket连接和HTTP报文拼装，传参进去它自己搞定。

这里面有个细节值得注意：json参数和data参数的区别。传json={"name": "tk"},requests会自动把字典转成JSON字符串，并且设置Content-Type: application/json。传data={"name": "tk"}，表单编码是application/x-www-form-urlencoded。很多后端要求特定的Content-Type，接错了直接返回415或400，排查半天才发现问题出在这。

3.2 响应对象的五个属性，背下来能少走一半弯路

requests发完请求后返回的response对象，日常用的属性就五个：

实际断言用得最多的是resp.json()。比如响应长这样：

{"code": 0, "message": "success", "data": {"token": "abc123", "userId": 10001}}

你直接：

data = resp.json() assert data["code"] == 0 assert data["data"]["token"] != ""

这比解析一整个字符串快得多，也直观得多。字段多层级嵌套的时候，写几个变量存中间值，别一个表达式套到底，那样出了问题很难定位。

3.3 Session会话保持，处理Cookie登录态的正确姿势

有些接口需要登录后才能调，登录成功会返回一个Cookie或Token。新手最常见的做法是每次请求都把Token手动粘进去，用是能用，但一旦Token过期就要重新拷贝，烦得很。

正确的方式是用requests.Session()：

session = requests.Session() # 登录，Session会自动保存服务端下发的Cookie resp = session.post("https://api.example.com/login", json={"username": "admin", "password": "123456"}) print(resp.json()) # 后续请求直接复用session，Cookie自动带上 resp2 = session.get("https://api.example.com/user/info") print(resp2.json())

Session对象会自动管理Cookie，同一个Session发出去的所有请求都会自动带上之前保存的Cookie，这就跟你在浏览器里登录之后继续操作一个道理。需要手动加Token的接口，也可以通过设置默认请求头来解决：

session.headers.update({"Authorization": "Bearer " + token})

设置一次，后续这个Session的所有请求都会自动带上这行Header，不用每个请求手动传。

4. 断言设计才是接口自动化的分水岭，别再只验状态码了

4.1 为什么"状态码等于200"是最弱的断言

我见过太多人写的断言长这样：

assert resp.status_code == 200

这条断言有意义吗？有，但极其有限。HTTP 200只能说明服务器响应了请求，不代表业务正确。很多系统里因为各种原因，业务失败也会返回200。比如一个查询接口，用户不存在时返回HTTP 200但body里code=10001、message="用户不存在"，如果你只断言状态码，这用例永远都是绿的——自动化测试全绿但上线照样出Bug，这类事八成就是这么来的。

测试断言的核心原则：你关心的不是"请求有没有成功"，而是"业务有没有做对"。所以断言至少要分两层：

• 第一层：HTTP层——状态码对不对、响应头对不对
• 第二层：业务层——业务码对不对、关键字段值对不对、数据结构对不对

4.2 三层断言体系的搭建思路，照着抄就行

我在实际项目里总结了一套三层断言体系，不复杂，但覆盖面够广，你直接用：

第一层：状态码断言

assert resp.status_code == 200, f"预期状态码200，实际{resp.status_code}"

这层用来发现网络层和服务端的明显错误，比如500、502、401这种，一眼就能定位是环境问题还是权限问题。

第二层：业务码断言

body = resp.json() assert body["code"] == 0, f"业务失败: {body['message']}"

这层用来验证业务逻辑。大多数公司自己的接口会封装统一的返回格式，code=0表示成功，非0表示失败。这层断言能拦住大部分业务逻辑错误。

第三层：关键业务字段断言

assert body["data"]["userName"] == "test_user" assert body["data"]["userAge"] >= 18

这层直接验证核心数据正确性。比如下订单接口，你要断言订单金额算得对不对；注册接口，你要断言用户角色给得对不对。字段层断言通常需要结合需求文档来写，也是你用例价值的真正体现。

再补一个技巧：每条断言的后面尽量加上失败提示，用逗号隔开字符串就行：

assert body["data"]["status"] == 1, f"用户状态异常: {body['data']['status']}"

这样用例跑挂了，你能直接从报错信息知道是哪里出了问题，不用打开日志翻半天。

4.3 列表和嵌套数据的断言，两个小妙招搞定

接口返回数据经常是一长串列表，比如订单列表、用户列表。对列表做断言时，最简单的思路是验证列表长度和关键元素是否存在：

orders = body["data"]["list"] assert len(orders) > 0, "订单列表为空" # 验证列表里是否包含特定订单号 order_ids = [o["orderId"] for o in orders] assert "ORD20240001" in order_ids

这里的第二招用到了Python的列表推导式，把列表里的某个字段抽出来生成一个新列表，然后直接判断目标值在不在里面。这个写法比循环加标志位的做法简洁得多。

嵌套数据也没多难，核心思路就是一层一层往下拆，用临时变量存中间值：

user_info = body["data"]["userInfo"] address = user_info["address"] assert address["city"] == "上海" assert address["district"] == "浦东新区"

写断言的时候千万别一个超长表达式套到底，报错了你根本看不出哪个字段出了问题。拆成临时变量还有个好处，后面想复用这个值做数据传递也方便。

5. 数据驱动和用例参数化，把写死的脚本变成真正能复用的自动化用例

5.1 为什么硬编码数据是接口自动化里最让人头疼的事

第一版脚本跑通之后，你很快会遇到一个尴尬场景：接口测试数据是写死的，比如用户名、手机号、商品ID都是固定值。代码本身没毛病，但一换环境、一换测试数据，脚本立刻跑不起来。更头疼的是——你要测"同一个接口、十组不同测试数据"的时候，难道复制粘贴十份代码吗？

这就引出了接口自动化第二个核心能力：数据驱动。本质上就一句话——把测试数据和测试代码分离。数据放在外部，代码只负责"怎么发请求、怎么断言"，数据变了代码不用动。

5.2 pytest参数化的标准用法，几十行代码省出几百行

pytest的@pytest.mark.parametrize装饰器就是干这个的。用法非常直白：

import pytest import requests # 定义测试数据和对应的预期结果 test_data = [ ("user1", "pass1", 0, "success"), ("user2", "wrongpass", 10001, "用户名或密码错误"), ] @pytest.mark.parametrize("username,password,exp_code,exp_msg", test_data) def test_login(username, password, exp_code, exp_msg): resp = requests.post("https://api.example.com/login", json={"username": username, "password": password}) body = resp.json() assert body["code"] == exp_code assert body["message"] == exp_msg

pytest会自动把test_data里的每一组数据当成一条独立用例来执行，跑的时候你能清楚看到哪组数据过了、哪组挂了。这样做有三大好处：

• 用例代码只写一份，数据想加多少组就加多少组
• 用例之间数据完全隔离，互不干扰
• 跑挂的时候报错信息直接显示是哪组数据出了问题

5.3 从Excel或JSON读测试数据，搭建一个小型数据驱动框架

参数化写在代码里已经比硬编码好了，但测试数据和管理人员还是隔了一层。更进一步的做法是把数据放到外部文件，用代码读进来。

项目大了之后，测试数据经常由产品、开发或测试经理提供，他们不会去改你的Python代码。这时候用JSON或Excel管理数据更合适。我推荐用JSON，结构清晰、支持嵌套，Python标准库直接就能解析：

[ { "username": "user1", "password": "pass1", "exp_code": 0, "exp_msg": "success" }, { "username": "user2", "password": "wrongpass", "exp_code": 10001, "exp_msg": "用户名或密码错误" } ]

对应的读取方式：

import json import pytest import requests def load_test_data(): with open("test_data.json", "r", encoding="utf-8") as f: return json.load(f) @pytest.mark.parametrize("case", load_test_data()) def test_login(case): resp = requests.post("https://api.example.com/login", json={"username": case["username"], "password": case["password"]}) body = resp.json() assert body["code"] == case["exp_code"] assert body["message"] == case["exp_msg"]

从一个参数变一个字典，代码立刻灵活很多。以后测试数据要改，直接找测试人员改JSON文件就行，代码层一行都不用动。

5.4 接口间数据传递，Token提取后如何传递给下一个接口

接口自动化里比参数化更绕不开的，是接口间的数据依赖。最典型的场景：登录拿到Token，查订单要用Token；创建订单拿到订单ID，查订单详情要用订单ID。

我的做法是用pytest的fixture机制配合模块级变量来存数据。最简单的方式是定义一个公共模块，测试运行过程中往里面塞数据：

# data_store.py class DataStore: token = "" order_id = ""

测试用例里：

# test_order.py import requests from data_store import DataStore def test_login(): resp = requests.post("https://api.example.com/login", json={"username": "admin", "password": "123456"}) DataStore.token = resp.json()["data"]["token"] def test_create_order(): resp = requests.post("https://api.example.com/order/create", headers={"Authorization": "Bearer " + DataStore.token}, json={"productId": "P1001"}) DataStore.order_id = resp.json()["data"]["orderId"] def test_get_order_detail(): resp = requests.get(f"https://api.example.com/order/{DataStore.order_id}", headers={"Authorization": "Bearer " + DataStore.token}) assert resp.json()["data"]["orderId"] == DataStore.order_id

这三个用例在pytest里默认按定义顺序执行，用同一个模块级变量把Token和订单ID传递下去。这套方案虽然看起来没那么高深，但胜在简单直接、容易理解，非常适合快速搭建的自动化项目。等以后项目复杂了，你自然会去了解fixture + conftest.py这种更规范的做法，但第一天学会这个足够了。

6. pytest组织用例与一键生成测试报告，自动化框架看着就像样了

6.1 pytest的用例发现规则和命令行高频参数

前面写的脚本还散落在单个文件里，要真正形成自动化项目，得靠pytest把用例组织起来。pytest的用例发现规则就三条，背下来就行：

• 测试文件以test_开头或以_test结尾
• 测试类以Test开头，且不能有__init__方法
• 测试函数以test_开头

遵从这个规则，你把所有用例按模块拆到不同的test_*.py文件里，在项目根目录直接敲pytest，它就能自动找到所有用例并执行。

实际跑的时候，这几个命令行参数出镜率最高：

# 执行某个文件 pytest test_login.py # 执行某个文件里的某个用例 pytest test_login.py::test_login # 显示print输出 pytest -s # 显示更详细的测试信息 pytest -v # 出错时打印完整回溯 pytest --tb=long # 只重跑失败用例 pytest --lf

我建议你在命令行跑的时候-s -v两个参数一起带，又能看print输出又能看到每个用例的结果。排查问题的时候效率翻倍。

6.2 fixture写前置和后置，登录准备和清理干净利落

pytest中最实用但也最容易被新手忽略的能力是fixture。接口自动化里最常见的场景：多个用例都要先登录拿到Token，总不能每个用例里都写一遍登录逻辑吧？

用fixture可以这样写：

import pytest import requests @pytest.fixture(scope="module") def login_token(): # 前置操作：登录拿Token resp = requests.post("https://api.example.com/login", json={"username": "admin", "password": "123456"}) token = resp.json()["data"]["token"] # 用yield返回值，测试执行完后再执行后面的清理代码 yield token # 后置操作：清理或退出登录 requests.post("https://api.example.com/logout", headers={"Authorization": "Bearer " + token}) def test_get_user_info(login_token): resp = requests.get("https://api.example.com/user/info", headers={"Authorization": "Bearer " + login_token}) assert resp.status_code == 200

scope="module"表示这个fixture在整个测试模块里只执行一次，登录只调一次，Token所有用例共享。yield前面的代码是前置操作，后面的代码是后置清理，这个机制非常好用，你以后运维自动化用例的时候会感谢它的。

6.3 pytest-html生成可视化报告，怎么在自动化项目里落地

测试跑完没有报告，跟没跑有什么区别。pytest-html就是干这个的，用法极简：

pytest -s -v --html=report.html --self-contained-html

--self-contained-html这个参数很重要，它会把报告需要的CSS、JS全部内嵌到HTML文件里，生成的单文件就能直接打开分享，不用附带一堆静态资源。

示例报告会包含用例总数、通过数、失败数、耗时这些常规指标，每条用例的通过与否、失败原因也会列出来。团队协作的时候把这个报告发到群里，比截图命令行清爽得多。

我个人的习惯是在项目根目录建一个run.py，把命令封装成脚本，这样组员不需要记pytest参数：

import pytest import os if __name__ == "__main__": report_dir = "reports" os.makedirs(report_dir, exist_ok=True) pytest.main(["-s", "-v", "--html=" + os.path.join(report_dir, "report.html"), "--self-contained-html", "--lf"])

以后再想加定时执行、邮件通知，都在这个入口文件里扩展就行。

7. 实战中比代码更重要的坑和技巧，我踩过你直接绕开

7.1 中文乱码和编码问题，接口测试最普遍的翻车现场

响应体里有中文，但resp.text打印出来全是乱码，这个问题几乎每个人都遇到过。原因很简单，requests库在解析响应体时，会根据响应头里的Content-Type推断编码。很多老系统返回的Content-Type里没写charset=utf-8，requests就默认用了Latin-1或者ISO-8859-1编码去解码，中文自然就乱了。

解决办法有两个。最简单的是直接指定编码：

resp.encoding = "utf-8" print(resp.text)

或者用resp.content拿原始字节，然后手动解码：

resp.text.encode("utf-8").decode("utf-8")

实际项目里我用得最多的是第一种，因为简单直观。如果发现中文乱码，第一步就检查resp.encoding是什么，然后手动设成utf-8，大概率能解决。

7.2 超时设置必须写，不然后果很严重

requests.get(url)不设置超时时间，请求会一直挂着，直到系统层面超时。这在自动化测试里是致命伤——某个接口偶发不通，测试脚本卡死在等待响应上，后面所有用例全部阻塞，本来一个小时的回归测试变成无限期挂起。

标准写法：

resp = requests.get(url, timeout=5)

这个5秒是连接和读取两个阶段的合计超时。如果你想分别设置：

resp = requests.get(url, timeout=(3, 5))

第一个参数是连接超时，第二个是读取超时。我推荐至少都设成5秒，既不会因为网络慢误报，也不会让脚本卡死。

7.3 接口返回大字段、动态时间戳、图片验证码，这些怎么处理

实际公司项目里，不是所有接口都像教程那么干净。差不多每个自动化项目都会遇到这几种头痛场景，我都处理过，给你说说思路。

大字段响应：比如响应体里带了一段很长的Base64图片，打印出来刷屏好几百行。分析问题的时候用resp.json().get("data")只取关键字段，别整个resp.text往控制台扔。排查问题聚焦关键信息。

动态时间戳和随机值：创建订单接口需要传当前时间戳，两分钟之后再跑同一套数据可能就冲突了。用Python标准库生成动态值：

import time import uuid timestamp = str(int(time.time())) random_order_id = uuid.uuid4().hex[:16]

把这些动态值作为每个用例独立的数据，别复用硬编码值。

图片验证码：如果登录接口需要验证码，自动化最省事的方式是找开发帮忙开一个测试环境的验证码万能开关，或者提供一个固定的测试验证码。这不是偷懒，是行业通用做法——自动化测试的目的是测业务逻辑，验证码本身就是用来拦住机器人的，没必要死磕图形识别。真要是验证码识别这种需求，也是单独的安全测试方向，不该混在业务自动化里做。

7.4 接口请求虽然通了，但断言失败，如何快速定位是代码问题还是数据问题

最后说一个排查思路，学会了能省你大量时间。接口自动化用例跑挂了，先别急着怀疑自己的代码有问题，按下面这个顺序排查：

1. 看响应内容：print(resp.text)，看服务端具体返回了什么。很多时候一看到实际返回就明白了，不是缺参数就是参数格式不对。
2. 用Postman或浏览器手工请求一次：一样的参数、一样的Headers，手工调一次看结果。如果手工调成功但脚本失败，说明是脚本问题，比如Header没带上、参数格式不对；如果手工调也失败，那基本是接口本身或测试数据的问题。
3. 看是不是数据过期了：Token过期、测试订单被删、测试账号被禁，这三件事是回归测试翻车率最高的原因。先把数据刷新一遍再跑。
4. 看断言本身是不是写错了：是不是把code的预期值写错了，或者取了不存在的字段。检查schema，看返回的JSON结构有没有变化。

这套排查顺序用熟了，定位一个报错基本在五分钟内。很多人遇到失败就慌，其实接口自动化最大的特点就是"失败一定看得见"，响应日志、状态码、返回值全都在，基本都是明牌。唯一可能让你纠结的是服务端报错信息写得烂，这种时候就去翻后端日志，不归调试脚本管。

8. 给你一条一天的实操路线，照着走完就能写自己的项目

最后给一条可以"照抄"的路线，严格跟着走，一天时间足够。我把每个时间段的目标都拆好，每一阶段做完你可以自检，卡住了就往回看对应的章节。

上午：环境+核心语法（约3小时）

• 第1小时：按第2章装好Python、VS Code、虚拟环境，跑通requests和pytest的import
• 第2小时：按第3章用requests写GET和POST请求，对着公开测试接口练手，强制自己用resp.status_code、resp.json()、resp.headers输出不同信息
• 第3小时：做Session登录串联练习，找公司或开源项目里带登录态的接口试一遍

自检标准：能独立写一个带参数的GET请求和一个带JSON body的POST请求，能打印和解析响应。

下午前半段：断言和数据驱动（约2小时）

• 第1小时：按第4章把三层断言体系落地到你的练习用例上，每层至少写一条
• 第2小时：按第5章把所有写死的测试数据改成parametrize参数化，至少准备5组测试数据

自检标准：断开数据库或改错测试数据后，用例能秒挂，并且从报错信息能定位到具体数据。

下午后半段：工程化和报告输出（约2小时）

• 第1小时：按第6章把所有用例整理成pytest标准结构，写上fixture处理登录Token
• 第2小时：用pytest-html生成第一份测试报告，把测试数据从JSON文件中读取

自检标准：命令行一条命令跑完所有用例，生成的HTML报告能正常打开。

晚上：实战收尾（约1小时）

• 拿你负责的项目选一条核心业务链路（比如"登录-创建订单-查订单-取消订单"），把当天的知识串起来完整跑一遍
• 把第7章的坑全部对照一遍，确认自己的脚本里没有这些隐患

这套路线是我带新人最常用的，实践下来，只要不是完全没碰过Python，一天基本都能完成。完成了之后你会发现，所谓接口自动化，就像搭积木——环境是底座、request是老本行、断言是标尺、参数化是效率、pytest是组织者。你把这五块积木拼起来，就已经超过很多号称"会接口自动化"的简历选手了。

接下来你要做的，不过是找真实项目往框架里填用例而已。这一步没什么技术含量，但一定要动手。把第一个接口用例填进去跑通的那一刻，你会觉得今天这一整天，值了。