1. fixture到底是解决什么问题的两个版本的代码对比你先回想一下自己写自动化测试的早期阶段。那时候我接手的项目里每个用例开头都要连数据库、创建临时用户、往缓存里塞数据跑完再用例内部清理。当时最痛苦的不是写这些代码而是它们散落在几十个用例文件里几乎每份测试代码的前十行长得一模一样。后来遇到一个老同事他指着pytest源码说你这种写法核心问题在于把“准备”和“清理”的逻辑硬编码进了用例而框架明明给你设计了更好的地方来放它们。这就是fixture存在的意义——它把测试运行前的准备和运行后的清理从测试用例函数里抽离出来变成独立的、可复用的、声明式的组件。先看一个不用fixture时的典型测试代码def test_user_profile(): # 准备阶段 db create_db_connection(test_db) db.reset() user db.create_user(tester_001, roleadmin) token login(user.name, user.password) # 测试阶段 resp client.get(f/api/users/{user.id}, headers{Authorization: token}) assert resp.status_code 200 # 清理阶段 db.delete_user(user.id) db.close()一个用例里混合了四件事环境初始化、业务数据构造、被测动作、清理动作。如果数据库连接方式变了所有用例都要跟着改如果某个用例忘记调用清理测试数据就一直留在库里下轮跑就出脏数据。用fixture改造之后import pytest pytest.fixture def db(): connection create_db_connection(test_db) connection.reset() yield connection connection.close() pytest.fixture def new_user(db): user db.create_user(tester_001, roleadmin) yield user db.delete_user(user.id) pytest.fixture def user_token(new_user): return login(new_user.name, new_user.password) def test_user_profile(new_user, user_token): resp client.get(f/api/users/{new_user.id}, headers{Authorization: user_token}) assert resp.status_code 200整个测试函数只剩业务动作和断言准备和清理全部下沉到fixture里。你不需要在每个用例里重复书写连接、创建、删除这些样板操作只要在函数参数上声明你“需要”什么pytest就自动帮你把对应的fixture结果“注入”进来。初看这个语法你会觉得奇怪明明没有调用任何函数参数名凭空出现一个new_user为什么它自动有值这就是pytest fixture的依赖注入机制——测试函数声明了形参pytest会在执行测试前去查找同名的fixture函数执行它并把返回值或yield的结果作为参数传给测试函数。因为这个查找是自动的所以你不需要在任何地方显式写new_user ...。fixture的核心价值我总结下来其实就三条复用性同一个准备逻辑写完一次任何测试函数声明参数即可获得。清晰分层数据库连接是环境类依赖用户数据是业务类依赖登录状态是组合类依赖各层fixture各管一段。自动收尾yield之后的代码就是teardown用例结束后pytest自动触发保证清理不会遗漏。这套机制你一旦上手就再也不想回到setUp/tearDown那一套老写法里去了。2. fixture的执行机制作用域、依赖顺序与conftest的边界fixture看着只是“带装饰器的函数”但真正决定它好用还是难用的是执行机制。我拆成三块说作用域、执行顺序、存放位置。2.1 五种作用域怎么选才不浪费测试时间fixture有个scope参数决定它在多大范围内只执行一次。pytest支持五种级别我直接做了一张对比表scope值生命周期典型用途注意点function默认每个测试用例执行前/后各一次临时文件、每个用例独立的数据、隔离的浏览器实例最安全但耗时操作难以复用class每个测试类执行前一次类内共享的实例数据用例之间仍然共享状态需保证只读module每个测试模块.py文件执行一次模块级数据库连接、配置信息模块内多个用例共享package每个测试包执行一次包级初始化、跨模块资源用得相对少目录结构配合要清晰session整个测试会话执行一次全局配置、一次性启动的容器环境、生成长期凭证最大程度复用但处理不当会污染全局状态选作用域的核心原则只有一条复用的代价是不是可控的。一个耗时的登录流程如果每次用例都重新走一遍测试时间会翻好几倍把它提升到session级只跑一次是合理的但如果登录状态本身会被用例修改比如某条用例把用户踢下线了session级的复用处就反而变成坑。pytest.fixture(scopesession) def admin_token(): # 只在会话开始时登录一次 resp login(admin, admin123) return resp.json()[token]2.2 依赖顺序pytest怎么决定先跑哪个fixturefixture之间可以相互依赖一个fixture直接以另一个fixture的名字作为参数即可。pytest在解析依赖时用的是深度优先策略如果测试函数需要user_token而user_token依赖new_usernew_user又依赖db那执行顺序就是db-new_user-user_token- 测试函数本身。这里最容易被忽略的一点是teardown的执行顺序和setup是反的。还是用上面的例子执行完测试后pytest会先清理user_token相关的资源再清理new_user的用户记录最后才关掉db连接。这个“先开后关”的顺序有它的合理性你不可能在数据库还没关的时候就删不了用户更不可能在用户还没删的时候就去关登录态。理解了这个依赖链的逆向顺序你就知道在yield后面的清理代码里不要做依赖上游资源的事情。如果你担心fixture层级太多导致执行顺序不直观可以加pytest --setup-show来观察实际执行顺序pytest tests/test_user.py --setup-show它会打印出每个fixture的调用和返回顺序排查依赖问题时比看代码更快。2.3 conftest.py的层级fixture的近水楼台fixture写在哪决定了它被谁看见。pytest规定fixture可以定义在测试文件内部只能当前文件用也可以定义在conftest.py里对同一目录及子目录下的所有测试可见。如果多级目录都有conftest.py那pytest的查找方式是从测试文件所在目录向上逐级搜索先找到的先用。目录结构示例tests/ ├── conftest.py # session级db连接全局可见 ├── api/ │ ├── conftest.py # api模块共用的登录fixture │ ├── test_user.py │ └── test_order.py └── ui/ ├── conftest.py # ui模块启动浏览器的fixture └── test_login_page.py我把这个结构当成测试工程里约定俗成的分层方式根目录conftest放最底层的资源数据库连接、全局配置子目录conftest放该模块专属的前置条件API模块的登录态、UI模块的浏览器驱动测试文件内只放极度场景化的临时fixture。有个坑得提醒你不要在子目录的conftest里定义与上级同名同目的fixture来“覆盖”比如根目录已经定义了scopesession的db子目录又定义一个scopefunction的同名db那子在目录下跑的时候用的是子目录的但目录外跑的时候用的是根目录的同一个测试工程的数据库行为竟然不一致。遇到这种需求正确的做法是给fixture取不同名字比如db和db_function或者用override_option这类机制去处理而不是靠同名遮蔽。3. 进阶特性yield清理、参数化、autouse与内置fixturefixture的基础用法只能解决“准备资源”真正让它成为核心能力的是后面这四个进阶特性。它们解决的是自动化测试里那些最容易写出重复代码的场景清理、多组数据、隐含前置条件、临时环境操作。3.1 yield把一个fixture变成完整的setup/teardown普通函数式的fixture只能准备资源但测试跑完之后资源必须释放。pytest的做法很简单fixture函数中用yield分割yield之前的代码就是这个fixture的setupyield之后的代码是teardown无论测试函数抛断言异常还是系统崩溃只要pytest能捕获到teardown就一定会执行。pytest.fixture def temp_db(): engine create_engine(sqlite:///:memory:) create_tables(engine) yield engine engine.dispose()你甚至可以在yield处把异常处理包上try/finally进一步保证teardown的可靠性。我建议在任何涉及数据库连接的fixture里都写上try/finally因为yield后的代码理论上会被pytest保证执行但万一fixture的setup阶段自身就抛异常了yield后面的代码可能不会走到这时候finally里做连接清理更稳妥。这里要特别提示一点fixture的yield和生成器的yield是两回事。fixture的yieldpytest会在测试执行结束后通过内部的fixture执行器再次调用生成器的next来触发teardown代码不是真的把你当迭代器所以不要在fixture里写无限循环或多次yield。3.2 参数化fixture一组参数跑出多个用例fixture自身可以带params参数pytest会拿着params里的每一组数据把fixture执行一遍最终让依赖它的测试函数运行的次数等于参数组合数。这在接口自动化测试里非常常用。pytest.fixture(params[ {role: admin, expect_code: 200}, {role: guest, expect_code: 403}, {role: banned, expect_code: 401}, ]) def auth_context(request): role request.param[role] token login(role) yield {role: role, token: token, expect_code: request.param[expect_code]} logout(token) def test_role_access(auth_context): resp client.get(/api/admin_panel, headers{Authorization: auth_context[token]}) assert resp.status_code auth_context[expect_code]同一个测试函数因为auth_context的param不同会执行三遍每一遍都有独立的fixture实例和独立的teardown。这就省去了用参数列表循环的麻烦而且每条参数组合在测试报告中是单独呈现的哪个角色挂了直接定位。在使用request.param时要记得request是pytest内置的fixture它携带了当前fixture实例的上下文。另外参数化fixture内部不要修改request.param的内容因为它在多个fixture实例之间可能是共享的改了就影响下一轮。3.3 autouse让测试不感知的fixtureautouseTrue可以让fixture在不需要显式声明的情况下自动应用于当前作用域内的所有测试。它适合放那些“每个用例都必须有但用例本身不关心”的隐含前置条件。典型场景是环境变量准备和日志采集pytest.fixture(autouseTrue, scopemodule) def setup_env(): os.environ[TEST_MODE] true yield os.environ.pop(TEST_MODE, None)用了autouse之后模块内任何一个测试函数都不用写setup_env参数环境变量却已经被准备了。但autouse是把双刃剑它最大的风险是制造隐式依赖一个测试明明依赖某个初始化数据代码里却没有任何线索。看代码的同事会在测试函数里找不到这个fixture的引用只有查conftest才能知道。我的个人经验是autouse只适合那些“所有测试无条件需要”的东西比如测试模式的环境变量、审计日志不适合业务数据准备。3.4 内置fixture你其实已经自带了一套工具箱pytest内置了大量官方fixture写测试时不用重新造轮子这里说三个我最常用的tmp_path每个测试独享的一个临时目录fixture自动清理不用管文件残留。capsys捕获测试里的stdout/stderr输出用capsys.readouterr()拿到结果并断言。monkeypatch安全地动态修改属性和环境变量测试结束后自动还原。def test_log_output(tmp_path, capsys, monkeypatch): monkeypatch.setenv(LOG_LEVEL, DEBUG) p tmp_path / app.log p.write_text(hello pytest) print(running test) captured capsys.readouterr() assert running test in captured.out assert p.read_text() hello pytest很多人第一次接触这几个内置fixture时才发现自己花了一下午手写的临时文件管理、打印捕获、环境变量打桩原来pytest早就做好了。4. 实战落地接口自动化测试里的fixture设计范例理论讲得再多不如一个完整的设计案例。我拿一个典型的用户中心接口测试模块来拆解需要登录、需要数据库有干净的用户数据、需要生成唯一的手机号、每个用例跑完要清理数据。同时结合allure报告来呈现测试结果分层。先看目录tests/ ├── conftest.py └── api/ ├── conftest.py ├── test_user_center.py └── data_factory.py根目录conftest.pyimport pytest from db import TestDatabase pytest.fixture(scopesession) def db(): _db TestDatabase() _db.reset_schema() yield _db _db.close_connection() pytest.fixture(scopesession) def base_url(): return http://internal-test-server/apiapi/conftest.pyimport pytest import allure pytest.fixture def real_phone(db): 生成唯一手机号并保证测试结束后删除该用户 phone db.generate_unique_phone() yield phone db.delete_user_by_phone(phone) pytest.fixture def registered_user(real_phone, db): 注册一个新用户返回用户信息和请求头 register_payload {phone: real_phone, password: Pssw0rd} resp requests.post(f{base_url}/register, jsonregister_payload) assert resp.status_code 201 token resp.json()[token] yield { phone: real_phone, token: token, user_id: resp.json()[user_id], } with allure.step(清理用户数据): db.delete_user_by_phone(real_phone) pytest.fixture def auth_header(registered_user): return {Authorization: fBearer {registered_user[token]}}test_user_center.pyimport allure import pytest pytestmark allure.suite(用户中心接口) allure.title(查询用户个人信息) def test_get_profile(auth_header, base_url): resp requests.get(f{base_url}/user/profile, headersauth_header) assert resp.status_code 200 assert resp.json()[phone] # 手机号能被查到 allure.title(更新用户昵称) def test_update_nickname(auth_header, base_url, db): new_nickname 测试昵称 resp requests.patch(f{base_url}/user/nickname, headersauth_header, json{nickname: new_nickname}) assert resp.status_code 200 assert db.get_nickname_by_phone(auth_header[phone]) new_nickname这个设计里各层fixture的职责单一db负责库表初始化和最终连接释放整个测试会话跑一次代价最小。real_phone负责生成唯一号码这个fixture本身不注册用户只是数据规则的一部分。registered_user在real_phone基础上注册适用所有需要真实用户数据的接口用例同时用allure.step记录清理动作报告里能看到测试后数据恢复的痕迹。auth_header在registered_user之上封装请求头让用例代码里不需要再拼token。你注意到没有我在auth_header的fixture里甚至没有写yield因为不需要清理。pytest允许这种不带yield的fixture它只是一个正常的资源准备函数。对接口自动化来说这是fixture最简单的形态。这套设计跑下来的实际效果300个接口用例执行完测试库里的临时用户记录永远是0每条用例在allure报告里的依赖顺序一目了然哪个环节慢、哪个环节失败看fixture名称就能定位。接口自动化最怕的就是用例互相污染fixture的依赖注入强制你把数据准备从用例里抽出来这种“污染源”就被天然隔离了。5. 我踩过的fixture坑作用域误用、隐式依赖与过度设计用fixture两年之后我发现它也会带来一些新问题。这几个坑是真实项目里最容易出现的我一个个拆5.1 session级fixture依赖function级fixture一跑就报错pytest有个硬性规定如果一个session级fixture依赖了一个function级fixture或者说一个更大作用域的fixture依赖了更小作用域的fixture运行时会直接报错。因为你申请session级fixture的意图是全程只跑一次结果它依赖的function级fixture却每个用例都会重新执行两者矛盾。pytest.fixture(scopesession) def global_token(new_user): # 报错new_user是function级 return new_user.token遇这类设计通常说明你对作用域的定义出了问题要么global_token降级为function级要么把new_user提升为session级但要承担session级数据共享的后续风险。我给你的建议是先在纸上把依赖链的每个fixture作用域列出来保证任意一条依赖链的作用域是从大到小的顺序session - module - function。5.2 autouse过多导致测试不知道自己在依赖什么我接手过一个模块conftest里有六个autouse fixture各自初始化不同数据测试文件里看不出来任何引用。有一天其中一个autouse fixture改了初始化规则该模块四十个用例在毫不知情的情况下全部失败。排查时看到用例里没有对应参数第一反应根本不会往autouse想。autouse会让你的测试依赖变成“隐式依赖”这其实是可读性和可维护性的隐形杀手。我的建议保留最多一到两个autouse fixture且只用于全局性的、无条件的准备如测试模式标记、日志初始化其余全部改成显式声明参数。显式依赖虽然长了一点但任何人读代码都能一眼看出这个用例依赖了哪些资源。5.3 fixture返回共享可变对象用例间互相污染一个module级fixture返回一个字典给模块内所有用例用。如果第一条用例往这个字典里写了个字段第二条用例读取时就多了一条脏数据。因为fixture是同一个实例可变对象的修改在模块内是共享的。修复办法看你的意图如果每个用例都应该拿到独立副本就改成函数返回拷贝pytest.fixture(scopemodule) def user_pool(): return {} pytest.fixture def current_user(user_pool): user user_pool.get(current_user, default_user()) return copy.deepcopy(user)如果确实是需要共享状态如全局计数器那你要在用例设计阶段就明确这个状态是“只读”还是“可写”只读就用tuple代替list可写就单独抽成一个线程安全的计数器类。5.4 fixture里放太多业务逻辑变成“抽象泄露”fixture的本意是准备资源但很多人会把业务操作也塞进fixture。比如fixture里调了五次接口、做了三步断言和业务用例的代码几乎一样长。这时fixture已经从“测试资源”变成了“测试逻辑”一旦断言失败你会分不清是业务bug还是fixture的bug。我的做法是fixture只负责准备输入数据和清理环境不负责断言业务结果。fixture内部的异常如果是资源问题连接失败、数据创建失败就直接抛让测试失败正常的业务校验放在用例里做。比如注册用户这个fixture里不要断言注册接口返回的每个字段顶多断言状态码是201因为它只是为后续业务做数据准备不是被测对象。5.5 teardown里依赖上游资源关闭顺序混乱前面讲的依赖链路里fixture清理顺序是逆向的所以teardown代码里不要访问已经关闭了的上游资源。如果你在new_user的cleandown里还调用了db连接但db的teardown已经被执行了这里就会拿到一个已经关闭的连接。这种情况要么把new_user和db合并成一个fixture要么把db的作用域提到更高层级保证db最后才关闭。pytest.fixture(scopesession) def db(): conn create_connection() yield conn conn.close() # 这里会在所有依赖它的fixture之后执行 pytest.fixture def new_user(db): user db.create_user() yield user db.delete_user(user) # 安全db还没关闭5.6 fixture数量爆炸维护成本转移到依赖图上fixture设计到后期最常见的病是每个可能被复用的片段都提取成一个fixture最终一个conftest上有三十多个fixture互相依赖关系复杂得像一张网。新来的同事根本分不清该用哪个fixture。这时候的修复方向是“合并职责”把同一资源的不同封装合并成一个fixture通过params或返回值区分使用场景而不是每个场景一个fixture。一个fixture对应一类资源准备这是最好的边界。6. 再分享一点实践习惯最后说几个我坚持了很长时间的实践习惯在conftest的每个fixture上方写一行注释说明“为什么是scopesession为什么依赖另一个fixture”这行注释在两个月后你回来看代码时极其重要。给fixture命名用名词短语不要用prepinit这种宽泛动词加缩写的组合好的fixture名应该让人一看就知道它返回的是什么资源。运行测试时用pytest --fixtures查看当前作用域内可用的fixture清单比翻阅conftest代码效率高得多排查fixture执行顺序用--setup-show想临时跳过某个fixture的执行可以在fixture内部加个环境变量开关不要用全局注释大法。我在实际项目里最大的体会是fixture的好坏直接决定了测试工程的可维护性上限。刚开始写测试时觉得fixture无非是个“初始化函数”用久了才明白它其实是你在测试代码里做架构设计的核心载体——资源分层、依赖关系、生命周期管理全都浓缩在一组fixture里。把fixture设计当成测试工程里的一个正经架构话题来对待你的自动化测试项目才不会跑到一半就变成维护泥潭。