1. 从“能跑就行”到“优雅测试”：为什么要选 Pytest
在软件测试这条路上摸爬滚打久了，你会发现一个很现实的问题：同样的测试用例，有人写得像一团乱麻，跑起来全靠运气；有人写得像一份精致的说明书，任何时候拉出来都能稳定复现、清晰定位问题。这中间的差距，往往不是技术高低，而是测试框架的选择和用法是否到位。
我第一次接触 Pytest 是在一个维护了三年的老项目上，那时团队还在用unittest，每个测试类都要继承TestCase，setUp 和 tearDown 满天飞，夹具共享基本靠复制粘贴，跑一个全量回归要十一分钟，而且经常是橙色的失败、红色的报错，看得人头皮发麻。后来我花了一个周末把核心用例迁移到 Pytest 上，运行时间缩到四分钟，断言错误信息直接指出实际值和期望值的差异，队友们纷纷过来问我“动了什么魔法”。其实魔法谈不上，只是 Pytest 的“约定优于配置”和“插件生态”让我从繁琐的样板代码里解放了出来。
先说 Pytest 是什么。它是目前 Python 生态里最主流的自动化测试框架，既支持单元测试，也支持接口测试、功能测试，甚至可以通过插件扩展到 Web UI 和移动端测试。它最直观的特点是“写起来像普通函数”，不需要强制继承，不需要强制以类为单位组织，一个def test_xxx()就能被自动发现并执行。而且它的断言直接使用 Python 原生assert，失败信息自动包装成易读的差异提示，这对新手极其友好。
这篇文章适合谁？适合那些已经会写 Python 基础语法、但还没找到一套顺手测试工具的开发者；适合正在用unittest格式写用例、但觉得冗余和僵化的测试工程师；也适合打算搭建团队级自动化测试体系、想知道 Pytest 到底能帮你省多少事的测试负责人。我会从最基础的环境搭建开始，讲清它的核心机制，再结合接口测试和参数化这些真实场景，把我在实际项目里踩过的坑和总结出来的套路一并分享给你。
2. 环境准备与快速上手：10 分钟跑通第一个用例
2.1 安装与版本选择
Pytest 的安装极其简单，国内网络环境下建议使用清华或阿里镜像源加速。我的建议是在虚拟环境中安装，避免污染系统级 Python 环境，尤其是你电脑上同时存在多个项目时，虚拟环境几乎是必须的。
python -m venv venv source venv/bin/activate # Windows 下为 venv\Scripts\activate pip install pytest验证安装版本：
pytest --version如果你是做接口测试，还需要安装requests；如果要生成 HTML 格式的报告，装pytest-html；如果想测试失败自动重跑，装pytest-rerunfailures。这些后面会一一提到，现阶段先保证核心框架可用。
实际开发中，我见过很多同事在全局环境里直接pip install pytest，结果不同项目的插件版本互相冲突，最后不得不花两小时重新整理环境。我个人强烈建议从一开始就把虚拟环境这个概念刻进 DNA 里。Pytest 7.x 是目前的主流版本，Python 版本建议 3.8 及以上，太老的 Python 版本不仅新语法支持差，部分插件也会出现兼容问题。
2.2 最小化用例结构与执行方式
先看一个最简单但完整的用例。你完全不需要继承任何基类，不需要写任何配置，只要把文件名以test_开头或者以_test.py结尾，函数名以test_开头，Pytest 就能自动发现。
# test_sample.py def add(x, y): return x + y def test_add(): assert add(2, 3) == 5 def test_add_string(): assert add("hello", " world") == "hello world"在终端执行：
pytest test_sample.py -v输出会显示每个用例的 pssed/failed 状态，-v参数让信息更详细，方便你随时确认用例被正确收集。这里有一个容易被忽略的细节：文件名字符必须严格是test_前缀或_test.py后缀，放在子目录时，目录名不要求以 test 开头，但为了规范建议统一使用tests/目录。
测试发现规则也是 Pytest 优雅的核心之一。你不需要像unittest那样必须创建 suite 来加载用例，Pytest 会递归扫描当前目录及子目录中符合规则的文件和函数。这个设计大大降低了测试的组织成本，但同时也要求你注意命名规范，否则用例会被无声地漏掉。我见过有同事把测试函数命名为check_result()，结果在 CI 里跑了半天，一个用例都没执行，还以为是环境问题。所以请一定记住：以 test 开头是自动发现的硬性约定。
2.3 断言的艺术：assert 失败时你能看到什么
Pytest 对断言的重写机制是它区别于其他框架的一张王牌。普通 Python 断言失败时只会抛出AssertionError，你根本不知道实际值是多少，而 Pytest 会深度重写断言表达式，并以极清晰的方式展示两边数值的差异。
def test_list_comparison(): expected = [1, 2, 3, 4] actual = [1, 2, 3, 5] assert actual == expected运行后失败信息大致长这样：
E AssertionError: assert [1, 2, 3, 5] == [1, 2, 3, 4] E At index 3 diff: 5 != 4 E Full diff: E - [1, 2, 3, 4] E + [1, 2, 3, 5]它不光告诉你两个列表不一样，还精确到是索引位置 3 不同、具体值分别是多少。这种信息量对于定位问题来说太重要了。在unittest里你写assertEqual也就只能看到两个对象的 repr，只有当你把msg参数写得很详细时才能勉强对比，而 Pytest 直接帮你把 diff 算好了。
在实际使用中，我还发现 Pytest 对字典、集合、字符串都有类似友好的对比输出。比如字典的 key 缺了哪个、多了哪个，它都会列出来。这让我在写接口测试时，可以直接把响应 JSON 和期望 JSON 做整块断言，而不需要手动遍历字段。不过需要注意，Pytest 的断言重写只对其收集并执行的测试文件生效，如果你的测试函数引用了被测试模块中的复杂表达式，那部分不会被重写。另外，断言不能写在assert后面跟复杂生成器表达式时，重写有时会失效，但绝大多数日常场景没问题。
3. 核心机制详解：fixture、parametrize、mark 与插件的运用
3.1 fixture 才是 Pytest 的灵魂
fixture是 Pytest 里面最强大、也最容易被新手误解的功能。你可以把它理解成一个“带依赖注入的资源准备与清理机制”。传统测试中每个用例需要初始化数据和环境，往往在 setUp/tearDown 里重复写，而 fixture 允许你把这种准备和清理逻辑独立出来，并明确声明用例依赖它。
举一个生活化的例子：想象你开了一家餐厅，每张桌子都要铺桌布、放餐具，客人吃完后还要收拾。如果你每次客人来都临时搬桌子、铺布、放碗、收盘子，会累个半死。fixture 就是“标准化的布台流程”，客人来了说“我要一张四人桌”，餐厅按标准流程把一切都准备好，客人走后自动把桌子恢复原样。
代码层面的样子如下：
import pytest @pytest.fixture def user_token(): # 模拟登录并返回token token = "mock-token-12345" yield token # 测试结束后清理 print("\n清理 token 相关数据") def test_get_user_info(user_token): assert user_token.startswith("mock-token")当测试函数参数表里有user_token时，Pytest 会自动调用这个 fixture 函数，并把yield出来的值作为参数传入。测试结束后，yield后面的代码会被执行，不管断言是否成功，清理工作一定会进行，这比try...finally写起来要干净得多。
fixture 还有很多高级玩法。比如scope参数控制共享范围：function是默认值，每个用例都独立跑一次；class共享于一个测试类；module共享于整个模块；session全局只跑一次。我在接口测试里最常用的是module级别的登录 token 获取，几十个接口用例共享同一个 token，既节省了重复登录时间，又保证不频繁打爆认证接口。
fixture 的依赖也可以链式嵌套。一个 fixture 可以请求另一个 fixture，形成层次清晰的依赖树。比如database_connection依赖于app_config，而所有测试用例只需要声明database_connection，不需要关心它内部还需要什么。这种依赖解耦让测试用例的可读性提升了一个层级。
fixture 还有一个隐藏技能是conftest.py。你可以把公共 fixture 放在conftest.py中，这样它对同目录及子目录的所有测试文件自动可见。这有点类似于全局注册表，但比全局变量更优雅，因为它有明确的生命周期和作用域。注意，conftest.py不能被测试文件直接 import，但它里面定义的 fixture 无需 import 就能在测试中作为参数使用，这是 Pytest 隐式查找机制的体现。
3.2 参数化：一套用例跑遍所有边界条件
写测试时，最枯燥的就是把同一段逻辑复制无数遍，只改不同输入值。Pytest 的@pytest.mark.parametrize装饰器可以把你从复制粘贴中解救出来。
import pytest @pytest.mark.parametrize("input_value, expected", [ (2, 4), (3, 9), (4, 16), ("4", 16), ]) def test_square(input_value, expected): assert int(input_value) ** 2 == expected执行时会看到四条独立的用例记录，每条都带有参数值。如果其中一条失败，其他条仍然会继续跑完，这比在一个用例中写 for 循环要强大得多。因为 for 循环一旦中途断言失败，后续数据根本不会执行，你也就无法知道后面的输入是否也有问题。参数化让每个数据点都成为独立可追溯的用例，测试报告里能精确显示是哪个输入值触发了失败。
参数化还可以用元组拆包的方式定义多组参数名，也可以和 fixture 结合起来用。我最常用的模式是把接口测试的数据文件（JSON/YAML）读进来，转换成参数列表，然后直接用parametrize跑。这样业务人员可以维护测试数据文件，测试代码完全不需要改动。
举一个真实的接口测试例子。假设我们要测试一个订单查询接口，输入订单号、用户身份、期望返回码。我准备了五组数据：正常订单、不存在订单、无权限用户订单、订单号为空、订单号为超长字符串。把这些数据写进order_cases.json，然后在测试里读取并参数化。
import json import pytest import requests with open("order_cases.json", encoding="utf-8") as f: order_cases = json.load(f) @pytest.mark.parametrize("case", order_cases) def test_query_order(case): url = "https://api.example.com/order/query" payload = {"order_no": case["order_no"]} resp = requests.post(url, headers={"Authorization": case["token"]}, json=payload) assert resp.status_code == case["expected_status"]这个方案既保证了数据与代码分离，又让新增用例的成本变成“往 JSON 里加一行”。如果你担心 JSON 文件读取在收集阶段就执行，导致无法动态加载，可以把参数化拆到每个用例内，但这会丧失独立性。实际项目里，我更推荐在测试模块顶部读取静态数据文件，Pytest 在收集阶段就能确定参数列表，也不会因为数据文件读取错误把所有用例都拖垮。
参数化还有个小技巧是给每条用例起 custom id，便于阅读报告。使用ids参数可以传入一个字符串列表，但更省力的方式是利用缺省的自生成 id，它会显示参数的具体值。如果参数值是个较长的 JSON 对象，报告可能变得冗余，此时可以用pytest.param(..., id="简短标识")手动指定。
3.3 mark 机制：分层、跳过和预期失败
mark是给测试打标签的机制。默认标记里最常用的是：
@pytest.mark.skip：无条件跳过@pytest.mark.skipif(condition, reason=...)：条件满足时跳过@pytest.mark.xfail(condition, reason=...)：预期失败@pytest.mark.parametrize：参数化（实际上也是一种标记）- 自定义标记：比如
@pytest.mark.smoke、@pytest.mark.api、@pytest.mark.webtest
自定义标记需要在pytest.ini或pyproject.toml中注册，否则会触发 warning。我通常建一个pytest.ini文件来配置基础信息：
[pytest] markers = smoke: 冒烟测试用例 api: 接口测试用例 slow: 执行较慢的用例 addopts = -v -s testpaths = testsaddopts里写-v -s是让我每次执行时默认显示详细信息和 print 输出，省得手动打字。testpaths指定测试目录，避免收集整个项目里的非测试目录。
标记的实际应用场景很丰富。比如你的项目有“冒烟集”和“全量回归”两个 CI 任务，那么冒烟任务可以执行pytest -m smoke，全量任务执行pytest -m "not slow"，灵活地排除慢用例。而xfail则适合标记已知 bug 且暂时无法修复的用例，不会让整体测试变成红色失败，累计不期望的标红通过数还能提醒团队去修复。
3.4 conftest.py 的正确姿势
conftest.py是 Pytest 特有的钩子文件，他可以放 fixture、插件注册、钩子函数，甚至影响测试收集行为。最常见的用法就是存放公共 fixture。我会在测试目录的根下放一个conftest.py，里面放 session 级别的浏览器驱动、日志对象和 API 客户端实例。
# tests/conftest.py import pytest from utils.api_client import APIClient @pytest.fixture(scope="session") def api_client(): client = APIClient(base_url="https://api.example.com") client.login("test_user", "test_pass") return client @pytest.fixture(scope="module") def token(api_client): return api_client.token这种结构下，任何测试模块都能直接引用api_client或token，完全不需要写共同的基类或工具类。注意，不要在conftest.py里写测试用例，它只作为配置和支持代码存在。另外，每个子目录也可能有自己的conftest.py，它的作用域限定在该目录内，形成层级化的配置体系。如果你发现一个 fixture 只被一个子目录使用，就放在子目录的conftest.py里，避免污染全局命名空间。
老手还会在conftest.py里实现自己的pytest_collection_modifyitems钩子，用来对测试用例排序、去重，或者根据标记自动调整参数，这属于比较进阶的玩法，新手先掌握 fixture 注册即可。
4. 接口测试实战：从登录到业务闭环
4.1 接口测试框架的初步设计
很多人把 Pytest 当作单元测试工具使用，但真正让它大放异彩的是接口自动化测试。我会用一个简化的电商项目来演示：系统包含用户登录、商品查询、购物车结算三个环节。我需要测试登录成功、登录失败、商品查询边界以及购物车结算链路。
设计原则是：配置与脚本分离、数据与代码分离、公共逻辑沉淀为 fixture 或工具函数。
目录结构大致这样：
tests/ ├── conftest.py ├── data/ │ └── login_cases.json ├── test_login.py ├── test_product.py └── test_cart.py先把conftest.py定义好全局的 API client：
import pytest import requests @pytest.fixture(scope="session") def base_url(): return "https://api.example.com" @pytest.fixture(scope="session") def session(base_url): s = requests.Session() s.headers.update({"Content-Type": "application/json"}) return s @pytest.fixture(scope="session") def login_token(session, base_url): resp = session.post(f"{base_url}/login", json={"username": "demo", "password": "123456"}) token = resp.json().get("token") return token这里的Session()利用了 requests 的会话持久化，会自动携带 cookie，并且能保持连接池，提高测试效率。login_token是 session 级别的，只登录一次，后续所有依赖它的测试用例都直接使用这个 token。
4.2 登录接口用例设计
登录属于高频基础接口，我会把正常、缺参、密码错误、账号锁定等场景全部参数化。注意，每个场景之间最好使用独立的用户数据，避免因为前一个用例篡改了数据导致后一个用例失败。这一步是新手最容易忽略的测试数据隔离问题。
import json import pytest import requests from pathlib import Path BASE_DIR = Path(__file__).parent with open(BASE_DIR / "data" / "login_cases.json", encoding="utf-8") as f: login_cases = json.load(f) @pytest.mark.parametrize("case", login_cases, ids=[c["id"] for c in login_cases]) def test_login(session, base_url, case): resp = session.post(f"{base_url}/login", json=case["payload"]) assert resp.status_code == case["expected_status"], f"状态码不匹配，实际：{resp.status_code}" if case["expected_status"] == 200: assert "token" in resp.json(), "登录成功响应中没有 token" else: assert resp.json().get("code") == case["expected_code"], "错误码不匹配"ids参数让报告中每条用例都有一个人类可读的名字，比如“正常登录”“密码错误”“用户不存在”，非常清晰。注意数据文件里的expected_code字段，通常代表业务错误码，与 HTTP 状态码是两码事，区分开可以避免混淆。
我再强调一个我在真实项目中踩过的坑：登录接口往往有验证码、时间戳、随机数等参数，直接录制请求数据回放容易被拦截。在设计测试数据时，需要和开发约定一个测试环境专用的“万能验证码”或关闭验证码校验。同时要对密码做脱敏处理，尽量使用独立的测试账号，不要拿生产账号来测。
4.3 供应链数据隔离与清理
接口测试最大的陷阱是共享数据库导致的数据冲突。比如你测“创建订单”，跑完一遍，数据库里多了一批数据，下次再跑时同一构造数据可能触发唯一索引冲突。解决办法有几种：
- 每个用例开始时创建独立的前置数据，结束时清理
- 使用事务回滚，测试后回滚到初始状态
- 测试环境中提供专用的 mock 服务
我比较推崇的是将“准备数据”和“清理数据”都封装进 fixture。用yield的思想在测试前建立数据，测试后删除。
@pytest.fixture def created_product(session, base_url, login_token): # 创建测试商品 data = {"name": "pytest_prod", "price": 999} resp = session.post(f"{base_url}/product", headers={"Authorization": login_token}, json=data) product_id = resp.json()["id"] yield product_id # 清理：删除该商品 session.delete(f"{base_url}/product/{product_id}", headers={"Authorization": login_token})这个 fixture 在测试用例中直接作为参数使用，用例结束时无论成功或失败，清理步骤都会执行，有效避免了脏数据残留。使用这种模式的关键是确保你的被测接口提供了“创建”和“删除”能力。如果被测系统不支持删除，那就得通过数据库层的清理工具，或者给数据加上特定的前缀标识，定期批量清理。
4.4 断言响应体时的技巧
对 JSON 响应进行断言，最直接的就是全量比对。但接口响应经常带有时间戳、随机 id、签名等字段，导致全量比对不稳定。我建议用“关键字段断言 + 结构断言”组合。
结构断言可以用jsonschema库。安装后：
pip install jsonschemafrom jsonschema import validate, ValidationError def assert_response_schema(resp_json, schema): try: validate(instance=resp_json, schema=schema) except ValidationError as e: raise AssertionError(f"响应结构不符合预期: {e.message}")接口联调阶段，开发经常会在响应里多一个字段或少一个字段，全量断言会让你频繁红。而 schema 断言允许你设定哪些字段必填、字段类型是什么，既能保证接口契约稳定，又不至于被无关字段干扰。如果团队里有前后端约定好的 OpenAPI 文档，甚至可以自动生成一部分测试用例，但那是后话了。
另外，对于列表型响应，我会断言len(data) > 0，然后抽查第一个元素的字段，而不是把整个大列表全部断言，除非接口文档明确要保证顺序和内容。接口测试的目标是尽早发现集成问题，而不是替代数据核对，所以断言粒度要合理。
5. 进阶特性与常见问题排查
5.1 pytest.ini 配置项实用清单
配置文件的正确使用，能让你的测试工程在不同人、不同 CI 环境下保持行为一致。我常用的配置项包括：
[pytest] testpaths = tests markers = smoke: 冒烟测试 api: 接口测试 addopts = -ra --strict-markers-ra表示报告所有执行摘要，包括 skipped, xfailed 等。--strict-markers让未注册的标记直接报错，防止有人筛写拼写错误的标记。testpaths让收集范围收敛在一个目录，避免误收集依赖包里的 case。
甚至还可以通过filterwarnings忽略特定警告，避免大量 DeprecationWarning 刷屏。这些配置项适合在团队里统一模板化，新成员 clone 项目后直接pytest就能得到和 CI 一致的结果。
5.2 失败重跑与 80% 的“假失败”
接口测试中，网络抖动、服务偶发超时、上游延迟都会造成误报。为了减少这类“假失败”，我安装了pytest-rerunfailures：
pip install pytest-rerunfailures命令行参数：
pytest --reruns 2 --reruns-delay 1意思是对失败用例再跑两次，间隔 1 秒。重跑机制最适合冒烟和集成测试，但对于单元测试却不推荐，因为单元测试要求确定性，跑失败应该当场暴露。如果某个接口用例经常要重跑三次才过，那大概率不是用例问题，而是接口不稳定。应当把这个信息反馈给开发团队，而不是一直用重跑来掩盖。
我曾在支付回调测试中遇到一个诡异现象：第一次调用返回 200，第二次传入相同参数却返回 500。后来排查发现是对接方有一个防重幂等表，第一次插入成功后，第二次来了同样的 transaction_id 触发器抛异常。这种问题靠重跑根本解决不了，必须深入分析业务逻辑。重跑只是稳定性的兜底手段，不能当作测试设计的遮羞布。
5.3 常用插件推荐与对比
插件是 Pytest 生态的优势所在，我列几个每天都在用的：
| 插件名 | 用途 | 说明 |
|---|---|---|
| pytest-html | 生成 HTML 测试报告 | 有自带的样式，可截图嵌入，适合发测试报告 |
| pytest-rerunfailures | 失败用例重跑 | 适合集成测试，缓解偶发问题 |
| pytest-xdist | 并行执行测试 | 多进程加速，用-n auto充分利用多核 |
| pytest-ordering | 自定义用例执行顺序 | 注意用例间应尽量无依赖 |
| pytest-cov | 测试覆盖率统计 | 和 coverage.py 配合 |
| allure-pytest | 生成 Allure 报告 | 适合大型团队，报告美观，可追溯步骤 |
使用pytest-xdist并行执行前要特别小心测试间共享数据的问题。如果你的测试没有做好数据隔离，并行后大概率出现互相干扰，不仅导致失败，而且会让失败原因变得难以捉摸。我从实战中得到一个准则：先保证串行全绿，再想并行提速。如果串行都不能稳定通过，并行只会让问题更复杂。
5.4 我遇到的高频问题与排查技巧
第一个常见问题：pytest执行后提示 “collected 0 items”。这种大概率是文件名或函数名不符合 test 开头规则，或者 testpaths 配置指向了错误的目录。处理方法是在项目根目录执行pytest --collect-only查看到底收集了什么，很少出现零收集其实是发现路径根本不在当前目录下。
第二个问题：fixture 报错 “fixture 'xx' not found”。先确认 fixture 是否定义在conftest.py中并且文件名拼写正确，再检查会不会是把 fixture 定义在其他目录的测试文件里。记住 fixture 的可见范围：定义文件本身、同目录下其他测试文件、子目录测试文件。有时候你把 fixture 放在tests/common/conftest.py里，但实际测试在tests/api/test_xxx.py，如果层级不匹配，就会找不到。
第三个问题：参数化数据量巨大导致报告刷屏。建议给参数化加上自定义 id，并通过-q选项减少输出，或者干脆使用--tb=short只显示较短的追溯信息。我习惯在 CI 里使用pytest -q --tb=short，既保留了失败概要，又不会让几百条成功用例的输出淹没核心信息。
第四个问题：断言失败时打印的中文乱码。在某些 Windows 终端和旧版 Pytest 组合中会出现。解决方法是在pytest.ini中设置disable_test_id_escaping和相关编码环境变量，但更根本的原因通常是系统 locale 未设为 UTF-8。最好在 CI 环境里直接设置PYTHONIOENCODING=utf-8。
5.5 超时控制与资源清理
接口挂起是测试执行里最令人抓狂的情况：一条用例没有响应，整个任务死在那里，CI 卡到超时才报错。解决办法是给接口调用加超时。requests本身就支持 timeout 参数，但很多人在写测试时忽略它。我建议在封装 API client 时统一加 timeout，没有例外。
import requests def request_with_timeout(method, url, **kwargs): kwargs.setdefault("timeout", 10) return requests.request(method, url, **kwargs)这样即使被测服务崩溃并失去响应，10 秒后用例也会抛超时异常，测试能继续执行并标记失败。如果你用的是 pytest-timout 插件，可以给整个用例设置超时时间：
pip install pytest-timeoutpytest --timeout=60但接口测试以单个请求超时为主最合适。因为整个用例超时可能是多个请求叠加，不好定位是哪个环节卡住。我在排查一个批量导入用例时，发现它运行了 8 分钟还没结束，就是因为某一步的下载链接挂了而 requests 没有超时。后来给所有请求统一加了 timeout，测试运行总时间从平均 20 分钟降到 6 分钟，关键问题是定位时间大幅缩短。
6. 实战建议：如何从当前测试困境切换到 Pytest
6.1 迁移现有 unittest 用例的步骤
如果你正在维护一个unittest体系，我可以给你一条渐进迁移的路径。第一步，不要一次性全部重写，而是让 Pytest 能直接运行你的unittest.TestCase。Pytest 原生就兼容unittest，所以你只需要安装 Pytest，然后在项目根目录执行pytest，它会自动跑所有继承unittest.TestCase的测试类。这让你迈出第一步的阻力几乎为零。
第二步，针对新写的用例，全部使用 Pytest 风格：独立的test_函数、fixture、参数化。老用例暂时保留，当每个模块被新用例覆盖后，再删除对应的unittest类。
第三步，用pytest的--junitxml=report.xml输出 CI 能识别的 XML 结果，替换掉原有的 runner 脚本。这一步是为了让报告格式统一，无论新旧用例都能在同一个 CI 面板上展示。
在迁移过程中最容易遇到的坑是setUpClass与 fixture 的 scope 混用。比如旧代码中setUpClass会创建一个昂贵的对象，如果在 Pytest 下同时存在 session 级 fixture，可能会重复初始化。建议迁移时先梳理每个类的初始化逻辑，判断它是属于 class 级还是 module 级，然后用@pytest.fixture(scope="class")或scope="module"替代。
6.2 测试工程结构建议
一套清爽的测试工程结构，应该让新人在五分钟内搞清楚“去哪写用例、去哪找数据、去哪加配置”。我比较推荐的结构如下：
project_root/ ├── pytest.ini ├── requirements-dev.txt ├── tests/ │ ├── conftest.py │ ├── data/ │ │ ├── login_cases.json │ │ └── product_cases.json │ ├── api/ │ │ ├── test_login.py │ │ ├── test_product.py │ │ └── test_cart.py │ └── utils/ │ ├── api_client.py │ └── assertion.py └── src/ └── 被测代码api_client.py负责封装请求方法，assertion.py放公共断言函数，data放静态测试数据。不要把所有工具函数都堆在conftest.py里，否则那个文件会变成垃圾场。fixture 关注的是依赖注入，真正的业务封装应该放在可被普通 import 的工具模块中。
6.3 在 CI 中的集成方式
CI 里执行 Pytest 只需要一行命令：
pytest -n auto --reruns 1 -q --junitxml=report.xml我在 GitHub Actions 或者 GitLab CI 中通常会这样设计阶段：第一个 job 跑静态检查和单元测试，速度要快；合并到主分支后触发集成测试，可能包含接口测试和慢用例。区分两者就是靠-m "unit"和-m "api"这种标记。如果测试文件变多，建议在 CI 上单独用一个 job 跑全量并上传 HTML 报告，让测试可视化。
CI 失败时的输出要简洁。我会在命令里加上--tb=short或者--tb=line，前者只显示失败点附近的行，后者只显示一条错误行，让日志不至于炸屏。如果配合 Allure 报告，CI 只需要保留 JUnit XML，然后交给 Allure 服务生成可视化报告即可。
6.4 最后分享几个真实经验
写测试不是为了数字好看，而是为了在改动发生时能快速告诉你“哪里炸了”。所以我的原则一直是：让失败的用例尽可能短地定位到问题所在。做到这一点，需要在断言里附上上下文信息，比如“状态码不匹配，实际：503，期望：200，请求路径：/order/query”。这些信息断言的输出会直接展示出来，节省大量翻日志的时间。
另一个经验是在团队里推行“测试用例即文档”的理念。用 Pytest 的参数化描述场景，用 fixture 传达前置条件，用自定义 mark 标注用例类别，这份测试代码本身就是最精确的需求规格。我曾在一个遗留项目里摸索业务逻辑，全靠读测试代码理解系统的边界行为，比文档准得多。
还要提醒的是，不要一上来就追求 100% 覆盖率。覆盖率是手段，不是目标。你可以先跑通主流程和核心分支，再逐步补充异常处理路径。尤其在初期，与其花大量时间覆盖边缘分支，不如把精力放在更可能出问题的集成点上，这样才能让测试发挥真正的价值。
Pytest 的入门其实不难，难的是在使用中不断体会它“得益于约定而非配置”的设计哲学。你越深入了解 fixture 和参数化，就越能发现测试代码也可以写得像优雅的乐谱，而不是一行行勉强能跑的通天塔。如果你正被测试代码的重复和脆弱折磨，不妨从今天开始重新整理你的测试用例，用 Pytest 把这份繁琐变成可维护的工程资产。
