如果你刚接触自动化测试大概率会在unittest和pytest之间反复纠结。我当年也一样用unittest写了小半年用例后来一脚踩进pytest就再也没回去。pytest是Python社区目前事实上的自动化测试框架标准它不只能写单元测试接口自动化、Web UI自动化、移动端自动化都能用同一套机制统一驱动。这篇文章不打算把pytest文档抄一遍而是把我在实际项目中怎么用它搭框架、怎么写用例、怎么埋坑、怎么出报告的经验讲清楚。适合正在选型的新手也适合已经写了不少用例但总觉得维护成本高的人读完你至少能回答自己一个问题为什么自动化测试框架最后大概率会落在pytest身上。1. 为什么自动化测试我最终选了pytest1.1 和unittest对比pytest赢在哪里用unittest写自动化测试有一种“被框架推着走”的感觉每个类必须继承TestCase每个方法必须叫test_开头断言必须用assertEqual、assertTrue这一整套API。这套东西不是不能用但写多了你会发现它在表达测试意图这件事上很啰嗦。pytest最大的变化是“去类化”。它可以让你用一个普通函数就能表达一条测试用例断言直接用Python原生的assert关键字。比如下面这是完整的pytest用例# test_demo.py def test_add(): result 1 1 assert result 2不需要继承不需要额外对象Python解释器看到test_前缀的函数就自动收集为用例。这种极简设计带来的好处是学习和迁移成本极低你只要会写Python函数就会写pytest用例。再往深看pytest的收集规则比unittest灵活得多。默认匹配test_*.py或*_test.py文件文件里匹配Test*类和test_*函数。这些规则全部可以在pytest.ini里改也就意味着你可以根据项目代码风格去适配框架而不是反过来。项目大了以后这种“框架适配项目”的能力非常值钱。1.2 pytest的设计哲学断言、夹具、插件各司其职pytest并不靠堆功能取胜它把核心能力拆成了三块断言、fixture和插件机制。断言负责“结果对不对”fixture负责“测试前后环境怎么准备和清理”插件负责“围绕测试生命周期做扩展”。三者组合起来就形成了一个既能写简单用例又能支撑大型测试平台的自动化测试框架。fixture是我认为pytest最值得研究的设计。它把传统测试里的setUp和tearDown抽象成了可声明、可组合、可复用的依赖。以前在unittest里每个类都要写一遍setUp遇到不同前置条件还得写多个类在pytest里你只需要定义一次fixture然后让用例声明“我需要它”中间的逻辑就自动完成了。插件机制则是pytest能成为“平台底座”的关键。官方插件有几百个常见的有pytest-xdist做并行执行pytest-rerunfailures做失败重跑pytest-assume做多重断言pytest-ordering控制执行顺序pytest-timeout限制用例超时。这些能力不需要你从零实现接上就能用真正做到了“测试框架”应该有的生态。1.3 自动化测试平台应该有的能力pytest怎么接有人问“一个自动化测试平台应该具有的能力”是什么我自己的理解是用例管理、环境管理、数据管理、执行调度、报告展示、失败分析、质量门禁。这几件事都不是pytest必须亲自做的但pytest提供了让它们落地的接口。用例管理靠pytest的收集和标记比如用pytest.mark.smoke标记冒烟用例用pytest.mark.api区分接口用例执行时通过-m smoke and api筛选。环境管理靠fixture和配置文件不同环境用不同base_url和账号数据fixture按环境参数返回不同配置。数据管理靠参数化把一套测试逻辑套在几十组数据上跑。执行调度靠pytest-xdist和CI平台的定时任务。报告展示靠Allure或pytest-html。失败分析靠Allure的步骤截图和日志。质量门禁靠pytest的退出码和覆盖率阈值。所以说pytest从来不是一个只能“跑函数”的小工具它是一台把测试逻辑和执行设施连接起来的中间层。你在上面跑多少用例、接多少能力上限取决于你对它的理解深度。2. pytest核心细节解析与实操要点2.1 fixture把setup和teardown做成了依赖注入fixture是pytest里最核心、也最容易被误用的功能。它可以是一个简单的返回值也可以带着清理逻辑。最常用的写法是yield式fixtureimport pytest import requests pytest.fixture(scopefunction) def user_token(): login_resp requests.post(https://api.example.com/login, json{ username: admin, password: 123456, }) assert login_resp.status_code 200 token login_resp.json()[token] yield token # 这里做清理 requests.post(https://api.example.com/logout, headers{Authorization: fBearer {token}})用例需要token时直接把user_token作为参数传进去def test_get_user_info(user_token): resp requests.get( https://api.example.com/user, headers{Authorization: fBearer {user_token}} ) assert resp.status_code 200yield之前是setupyield之后是teardown。这个设计比unittest里的setUp/tearDown直观得多因为它把“这个用例需要什么”和“用例跑完要清理什么”绑定在了一起。scope参数是fixture的灵魂。function表示每个用例都重新执行适合登录token这种要隔离的场景class表示一个测试类共享module表示一个文件共享session表示整个测试会话只执行一次适合浏览器驱动、数据库连接这类重资源。我踩过最典型的坑是为了省时间把登录token设成session级别结果第二个用例修改了密码导致后续用例全部失败。这类问题不是pytest的问题是scope用法没想清楚。2.2 参数化一条用例跑出一堆数据组合接口自动化测试里最常干的事是用同一套校验逻辑跑多组入参。pytest的pytest.mark.parametrize把这件事压缩成了几行代码import pytest import requests pytest.mark.parametrize(username,password,expected_status, [ (admin, 123456, 200), (admin, wrong, 401), (, 123456, 400), (admin, , 400), ]) def test_login(username, password, expected_status): resp requests.post(https://api.example.com/login, json{ username: username, password: password, }) assert resp.status_code expected_status这条test_login会展开成4条独立用例每一条都显示参数组合作为用例名。好处是测试报告里能看到“登录接口传入空密码时返回400”这种可读性很高的问题而不是笼统的一句“登录接口失败”。坏处是如果参数很多报告会爆炸式增长所以建议参数化只用来覆盖边界值和关键分支不要把所有随机数据都堆进来。参数化还能和fixture组合比如先用fixture拿token再参数化不同的商品id去查详情。组合时参数名和fixture名如果一样就会出现“fixture覆盖”的坑我建议参数名尽量和fixture名区分开不要图省事同名。2.3 断言不只是assert异常校验也要到位很多从unittest过来的人会问pytest只有assert够用吗我的回答是原生assert反而更接近自然语言。你要判断“响应码是200”写assert resp.status_code 200比self.assertEqual(resp.status_code, 200)读起来顺畅得多。但自动化测试里还有一种常见场景测试接口或函数“按预期抛异常”。这时候要用pytest.raisesimport pytest def divide(a, b): return a / b def test_divide_by_zero(): with pytest.raises(ZeroDivisionError): divide(1, 0)pytest.raises还能顺便检查异常信息比如断言错误信息里包含某个关键词def test_divide_message(): with pytest.raises(ZeroDivisionError, matchdivision by zero): divide(1, 0)如果用例里有多步操作每一步都可能失败普通assert会在第一步失败后直接停止。想收集所有断言结果可以用pytest-assume插件import pytest def test_multiple_checks(): with pytest.assume: assert 1 2 with pytest.assume: assert 2 2注意assume会把所有断言跑完再统一报错适合校验一个接口返回体中的多个字段。但不要滥用因为有些断言失败后系统状态已经不对继续执行只会浪费时间和制造噪音。2.4 钩子函数在测试生命周期里加私货pytest的钩子函数是它和unittest拉开差距的另一个地方。你可以通过在conftest.py里定义特定名字的函数干预测试的收集、执行、报告全过程。比如我想在每条用例执行前打印自定义日志# conftest.py import pytest pytest.hookimpl(tryfirstTrue) def pytest_runtest_setup(item): print(f\n开始执行用例: {item.name})又比如想控制用例执行顺序给某条用例加优先级标记import pytest pytest.mark.third def test_three(): pass配合pytest-ordering插件通过装饰器指定顺序pytest.mark.run(order1) def test_login(): pass当然用例依赖和顺序本身是坏味道但某些场景下确实绕不开比如清空购物车用例必须等加入购物车用例先跑。这里我建议尽量把这类顺序逻辑放进fixture里而不是依赖用例执行顺序因为一旦用例并发跑顺序依赖就会立刻崩掉。3. 从零搭建一个可落地的pytest自动化测试项目3.1 环境准备与项目目录结构搭建pytest项目不需要太复杂一个干净的虚拟环境加一个清晰目录就够了。我通常用如下结构project/ ├── pytest.ini ├── requirements.txt ├── tests/ │ ├── __init__.py │ ├── conftest.py │ ├── test_api/ │ │ ├── test_user.py │ │ ├── test_order.py │ │ └── test_cart.py │ └── test_ui/ │ └── test_login.py ├── core/ │ ├── __init__.py │ ├── api_client.py │ └── assertions.py └── data/ └── test_data.jsoncore里放业务封装tests里放用例data里放数据文件。不要在用例文件里直接写请求地址和账号密码这些必须统一收口到环境配置。安装依赖时建议一次性把常用插件装好pip install pytest pytest-xdist pytest-rerunfailures pytest-assume pytest-ordering pytest-timeout allure-pytest requests我见过很多项目直接在系统全局环境里装包时间一长就乱套。虚拟环境是底线别省这一步。3.2 第一个能跑的pytest用例新建tests/test_demo.py写入最简单的用例def test_demo(): assert 1 1 2切换进项目目录后运行pytest -v终端会显示一条PASSED。看到这个结果基础链路就算通了。从这里开始你可以逐步加入接口请求、页面操作、数据库校验。在写真正用例之前建议先配置pytest.ini把收集规则和常用参数固定下来[pytest] testpaths tests python_files test_*.py python_classes Test* python_functions test_* addopts -v -s --tbshorttestpaths告诉pytest去哪里找用例addopts是每个用例默认带上的参数。把-v -s写进addopts后命令行执行时就不用每次手动敲日志也能直接看到。不要小看这个文件它会让整个项目的执行行为变得可预期。3.3 用conftest.py统一管理公共fixtureconftest.py是pytest里最像“世界中心”的文件。放在根目录下的conftest对所有子目录用例生效放在某个子目录下的conftest只对该目录生效。我习惯把全局fixture放根目录把模块级专用fixture放对应目录# tests/conftest.py import pytest import requests pytest.fixture(scopesession) def base_url(): return https://api.example.com pytest.fixture(scopesession) def session_token(base_url): resp requests.post(f{base_url}/login, json{ username: admin, password: 123456, }) assert resp.status_code 200 return resp.json()[token]这里的base_url和session_token都不用导入只要用例函数声明同名参数pytest就会自动从conftest里找。conftest还有一个常见用途是定义命令行参数让它影响fixture结果。比如用--env切换测试环境def pytest_addoption(parser): parser.addoption(--env, actionstore, defaulttest, help环境: test/staging/prod) pytest.fixture(scopesession) def base_url(request): env request.config.getoption(--env) urls { test: https://test.example.com, staging: https://staging.example.com, prod: https://prod.example.com, } return urls[env]执行时用pytest --envstaging就能跑测试环境。这套设计在接口自动化项目里几乎是标配它让一套用例可以在多环境之间平移。3.4 接入Allure生成分层报告我最早用的是pytest-html简单但信息量有限。后来切到Allure发现它才是把自动化测试报告做得像平台的东西。Allure支持用例步骤、附件、严重级别、历史趋势还能从失败堆栈里快速定位问题。接入步骤不复杂。先确认装了allure-pytest再在机器上安装Allure命令行工具。以macOS为例brew install allure执行用例时指定结果目录pytest --alluredir./allure-results然后生成html报告allure generate ./allure-results -o ./allure-report --clean allure open ./allure-report为了让报告更专业可以在用例里加描述信息import allure allure.feature(登录模块) allure.story(普通用户登录) allure.severity(allure.severity_level.BLOCKER) allure.title(登录成功用例) def test_login_success(): with allure.step(输入用户名密码): pass with allure.step(点击登录): pass这样Allure报告里就会按照feature和story形成分组失败时能顺着步骤看到底是哪一步出错。自动化测试平台最需要的“结构化报告”能力Allure和pytest组合后基本全给补齐了。3.5 在CI里跑pytest并守住质量门禁本地能跑通只是第一步项目可持续的关键是把pytest接进CI。GitLab CI和GitHub Actions都支持简单的pytest流水线。核心干三件事安装依赖、跑测试、保留报告。以GitHub Actions为例简化版工作流可以这么理解用Python 3.11环境安装requirements然后执行pytest --alluredir./allure-results --maxfail5最后上传报告产物。CI里建议加--maxfail防止一堆失败用例刷屏导致日志爆炸。我一般还会加--timeout60给每个用例一个硬超时防止某些接口卡死拖垮整个任务。质量门禁怎么设我的经验是“从宽容到严格”。第一天就设置100%通过率会让团队崩溃但设置0%又没意义。比较合理的是先让冒烟用例作为门禁冒烟全过才跑完整回归完整回归允许一定比例的失败白名单但趋势要下降。pytest的退出码在CI里很好用全部通过且覆盖率达标则退出0否则退出非0流水线自动失败。4. 常见问题与排查技巧实录4.1 fixture不生效、scope混乱导致数据串场新手最常碰到的问题是定义了fixture但用例里不生效。先检查是不是把fixture函数写在了测试文件里却忘了参数名再检查是不是conftest.py放错目录导致用例的收集范围覆盖不到它。pytest的fixture查找规则是按“从近到远”来找的最近的是同文件最远的是根目录conftest.py如果找不到就会报fixture xxx not found。scope混乱导致的“数据串场”更隐蔽。比如一个session级别的fixture返回了可变的列表用例A往里加了一个元素用例B跑的时候就会拿到被污染的数据。解决方式是在fixture里返回深拷贝对象或者把到底用function还是session想清楚被修改的共享数据不要轻易用session。排查fixture问题时加个--setup-show参数能直观看到fixture的初始化和销毁顺序pytest --setup-show test_demo.py这个参数会列出每条用例的fixture调用链串场问题基本一眼就能看出来。4.2 用例收集不到多半是命名和路径出了问题执行pytest后显示collected 0 items先别怀疑框架坏了。99%的情况是文件名、类名、函数名没有匹配默认规则。检查是不是文件名以_test.py结尾但大小写不对是不是类名没有用Test开头是不是函数名没有用test_开头。如果都没问题再看testpaths配置是否指向了正确的目录。还有一种情况是测试文件放在了没有__init__.py的目录里或者目录名带特殊字符导致pytest的导入路径串了。我自己习惯在tests目录保留__init__.py这样pytest会把每个包当作一个模块导入不会出现两个同名用例文件互相干扰的问题。收集排查用这个命令最直接pytest --collect-only -q它会列出所有被收集到的用例路径如果列表比预期短对比一下就知道了。4.3 参数化用例在报告里的可读性差用pytest.mark.parametrize跑大量数据时默认用例名会把参数值直接拼进去。参数里如果有超长json字符串报告里就等着一长串乱码吧。解决方式是指定用例IDpytest.mark.parametrize(username,password, [ (admin, 123456), (alice, abc), ], ids[正确密码, 错误密码])ids能让每条用例展示成“正确密码”“错误密码”报告可读性直接提高一个档次。参数多时建议ids保持简洁比如test_login_输出正确密码这样能用中文描述为什么测这一组比堆数字有意义得多。4.4 并发执行时接口互相干扰pytest-xdist并行跑用例有多香踩坑就有多痛。最容易出事的是登录token这种共享状态并发用例同时请求登录接口后一个token覆盖前一个token导致大量401。我的建议是并发前先分清共享资源和隔离资源。token如果不想每个用例都登录一次就考虑用session级别的fixture加锁但更稳妥的是对写操作接口的用例做串行只在只读接口用例上开并行。xdist还带来了另一个问题Allure报告结果目录会被多个进程同时写。现在新版allure-pytest已经能处理进程号但我仍然建议跑并发时给每个worker独立结果目录或者干脆在pytest.ini里配置addopts -n 4 --dist loadscope--dist loadscope会让同一个文件里的用例分到同一个worker避免文件内共享fixture被并发破坏。4.5 重试、超时和用例依赖如何平衡业务级接口自动化里偶尔的网络抖动和缓存延迟确实会让人恼火。pytest-rerunfailures可以给用例加重试pytest --reruns 2 --reruns-delay 1但重试是一把双刃剑。如果接口本身有问题重试只会浪费时间如果用例有依赖前置用例重试更是雪上加霜。我给团队定的原则是只有对“幂等且无副作用”的用例允许重试比如查询类接口下单、支付、删除这类写操作失败后必须人工介入不要自动重试。用例依赖问题我在2.4里提过这里补充一点如果非要依赖顺序至少把依赖关系写在一个fixture里比如“已登录用户”“已加购商品”这样即使用例重排、并发也能靠fixture自身保证前提条件。pytest排序插件能解决执行顺序但解决不了数据不一致的根因。5. 一些关于pytest的进阶经验最后聊几个我在真实项目中摸索出来的细节这些内容不算复杂但都能直接减少维护成本。第一个是标记体系的建立。项目用例一多光靠文件名已经分不清优先级和环境。我在conftest里统一注册marker比如smoke、regression、slow、api、ui然后在CI里用-m smoke只跑冒烟用-m not slow跳过慢用例。marker用之前记得在pytest.ini里声明否则pytest会提示warning严格模式下甚至会失败。第二个是数据准备和清理的标准化。接口自动化最痛苦的不是写请求而是准备前置数据。我会封装一个data_builder模块用户、订单、优惠券等测试数据都通过接口批量创建再在case里通过fixture自动清理。不要直接往测试库手工插数据插了不知道删了更不知道最后只能靠一套“数据自建自清”的机制兜底。第三个是善用pytest_collection_modifyitems钩子。比如给所有用例自动添加特性标签或者动态决定跳过某些环境的用例。我做过一个很实用的功能读取配置文件中的环境标识如果当前环境没有部署某个服务就自动跳过对应接口用例并在跳过的原因里写明“服务未部署”。这个功能让团队在环境不完整时也能放心跑用例而不是看到一片红色后恐慌。第四个经验是报告要维护趋势而非单次结果。Allure的历史趋势图能反映失败率变化但前提是每次跑完都保留allure-results并合并到同一个趋势数据源。别用一次--clean把历史全清了那样你永远看不到质量是在变好还是变坏。还有一个小技巧调试fixture时可以用pytest --fixtures命令列出所有可见fixture方便确认自己定义的名字有没有被覆盖。名字冲突这事我至少碰到过三次每次都是靠着这个命令发现原来根目录conftest里已经有一个同名fixture直接把我的覆盖了。如果你现在正要搭建新的自动化测试项目我的建议是别一上来就追求“大而全”。先用pytest加pytest-html跑起来把第一条用例跑通再逐渐加入fixture、参数化、Allure、CI和并发。框架本身的复杂度是够用的真正决定项目能不能长期跑下去的是你对用例边界、数据隔离和报告可读性的设计。这个顺序走下来你会和我一样发现pytest不是那个“需要说服自己接受”的工具而是那个你越用越觉得顺手的底座。