尧图网站建设 
接口自动化测试最稳的入门组合至今还是 Python 的 Requests 发请求、Pytest 管理用例再通过持续集成让整个测试过程自动跑起来。这套技术栈看起来不复杂但很多人卡住是因为没有先搞清楚Requests 帮你解决“能不能把一次请求发出去”Pytest 帮你解决“发出去之后凭什么判断它对不对”持续集成解决“怎么让接口测试每天或每次发布都自动重复执行”。三件事属于不同层次如果一上来就埋头写 requests.get()很容易出现“脚本能跑但换个人、换台机器、换批数据就散架”的情况。所以这篇内容不是那种贴满代码的速查手册而是按一条完整的落地链路来拆环境准备、Requests 请求层、Pytest 用例层、数据驱动与分层、报告与 Jenkins 持续集成。标题里提到 6 小时我会在最后给一份明确的时间分配表把“6 小时能练到什么程度”说清楚。先给结论6 小时足够你从零搭好一套能在本地运行、能出 HTML 报告、能手动或自动触发的最小接口自动化体系但不足以让你应对所有复杂业务。能把最小闭环跑通后面再往场景里填用例才是最现实的成长路径。1. 接口自动化到底在学什么Requests、Pytest、持续集成分工不同1.1 从一条手工接口测试说起很多新手对“接口自动化测试”的理解是写一段 Python 脚本把接口地址放进去运行后能看到返回结果。这个理解不算错但离真正的自动化还差一步。手工测试人工大概会做这些事打开接口文档确定请求方法构造请求参数发送请求然后看返回的 HTTP 状态码和响应体再对照业务预期判断功能是否通过。自动化测试要做的是把这条路用代码固定下来并且让机器自己判断结果而不是人肉看一串 JSON 然后拍脑袋说“看起来没问题”。Requests 只负责“发请求”和“拿响应”。它不负责告诉你这个结果对不对。比如登录接口返回了 200不代表登录一定成功业务逻辑可能返回一个code: 1001表示密码错误但 HTTP 状态码依然是 200。如果只把 Requests 当作全部断言能力会很弱最终仍然需要人去看输出。1.2 Requests、Pytest、CI 在链路里的角色我用一句话给它们分工RequestsHTTP 客户端负责把请求发出把响应拿回来。Pytest测试框架负责收集用例、执行用例、断言结果、生成可读报告。持续集成通过 Jenkins、GitLab CI 这类平台在指定时间或代码提交后自动执行 pytest保存报告并把失败信息反馈给团队。为什么会选这三个组合因为 Python 的 requests 语法足够简单适合快速描述接口调用pytest 对接口测试非常友好一个函数就是一个用例支持参数化也支持 fixture 处理前置条件持续集成平台则能把测试从“我本地跑一下”升级成“每次发布前自动跑一遍”。单独用 Postman 也能做接口测试甚至可以做批量执行。但 Postman 在断言维度、报告呈现、与代码仓库结合方面没有 Python 这套组合灵活。尤其是项目代码本身用 Java、Go、Python 开发时测试代码放在同一个仓库里通过 CI 触发是更自然的工作流。1.3 六小时能够建立的是“最小闭环”“6 小时搞懂接口自动化”这个说法要客观一点。如果你已经会 Python 基础6 小时足够完成一轮刻意练习两小时熟悉 Requests 和 HTTP 请求两小时看 Pytest 怎么组织用例一小时内补上 fixture、参数化和数据驱动最后一小时把报告和持续集成链路跑通。如果完全零基础6 小时可能会被 Python 环境本身占用一部分。更合理的预期是6 到 9 小时先跑通最小闭环而不是追求把 pytest 的所有特性、requests 的所有高级用法、Jenkins 的所有权限模型都学完。第一个学习周期结束后你应该能达到这样的状态给你一个新接口能在 5 到 10 分钟内写出一条用例用例能自动断言能选择单条、多条或整个目录执行能生成一份报告让别人看懂。这才是“搞懂”的标准。2. 环境准备阶段先别急着写代码把 Python、requests、pytest 一次装对接口自动化的很多报错根因不是代码逻辑而是环境没配好。Python 版本不对、pip 装到了别的解释器、pytest 不在当前环境、VSCode 没有选中虚拟环境里的解释器都会让你反复怀疑代码写错了。2.1 Python 版本和安装自检如果你的机器还没有 Python建议安装当前主流的稳定版本。接口自动化并不需要追最新版本Python 3.10、3.11、3.12 这类版本都可以正常使用。重点是安装完成后做一次自检python --version pip --versionWindows 用户如果直接输入python没反应可以先确认是否把 Python 加进 PATH或者检查是否安装了 Microsoft Store 版本有时终端里执行的是不同解释器。macOS 和 Linux 上经常需要输入python3而不是python因为系统可能自带 Python 2 或者用python3区分版本。这一步不要跳过。很多人后面遇到ModuleNotFoundError: No module named requests通常就是因为当前终端运行的 Python 和安装 requests 的 Python 不是同一个。2.2 依赖安装与虚拟环境接口自动化项目很小但依赖也属于项目的一部分。不要图省事直接往全局环境里装 requests 和 pytest否则后续不同项目之间可能出现依赖版本冲突。建议先在项目目录下建虚拟环境python -m venv .venvWindows 激活方式.venv\Scripts\activatemacOS 或 Linux 激活方式source .venv/bin/activate激活后安装依赖pip install requests pytest pytest-htmlpytest-html 用来生成 HTML 报告第一轮学习先用它足够。如果想要更漂亮的报告后面可以再装 allure-pytest。但 Allure 通常还需要单独安装 Allure 命令行工具入门阶段我不建议一步到位先把 pytest-html 用熟再升级报告体系。如果下载速度很慢或者因为网络原因安装失败可以切换 pip 国内镜像源这是常规做法不代表依赖本身有问题。2.3 用一条 demo 用例确认环境就绪不要一上来就写接口代码。先创建一个最简单的测试文件确认环境链路是通的# test_demo.py def test_ping(): assert 1 1 2然后在项目目录执行pytest -v看到 1 passed说明 pytest 能正常工作。再执行python -c import requests; print(requests.__version__)能打印出版本号说明 requests 可用。这样后续写接口用例时报错范围就可以缩小到业务代码本身而不是环境。VSCode 用户还需要注意打开项目后命令面板里选择 Python 解释器指向.venv\Scripts\python.exe或.venv/bin/python。否则编辑器和终端可能用的不是同一个解释器代码在终端里能跑在编辑器里却提示模块找不到。3. Requests 请求层把一次接口调用拆成五个可控变量很多人学 Requests 失败是因为以为只要掌握requests.get()和requests.post()就结束了。真实工作中一个接口是否能稳定跑通看的往往是你有没有把每个变量控制好。3.1 URL、method、headers、body、timeout一次接口请求至少要确认五个点请求地址URL请求方法GET、POST、PUT、DELETE 等请求头Content-Type、Authorization 等请求参数query 参数或 body 参数超时时间timeout看一个最基础的例子import requests url https://api.example.com/v1/login payload {username: admin, password: 123456} headers {Content-Type: application/json} resp requests.post(url, jsonpayload, headersheaders, timeout10) print(resp.status_code) print(resp.json())这里有几个容易被忽略的地方第一请求地址必须确认有没有路径拼错。很多接口返回 404 或 405不是代码问题而是 URL 少了前缀或方法用错。第二json 参数不是必须手动加 Content-Type。requests.post(url, jsonpayload)库会自动把字典序列化成 JSON并设置Content-Type: application/json。如果你的系统要求不一样再显式设置 headers 也不迟。第三timeout 一定要写。一个没有超时时间的请求在下游服务卡住时可能让整个测试任务一直挂着。宁可让它在 10 秒后失败也不要让整个测试流程没有终点。GET 请求带查询参数时直接用 params 更清晰resp requests.get( https://api.example.com/v1/users, params{page: 1, size: 20}, headers{Authorization: Bearer demo_token}, timeout5, )3.2 登录后如何保存 TokenSession 不只是一个封装接口测试里最常见的场景是先登录拿到 Token再带着 Token 查别的业务接口。如果每个用例都单独请求一次登录不仅慢还容易触发服务端限流。Requests 提供了 Session 对象它会把同一个会话中的 Cookie 保存下来也能让你统一设置公共 header。更实用的方式是登录后把返回的 token 取出来手动放到 Session 的 headers 里后续所有请求都默认带上。示例session requests.Session() login_url https://api.example.com/v1/login login_data {username: admin, password: 123456} resp session.post(login_url, jsonlogin_data, timeout10) body resp.json() token body[data][token] session.headers.update({Authorization: fBearer {token}}) user_info_resp session.get(https://api.example.com/v1/user/info, timeout10) print(user_info_resp.status_code)Session 在不同测试用例之间传值并不方便所以实际项目中通常会把它放到 pytest 的 fixture 里让所有用例共享一个已登录的会话。这个后面会讲。这里要注意如果被测系统的登录状态是服务端保存的Session 的 cookie 机制正好匹配如果是无状态 JWT你只需要把 token 塞进 header。不要以为所有系统都一样。3.3 响应判断从状态码开始但不能停在状态码接口返回后你首先看的是resp.status_code这是 HTTP 层面的状态。它只代表请求被服务端接收并返回了不代表业务成功。常见的业务接口响应体结构可能是{ code: 0, message: success, data: { token: xxx, userId: 123 } }也可能返回{ code: 1001, message: 用户名或密码错误 }所以判断响应时要分两层看。第一层是 HTTP 状态码第二层是业务码。很多接口自动化用例写得不严谨只断言了resp.status_code 200结果接口内部已经报错但测试仍然通过。这个问题必须在一开始就养成正确的断言习惯。3.4 遇到 429、连接超时和 SSL 报错时的排查顺序Requests 跑久了多少会遇到一些网络层错误。最常见的有下面几类429 Too Many Requests表示请求频率超过服务端限制。这不一定是你的代码逻辑错误可能只是同一段时间内请求次数太多。一些服务还会对未认证请求设置更低的限制带认证信息后额度会更高。遇到 429先看是否带上了有效的认证头再看是不是并发过高或循环太快不要一见到失败就无限重试。如果代码里已经加了重试但一直报类似exceeded retry limit, last status: 429 too many requests的错说明服务端仍然认为你请求过快这时候要降低频率而不是继续猛跑。连接超时或 read timed out先确认服务地址是否能连通再确认测试环境有没有网络隔离然后用 curl 或 Postman 请求一次做对比。不要直接调大 timeout因为 timeout 只是兜底不是解决网络不通的手段。SSLError通常是被测环境证书不受信任比如自签名证书。开发测试阶段可以通过verifyFalse临时处理但生产环境不要这么做也不要把 verifyFalse 写成一个固定参数到处复用。更规范的方式是让环境使用受信任证书或者单独配置证书路径。遇到任何网络层报错都比较推荐按这样的顺序排查先看控制台原始响应文本再用 Postman 同参数请求一次确认接口本身可用最后才回到代码里看 headers、params、timeout 有没有问题。很多“看起来像代码问题”的报错其实是请求参数格式和服务端预期不一致。4. Pytest 测试层从“能发请求”变成“能自动判定结果”Requests 把请求发出去了也拿到响应了但责任到这里就结束了。谁来判断结果是否正确、谁来组织上百条用例、谁来输出一段让人能看懂的失败信息这些是 Pytest 要做的事。4.1 为什么是 pytest 而不是 unittestPython 自带 unittest也能做接口测试。但 unittest 的写法更重很多代码要用类和方法包起来pytest 则允许你直接写一个函数作为用例断言也只需要用 Python 原生的assert失败信息会自动展示。pytest 在接口测试里的几个实用能力测试文件命名以test_开头函数命名以test_开头框架会自动收集。支持parametrize方便把同一接口的多种输入组合成多组用例。支持 fixture用来处理登录、建数据、清理测试数据等前置后置逻辑。有丰富的插件体系比如 pytest-html、allure-pytest、pytest-xdist 等。新手阶段不需要把 pytest 所有功能都摸透先掌握这几个就够用。4.2 fixture把登录和清理这类前置条件抽出来假设你要测“创建用户后查询用户”的场景前置条件是必须已登录。如果你在每个 test 函数里复制一段登录代码代码会变得很冗长而且登录失败时很难定位因为多个用例会同时失败你分不清是登录接口挂了还是业务接口挂了。fixture 就是用来解决这个问题的import pytest import requests BASE_URL https://api.example.com pytest.fixture(scopesession) def token(): resp requests.post( f{BASE_URL}/v1/login, json{username: admin, password: 123456}, timeout10, ) assert resp.status_code 200 body resp.json() assert body[code] 0 return body[data][token] pytest.fixture(scopesession) def session(token): s requests.Session() s.headers.update({Authorization: fBearer {token}}) return s def test_get_user_info(session): resp session.get(f{BASE_URL}/v1/user/info, timeout10) assert resp.status_code 200 assert resp.json()[code] 0这里有几个细节要注意。scope 设置为 session表示整个测试阶段只执行一次登录多个用例共享同一个 token。如果每个用例都登录一次不仅速度慢还容易触发服务端限流。如果你的系统对 token 有效期很短或者某些操作必须每次重新登录再将 scope 改为 function 也不迟。fixture 的返回值会被注入到测试函数参数里。参数名不要随便写因为 pytest 会按名字去查找对应的 fixture。你写def test_get_user_info(session)就必须存在一个名为 session 的 fixture否则会报 fixture not found。4.3 断言策略三层检查缺一不可写接口自动化断言时我一般会做三层检查。第一层HTTP 状态码。确保请求被服务端接受没有 404、500 这类系统级错误。示例assert resp.status_code 200第二层业务码。针对项目里常见的code字段做比较。这一步能区分“接口通了”和“业务真的成功”。body resp.json() assert body[code] 0 assert body[message] success第三层关键业务数据。如果必须返回用户 ID就检查 data 里有没有这个字段、是否大于 0、值是否符合预期。assert body[data][userId] 0 assert body[data][role] admin有些用例还需要更细的 schema 校验比如校验返回字段名称和类型。这一块可以先不学入门阶段做好三层断言已经能让问题暴露得很清楚。4.4 用例组织与失败快速定位Pytest 执行时可以按文件、按类、按函数筛选pytest cases/test_login.py -v pytest cases/test_login.py::test_wrong_password -v pytest cases -k login -v-k会用关键字匹配用例名适合临时跑一批关联用例。--maxfail1表示遇到第一条失败就停下来适合调试时快速定位问题。用例多了以后不要把所有文件平铺在一个目录里。通常可以按业务模块分文件比如 test_login.py、test_user.py、test_order.py。每个文件里再按场景拆函数。如果某个用例因为环境原因注定失败可以先标记跳过或预期失败import pytest pytest.mark.skip(reason该功能暂未上线) def test_not_online(): pass pytest.mark.xfail(reason已知缺陷先标记预期失败) def test_known_bug(): assert False这一阶段的关键转变是你不再通过 print 看结果而是让 pytest 告诉你通过、失败、跳过。只有这样做后续才可能接 CI因为 CI 只能看懂“进程退出码”和测试报告不能看懂你终端里打印的 JSON。5. 数据驱动和目录分层用例超过 50 条后别还在堆乱代码刚开始做接口自动化时每个测试文件里直接写 requests 请求也没什么问题。但是用例一旦超过 50 条重复代码开始变多修改一个公共地址要改 20 处新增一个环境就要复制一批文件。这时候就需要分层和参数化。5.1 先理解“框架三层”配置、接口封装、用例常见的接口自动化框架不是把代码放得复杂而是把职责分清楚配置层存放环境地址、超时、账号、数据库连接等全局信息。接口层把某个模块的请求封装成函数。例如 LoginApi 类里的 login 方法UserApi 类里的 get_user_info 方法。测试用例不直接拼 URL 和 headers而是调用这些方法。用例层只描述业务场景和测试数据不关心 HTTP 细节。一个典型的项目目录大致是这样的api_auto/ config/ settings.py api/ login_api.py user_api.py cases/ test_login.py test_user.py data/ login_data.yaml reports/ requirements.txt这样做有一个实际好处被测服务切换环境时只需要改配置层服务端某个接口路径变化时只需要改接口层新增业务场景时在用例层加数据和方法调用不需要动其他代码。5.2 用 parametrize 描述多组输入假设登录接口需要测正确密码、错误密码、用户不存在等场景。与其写三个几乎一样的 test 函数不如用参数化import pytest import requests BASE_URL https://api.example.com def call_login(username, password): return requests.post( f{BASE_URL}/v1/login, json{username: username, password: password}, timeout10, ) pytest.mark.parametrize( username,password,expected_code, [ (admin, 123456, 0), (admin, wrong_password, 1001), (nobody, 123456, 1001), ], ids[正确登录, 密码错误, 用户不存在], ) def test_login(username, password, expected_code): resp call_login(username, password) assert resp.status_code 200 assert resp.json()[code] expected_code参数化之后的每一条数据都会被 pytest 当成独立用例。你用-v执行时能看到“正确登录”“密码错误”“用户不存在”这些可读的用例名报告看起来也更清晰。注意 ids 里的字符串不能有歧义否则定位失败时不知道是哪一组数据。5.3 外部文件数据要不要引入参数化直接写在装饰器里适合数据量小的场景。如果用例数据很多比如 50 组账号、几百种商品数据继续写装饰器会让测试文件变得臃肿。这时候可以把数据放到 YAML 或 JSON 文件中。一个简单的 YAML 数据文件# data/login_data.yaml - username: admin password: 123456 expected_code: 0 case_id: login_success - username: admin password: wrong expected_code: 1001 case_id: login_wrong_password然后用 fixture 读取import pytest import yaml pytest.fixture(scopesession) def login_cases(): with open(data/login_data.yaml, encodingutf-8) as f: return yaml.safe_load(f)但这只是把数据搬到外部测试用例还是要参数化。真正应用时你还需要确定期望字段怎么维护。我见过很多团队为了做“数据驱动”写了非常重的读取 Excel 模板最后反而没人能改数据这是一个需要警惕的过度设计。5.4 “搭框架”的边界别把简单项目变成重框架网络上经常看到“接口自动化测试框架怎么搭建”这类问题。很多人会把关键字驱动、报告平台、任务调度、代码生成器全部塞进项目里结果项目还没跑起来先被框架本身的学习成本压垮。我的观点是requests pytest fixture parametrize 本身就可以构成一套轻量框架。如果你的业务复杂度不高只要按配置层、接口层、用例层三层分好目录就已经很清晰。只有当团队有多人协作、需要重复执行大量数据、要接不同的被测系统时才考虑引入更重的基础组件。入门阶段最好的框架是“别人看目录结构就能明白你在做什么”的框架而不是“技术名词最多”的框架。6. 报告和持续集成接口自动化能交给 Jenkins 才是完整闭环本地能跑通 pytest只说明你已经能用代码执行用例。但接口自动化的价值很大一部分来自“可重复、可定时、可提醒”。如果每次都靠人手动打开终端敲 pytest那它还不是真正意义上的持续集成。6.1 先让本地能产出 HTML 报告先把报告插件用起来pytest cases -v --htmlreports/report.html --self-contained-html--self-contained-html会把 CSS 和 JS 嵌入 HTML 文件里这样报告单文件就能直接打开不需要额外访问网络资源。报告会展示用例总数、通过数、失败数、失败信息、执行时间给别人看也足够直观。如果你后续使用 Allure步骤会变成pytest cases --alluredirallure-results allure serve allure-resultsAllure 报告更好看但需要额外安装命令行工具也会引入更多配置。第一轮学习不必强上先把 pytest-html 跑明白等团队确实有报告美观需求时再迁移。6.2 用一个简单 Jenkins Job 把 pytest 跑起来Jenkins 在这里扮演的角色是执行者。你可以在 Jenkins 上新建一个自由风格项目配置 Git 仓库地址再在“构建步骤”里执行 shell 命令。常见的一段构建命令cd api_auto if [ ! -d .venv ]; then python3 -m venv .venv fi source .venv/bin/activate pip install -r requirements.txt python -m pytest cases -v --htmlreports/report.html --self-contained-html这段命令做的事情非常直观进入项目目录如果没有虚拟环境就创建然后激活虚拟环境安装依赖最后执行测试。Jenkins 每跑一次都会生成一份新的报告。要注意的是Jenkins 执行机如果有多个项目尽量每个项目都使用自己的虚拟环境不要共用一个全局环境否则 A 项目升级 requests 可能影响 B 项目的测试。6.3 想更工程化Jenkinsfile 到底在描述什么自由风格项目适合演示真实团队更常用 Pipeline。Pipeline 的本质是把 CI 流程写成代码存到仓库里Jenkins 读 Jenkinsfile 后按阶段执行。一个最简的 Jenkinsfile 示意pipeline { agent any stages { stage(Checkout) { steps { checkout scm } } stage(Run API Tests) { steps { sh cd api_auto python3 -m venv .venv . .venv/bin/activate pip install -r requirements.txt python -m pytest cases -v --htmlreports/report.html --self-contained-html } } } post { always { publishHTML(target: [ reportDir: api_auto/reports, reportFiles: report.html, reportName: API Test Report ]) } } }这段代码不是拿来直接抄就能跑因为每个 Jenkins 的插件和权限配置会有差异。真正落地时你要根据自己的 Git 地址、执行机路径、Python 解释器和目录结构做调整。如果你想了解更细的 pipeline 语法可以参考 Jenkins 官方文档或先手动跑通自由风格项目再用 pipeline 替换。Pipeline 的好处是可以把“拉代码、装依赖、跑测试、发报告、发通知”写成一个可版本化的文件。别人一看就知道接口自动化的 CI 是怎么执行的不需要登录 Jenkins 一个个点配置。6.4 集成后的资源、超时和限流参数接口测试放进 CI 之后要额外关注几个参数。并发限制。如果多个 Jenkins Job 同时跑或同一个 Job 里开了 pytest-xdist 多进程流量可能瞬间翻倍导致被测环境出现 429。不要为了追求跑得快就无限加并发。第一轮先单进程跑能稳定了再加并发。任务超时。Jenkins 侧可以设置超时时间比如 30 分钟跑不完就标记失败。否则测试任务可能因为某个接口卡住而长期占用执行机。失败通知。接口测试失败不一定都是代码问题也可能是被测环境不稳定。但 CI 的目的是及时暴露问题不要因为“这个接口经常偶尔失败”就直接关掉通知。更好的处理是先定位是测试环境问题、脚本问题还是产品缺陷再决定要不要调整用例。定时构建。可以选每天凌晨跑一次避开业务高峰期。Jenkins 的 cron 支持H 2 * * *这种哈希写法意思是每天凌晨 2 点左右执行避免多个任务在整点同时挤在一起。持续集成的核心价值不是替代人肉点击而是让接口测试成为代码提交或发布流程里的一个检查关卡。每次合并代码前自动跑一遍关键接口有问题提前暴露这才是“持续集成测试”真正值得做的地方。7. 6 小时学习路线和自检清单你能跑通什么不能指望什么最后把 6 小时拆开给出一份可以直接照着执行的时间分配。这里默认你已经了解一点 Python 语法知道变量、函数、字典是什么如果完全没有 Python 基础请把时间拉长到 8 到 9 小时。7.1 按小时拆分的第一轮练习时间段目标练习内容第 1 小时环境准备安装 Python创建项目目录和虚拟环境安装 requests、pytest、pytest-html跑通一条 demo 用例第 2 小时Requests 请求写一段 POST 登录请求写一段 GET 查询请求打印状态码和 JSON 响应第 3 小时Pytest 基础把 Requests 代码改成 pytest 用例用 assert 断言状态码和业务码第 4 小时fixture 和会话把登录封装成登录接口方法用 fixture 返回带 token 的 session第 5 小时参数化与分层给登录接口补充多组错误密码数据用 parametrize 参数化整理目录结构第 6 小时报告和 CI生成 pytest-html 报告手动在 Jenkins 或本地命令行模拟一次自动执行很多人的问题是第 1 小时被安装卡住就放弃了或者在 Requests 上反复纠结各种高级用法。接口自动化的学习节奏应该是先把链路跑通一个接口、一条用例、一份报告。通了之后再往多接口、多数据、多环境扩展。7.2 每完成一段怎么自检不要只跟着练完就觉得自己会了要给自己设验收标准。环境准备好后能新建一个空目录从零创建一个虚拟环境并跑通 pytest。Requests 学完后能对一个实际接口完成 GET 和 POST 请求并能区分 URL、params、headers、body、timeout 各自的作用。Pytest 学完后能把一条接口请求写成测试函数失败时能通过 pytest 的错误信息定位是断言失败还是请求失败。数据驱动学完后能用 3 组以上参数化数据描述同一个接口测试并能通过用例名区分是哪组输入失败了。报告和 CI 学完后能不看教程独立配置一个新的 Jenkins 自由风格项目执行完成后能在浏览器里打开 HTML 报告。如果上面这些都能做到说明你已经完成了一个合格的接口自动化最小闭环。7.3 真正容易卡住你的不是代码而是这几个场景第一类场景是每次运行结果都不一样。这通常不是脚本不稳定而是测试数据没隔离。比如创建用户用例重复跑用户名唯一性校验导致第二次失败。接口自动化里很多问题都需要处理数据清理你可以在测试前先删除旧数据或者在用例结束后调用清理接口。第二类场景是上游依赖接口不稳定。下单接口依赖登录登录接口又依赖用户服务。如果只是把登录写在每个用例前面一旦用户服务宕机所有用例都会失败。这时候要先确认测试环境是否正常不要急着去改脚本逻辑。第三类场景是被动等待太多。看到请求失败就加 sleep或者失败后无限重试。sleep 只能让问题变慢不能解决问题。重试可以有但要有限度和退避策略。比如遇到 429退避几秒后再试一到两次如果仍然失败就标记为失败保留日志而不是无休止地刷请求。7.4 下一步能力提升方向第一轮闭环跑通之后想继续深入可以按这个顺序练习掌握更多 pytest 用法比如 fixture conftest.py 共享、yield fixture 做清理、自定义钩子。掌握更多 Requests 用法比如文件上传、流式响应、超时重试策略。学习接口测试数据构造包括从数据库准备数据、通过平台造数、调用上游接口间接造数。学习报告增强把 pytest-html 或 Allure 报告接入 Jenkins并增加趋势图。了解多环境支持比如 dev、test、staging 通过配置文件切换。如果只是做业务团队内部的接口回归不一定需要把平台做得多复杂。真正值钱的是你能稳定描述业务场景、准确断言结果、快速定位失败原因。框架再简单能持续跑出有效反馈就有价值框架再华丽里面装的用例全是无效断言也只是自我感动。练习接口自动化技术的最终标准其实是让测试结果可以被信任它说你挂了就是真的有问题它说通过了团队敢放心发布。只要能守住这条线你的 Requests 和 Pytest 组合就已经在团队里发挥作用了。 从零搭建接口自动化测试：Requests+Pytest+持续集成落地指南
接口自动化测试最稳的入门组合至今还是 Python 的 Requests 发请求、Pytest 管理用例再通过持续集成让整个测试过程自动跑起来。这套技术栈看起来不复杂但很多人卡住是因为没有先搞清楚Requests 帮你解决“能不能把一次请求发出去”Pytest 帮你解决“发出去之后凭什么判断它对不对”持续集成解决“怎么让接口测试每天或每次发布都自动重复执行”。三件事属于不同层次如果一上来就埋头写 requests.get()很容易出现“脚本能跑但换个人、换台机器、换批数据就散架”的情况。所以这篇内容不是那种贴满代码的速查手册而是按一条完整的落地链路来拆环境准备、Requests 请求层、Pytest 用例层、数据驱动与分层、报告与 Jenkins 持续集成。标题里提到 6 小时我会在最后给一份明确的时间分配表把“6 小时能练到什么程度”说清楚。先给结论6 小时足够你从零搭好一套能在本地运行、能出 HTML 报告、能手动或自动触发的最小接口自动化体系但不足以让你应对所有复杂业务。能把最小闭环跑通后面再往场景里填用例才是最现实的成长路径。1. 接口自动化到底在学什么Requests、Pytest、持续集成分工不同1.1 从一条手工接口测试说起很多新手对“接口自动化测试”的理解是写一段 Python 脚本把接口地址放进去运行后能看到返回结果。这个理解不算错但离真正的自动化还差一步。手工测试人工大概会做这些事打开接口文档确定请求方法构造请求参数发送请求然后看返回的 HTTP 状态码和响应体再对照业务预期判断功能是否通过。自动化测试要做的是把这条路用代码固定下来并且让机器自己判断结果而不是人肉看一串 JSON 然后拍脑袋说“看起来没问题”。Requests 只负责“发请求”和“拿响应”。它不负责告诉你这个结果对不对。比如登录接口返回了 200不代表登录一定成功业务逻辑可能返回一个code: 1001表示密码错误但 HTTP 状态码依然是 200。如果只把 Requests 当作全部断言能力会很弱最终仍然需要人去看输出。1.2 Requests、Pytest、CI 在链路里的角色我用一句话给它们分工RequestsHTTP 客户端负责把请求发出把响应拿回来。Pytest测试框架负责收集用例、执行用例、断言结果、生成可读报告。持续集成通过 Jenkins、GitLab CI 这类平台在指定时间或代码提交后自动执行 pytest保存报告并把失败信息反馈给团队。为什么会选这三个组合因为 Python 的 requests 语法足够简单适合快速描述接口调用pytest 对接口测试非常友好一个函数就是一个用例支持参数化也支持 fixture 处理前置条件持续集成平台则能把测试从“我本地跑一下”升级成“每次发布前自动跑一遍”。单独用 Postman 也能做接口测试甚至可以做批量执行。但 Postman 在断言维度、报告呈现、与代码仓库结合方面没有 Python 这套组合灵活。尤其是项目代码本身用 Java、Go、Python 开发时测试代码放在同一个仓库里通过 CI 触发是更自然的工作流。1.3 六小时能够建立的是“最小闭环”“6 小时搞懂接口自动化”这个说法要客观一点。如果你已经会 Python 基础6 小时足够完成一轮刻意练习两小时熟悉 Requests 和 HTTP 请求两小时看 Pytest 怎么组织用例一小时内补上 fixture、参数化和数据驱动最后一小时把报告和持续集成链路跑通。如果完全零基础6 小时可能会被 Python 环境本身占用一部分。更合理的预期是6 到 9 小时先跑通最小闭环而不是追求把 pytest 的所有特性、requests 的所有高级用法、Jenkins 的所有权限模型都学完。第一个学习周期结束后你应该能达到这样的状态给你一个新接口能在 5 到 10 分钟内写出一条用例用例能自动断言能选择单条、多条或整个目录执行能生成一份报告让别人看懂。这才是“搞懂”的标准。2. 环境准备阶段先别急着写代码把 Python、requests、pytest 一次装对接口自动化的很多报错根因不是代码逻辑而是环境没配好。Python 版本不对、pip 装到了别的解释器、pytest 不在当前环境、VSCode 没有选中虚拟环境里的解释器都会让你反复怀疑代码写错了。2.1 Python 版本和安装自检如果你的机器还没有 Python建议安装当前主流的稳定版本。接口自动化并不需要追最新版本Python 3.10、3.11、3.12 这类版本都可以正常使用。重点是安装完成后做一次自检python --version pip --versionWindows 用户如果直接输入python没反应可以先确认是否把 Python 加进 PATH或者检查是否安装了 Microsoft Store 版本有时终端里执行的是不同解释器。macOS 和 Linux 上经常需要输入python3而不是python因为系统可能自带 Python 2 或者用python3区分版本。这一步不要跳过。很多人后面遇到ModuleNotFoundError: No module named requests通常就是因为当前终端运行的 Python 和安装 requests 的 Python 不是同一个。2.2 依赖安装与虚拟环境接口自动化项目很小但依赖也属于项目的一部分。不要图省事直接往全局环境里装 requests 和 pytest否则后续不同项目之间可能出现依赖版本冲突。建议先在项目目录下建虚拟环境python -m venv .venvWindows 激活方式.venv\Scripts\activatemacOS 或 Linux 激活方式source .venv/bin/activate激活后安装依赖pip install requests pytest pytest-htmlpytest-html 用来生成 HTML 报告第一轮学习先用它足够。如果想要更漂亮的报告后面可以再装 allure-pytest。但 Allure 通常还需要单独安装 Allure 命令行工具入门阶段我不建议一步到位先把 pytest-html 用熟再升级报告体系。如果下载速度很慢或者因为网络原因安装失败可以切换 pip 国内镜像源这是常规做法不代表依赖本身有问题。2.3 用一条 demo 用例确认环境就绪不要一上来就写接口代码。先创建一个最简单的测试文件确认环境链路是通的# test_demo.py def test_ping(): assert 1 1 2然后在项目目录执行pytest -v看到 1 passed说明 pytest 能正常工作。再执行python -c import requests; print(requests.__version__)能打印出版本号说明 requests 可用。这样后续写接口用例时报错范围就可以缩小到业务代码本身而不是环境。VSCode 用户还需要注意打开项目后命令面板里选择 Python 解释器指向.venv\Scripts\python.exe或.venv/bin/python。否则编辑器和终端可能用的不是同一个解释器代码在终端里能跑在编辑器里却提示模块找不到。3. Requests 请求层把一次接口调用拆成五个可控变量很多人学 Requests 失败是因为以为只要掌握requests.get()和requests.post()就结束了。真实工作中一个接口是否能稳定跑通看的往往是你有没有把每个变量控制好。3.1 URL、method、headers、body、timeout一次接口请求至少要确认五个点请求地址URL请求方法GET、POST、PUT、DELETE 等请求头Content-Type、Authorization 等请求参数query 参数或 body 参数超时时间timeout看一个最基础的例子import requests url https://api.example.com/v1/login payload {username: admin, password: 123456} headers {Content-Type: application/json} resp requests.post(url, jsonpayload, headersheaders, timeout10) print(resp.status_code) print(resp.json())这里有几个容易被忽略的地方第一请求地址必须确认有没有路径拼错。很多接口返回 404 或 405不是代码问题而是 URL 少了前缀或方法用错。第二json 参数不是必须手动加 Content-Type。requests.post(url, jsonpayload)库会自动把字典序列化成 JSON并设置Content-Type: application/json。如果你的系统要求不一样再显式设置 headers 也不迟。第三timeout 一定要写。一个没有超时时间的请求在下游服务卡住时可能让整个测试任务一直挂着。宁可让它在 10 秒后失败也不要让整个测试流程没有终点。GET 请求带查询参数时直接用 params 更清晰resp requests.get( https://api.example.com/v1/users, params{page: 1, size: 20}, headers{Authorization: Bearer demo_token}, timeout5, )3.2 登录后如何保存 TokenSession 不只是一个封装接口测试里最常见的场景是先登录拿到 Token再带着 Token 查别的业务接口。如果每个用例都单独请求一次登录不仅慢还容易触发服务端限流。Requests 提供了 Session 对象它会把同一个会话中的 Cookie 保存下来也能让你统一设置公共 header。更实用的方式是登录后把返回的 token 取出来手动放到 Session 的 headers 里后续所有请求都默认带上。示例session requests.Session() login_url https://api.example.com/v1/login login_data {username: admin, password: 123456} resp session.post(login_url, jsonlogin_data, timeout10) body resp.json() token body[data][token] session.headers.update({Authorization: fBearer {token}}) user_info_resp session.get(https://api.example.com/v1/user/info, timeout10) print(user_info_resp.status_code)Session 在不同测试用例之间传值并不方便所以实际项目中通常会把它放到 pytest 的 fixture 里让所有用例共享一个已登录的会话。这个后面会讲。这里要注意如果被测系统的登录状态是服务端保存的Session 的 cookie 机制正好匹配如果是无状态 JWT你只需要把 token 塞进 header。不要以为所有系统都一样。3.3 响应判断从状态码开始但不能停在状态码接口返回后你首先看的是resp.status_code这是 HTTP 层面的状态。它只代表请求被服务端接收并返回了不代表业务成功。常见的业务接口响应体结构可能是{ code: 0, message: success, data: { token: xxx, userId: 123 } }也可能返回{ code: 1001, message: 用户名或密码错误 }所以判断响应时要分两层看。第一层是 HTTP 状态码第二层是业务码。很多接口自动化用例写得不严谨只断言了resp.status_code 200结果接口内部已经报错但测试仍然通过。这个问题必须在一开始就养成正确的断言习惯。3.4 遇到 429、连接超时和 SSL 报错时的排查顺序Requests 跑久了多少会遇到一些网络层错误。最常见的有下面几类429 Too Many Requests表示请求频率超过服务端限制。这不一定是你的代码逻辑错误可能只是同一段时间内请求次数太多。一些服务还会对未认证请求设置更低的限制带认证信息后额度会更高。遇到 429先看是否带上了有效的认证头再看是不是并发过高或循环太快不要一见到失败就无限重试。如果代码里已经加了重试但一直报类似exceeded retry limit, last status: 429 too many requests的错说明服务端仍然认为你请求过快这时候要降低频率而不是继续猛跑。连接超时或 read timed out先确认服务地址是否能连通再确认测试环境有没有网络隔离然后用 curl 或 Postman 请求一次做对比。不要直接调大 timeout因为 timeout 只是兜底不是解决网络不通的手段。SSLError通常是被测环境证书不受信任比如自签名证书。开发测试阶段可以通过verifyFalse临时处理但生产环境不要这么做也不要把 verifyFalse 写成一个固定参数到处复用。更规范的方式是让环境使用受信任证书或者单独配置证书路径。遇到任何网络层报错都比较推荐按这样的顺序排查先看控制台原始响应文本再用 Postman 同参数请求一次确认接口本身可用最后才回到代码里看 headers、params、timeout 有没有问题。很多“看起来像代码问题”的报错其实是请求参数格式和服务端预期不一致。4. Pytest 测试层从“能发请求”变成“能自动判定结果”Requests 把请求发出去了也拿到响应了但责任到这里就结束了。谁来判断结果是否正确、谁来组织上百条用例、谁来输出一段让人能看懂的失败信息这些是 Pytest 要做的事。4.1 为什么是 pytest 而不是 unittestPython 自带 unittest也能做接口测试。但 unittest 的写法更重很多代码要用类和方法包起来pytest 则允许你直接写一个函数作为用例断言也只需要用 Python 原生的assert失败信息会自动展示。pytest 在接口测试里的几个实用能力测试文件命名以test_开头函数命名以test_开头框架会自动收集。支持parametrize方便把同一接口的多种输入组合成多组用例。支持 fixture用来处理登录、建数据、清理测试数据等前置后置逻辑。有丰富的插件体系比如 pytest-html、allure-pytest、pytest-xdist 等。新手阶段不需要把 pytest 所有功能都摸透先掌握这几个就够用。4.2 fixture把登录和清理这类前置条件抽出来假设你要测“创建用户后查询用户”的场景前置条件是必须已登录。如果你在每个 test 函数里复制一段登录代码代码会变得很冗长而且登录失败时很难定位因为多个用例会同时失败你分不清是登录接口挂了还是业务接口挂了。fixture 就是用来解决这个问题的import pytest import requests BASE_URL https://api.example.com pytest.fixture(scopesession) def token(): resp requests.post( f{BASE_URL}/v1/login, json{username: admin, password: 123456}, timeout10, ) assert resp.status_code 200 body resp.json() assert body[code] 0 return body[data][token] pytest.fixture(scopesession) def session(token): s requests.Session() s.headers.update({Authorization: fBearer {token}}) return s def test_get_user_info(session): resp session.get(f{BASE_URL}/v1/user/info, timeout10) assert resp.status_code 200 assert resp.json()[code] 0这里有几个细节要注意。scope 设置为 session表示整个测试阶段只执行一次登录多个用例共享同一个 token。如果每个用例都登录一次不仅速度慢还容易触发服务端限流。如果你的系统对 token 有效期很短或者某些操作必须每次重新登录再将 scope 改为 function 也不迟。fixture 的返回值会被注入到测试函数参数里。参数名不要随便写因为 pytest 会按名字去查找对应的 fixture。你写def test_get_user_info(session)就必须存在一个名为 session 的 fixture否则会报 fixture not found。4.3 断言策略三层检查缺一不可写接口自动化断言时我一般会做三层检查。第一层HTTP 状态码。确保请求被服务端接受没有 404、500 这类系统级错误。示例assert resp.status_code 200第二层业务码。针对项目里常见的code字段做比较。这一步能区分“接口通了”和“业务真的成功”。body resp.json() assert body[code] 0 assert body[message] success第三层关键业务数据。如果必须返回用户 ID就检查 data 里有没有这个字段、是否大于 0、值是否符合预期。assert body[data][userId] 0 assert body[data][role] admin有些用例还需要更细的 schema 校验比如校验返回字段名称和类型。这一块可以先不学入门阶段做好三层断言已经能让问题暴露得很清楚。4.4 用例组织与失败快速定位Pytest 执行时可以按文件、按类、按函数筛选pytest cases/test_login.py -v pytest cases/test_login.py::test_wrong_password -v pytest cases -k login -v-k会用关键字匹配用例名适合临时跑一批关联用例。--maxfail1表示遇到第一条失败就停下来适合调试时快速定位问题。用例多了以后不要把所有文件平铺在一个目录里。通常可以按业务模块分文件比如 test_login.py、test_user.py、test_order.py。每个文件里再按场景拆函数。如果某个用例因为环境原因注定失败可以先标记跳过或预期失败import pytest pytest.mark.skip(reason该功能暂未上线) def test_not_online(): pass pytest.mark.xfail(reason已知缺陷先标记预期失败) def test_known_bug(): assert False这一阶段的关键转变是你不再通过 print 看结果而是让 pytest 告诉你通过、失败、跳过。只有这样做后续才可能接 CI因为 CI 只能看懂“进程退出码”和测试报告不能看懂你终端里打印的 JSON。5. 数据驱动和目录分层用例超过 50 条后别还在堆乱代码刚开始做接口自动化时每个测试文件里直接写 requests 请求也没什么问题。但是用例一旦超过 50 条重复代码开始变多修改一个公共地址要改 20 处新增一个环境就要复制一批文件。这时候就需要分层和参数化。5.1 先理解“框架三层”配置、接口封装、用例常见的接口自动化框架不是把代码放得复杂而是把职责分清楚配置层存放环境地址、超时、账号、数据库连接等全局信息。接口层把某个模块的请求封装成函数。例如 LoginApi 类里的 login 方法UserApi 类里的 get_user_info 方法。测试用例不直接拼 URL 和 headers而是调用这些方法。用例层只描述业务场景和测试数据不关心 HTTP 细节。一个典型的项目目录大致是这样的api_auto/ config/ settings.py api/ login_api.py user_api.py cases/ test_login.py test_user.py data/ login_data.yaml reports/ requirements.txt这样做有一个实际好处被测服务切换环境时只需要改配置层服务端某个接口路径变化时只需要改接口层新增业务场景时在用例层加数据和方法调用不需要动其他代码。5.2 用 parametrize 描述多组输入假设登录接口需要测正确密码、错误密码、用户不存在等场景。与其写三个几乎一样的 test 函数不如用参数化import pytest import requests BASE_URL https://api.example.com def call_login(username, password): return requests.post( f{BASE_URL}/v1/login, json{username: username, password: password}, timeout10, ) pytest.mark.parametrize( username,password,expected_code, [ (admin, 123456, 0), (admin, wrong_password, 1001), (nobody, 123456, 1001), ], ids[正确登录, 密码错误, 用户不存在], ) def test_login(username, password, expected_code): resp call_login(username, password) assert resp.status_code 200 assert resp.json()[code] expected_code参数化之后的每一条数据都会被 pytest 当成独立用例。你用-v执行时能看到“正确登录”“密码错误”“用户不存在”这些可读的用例名报告看起来也更清晰。注意 ids 里的字符串不能有歧义否则定位失败时不知道是哪一组数据。5.3 外部文件数据要不要引入参数化直接写在装饰器里适合数据量小的场景。如果用例数据很多比如 50 组账号、几百种商品数据继续写装饰器会让测试文件变得臃肿。这时候可以把数据放到 YAML 或 JSON 文件中。一个简单的 YAML 数据文件# data/login_data.yaml - username: admin password: 123456 expected_code: 0 case_id: login_success - username: admin password: wrong expected_code: 1001 case_id: login_wrong_password然后用 fixture 读取import pytest import yaml pytest.fixture(scopesession) def login_cases(): with open(data/login_data.yaml, encodingutf-8) as f: return yaml.safe_load(f)但这只是把数据搬到外部测试用例还是要参数化。真正应用时你还需要确定期望字段怎么维护。我见过很多团队为了做“数据驱动”写了非常重的读取 Excel 模板最后反而没人能改数据这是一个需要警惕的过度设计。5.4 “搭框架”的边界别把简单项目变成重框架网络上经常看到“接口自动化测试框架怎么搭建”这类问题。很多人会把关键字驱动、报告平台、任务调度、代码生成器全部塞进项目里结果项目还没跑起来先被框架本身的学习成本压垮。我的观点是requests pytest fixture parametrize 本身就可以构成一套轻量框架。如果你的业务复杂度不高只要按配置层、接口层、用例层三层分好目录就已经很清晰。只有当团队有多人协作、需要重复执行大量数据、要接不同的被测系统时才考虑引入更重的基础组件。入门阶段最好的框架是“别人看目录结构就能明白你在做什么”的框架而不是“技术名词最多”的框架。6. 报告和持续集成接口自动化能交给 Jenkins 才是完整闭环本地能跑通 pytest只说明你已经能用代码执行用例。但接口自动化的价值很大一部分来自“可重复、可定时、可提醒”。如果每次都靠人手动打开终端敲 pytest那它还不是真正意义上的持续集成。6.1 先让本地能产出 HTML 报告先把报告插件用起来pytest cases -v --htmlreports/report.html --self-contained-html--self-contained-html会把 CSS 和 JS 嵌入 HTML 文件里这样报告单文件就能直接打开不需要额外访问网络资源。报告会展示用例总数、通过数、失败数、失败信息、执行时间给别人看也足够直观。如果你后续使用 Allure步骤会变成pytest cases --alluredirallure-results allure serve allure-resultsAllure 报告更好看但需要额外安装命令行工具也会引入更多配置。第一轮学习不必强上先把 pytest-html 跑明白等团队确实有报告美观需求时再迁移。6.2 用一个简单 Jenkins Job 把 pytest 跑起来Jenkins 在这里扮演的角色是执行者。你可以在 Jenkins 上新建一个自由风格项目配置 Git 仓库地址再在“构建步骤”里执行 shell 命令。常见的一段构建命令cd api_auto if [ ! -d .venv ]; then python3 -m venv .venv fi source .venv/bin/activate pip install -r requirements.txt python -m pytest cases -v --htmlreports/report.html --self-contained-html这段命令做的事情非常直观进入项目目录如果没有虚拟环境就创建然后激活虚拟环境安装依赖最后执行测试。Jenkins 每跑一次都会生成一份新的报告。要注意的是Jenkins 执行机如果有多个项目尽量每个项目都使用自己的虚拟环境不要共用一个全局环境否则 A 项目升级 requests 可能影响 B 项目的测试。6.3 想更工程化Jenkinsfile 到底在描述什么自由风格项目适合演示真实团队更常用 Pipeline。Pipeline 的本质是把 CI 流程写成代码存到仓库里Jenkins 读 Jenkinsfile 后按阶段执行。一个最简的 Jenkinsfile 示意pipeline { agent any stages { stage(Checkout) { steps { checkout scm } } stage(Run API Tests) { steps { sh cd api_auto python3 -m venv .venv . .venv/bin/activate pip install -r requirements.txt python -m pytest cases -v --htmlreports/report.html --self-contained-html } } } post { always { publishHTML(target: [ reportDir: api_auto/reports, reportFiles: report.html, reportName: API Test Report ]) } } }这段代码不是拿来直接抄就能跑因为每个 Jenkins 的插件和权限配置会有差异。真正落地时你要根据自己的 Git 地址、执行机路径、Python 解释器和目录结构做调整。如果你想了解更细的 pipeline 语法可以参考 Jenkins 官方文档或先手动跑通自由风格项目再用 pipeline 替换。Pipeline 的好处是可以把“拉代码、装依赖、跑测试、发报告、发通知”写成一个可版本化的文件。别人一看就知道接口自动化的 CI 是怎么执行的不需要登录 Jenkins 一个个点配置。6.4 集成后的资源、超时和限流参数接口测试放进 CI 之后要额外关注几个参数。并发限制。如果多个 Jenkins Job 同时跑或同一个 Job 里开了 pytest-xdist 多进程流量可能瞬间翻倍导致被测环境出现 429。不要为了追求跑得快就无限加并发。第一轮先单进程跑能稳定了再加并发。任务超时。Jenkins 侧可以设置超时时间比如 30 分钟跑不完就标记失败。否则测试任务可能因为某个接口卡住而长期占用执行机。失败通知。接口测试失败不一定都是代码问题也可能是被测环境不稳定。但 CI 的目的是及时暴露问题不要因为“这个接口经常偶尔失败”就直接关掉通知。更好的处理是先定位是测试环境问题、脚本问题还是产品缺陷再决定要不要调整用例。定时构建。可以选每天凌晨跑一次避开业务高峰期。Jenkins 的 cron 支持H 2 * * *这种哈希写法意思是每天凌晨 2 点左右执行避免多个任务在整点同时挤在一起。持续集成的核心价值不是替代人肉点击而是让接口测试成为代码提交或发布流程里的一个检查关卡。每次合并代码前自动跑一遍关键接口有问题提前暴露这才是“持续集成测试”真正值得做的地方。7. 6 小时学习路线和自检清单你能跑通什么不能指望什么最后把 6 小时拆开给出一份可以直接照着执行的时间分配。这里默认你已经了解一点 Python 语法知道变量、函数、字典是什么如果完全没有 Python 基础请把时间拉长到 8 到 9 小时。7.1 按小时拆分的第一轮练习时间段目标练习内容第 1 小时环境准备安装 Python创建项目目录和虚拟环境安装 requests、pytest、pytest-html跑通一条 demo 用例第 2 小时Requests 请求写一段 POST 登录请求写一段 GET 查询请求打印状态码和 JSON 响应第 3 小时Pytest 基础把 Requests 代码改成 pytest 用例用 assert 断言状态码和业务码第 4 小时fixture 和会话把登录封装成登录接口方法用 fixture 返回带 token 的 session第 5 小时参数化与分层给登录接口补充多组错误密码数据用 parametrize 参数化整理目录结构第 6 小时报告和 CI生成 pytest-html 报告手动在 Jenkins 或本地命令行模拟一次自动执行很多人的问题是第 1 小时被安装卡住就放弃了或者在 Requests 上反复纠结各种高级用法。接口自动化的学习节奏应该是先把链路跑通一个接口、一条用例、一份报告。通了之后再往多接口、多数据、多环境扩展。7.2 每完成一段怎么自检不要只跟着练完就觉得自己会了要给自己设验收标准。环境准备好后能新建一个空目录从零创建一个虚拟环境并跑通 pytest。Requests 学完后能对一个实际接口完成 GET 和 POST 请求并能区分 URL、params、headers、body、timeout 各自的作用。Pytest 学完后能把一条接口请求写成测试函数失败时能通过 pytest 的错误信息定位是断言失败还是请求失败。数据驱动学完后能用 3 组以上参数化数据描述同一个接口测试并能通过用例名区分是哪组输入失败了。报告和 CI 学完后能不看教程独立配置一个新的 Jenkins 自由风格项目执行完成后能在浏览器里打开 HTML 报告。如果上面这些都能做到说明你已经完成了一个合格的接口自动化最小闭环。7.3 真正容易卡住你的不是代码而是这几个场景第一类场景是每次运行结果都不一样。这通常不是脚本不稳定而是测试数据没隔离。比如创建用户用例重复跑用户名唯一性校验导致第二次失败。接口自动化里很多问题都需要处理数据清理你可以在测试前先删除旧数据或者在用例结束后调用清理接口。第二类场景是上游依赖接口不稳定。下单接口依赖登录登录接口又依赖用户服务。如果只是把登录写在每个用例前面一旦用户服务宕机所有用例都会失败。这时候要先确认测试环境是否正常不要急着去改脚本逻辑。第三类场景是被动等待太多。看到请求失败就加 sleep或者失败后无限重试。sleep 只能让问题变慢不能解决问题。重试可以有但要有限度和退避策略。比如遇到 429退避几秒后再试一到两次如果仍然失败就标记为失败保留日志而不是无休止地刷请求。7.4 下一步能力提升方向第一轮闭环跑通之后想继续深入可以按这个顺序练习掌握更多 pytest 用法比如 fixture conftest.py 共享、yield fixture 做清理、自定义钩子。掌握更多 Requests 用法比如文件上传、流式响应、超时重试策略。学习接口测试数据构造包括从数据库准备数据、通过平台造数、调用上游接口间接造数。学习报告增强把 pytest-html 或 Allure 报告接入 Jenkins并增加趋势图。了解多环境支持比如 dev、test、staging 通过配置文件切换。如果只是做业务团队内部的接口回归不一定需要把平台做得多复杂。真正值钱的是你能稳定描述业务场景、准确断言结果、快速定位失败原因。框架再简单能持续跑出有效反馈就有价值框架再华丽里面装的用例全是无效断言也只是自我感动。练习接口自动化技术的最终标准其实是让测试结果可以被信任它说你挂了就是真的有问题它说通过了团队敢放心发布。只要能守住这条线你的 Requests 和 Pytest 组合就已经在团队里发挥作用了。