1. 为什么是Pytest它到底比unittest强在哪先聊个现实问题很多人都问过我Python自带的unittest不是也挺好的吗为什么要换pytest我在公司待过好几个项目刚开始也是unittest一把梭。写一个测试用例得继承unittest.TestCase测试方法要写def test_xxx(self)断言得用self.assertEqual()、self.assertTrue()这些自带方法。如果一个测试类里十几个用例每个用例还想做不同的前置准备那个setUp()方法基本就是个大杂烩。更别提断言失败时assertEqual打印出来的message信息说实话有时候连我自己都要仔细看才知道到底差在哪里。后来碰上接口自动化测试的项目用例量动不动就上百我咬咬牙切到了pytest。第一感受是写起来真轻一个普通函数里面一个assert就完事不需要继承任何东西。但真正让我决定彻底换掉unittest的原因是pytest的几个核心能力。首先断言。pytest直接用Python原生的assert语句失败时自动展开表达式告诉你左右两边到底谁是谁。比如assert result[code] 200失败了你直接能看到result[code]的实际值和200之间的差异对于调试来说比assertEqual那种死板的输出强太多了。其次fixture机制。这是pytest的灵魂。unittest里用setUp和tearDown管理前后置但作用域只有类级别函数级别的临时数据、模块级别的资源、会话级别的登录token你就得自己想办法组织。pytest的fixture按scope区分可以精确控制到函数、类、模块、包、会话五个级别而且还可以互相依赖、做参数化。这个能力放到接口自动化测试里简直就是刚需——登录token只需要做一次数据库连接每个用例隔离这些都是fixture顺手就能安排的。再加上插件生态。pytest最恐怖的地方是插件数量和质量都相当能打。跑并发有pytest-xdist生成高级报告有pytest-allure统计覆盖率有pytest-cov失败重跑有pytest-rerunfailures。这些插件随便挑一个都是插上就能用不需要你改任何测试代码。相比之下unittest要自己做一套这些能力得花不少额外功夫。还有一点就是用例发现机制。pytest默认以test_*.py、*_test.py作为测试文件test_开头的函数或方法作为测试用例也可以自定义。这比unittest里必须用unittest.main()或TestLoader那一套灵活得多。目录一摆好命令行一敲用例直接全部收集上来省心。当然我不是说unittest一无是处。对于一些非常简单的、项目里也就几十个用例的场景用unittest也能正常运行。但一旦测试量上来要搞数据驱动、前置后置、并发执行pytest是性价比最高的选择。这篇分享就以我这两年在接口测试和单元测试中的实际经验为背景把pytest的入门路径掰开揉碎从怎么装、怎么写、怎么跑到fixture机制、参数化、插件生态和常见坑一步一步走一遍。2. 环境准备与第一个用例2.1 安装与目录规范先解决环境。不管你是Windows、macOS还是Linux只要Python环境正常pytest的安装一条命令就能搞定pip install pytest装完之后验证一下版本pytest --version能看到版本号说明就绪了。如果你用的是虚拟环境记得激活虚拟环境再装尽量避免污染系统级Python。国内网络环境不好的话可以加国内的pip镜像源比如清华源pip install -i https://pypi.tuna.tsinghua.edu.cn/simple pytest然后是项目结构。pytest的用例发现基于三个约定测试文件命名、测试函数/方法命名、testpaths配置。默认情况下文件命名为test_*.py或者*_test.py文件内的测试函数或方法以test_开头类名一般以Test开头且类内方法名为test_*我习惯的项目结构长这样project/ ├── src/ │ └── ... ├── tests/ │ ├── test_user_api.py │ ├── test_order_api.py │ └── conftest.py └── pytest.initests目录单独放测试代码业务代码放src目录根目录放一个pytest.ini做统一配置。这样做的好处是测试代码和业务代码不互相污染后续用pytest跑的时候只扫描tests目录收集速度也快。这里有个细节很多人会忽略如果业务代码和测试代码混在一起pytest默认会把测试文件所在目录加入sys.path有时候会意外引入错误的模块路径。单独建tests目录再配合pytest.ini的testpaths可以规避这类问题。2.2 第一个测试用例新建一个测试文件比如test_first.py写下最简单的用例def test_addition(): assert 1 1 2 def test_string_contains(): name pytest is awesome assert pytest in name在终端输入pytest test_first.py你会看到类似输出collected 2 items test_first.py .. [100%]两个点表示两个用例都通过了。如果故意改一个断言让它失败def test_addition(): assert 1 1 3再跑一次输出里就会清楚地显示出assert (1 1) 3左侧的实际值是2一目了然。这就是前面说的pytest的断言输出能力直接告诉你哪里错了而不是让你盯着一个笼统的False猜半天。2.3 命令行参数把这几个常用的运行参数背下来日常就能吃得开pytest -v # 显示每个用例的详细结果 pytest -q # 简洁模式只输出点和汇总 pytest -k login # 按用例名筛选支持模糊匹配 pytest -m smoke # 按标记(marker)筛选比如只跑冒烟用例 pytest -s # 显示print输出调试时经常用 pytest --collect-only # 只看收集到哪些用例不执行 pytest test_first.py::test_addition # 精确执行指定用例 pytest --maxfail1 # 遇到第一个失败就停止刚开始用pytest的人容易犯一个错误就是排查问题的时候不带-s结果print内容全被吞掉然后一脸迷茫。其实pytest默认为了保持输出整洁捕获了print的输出加了-s之后就全部放出来了。调试用例时我的常规操作是pytest -s test_xxx.py::test_yyy先精确定位到一条用例再查问题。另外-k这个参数在用例多的时候特别救急。比如我只想跑所有包含order的用例pytest -k order就够了不用去改文件。如果想排除某个关键词用-k not order。逻辑运算符也支持比如-k order or user。2.4 配置文件pytest.ini新手往往不写配置文件命令行参数一把梭这也没错但项目一复杂就不够用。推荐根目录放一个pytest.ini把公共配置沉淀下来[pytest] testpaths tests python_files test_*.py python_functions test_* addopts -v -s markers smoke: 冒烟用例 slowly: 慢速回归用例testpaths指定扫描目录python_files指定测试文件匹配规则addopts表示默认追加的命令行参数markers则是注册自定义标记。注册标记是为了避免pytest在用例上用了未登记的marker时报出Warning。这也是一个很多新手会遇到的提示如果运行的时候看到PytestUnknownMarkWarning说明你在用例上用了pytest.mark.xxx但没在配置里登记把marker写进pytest.ini就能消掉。3. Fixture机制pytest真正强大的地方3.1 fixture与unittest的setUp/tearDown先理解一个概念fixture解决的是什么问题写测试时经常要做前置准备比如开数据库连接、创建临时文件、登录拿token、往测试环境塞数据。等用例跑完还要清理现场比如关连接、删数据、恢复配置。在unittest里你把它们拆成setUp和tearDown。但问题随之而来如果不同用例需要不同的前置条件怎么办如果某些用例需要登录某些不需要呢在unittest里你只能要么全都登录要么做一堆if判断代码越来越难看。pytest的fixture思路完全不同。fixture是函数级别的依赖注入一个测试用例需要什么就在参数里声明什么。pytest执行用例前会先自动实例化对应的fixture执行其前置逻辑把返回值传给用例跑完之后再执行后置清理逻辑。看一下最经典的写法import pytest pytest.fixture def user_token(): token login(admin, admin123) yield token logout(token)user_token这个fixtureyield之前的代码属于前置部分返回值token会被注入到请求它的测试用例中yield之后的代码在用例执行完之后执行属于后置清理。测试用例想用就直接在参数列表里写user_tokendef test_get_user_info(user_token): headers {Authorization: user_token} ...这样每个用到token的用例都能拿到登录后的token用不到token的用例根本不用声明它。可组合、可复用、可精准控制这就是fixture的设计优势。3.2 scope控制fixture的生命周期fixture通过scope参数控制生命周期一共五个级别scope生命周期典型场景function每个测试函数执行前后各一次临时数据、独立连接class每个测试类只执行一次类级别的公共准备module每个测试模块执行一次模块级配置package每个包执行一次包级公共资源session整个测试会话只执行一次登录token、全局配置默认是scopefunction也就是每个用例都会创建一个fixture实例。如果你的了一个session级别的登录fixture那么整个测试期间登录动作只会执行一次import pytest pytest.fixture(scopesession) def session_token(): token login(admin, admin123) yield token logout(token)这类设计在接口自动化测试里尤其实用。每次接口用例执行前都去登录一遍效率太低了光是登录这个动作就要消耗不少时间而session级别的token可以保证整个测试流程只要一次登录后续用例全部共享。但要注意session级别的fixture可能会保留状态如果你用例间存在数据污染排查起来会比较头疼。所以我的习惯是共享的、只读的资源用session级每个用例都要独立的、会变的数据用function级。class和module级别的fixture我用的频率没有前两者高但有一个场景值得提如果你有一批用例属于同一个测试类且它们共享相同的前置条件那class级别的fixture比function级别效率高得多。我之前在数据库相关测试里在一个测试类中每个用例都要读取同一个慢速磁盘文件后来把fixture从function改成class同样数量用例的执行时间直接砍掉一半。3.3 自动使用autousefixture加autouseTrue后不需要显式声明参数pytest会自动执行这个fixture。适合做全局的、每个用例都需要的前置后置工作。pytest.fixture(autouseTrue) def print_test_name(): print(开始执行测试) yield print(测试结束)autouse一个非常重要的应用场景是日志收集。我曾经在测试一个支付网关接口时需要把所有用例的请求和响应都打到一个独立的日志文件里方便排查线上问题。一个autouse的fixture在yield前后记录时间戳、请求ID、用例名所有用例都自动带上这套逻辑还不用一个用例一个用例去修改。但autouse也不是随便乱用的它对测试干扰较大。比如有些环境变量、mock状态在autouse里设置很可能在无意中影响其他不相关的用例。我的建议是autouse只放那些人人依赖、无人显式声明的公共设施比如日志、全局超时设置、case级的环境变量隔离。3.4 conftest.py公共fixture的家如果一个fixture只在一个文件里用直接写在该文件顶部就行。但如果有多个测试文件都要复用同一个fixture就要把fixture放到一个叫conftest.py的文件里。pytest会从测试文件的目录层级向上查找conftest.py也就是说父目录的conftest.py对子目录下的测试文件自动生效。比如这套结构tests/ ├── conftest.py ├── test_user_api.py └── order/ ├── conftest.py └── test_order_api.py根目录的conftest.py可以放所有模块都需要的基础fixture比如日志、测试环境地址order目录的conftest.py放订单模块独有的fixture比如订单数据的构造。这两个conftest里的fixture对各自的测试文件生效互不干扰。这里有个坑我踩过不止一次conftest.py中的fixture名不小心和测试文件里的局部函数名重名了结果pytest在解析用例依赖时把局部函数当成了fixture来传报出一堆奇怪的定位错误。后来我养成了一个习惯所有fixture用统一的命名风格用形如fixture_xxx或者xxx_fixture的方式区分普通函数。4. 参数化与数据驱动让用例从1条变N条4.1 pytest.mark.parametrize的基本用法如果一个测试函数只有一组数据那写成一函数就够了。但现实是一条逻辑往往要验证多组数据比如登录接口要覆盖正确密码、错误密码、账号不存在、密码为空等场景。如果每个场景都单写一个函数代码量会爆炸维护成本也高。参数化就是为了解决这个问题。用pytest.mark.parametrize一条测试函数就变成了多条测试用例import pytest pytest.mark.parametrize(username,password,expected_code, [ (admin, 123456, 200), (admin, wrong, 401), (nobody, 123456, 404), (admin, , 400), ]) def test_login(username, password, expected_code): result login_api(username, password) assert result[status_code] expected_code执行的时候pytest会生成4条独立的用例每一条的测试数据不同。如果其中有失败只有对应的那一条显示失败其他照常运行。这在回归测试里特别好使一次逻辑写三五行几十组数据往列表里一塞用例覆盖度立刻拉满。参数名和参数值列表是成对出现的也可以叠加多个parametrize装饰器实现笛卡尔积比如验证不同用户在不同环境下的行为pytest.mark.parametrize(username, [admin, guest]) pytest.mark.parametrize(env, [dev, staging]) def test_user_profile(username, env): ...这样会生成2*24条用例。但叠加之后用例数量是乘法增长如果组数多用例数量会非常可观尽量确认是不是真的需要全组合。4.2 给用例起个好认的名字参数化之后pytest生成的用例名是test_login[admin-123456-200]这种形式。默认会直接把参数值拼上去如果参数里有中文、特殊字符或者特别长的对象用例名会变得异常难以阅读。用ids参数可以自定义每个参数字段的展示名pytest.mark.parametrize( username,password,expected_code, [ (admin, 123456, 200), (admin, wrong, 401), ], ids[correct password, wrong password] ) def test_login(username, password, expected_code): ...这样可以一眼看出每条用例验证的是哪个场景对排错帮助很大。尤其是跑pytest -v时可读性会好很多。4.3 从外部文件读取测试数据当测试数据量非常大比如接口自动化测试中的几十上百条用例数据硬编码在测试代码里会让代码失控。比较常见的做法是把数据放在JSON、YAML或CSV文件里测试代码负责读取并生成测试数据。举一个JSON数据驱动的例子[ {username: admin, password: 123456, expected: 200, desc: 正确密码}, {username: admin, password: wrong, expected: 401, desc: 错误密码} ]对应的测试代码import json import pytest def load_json_data(path): with open(path, encodingutf-8) as f: return json.load(f) pytest.mark.parametrize(case, load_json_data(./data/login_cases.json)) def test_login_from_json(case): result login_api(case[username], case[password]) assert result[status_code] case[expected]这种做法的好处非常直接测试逻辑没有变数据文件却可以随时增删。产品说我又发现了一个边界场景我直接往JSON文件里加一条记录跑一遍pytest用例自动多了一条完全不用碰代码。需要注意一点参数化是在收集阶段就发生的load_json_data在导入测试模块的时候就被调用了。如果文件路径写错或者JSON格式有问题pytest收集用例时就会报错这个报错信息有时候没有那么直观需要靠报错堆栈定位。我自己遇到过一次JSON文件末尾多了一个逗号收集阶段一直报错排查了半天才发现是数据文件格式问题。4.4 数据驱动在接口自动化中的落地数据驱动在接口自动化测试里最能体现价值。某个业务接口的参数组合非常多比如订单查询接口可能有订单号、用户ID、时间范围、页码、排序方式等维度每个维度又有若干边界值。我通常会把核心接口的测试数据独立成一个数据文件每条记录包括请求参数和预期结果然后用一条参数化用例统一执行。这带来的额外收益是测试报告的可读性大大提高。结合后面要讲的allure报告每一条数据驱动的用例都能单独显示失败后一眼能看到是哪个参数组合出的问题是产品逻辑bug还是测试数据过期定位速度比旧式的一个用例内部多次断言模式快得多。要注意的是数据驱动的用例多了以后如果每条用例都打真实的业务接口执行时间会很长。这时候就需要结合pytest-xdist做并发让多条case并行跑。数据文件的用例独立性就变得非常重要如果case之间互相有状态依赖并发后会出现偶发失败。所以写数据驱动用例前先思考一下这些数据是不是真的互相独立。5. 插件生态日常使用的六个真香插件5.1 pytest-xdist并发执行测试用例多了之后最直接的痛点就是一个一个跑太慢。pytest-xdist可以做到多进程并行执行测试用例。安装很简单pip install pytest-xdist跑法更简单pytest -n 4-n后面的数字表示用几个进程来跑。也可以写成-n auto它会根据机器CPU核数自动决定并发数。我刚开始用xdist时犯过一个错误直接把带session scope的fixture所谓的登录token共享给所有进程用结果每个进程都去执行登录后台的验证码校验直接被打崩了。后来看了官方文档才明白xdist的并行机制是每个worker进程独立收集和执行用例session级别的fixture在每个worker里都会执行一遍它跟你预期的全进程共享根本不是一回事。如果你打算做并发测试fixture里的前置准备要设计成每个worker可以独立完成的。把-n 4跑出来的结果跟单进程结果做对比如果出现用例之间的状态干扰多半就是并发导致的。5.2 pytest-allure让测试报告真正可读对测试报告有要求的团队应该都在找allure的方案。pytest搭配allure生成的报告无论是测试步骤、失败堆栈还是历史趋势都相当完善。安装和基本用法pip install pytest-allure pytest --alluredir./allure-results执行完之后需要打开报告allure generate ./allure-results -o ./allure-report --clean allure open ./allure-report在代码里可以用这些装饰器为用例增加更多上下文import allure allure.feature(登录模块) allure.story(验证用户密码) allure.title(正确密码登录成功) def test_login_success(): ...feature基本对标模块名story对标功能点title则是最终展示在报告中的用例标题。报告中可以清晰区分模块层级也便于管理层直接看大类的通过率。在失败用例的详情页里pytest的断言信息、命令行输出、附带的日志都会一并显示出来。有一点提醒一下allure的报告结果不是你执行完pytest就自动生成的。--alluredir只是把json结果文件写到指定目录必须再用allure命令来生成html报告。在CI/CD里要加上bulid报告这一步否则不会自动产出网页。5.3 pytest-cov覆盖率统计单元测试必须关注覆盖率。pytest-cov插件可以统计测试用例对业务代码的行覆盖率、分支覆盖率。pip install pytest-cov pytest --covsrc --cov-reporthtml--covsrc告诉pytest统计src目录下代码的覆盖率--cov-reporthtml会生成一份html格式的覆盖率报告。CI流水线里也可以加一个--cov-fail-under80如果覆盖率不足80%就直接失败。用覆盖率主要是为了找测试死角。有时候写了一条测试把核心逻辑大部分分支都覆盖了但仍然有某几行没被跑到。覆盖率的报告就像一张地图标出哪几行代码还没被走过照着去补测试效率比瞎猜高得多。5.4 pytest-rerunfailures失败用例自动重跑网络抖动、环境偶发问题导致的用例失败是最让人沮丧的明明是稳定的代码跑一次挂了人肉确认后又没问题。pytest-rerunfailures可以针对这类偶发性失败做自动重试。pip install pytest-rerunfailures pytest --reruns 3 --reruns-delay 1--reruns 3表示最多重试3次--reruns-delay 1表示每次重试间隔1秒。但这里请务必想清楚哪些用例可以重试哪些不该重试。数据写入类、状态变更类的用例重试很可能会造成重复数据或者脏数据。我更推荐把它用在纯读取类的接口测试比如查询接口、详情接口这些接口偶发失败通常都是网络抖动或服务端瞬时压力导致重试一下无伤大雅而对于下单、支付、创建订单这类操作重试带来的副作用可能比失败本身更大宁可让它失败后人工介入。5.5 pytest-html轻量级HTML报告如果不愿意引入allure那么重的方案pytest-html是很好的替代品。pip install pytest-html pytest --htmlreport.html生成的是一个单文件HTML打开就能看到所有用例的通过率、执行时间、失败原因。它虽然没有allure那么炫酷但胜在轻量一条命令就能出报告特别适合个人项目或者小型团队临时验收用。5.6 pytest-ordering控制用例执行顺序默认情况下pytest按文件、函数定义顺序执行但有时候我们希望某些用例必须先跑比如先准备数据再跑查询用例。pytest-ordering插件允许给用例加优先级。import pytest pytest.mark.run(order1) def test_setup_data(): ... pytest.mark.run(order2) def test_query_data(): ...坦白讲我对这个插件的态度是谨慎的。过度依赖用例顺序会让测试套件变得脆弱因为一旦某个前面的用例挂了后面的用例全都会跟着挂。它更适合用在必须的前置依赖比如先创建用户再验证用户详情而不是用来作为测试的逻辑编排工具。能设计成独立用例的尽可能不要用order依赖。6. 常见问题与排查技巧实录6.1 fixture解析失败fixture不存在或参数混乱报错信息形如fixture xxx not found。这种情况十有八九是fixture定义的位置不对或者参数名拼写错误。排查顺序先确认fixture是否定义在conftest.py中并且conftest.py的目录层级是否覆盖当前的测试文件再确认fixture名是否被局部同名函数覆盖最后看一眼fixture的参数名是否跟测试函数的参数名一一对应还有一个常见误会测试函数里的参数是普通数据比如字符串、数字本来应该用参数化传入结果不小心在函数参数里写了个普通变量名pytest会把这个普通变量名当成一个fixture名去解析自然就报fixture not found。解决方法是把数据交给参数化机制不要把普通数据放在函数的形参里。6.2 断言失败但不知道怎么调试pytest默认的输出已经比unittest友好很多但遇到复杂的断言比如比较一个包含多层的字典光看失败信息可能还不够。我常用的办法是加上-s让print输出可见在断言前把关键变量打印出来使用-v查看每个用例的完整信息在用例内加上pytest.set_trace()配合--pdb可以在断言失败时进入调试器具体操作pytest test_xxx.py -s -v如果用例里需要断点调试可以在代码中直接写def test_complex(): result get_complex_data() pytest.set_trace() assert result[data][items][0][price] 10运行到该行时会进入PDB交互界面可以逐行查看result的内容想查哪一层就查哪一层。但是注意用pytest.set_trace()调试完一定要删掉否则CI里跑用例会卡在调试交互界面。6.3 用例之间有相互依赖导致随机失败这个问题在数据驱动、并发执行时最容易出现。比如一个用例创建了订单A另一个用例去查询订单A后者的执行依赖前者执行成功。如果两个用例被分到不同的worker进程并行跑后者可能先跑订单A还没创建断言直接失败。方案有几个用fixture把创建订单和查询订单合成一个完整流程在同一个用例里完成用scopeclass或module的fixture把关联操作放在一起使用xdist的--distloadscope让同一个测试文件里的用例尽量在同一个worker里执行我个人的经验是依赖关系应该在测试设计阶段规避而不是靠工具硬调。如果一堆用例之间存在隐性的先后依赖说明测试粒度设计得还不够好。尽量让每一条用例独立构造自己的数据跑完再清理这是最稳定的方式。6.4 环境配置在不同机器上表现不一致在Jenkins、GitLab CI或者GitHub Actions上跑用例经常会出现本地全绿、CI上却有失败的玄学。这类问题多数出在环境变量、时间、时区、数据库状态和路径上。建议在conftest.py中做一个fixture专门检查CI的必要环境变量缺失直接fail fast节省排查时间。另外测试中会用到外部资源的路径建议用相对路径而不是绝对路径。去CI上一跑容器的工作目录跟你本机不一样路径一错用例全部失败。用pathlib.Path(__file__).parent这种由测试文件自身推导路径的方法可以避免大部分路径问题。6.5 想跳过某些用例场景某个功能需要在生产环境验证但当前是在测试环境不需要执行。pytest提供了skip与skipif两个装饰器import pytest pytest.mark.skip(reason该用例仅在生产环境执行) def test_production_only(): ... pytest.mark.skipif(env dev, reason开发环境不支持) def test_pay_callback(): ...也可以使用条件判断的方式在测试环境不是staging时直接跳过。这样不会把用例删掉也不会执行报错报告里能看到一条Skipped的记录方便了解哪些用例没跑以及为什么没跑。6.6 测试用例太多收集阶段变慢pytest收集用例时会把匹配到的所有测试文件全部导入并解析。如果项目规模大或者某些测试模块内部做了繁重的初始化工作收集阶段就会很慢跑一条用例也要等半分钟。优化手段在pytest.ini中精确指定testpaths不要让pytest扫描整个项目目录[pytest] testpaths tests减少测试模块顶部的重活比如不要在模块顶层就初始化数据库连接或加载大模型数据把这类工作挪到fixture里等真正需要用的时候再初始化用-p no:cacheprovider关闭缓存机制在某些场景下也能提升一点点收集速度我在一个大项目中碰到过收集一次要四十多秒的情况最后发现是一个测试模块顶部调用了超时时间很长的网络请求。把那个请求挪到fixture里懒加载之后收集时间瞬间降到了两秒。最后的实践建议从我个人的实际项目经验来看pytest的入门曲线是比较平缓的但真正用好它靠的是把fixture作用域理清、参数化数据驱动落地、插件选型贴合项目场景以及养成用例互相独立、不依赖执行顺序的设计习惯。前期图省事写的耦合用例后期都会变成随机失败的定时炸弹还不如一开始就花点时间组织好测试结构。如果你是刚接触pytest建议从一个小模块开始把unittest的老用例迁移过来对比一下旧代码和新代码的维护成本差异很快就能体会到我说的优雅在哪里。等对这个框架的脾气摸熟了再把数据驱动、并发执行、allure报告这些能力逐步加进来你的测试体系会越来越像一个真正能扛住回归压力的工程体系而不是一堆随手写的断言脚本。