接口测试系列接口自动化测试 pytest框架三这篇继续聊接口自动化测试。前面两篇如果都读过了应该已经知道pytest是怎么把一类接口的用例组织起来的也知道基础断言、fixture大概怎么回事。但很多朋友卡在一个地方单跑一两个接口很顺一旦接口变多、数据要复用、环境要切换用例结构就乱了维护成本直接起飞。这篇就把工程化落地的事一次性讲透重点说pytest框架里真正决定用例好不好维护的几个核心机制包括conftest全局复用、parametrize参数化、token管理、数据驱动、报告生成和失败重试。看完之后你手上那套接口自动化测试的代码应该能直接从“能跑”升级到“能进CI、能长期维护”。适合已经写过一些pytest用例、想搭一套正规接口自动化测试框架的同学也适合被一堆重复代码折磨得想重构的人。1. 内容整体设计与思路拆解1.1 系列前两篇做了什么事第三篇补齐哪块先说清楚这个系列走到哪一步了。前两篇大概率已经把pytest的发现规则、断言写法、基础fixture讲得差不多了。那些东西是地基没有它们后面什么都没法聊。但只靠那些基础能力去写接口自动化测试你会很快发现一个尴尬局面每个测试文件都要重新登录、重新拼参数、重新读配置公共逻辑堆在顶层函数里改一个环境地址要全局搜索替换。第三篇就是来解决这个尴尬的。目标很直接让测试代码具备工程化能力。说得细一点是四件事。第一用conftest.py把全局资源请求客户端、token、日志、配置统一管理起来用例文件里不再重复造轮子。第二用parametrize把一条用例扩展成一组用例数据量上去之后代码量不上去。第三把接口关联、动态参数、数据驱动这些真实业务场景里躲不开的问题用一套可复用的方案落地。第四把报告、重试、环境切换这些“上了CI才知道有用”的东西提前配好。所以我建议把这篇当作一次“脚手架搭建”来看。前两篇教你怎么写单个用例这篇教你怎么让一百个用例还能优雅地活着。1.2 为什么接口自动化测试要选pytest而不是其他这个话题网上讨论很多但落到实际项目里我的判断标准其实很朴素团队能不能低成本地理解它、插件生态够不够、失败之后能不能快速定位。pytest在这三件事上都做得不错。对比一下。unittest是标准库但它那套类继承结构和广泛的setUp/tearDown约定写多了会让人忍不住吐槽一个用例要关心类的生命周期接口测试里真的没那么多人愿意写一个TestCase类。Robot Framework上手门槛低但当你需要自定义断言逻辑、动态参数组合、灵活控制执行顺序的时候封装一层又一层反而比pytest难维护。pytest的思路不一样它把测试函数当作普通函数来处理fixture通过依赖注入自动传参用例只管声明“我需要什么”至于这个依赖怎么创建、什么时候销毁由fixture体系管理。这个抽象方向对了写起来就顺手很多。另外一个点是插件生态。pytest的插件不夸张地说覆盖了自动化测试的大部分需求参数化、依赖控制、报告、重试、顺序控制、并发执行。这些东西不是哪个公司内部的封装的私有能力而是社区沉淀出来的通用方案踩坑资料也多。做接口自动化测试选pytest在当下不是最优解但一定是不容易错的选择。1.3 工程目录怎么规划才能支撑多接口多环境一个清晰的项目目录比任何设计模式都重要。目录结构是框架的骨架如果连目录都乱后面的代码怎么组织都是别扭的。给你一个我实测比较好用的目录结构你可以按需裁剪api_auto_test/ ├── config/ │ ├── __init__.py │ ├── settings.py │ └── env.yaml ├── common/ │ ├── __init__.py │ ├── request_client.py │ ├── context.py │ ├── read_data.py │ └── log.py ├── testcases/ │ ├── __init__.py │ ├── conftest.py │ ├── test_user.py │ └── test_order.py ├── data/ │ ├── user.yaml │ └── order.yaml ├── reports/ │ └── allure-results/ ├── logs/ ├── pytest.ini └── requirements.txt几个关键决策说一下。testcases只放用例文件不放公共逻辑公共逻辑全部下沉到common。这样新人进来之后第一眼就知道“我要看用例就看testcases我要改请求封装就看common”心智负担小很多。data目录放测试数据文件这是数据驱动的基础。reports和logs生成出来的东西不进版本库这一条建议放到.gitignore里。pytest.ini放pytest配置包括测试路径、参数、标签关于pytest.ini的用法后面会讲到。这里有个细节值得多提一句common里那层request_client.py不是简单把requests再封装一层而是要把接口测试需要的通用逻辑都收进去比如统一打印请求日志、统一添加上下游关联变量、统一处理response断言。这层是做接口自动化测试的核心资产。2. 核心细节解析与实操要点2.1 fixture的依赖注入测试函数的状态来源fixture是pytest里最值得花时间理解的概念没有之一。它的本质是依赖注入测试函数声明自己需要一个参数pytest就去查找同名的fixture执行它并把返回值传给测试函数。你不用在测试函数里关心这个fixture是怎么创建的也不用关心它什么时候释放。先看一个最简单的例子import pytest pytest.fixture def user_token(): # 模拟登录获取token return fake-token-123456 def test_get_user_info(user_token): assert user_token.startswith(fake-token)这个例子太简单但已经能看出fixture的意义test_get_user_info如果直接自己发请求拿token那这个用例就既要关心“怎么登录”又要关心“怎么验证用户信息”职责混乱。通过fixture登录逻辑被抽离了测试函数只关心自己的业务验证。fixture有四个常见参数选择的时候要想清楚。scope控制fixture的生命周期。function级别的fixture每个测试函数执行一次class级别每个类执行一次module级别每个模块执行一次session级别整个测试会话只执行一次。autouse设为True时该fixture会被同作用域下的所有测试自动调用不需要在参数里声明。params给fixture传参数一个fixture参数值列表会生成多个fixture实例。yield在yield之前的代码是setupyield后面的代码是teardown。其中scope的选择最容易犯错。比如登录token这种资源理论上用session级别最合适但如果你没搞清楚session级别fixture的缓存机制就可能出现“第一个用例登录成功后面的用例token过期”这种问题。这个问题我们在第三部分详细展开。2.2 conftest.py跨文件复用而不是写一堆基类如果说fixture是pytest的依赖注入机制conftest.py就是把这个机制“全局化”的关键。conftest.py是一个特殊文件pytest会从测试目录开始向上查找所有conftest.py并自动加载其中的fixture。你不需要显式import它定义在conftest.py里的fixture会自动对同目录及子目录下的测试生效。这个特性直接解决了公共逻辑复用的问题。以前写unittest的时候公共逻辑要么写一个基类然后让TestCase继承要么写一个工具函数到处import。这两条路都不够优雅。基类继承会引入类层次结构改基类就可能影响所有子类而且新人很难一眼看出基类到底做了什么。工具函数到处import的问题是你根本没法方便地在函数里注入“带状态的资源”比如一个已经登录好的session你总不能每个函数都手动传一遍吧。conftest.py的解决方式是声明式复用。举个例子# testcases/conftest.py import pytest from common.request_client import RequestClient pytest.fixture(scopesession) def client(env_config): return RequestClient(base_urlenv_config[base_url])在testcases目录下所有测试函数里直接写def test_xxx(client)就能拿到一个已经初始化好的请求客户端。这个client是session级别的所有用例共用同一个连接池跑起来快很多。conftest.py还有一个作用放钩子函数hook。比如你想在每个用例执行完打印响应日志就可以在conftest.py里写pytest_runtest_makereport钩子。这是unittest完全做不到的扩展方式。钩子函数这块内容不少但我们这篇文章先聚焦fixture后续可以单独开一篇讲pytest钩子。2.3 parametrize参数化一条用例撑起一个数据集接口测试里最典型的场景是同一个接口多组入参每个入参都对应不同的期望结果。如果复制粘贴十遍用例代码冗余不说报告里还看不出是哪一组数据挂了。这时候就必须用parametrize。import pytest pytest.mark.parametrize(username,password,expected_code, [ (admin, 123456, 200), (admin, wrong, 401), (, 123456, 400), (admin, , 400), ], ids[正常登录, 密码错误, 用户名为空, 密码为空]) def test_login(username, password, expected_code): resp do_login(username, password) assert resp.status_code expected_code这里直接给参数化加了ids这样在测试报告中看到的是“正常登录”“密码错误”这样的名字而不是“login[0]”这种无意义编号。别小看这一个参数报告可读性在排障时能帮你省不少时间。parametrize还支持多组参数组合也就是笛卡尔积。比如测试搜索接口要分别测试关键词、页码、排序方式就可以组合出几十个用例pytest.mark.parametrize(keyword, [手机, 电脑, ]) pytest.mark.parametrize(page, [1, 2]) pytest.mark.parametrize(sort, [asc, desc]) def test_search(keyword, page, sort): pass这样就能生成12条用例。不过要注意组合用例的数量增长很快实际项目中要控制组合维度不然跑一次回归时间会变得不可控。3. 实操过程与核心环节实现3.1 请求客户端把session复用起来做接口自动化测试大多数人会直接requests.get/post这没问题但一旦用例变多就会遇到两个麻烦每次请求都要写header、token重复代码满天飞requests每次创建新连接没有复用连接池性能浪费。更关键的是你没地方统一打印日志出了问题排查起来很被动。所以第一步封装一个请求客户端。核心是使用requests.Session。# common/request_client.py import requests from common.log import logger class RequestClient: def __init__(self, base_url, token): self.session requests.Session() self.base_url base_url self.headers { Content-Type: application/json, Authorization: fBearer {token} } def request(self, method, path, **kwargs): url self.base_url path kwargs.setdefault(headers, self.headers) response self.session.request(method, url, **kwargs) logger.info(f{method.upper()} {url} - {response.status_code}, time{response.elapsed.total_seconds():.3f}s) if response.headers.get(content-type, ).startswith(application/json): logger.info(fresponse: {response.text}) return response def get(self, path, **kwargs): return self.request(GET, path, **kwargs) def post(self, path, **kwargs): return self.request(POST, path, **kwargs) def update_token(self, token): self.headers[Authorization] fBearer {token}用Session的好处是TCP连接会被复用Cookie可以自动携带而且可以在一个session范围内统一设置headers。日志打印是刚需每次请求都记录状态码和耗时排查问题的时候能快速定位是哪一步慢、哪一步挂了。注意这里对json请求体的处理。如果你传json参数requests会帮你在请求头里加上Content-Type: application/json但如果你已经在headers里写死了就要留意优先级问题。实际上requests对json参数的处理是在调用的那一刻动态设置Content-Type的所以不会冲突但如果你直接用data传字符串就必须自己保证content-type是对的。3.2 token管理登录一次全局有效接口测试里最常见的依赖是token。大多数业务接口需要登录后拿到token才能访问。token如果每个用例都登录一次性能太差如果生成后整个测试过程一直用又怕过期。所以我把token管理设计成session级别的fixture整个pytest进程只登录一次。# testcases/conftest.py import pytest from common.request_client import RequestClient from common.context import Context pytest.fixture(scopesession) def env_config(): # 具体读取逻辑见3.5 return read_env(test) pytest.fixture(scopesession) def context(): return Context() pytest.fixture(scopesession) def client(env_config, context): client RequestClient(base_urlenv_config[base_url]) # 登录并保存token login_resp client.post(/api/login, json{ username: env_config[username], password: env_config[password], }) assert login_resp.status_code 200 token login_resp.json()[data][token] client.update_token(token) # 把token存入全局上下文其他fixture也能用 context.set(token, token) return client这里有个小设计很关键Context类。它是一个全局上下文容器用来保存接口之间的关联变量。token、user_id这类数据都可以放进去。为什么要自己做这么一层因为pytest的fixture返回值默认是不可变的你不能在多个fixture之间共享一个可变对象然后随便改它。Context类就是我们的“全局变量区”。# common/context.py class Context: def __init__(self): self._data {} def set(self, key, value): self._data[key] value def get(self, key, defaultNone): return self._data.get(key, default)3.3 接口关联上一个接口的返回值怎么给下一个用接口关联是业务型接口自动化测试的必修课。比如下单接口需要用户ID而用户ID是创建用户接口的返回值。这种关联关系如果靠用例之间手动传参代码就会写成一坨。更通用的做法是使用上下文变量引用然后请求前做替换。做法不复杂在RequestClient的request方法里加一个步骤发送请求前把path、json、params、headers里的${key}这种占位符替换成Context里存的值。这个思路和JMeter里的用户自定义变量、Postman里的环境变量是一样的思路。import re class RequestClient: def __init__(self, base_url, token, contextNone): self.context context def _replace_context(self, data): if isinstance(data, str): def replacer(match): key match.group(1) value self.context.get(key) if value is None: raise ValueError(fcontext中未找到变量: {key}) return str(value) return re.sub(r\$\{(\w)\}, replacer, data) elif isinstance(data, dict): return {k: self._replace_context(v) for k, v in data.items()} elif isinstance(data, list): return [self._replace_context(item) for item in data] return data def request(self, method, path, **kwargs): path self._replace_context(path) if json in kwargs: kwargs[json] self._replace_context(kwargs[json]) if params in kwargs: kwargs[params] self._replace_context(kwargs[params]) if headers in kwargs: kwargs[headers] self._replace_context(kwargs[headers]) # ...发起请求这样在写用例的时候可以很形象地表达关联关系创建用户接口返回user_id后用context.set(user_id, user_id)存起来。下单接口测试数据里直接写userId: ${user_id}执行时自动替换。这个设计能极大减少用例代码量而且让测试数据文件更像“数据”而不是“逻辑”。这里要提醒一个细节requests.Session的请求是无状态的你改client.headers不会影响之前已经发出的请求但如果你在并发场景下修改context就要考虑竞态了。好在大多数接口自动化测试是顺序执行并发是后面用pytest-xdist时才需要考虑的事。3.4 数据驱动从yaml读取测试数据让用例只看数据不看逻辑写到这一步用例函数已经比较清爽了但还有一个问题测试数据写死在代码里每加一条用例就要改代码这不符合测试数据与测试逻辑分离的原则。解决方案是数据驱动把测试数据写到yaml文件用例函数用parametrize把数据加载进来。yaml是我最推荐的数据格式它可读性好、层级清晰比Excel好在能版本管理比json好在写起来省引号和逗号。# data/order.yaml - name: 正常创建订单 api: /api/order/create method: POST data: userId: ${user_id} productId: 1001 count: 2 expected: status_code: 200 code: 0 - name: 商品数量为0 api: /api/order/create method: POST data: userId: ${user_id} productId: 1001 count: 0 expected: status_code: 200 code: 10001读取yaml的函数放common/read_data.py# common/read_data.py import yaml import os def read_yaml(file_path): with open(file_path, encodingutf-8) as f: return yaml.safe_load(f) def load_test_data(file_name): data_dir os.path.join(os.path.dirname(os.path.dirname(__file__)), data) return read_yaml(os.path.join(data_dir, file_name))然后在用例文件里加载数据# testcases/test_order.py import pytest from common.read_data import load_test_data order_cases load_test_data(order.yaml) pytest.mark.parametrize(case, order_cases, ids[c[name] for c in order_cases]) def test_create_order(client, case): resp client.request(case[method], case[api], jsoncase[data]) assert resp.status_code case[expected][status_code] body resp.json() assert body[code] case[expected][code]这里有一个需要特别提醒的点parametrize的参数列表是在收集阶段就确定的所以load_test_data的执行发生在模块导入时。这本身没问题但意味着如果你在yaml文件里用了${user_id}这种占位符它仅仅是一个字符串真正执行时才会被替换。所以上面的用例里创建订单数据里的${user_id}会在请求发出前被RequestClient._replace_context替换成真实值。这个设计的关键在于占位符替换发生在request方法内部而不是数据读取阶段所以parametrize时data里还是占位符完全不影响。把这条讲透为什么不在读取yaml的时候就直接替换因为上下文里的值依赖前面用例的执行结果而parametrize是收集阶段就执行的收集阶段还没有执行任何用例当然拿不到user_id。所以替换时机必须后移到请求阶段这个顺序不能反。3.5 环境切换一套代码多套环境随便切测试环境、预发布环境、本地环境地址不同、账号不同。如果改一次环境就要改代码那框架离淘汰就不远了。环境配置放在config/env.yaml# config/env.yaml test: base_url: http://test-api.example.com username: test_user password: test_pass123 pre: base_url: http://pre-api.example.com username: pre_user password: pre_pass123读取逻辑# config/settings.py import os import yaml _current_env os.getenv(TEST_ENV, test) def get_env_config(): config_path os.path.join(os.path.dirname(__file__), env.yaml) with open(config_path, encodingutf-8) as f: config yaml.safe_load(f) return config[_current_env]运行的时候指定环境TEST_ENVpre pytest -qWindows下是set TEST_ENVpre pytest -q。这个设计简单但非常有效它让环境切换变成启动参数而不是代码改动。3.6 报告与重试工具链组合减少人工盯盘接口自动化测试跑在CI里没有人会盯着终端看输出所以报告和失败重试是必需品。报告我推荐用allure虽然配置比pytest-html繁琐一点但展示效果和数据丰富度好得多。基本用法是先装插件然后执行时指定结果目录pip install allure-pytest pytest-rerunfailures pytest --alluredirreports/allure-results --reruns 2 --reruns-delay 1用--reruns 2的意思是失败后最多重试2次--reruns-delay 1表示每次重试间隔1秒。采集完结果后用allure命令行生成报告allure generate reports/allure-results -o reports/allure-report --clean重试机制对接口测试来说非常实用尤其是下游服务偶发超时这种问题重试一次可能就过了。但注意一点不是所有失败都适合重试断言失败比如返回码和期望不一致重试多少次都不会变这时候重试只会拖慢测试运行时间。所以重试次数不要设太高一般2次足够。使用allure之后还可以通过装饰器给用例附加更丰富的描述信息比如功能模块、严重级别、接口地址。import allure allure.feature(订单模块) allure.story(创建订单) allure.title(正常创建订单) pytest.mark.parametrize(case, order_cases, ids[c[name] for c in order_cases]) def test_create_order(client, case): pass这样在allure报告里就能按功能模块筛选用例排障时直接按模块归拢不用一个个用例翻。别小看这种元信息项目用例过千之后筛选效率决定了排障效率。4. 常见问题与排查技巧实录4.1 用例执行顺序不可控怎么办pytest默认按模块文件名排序模块内按函数定义顺序排序但这个顺序很多时候不是你期望的业务顺序。有些同学喜欢通过用例名加数字前缀test_01_xxx、test_02_xxx来控制顺序这是一种可行方案但很容易让用例名变得很难看。我更推荐的方案是从设计上消除用例间的顺序依赖。每个用例都应该可以独立运行而不是“上一个用例必须先生成数据”。接口关联通过context来解耦而不是通过用例执行顺序来保证。如果非要有顺序比如必须先有用户才能测订单那应该在fixture层解决比如在创建订单的用例里依赖一个created_user的fixture由fixture去创建用户而不是依赖test_create_user先执行。如果实在要控制顺序用pytest-order插件pip install pytest-orderpytest.mark.order(1) def test_login(): pass pytest.mark.order(2) def test_create_order(): pass但请你相信我顺序依赖是测试套件里最容易被忽视的定时炸弹。今天加一个用例、明天调整一个用例顺序可能就乱了然后莫名奇妙挂掉。尽量在框架设计层面避免它。4.2 session级fixture的数据污染这是我在实际项目中踩过最深的坑。一个session级别的fixture被设计成返回一个可变对象比如列表、字典结果某个测试函数往里加了一条数据后续所有用到这个fixture的用例都受影响。表面上看是某条用例挂了实际上是被前一个用例污染了。解决方案有几个方向。fixture返回的对象尽量是不可变的或者请求客户端内部不要暴露可变状态。如果确实需要共享可变状态比如共享的用户信息字典那就在使用侧做一个copydef test_update_user(user_info): local_info dict(user_info) # 拷贝一份 local_info[name] new_name ...另外session级别的fixture在设计时要考虑一个隐含假设这个fixture内部的连接、token、状态在整个测试会话中是单例且稳定的。如果某个用例需要特殊状态就单独建一个function级别的fixture不要复用session级的那个对象。4.3 断言失败时缺少响应日志排查全靠猜这是新人最容易犯的错。断言一句assert resp.status_code 200一旦失败只会看到“assert 500 200”完全没有上下文。你怎么知道是哪个接口、什么参数、响应体是什么所以我在RequestClient里统一打印了请求日志但在断言层还需要再补一层。推荐用pytest的断言钩子pytest_assertrepr_compare在conftest.py里自定义断言失败时的输出。但更简单实用的方式是断言前先打印响应内容或者用allure的attach把请求和响应挂在报告里。import allure def assert_response(resp, expected_status_code): if resp.status_code ! expected_status_code: allure.attach(resp.text, 响应体, allure.attachment_type.TEXT) raise AssertionError(f期望状态码 {expected_status_code}实际 {resp.status_code}响应体: {resp.text})这样失败时报告里能看到请求失败时的原始响应排查效率直接翻倍。这个思路要往框架深处走让所有断言失败都自动带上日志上下文而不是依赖每个用例的作者自觉。4.4 参数化数据量过大报告冗长难排查组合参数化生成几百条用例报告里一长串看一眼就头疼。我的处理方式是给每个参数化用例都加清晰的ids并在参数化数据里包含“业务名称”字段这样报告能直接看出是哪条业务场景挂了。另外如果参数组合特别多可以给用例加上allure的layer和feature标签按业务模块筛选而不是在几百条用例里硬翻。还有一个经验数据驱动时把预期结果也放到数据文件里但预期字段要设计得合理。不要只存一个status_code要存业务码code、关键返回字段这样断言才能覆盖到接口的真实业务含义而不仅仅是“没报错”。我见过很多接口自动化测试跑着全绿但接口逻辑已经坏了就是因为断言只比较了HTTP状态码接口即使返回业务错误也是200所以永远绿。断言必须落到业务字段上。5. 给实战项目的几点补充建议前面把框架的骨架搭起来了这里再补一点实战中才意识到的细节。pytest.ini是pytest的配置文件建议在项目根目录维护一份。它能帮你统一测试路径、命令行参数、标签规则。比如这样# pytest.ini [pytest] testpaths testcases python_files test_*.py python_classes Test* python_functions test_* addopts -ra --strict-markers markers smoke: 冒烟测试标记 regression: 回归测试标记--strict-markers会强制要求标记必须先在pytest.ini里声明这样就不会出现拼写错误导致的标记失效。-ra参数会在测试结束后汇总所有失败原因跑长套件的时候很有用。日志方面我习惯在common/log.py里用logging模块封装一个带文件输出的logger。日志级别在本地调试时设置DEBUGCI上设置INFO避免日志刷屏。请求日志和断言日志分开看方便定位。最后说说并发执行。用例多起来之后单线程跑可能就很慢了。pytest-xdist可以用多进程并行跑但前提是测试用例之间没有共享状态或者共享状态做了并发安全的处理。我在实际项目里是先保证用例独立性然后才上并发否则跑起来就是灾难。并发下context的写入要注意加锁这个如果后面用到可以单独讲一次。再补一个容易被忽略的点requests里timeout一定要设置。不设置timeout的话某个接口挂起时整个测试会一直卡着CI任务永远不会结束。设置timeout之后接口长时间无响应会被判定为失败而不是无限等待。这个看着是个小事但线上出过事故教训深刻。response self.session.request(method, url, timeout10, **kwargs)如果你想在yaml数据里也支持timeout配置可以在request方法里优先使用kwargs里传入的timeout没有的话再用默认值。这样灵活性更高。写在最后做了这么多接口自动化测试的项目我个人最大的体会是pytest框架本身只是一个执行引擎真正的核心是围绕它设计的工程化配套。fixture管资源parametrize管数据conftest管复用context管关联日志和报告管排查。这五件事想清楚一套接口自动化测试框架的基本盘就稳了。最后再分享一个小技巧框架搭好之后不要把所有字段都放进配置文件或数据文件里。配置文件只放环境相关的内容地址、账号业务相关的数据放数据文件代码相关的逻辑放common。这样分层之后测试人员改数据不需要碰代码开发人员改逻辑不会影响数据两者职责清晰。这个系列后面可以接着聊pytest的插件开发、并发执行、与CI工具集成也可以聊聊如何把接口自动化测试的请求录制下来生成用例。有具体想了解的方向可以在评论里一起讨论。