1. 为什么 Pytest 成了 Python 测试的事实标准1.1 从 unittest 到 Pytest 的迁移逻辑如果你写过 Python 的单元测试大概率是从unittest起步的。它是标准库自带的不用额外装包类继承、self.assertEqual那一套写起来也算规整。但写过几个模块之后很多人都会产生同一个念头这东西太啰嗦了。一个最简单的断言unittest要写成self.assertEqual(result, expected)而 Pytest 直接assert result expected就完事。别小看这点差别一个测试文件里几十上百个断言累积起来就是巨大的心智负担。更关键的是Pytest 的assert在失败时会自动做表达式重写把中间值打印得清清楚楚而unittest只给你一句干巴巴的 not equal。我自己的迁移经历是这样的早期项目用unittest写了两百多个用例后来要接入参数化测试发现unittest得靠ddt这类第三方库写法别扭报告也不好看。换成 Pytest 之后pytest.mark.parametrize一行装饰器搞定用例数量直接翻倍维护成本反而降了。Pytest 的核心优势可以归纳成几条断言简洁、自动发现用例、fixture 依赖注入、参数化原生支持、插件生态庞大。这几点加起来让它从 2010 年前后开始逐渐蚕食unittest的地盘到现在几乎成了 Python 测试的默认选择。你去看 GitHub 上稍微活跃一点的 Python 项目测试目录里十有八九是test_xxx.py配pytest.ini或pyproject.toml。1.2 Pytest 到底解决了哪些真实痛点很多人以为 Pytest 只是写起来短一点其实它解决的是测试工程化的问题。第一个痛点是测试隔离与资源管理。传统写法里每个测试函数要自己setUp数据库连接、临时文件、mock 对象用完还要tearDown。一旦某个用例中途抛异常清理逻辑可能就被跳过了导致后续用例互相污染。Pytest 的 fixture 用生成器yield把准备和清理写在一个函数里框架保证清理一定执行这就从机制上避免了资源泄漏。第二个痛点是测试数据的复用与组合。fixture 可以互相依赖一个db_connectionfixture 可以被user_repofixture 依赖user_repo又可以被具体用例依赖。这种依赖图由框架自动解析你不需要手动传参。配合scope参数function、class、module、session还能控制资源的创建频率比如数据库连接整个测试会话只建一次。第三个痛点是失败信息的可读性。Pytest 的断言重写会把assert user.age 18失败时的user.age实际值打印出来还会展示调用栈中每一层的局部变量。排查问题时这一条能省掉大量加print的时间。第四个痛点是生态整合。pytest-cov做覆盖率pytest-xdist做并行pytest-html出报告pytest-mock封装 mockallure-pytest对接 Allure 报告。这些插件基本都是装完即用配置量极小。相比之下unittest生态要零散得多。1.3 适合哪些人深入学这篇内容适合几类人一是刚学完 Python 基础、准备给代码加测试的开发者二是做接口自动化、UI 自动化需要一套稳定测试框架的测试工程师三是想把手动回归流程改造成 CI 流水线的团队。如果你已经在用unittest但觉得别扭那更值得花时间把 Pytest 吃透迁移成本比想象中低。需要的前置知识不多会写 Python 函数、懂基本的模块导入、知道什么是异常。剩下的 Pytest 概念我会在下面一步步拆开讲。2. 环境搭建与第一个可运行用例2.1 Python 环境与 Pytest 安装的正确姿势先说环境。Pytest 支持 Python 3.7 及以上现在主流是 3.10 到 3.12。如果你还没装 Python去官网下载安装包Windows 上记得勾选 Add Python to PATH这一步漏了后面命令行会找不到python。装完在终端敲python --version确认版本。接下来是虚拟环境。我强烈建议每个项目单独建 venv不要往全局环境里装包。原因很简单不同项目依赖的 Pytest 版本和插件可能冲突全局装迟早出问题。# 创建虚拟环境 python -m venv venv # 激活Windows venv\Scripts\activate # 激活macOS / Linux source venv/bin/activate激活后命令行前面会出现(venv)标识。然后安装 Pytestpip install pytest想确认装好了敲pytest --version会输出版本号。这里有个小坑有些系统里pytest命令和python -m pytest行为不完全一致尤其是涉及路径和导入的时候。我个人的习惯是统一用python -m pytest它能保证用的是当前虚拟环境里的解释器避免明明装了却找不到的诡异问题。如果你用 VS Code记得在右下角把 Python 解释器切到刚建的 venv否则编辑器里的测试发现功能会指向全局环境。PyCharm 则在 Settings 里配置项目解释器然后在 Tools 里把默认测试运行器改成 pytest。2.2 目录结构与命名约定Pytest 的自动发现机制依赖命名约定搞错了就会出现用例明明写了却一个都没跑的情况。规则是这样的测试文件命名test_*.py或*_test.py测试函数命名test_开头测试类命名Test开头且类里不能有__init__方法一个典型的项目结构长这样myproject/ ├── src/ │ └── calculator.py ├── tests/ │ ├── conftest.py │ ├── test_calculator.py │ └── test_advanced/ │ └── test_statistics.py ├── pytest.ini └── requirements.txtconftest.py是个特殊文件放在哪一层它里面的 fixture 就对那一层及以下的所有测试可见。这个机制后面讲 fixture 时会重点说。pytest.ini是配置文件用来设定默认参数。一个最小配置[pytest] testpaths tests python_files test_*.py python_functions test_* addopts -v --tbshorttestpaths限定搜索目录避免 Pytest 去翻venv里的第三方包。addopts里的-v是详细输出--tbshort让失败回溯更紧凑。这两个参数我几乎每个项目都会加。2.3 第一个用例与运行方式写个最简单的例子。假设src/calculator.pydef add(a, b): return a b def divide(a, b): if b 0: raise ValueError(除数不能为零) return a / b对应测试tests/test_calculator.pyimport pytest from src.calculator import add, divide def test_add_positive(): assert add(2, 3) 5 def test_add_negative(): assert add(-1, -1) -2 def test_divide_normal(): assert divide(10, 2) 5 def test_divide_by_zero(): with pytest.raises(ValueError, match除数不能为零): divide(1, 0)运行方式有几种各有用途# 跑全部 python -m pytest # 跑指定文件 python -m pytest tests/test_calculator.py # 跑指定函数 python -m pytest tests/test_calculator.py::test_add_positive # 按关键字筛选 python -m pytest -k divide # 遇到第一个失败就停 python -m pytest -x # 显示最慢的10个用例 python -m pytest --durations10-k这个参数特别实用它支持表达式比如-k add and not negative就能排除掉带 negative 的用例。调试阶段我经常用它来聚焦某几个用例。注意pytest.raises里的match参数是正则匹配不是精确相等。写match除数也能匹配上但如果你写的是特殊字符记得转义。3. FixturePytest 最值得投入时间学的部分3.1 Fixture 的基本用法与依赖注入Fixture 是 Pytest 的灵魂。它的本质是把测试需要的准备工作抽成可复用的函数由框架按需注入。看个例子import pytest pytest.fixture def sample_user(): return {name: 张三, age: 28} def test_user_name(sample_user): assert sample_user[name] 张三 def test_user_age(sample_user): assert sample_user[age] 18测试函数的参数名sample_user和 fixture 函数名一致Pytest 就自动把返回值传进来。这就是依赖注入——你不需要import不需要手动调用只要在参数里声明。带清理逻辑的 fixture 用yieldpytest.fixture def temp_file(tmp_path): f tmp_path / data.txt f.write_text(hello) yield f # yield 之后的代码是清理逻辑 if f.exists(): f.unlink()tmp_path是 Pytest 内置的 fixture提供一个临时目录每个用例独立用完自动清理。这种内置 fixture 还有很多比如tmp_path_factory、capsys捕获标准输出、monkeypatch临时修改属性/环境变量、request访问当前测试上下文。3.2 Scope 的选择与性能权衡Fixture 的scope决定了它的生命周期这是性能优化的关键scope生命周期适用场景function每个测试函数一次默认需要隔离的状态、临时数据class每个测试类一次类内共享的轻量资源module每个模块一次模块级配置、只读数据package每个包一次包级共享资源session整个测试会话一次数据库连接、浏览器实例、昂贵初始化选 scope 的原则是能共享就共享但共享的前提是不影响隔离性。比如数据库连接池用session没问题但如果某个用例会往表里写数据那要么用functionscope要么在每个用例里手动回滚。我踩过的一个坑早期把 mock 对象设成sessionscope结果第一个用例改了 mock 的返回值后面所有用例都受影响排查了半天才发现是 scope 用错了。凡是会被用例修改的状态一律用 function scope这是血泪教训。3.3 conftest.py 的分层与共享机制conftest.py不需要 importPytest 会自动加载。它的作用域是所在目录及其子目录。这个特性可以用来做分层配置tests/ ├── conftest.py # 全局 fixture数据库连接、配置读取 ├── unit/ │ ├── conftest.py # 单元测试专用mock 工厂 │ └── test_calc.py └── integration/ ├── conftest.py # 集成测试专用真实服务地址 └── test_api.py子目录的conftest.py可以覆盖父目录的同名 fixture也可以依赖父目录的 fixture。这种分层让不同测试类型各取所需又不会互相干扰。一个实战中的conftest.py示例import pytest from src.config import load_config from src.db import create_engine, create_session pytest.fixture(scopesession) def config(): return load_config(test.yaml) pytest.fixture(scopesession) def engine(config): eng create_engine(config[db_url]) yield eng eng.dispose() pytest.fixture def db_session(engine): session create_session(engine) yield session session.rollback() session.close()注意db_session的清理逻辑里先rollback再close这样即使用例里写了数据也不会污染数据库。这个模式在接口自动化里非常常用。3.4 Fixture 参数化与间接参数Fixture 本身也能参数化配合request.param使用pytest.fixture(params[mysql, postgresql, sqlite]) def db_backend(request): return request.param def test_query(db_backend): assert db_backend in [mysql, postgresql, sqlite]这个用例会被执行三次每次db_backend取不同的值。如果测试函数也需要参数化可以用indirectTrue把参数传给 fixturepytest.fixture def user(request): return create_user(rolerequest.param) pytest.mark.parametrize(user, [admin, guest], indirectTrue) def test_permission(user): assert user.role in [admin, guest]indirectTrue的意思是这个参数不直接传给测试函数而是传给同名 fixture。这个技巧在需要根据参数构造不同测试数据的场景里特别好用。4. 参数化、标记与用例组织4.1 parametrize 的多种玩法参数化是 Pytest 相比unittest最直观的优势。基本写法pytest.mark.parametrize(a, b, expected, [ (1, 2, 3), (0, 0, 0), (-1, 1, 0), (100, 200, 300), ]) def test_add(a, b, expected): assert add(a, b) expected四个数据组合会生成四个独立用例报告里分别显示。如果某个组合失败其他组合照常执行。给用例起可读的名字用ids参数pytest.mark.parametrize(a, b, expected, [ (1, 2, 3), (-1, 1, 0), ], ids[正数相加, 正负抵消]) def test_add(a, b, expected): assert add(a, b) expected多个parametrize叠加会做笛卡尔积pytest.mark.parametrize(x, [1, 2]) pytest.mark.parametrize(y, [10, 20]) def test_multiply(x, y): assert x * y in [10, 20, 40]这会生成 2×24 个用例。数据量大的时候要小心笛卡尔积很容易把用例数炸到几百上千。数据源也可以从外部文件读比如 JSON 或 CSVimport json def load_cases(): with open(cases.json, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_cases(), idslambda c: c[name]) def test_from_file(case): assert process(case[input]) case[expected]这种模式在接口自动化里很常见测试数据和代码分离非技术人员也能维护用例。4.2 标记mark的分类与自定义Pytest 内置了几个常用标记pytest.mark.skip无条件跳过pytest.mark.skipif(condition, reason...)条件跳过pytest.mark.xfail预期失败失败不算错通过反而报 XPASSpytest.mark.slow自定义标记配合-m筛选自定义标记需要在pytest.ini里注册否则会有警告[pytest] markers slow: 耗时较长的用例 smoke: 冒烟测试 integration: 集成测试然后就能这样用# 只跑冒烟 python -m pytest -m smoke # 排除慢用例 python -m pytest -m not slowskipif在跨平台项目里很有用import sys pytest.mark.skipif(sys.platform win32, reason仅支持 Unix) def test_unix_only(): ...xfail则适合标记已知 bugpytest.mark.xfail(reason已知问题 #123待修复) def test_known_bug(): assert buggy_function() expected如果这个用例某天修好了报告里会显示 XPASS提醒你去掉标记。4.3 用例分层与目录组织策略用例多了之后组织方式直接影响维护成本。我一般按测试类型分层tests/ ├── unit/ # 单元测试快无外部依赖 ├── integration/ # 集成测试依赖数据库/缓存 ├── e2e/ # 端到端依赖完整环境 └── performance/ # 性能测试每层有自己的conftest.py和标记。CI 里可以分阶段跑提交时只跑unit合并前跑integration发布前跑e2e。命名上我习惯用被测对象_场景_预期的格式比如test_login_with_wrong_password_returns_401。名字长一点没关系报告里一眼能看出测的是什么比test_login_2强太多。5. 接口自动化实战从单测到完整框架5.1 请求封装与 fixture 设计接口自动化的核心是把 HTTP 请求封装成可复用的 fixture。用requests举例import pytest import requests pytest.fixture(scopesession) def api_client(config): session requests.Session() session.headers.update({ Content-Type: application/json, Authorization: fBearer {config[token]}, }) session.base_url config[base_url] yield session session.close() pytest.fixture def get(api_client): def _get(path, **kwargs): return api_client.get(f{api_client.base_url}{path}, **kwargs) return _get pytest.fixture def post(api_client): def _post(path, **kwargs): return api_client.post(f{api_client.base_url}{path}, **kwargs) return _post用requests.Session而不是每次requests.get好处是连接复用、cookie 保持、header 统一。sessionscope 让整个测试会话共用一个连接池速度提升明显。测试用例写起来就很干净def test_create_user(post): resp post(/users, json{name: 李四, age: 30}) assert resp.status_code 201 assert resp.json()[name] 李四 def test_get_user(get): resp get(/users/1) assert resp.status_code 2005.2 数据驱动与用例分层接口测试的数据量大必须做数据驱动。我通常把用例数据放在 YAML 里# cases/user_login.yaml - name: 正确密码登录 request: method: post path: /login json: username: admin password: correct expected: status: 200 body: code: 0 - name: 错误密码登录 request: method: post path: /login json: username: admin password: wrong expected: status: 401 body: code: 1001然后用一个通用测试函数驱动import yaml import pytest def load_yaml(path): with open(path, encodingutf-8) as f: return yaml.safe_load(f) pytest.mark.parametrize(case, load_yaml(cases/user_login.yaml), idslambda c: c[name]) def test_user_login(case, api_client): req case[request] resp api_client.request(req[method], req[path], jsonreq.get(json)) assert resp.status_code case[expected][status] assert resp.json()[code] case[expected][body][code]这种一个测试函数 N 条数据的模式新增用例只需要改 YAML不用动代码。团队协作时测试同学维护数据开发同学维护框架职责清晰。5.3 断言封装与失败信息增强原生assert在接口测试里信息不够我一般封装一层def assert_response(resp, expected_statusNone, expected_codeNone): if expected_status is not None: assert resp.status_code expected_status, ( f状态码不符期望 {expected_status}实际 {resp.status_code} f响应体 {resp.text[:200]} ) if expected_code is not None: body resp.json() assert body.get(code) expected_code, ( f业务码不符期望 {expected_code}实际 {body.get(code)} f完整响应 {body} )失败时把响应体截断打印出来排查接口问题时能直接看到服务端返回了什么省去复现步骤。5.4 Allure 报告集成allure-pytest能让报告变得非常直观pip install allure-pytest用例里加装饰器import allure allure.feature(用户模块) allure.story(登录) allure.title(正确密码登录成功) allure.severity(allure.severity_level.CRITICAL) def test_login_success(post): with allure.step(发送登录请求): resp post(/login, json{username: admin, password: correct}) with allure.step(校验状态码): assert resp.status_code 200跑完生成报告python -m pytest --alluredir./allure-results allure serve ./allure-results报告里能看到 feature/story 分组、步骤详情、失败截图UI 测试时、请求响应附件。给团队看的时候比纯文本输出专业得多。6. 常见问题与排查技巧实录6.1 用例发现失败的排查清单用例没跑是新手最常遇到的问题。按这个顺序排查现象可能原因解决收集到 0 个用例文件名不符合test_*.py重命名文件收集到 0 个用例函数名不以test_开头重命名函数收集到 0 个用例测试类有__init__删掉__init__收集到 0 个用例testpaths配错检查pytest.ini导入报错包路径问题加__init__.py或用pythonpath配置导入报错虚拟环境没激活激活 venv 或用python -m pytest导入问题特别常见。如果src不在sys.path里可以这样配[pytest] pythonpath .或者在项目根目录放conftest.pyPytest 会把根目录加入sys.path。6.2 fixture 报错与作用域冲突ScopeMismatch是最典型的 fixture 错误一个functionscope 的 fixture 依赖了sessionscope 的 fixture 没问题反过来就会报错。因为 session 级的 fixture 在 function 级之前就创建了没法依赖一个还没创建的东西。解决办法是调整 scope让被依赖的 fixture scope 不小于依赖者。比如db_sessionfunction依赖enginesession是合法的但engine依赖db_session就非法。另一个常见错误是fixture xxx not found。原因通常是fixture 定义在conftest.py里但目录层级不对或者拼写不一致。检查一下conftest.py是否在被测文件的父目录链上。6.3 并行执行与状态污染pytest-xdist能大幅加速pip install pytest-xdist python -m pytest -n auto-n auto按 CPU 核数自动分配进程。但并行会带来状态污染问题多个进程同时操作同一个数据库、同一个文件、同一个端口结果就乱了。我的处理原则是并行只跑无状态用例。有状态的用例写数据库、改全局配置用-m not parallel排除或者给每个 worker 分配独立的资源。xdist提供了worker_idfixturepytest.fixture def db_name(worker_id): return ftest_db_{worker_id}这样每个进程用独立的数据库互不干扰。6.4 覆盖率统计的坑pytest-cov用法pip install pytest-cov python -m pytest --covsrc --cov-reporthtml生成的htmlcov/index.html能看到每行代码是否被执行。但覆盖率有个陷阱高覆盖率不等于高质量测试。我见过覆盖率 95% 但全是assert True的项目。覆盖率只能说明代码被执行过不能说明断言有效。另外--cov统计的是导入的模块。如果某个模块根本没被测试导入它不会出现在报告里看起来覆盖率很高实际漏测。用--covsrc --cov-reportterm-missing能看到哪些行没覆盖配合--cov-fail-under80在 CI 里卡阈值。6.5 调试技巧pdb 与 --pdb用例失败时想进调试器加--pdbpython -m pytest tests/test_calc.py::test_add --pdb失败时会停在pdb提示符可以查看变量、单步执行。--pdbcls还能换成ipdb获得更好的交互体验。另一个技巧是--lflast failed只重跑上次失败的用例调试循环里非常省时间python -m pytest --lf配合--fffailed first先跑失败的再跑其他的适合修复阶段。7. 从单测到 CI把 Pytest 接入流水线7.1 配置文件的最佳实践把所有配置集中到pyproject.toml或pytest.ini避免命令行参数散落各处。我倾向pyproject.toml因为现代 Python 项目基本都用它[tool.pytest.ini_options] testpaths [tests] addopts -v --tbshort --strict-markers markers [ slow: 耗时用例, smoke: 冒烟测试, integration: 集成测试, ] filterwarnings [error]--strict-markers让未注册的标记直接报错避免拼写错误被忽略。filterwarnings [error]把警告当错误处理能提前发现弃用 API 的调用。7.2 CI 中的分阶段执行在 CI 里我一般分三个阶段# 伪代码示意 stages: - lint: # 代码风格检查 - unit: # 单元测试快 - integration: # 集成测试慢单元测试阶段python -m pytest tests/unit -m not slow --covsrc --cov-fail-under80集成测试阶段python -m pytest tests/integration -m integration --alluredir./allure-results分阶段的好处是快速反馈单元测试几十秒出结果开发者提交后马上知道有没有破坏基本功能集成测试几分钟放在后面跑不阻塞快速迭代。7.3 测试数据与环境隔离CI 环境里数据库、缓存、第三方服务都要准备好。我的做法是用 Docker Compose 起依赖服务测试前跑迁移脚本测试后清理docker compose up -d db redis python -m pytest tests/integration docker compose down -v-v参数会删除数据卷保证下次跑是干净环境。测试数据用 fixture 动态生成不要依赖预置数据否则用例之间会互相影响。环境配置通过环境变量注入conftest.py里读取import os pytest.fixture(scopesession) def config(): return { base_url: os.environ.get(API_BASE_URL, http://localhost:8000), db_url: os.environ.get(TEST_DB_URL, sqlite:///:memory:), }本地开发用默认值CI 里通过环境变量覆盖一套代码适配多环境。8. 一些让我少走弯路的经验写测试这件事工具只是表面真正决定质量的是习惯。我总结几条自己踩坑后形成的做法。第一测试要能独立运行。任何一个用例单独跑都应该通过不能依赖其他用例的执行顺序。Pytest 默认按文件、函数定义顺序执行但不要依赖这个顺序。用pytest-randomly插件随机打乱顺序跑一遍能暴露隐藏的依赖问题。第二fixture 不要过度抽象。我见过把 fixture 套了五六层的项目改一个地方要追半天。fixture 的层级控制在两三层以内超过就考虑拆成独立的辅助函数。第三失败信息要自解释。断言里带上上下文比如assert resp.status_code 200, f响应体{resp.text}。半夜被 CI 报警叫醒时你会感谢白天多写的这几个字。第四测试代码也是代码。同样要 review、要重构、要遵守命名规范。测试代码腐烂的速度比生产代码还快因为大家默认它不重要。实际上测试是唯一能证明生产代码正确的东西值得同等对待。第五别追求 100% 覆盖率。把精力放在核心逻辑、边界条件、历史 bug 上。一个覆盖了所有异常分支的 70% 覆盖率比一个只跑 happy path 的 95% 有价值得多。最后分享一个我常用的调试小技巧在conftest.py里加一个自动打印用例耗时的 fixture跑测试时能直观看到哪些用例慢针对性优化。import time import pytest pytest.fixture(autouseTrue) def log_duration(request): start time.time() yield duration time.time() - start if duration 1.0: print(f\n[慢用例] {request.node.name}: {duration:.2f}s)autouseTrue让这个 fixture 自动应用到所有用例不用手动声明。超过 1 秒的用例会打印出来优化性能时一目了然。这个习惯帮我发现过好几个隐藏的 N1 查询问题。
Pytest 测试框架实战：从单元测试到接口自动化与 CI 集成
1. 为什么 Pytest 成了 Python 测试的事实标准1.1 从 unittest 到 Pytest 的迁移逻辑如果你写过 Python 的单元测试大概率是从unittest起步的。它是标准库自带的不用额外装包类继承、self.assertEqual那一套写起来也算规整。但写过几个模块之后很多人都会产生同一个念头这东西太啰嗦了。一个最简单的断言unittest要写成self.assertEqual(result, expected)而 Pytest 直接assert result expected就完事。别小看这点差别一个测试文件里几十上百个断言累积起来就是巨大的心智负担。更关键的是Pytest 的assert在失败时会自动做表达式重写把中间值打印得清清楚楚而unittest只给你一句干巴巴的 not equal。我自己的迁移经历是这样的早期项目用unittest写了两百多个用例后来要接入参数化测试发现unittest得靠ddt这类第三方库写法别扭报告也不好看。换成 Pytest 之后pytest.mark.parametrize一行装饰器搞定用例数量直接翻倍维护成本反而降了。Pytest 的核心优势可以归纳成几条断言简洁、自动发现用例、fixture 依赖注入、参数化原生支持、插件生态庞大。这几点加起来让它从 2010 年前后开始逐渐蚕食unittest的地盘到现在几乎成了 Python 测试的默认选择。你去看 GitHub 上稍微活跃一点的 Python 项目测试目录里十有八九是test_xxx.py配pytest.ini或pyproject.toml。1.2 Pytest 到底解决了哪些真实痛点很多人以为 Pytest 只是写起来短一点其实它解决的是测试工程化的问题。第一个痛点是测试隔离与资源管理。传统写法里每个测试函数要自己setUp数据库连接、临时文件、mock 对象用完还要tearDown。一旦某个用例中途抛异常清理逻辑可能就被跳过了导致后续用例互相污染。Pytest 的 fixture 用生成器yield把准备和清理写在一个函数里框架保证清理一定执行这就从机制上避免了资源泄漏。第二个痛点是测试数据的复用与组合。fixture 可以互相依赖一个db_connectionfixture 可以被user_repofixture 依赖user_repo又可以被具体用例依赖。这种依赖图由框架自动解析你不需要手动传参。配合scope参数function、class、module、session还能控制资源的创建频率比如数据库连接整个测试会话只建一次。第三个痛点是失败信息的可读性。Pytest 的断言重写会把assert user.age 18失败时的user.age实际值打印出来还会展示调用栈中每一层的局部变量。排查问题时这一条能省掉大量加print的时间。第四个痛点是生态整合。pytest-cov做覆盖率pytest-xdist做并行pytest-html出报告pytest-mock封装 mockallure-pytest对接 Allure 报告。这些插件基本都是装完即用配置量极小。相比之下unittest生态要零散得多。1.3 适合哪些人深入学这篇内容适合几类人一是刚学完 Python 基础、准备给代码加测试的开发者二是做接口自动化、UI 自动化需要一套稳定测试框架的测试工程师三是想把手动回归流程改造成 CI 流水线的团队。如果你已经在用unittest但觉得别扭那更值得花时间把 Pytest 吃透迁移成本比想象中低。需要的前置知识不多会写 Python 函数、懂基本的模块导入、知道什么是异常。剩下的 Pytest 概念我会在下面一步步拆开讲。2. 环境搭建与第一个可运行用例2.1 Python 环境与 Pytest 安装的正确姿势先说环境。Pytest 支持 Python 3.7 及以上现在主流是 3.10 到 3.12。如果你还没装 Python去官网下载安装包Windows 上记得勾选 Add Python to PATH这一步漏了后面命令行会找不到python。装完在终端敲python --version确认版本。接下来是虚拟环境。我强烈建议每个项目单独建 venv不要往全局环境里装包。原因很简单不同项目依赖的 Pytest 版本和插件可能冲突全局装迟早出问题。# 创建虚拟环境 python -m venv venv # 激活Windows venv\Scripts\activate # 激活macOS / Linux source venv/bin/activate激活后命令行前面会出现(venv)标识。然后安装 Pytestpip install pytest想确认装好了敲pytest --version会输出版本号。这里有个小坑有些系统里pytest命令和python -m pytest行为不完全一致尤其是涉及路径和导入的时候。我个人的习惯是统一用python -m pytest它能保证用的是当前虚拟环境里的解释器避免明明装了却找不到的诡异问题。如果你用 VS Code记得在右下角把 Python 解释器切到刚建的 venv否则编辑器里的测试发现功能会指向全局环境。PyCharm 则在 Settings 里配置项目解释器然后在 Tools 里把默认测试运行器改成 pytest。2.2 目录结构与命名约定Pytest 的自动发现机制依赖命名约定搞错了就会出现用例明明写了却一个都没跑的情况。规则是这样的测试文件命名test_*.py或*_test.py测试函数命名test_开头测试类命名Test开头且类里不能有__init__方法一个典型的项目结构长这样myproject/ ├── src/ │ └── calculator.py ├── tests/ │ ├── conftest.py │ ├── test_calculator.py │ └── test_advanced/ │ └── test_statistics.py ├── pytest.ini └── requirements.txtconftest.py是个特殊文件放在哪一层它里面的 fixture 就对那一层及以下的所有测试可见。这个机制后面讲 fixture 时会重点说。pytest.ini是配置文件用来设定默认参数。一个最小配置[pytest] testpaths tests python_files test_*.py python_functions test_* addopts -v --tbshorttestpaths限定搜索目录避免 Pytest 去翻venv里的第三方包。addopts里的-v是详细输出--tbshort让失败回溯更紧凑。这两个参数我几乎每个项目都会加。2.3 第一个用例与运行方式写个最简单的例子。假设src/calculator.pydef add(a, b): return a b def divide(a, b): if b 0: raise ValueError(除数不能为零) return a / b对应测试tests/test_calculator.pyimport pytest from src.calculator import add, divide def test_add_positive(): assert add(2, 3) 5 def test_add_negative(): assert add(-1, -1) -2 def test_divide_normal(): assert divide(10, 2) 5 def test_divide_by_zero(): with pytest.raises(ValueError, match除数不能为零): divide(1, 0)运行方式有几种各有用途# 跑全部 python -m pytest # 跑指定文件 python -m pytest tests/test_calculator.py # 跑指定函数 python -m pytest tests/test_calculator.py::test_add_positive # 按关键字筛选 python -m pytest -k divide # 遇到第一个失败就停 python -m pytest -x # 显示最慢的10个用例 python -m pytest --durations10-k这个参数特别实用它支持表达式比如-k add and not negative就能排除掉带 negative 的用例。调试阶段我经常用它来聚焦某几个用例。注意pytest.raises里的match参数是正则匹配不是精确相等。写match除数也能匹配上但如果你写的是特殊字符记得转义。3. FixturePytest 最值得投入时间学的部分3.1 Fixture 的基本用法与依赖注入Fixture 是 Pytest 的灵魂。它的本质是把测试需要的准备工作抽成可复用的函数由框架按需注入。看个例子import pytest pytest.fixture def sample_user(): return {name: 张三, age: 28} def test_user_name(sample_user): assert sample_user[name] 张三 def test_user_age(sample_user): assert sample_user[age] 18测试函数的参数名sample_user和 fixture 函数名一致Pytest 就自动把返回值传进来。这就是依赖注入——你不需要import不需要手动调用只要在参数里声明。带清理逻辑的 fixture 用yieldpytest.fixture def temp_file(tmp_path): f tmp_path / data.txt f.write_text(hello) yield f # yield 之后的代码是清理逻辑 if f.exists(): f.unlink()tmp_path是 Pytest 内置的 fixture提供一个临时目录每个用例独立用完自动清理。这种内置 fixture 还有很多比如tmp_path_factory、capsys捕获标准输出、monkeypatch临时修改属性/环境变量、request访问当前测试上下文。3.2 Scope 的选择与性能权衡Fixture 的scope决定了它的生命周期这是性能优化的关键scope生命周期适用场景function每个测试函数一次默认需要隔离的状态、临时数据class每个测试类一次类内共享的轻量资源module每个模块一次模块级配置、只读数据package每个包一次包级共享资源session整个测试会话一次数据库连接、浏览器实例、昂贵初始化选 scope 的原则是能共享就共享但共享的前提是不影响隔离性。比如数据库连接池用session没问题但如果某个用例会往表里写数据那要么用functionscope要么在每个用例里手动回滚。我踩过的一个坑早期把 mock 对象设成sessionscope结果第一个用例改了 mock 的返回值后面所有用例都受影响排查了半天才发现是 scope 用错了。凡是会被用例修改的状态一律用 function scope这是血泪教训。3.3 conftest.py 的分层与共享机制conftest.py不需要 importPytest 会自动加载。它的作用域是所在目录及其子目录。这个特性可以用来做分层配置tests/ ├── conftest.py # 全局 fixture数据库连接、配置读取 ├── unit/ │ ├── conftest.py # 单元测试专用mock 工厂 │ └── test_calc.py └── integration/ ├── conftest.py # 集成测试专用真实服务地址 └── test_api.py子目录的conftest.py可以覆盖父目录的同名 fixture也可以依赖父目录的 fixture。这种分层让不同测试类型各取所需又不会互相干扰。一个实战中的conftest.py示例import pytest from src.config import load_config from src.db import create_engine, create_session pytest.fixture(scopesession) def config(): return load_config(test.yaml) pytest.fixture(scopesession) def engine(config): eng create_engine(config[db_url]) yield eng eng.dispose() pytest.fixture def db_session(engine): session create_session(engine) yield session session.rollback() session.close()注意db_session的清理逻辑里先rollback再close这样即使用例里写了数据也不会污染数据库。这个模式在接口自动化里非常常用。3.4 Fixture 参数化与间接参数Fixture 本身也能参数化配合request.param使用pytest.fixture(params[mysql, postgresql, sqlite]) def db_backend(request): return request.param def test_query(db_backend): assert db_backend in [mysql, postgresql, sqlite]这个用例会被执行三次每次db_backend取不同的值。如果测试函数也需要参数化可以用indirectTrue把参数传给 fixturepytest.fixture def user(request): return create_user(rolerequest.param) pytest.mark.parametrize(user, [admin, guest], indirectTrue) def test_permission(user): assert user.role in [admin, guest]indirectTrue的意思是这个参数不直接传给测试函数而是传给同名 fixture。这个技巧在需要根据参数构造不同测试数据的场景里特别好用。4. 参数化、标记与用例组织4.1 parametrize 的多种玩法参数化是 Pytest 相比unittest最直观的优势。基本写法pytest.mark.parametrize(a, b, expected, [ (1, 2, 3), (0, 0, 0), (-1, 1, 0), (100, 200, 300), ]) def test_add(a, b, expected): assert add(a, b) expected四个数据组合会生成四个独立用例报告里分别显示。如果某个组合失败其他组合照常执行。给用例起可读的名字用ids参数pytest.mark.parametrize(a, b, expected, [ (1, 2, 3), (-1, 1, 0), ], ids[正数相加, 正负抵消]) def test_add(a, b, expected): assert add(a, b) expected多个parametrize叠加会做笛卡尔积pytest.mark.parametrize(x, [1, 2]) pytest.mark.parametrize(y, [10, 20]) def test_multiply(x, y): assert x * y in [10, 20, 40]这会生成 2×24 个用例。数据量大的时候要小心笛卡尔积很容易把用例数炸到几百上千。数据源也可以从外部文件读比如 JSON 或 CSVimport json def load_cases(): with open(cases.json, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_cases(), idslambda c: c[name]) def test_from_file(case): assert process(case[input]) case[expected]这种模式在接口自动化里很常见测试数据和代码分离非技术人员也能维护用例。4.2 标记mark的分类与自定义Pytest 内置了几个常用标记pytest.mark.skip无条件跳过pytest.mark.skipif(condition, reason...)条件跳过pytest.mark.xfail预期失败失败不算错通过反而报 XPASSpytest.mark.slow自定义标记配合-m筛选自定义标记需要在pytest.ini里注册否则会有警告[pytest] markers slow: 耗时较长的用例 smoke: 冒烟测试 integration: 集成测试然后就能这样用# 只跑冒烟 python -m pytest -m smoke # 排除慢用例 python -m pytest -m not slowskipif在跨平台项目里很有用import sys pytest.mark.skipif(sys.platform win32, reason仅支持 Unix) def test_unix_only(): ...xfail则适合标记已知 bugpytest.mark.xfail(reason已知问题 #123待修复) def test_known_bug(): assert buggy_function() expected如果这个用例某天修好了报告里会显示 XPASS提醒你去掉标记。4.3 用例分层与目录组织策略用例多了之后组织方式直接影响维护成本。我一般按测试类型分层tests/ ├── unit/ # 单元测试快无外部依赖 ├── integration/ # 集成测试依赖数据库/缓存 ├── e2e/ # 端到端依赖完整环境 └── performance/ # 性能测试每层有自己的conftest.py和标记。CI 里可以分阶段跑提交时只跑unit合并前跑integration发布前跑e2e。命名上我习惯用被测对象_场景_预期的格式比如test_login_with_wrong_password_returns_401。名字长一点没关系报告里一眼能看出测的是什么比test_login_2强太多。5. 接口自动化实战从单测到完整框架5.1 请求封装与 fixture 设计接口自动化的核心是把 HTTP 请求封装成可复用的 fixture。用requests举例import pytest import requests pytest.fixture(scopesession) def api_client(config): session requests.Session() session.headers.update({ Content-Type: application/json, Authorization: fBearer {config[token]}, }) session.base_url config[base_url] yield session session.close() pytest.fixture def get(api_client): def _get(path, **kwargs): return api_client.get(f{api_client.base_url}{path}, **kwargs) return _get pytest.fixture def post(api_client): def _post(path, **kwargs): return api_client.post(f{api_client.base_url}{path}, **kwargs) return _post用requests.Session而不是每次requests.get好处是连接复用、cookie 保持、header 统一。sessionscope 让整个测试会话共用一个连接池速度提升明显。测试用例写起来就很干净def test_create_user(post): resp post(/users, json{name: 李四, age: 30}) assert resp.status_code 201 assert resp.json()[name] 李四 def test_get_user(get): resp get(/users/1) assert resp.status_code 2005.2 数据驱动与用例分层接口测试的数据量大必须做数据驱动。我通常把用例数据放在 YAML 里# cases/user_login.yaml - name: 正确密码登录 request: method: post path: /login json: username: admin password: correct expected: status: 200 body: code: 0 - name: 错误密码登录 request: method: post path: /login json: username: admin password: wrong expected: status: 401 body: code: 1001然后用一个通用测试函数驱动import yaml import pytest def load_yaml(path): with open(path, encodingutf-8) as f: return yaml.safe_load(f) pytest.mark.parametrize(case, load_yaml(cases/user_login.yaml), idslambda c: c[name]) def test_user_login(case, api_client): req case[request] resp api_client.request(req[method], req[path], jsonreq.get(json)) assert resp.status_code case[expected][status] assert resp.json()[code] case[expected][body][code]这种一个测试函数 N 条数据的模式新增用例只需要改 YAML不用动代码。团队协作时测试同学维护数据开发同学维护框架职责清晰。5.3 断言封装与失败信息增强原生assert在接口测试里信息不够我一般封装一层def assert_response(resp, expected_statusNone, expected_codeNone): if expected_status is not None: assert resp.status_code expected_status, ( f状态码不符期望 {expected_status}实际 {resp.status_code} f响应体 {resp.text[:200]} ) if expected_code is not None: body resp.json() assert body.get(code) expected_code, ( f业务码不符期望 {expected_code}实际 {body.get(code)} f完整响应 {body} )失败时把响应体截断打印出来排查接口问题时能直接看到服务端返回了什么省去复现步骤。5.4 Allure 报告集成allure-pytest能让报告变得非常直观pip install allure-pytest用例里加装饰器import allure allure.feature(用户模块) allure.story(登录) allure.title(正确密码登录成功) allure.severity(allure.severity_level.CRITICAL) def test_login_success(post): with allure.step(发送登录请求): resp post(/login, json{username: admin, password: correct}) with allure.step(校验状态码): assert resp.status_code 200跑完生成报告python -m pytest --alluredir./allure-results allure serve ./allure-results报告里能看到 feature/story 分组、步骤详情、失败截图UI 测试时、请求响应附件。给团队看的时候比纯文本输出专业得多。6. 常见问题与排查技巧实录6.1 用例发现失败的排查清单用例没跑是新手最常遇到的问题。按这个顺序排查现象可能原因解决收集到 0 个用例文件名不符合test_*.py重命名文件收集到 0 个用例函数名不以test_开头重命名函数收集到 0 个用例测试类有__init__删掉__init__收集到 0 个用例testpaths配错检查pytest.ini导入报错包路径问题加__init__.py或用pythonpath配置导入报错虚拟环境没激活激活 venv 或用python -m pytest导入问题特别常见。如果src不在sys.path里可以这样配[pytest] pythonpath .或者在项目根目录放conftest.pyPytest 会把根目录加入sys.path。6.2 fixture 报错与作用域冲突ScopeMismatch是最典型的 fixture 错误一个functionscope 的 fixture 依赖了sessionscope 的 fixture 没问题反过来就会报错。因为 session 级的 fixture 在 function 级之前就创建了没法依赖一个还没创建的东西。解决办法是调整 scope让被依赖的 fixture scope 不小于依赖者。比如db_sessionfunction依赖enginesession是合法的但engine依赖db_session就非法。另一个常见错误是fixture xxx not found。原因通常是fixture 定义在conftest.py里但目录层级不对或者拼写不一致。检查一下conftest.py是否在被测文件的父目录链上。6.3 并行执行与状态污染pytest-xdist能大幅加速pip install pytest-xdist python -m pytest -n auto-n auto按 CPU 核数自动分配进程。但并行会带来状态污染问题多个进程同时操作同一个数据库、同一个文件、同一个端口结果就乱了。我的处理原则是并行只跑无状态用例。有状态的用例写数据库、改全局配置用-m not parallel排除或者给每个 worker 分配独立的资源。xdist提供了worker_idfixturepytest.fixture def db_name(worker_id): return ftest_db_{worker_id}这样每个进程用独立的数据库互不干扰。6.4 覆盖率统计的坑pytest-cov用法pip install pytest-cov python -m pytest --covsrc --cov-reporthtml生成的htmlcov/index.html能看到每行代码是否被执行。但覆盖率有个陷阱高覆盖率不等于高质量测试。我见过覆盖率 95% 但全是assert True的项目。覆盖率只能说明代码被执行过不能说明断言有效。另外--cov统计的是导入的模块。如果某个模块根本没被测试导入它不会出现在报告里看起来覆盖率很高实际漏测。用--covsrc --cov-reportterm-missing能看到哪些行没覆盖配合--cov-fail-under80在 CI 里卡阈值。6.5 调试技巧pdb 与 --pdb用例失败时想进调试器加--pdbpython -m pytest tests/test_calc.py::test_add --pdb失败时会停在pdb提示符可以查看变量、单步执行。--pdbcls还能换成ipdb获得更好的交互体验。另一个技巧是--lflast failed只重跑上次失败的用例调试循环里非常省时间python -m pytest --lf配合--fffailed first先跑失败的再跑其他的适合修复阶段。7. 从单测到 CI把 Pytest 接入流水线7.1 配置文件的最佳实践把所有配置集中到pyproject.toml或pytest.ini避免命令行参数散落各处。我倾向pyproject.toml因为现代 Python 项目基本都用它[tool.pytest.ini_options] testpaths [tests] addopts -v --tbshort --strict-markers markers [ slow: 耗时用例, smoke: 冒烟测试, integration: 集成测试, ] filterwarnings [error]--strict-markers让未注册的标记直接报错避免拼写错误被忽略。filterwarnings [error]把警告当错误处理能提前发现弃用 API 的调用。7.2 CI 中的分阶段执行在 CI 里我一般分三个阶段# 伪代码示意 stages: - lint: # 代码风格检查 - unit: # 单元测试快 - integration: # 集成测试慢单元测试阶段python -m pytest tests/unit -m not slow --covsrc --cov-fail-under80集成测试阶段python -m pytest tests/integration -m integration --alluredir./allure-results分阶段的好处是快速反馈单元测试几十秒出结果开发者提交后马上知道有没有破坏基本功能集成测试几分钟放在后面跑不阻塞快速迭代。7.3 测试数据与环境隔离CI 环境里数据库、缓存、第三方服务都要准备好。我的做法是用 Docker Compose 起依赖服务测试前跑迁移脚本测试后清理docker compose up -d db redis python -m pytest tests/integration docker compose down -v-v参数会删除数据卷保证下次跑是干净环境。测试数据用 fixture 动态生成不要依赖预置数据否则用例之间会互相影响。环境配置通过环境变量注入conftest.py里读取import os pytest.fixture(scopesession) def config(): return { base_url: os.environ.get(API_BASE_URL, http://localhost:8000), db_url: os.environ.get(TEST_DB_URL, sqlite:///:memory:), }本地开发用默认值CI 里通过环境变量覆盖一套代码适配多环境。8. 一些让我少走弯路的经验写测试这件事工具只是表面真正决定质量的是习惯。我总结几条自己踩坑后形成的做法。第一测试要能独立运行。任何一个用例单独跑都应该通过不能依赖其他用例的执行顺序。Pytest 默认按文件、函数定义顺序执行但不要依赖这个顺序。用pytest-randomly插件随机打乱顺序跑一遍能暴露隐藏的依赖问题。第二fixture 不要过度抽象。我见过把 fixture 套了五六层的项目改一个地方要追半天。fixture 的层级控制在两三层以内超过就考虑拆成独立的辅助函数。第三失败信息要自解释。断言里带上上下文比如assert resp.status_code 200, f响应体{resp.text}。半夜被 CI 报警叫醒时你会感谢白天多写的这几个字。第四测试代码也是代码。同样要 review、要重构、要遵守命名规范。测试代码腐烂的速度比生产代码还快因为大家默认它不重要。实际上测试是唯一能证明生产代码正确的东西值得同等对待。第五别追求 100% 覆盖率。把精力放在核心逻辑、边界条件、历史 bug 上。一个覆盖了所有异常分支的 70% 覆盖率比一个只跑 happy path 的 95% 有价值得多。最后分享一个我常用的调试小技巧在conftest.py里加一个自动打印用例耗时的 fixture跑测试时能直观看到哪些用例慢针对性优化。import time import pytest pytest.fixture(autouseTrue) def log_duration(request): start time.time() yield duration time.time() - start if duration 1.0: print(f\n[慢用例] {request.node.name}: {duration:.2f}s)autouseTrue让这个 fixture 自动应用到所有用例不用手动声明。超过 1 秒的用例会打印出来优化性能时一目了然。这个习惯帮我发现过好几个隐藏的 N1 查询问题。
 到 FIFO 的进程间通信)
