企业官网建设流程全解析

1. 从一个“跑不过去”的测试用例说起

刚接触 pytest 时，我其实是拒绝的。当时项目里所有人都用 unittest 写接口测试，类套类、setUp 套 tearDown，跑得也还行。直到有一次接手一个遗留系统，几千行测试代码堆在一起，稍微改一处公共 setUp，后面十几个用例全挂，定位问题花了一整天。那之后我认真研究了一下 pytest，才发现它解决的不只是“写起来顺手”的问题，而是把测试这件事本身的复杂度大幅降低了。

网上关于 pytest 的教程很多，但大多是“教你写第一个用例”就结束了，真正进入实际项目后，你会发现要做的事远不止这些：目录怎么规划、fixture 作用域怎么定、参数化数据怎么组织、失败重跑和并发执行怎么配、覆盖率报告怎么落到 CI 里——这些才是让测试真正长期可维护的关键。

这篇文章就来聊聊我在实际项目里把 pytest 用起来的心得和踩坑记录。内容会围绕基础设施、断言与 fixture、参数化、插件生态、以及几个真实的疑难杂症展开，适合已经会用 Python 但刚接触 pytest 的团队，也适合想优化现有测试结构的同学参考。

2. 项目怎么搭，直接决定测试好不好维护

很多团队一开始不重视测试目录结构，“反正能跑就行”，结果测试文件越来越多，谁也不敢乱动，甚至出现一个测试文件两千行的“屎山”。pytest 对目录结构没有硬性要求，但从第一天就定好约定，后面会轻松太多。

2.1 推荐目录布局与 sys.path 问题

我常用的项目结构大致长这样：

project_root/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── api/ │ ├── services/ │ └── models/ ├── tests/ │ ├── __init__.py │ ├── conftest.py │ ├── unit/ │ ├── integration/ │ └── data/ ├── pyproject.toml └── requirements-dev.txt

这里有一个非常容易踩的坑：如果tests目录下没有__init__.py，而 pytest 又处于 rootdir 之下，导入app模块时可能会遇到模块找不到的问题，尤其是当app没有作为包安装到环境中时。早期我习惯在tests里加一个空__init__.py，但后来发现 pytest 的导入模式（import-mode=importlib）对无__init__.py的测试目录反而更友好，可以避免多个同名测试文件互相覆盖。

更稳妥的做法是在pyproject.toml里配上：

[tool.pytest.ini_options] pythonpath = ["."] testpaths = ["tests"]

pythonpath = ["."]是 pytest 7.0 之后原生支持的配置项，它会自动把项目根目录加入导入路径，省去手工改sys.path的野蛮操作。之前我在 CI 环境里遇到“本地能跑、Jenkins 上报 module not found”的情况，根因就是环境里的 PYTHONPATH 不一致，后来统一在 pyproject.toml 里声明，问题就再没出现过。

2.2 conftest.py 到底该放几层

conftest.py 是 pytest 里最容易理解错的概念之一。它的作用是给所在目录及其子目录下的测试文件提供共享的 fixture、钩子函数和插件配置。很多新手把所有 fixture 全堆在根目录一个 conftest.py 里，看起来方便，实际上会让 fixture 之间的依赖关系越来越混乱。

我自己用的原则是：全局性的、几乎所有测试都用的（比如测试数据库连接、统一日志开关）放在tests/conftest.py；按业务模块拆分的 fixture 放在对应的子目录 conftest.py 里；同一个用例文件内部才用到的数据准备逻辑，要么写在文件顶部，要么放到测试类里。千万不要在 conftest.py 里写测试逻辑，conftest 不是用来放测试用例的。

另外，fixture 的命名尽量用名词而不是动词，比如user_payload、order_service这样一眼能看出来的，比create_user_and_get_token这种长动词更清晰。因为 fixture 本质上是一个依赖注入的名字，阅读测试时第一反应是“它提供了什么”，而不是“它做了什么”。

2.3 依赖管理与环境隔离

pytest 本身只是测试执行器，但实际项目里你几乎一定会用到这些：requests 或 httpx（接口调用）、pytest-cov（覆盖率）、pytest-xdist（并发）、pytest-rerunfailures（失败重跑）。这些依赖要和业务代码的依赖分开，建一个requirements-dev.txt或者在 pyproject.toml 里拆一个 optional dependency 组。

我强烈建议在虚拟环境里跑测试，尤其是 Python 多版本并存的机器上，否则很容易出现“明明测试过了，换个环境全挂”的诡异现象。项目里用一个.env.example记录所需的环境变量，conftest.py 里用os.getenv获取，不要写死连接串。测试环境、开发环境、生产环境的数据库地址和密钥必须分开，这算是常识，但我在不少项目的测试代码里见过直接硬编码的数据库 URL，非常危险。

配置好之后，一个干净的最小可用配置长这样：

[tool.pytest.ini_options] minversion = "7.0" testpaths = ["tests"] pythonpath = ["."] addopts = "-q --strict-markers" markers = [ "smoke: 冒烟测试，执行最快的主链路", "slow: 耗时长，默认不跑", "p0: 核心用例级别" ]

--strict-markers这个配置很重要：它会把所有未被注册的标记当成错误，防止你拼错 marker 名导致用例被静默跳过。比如你想用@pytest.mark.smoke，但手误写成@pytest.mark.smoke2，没有 strict 模式的话 pytest 只会给个 warning，用例照跑；一旦真的想用-m smoke过滤时，用例没被执行你都不一定发现。这里把 marker 注册好，相当于给项目立了规矩。

3. 断言写不好，测试等于白写

pytest 最吸引人的一点是它原生强大的断言机制。不夸张地说，它的断言语法的自然程度，让很多从 unittest 转过来的人回不去了。unittest里要写assertEqual(a, b)、assertTrue(x)、assertIn(y, z)，pytest 里直接用 Python 原生assert就行，失败时还能自动显示两边表达式的值。

3.1 断言失败信息看不懂怎么办

原生 assert 的失败信息在多数情况下已经够清晰了。比如：

def test_price_calculation(): actual = calculate_total(100, 0.9) assert actual == 95

跑失败后显示：

E assert 90.0 == 95

这对简单值够用。但如果是字典、列表嵌套结构，看起来就会很吃力。此时 pytest 的另一个隐藏能力——assert内部使用了“断言重写”技术——会自动展开复杂表达式的差异。两个列表比较失败时，它会尽量显示哪个位置、哪个元素不同，比 unittest 的“两个列表对象不相等”好用太多。

万一你想自定义失败消息，直接加说明即可：

assert response.status_code == 200, f"expected 200, got {response.status_code}, body={response.text}"

这条在实际排障时帮过大忙：光是状态码和响应体的前两百字，就能定位 80% 的接口问题。

3.2 接口/Web 项目常用的断言组合

接口测试里，我的断言套路基本是这样：

def test_create_order_success(client, order_payload): resp = client.post("/api/v1/orders", json=order_payload) assert resp.status_code == 201 data = resp.json() assert data["order_id"] assert data["status"] == "CREATED" assert data["total"] == order_payload["total"]

这里要注意三点：第一，状态码断言一定要用语义化的值如201 Created对应的数值201，不要用 200 一把梭；第二，字段存在的断言assert data["order_id"]可以同时校验非空，但要注意 order_id 如果是 0 就会被误判；第三，不要断言整个响应体精确等于某个 dict，因为里面有时间戳、随机 id 等不稳定字段，盲目全等会让测试变得脆。

数据类断言有一个好用的工具——jsonschema。对复杂接口，我会把返回结构定义成 JSON Schema，然后用jsonschema.validate验证。这样做的好处是：结构变化时，测试失败信息能精确告诉你哪个字段缺失或类型不对，而不是只看到一串 dict 差异。

3.3 浮动比较与异常断言

关于数字断言，UI 或金额计算里经常遇到浮点误差问题。断言0.1 + 0.2 == 0.3必定失败。用pytest.approx：

assert total == pytest.approx(102.3, rel=0.01)

approx支持相对误差和绝对误差，实际业务里我习惯abs=0.01这种绝对误差，因为金额类计算相对误差可能掩盖掉真正的错误。

异常断言，用pytest.raises：

def test_get_user_not_found(client): with pytest.raises(HTTPError) as exc_info: client.get("/api/v1/users/999999") assert exc_info.value.response.status_code == 404

这里很多新手会写法：

with pytest.raises(Exception): ...

不要这么写，捕获Exception会把KeyboardInterrupt、SystemExit之外的所有异常都吞掉，一旦逻辑里有其他 bug 也会被当成“符合预期”放过。尽量精确到具体的异常类型。

4. fixture：测试代码里的“依赖注入容器”

4.1 fixture 作用域和自动使用

fixture 是 pytest 最核心也是最强大的概念。很多人把 fixture 简单理解为“setUp/tearDown 的替换品”，但实际上它是一个可组合的依赖注入系统。

作用域（scope）是 fixture 最重要的参数：

我踩过最大的坑是过度使用 session 作用域。比如一个db_connectionfixture 设为 session 级别，看起来效率很高，但如果在测试过程中误操作了数据库状态（比如某个测试把一张表清空了），下一个测试文件还会用着这个“污染过”的连接，排查起来极其痛苦。所以我的原则是：默认 function 作用域，只有创建/销毁成本确实很高（如浏览器驱动、真实网络服务）时才提升作用域级别，并且把状态清理逻辑写进 fixture 的 yield 之后部分。

fixture 的依赖注入方式很直观：

@pytest.fixture def user_token(client, user_credentials): resp = client.post("/login", data=user_credentials) return resp.json()["token"] def test_me_endpoint(client, user_token): resp = client.get("/me", headers={"Authorization": f"Bearer {user_token}"}) assert resp.status_code == 200

client和user_credentials是两个独立 fixture，user_token依赖它们，测试函数再依赖user_token。这种层层组合的方式比继承清爽太多。

如果想对一个作用域内的所有测试自动生效，用autouse=True：

@pytest.fixture(autouse=True) def disable_external_requests(): """全局禁用真实外部网络请求""" ...

autouse 一定要慎用，它会隐式地在每个测试前执行，全局影响面大。我在一个项目里见过有人把初始化大量数据的 fixture 设成 autouse，结果每个人改代码都要等半天测试初始化。正确的做法是只在需要的地方显式声明依赖。

4.2 yield fixture 与清理逻辑

fixture 里的yield之前是 setup，之后是 teardown。例如操作临时目录：

@pytest.fixture def tmp_workspace(tmp_path): workspace = tmp_path / "workspace" workspace.mkdir() yield workspace shutil.rmtree(workspace, ignore_errors=True)

但要注意tmp_path本身就是 pytest 内置的临时目录 fixture，测试结束后会自动清理，显式调用rmtree通常没必要。真正的场景是：你创建了一个外部的进程、端口、文件句柄，测试结束后必须释放。

fixture 抛异常的位置不同，行为也不同。yield之前抛异常，pytest 判定 fixture setup 失败，对应测试会被 error；yield之后抛异常，pytest 则在该用例结束后报 teardown error。这意味着清理代码里的异常不能被吞掉，建议在 teardown 里打印日志而不是盲目 catch。

4.3 工厂式 fixture 与动态数据

有时候一个 fixture 返回固定对象不够用，测试里需要动态传参。此时可以把 fixture 设计成工厂函数：

@pytest.fixture def make_order(): orders_created = [] def _create(order_id=None, amount=None, **kwargs): order = Order( order_id=order_id or str(uuid4()), amount=amount or calc_random_amount(), **kwargs ) orders_created.append(order) return order yield _create for o in orders_created: o.delete() # 统一的清理入口

这种模式的精髓是“生产在函数内部、清理在 fixture 外部”，测试只关心创建参数，不用重复写清理代码。还有一个附带的好处：可以在内部增加一个计数器或日志列表，测试结束后校验“创建了 N 个对象”之类的全局效应。

5. 参数化与动态测试生成

5.1 参数化基础与数据来源

@pytest.mark.parametrize应该是 pytest 里使用频率最高的内置装饰器。把测试数据与测试逻辑分离，可以减少大量重复代码，同时也让“新增一条测试场景”变成“新增一行数据”。

最简单的用法：

@pytest.mark.parametrize("a,b,expected", [ (1, 2, 3), (2, 2, 4), (0, 5, 5), ]) def test_add(a, b, expected): assert a + b == expected

数据量少还好，一旦超过十组，写在装饰器里就非常难读。我会把数据单独放到模块顶部的列表或外部 JSON/YAML 文件里。

TEST_CASES = [ pytest.param(1, 2, 3, id="one_plus_two"), pytest.param(-1, 1, 0, id="negative_and_positive"), pytest.param(100, -20, 80, id="large_offset"), ]

pytest.param的id参数能自定义用例名。跑起来显示的是test_add[one_plus_two]，一眼就看出哪组数据失败。如果不给 id，默认会显示参数值，遇到长字符串数据时终端里一长串乱码，可读性极差。

5.2 数据驱动：Json/Yaml 管理测试数据

当测试数据量庞大，比如支付渠道有几百个异常码要分别验证时，把数据外置到 JSON 文件是更推荐的做法：

import json def load_cases(path): with open(path, encoding="utf-8") as f: return json.load(f) @pytest.mark.parametrize("case", load_cases("data/error_codes.json")) def test_error_code_handling(case): code = case["code"] resp = simulate_payment_error(code) assert resp.status_code == case["expected_status"]

外置数据的存储文件怎么组织，没有绝对的标准，但我会遵循：一份数据对应一个测试文件；测试文件的数据结构字段名和断言逻辑强相关，不要一套数据结构到处复用。否则改了一个文件，另外两个测试文件跟着破。

5.3 组合参数的注意点

参数化里最容易踩的坑是组合爆炸。看一个例子：

@pytest.mark.parametrize("env", ["dev", "staging", "prod"]) @pytest.mark.parametrize("user", ["alice", "bob", "carol"]) def test_login_performance(env, user): ...

这里会生成 3 * 3 = 9 个用例。真实项目里如果叠加三重甚至四重参数化，用例数会指数级增长。有一次我写了 3 个装饰器各 10 组参数，一跑直接 1000 个用例，光初始化就花了几分钟。所以参数化组合要克制，通常只对两个维度做全组合，第三个维度单独抽出来用循环或工厂 fixture 控制。

5.4 自定义 hook 动态添加参数化场景

有些更灵活的场景，参数是运行时才知道的，比如根据数据库里存在的用户列表动态生成数据。这可以用pytest_generate_testshook 实现：

def pytest_generate_tests(metafunc): if "user_case" in metafunc.fixturenames: cases = fetch_users_from_db() # 自定义逻辑 metafunc.parametrize("user_case", cases, ids=[c["id"] for c in cases])

这个 hook 会为所有需要user_casefixture 的测试函数生成参数化数据。注意这里的 DB 访问最好在初始化阶段做好缓存，否则每个测试函数都会跑一次，性能堪忧。

6. 工程化配置：从能用到好用

6.1 插件矩阵与作用说明

pytest 的生态是它最大的护城河。我维护项目时几乎固定使用以下插件：

不过，插件不是越多越好。每个插件都可能在 fixture、hook 层面产生冲突。尤其pytest-xdist和pytest-rerunfailures同时用时，有时候会在重跑时的 random seed 或 fixture 作用域上出问题。我的建议是：从最小插件集开始，逐步增加，每加一个插件就运行一次全量测试看有没有行为变化。

6.2 覆盖率配置与阈值控制

统计覆盖率之前，先想清楚一件事：覆盖率数字不等于代码质量，它只是“哪些代码被执行过”的度量。接口测试更适合做功能覆盖率（每个接口必达），而单元测试适合做行/分支覆盖率。

在 pyproject.toml 里配置：

[tool.coverage.run] source = ["app"] branch = true omit = [ "app/main.py", "app/__init__.py", ]

source指定要统计的包目录，omit排掉不想统计的入口文件和初始化代码。branch = true开启分支覆盖率，能帮助发现 if/else 里没测到的分支。

执行时：

pytest --cov=app --cov-report=term-missing --cov-fail-under=80

--cov-fail-under=80让覆盖率低于 80% 时整个测试流程失败，适合在 CI 里强制执行。但这里有个教训：一开始就把阈值设到 90% 以上，很容易导致团队为了凑覆盖率写一堆毫无断言的测试，反而造假。建议先跑出基线，比如 60%，逐渐提高到 80% 以上，同时配合--cov-report=html生成 HTML 报告供人工查看。

6.3 CI 集成与测试报告输出

在 CI 流水线里，测试环节通常是这样的：

pip install -r requirements-dev.txt pytest --maxfail=3 -n auto --dist=loadgroup \ --rerun=2 --rerun-delay=2 \ --html=report.html --self-contained-html \ -m "not slow"

重点解析：

• --maxfail=3：一旦出现 3 个失败就终止整个测试任务，避免后续用例白跑浪费时间，适合 CI 的快速失败策略。
• -n auto --dist=loadgroup：按测试模块分发任务，把耗时相近的用例集合在一起执行。
• --rerun=2 --rerun-delay=2：对偶发失败重跑 2 次，间隔 2 秒。
• --html=report.html --self-contained-html：生成单文件报告，方便发邮件或归档。

如果要往 CI 日志里输出失败摘要，可以用：

pytest --tb=short -q

--tb=short只显示每个失败用例的异常位置和局部变量，比默认的长 traceback 可读性好很多，尤其在日志滚动的 CI 场景里。

6.4 marker 的工程化用法

项目里 marker 应该用来分层测试。我自己固定的 marker 体系：

@pytest.mark.smoke def test_core_login(): ... @pytest.mark.slow def test_report_generation(): ... @pytest.mark.p0 def test_payment_flow(): ...

日常本地调试用：

pytest -m "not slow"

发布前回归跑：

pytest -m "p0 or smoke"

marker 不要滥用，一般 3 到 5 个就够了。用得越多，团队对“这个标记到底过滤什么”的理解成本越高。

7. 常见问题排查与疑难杂症实录

这部分是长期实战攒下来的经验，挑几个特别典型、经常见到的坑，整理成速查式内容。

7.1 测试方法顺序和随机问题

有时候你单独跑一个测试用例是过的，两个一起跑就挂；或者每次执行顺序不同，结果时好时坏。这种情况的原因，绝大多数是共享状态被污染。典型的污染源有：

• 模块级全局变量被某个用例修改了。
• fixture 返回的是可变对象（dict/list），测试里直接改动了它，导致下一个用例的 fixture 依赖这个被改过的对象。
• session 级的数据库连接/缓存实例中残留了上一个用例的数据。

排查方法快速有效：对可疑用例加--count=2连续执行多次看是否必现，再用-p no:randomly禁用随机顺序确认是否与顺序有关。最彻底的解决方案是——每个用例使用独立的 fixture 实例，避免共享可变对象。

这里分享一个我非常强烈的建议：fixture 千万不要返回全局单例的可变 dict，然后让测试用例直接改它。如果非要有这种“共享配置”数据，返回一个深拷贝或者用MappingProxyType包装成只读结构。

7.2 fixture 创建参数化数据冲突

fixture 配合参数化时有一个非常隐蔽的问题。比如：

@pytest.fixture def user(request): return create_user(request.param) @pytest.mark.parametrize("user", ["admin", "guest"], indirect=True) def test_permission(user): assert user...

indirect=True表示把参数传给 fixture，而不是直接传给测试函数。这里如果不加indirect=True，pytest 会把参数作为普通数据传入测试函数，fixtureuser不会被创建。这个细节很坑，因为参数名和 fixture 名重名时，pytest 的解析优先级是 fixture 优先，但如果加了indirect=False，则直接把参数值传给测试函数，fixture 会被绕过。理解这一点，才能灵活控制数据由 fixture 处理还是直接使用。

7.3 偶发失败的处理

偶发性失败（flaky test）最消耗团队信任。重跑插件能掩盖一部分问题，但治标不治本。我的处理原则是：

• 先用pytest --count=10复现频率，确认是必现还是偶现。
• 分类排查：
  • 网络类：加上超时断言，比如响应必须 2 秒内返回，而不是无限等待。
  • 时间类：生成唯一订单号用 uuid，避免时间戳碰撞。
  • 并发类：测试库数据互相干扰，加事务回滚或每个用例独立数据。
  • 环境类：依赖某个本机路径或端口，统一用 fixtures 提供 mock 或临时代替。
• 偶发里最狡猾的是“顺序依赖”。例如 A 用例创建订单，B 用例查询订单，虽然 B 明明有自己的数据准备，但 A 执行失败导致 B 里的数据多了一条，查询结果从 1 条变 2 条。解决方法是断言精确的订单号，而不是“返回列表长度等于 1”。

7.4 运行速度太慢怎么优化

测试数量上来后，全量跑一次甚至以小时计。建议从这几个方向优化：

1. 合理利用 xdist：-n auto并行执行，多核机器效果立竿见影，但要注意数据库、文件目录等资源隔离，否则并行后互相干扰。
2. 分层分级：冒烟/接口/集成测试分开，日常提交只跑冒烟和接口，发布前全量跑。
3. 分析耗时项：用--durations=10查看最慢的 10 个用例。实际项目里经常发现 90% 的时间花在 10% 的用例上，针对它做优化性价比最高。
4. 减少重复初始化：大型 fixture（如 Docker 容器、数据库初始化）用 session 作用域复用，同时把状态清理做到 yield 后。
5. 免测原则：不是每个函数都需要测试，纯 getter/setter、简单的数据转移类代码可以跳过，集中力量测试有业务逻辑的部分。

7.5 输出太冗长怎么办

默认的 pytest 输出在大量用例时非常吵。我的常用组合：

pytest -q --tb=short --disable-warnings --no-header

• -q：只显示文件名和测试名。
• --disable-warnings：关闭警告输出，但前提是你确认这些 warning 不是风险信号。
• --no-header：去掉启动界面的环境信息。

如果还想要好看的 UI，建议用pytest-sugar。个人体验：本地开发用 sugar，CI 用不带插件的原始输出，日志更干净。

8. mock 与外部依赖

测试里最危险的是访问真实外部系统，比如第三方支付 API、短信服务、邮件网关。首先我们要明白，mock 的边界不是“一概不用”，而是“不该访问外部时绝不访问”。核心链路可以用 mock 替代，但真正的支付或短信接口的兼容性，应当靠单独的“契约测试”或可控的沙箱环境来验证，不能全依赖 mock。

8.1 用 monkeypatch 改变行为

pytest 自带的monkeypatchfixture 可以在测试里安全替换属性或方法，测试结束后自动还原，非常干净，比手动 try/finally 改unittest.mock.patch省心：

def call_external_api(): return requests.get("https://example.com/data") def test_call_external_api(monkeypatch): def fake_get(*args, **kwargs): return SimpleNamespace(status_code=200, text="fake") monkeypatch.setattr("module.requests.get", fake_get) assert call_external_api().status_code == 200

注意 monkeypatch 替换的是模块里的引用点，而不是 requests 库本身。也就是说，如果业务代码是from requests import get这样导入的，monkeypatch 应该设置module.get，而不是requests.get。

8.2 用 pytest-mock 简化 mock

如果项目里已经大量使用unittest.mock，用pytest-mock插件可以把 mock 对象作为 fixture 传入：

def test_with_mocker(mocker): mock_redis = mocker.patch("app.cache.redis_client.get", return_value="cached") result = get_from_cache("key") assert result == "cached" mock_redis.assert_called_once_with("key")

pytest-mock的好处是它自动管理了 mock 的清除和恢复，不用担心 patch 泄漏到其他用例。加上assert_called_once_with这类断言，比单纯验证返回值更能约束行为。

8.3 模拟时间与随机数

时间相关的测试，用freezegun：

from freezegun import freeze_time @freeze_time("2024-06-01 12:00:00") def test_order_create_time(client): resp = client.post("/orders", json=...) assert resp.json()["created_at"] == "2024-06-01T12:00:00"

随机数相关的测试，用random.seed(固定值)或者在 fixture 里替换random.random为固定函数。实际项目里订单号、密码盐、验证码这类随机逻辑，建议设计成可注入的随机源，测试时传入伪随机数列，而不是依赖全局 random 状态。

9. 大型项目中的测试分层设计

9.1 单元/集成/端到端的划分

测试金字塔不是一个新鲜概念，但在 pytest 项目里怎么落地，很多人是模糊的。我的划分逻辑：

• 单元测试：针对单个函数/方法，不启动外部服务，不访问数据库。用假数据或 mock 隔离所有边界。目标是速度快、问题定位准确。
• 集成测试：测试模块之间的协作，通常涉及数据库、Redis、文件系统。会真访问这些基础设施，但会在测试环境里隔离数据，测试结束后清理。
• 端到端测试：模拟真实用户操作整个系统，通常需要 UI 或完整 API 链路。运行时间长，数量最少，只在关键路径上用。

目录结构我习惯这样分：

tests/ ├── unit/ │ ├── test_price_calculator.py │ └── test_utils.py ├── integration/ │ ├── test_order_api.py │ └── test_user_api.py ├── e2e/ │ └── test_full_purchase_flow.py └── conftest.py

9.2 测试数据统一管理

无论哪一层测试，数据的一致性都重要。我在项目里做了tests/data目录，里面放 JSON/YAML 文件，conftest.py 里提供几个通用 fixture 用来加载：

@pytest.fixture def load_fixture_data(): def _load(name): with open(f"tests/data/{name}.json", encoding="utf-8") as f: return json.load(f) return _load

在测试里使用：

def test_create_order(client, load_fixture_data): payload = load_fixture_data("order_valid") ...

数据文件和测试用例分离后，新增测试场景不用改测试代码，只改数据文件，大大降低了维护成本。注意数据的命名要有业务含义，比如order_valid、order_missing_amount、order_negative_quantity，方便新人快速理解场景意图。

9.3 测试报告的长期归档

CI 中的测试结果报告不只是看一眼，还要存起来用于趋势分析。pytest-html 生成 HTML 报告后，我会把 XML 格式也输出，方便程序解析：

pytest --junitxml=test-results.xml --html=report.html

CI 里把这些报告设置成 artifact，每次提交都能看到历史趋势。线上出了故障，可以快速比对“这个测试规则是新增的还是改动过的”。

10. 最后的几点经验

写 pytest 测试其实和写业务代码一样，长期维护的核心是“简单、明确、可预测”。我见过很多测试项目从热火朝天走向荒废，不是因为框架不行，而是因为测试代码被写得太复杂、太依赖执行顺序、太多 mock 导致失去信心。

实际用下来给我最大帮助的三个做法：

第一，测试目录和业务目录严格分离，但 conftest 的层级设计要趁早定好。不要等 fixture 写了几百个再回头重构，那比重构业务代码还痛苦。

第二，频繁跑、小步跑。不要憋到下班前才跑一次全量测试，那会把一天攒下来的错误一次性爆发出来。配合-m "not slow"和--maxfail=3，随时提交随时验证。

第三，敢于删测试。如果一个测试已经连续两三个月没失败过，而且它的业务逻辑也不在了，那它可能只是耗时的摆设。与其保留“假安全感”，不如删掉，把精力留给真正会暴露问题的用例。

pytest 远不止一个测试框架，它背后体现的工程理念是：测试应该是开发者的朋友，而不是负担。希望这些踩坑记录能帮你少走一些弯路。如果你在项目里也遇到类似问题，或者有更好的实践方式，欢迎在评论里交流。