做测试自动化的朋友应该都听过 pytest如果你还没用过它那我强烈建议你认真看完这篇。pytest 是目前 Python 生态里最主流、最灵活的自动化测试框架不管你是做单元测试、接口测试还是 UI 自动化它都能帮你把用例组织得明明白白。我最早接触 pytest 的时候还在用 unittest 写用例写起来又长又啰嗦setup 和 teardown 来回折腾。换成 pytest 之后最直观的感受就是代码量少了一半断言直接用 assert 关键字fixture 机制更是把测试数据的准备和清理变得优雅。这篇文章不扯理论直接结合我实际项目里的经验从安装配置、第一个用例、fixture 核武器到接口自动化和 UI 自动化的完整落地把 pytest 这套东西讲透。不管你是刚入行的测试新人还是写了不少用例的老手这篇文章应该都能帮你少走一些弯路。1. 为什么选择 pytest抛开 unittest 和 nose 的纠结很多初学者会纠结该选哪个测试框架我当年也纠结过。其实答案很明确现在做 Python 自动化测试选 pytest 基本不会错。它不是什么新玩意儿但生态和社区活跃度一直排在前面尤其在接口测试和 UI 自动化这两个领域pytest 几乎成了事实标准。1.1 一个简单用例看三种框架的差距先看一段最直观的对比。同样写一个简单的加法函数测试用 unittest 大概是这个画风import unittest def add(a, b): return a b class TestAdd(unittest.TestCase): def setUp(self): # 每次用例前的准备工作 self.a 1 self.b 2 def tearDown(self): # 每次用例后的清理工作 pass def test_add(self): result add(self.a, self.b) self.assertEqual(result, 3) if __name__ __main__: unittest.main()换成 pytest同样的事情只需要这样def add(a, b): return a b def test_add(): assert add(1, 2) 3区别是肉眼可见的unittest 要求你写类、继承 TestCase断言得用 self.assertEqual 这一套 API代码量翻倍不说可读性也差。pytest 直接写普通函数断言就是 Python 原生的 assert 关键字失败信息还特别详细能自动告诉你左边等于什么、右边等于什么、中间差在哪。我当时把项目从 unittest 迁到 pytest几百条测试用例实际改起来很快大部分工作就是把 self.assertEqual 改成 assert再把 setUp 和 tearDown 换成 fixture。1.2 插件生态从报告到重试一站式解决pytest 真正拉开差距的地方是插件生态。与其说 pytest 是一个框架不如说它是一个平台。官方和社区贡献的插件覆盖了几乎所有测试场景我日常用到的有这么几个pytest-html生成 HTML 格式的测试报告一条命令搞定不需要额外写代码。pytest-xdist分布式执行用例多核机器上能把用例跑出好几倍的加速效果。pytest-rerunfailures用例失败自动重试做接口自动化的时候特别有用能有效应对网络抖动。pytest-cov集成 coverage.py查看代码覆盖率。pytest-playwrightUI 自动化直接提供浏览器 fixture后面会细讲。allure-pytest接入 Allure 报告生成超豪华的可视化报告适合交付给团队或客户看。这还只是冰山一角。unittest 解决这些需求几乎都得自己造轮子要么写一个基类封装公共逻辑要么引入一堆第三方工具再拼拼凑凑维护成本很高。pytest 提供了一个统一的入口装好插件就能直接跑这是它在工程效率上最大的优势。1.3 社区现状与长期维护价值还有一个很实际的考量招人容易、资料好搜。现在简历上写熟悉 pytest 的测试工程师明显比写 unittest 的多。GitHub 上开源项目用 pytest 做 CI 的占比也非常高JetBrains 的 PyCharm 直接内置了对 pytest 的完善支持Visual Studio Code 的 Python 插件同样默认推荐 pytest 配置。作为测试工程师掌握 pytest 更像是掌握一项基础技能而不是只会一个冷门工具。2. 环境准备与第一个用例从 pip 到 Pycharm 跑通先把环境搭起来。这一步看着简单但我见过太多新手卡在这里原因五花八门装到了错误的 Python 环境、PyCharm 里测试运行器没配好、文件名不符合 pytest 的收集规则。一个个说。2.1 安装 pytest 的正确姿势安装本身不复杂打开命令行执行pip install pytest如果你想装最新版本或者后续还需要那些常用插件可以一次性装齐pip install pytest pytest-html pytest-xdist pytest-rerunfailures但这里有个非常关键的前提务必先确认你当前用的是哪个 Python 环境。很多新人喜欢直接在系统 Python 里装结果后面项目多了A 项目要 pytest 6B 项目要 pytest 8冲突就来了。我的建议是从一开始就养成用虚拟环境的习惯python -m venv .venv source .venv/bin/activate # Windows 下是 .venv\Scripts\activate pip install pytest装完以后验证一下版本确认装到了正确的环境里pytest --version如果命令行提示找不到 pytest大概率是环境变量或者当前 shell 没激活虚拟环境。我自己踩过的一个坑是明明刚 pip install 过 pytest命令行执行 pytest 却报 command not found。后来一看原来是 pip 装到了某个全局 Python 路径而当前 shell 使用的是另一个 Python 解释器。解决办法很简单用 python -m pytest 来替代 pytest 命令python -m pytest用这种写法Python 会自动从当前环境查找 pytest基本不会出现认错环境的问题。2.2 第一个测试用例断言与运行方式新建一个文件 test_demo.py注意文件名必须以 test_ 开头或者 _test.py 结尾这是 pytest 的默认收集规则。文件内容可以是最简单的def test_demo(): assert 1 1 2在命令行运行python -m pytest test_demo.py -v-v 参数会输出详细的用例名和执行结果你会看到collected 1 item test_demo.py::test_demo PASSED写好了测试用例用 PyCharm 跑也很方便。但这里有一个我见到频率最高的问题PyCharm 里右键运行测试时有时会默认调用 unittest 运行器导致明明写的是 pytest 用例却不被识别提示 No tests were found。解决办法是手动指定测试运行器。打开 PyCharm 的设置界面macOS 上是 PyCharm PreferencesWindows 上是 File Settings找到 Tools Python Integrated Tools Testing。在默认测试运行器Default test runner下拉框里选择 pytest保存。以后再右键运行测试文件PyCharm 就会使用 pytest 运行器并且会自动帮你生成一个运行配置里面默认加上了 --no-header --no-summary -q 之类的参数方便在面板里输出简洁结果。还有一个细节如果你的项目目录结构不是标准的记得在配置里把 Working directory 设置成项目根目录不然 pytest 可能找不到 conftest.py 或者测试数据文件。2.3 用例发现规则与命名约束pytest 能自动找到你的用例靠的是一套隐式约定理解这套约定就能避免大量为什么我的测试没跑的问题。默认规则总结成三句话按优先级排列文件名匹配文件名为 test_*.py 或 *_test.py 的会被收集其他文件一律忽略。函数名匹配文件中以 test_ 开头的函数会被视为测试用例。类名匹配文件中以 Test 开头的类其内部的 test_ 开头的方法会被视为测试用例但类不能有init方法。这套约定初看会觉得隐式得有点不踏实但它的价值恰恰在零配置。你只要按规则命名pytest 就能自动把整个项目目录扫描一遍把所有用例找出来。我接手过一个大项目测试用例分布在十几个目录里靠这套规则直接全部发现了根本不需要在配置里逐个注册省心得很。2.4 常用命令行参数快速上手命令行参数是日常使用频率最高的东西先列几个最实用的-v 输出更详细的用例执行信息 -k 关键词 按表达式筛选用例例如 -k login or register -m 冒号表达式 按标记筛选用例例如 -m slow -x 第一次失败就停止执行适合快速回归 --lf 只运行上一次失败的用例 --tbshort 输出简短的 traceback 信息 -s 显示 print 输出调试时特别有用 -q 简化输出只显示最终结果我调试用例的时候最常用的是 -s 加上 print因为 pytest 默认会捕获输出不加 -s 的话 print 内容不会显示很容易让新手误以为代码没执行到。3. fixture 机制pytest 的核武器如果说 pytest 只能选一个最值得学习的特性我的答案一定是 fixture。很多从 unittest 转过来的同学一开始不太理解 fixture 到底是个什么东西总觉得不如 setUp 和 tearDown 直观。但我用一句话概括fixture 就是一个可以被测试函数自动注入的依赖准备函数。理解这句话后面就顺了。3.1 fixture 是什么从 setup/teardown 的痛点说起先回顾 unittest 的老写法每一个测试类里面都要写 setUp 和 tearDown如果几个测试类都需要准备相同的数据就只能写一个公共基类然后让测试类继承。这种继承关系一旦超过两层代码就变得很难维护。更麻烦的是setUp 和 tearDown 是成对出现的你没法说这个用例只需要准备 A 数据不需要清理 A 数据只需要清理 B 数据。所有用例用同一套准备和清理逻辑灵活性很差。fixture 的写法长这样import pytest pytest.fixture def user(): 准备一个测试用户 u {name: admin, role: admin} return u def test_check_admin(user): assert user[role] admin这个 user 函数就是一个 fixture。当一个测试函数的参数列表里写上了 user 这个名字pytest 就会自动去查找同名 fixture执行它然后把返回值注入给测试函数。这本质上是依赖注入而不是继承。好处很明显每个测试函数只声明自己需要的依赖其他的一概不管。3.2 明确 fixture 作用域与自动使用fixture 还有一个非常好的参数叫 scope用来控制 fixture 的生命周期可选值有四个scope 值生命周期典型场景function默认每个测试用例执行前后各调用一次临时数据、独立环境class每个测试类执行期间调用一次类级共享资源如类级浏览器实例module每个模块文件执行期间调用一次模块内共享的数据集session整个测试会话期间只调用一次数据库连接、登录 token、全局配置用法非常简单pytest.fixture(scopesession) def login_token(): 整个测试会话只登录一次返回 token token fake-token return token def test_get_user_info(login_token): assert login_token我实际项目里的经验是如果接口测试用例非常多每个用例都登录一次时间成本完全无法接受。这时候把登录 token 设计成 session 级别的 fixture登录一次所有用例共用整个测试套件的时间能缩短一个数量级。但对应的代价是用例之间的隔离性变差了——如果某个用例改动了用户状态后面的用例可能会受影响。所以建议对共享的 fixture要约定只能做只读操作或者使用不可变的数据结构。还有一种情况是用 autouse它让 fixture 自动生效甚至不需要测试函数在参数里声明pytest.fixture(autouseTrue) def track_running(): 自动记录当前正在执行的用例名 print(开始执行)outouse 适合用来统一做一些环境准备、环境检查、日志标记一类的事。但我不建议大量使用 autouse因为它会让 fixture 的执行变得隐式反而失去显式依赖声明带来的可读性。3.3 conftest.py跨文件共享的魔法fixture 写在测试文件里只能作用于当前文件要实现跨文件共享pytest 给出了一个约定conftest.py。这个文件会被 pytest 自动加载里面的 fixture 对当前目录及其子目录下的所有测试文件都可见。目录结构可以是这样的project/ ├── conftest.py # 全局共享 fixture ├── testcases/ │ ├── conftest.py # 局部共享 fixture只对 testcases 目录生效 │ ├── test_login.py │ └── test_order.py └── data/ └── test_data.json全局的 fixture 放在项目根目录的 conftest.py 里比如数据库连接、全局配置、日志对象。局部业务相关的 fixture 放在对应模块目录的 conftest.py 里比如登录的 token、创建订单的辅助函数。pytest 在查找 fixture 时会从测试文件所在目录逐级向上查找 conftest.py找到一个就用一个所以同名 fixture 里离测试文件更近的那一个优先生效。这里有个非常隐蔽的坑conftest.py 文件本身不会被收集为测试用例如果你在里面写了测试函数不会被执行。另外conftest.py 这个名字不能改改了 pytest 就不认了。3.4 参数化用一组数据测多个场景接口测试里最常见的需求就是同一个接口用多组入参验证不同场景。这时候就要用参数化。import pytest import requests pytest.mark.parametrize(account, password, expected_code, [ (admin, correct, 200), (admin, wrong, 401), (, , 400), (None, password, 422), ]) def test_login_cases(account, password, expected_code): resp requests.post(http://localhost:8000/api/login, json{account: account, password: password}) assert resp.status_code expected_code这样写一遍pytest 会自动生成 4 条用例记录每条用例的失败信息都是独立的互不影响。多参数可以组合使用pytest.mark.parametrize(env, [test, dev]) pytest.mark.parametrize(user, [admin, guest]) def test_combination(env, user): pass这两层参数化会产生笛卡尔积的效果2 × 2 4 条用例。参数多的时候要留意组合数我自己遇到过 3 层参数化直接生成几百条用例的情况跑起来一时半会儿结束不了后来才学会用 -k 表达式筛选特定参数组合先做快速验证。4. 接口自动化实战从零搭建一个可维护的测试体系聊完 fixture 的原理我们来点实际的。我根据自己做过的一个项目完整拆解一下用 pytest 做接口自动化测试的落地过程。这个项目的背景是被测系统是一个前后端分离的 Web 服务后端提供 RESTful API大概三十多个接口涉及登录、用户、订单、支付几个核心模块。团队希望在版本迭代时能快速回归接口功能。4.1 目录结构与依赖设计好的测试项目目录结构一开始就要设计好不能想到哪写到哪。我常用的是这套结构api_test_project/ ├── requirements.txt ├── pytest.ini ├── conftest.py ├── api/ # 封装接口请求 │ ├── __init__.py │ ├── base.py │ ├── user_api.py │ └── order_api.py ├── data/ # 测试数据 │ ├── user_data.json │ └── order_data.json ├── testcases/ # 测试用例 │ ├── __init__.py │ ├── test_login.py │ ├── test_user.py │ └── test_order.py ├── utils/ # 通用工具 │ ├── __init__.py │ └── helpers.py └── reports/ # 测试报告输出三层分离的思想api 层负责和 HTTP 接口打交道testcases 层只关注业务断言data 层负责测试数据。这样分工的好处是接口的 URL 改了只需要改 api 层字段校验逻辑变了只需要改 testcases 层新增测试数据只需要在 data 层加数据。requirements.txt 里把依赖写清楚pytest8.0 requests2.31 pytest-html4.0 pytest-rerunfailures13.0 pytest-xdist3.5pytest.ini 配置文件里可以放一些固定参数避免每次都在命令行里重复敲[pytest] testpaths testcases addopts -v --tbshort --htmlreports/result.html --self-contained-html注意这里面加了一个 --self-contained-html 参数它的作用是让 pytest-html 生成的报告里带上所有 CSS 和 JS单独打开 HTML 文件就能看完整样式而不是依赖一堆外部资源文件。不加这个参数报告发给同事的时候经常样式丢失坑得很。4.2 接口测试断言技巧不只是状态码接口测试第一反应是断言状态码 200但只断状态码远远不够。我见过最典型的翻车场景是接口返回了 200但业务码是错误码响应体里是 { code: 50001, message: 参数错误 }。所以断言要分层先验证 HTTP 状态码再验证业务码再验证关键字段值。我习惯用 requests 库封装一个简单的基础请求模块# api/base.py import requests class BaseAPI: def __init__(self, base_url, tokenNone): self.base_url base_url self.session requests.Session() if token: self.session.headers.update({Authorization: fBearer {token}}) def get(self, path, **kwargs): return self.session.get(self.base_url path, timeout10, **kwargs) def post(self, path, **kwargs): return self.session.post(self.base_url path, timeout10, **kwargs)超时设置是重中之重不加 timeout 的请求一旦服务端响应很慢整个测试会一直卡在那里而且毫无提示。我这里统一设置 10 秒超时还可以结合 pytest-rerunfailures 做失败重试应对偶发性的网络抖动。在断言业务字段的时候我后来发现一个很实用的简化思路不需要每次都写复杂的嵌套取值代码。如果是 JSON 响应直接取键即可def test_create_order_return_order_id(): resp order_api.create_order(...) assert resp.status_code 200 body resp.json() assert body[code] 0 assert body[data][orderId] 0但对于嵌套特别深的响应结构与其写一长串 [data][xxx][yyy]不如写一个工具函数来取动态路径# utils/helpers.py def get_value_by_path(data, path): 按点号分隔的路径取值如 data.order.id keys path.split(.) cur data for k in keys: if isinstance(cur, dict) and k in cur: cur cur[k] else: return None return cur然后在测试里assert get_value_by_path(body, data.order.id) expected_order_id这个思路是从 JSONPath 简化来的代码短了一大截够用且好维护。4.3 数据驱动从 JSON 文件读取测试数据工程化到一定规模后参数化数据不应该写死在代码里而是放进数据文件。以用户模块为例data/user_data.json 里存放{ invalid_user: [ {account: , password: 123456, expected_code: 400}, {account: admin, password: , expected_code: 400}, {account: admin, password: wrong, expected_code: 401} ] }测试文件里读取这些数据再交给参数化import json import pytest from api.user_api import UserAPI with open(data/user_data.json, encodingutf-8) as f: user_data json.load(f) pytest.mark.parametrize(case, user_data[invalid_user]) def test_invalid_user(case): resp UserAPI.login(case[account], case[password]) assert resp.status_code case[expected_code]这种方式有一个隐性问题要注意模块加载时读取 JSON 文件意味着文件路径是相对于进程的工作目录。如果 pytest 不是从项目根目录启动的路径会报错。我的经验是始终在 pytest.ini 里配置好 testpaths或者用 pathlib 基于当前文件位置计算绝对路径import json from pathlib import Path DATA_DIR Path(__file__).resolve().parent.parent / data with open(DATA_DIR / user_data.json, encodingutf-8) as f: user_data json.load(f)用 Path(file) 定位数据文件不会因为当前工作目录不同而找不到文件这个细节能省掉很多莫名其妙的报错。4.4 测试报告与持续集成的衔接接口测试跑完之后第一件事就是看报告。pytest-html 生成的报告比较朴素但胜在零配置。命令行直接跑python -m pytest --htmlreports/result.html --self-contained-html跑完以后reports/result.html 里会有每个用例的通过/失败状态、执行时间、失败时的 traceback 信息足够日常回归使用。如果团队或者客户需要更美观的报告Allure 是另一个方案。Allure 本质上是一个报告服务pytest 只负责生成包含测试结果的数据文件再由 Allure 命令行工具渲染成网页。基本步骤是pip install allure-pytest在 pytest.ini 里加上 --alluredirreports/allure-results跑完测试后在项目根目录执行allure generate reports/allure-results -o reports/allure-report --clean allure open reports/allure-report前面那个 --clean 参数很关键它先清空输出目录再生成避免旧报告残留导致渲染错乱。Allure 的报告比 pytest-html 丰富很多能看到用例分类、历史趋势、执行时间分布。但它的依赖也重本地得装 Java 和 allure 命令行工具所以小项目我更推荐先用 pytest-html等报告确实不够用了再上 Allure。在 CI 里跑接口自动化也简单。以常见的 Jenkins 或 GitLab CI 为例核心就是执行同一行命令再把报告文件归档。我一般会在 CI 脚本里加上这两个参数python -m pytest --maxfail5 --reruns2 --htmlreports/result.html --self-contained-html--maxfail5 表示失败 5 个用例就停止避免大量失败用例刷屏浪费时间--reruns2 表示每个失败用例自动重试两次可以在网络抖动场景下减少偶发失败。这里有一个点想提醒大家重试适合用在稳定的接口回归如果接口本身有 bug重试只是拖慢测试时间不会有任何帮助。CI 上建议把重试次数调到 1 或者 0真正发现问题就让它快速失败。4.5 fixture 的接口实战组合案例把前面的内容串联成一个完整场景测试下单流程需要先登录拿到 token再用 token 创建订单。import pytest from api.user_api import UserAPI from api.order_api import OrderAPI pytest.fixture(scopesession) def login_token(): 整个测试会话期间只登录一次返回 token resp UserAPI.login(admin, password) assert resp.status_code 200 assert resp.json()[code] 0 return resp.json()[data][token] pytest.fixture() def order_api(login_token): 每个用例创建一个独立的 OrderAPI 实例 return OrderAPI(base_urlhttp://localhost:8000, tokenlogin_token) def test_create_order(order_api): resp order_api.create_order({productId: 1, quantity: 2}) assert resp.status_code 200 body resp.json() assert body[code] 0 assert body[data][orderId] 0 def test_query_order(order_api): resp order_api.query_order(order-123) assert resp.status_code 200 assert resp.json()[code] 0注意到一个细节order_api 这个 fixture 是 function 作用域每个用例单独创建 OrderAPI 实例但 token 是 session 作用域整个测试过程只登录一次。这种大共享 小隔离的设计是我实际操作下来最舒服的状态既省了重复登录的时间又避免了用例之间因共用实例而互相污染状态的情况。5. UI 自动化扩展pytest 是 selenium/playwright 的最佳搭档接口自动化到位之后UI 自动化是很多团队的下一步。这时候 pytest 的价值同样明显因为 Selenium 和 Playwright 本身都不是测试框架它们只是自动化操作浏览器的库测试的组织、断言、报告、重试还得靠 pytest 来管。5.1 为什么 UI 自动化要用 pytest 管理很多新手刚开始玩 Selenium写出来的脚本是线性代码打开浏览器、操作、关闭、跑完。这种脚本最大的问题是没有用例概念没有断言体系出错就不知道自己错在哪。pytest 正好补上这块拼图。一个经典的 Selenium pytest 的 fixture 结构长这样import pytest from selenium import webdriver pytest.fixture() def driver(): driver webdriver.Chrome() driver.implicitly_wait(10) yield driver driver.quit() def test_search_keyword(driver): driver.get(https://example.com) assert Example in driver.title这里用到 yield 的关键用法yield 之前的代码在用例开始前执行yield 之后的代码在用例结束后执行。这就完美替代了 unittest 里的 setUp 和 tearDown。每个用例拿到的 driver 都是独立的用例结束后浏览器会自动关闭不会出现浏览器越开越多、内存爆掉的问题。5.2 playwright 的好搭档更高的集成度最近一两年Playwright 的热度非常高它的浏览器操作更稳定而且天生支持多浏览器和并发。pytest-playwright 插件直接把两者打通了安装插件之后pytest 会自动管理浏览器生命周期测试函数里直接声明 page 参数即可。import pytest def test_example(page): page.goto(https://example.com) assert page.title() Example Domain这背后和 Selenium 的思路是一致的只是通过 pytest-playwright 把浏览器和页面对象的创建、回收全部接管了。试想如果用纯 Playwright 脚本手动创建浏览器上下文代码会多一大截而且每个用例都要重复处理启动和关闭。用 pytest 之后这些操作都变成了一件默认已经准备好的事。UI 自动化的用例组织、断言、报告体系全部可以直接复用 pytest 的能力。从维护成本看这是目前性价比最高的 UI 自动化落地方案之一。5.3 避免的坑用例隔离与浏览器实例复用UI 自动化有一个真实的教训为了追求性能把浏览器实例的作用域设成 session所有用例共用同一个浏览器。这种做法最开始跑得挺快但用例一旦变多问题就来了——上一个用例的登录状态、弹窗、页面跳转都会对下一个用例造成干扰用例失败率直线上升。最难受的是这些问题还不是每次必现的排查起来特别折磨人。我的建议很明确UI 自动化默认用 function 作用域每个用例一个干净的浏览器环境。虽然启动浏览器的开销高一些但换来的是用例之间的完全隔离。等用例量级上来之后再考虑用 pytest-xdist 做并发执行来弥补性能开销而不是牺牲隔离性。并发跑多个浏览器时每个 worker 进程里都有独立的浏览器实例互不干扰。6. 常见问题与排查技巧实录最后这一部分我把自己和周围同事踩过的坑集中整理一遍。很多问题你搜资料也能搜到但散落在不同地方这里我尽量一条条说清楚。6.1 PyCharm 运行不识别测试用例症状在 PyCharm 里右键运行一个 test_demo.py 文件控制台提示 No tests were found但明明文件里有 test_ 开头的函数。排查思路按优先级排检查运行配置里的测试运行器。最常见的原因就是默认运行器还是 unittest。按照前面说的在 Settings Tools Python Integrated Tools Testing 里改成 pytest。检查文件名。文件是不是叫 test_demo.pypy 文件名的前缀或后缀必须符合规则。如果文件在某个包目录下确认目录下有没有init.py没有的话 pytest 也能识别但某些 IDE 的右键运行行为会变得奇怪。检查 pytest 是否安装到了当前环境。命令行执行 python -m pytest test_demo.py如果命令行能跑通、IDE 不能那就是 IDE 的解释器配置不对确认 PyCharm 里选的是同一个虚拟环境。另外如果项目里同时有 unittest 和 pytest 混用右键运行的时候偶尔会跑到 unittest 运行器去收集用例然后报错。这种情况直接把运行器统一成 pytest 就好。6.2 fixture 重名和 conftest 加载顺序困惑症状明明在 conftest.py 里定义了一个 fixture但测试文件里死活调不到或者两个同名 fixture 互相覆盖不知道哪个生效。首先pytest 查找 fixture 的机制是从测试文件所在目录开始往上查找。比如测试文件在 project/testcases/test_user.pypytest 会先找 project/testcases/conftest.py再找 project/conftest.py。如果上下层都定义了同名 fixture离测试文件更近的那个会获胜。这不是 bug而是刻意设计的层级覆盖能力。其次如果你非常确定 conftest.py 就在那但就是调不到先检查一下文件名拼写是否准确conftest.py 拼错一个字母pytest 就完全不认它了。还有一个易错点同一级目录下有多个 conftest.py 且内容有误pytest 在导入时可能直接报错但报错信息会被隐藏表现出来是fixture 找不到。遇到这种情况先试试在命令行跑一遍 pytest --collect-only它会强制 pytest 去加载所有测试模块和 conftest并显示详细导入错误。6.3 断言失败看不懂症状用例失败控制台报了一大堆 traceback看半天没明白断言到底哪一步错了。pytest 的断言失败信息本身带 diff 能力但如果断言在复杂的表达式里比如 assert a b and c d它只会告诉你整条表达式为 False但不告诉你哪一段失败。解决办法是拆成多条断言一条断言只验证一件事assert resp.status_code 200 assert resp.json()[code] 0 assert resp.json()[data][count] 1这样失败信息立刻能定位。还可以加自定义消息assert body[code] 0, f业务码异常期望 0实际 {body[code]}响应体{body}实际排查时--tbshort 能让 traceback 信息精简很多--locals 能额外显示每一条局部变量的值这两个参数配合基本能解决九成的不知道失败现场长什么样的问题。6.4 参数化一多就混乱症状一个参数化的用例生成了几十条记录跑的时候分不清哪组数据对应哪条失败。解决方案是给每组参数起一个可读的 id。pytest 支持在参数中直接指定 idpytest.mark.parametrize(account,password,expected_code, [ pytest.param(admin, correct, 200, idcorrect_password), pytest.param(admin, wrong, 401, idwrong_password), pytest.param(, , 400, idempty_fields), ]) def test_login(account, password, expected_code): ...如果不使用 idspytest 会自动给用例名加上参数值但如果参数太长或者包含不可读的特殊字符报告里会很难看。加了 id 之后报告里显示的就是 test_login[correct_password] 这种一目了然的名字失败定位快很多。6.5 测试顺序依赖问题症状单独跑某个用例能通过全量跑却失败说明用例之间有顺序依赖。这是测试领域最经典的禁忌。pytest 默认按照文件名的字典序执行测试例如 test_b.py 会在 test_a.py 之后执行同文件内按函数定义顺序执行。如果你在某个用例里写了改变全局状态的操作就可能影响后续用例。解决办法是每个用例必须自包含前置条件和清理逻辑能用 fixture 就用 fixture用 yield 清理状态。对于需要有序执行的场景不要因为习惯上应该先登录再测下单就把用例写在一个文件里而是用 fixture 的依赖关系来保证。如果实在难以避免才使用 pytest-ordering 插件通过 pytest.mark.order(n) 指定执行顺序但这属于非常规手段能不用就不用。写在最后的一点私货说句个人体会pytest 上手成本很低但能走多远取决于你对 fixture 和工程化的理解。很多人学会一套接口自动化模板之后就一直用那一套时间长了就会觉得 pytest 不过如此。其实它的能力远不止于此从插件开发到自定义标记、从 hooks 到集成报告服务每一层都有值得深挖的东西。我自己实操下来最推荐的做法是拿一个真实的项目练手从几十条用例开始逐步加上参数化、fixture 分层、数据驱动和 CI 集成你会发现测试框架这件事越用越顺手。最后再分享一个小技巧去 pytest 的官方文档里翻一翻内置 fixtures 的列表tmp_path、capsys、monkeypatch 这些内置工具非常能打用好它们能省掉很多自造轮子的时间。