pytest环境切换实战：命令行参数与配置工厂两套方案解析

1. 从“来回改代码”说起的痛点

做自动化测试的都知道，最磨人的往往不是用例怎么写，而是环境怎么切。接口地址、数据库连接、Redis、OSS凭证，这些东西在测试环境、预发布环境、生产环境之间几乎没有一次能完全对上的。你辛辛苦苦把测试环境跑绿了，临上线前想在预发布环境跑一遍回归，结果靠手去改配置文件？改完还得记得改回来，改漏一个配置项，一整套用例全废，还得花半天时间排查到底是代码逻辑变了还是环境变了。

前阵子我接了一个某跨平台结算系统的接口自动化任务，测试用例本身写得挺快，真正耗时间的反而是环境的适配问题。跑测试环境是一套host、一套账号体系，跑预发布又是一套，中间还夹着联调环境。需求方提得也很直接——能不能命令行里指定环境，说跑哪个就跑哪个，不要动代码。

我跟几个开发者朋友聊下来，这种诉求在自动化团队里太普遍了。但很多人第一反应是直接在conftest.py里写os.environ，或者粗暴地维护多个配置文件然后手动改文件名。这些办法不是不能用，只是要么侵入太强、要么容易出错。后来我在这个项目里沉淀出两套相对成熟的方案，一套是解析命令行参数驱动配置加载，另一套是走pytest的hook机制把环境选择抬高到会话级别。这两套方案各有侧重，这篇就展开聊聊它们的取舍和落地细节。

先给零基础的同学补个背景：pytest本身是一个测试框架，conftest.py是它的夹具和钩子的集中注册地。你在conftest.py里定义的fixture，可以被同目录及子目录下的所有用例自动共享。所谓“环境切换”，本质就是让测试代码在运行前拿到正确的配置数据源，并且保证session级别的资源（比如数据库连接）不串环境。理解了这一点，下面的方案才能看明白。

2. 方案一：命令行参数驱动全局配置加载

这套方案的核心思路是靠pytest的钩子函数在用例执行前拦截命令行参数，解析出目标环境名称，然后动态决定配置文件的加载路径。整体不依赖额外的第三方库，是几套方案里最轻量的一种。

2.1 核心思路：把环境命变成配置文件的“钥匙”

大多数项目的配置文件长这样：

# config/test.yaml base_url: "http://test.internal.example.com" db: host: "192.168.1.10" port: 3306 user: "tester" password: "TestPass@2024" # config/pre.yaml base_url: "http://pre.internal.example.com" db: host: "10.20.30.40" port: 3306 user: "pre_user" password: "PrePass@2024"

如果每一次切换都要打开文件替换base_url和db host，不仅效率低，还极容易出现“改了一半”的尴尬情况。方案一的思路是：为每一个环境准备一个配置文件，然后在pytest启动时，解析出用户传入的环境参数，把它当作钥匙，从配置文件目录里选中对应的那份配置加载到全局变量里。

后续的case里，不管是接口的base_url，还是数据库连接的host，都统一从一个全局配置对象里读取，绝不散落在各个用例里。这样做的好处是配置的“单一数据源”被锁死了，不会出现某个用例手写了一个测试环境的IP、另一个用例却用了预发布环境的IP这种问题。

2.2 环境参数解析与配置加载的完整实现

第一步，改造conftest.py，加入一个session级别的fixture，负责读取并缓存配置。

import os import yaml import pytest CONFIG_CACHE = {} def load_config(env_name: str) -> dict: config_path = os.path.join( os.path.dirname(os.path.abspath(__file__)), "config", f"{env_name}.yaml" ) if not os.path.exists(config_path): raise FileNotFoundError( f"未找到环境配置文件: {config_path}，请检查环境名称是否正确。" ) with open(config_path, "r", encoding="utf-8") as f: return yaml.safe_load(f) @pytest.fixture(scope="session") def global_config(request): env_name = request.config.getoption("--env") if env_name not in CONFIG_CACHE: CONFIG_CACHE[env_name] = load_config(env_name) return CONFIG_CACHE[env_name]

可以看到，这里用了一个模块级的CONFIG_CACHE字典。这么做不是为了装样子，而是防止同一个session里多次读取同名文件。虽然yaml文件本身读取很快，但一旦配置文件里包含密钥的解密逻辑，或者文件在远程仓库、需要通过HTTP拉取，缓存的价值就出来了。这是一个容易被忽视的性能优化点，在配置加载成本很低时无所谓，成本高了就是实打实的加速。

第二步，让pytest认识--env这个参数。pytest里要新增命令行参数，最标准的方式是写一个pytest_addoption钩子函数：

def pytest_addoption(parser): parser.addoption( "--env", action="store", default="test", help="指定执行环境: test / pre / prod", )

默认值设为test，保证开发者什么都不传的时候也能跑起来，不至于一上来就报错。使用方在命令行直接执行：

pytest -v --env=pre

pytest会把--env=pre解析到request.config里，global_config这个fixture再根据它的值去选择pre.yaml。整个链路就是“命令行参数 -> request.config -> fixture返回配置对象”，非常清晰。如果部署在CI流水线里，只要在触发脚本里根据分支或用例标签动态传值，就能无缝切换。

2.3 使用场景与优劣边界这种东西

方案一我实际用下来，最爽的一点是足够直观。新加入项目的开发者不需要理解pytest的深层hook机制，只要在用例里声明依赖global_config，然后像读字典一样取配置字段就行。

def test_login(global_config): url = global_config["base_url"] + "/api/login" payload = {...} resp = requests.post(url, json=payload) assert resp.status_code == 200

用例里没有任何环境判断，不需要if env == "test"这样的分支，配置数据是什么就是什么。代码量少，心智负担低。

但它有两个边界问题。

第一个是全局配置作用域统一。global_config是session级别的，同一个session里所有用例拿到的都是同一份配置。如果你的项目需要在一个pytest进程里混跑多个环境的用例，这套方案会失效。不过说实话，正常项目中不太会这么干。为了“一个进程跑多个环境”去牺牲配置的清晰性，有点得不偿失。

第二个是它不解决依赖注入问题。所有配置都是被动读取，如果你的用例里有非常复杂的依赖关系，比如某个连接池必须在环境确定后、但测试数据准备前建立，那么你需要手动控制fixture的加载顺序。不过对于绝大多数接口自动化项目来说，这种复杂度很少出现，属于可以接受的取舍。

注意：使用yaml.safe_load而不是yaml.load，可以避免yaml文件中包含恶意标签时被反序列化成任意对象的安全隐患。虽然配置文件是团队内部维护的，但这个习惯还是要从一开始就养好。

3. 方案二：基于pytest_addoption与fixture工厂的环境上下文

如果你觉得方案一的“一把钥匙开一把锁”还不够灵活，比如配置中除了静态文件，还想叠加从环境变量注入的动态配置，或希望将配置对象按区域、按模块做差异化的覆盖，那么方案二会更合适。

这套方案的思路可以概括为四个字：工厂模式。它不再直接返回配置字典，而是返回一个“配置工厂”，由工厂根据运行上下文决定最终返回什么，并且允许你对不同用例组做二次定制。

3.1 为什么不能所有项目都套用“读文件返回字典”

方案一有一个隐藏假设：不同环境之间，除了配置值不同，配置结构是完全一致的。这个假设在很多长期维护的项目里并不成立。某个环境的数据库可能多了读写分离，另一个环境可能有独立的Redis哨兵集群，再比如某些环境走的是不同的账号体系，连鉴权协议都不同。

强行用同一个schema去套，配置文件会越写越扭曲。yaml里塞一堆null占位，代码里到处是get("some_key") or "default"，看起来能跑，实际上已经埋了雷。方案二的工厂模式就允许你在“给配置”这一步做逻辑分支，环境差异再大，也在工厂里被消化掉，case层完全感知不到。

3.2 配置工厂与动态合入的实现细节

我把这套实现拆成两个层次。

第一层是基础配置加载。这部分和方案一很像，但返回的raw_config是一个origin数据源，不直接对外暴露。

@pytest.fixture(scope="session") def raw_config(request): env_name = request.config.getoption("--env", default="test") base_conf = _load_yaml_by_env(env_name) override_conf = _load_env_overrides(env_name) merged = {**base_conf, **override_conf} return merged

这里的_load_env_overrides会用环境变量中的同名配置项覆盖yaml里的默认值。日常开发中，某个临时联调环境可能只是改一个host，根本没必要新增一个yaml文件。直接用环境变量指定，用完即焚，干净利落。

def _load_env_overrides(env_name: str) -> dict: prefix = f"AUTOTEST_{env_name.upper()}" overrides = {} for key in ["BASE_URL", "DB_HOST", "DB_PASSWORD"]: env_value = os.environ.get(f"{prefix}_{key}") if env_value: overrides[key.lower()] = env_value return overrides

比如临时想让pre环境的请求指向本机端口，直接在命令行加上：

AUTOTEST_PRE_BASE_URL=http://127.0.0.1:8080 pytest --env=pre

这个功能非常解手，尤其在联调阶段。不用动任何仓库里的文件，就能把某条链路打到本地服务。

第二层是配置工厂。它接收raw_config和使用方传入的定制函数，返回最终的配置对象。

@pytest.fixture(scope="session") def config_factory(raw_config): def _create_config(override_fn=None): if override_fn is None: return raw_config return override_fn(raw_config) return _create_config

用例侧可以这么用：

def test_order_flow(config_factory): cfg = config_factory(lambda base: { **base, "timeout": 30, "retry_count": 2 }) ... }

甚至可以在特定的测试模块的conftest.py里定义一个局部fixture，针对该模块单独注入超时参数、文件路径前缀等。这种二次定制能力，本质上是把环境的横向差异和用例的纵向差异解耦了，复用性比直接返回一个固定字典要强很多。

3.3 适用边界与学习成本权衡

方案二的功能更强，但学习成本也上了一个台阶。你至少需要理解fixture的工厂思想，还要明白闭包的概念。对小组里刚接触pytest的新人来说，看到一个fixture返回一个函数的写法，大概率会愣一下。

我个人的判断标准是这个：如果项目的环境数量稳定在2~3个，且配置结构高度类似，直接上方案二属于过度设计。反过来，如果环境种类多、配置项差异大，或者有大量的联调场景，方案二能帮你省下不少苦力。

提示：不要为了“设计模式”而设计模式。方案二的价值在于它把“环境差异”的复杂度收拢到了工厂内部，如果你的环境本身没有那么多差异，强行引入工厂只会增加认知负担。

4. 两套方案横向对比与选型建议

4.1 关键维度对照

4.2 按项目阶段选型

如果是一个刚起步的自动化项目，团队里大部分人还在熟悉pytest的阶段，我会毫不犹豫推荐方案一。它的每一行代码都很直白，出了问题也好排查。等你跑了一段时间，发现越来越多的临时环境需求，再平滑地往方案二迁移也不难。迁移的时候，底层配置文件不用动，只是把global_config这个fixture的实现从“返回dict”改成“返回工厂函数”，然后改一下调用方的取值方式。

如果是那种一上来就知道要支持很多环境、很多定制场景的大型项目，直接按方案二起步，少走弯路。

4.3 环境命名的约定

不管选哪套方案，环境命名的约定一定要趁早定下来。我建议全部用英文小写和连接符，比如test、pre、staging、prod，不要出现测试环境、Pre环境这种中文和英文混着的写法。命令行里输入--env=测试环境不是不行，但传到CI里，shell编码、日志展示都会有一堆潜在问题。

另外，环境名最好和配置文件名称完全绑定。也就是说，--env=pre就一定对应pre.yaml，--env=pre不能对应prod.yaml。宁可文件复制一份，也不要搞出“别名”机制，否则配置的确定性就打折扣了。

5. 踩坑实录：那些网上的教程没告诉你的细节

5.1 conftest.py作用域导致配置加载了但用例读不到

这是新手最容易踩的坑。conftest.py不是全局只有一个，它是分层的。你如果在根目录的conftest.py里定义了global_config，子目录的用例理论上能拿到这个fixture。但如果你在tests/api/下面又建了一个conftest.py，也定义了一个同名或不同名的fixture，就会发生遮蔽。

踩过一次之后就学乖了：环境配置相关的fixture固定放在根目录的conftest.py，子目录里的conftest.py只放与该目录用例强相关的局部夹具，绝不去动全局配置。这样各司其职，不会出现那种“用例在本地能跑，到了CI就报fixture not found”的诡异问题。

5.2 配置文件读取编码的坑

Windows环境下读取yaml文件，如果不指定encoding="utf-8"，有时会因为系统默认编码是GBK而报UnicodeDecodeError。别问我是怎么知道的，线上流水跑了几天突然出现中文注释乱码的痛，经历过的都懂。所以load_config里面打开文件时，一定显式写上encoding="utf-8"。

5.3 fixture缓存和可变对象共享

方案一里我用了CONFIG_CACHE字典做缓存，但这个缓存是模块级全局变量。pytest在执行时如果开了-p no:cacheprovider插件，或者在xdist模式下多进程执行，每个worker的模块级变量是独立的。所以不要期望在多个worker之间共享这个缓存，它只是一个单进程内的简易缓存，不要给它加太多戏。

5.4 环境参数校验不能只靠人的自觉

命令行参数是字符串，传成--env=pree（多打了一个e）也是合法的字符串。如果你的load_config只是拼路径然后读文件，那么pree.yaml不存在时会抛FileNotFoundError，虽然最终也会报错，但报错信息不友好。最好是显式定义一个白名单：

ENV_WHITELIST = {"test", "pre", "prod"} def validate_env(env_name: str): if env_name not in ENV_WHITELIST: raise ValueError( f"不支持的环境: {env_name}，可选值: {ENV_WHITELIST}" )

在pytest_addoption里注册参数后，马上在pytest_configure里做校验，可以让错误在启动阶段就暴露，而不是等到第一个用配置的用例挂了才反应过来。这个细节对线上CI特别有用，因为CI里的错误日志是异步查看的，越早报错越好定位。

5.5 不要把密钥直接写进yaml并提交到仓库

很多项目为了图方便，把数据库密码、Redis密码、第三方服务的secret直接写进配置文件提交到Git。如果这个仓库是私有且权限管理严格的还好，一旦权限配置稍有疏漏，密钥泄漏就是安全事件。推荐的做法是yaml里只放非敏感配置，敏感项全部通过环境变量注入。环境变量注入这一层，恰好方案二里已经实现了框架，你只需把敏感字段的读取统一从os.environ里获取即可。

6. 配合CI流水线的实操扩展

前面两套方案在命令行里手动跑都没问题，但自动化测试最有价值的地方在于接入CI，让每次提交、每次定时构建都能自动跑对应环境的回归。

比如在CI脚本里，根据当前分支决定用什么环境：

if [ "$CI_COMMIT_BRANCH" == "develop" ]; then ENV=test elif [ "$CI_COMMIT_BRANCH" == "release" ]; then ENV=pre fi pytest -v --env=$ENV --alluredir=./allure-results

注意这里有一个坑：CI_COMMIT_BRANCH的具体变量名取决于你用的是什么CI平台，不能照抄。有的平台是BRANCH_NAME，有的是GIT_BRANCH，还有的是TRAVIS_BRANCH。要先去查对应平台的文档，确认准确的环境变量名，不然分支判断永远不生效，CI里跑的环境永远是默认环境。

另外，如果你同时跑了多个环境的用例，但又不想每次都等全量回归，可以结合-k参数做用例筛选。比如只跑和订单相关的用例：

pytest -v --env=pre -k "order"

把环境切换和用例筛选结合起来，一套用例就能组合出非常多的回归矩阵。这是我在那个跨平台结算系统项目里的实际用法。发布前跑pre全量，每次提交跑test环境的smoke，成本低、反馈快。

7. 最后说两句实在话

这两套方案我后来在好几个项目里都复用过，稳定性是经过验证的。方案一够简单，方案二够灵活，它们之间没有绝对的优劣，只有合不合适。如果你问我个人偏好，我会说大多数时候方案一就够了，方案二更像是一个“当你真的需要它时再去学”的后手。

如果你正准备搭一套新的自动化测试项目，我的建议是把环境切换这个能力放在第一批基建里做掉，不要等用例写了几百条之后再去补。越早定义好--env这个入口，后面每一条用例的写法就越一致。等到用例量上来了再改，改动成本就不是改一个conftest.py那么简单了，你可能要翻遍所有用例去改配置取用方式。

最后分享一个小的实操心得：无论用哪套方案，都建议在用例执行前加一个简单的配置自检用例，专门打印当前环境名、base_url、数据库host这几个关键字段。这个用例的作用不是测业务逻辑，而是让任何人拿到日志，第一眼就能确认“哦，这次跑的是pre环境，配置没错”。这个习惯我在好几个项目里救了命——有一次CI上挂了，排查半天发现根本不是代码问题，是流水线把环境变量传错了，导致所有用例跑到了test环境，白白浪费了半天时间。配置自检用例虽然只有十来行，但带来的确定性是无价的。