Pytest+Playwright自动化测试：pytest.ini配置详解与最佳实践

1. 项目概述

最近在团队里搞UI自动化，发现很多同事虽然会用Playwright写脚本，但项目一复杂，测试用例一多，运行和管理就变得特别头疼。比如，有人习惯用pytest -v看详细输出，有人需要生成Allure报告，还有人希望测试失败时自动截图。如果每个人都带着一堆命令行参数跑测试，不仅容易出错，协作起来也麻烦。这时候，一个配置得当的pytest.ini文件就成了项目的“定海神针”。它能把所有分散的、临时的命令行配置，固化成一个团队共享的、版本可控的“自动化运行规范”。今天我就结合一个真实的Pytest+Playwright项目，从头到尾拆解pytest.ini该怎么配，为什么这么配，以及那些官方文档里不会写的“踩坑”经验。

简单说，pytest.ini是Pytest框架的配置文件，它允许你预先定义测试运行的默认行为。对于UI自动化项目，它的价值在于：统一测试环境、固化最佳实践、提升协作效率。无论你是刚接触Playwright的新手，还是正在为团队搭建自动化框架的负责人，理解并善用这个配置文件，都能让你的自动化工程更加稳健和高效。

2. 核心需求与pytest.ini的价值解析

2.1 为什么UI自动化项目必须重视pytest.ini？

你可能觉得，命令行参数也能达到类似效果，为什么非要一个配置文件？我举个例子你就明白了。假设团队有5个人，A习惯用pytest -x（遇到失败就停止），B需要--headed模式调试，C要生成allure-results，D则要求--tb=short简化错误回溯。如果没有pytest.ini，每个人要么记一长串命令，要么写个复杂的shell脚本。更糟糕的是，一旦要集成到CI/CD流水线（比如GitHub Actions），你还需要在YAML文件里重新定义这些参数，很容易出现本地和线上环境不一致的问题。

而pytest.ini解决了三个核心痛点：

1. 一致性：确保所有开发者和CI服务器使用完全相同的pytest配置，消除“在我机器上是好的”这类问题。
2. 可维护性：配置集中管理，修改一处，全局生效。比如要统一增加一个--strict-markers（严格标记检查）的规范，只需要更新pytest.ini并通知大家拉取即可。
3. 降低使用门槛：新成员加入项目，不需要询问或记忆复杂的命令行，直接运行pytest就能以团队标准模式执行测试。

在Playwright UI自动化场景下，pytest.ini的配置往往围绕几个关键目标展开：测试发现、执行控制、报告生成、与Playwright的深度集成。接下来，我们就逐一拆解。

2.2 一个典型的Playwright项目对pytest.ini的期望

结合我手头的项目和常见需求，一份理想的配置应该能帮我们做到：

• 智能的测试发现：只跑我们关心的测试用例，比如按模块、按标记（mark）。
• 稳定的执行环境：为Playwright配置好浏览器类型、是否无头运行、超时时间、视口大小等。
• 丰富的输出与报告：在控制台看到清晰的结构和日志，同时能生成用于持续集成的Allure或HTML报告。
• 高效的失败排查：测试失败时，能自动捕获截图、录屏或Trace，而不是让人对着抽象的错误信息干瞪眼。
• 灵活的并行执行：当用例数量上百时，利用多进程或分布式缩短反馈时间。

pytest.ini就是实现这些期望的基石。它本身是一个标准的INI格式文件，通常放在项目根目录。Pytest运行时会自动发现并加载它。

3. pytest.ini 基础结构与全局配置详解

3.1 文件结构与基本语法

让我们先从一个最简化的pytest.ini开始看起：

[pytest] # 这是一个注释。所有配置项都在 [pytest] 这个section下 addopts = -v -s testpaths = testcases python_files = test_*.py *_test.py python_classes = Test* python_functions = test_*

• [pytest]: 这是必须的节（section）头，所有pytest相关的配置都写在这里面。
• addopts: 这是最重要的选项之一，代表“add options”。它的值是一系列命令行参数，就像你手动在终端输入的一样。这里设置了-v（输出详细信息）和-s（允许控制台输出，比如print语句）。
• testpaths: 告诉pytest去哪里寻找测试文件。这里设置为testcases目录，pytest就会递归地在这个目录下搜索。
• python_files/python_classes/python_functions: 这三个定义了pytest的测试发现规则。默认情况下，pytest会查找以test_开头或_test结尾的文件、以Test开头的类、以及以test_开头的函数或方法。通常我们保持默认即可，除非有特殊的命名规范。

注意：addopts中的选项优先级低于命令行直接输入的参数。比如你在pytest.ini中设置了addopts = -v，但在命令行运行pytest -q，那么最终会以安静模式(-q)运行，因为命令行参数覆盖了配置文件。

3.2 常用全局配置项实战

在实际的Playwright项目中，我们会根据需求丰富这个配置文件。以下是一些高频且实用的配置项：

[pytest] # 1. 默认命令行参数 addopts = -v # 详细输出 --tb=short # 错误回溯信息格式为简短模式。`auto`/`long`/`short`/`line`/`no`。short模式在UI自动化中很实用，信息足够且不冗长。 --strict-markers # 严格检查marks，如果使用了未注册的mark，pytest会报错，防止标记名拼写错误。 --disable-warnings # 禁用警告输出，让控制台更干净。也可以使用 `-p no:warnings`。 --show-capture=no # 不自动显示测试中被捕获的日志输出（可通过allure报告查看），避免控制台刷屏。 # 2. 测试发现路径 testpaths = testcases # 如果你有多个测试目录 # testpaths = testcases api_tests e2e_tests # 3. 测试文件/类/函数匹配模式 (通常保持默认) python_files = test_*.py *_test.py python_classes = Test* python_functions = test_* # 4. 自定义标记 (marks) 注册 # 这是团队协作的关键！提前定义好所有可用的标记及其描述。 markers = smoke: 冒烟测试用例 regression: 回归测试用例 login: 与登录功能相关的测试 order: 与订单流程相关的测试 slow: 运行缓慢的测试，可选择性地跳过 skip: 跳过此测试用例 parametrize: 参数化测试（虽然pytest内置，但显式声明是个好习惯） # 5. 日志配置（与Python logging模块集成） log_cli = true # 在控制台启用日志输出 log_cli_level = INFO # 控制台日志级别 log_cli_format = %(asctime)s [%(levelname)s] %(name)s: %(message)s log_cli_date_format = %Y-%m-%d %H:%M:%S log_file = logs/pytest_run.log # 同时将日志写入文件 log_file_level = DEBUG # 文件日志级别可以更详细 log_file_format = %(asctime)s [%(levelname)s] %(name)s [%(filename)s:%(lineno)d]: %(message)s # 6. 控制测试执行顺序 (谨慎使用) # pytest默认按文件、类、函数名排序。可以安装pytest-order插件来控制。 # addopts里可以加 --order-scope=class --order-dependencies

配置心得：

• --tb=short：在UI自动化中强烈推荐。因为Playwright的错误信息通常很详细，long模式会打印出完整的调用栈和页面上下文，在控制台看起来非常冗长。short模式只给出错误本质和关键位置，结合Allure报告查看详细Trace更高效。
• 严格标记（Strict Markers）：一定要加--strict-markers。它强制要求所有在测试用例上使用的@pytest.mark.xxx都必须先在pytest.ini里注册。这能有效避免因为标记名拼写错误（例如@pytest.mark.regresion）而导致测试被意外忽略的坑。
• 日志分离：建议将控制台日志(log_cli)级别设为INFO或WARNING，保持简洁；而文件日志(log_file)级别设为DEBUG，用于事后详细排查。日志格式里加上filename和lineno对定位问题非常有帮助。

4. 与Playwright的深度集成配置

这才是pytest.ini在UI自动化项目中的精髓所在。我们需要通过配置，让pytest在启动时就知道如何初始化Playwright，并传递我们想要的浏览器参数。

4.1 通过addopts传递Playwright命令行参数

最直接的方式是将Playwright的pytest插件参数放在addopts里。Playwright for Pytest提供了很多专用命令行选项。

[pytest] addopts = -v --tb=short --strict-markers # Playwright 专用参数 --browser chromium # 指定浏览器：chromium, firefox, webkit。可指定多个，如 `--browser chromium --browser firefox` --headed # 有头模式运行，用于调试。在CI环境中通常会去掉此项。 --slowmo 100 # 每个操作延迟100毫秒，方便观察测试过程。 --viewport-size 1920,1080 # 设置浏览器视口大小 --device “iPhone 12” # 模拟移动设备（需要Playwright知道此设备） --base-url https://www.example.com # 设置基础URL，在fixture或page对象中可以通过 `request.config.getoption(“--base-url”)` 获取 --tracing on # 开启Trace录制（非常有用！），可选 `on`, `off`, `retain-on-failure`（仅在失败时保留） --video on # 开启视频录制，可选 `on`, `off`, `retain-on-failure` --screenshot on # 开启截图，可选 `on`, `off`, `only-on-failure`

参数解析与避坑：

• --browser：默认是chromium。如果你需要跨浏览器测试，可以列出多个。但要注意，这会导致每个测试用例在所有指定浏览器上各运行一次，总测试时间会倍增。通常建议在CI的不同任务中分别指定浏览器，而不是在一个命令中运行所有。
• --headedvs 无头模式：调试时务必用--headed，你能看到浏览器实际的操作。但在CI（如GitHub Actions）或服务器上运行时，一定要去掉--headed，因为无头模式不需要图形界面，资源消耗小，速度更快。可以在pytest.ini中注释掉它，通过环境变量或不同的ini文件来区分环境。
• --tracing和--video：这是Playwright最强的调试功能之一。retain-on-failure策略是最佳实践，它只保存失败用例的Trace和视频，节省磁盘空间。Trace文件可以用Playwright CLI命令playwright show-trace trace.zip打开，以可视化时间线的方式复盘测试每一步，包括网络请求、DOM快照、控制台日志等，排查问题效率极高。
• --base-url：这是一个非常有用的配置。在你的Page Object或测试用例中，你可以通过pytest的requestfixture 来获取这个值，从而避免在代码中硬编码URL。例如，你可以轻松地在测试、预生产和生产环境之间切换，只需修改pytest.ini或通过命令行覆盖。

4.2 使用pytest插件与自定义选项

除了通过addopts传递，更灵活的方式是利用pytest的插件系统和自定义配置。我们可以在项目根目录的conftest.py文件中编写fixture来读取这些配置。

首先，在pytest.ini中定义一些自定义变量（虽然不常见，但可行），或者更常见的是，我们利用addopts传递的参数，在fixture中消费。

例如，我们想根据配置决定是否启用“慢动作”模式，可以在conftest.py中这样写：

# conftest.py import pytest from playwright.sync_api import Page @pytest.fixture(scope="session") def browser_context_args(browser_context_args, playwright, request): """自定义浏览器上下文参数，整合pytest.ini中的配置""" # 从pytest配置中获取参数 slowmo = request.config.getoption("--slowmo") viewport_size = request.config.getoption("--viewport-size") device = request.config.getoption("--device") # 准备传递给 browser.new_context() 的参数 context_args = {**browser_context_args} # 继承默认参数 if slowmo and slowmo.isdigit(): context_args["slow_mo"] = int(slowmo) if viewport_size: width, height = viewport_size.split(',') context_args["viewport"] = {"width": int(width), "height": int(height)} if device: # 注意：这里需要playwright.devices，通常我们在另一个fixture中处理device更合适 # 此处仅为示例逻辑 try: context_args.update(playwright.devices[device]) except KeyError: print(f"Warning: Device '{device}' not found. Using default viewport.") return context_args @pytest.fixture def base_url(request): """提供一个base_url fixture，供page对象使用""" return request.config.getoption("--base-url")

然后，在你的Page Object里，就可以使用这个base_urlfixture了：

# pages/login_page.py class LoginPage: def __init__(self, page: Page, base_url: str): self.page = page self.base_url = base_url def navigate(self): # 使用配置中的base_url，而不是硬编码 self.page.goto(f"{self.base_url}/login") # ... 其他操作

这样做的好处：将环境配置（URL、浏览器参数）与测试逻辑完全分离。切换测试环境时，只需修改pytest.ini或使用不同的命令行参数，无需改动任何一行测试代码。

5. 高级配置：报告、并行与多环境

5.1 集成Allure报告生成

Allure是当下最流行的测试报告框架之一，与pytest集成非常方便。除了安装allure-pytest包，我们可以在pytest.ini中配置Allure相关的元数据，使报告更美观、信息更丰富。

[pytest] addopts = -v --tb=short --strict-markers --alluredir=allure-results # 指定Allure原始结果输出目录 # Allure报告相关的环境变量（也可以通过命令行传递） env = ALLURE_NOOPENER=false ALLURE_OUTPUT_DIR=allure-results # 可选：配置Allure的categories.json路径（用于定义测试失败的分类） # allure_categories_path = categories.json # 可选：配置Allure的environment.properties路径（用于记录测试环境信息） # allure_environment_path = environment.properties

运行测试后，使用allure serve allure-results在本地查看报告，或使用allure generate allure-results -o allure-report --clean生成静态报告。

一个关键技巧：在conftest.py中，你可以动态生成environment.properties文件，自动捕获测试运行时的环境信息（如Python版本、Playwright版本、浏览器版本、基础URL等），让报告更具可追溯性。

# conftest.py (部分代码) import allure import pytest import sys from playwright._repo_version import version as playwright_version @pytest.hookimpl(tryfirst=True) def pytest_sessionstart(session): """在测试会话开始时，记录环境信息到Allure""" env_info = { "Python.Version": sys.version, "Playwright.Version": playwright_version, "Runner.OS": sys.platform, # 可以从pytest config中获取更多 "Pytest.BaseURL": session.config.getoption("--base-url", default="Not Set"), "Pytest.Browser": session.config.getoption("--browser", default="chromium"), } # 写入环境属性文件 allure_dir = session.config.getoption("--alluredir") if allure_dir: import os env_file = os.path.join(allure_dir, "environment.properties") os.makedirs(allure_dir, exist_ok=True) with open(env_file, 'w') as f: for key, value in env_info.items(): f.write(f"{key}={value}\n")

5.2 配置并行测试（pytest-xdist）

当测试用例数量庞大时，并行执行是缩短测试周期的利器。pytest-xdist插件可以实现这一点。配置很简单：

[pytest] addopts = -v --tb=short -n auto # 使用auto模式，自动检测CPU核心数并创建相应数量的worker进程 # 或者指定固定数量 # -n 4 # 对于UI自动化，有时需要每个worker有独立的状态，避免cookie/session冲突 # 可以配合 `--dist=loadscope` 尝试将同一个模块或类的测试分到同一个worker # addopts = -n auto --dist=loadscope

并行测试的注意事项：

1. 资源竞争：UI测试涉及浏览器实例，并行运行会消耗大量内存和CPU。-n auto不一定是最优的，需要根据机器性能调整。在CI中，可能-n 2或-n 3更稳定。
2. 测试独立性：这是并行测试的前提。确保每个测试用例不依赖其他测试产生的数据或状态。使用setup_method/teardown_method或@pytest.fixture为每个测试提供干净的环境。
3. 共享资源：如果测试需要访问同一个数据库或外部服务，注意做好数据隔离，例如使用随机生成的用户名或订单号。
4. Playwright Context Isolation：确保每个pytest worker使用独立的Playwright browser context，这是pytest-playwright插件默认会处理的，但如果你自己管理browser实例，需要格外小心。

5.3 多环境配置策略

项目通常有开发、测试、预生产、生产等多个环境。我们不可能为每个环境维护一个pytest.ini。最佳实践是：使用一个基准的pytest.ini，然后通过环境变量或额外的pytest命令行参数来覆盖特定配置。

策略一：环境变量 + pytest.ini默认值在pytest.ini中设置一个默认的base-url，但允许被环境变量覆盖。

[pytest] addopts = -v --tb=short --base-url = https://default.test.env

然后，在运行测试前设置环境变量：

# Linux/macOS export PYTEST_BASE_URL=https://staging.env pytest # Windows (cmd) set PYTEST_BASE_URL=https://staging.env pytest # 在conftest.py中读取环境变量，优先级高于pytest.ini import os @pytest.fixture(scope="session") def base_url(request): env_url = os.getenv("PYTEST_BASE_URL") config_url = request.config.getoption("--base-url") return env_url if env_url else config_url

策略二：使用pytest的-c参数指定不同配置文件你可以创建多个配置文件，如pytest.staging.ini,pytest.prod.ini。

# pytest.staging.ini [pytest] addopts = -v --tb=short --base-url=https://staging.env --headed # pytest.prod.ini (通常禁用headed和video以提升性能) [pytest] addopts = -v --tb=short --base-url=https://prod.env --tracing retain-on-failure

运行命令：

pytest -c pytest.staging.ini pytest -c pytest.prod.ini

策略三：在CI/CD中动态生成配置在GitHub Actions或Jenkins等CI工具中，你可以在任务步骤里，根据触发分支或手动选择的环境，动态地组装pytest命令。

# GitHub Actions 示例片段 jobs: test: runs-on: ubuntu-latest strategy: matrix: browser: [chromium, firefox] steps: - uses: actions/checkout@v3 - uses: actions/setup-python@v4 - run: pip install -r requirements.txt - run: playwright install ${{ matrix.browser }} - run: | # 根据分支决定环境 if [[ ${{ github.ref }} == 'refs/heads/main' ]]; then BASE_URL="https://prod.example.com" PYTEST_OPTS="--tracing retain-on-failure" else BASE_URL="https://staging.example.com" PYTEST_OPTS="--headed --video on" fi pytest $PYTEST_OPTS --base-url=$BASE_URL --browser=${{ matrix.browser }}

6. 完整配置示例与逐行解析

下面是一个融合了上述所有要点的、面向中型UI自动化项目的pytest.ini完整示例，我会加上详细注释。

[pytest] # ==================== 核心执行配置 ==================== # addopts: 定义默认命令行参数集合。这是配置的“心脏”。 addopts = # 基础输出控制 -v # 详细信息，显示每个测试用例的名字和状态 --tb=short # 使用简短格式的traceback，便于快速定位错误行 --strict-markers # 强制检查，使用的所有@pytest.mark必须在此注册，避免笔误 --disable-warnings # 不显示警告信息，保持控制台整洁 --show-capture=no # 不自动打印被捕获的日志/标准输出，通过报告查看更清晰 # Playwright 专用配置 --browser chromium # 默认使用Chromium浏览器。可改为 `--browser chromium --browser firefox` 进行多浏览器测试 --headed # 【调试时启用】有界面模式运行。CI环境请注释掉此行。 --slowmo 50 # 每个操作延迟50毫秒，方便人工观察测试步骤，调试神器 --viewport-size 1920,1080 # 设置浏览器窗口大小为1080p --base-url https://demo.playwright.dev # 基础URL，所有page对象的相对路径都基于此 --tracing retain-on-failure # 仅当测试失败时保存Trace文件，平衡调试需求和存储空间 --screenshot only-on-failure # 仅当测试失败时截图 --video retain-on-failure # 仅当测试失败时保存录制视频 # 报告与结果输出 --alluredir=./allure-results # 指定Allure原始数据输出目录 --clean-alluredir # 运行前清空上一次的Allure结果（避免累积） # 并行执行 (根据机器性能酌情启用，调试时建议关闭) # -n auto # 自动根据CPU核心数启动worker进程 # --dist=loadscope # 尝试将同一个模块或类的测试分发到同一个worker，减少状态冲突 # ==================== 测试发现规则 ==================== # 告诉pytest去哪里找测试文件 testpaths = testcases # 主测试用例目录 # integration_tests # 可以有多个目录 # 定义什么样的文件、类、函数被认为是测试 python_files = test_*.py *_test.py # 匹配 test_login.py 或 login_test.py python_classes = Test* # 匹配 TestLoginPage 这样的类 python_functions = test_* # 匹配 test_valid_login 这样的函数 # ==================== 自定义标记注册 ==================== # 团队规范：所有可用标记必须在此声明并附简短描述 markers = smoke: 核心业务流程冒烟测试，必须快速通过 regression: 全功能回归测试套件 login: 与用户登录/登出相关的测试 cart: 与购物车功能相关的测试 checkout: 与结算支付流程相关的测试 api: 包含API调用的混合测试 ui: 纯前端UI交互测试 slow: 执行时间较长的测试，在快速验证时可跳过 skip(reason): 跳过此测试用例，需注明原因 flaky: 不稳定的测试，需要重点关注和修复 # ==================== 日志系统配置 ==================== # 控制台日志配置 log_cli = true log_cli_level = INFO log_cli_format = %(asctime)s [%(levelname)-8s] %(name)-20s: %(message)s log_cli_date_format = %H:%M:%S # 文件日志配置 (更详细，用于归档和深度排查) log_file = ./logs/pytest_execution.log log_file_level = DEBUG log_file_format = %(asctime)s [%(levelname)-8s] %(name)-20s [%(filename)15s:%(lineno)3d] - %(message)s log_file_date_format = %Y-%m-%d %H:%M:%S # ==================== 其他杂项配置 ==================== # 设置缓存目录，加速后续测试运行（特别是使用了@pytest.mark.parametrize时） cache_dir = .pytest_cache # 设置JUnit XML报告输出（部分CI平台需要此格式） junit_suite_name = Playwright UI Test Suite junit_logging = all # junit_duration_report = call # 报告每个测试步骤的耗时

7. 常见问题、排查技巧与实操心得

即使配置写得再完美，实际运行中还是会遇到各种问题。下面是我总结的一些高频问题和解决思路。

7.1 配置不生效？检查配置加载顺序与优先级

问题：明明在pytest.ini里设置了addopts = --tb=short，但运行pytest时错误回溯还是长长的--tb=long格式。

排查：

1. 确认文件位置与名称：pytest.ini必须放在项目根目录（即运行pytest命令的目录）。文件名必须是pytest.ini，而不是pytest.conf或pytest.cfg。
2. 检查命令行覆盖：记住，命令行参数的优先级高于pytest.ini中的addopts。如果你运行了pytest --tb=long，那么命令行参数会覆盖配置文件。检查你的终端历史或CI脚本。
3. 检查多个配置文件：Pytest会从当前目录向上搜索，使用找到的第一个pytest.ini。确保你没有在子目录中意外放置了另一个pytest.ini。
4. 使用pytest --help查看生效配置：运行pytest --help，在输出的最上方，会显示config file:路径，这就是Pytest实际加载的配置文件。确认它是不是你修改的那个。

7.2 并行测试（pytest-xdist）下的资源与状态冲突

问题：使用-n auto并行运行时，测试间歇性失败，错误提示可能是元素找不到、页面状态不对，或者数据库数据冲突。

解决思路：

1. 确保测试完全独立：这是根本。每个测试都应该能独立运行，不依赖其他测试留下的cookie、localStorage、数据库记录等。在conftest.py中，为每个测试提供干净的browser context和pagefixture（pytest-playwright默认已做好）。
2. 使用--dist=loadscope：这个参数会尽量将同一个测试文件（module）或同一个测试类（class）中的测试分发到同一个worker执行。对于共享同一个Page对象或测试类的用例，这可以减少状态初始化开销和冲突。
3. 隔离测试数据：使用随机数或UUID生成唯一的用户名、邮箱、订单号。例如，在fixture中生成测试数据。

   import uuid @pytest.fixture def unique_username(): return f"user_{uuid.uuid4().hex[:8]}"

4. 控制并行度：不要盲目使用auto。在CI机器上，可能内存不足。可以从-n 2开始，逐步增加，观察稳定性和执行时间。pytest -n 2 --dist=loadscope是一个不错的起点。
5. 为Playwright配置单独的浏览器缓存目录：如果测试需要下载文件或缓存，为每个worker指定独立的user_data_dir可以避免冲突。

   # conftest.py @pytest.fixture(scope="function") def context(browser, worker_id, tmp_path_factory): # worker_id 在并行时是唯一的，如 'gw0', 'gw1' user_data_dir = tmp_path_factory.mktemp(f"playwright_cache_{worker_id}") context = browser.new_context(user_data_dir=str(user_data_dir)) yield context context.close()

7.3 Allure报告没有数据或显示不全

问题：运行后allure-results文件夹是空的，或者报告里缺少步骤详情、截图。

排查步骤：

1. 检查--alluredir参数：确保pytest.ini中的addopts包含了--alluredir=./allure-results，并且路径正确。运行后检查该目录下是否有.json结果文件。
2. 检查Allure装饰器：确保在测试用例和fixture中正确使用了@allure.title,@allure.step,@allure.attach等装饰器来丰富报告内容。Playwright的截图可以很方便地附加到报告：

   import allure from playwright.sync_api import Page def test_example(page: Page): # ... 一些操作 page.screenshot(path="screenshot.png") allure.attach.file("screenshot.png", name="失败截图", attachment_type=allure.attachment_type.PNG) # 或者直接attach内存中的bytes # allure.attach(page.screenshot(), name="截图", attachment_type=allure.attachment_type.PNG)

3. 清理历史结果：在运行前，可以添加--clean-alluredir参数（如上例），或手动删除allure-results文件夹，避免旧数据干扰。
4. 查看pytest执行日志：运行pytest时，如果Allure插件初始化失败，通常会有错误信息输出到控制台。注意查看开头部分的日志。

7.4 如何管理不同环境的配置（开发、CI）

这是我推荐的一种项目结构：

your_project/ ├── pytest.ini # 基础配置，包含开发调试时的默认值（如--headed） ├── pytest.ci.ini.example # CI配置模板，不含--headed，启用并行和失败保留 ├── conftest.py ├── requirements.txt ├── testcases/ └── ...

本地开发：直接使用根目录的pytest.ini，默认有头模式，方便调试。CI环境：在CI脚本中，复制或重命名pytest.ci.ini.example为pytest.ci.ini，然后使用pytest -c pytest.ci.ini运行。也可以在CI中直接通过环境变量覆盖关键参数：

# 在GitHub Actions的step中 - run: | # 覆盖pytest.ini中的headed和slowmo配置 pytest --no-headed --slowmo 0 --tracing retain-on-failure

终极心法：将pytest.ini视为本地开发和团队共享的基准配置，而将CI/CD脚本或环境变量视为针对特定环境的调优和覆盖。这样既保证了团队内配置的统一，又保留了环境的灵活性。

最后，别忘了将pytest.ini提交到版本控制系统（如Git）。它是项目构建和测试规范的重要组成部分，和requirements.txt、Dockerfile一样重要。每次对配置的修改，都应该经过团队评审，因为它的变动会影响每个人的本地测试行为和整个CI流程的稳定性。