企业官网建设流程全解析

如果你已经在用 Postman 或者 Jmeter 手动点接口，那自动化脚本对你的门槛，其实只有一层窗户纸。我经常在团队里看到这样的场景：测试同学打开 Postman，把登录接口的 URL、Header、Body 一个个填好，点 Send，拿到 token，再复制到下一个接口。这套动作一天重复几十遍，点得多了，手比脑子还诚实。有人问过我："自动化脚本是不是很难？是不是得专门学代码才能写？" 我的回答从来都是：自动化脚本没有你想象的那么玄，它就是把你平时在 Postman/Jmeter 里手工点的接口请求，用代码写成可重复执行的脚本。

这篇内容适合两类人：一类是已经在用 Postman/Jmeter 做接口测试、但总觉得自动化高不可攀的测试同学；另一类是后端开发，想把手动验证接口的过程沉淀成可回归的脚本。我会从最基础的认知讲起，一步步拆解请求结构，给出能直接跑的代码，再讲清楚怎么让脚本从"能跑"变成"稳定跑一万次"，最后把 Jmeter 里的场景也脚本化。全程不绕弯子，都是可以复制的实操。

1. 别把自动化脚本想玄了：你点的每个请求，背后都是一条HTTP消息

1.1 手工点按钮的本质是什么

在 Postman 里点 Send，程序背后做的事情，和你用代码发一个 HTTP 请求没有任何区别。你填写的 URL 是这趟请求的地址，选择的 GET/POST 是请求方式，Header 里放的是给服务端看的附加说明，Body 里写的是要传给服务端的业务数据。服务端收到后返回一段响应文本，Postman 帮你渲染成好看的 JSON 格式展示出来。

这个链条用代码来表达，就是requests.post(url, json=data, headers=headers)这样一行。你之所以觉得手工点击很轻松，是因为 Postman 替你承担了"构造 HTTP 消息"这个底层工作。但同样因为它是图形界面，每一次点击都是全新的操作，无法被记录、无法被回放、无法一键跑一百次。

Jmeter 也是同一个逻辑。你在线程组里添加一个 HTTP 请求采样器，配置域名、路径、参数，然后点绿色三角运行。很多人用 Jmeter 做过压测，却从没想过：那个 HTTP 请求采样器里的每一项配置，本质上翻译过来都是代码里的一个个参数。如果你理解了这层映射，再看自动化脚本，就不会觉得是在学一门新技能，而是在做一次"已知技能的代码化表达"。

1.2 Postman 里的每个手势，对应代码里的什么

我见过很多同学卡在同样的地方：不知道自动化脚本该从哪里下手。我建议他们做一件事——把自己在 Postman 里的常规操作列出来，一行一行翻译成代码。你会发现这个对照关系惊人的简单：

举个例子，在 Postman 里测试登录接口的时候，你填的是 POST、https://api.example.com/login、Header 里写Content-Type: application/json、Body 里写{"username": "admin", "password": "123456"}。这段操作翻译成代码就是：

import requests url = "https://api.example.com/login" headers = {"Content-Type": "application/json"} body = {"username": "admin", "password": "123456"} response = requests.post(url, json=body, headers=headers) print(response.json())

就这么简单。你点 Send 后看到的东西，全在这个response对象里。想验证 HTTP 状态码是 200，就写assert response.status_code == 200；想验证业务返回码是 0，就写assert response.json()["code"] == 0。这就是 Postman 里看响应、看断言结果的那个环节。

1.3 同样的事情，为什么用代码写一遍就值了

手工操作和代码脚本，表面上做的是同一件事，但本质完全不同。你要理解这个"值"在哪里，才不会觉得自动化是为了写代码而写代码。

手工操作是一锤子买卖。你今天点一遍通过了，明天想再验证一次，还得重新打开 Postman 重新点。中间万一漏配了一个 Header，或者复制 token 的时候少复制了后半段，结果就是误导你的判断。自动化脚本写出后，同样的动作可以回放一千次，且每一次的请求内容都不会因为"手抖"而变形。

脚本还天然解决了留痕问题。你手工点接口的时候，如果没有人站在旁边看，事后很难证明你测了哪些接口、每个接口的响应是什么。但脚本每执行一次，请求和响应的日志会完整保留下来。这个能力在项目交付、问题定位、回归验证的时候极其有用——尤其是线上出了问题，你能快速回答"这个接口在上个版本是好的，这次改动后开始报错"。

更重要的是，脚本可以脱离人独立运行。它可以被 CI 平台在每次代码提交后自动触发，可以写进定时任务在每天早上跑一遍，也可以接入你现有的测试平台做数据统计。这是任何手工点击都做不到的。理解到这一层，你才算真正理解了自动化脚本存在的意义。

2. 请求结构拆解：把 Postman 里的一条记录"翻译"成代码

2.1 最快的路径：让 Postman 先帮你生成代码

如果你的手边已经有一个调通的 Postman 请求，又不想从零开始写 Python 代码，最快的办法是让 Postman 自己把代码生成出来。在 Postman 的请求编辑界面右上角，有一个</>图标，点开后可以选择目标语言，找到 Python Requests 这一项。它会自动把当前请求翻译成一段可执行的 Python 代码。

我第一次用这个功能的时候，坦白讲有点震惊，因为它连 Header、Body 里的每个字段都给你填好了。对于拷贝整个请求结构这件事，它比人肉手工抄写可靠得多。但要注意，生成的代码有一个显著的问题：它会把所有的值全部硬编码在代码里。URL 是写死的，Header 的 token 是写死的，Body 里的账号密码也是写死的。如果你直接拿去跑，确实能跑通，但换个环境、换个用户、换一台机器可能就废了。

所以我的习惯是：把 Postman 生成的代码当作"翻译草稿"，在此基础上做三件事——把 URL 抽成变量，把有生命周期限制的值（token、时间戳、随机码）改成动态获取，把关键响应加上断言。这样既有 Postman 生成的准确性，又有脚本该有的灵活性。

2.2 请求的五个要素：每个都要弄清楚再动手

无论你用 Postman、Jmeter 还是直接写库，HTTP 请求的核心都由五个要素组成。我在带人的时候，要求他们必须能默写出这五样东西，因为任何一个环节理解不到位，脚本都会在某个时刻突然翻车。

• 请求方法与 URL：决定你要对哪个资源做什么操作。GET 通常用来查询，POST 用来提交创建，PUT 用来全量更新，PATCH 用来局部更新，DELETE 用来删除。
• Query 参数：URL 问号后面的键值对，比如?page=1&size=20。在 requests 里用params={"page": 1, "size": 20}传入，程序会自动帮你拼接并处理中文编码。如果你手动拼 URL 字符串，碰到包含中文或特殊字符的参数，还要自己处理 URL 编码，非常容易出错。
• Headers：这里面最核心的就是Content-Type，它告诉服务端 Body 里的数据是什么格式。用requests的json=参数发送 JSON 时，库会自动帮你设置Content-Type: application/json，很多新手不知道这一点，自己又在 Header 里写了一遍，结果一样，但显得多余。
• Body：不同接口对 Body 的格式要求不一样。最常见的是 JSON，对应json={}；另一种是表单格式，对应data={}；还有上传文件用的multipart/form-data，对应files={}。如果你接口用的是 JSON，却用data参数传了一个字典，服务端可能解析不出来，报 400 错误。
• 认证与状态：登录之后绝大多数接口需要携带 token 或 cookie，证明你是已经认证过的用户。这里有一个新手经常踩的坑——以为每次请求都要手动把 token 塞进 Header。其实用requests.Session()之后，登录接口返回的 cookie 会被 session 自动保存，后续用同一个 session 发请求时，cookie 会自动带上。

2.3 一个真实案例：从浏览器抓包到 Python 脚本

我经常拿电商系统的"登录后查询订单"这个场景来演示完整流程。你在浏览器 F12 的 Network 面板里，可以看到登录请求长什么样：请求 URL 是https://api.example.com/login，Method 是 POST，Payload 是{"phone": "13800138000", "password": "abc123"}，Response 返回了{"code": 0, "data": {"token": "eyJhbGciOi..."}}。

把这个流程脚本化，需要做三件事。第一，用账号密码请求登录接口，拿到响应里返回的 token。第二，调用查询订单接口https://api.example.com/orders?page=1，Header 里带上Authorization: Bearer <token>。第三，断言订单接口返回的数据结构符合预期。写成代码如下：

import requests base_url = "https://api.example.com" session = requests.Session() # 第一步：登录 login_resp = session.post( f"{base_url}/login", json={"phone": "13800138000", "password": "abc123"} ) login_data = login_resp.json() assert login_data["code"] == 0, f"登录失败: {login_data}" token = login_data["data"]["token"] # 第二步：携带 token 查询订单 order_resp = session.get( f"{base_url}/orders", params={"page": 1}, headers={"Authorization": f"Bearer {token}"} ) order_data = order_resp.json() # 第三步：断言 assert order_resp.status_code == 200 assert order_data["code"] == 0 assert isinstance(order_data["data"]["list"], list)

这段代码已经具备了一个可重复执行脚本的基本形态。你可能注意到了，我特意用同一个session发送登录和查询请求，即使不手动加 token，session 也会把登录接口返回的 Cookie 保存下来。不过实际项目里，很多接口用的是 Header 里的 Bearer Token 而不是 Cookie，所以示例里还是显式地往 Header 里塞了 token。两种方式都掌握，遇到什么接口都能处理。

3. 手把手实现第一个可重复执行的接口脚本

3.1 环境准备：别在这一步卡太久

动手写接口脚本，Python 环境是最简洁的选择。我用的是 Python 3，配合两个第三方库：requests负责发送 HTTP 请求，pytest负责组织测试用例和断言。整个准备过程，在一个命令行窗口里五分钟搞定：

# 创建并激活虚拟环境 python3 -m venv api_test_env source api_test_env/bin/activate # 安装依赖 pip install requests pytest

为什么要用虚拟环境？因为它是你"可重复执行"的第一道保障。不同项目依赖的库版本可能不一样，如果不做隔离，今天升级一个库，明天另一个项目的脚本就莫名其妙挂了。我见过太多团队因为全局 Python 环境里装了一堆互相冲突的包，排查问题排查了半天，最后发现是环境问题而不是脚本问题。从第一天就用虚拟环境，这个成本极低，收益却很大。

3.2 从"一个请求"到"一个用例"：引入 pytest

有了上面 2.3 的代码，你已经能跑通一次请求了。但这样的脚本还有个问题：它是一次性的，断言失败也只是往屏幕上吐一段红字。要做到可维护、可重复执行，需要引入 pytest 来管理你的用例。

pytest 的核心思想很简单：一个以test_开头的函数就是一个测试用例，函数里的assert就是断言。执行pytest命令后，它会自动发现所有test_开头的函数并逐个执行。把登录流程整理成用例的写法是这样的：

import requests BASE_URL = "https://api.example.com" session = requests.Session() def test_login_success(): resp = session.post( f"{BASE_URL}/login", json={"phone": "13800138000", "password": "abc123"} ) data = resp.json() assert resp.status_code == 200 assert data["code"] == 0 assert data["data"]["token"] != ""

跑一下pytest -v，你会看到它输出了一个清晰的执行结果。这个例子看起来和普通脚本差别不大，但 pytest 给你带来了三个关键能力：第一，断言失败时，它会详细展示哪个文件哪个函数哪一行失败了，失败原因是什么；第二，一个文件里可以写很多test_函数，批量执行；第三，它支持 fixture、参数化等高级功能，为后面的进阶打下基础。

3.3 接口关联：把上一个接口的返回，传给下一个接口

真实业务接口几乎没有孤立的，全靠接口之间传数据。最常见的模式就是"登录拿 token，调业务接口时把 token 放 Header"。

我在 3.2 的例子里还没有完整展示 token 的传递过程，这里单独拿出来讲。实际开发中，token 在响应里的位置多种多样，有的在data.token，有的在data.access_token，还有的藏在返回头Set-Cookie里。稳妥的做法是先print(resp.text)看清返回结构，再写提取逻辑：

login_data = resp.json() token = login_data["data"]["token"] # 字典路径直接取

有的接口返回嵌套层级很深，比如{"data": {"user": {"token_info": {"access_token": "xxx"}}}}。这时候写一长串下标取值很容易踩 KeyError，我建议写一个简单的递归查找函数，按 key 名全局搜索：

def find_key(data, target): if isinstance(data, dict): for key, value in data.items(): if key == target: return value result = find_key(value, target) if result is not None: return result elif isinstance(data, list): for item in data: result = find_key(item, target) if result is not None: return result return None token = find_key(resp.json(), "token")

这个小工具函数我几乎每个项目都要用，比层数一直变的时候一个个取下标省心得多。取到 token 之后，就可以把它写进后续请求的 Header：

HEADERS = {"Authorization": f"Bearer {token}"} resp = session.get(f"{BASE_URL}/orders", headers=HEADERS)

3.4 参数化：让脚本从"写死"变成"数据驱动"

第一次写自动化脚本的人，很容易把所有值全部写进代码里。账号密码写死，订单 ID 写死，页码写死。这样的脚本虽然能跑，但本质上和手工点没有太大区别——你改变一个测试数据，就要改一遍代码。参数化是摆脱这种局面的关键一步。

pytest 的@pytest.mark.parametrize可以让你用一份数据跑多组用例。比如登录接口要测"正确密码、错误密码、账号不存在、密码为空"这四种情况，你可以这么写：

import pytest import requests @pytest.mark.parametrize("payload, expected_code", [ ({"phone": "13800138000", "password": "abc123"}, 0), ({"phone": "13800138000", "password": "wrong"}, 1001), ({"phone": "not_exist", "password": "abc123"}, 1002), ({"phone": "13800138000", "password": ""}, 1003), ]) def test_login_with_params(payload, expected_code): resp = requests.post("https://api.example.com/login", json=payload) assert resp.json()["code"] == expected_code

为什么要从"写死"变成"数据驱动"？因为接口测试很大程度上是数据组合的验证。你关心的不是一组数据跑通，而是多组数据分别得到预期结果。参数化让测试数据从代码里抽离出来，后续新增测试场景时不用改函数体，只需要加一组数据即可。测试数据多了以后，你还可以把它们放进 JSON 或 YAML 文件里，由脚本读取，这就是数据与代码分离的雏形。

另外一个常见的需求是动态参数。比如创建订单接口要求订单号唯一，一个固定的订单号跑第二次就会报"订单已存在"。解决方案是用时间戳或 UUID：

import time from uuid import uuid4 order_no = f"TEST{uuid4().hex[:12]}" timestamp = int(time.time()) payload = {"order_no": order_no, "created_at": timestamp}

这保证了每次执行脚本产生的数据都是唯一的，脚本就有了重复执行而不互相干扰的能力。

4. 可重复执行的关键不是"能跑一次"，而是"能跑一万次"

4.1 自动化脚本最大的敌人：不稳定

我见过太多团队，自动化脚本写出来当天跑得很欢，第二天就红了一片。为什么？因为"能跑通一次"和"能稳定跑很多次"是两回事。自动化脚本真正的敌人不是接口变复杂了，而是不稳定。

不稳定来自很多方面。Token 有效期只有一小时，脚本过了有效期就全部 401；测试环境的数据被上一个用例污染了，导致断言失败；网络偶发超时，接口本身没问题但脚本判失败；配置写死了测试环境的域名，一换环境全部跑不通；断言写得不够严谨，接口已经悄悄出错，脚本却还显示通过。每一个问题我都踩过，每一个问题也都有对应的解法。这节内容，就是我在这些坑里爬出来的经验总结。

4.2 环境配置化：别把域名和密码写死在代码里

我刚开始做接口自动化的时候，习惯把所有环境的域名直接写死在代码里。后来被现实教育了：开发环境、测试环境、预发布环境，URL 不一样，账号密码也不一样。每切换一次环境，就要改一遍代码，改完还可能漏掉某个接口。

正确的做法是把环境信息放到配置文件和环境变量里。用 Python 的os.getenv读取环境变量，再配一份.env文件（注意别提交到代码仓库）管理敏感数据：

import os BASE_URL = os.getenv("API_BASE_URL", "https://test.api.example.com") USERNAME = os.getenv("API_USERNAME", "test_user") PASSWORD = os.getenv("API_PASSWORD", "test_password")

这样跑测试的时候，只需要在命令行设置环境变量就能切换环境：

API_BASE_URL=https://dev.api.example.com pytest -v

另外提醒一句：账号密码这类敏感信息不要直接写进代码，更不要提交到 Git。我见过有人把自己的生产环境密码写死在测试脚本里，然后整个仓库被拖下来，密码直接泄露的事故。哪怕只是为了测试，也要养成用环境变量的习惯。

4.3 断言设计：只看状态码 200，等于没测

新手最容易犯的错误是把assert response.status_code == 200当成了全部断言。实际上，HTTP 200 只能说明"请求被服务端正常处理了"，完全没有验证业务逻辑的对错。举个真实例子：一个查询接口在用户不存在时返回了 200 和一个空的 data 列表，如果只断言 200，错误根本不会暴露，但用户实际看到的是"查不到任何数据"。

接口测试的断言至少应该包含三层：

• 传输层断言：HTTP 状态码是 200、201、204 等预期值，响应时间不超过阈值；
• 业务层断言：返回的 JSON 中业务状态码code是否符合预期，message是否匹配；
• 数据层断言：关键字段是否存在，类型是否正确，列表长度是否符合预期，金额是不是计算正确。

我常用的一组断言模板：

def assert_api_response(resp, expected_code=0): assert resp.status_code == 200, f"HTTP状态码异常: {resp.status_code}" data = resp.json() assert data["code"] == expected_code, f"业务码异常: {data}" assert "data" in data, f"响应缺少data字段: {data}" return data["data"]

如果你需要更严格的数据结构校验，可以引入jsonschema库，直接用 JSON Schema 描述"这个接口返回的 data 应该长什么样"。字段类型错误、字段缺失、嵌套结构不对，都能一次校验出来，比手写一长串assert更高效、更清晰。

4.4 失败后的现场保留：让脚本告诉你错在哪儿

脚本失败不可怕，可怕的是失败后你完全不知道它到底哪里出了问题。没有日志的自动化脚本，就像一个没有监控的服务器——它宕机了你也不知道为什么。

我习惯在每个用例执行时，把请求信息和响应信息记录下来。最轻量的做法是写一个日志函数：

import logging logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(name)s - %(levelname)s - %(message)s') logger = logging.getLogger("api_test") # 在请求前后打印关键信息 logger.info("请求: POST %s", url) logger.info("请求头: %s", headers) logger.info("请求体: %s", payload) logger.info("响应: %s", resp.text)

但凡脚本出问题，第一件事永远是翻日志，看请求发出去的是什么、服务端回的是什么。大多数接口问题通过这一对“请求-响应”就能定位。更进阶的做法是接入 Allure 报告，在用例失败时自动附加当时的请求和响应内容，这样整个团队在 CI 上看报告时，都能直接看到失败现场，不需要每个人重新跑一遍才能复现。

4.5 幂等设计：让脚本无论跑多少遍，结果都一样

可重复执行还有一个隐藏前提：你的业务数据要支持重复执行。创建一个订单的接口，如果每次都创建成功，第一次跑没问题，第二次跑就会因为订单号重复失败。解决这个问题的方法，就是让脚本具备"幂等性"——无论跑多少遍，结果都是一致的。

一个常用的套路是先查重再创建：

import requests from uuid import uuid4 BASE_URL = "..." session = requests.Session() token = "..." unique_order_no = f"TEST{uuid4().hex[:12]}" # 先判断这个订单号是否已存在 check_resp = session.get(f"{BASE_URL}/orders/{unique_order_no}", headers={"Authorization": f"Bearer {token}"}) if check_resp.status_code == 404: # 不存在，才执行创建 create_resp = session.post( f"{BASE_URL}/orders", json={"order_no": unique_order_no, "amount": 99.9}, headers={"Authorization": f"Bearer {token}"} ) assert create_resp.status_code in (200, 201) else: # 已存在，直接跳过创建并清理掉 session.delete(f"{BASE_URL}/orders/{unique_order_no}", headers={"Authorization": f"Bearer {token}"})

设计的关键思路是：脚本不能假设"测试环境永远是干净的"。真实环境里，上一次跑完留下的脏数据随时会影响到你。学会在脚本里做前置清理、后置清理、先查后建，你的脚本才能真正做到"重复执行"。

5. 把 Jmeter 里的场景也脚本化：从图形界面到命令行

5.1 Jmeter 测试计划的本质，与代码是一一对应的

很多用 Jmeter 的人，一提到"脚本"第一反应是"Jmeter 不是有图形界面吗，还要脚本干嘛？"这个想法低估了 Jmeter 脚本化的价值。实际上，Jmeter 测试计划的本质和代码脚本就是一回事：线程组相当于代码里的一个 for 循环，HTTP 请求采样器相当于循环体里的requests.get/post，断言相当于assert，监听器相当于日志输出和测试报告。

Jmeter 的图形界面适合调试场景，但当你要在 CI 里每次发版后自动跑一遍压测，或者需要在一台没有图形界面的服务器上执行压测任务时，你必须把它从图形界面里解放出来。命令行模式就是解放它的方式。

5.2 用 JSR223 断言：在 Jmeter 里写你自己的校验逻辑

Jmeter 内置的断言组件（响应断言、大小断言等）在处理简单场景时够用，但一旦涉及"从响应里提取 token，再校验另一个字段的长度"这类逻辑，你仍然需要写脚本。Jmeter 里支持 BeanShell 脚本，但我更推荐用 JSR223 采样器配合 Groovy 语言来做断言，因为 Groovy 和 Jmeter 的结合性能更好，语法也更接近现代编程语言。

下面是一个在 JSR223 断言里验证登录响应并提取 token 的示例：

def responseText = prev.getResponseDataAsString() def json = new groovy.json.JsonSlurper().parseText(responseText) assert json.code == 0 : "业务码错误: ${json.code}" assert json.data.token != null : "token为空" // 把 token 存入 Jmeter 变量，供后续请求使用 vars.put("token", json.data.token)

写完这段 Groovy 脚本，后续的 HTTP 请求采样器里就可以直接用${token}引用这个变量。Jmeter 变量引用的用法和代码脚本里的参数化异曲同工，本质上都是在运行时动态替换值。

还有一个我在 Jmeter 录制 HTTPS 脚本时踩过的坑：如果你用 Jmeter 的 HTTP(S) 脚本录制功能抓 HTTPS 包，需要在 Jmeter 里安装它的根证书，并在浏览器里信任这个证书，否则手机或浏览器上的请求根本录不进去。很多人录制失败，九成是因为没有处理好证书信任问题。这个操作不复杂，但很容易被忽略。

5.3 命令行跑 Jmeter：从"点运行"到"一条命令"

Jmeter 命令行模式的核心命令是这样：

jmeter -n -t test_plan.jmx -l result.jtl -e -o report_dir

参数含义分别是：-n表示非 GUI 模式，-t指定测试计划文件，-l指定原始结果文件的输出路径，-e表示生成 HTML 报告，-o指定报告输出目录。如果是一次压测任务，你还需要动态控制线程数和循环次数。Jmeter 允许通过-J参数从命令行传入 JMeter 属性，测试计划里用${__P(threads, 10)}这样的写法来引用：

jmeter -n -t test_plan.jmx -Jthreads=50 -Jloops=100 -l result.jtl -e -o report_dir

这一步的意义是巨大的。从此之后，压测不再需要人坐在电脑前点绿色的运行按钮，而是变成可重复执行的命令。你可以把它写进 CI 流水线，也可以安排成定时任务。我见过不少团队因为不会命令行模式，每天定时压测都是靠同事手动操作，一旦执行人请假，压测就断档。学会命令行模式之后，这个场景彻底消失了。

5.4 Postman 代码脚本和 Jmeter，到底该用哪个

这是我在团队里被问得最多的问题。我的建议是分场景：

作为个人经验，我通常会在项目里同时保留两套东西：Postman 用来做接口调试和给团队分享接口调用样例，代码脚本用来做功能回归和 CI；Jmeter 则专门负责性能测试场景。三者并不冲突，它们的共同底层逻辑都是 HTTP 请求的构造与响应验证。想明白这一点，你就不会在"学 Postman 还是学 Jmeter 还是学 Python"之间纠结了。

另外，针对最近大家讨论比较多的"根据测试用例自动生成自动化脚本"这类 AI 辅助测试的玩法，我的看法是：工具越智能，你越要把基础原理吃透。你连请求结构都不会拆，AI 生成的脚本出了问题你根本不知道从哪修。反过来，如果你已经能把一个接口手动翻译成代码，那 AI 生成脚本对你来说只是提效工具，而不是救命稻草。基础牢固了，再往上走才踏实。

我在实际项目里带过不少测试同学，最终能独立维护接口自动化脚本的人，都具备同一个习惯：每遇到一个接口，先把它在 Postman 里调通，再亲手用代码写一遍，哪怕慢也坚持手写。这个过程重复二十个接口之后，你就不会再问"自动化脚本怎么写"了，因为你眼里看到的接口，已经自动拆成了 method、url、headers、body、断言这五个部分。

最后给你一个可以立刻上手的建议：今天就把你明天要在 Postman 里手工点的三个接口，用 Python 代码写一遍。不要用代码生成功能，就手写。写不出来的部分去查 requests 文档，查完再写。三个接口跑通之后，你会发现之前那道"我不会写脚本"的心理障碍，已经彻底消失了。