聊到Python测试，很多人第一反应是“写测试就是给代码上个保险”，但真到了项目里，单元测试、集成测试、性能测试这三层到底怎么划分、怎么写、怎么融入日常开发，很多人其实是一笔糊涂账。我前后在几个项目组里折腾过这套东西，从最初“测试比代码还难写”的抱怨，到后来把测试当成开发流程的一部分，中间踩过的坑、总结出来的套路，还是挺值得拿出来说一说的。这篇文章不讲虚的，直接围绕单元测试、集成测试、性能测试三条主线，把思路、工具、实操细节和排查经验都摊开讲清楚，适合想系统落地Python测试的开发者参考。

1. 测试到底在测什么：先把整体地图铺开

1.1 测试金字塔与三层测试的边界

测试金字塔这个概念虽然老，但直到今天仍然是设计测试策略最实用的参考。简单说，金字塔分三层：底层是单元测试，量大、速度快、成本低；中间是集成测试，数量适中、速度尚可、能验证模块之间的协作；顶层是端到端测试，数量最少、速度最慢、成本最高。

我见过不少团队把这三层混着用，最典型的就是“只写接口测试，不写单元测试”，理由是接口测试覆盖了逻辑，单元测试写起来费劲。这个想法在项目前期看着还行，一旦业务逻辑复杂到一定程度，排查问题的成本会直线上升。因为接口测试一旦失败，你很难立刻定位是哪个函数、哪个分支出了问题，必须层层debug。而单元测试会把问题精确到函数级别，报错信息直接告诉你哪一个断言失败了。

这三层不是替代关系，而是互补关系。我的经验是：单元测试保证每一块积木本身是好的，集成测试保证积木拼在一起不出乱子，性能测试保证拼好的建筑在真实负载下不会塌。对应到Python项目里，pytest负责单元测试和集成测试的组织，性能测试则可以在此基础上叠加专门的工具。

1.2 按风险分配测试成本：先测什么、多测什么

测试成本不是平均分配的。刚入门的时候，我恨不得把所有函数都写上测试，结果就是大量低价值的测试占了时间，真正容易出问题的核心逻辑反而没覆盖到位。后来我换了一种思路：按风险排优先级。

什么算高风险？第一类是资金相关逻辑，比如订单金额计算、折扣叠加、支付回调处理；第二类是核心业务规则，比如权限校验、状态机流转、库存扣减；第三类是容易被改坏的公共方法，比如一些工具函数、数据解析函数。这些地方不写测试，后续重构时心里就是悬着的。而一些一次性脚本、展示层代码、纯私有辅助方法，就不必强求全覆盖。

覆盖率的数字也是一种参考，但不要盲目追高。我见过某个项目覆盖率95%，但核心交易链路完全没有被测过——因为那部分逻辑写在了一个巨大的函数里，测试很难构造输入。与其纠结覆盖率数字，不如先把高风险的几条链路用例补齐，再回头补充其他模块。

1.3 测试的自动化程度与回归价值

自动化测试最大的价值其实是回归保护。手动测试只能证明“当前这次操作是好的”，自动化测试可以在每次提交代码时反复证明“以前能跑的功能没有被改坏”。尤其在多人协作的项目里，A同学改了公共模块，B同学的功能依赖它，如果没有自动化回归，这种隐性破坏往往要等上线后被用户发现。

我在一个项目里见过最典型的例子：某个公共函数改了返回值格式，调用方没有适配，结果线上订单查询报错。当时这个函数有单元测试，但单元测试只验证了函数自身输出，没有验证调用方的集成行为。后来我们补了一层集成测试，把公共模块和调用方的链路一起测，这个问题就被自动挡住了。

所以，搭建测试体系时不要只盯着“写了多少测试”，要盯住“能挡住多少回归”。如果某次改动引发了一个bug，而测试体系没有发现，那就说明测试存在缺口，需要补上对应的用例。

2. 单元测试：pytest让断言变成一种习惯

2.1 一个最小可用的pytest测试长什么样

选pytest而不是unittest，原因很简单：pytest的写法更简洁、fixture更灵活、插件生态更强。unittest是标准库自带的，但在实际项目里，pytest几乎成了事实标准。如果项目是一个标准Python包，安装后测试基本就是pip install pytest然后写测试文件。

一个最小的pytest测试是这样的：

# test_discount.py from order import calculate_discount def test_calculate_discount_basic(): assert calculate_discount(100, 0.8) == 80

这个文件就定义了一个测试函数，函数名以test_开头，内部用assert断言结果。pytest会递归搜索当前目录下所有test_.py或_test.py文件，收集里面所有test_开头的函数并执行。

体验过unittest那种必须继承TestCase、用self.assertEqual写断言的写法，再用pytest会明显感觉到自由很多。pytest还提供了异常断言、近似值断言这些方便的语法：

def test_raises_on_invalid_input(): import pytest with pytest.raises(ValueError): calculate_discount(-1, 0.8) def test_float_compare(): assert 0.1 + 0.2 == pytest.approx(0.3)

这两点都是实际项目中容易踩坑的地方：非法的业务输入要明确抛异常而不是静默返错；浮点运算结果不能直接用==比较，要用approx做精度容差。基础断言写法熟练之后，日常单元测试基本就够用了。

2.2 fixture：解决“怎么准备测试环境”的通用问题

单元测试里最麻烦的不是断言，而是准备数据。比如测试一个查询用户订单详情的函数，你需要一个用户、几笔订单、订单里的商品信息。如果每个测试函数都自己造一遍数据，代码会又臭又长。pytest的fixture机制就是为此设计的。

import pytest @pytest.fixture def sample_user(): return {"id": 1, "name": "Alice", "level": "vip"} @pytest.fixture def sample_orders(sample_user): return [ {"id": 101, "user_id": sample_user["id"], "amount": 299}, {"id": 102, "user_id": sample_user["id"], "amount": 59}, ] def test_user_total_spent(sample_user, sample_orders): total = calculate_total_spent(sample_user, sample_orders) assert total == 358

fixture就是“依赖注入”的简化版：测试函数把需要的数据以参数的形式声明出来，pytest自动查找同名fixture然后执行、注入。fixture之间也可以互相依赖，比如sample_orders依赖sample_user，pytest会按依赖顺序自动解析。

fixture还有一个比手工造数据强大得多的能力：yield后置逻辑。比如你要建一个临时数据库并测试数据，测试结束后希望数据自动清理，可以这样写：

@pytest.fixture def temp_db(): db = create_temp_database() yield db db.drop()

这样每个用temp_db的测试，执行前会建库，执行后会自动清场。fixture的scope参数则可以控制复用范围，module、class、session级别的fixture只初始化一次，适合耗时的准备工作。

实操中我第一次踩的坑就是fixture命名太短，比如def db()，后来项目大了之后，根本不知道这个db连接的是本地库还是测试库。建议fixture命名用完整的语义名称，并且把fixture定义单独放到conftest.py里，实现跨模块共享。

2.3 mock实战：不联网、不依赖真实下游

单元测试的铁律之一是“测试不跑真实的网络、不请求真实的外部服务”。否则一次CI跑下来，因为第三方接口超时而挂掉，谁也不知道是代码问题还是网络问题。这时候就要用mock。

from unittest.mock import patch def send_welcome_email(user_email): # 内部依赖外部邮件服务 email_client.send(user_email, "Welcome!") @patch("user_service.email_client") def test_send_welcome_email(mock_email_client): send_welcome_email("test@example.com") mock_email_client.send.assert_called_once_with( "test@example.com", "Welcome!" )

这里的核心是把依赖的外部对象替换成mock对象，然后验证它是否按预期被调用。patch的目标字符串要写清“在哪里使用它”，而不是“它定义在哪里”。这个细节我踩过几次坑：如果被测模块里写的是from email_module import email_client，寄那么patch("email_module.email_client")是没用的，因为模块里的名字已经绑定到原对象了。要patch的是“被测代码模块里的这个名字”，比如@patch("user_service.email_client")。

mock还可以设定返回值或侧effects：

@patch("user_service.api_call") def test_api_return_value(mock_api): mock_api.return_value = {"status": "ok"} result = user_service.process_request() assert result == "ok"

模拟异常也是对边界条件的常见测试手法。mock一个接口让它抛超时异常，再验证被测代码能正确处理超时重试逻辑——这种用例写出来，比单纯测正常路径更能反应真实环境问题。

2.4 参数化：同一个逻辑，跑完整张数据表

测试代码里最没有技术含量却又最容易遗漏的，就是边界值。比如一个折扣计算函数，除了常规价格，还要考虑0元、负数、超过100%的折扣、极大金额等等。把这些边界case逐一写成独立测试函数，代码会膨胀到难以维护。pytest的parametrize就是为这个场景设计的：

import pytest from order import calculate_discount @pytest.mark.parametrize("price, ratio, expected", [ (100, 0.8, 80), (0, 0.5, 0), (100, 0, 0), (100, 1, 100), (50, 0.33, 16.5), ]) def test_calculate_discount(price, ratio, expected): assert calculate_discount(price, ratio) == expected

跑这个测试时，pytest会显示每个用例的具体参数，哪一组失败一目了然。parametrize也能组合多个维度，比如同时测价格和折扣的笛卡尔积，但我建议不要盲目组合，组合太多会造成大量重复执行，反而模糊了真正的测试意图。

经验之谈：每次发现一个bug，第一反应不应该是“改完就完”，而是把这个bug对应的输入加入参数化用例，让测试守住这条边界。

2.5 覆盖率与断言质量：数量不如重点

很多人对单元测试的价值感知来自覆盖率报告。确实，覆盖率能直观告诉你哪些代码从没被执行过。我用pytest-cov比较多，跑一下就能看到模块级的覆盖情况。

pytest --cov=myproject --cov-report=html

但我必须泼一盆冷水：覆盖率是“必要不充分”的指标。一个函数100%覆盖可能只测了正常返回分支，连异常分支都没碰。所以我的建议是，覆盖率报告用来辅助发现“完全没被测到的模块”，而不是作为KPI。核心逻辑的每个分支、每个异常路径，才是真正要人工核对的因素。

另一个细节是断言的强度。我见过不少测试写成这样：

def test_foo(): result = foo() assert result is not None

这种断言几乎等于没测——任何返回非None的实现都能通过。好的断言应该验证业务结果的具体值、调用的参数、异常的类型和消息。一句话总结：断言要具体到“谁、在什么条件下、被调用了几次、传了什么参数、返回了什么值”。

3. 集成测试：把真实模块和真实依赖拉到一起

3.1 集成测试与单元测试的本质区别

单元测试是“隔离测试”，它故意把被测对象依赖的其他模块mock掉，只验证当前函数自身逻辑。集成测试则反其道而行之：把多个真实模块拼接在一起，验证它们协作时是否按预期工作。

打个比方，单元测试是检查发动机的每个零件，集成测试是启动发动机看看整机能不能运转。零件单独都好，不代表装一起就转得起来——接口参数对不上、数据格式不兼容、调用顺序出错，都是集成阶段才暴露的问题。

Python项目里最常见的集成测试目标是数据库和外部API服务。数据库测试要解决“测试数据怎么来怎么走”的问题；外部API测试要解决“怎么保证服务可用且可控”的问题。

3.2 数据库集成测试：用事务回滚实现可重复

数据库集成测试最大的难点是数据污染。测试往表里插了数据，如果不清理干净，下次测试就会受影响。最简单的做法是每个测试用独立事务，测试结束后回滚，让所有数据改动“消失”。

在SQLAlchemy里常见写法：

import pytest from sqlalchemy import create_engine from sqlalchemy.orm import sessionmaker @pytest.fixture def db_session(): engine = create_engine("sqlite:///:memory:") Session = sessionmaker(bind=engine) session = Session() yield session session.close()

用内存SQLite做测试库，好处是快、隔离、无副作用。但有个坑要注意：如果你的代码用了PostgreSQL专有的JSONB、数组字段等特性，SQLite往往不支持，这时就得用真实数据库，比如本地Docker起一个PostgreSQL实例，再在测试里包一层外事务回滚。

@pytest.fixture def db_session(postgres_engine): connection = postgres_engine.connect() trans = connection.begin() session = Session(bind=connection) yield session trans.rollback() connection.close()

核心思路是让每个测试都且环境，测试A插入的数据不影响测试B，测试B也不必手动清理。这样可以放心大胆地在测试里造数据、改数据。

3.3 外部服务怎么处理：本地替身与可控依赖

外部服务集成测试的经典困境是“真实性”和“可控性”的矛盾。直接用真实服务，测试结果真实但不可控——你今天能连上，明天可能连不上；线上证书一换，测试全挂。全部mock掉，测试可控但失去集成意义——mock和真实服务行为往往有偏差。

比较推荐的折中方案是“本地替身”：在本地环境启动一个真实的第三方服务的替代品，比如用WireMock模拟HTTP接口，或者用containerized的真实依赖（比如Redis、MySQL）跑测试。这样测试既走了真实的网络协议栈，又不依赖于外部网络环境。

import requests from tests.wiremock import mock_payment_endpoint def test_order_payment_integration(): mock_payment_endpoint(success=True) result = order_service.pay(order_id=123, amount=99) assert result["status"] == "paid"

mock_payment_endpoint在本地起了一个HTTP服务，模拟真实支付接口的响应。被测代码发起的请求经过真实HTTP栈到本地的替身服务，链路更接近生产环境。

3.4 用Docker搭建可复现的集成测试环境

在多人协作的项目里，集成测试环境最容易出现“我本地能过、你本地挂了”的情况。根本原因是每个人的依赖环境不一致：A的MySQL版本8.x，B的MySQL版本5.7；A的Redis有密码，B的Redis没密码。

用Docker Compose管理测试依赖是比较通行的解法。在项目根目录放一个docker-compose.test.yml，定义测试用的数据库、缓存、消息队列等中间件，CI和本地共用同一套镜像版本。

services: db: image: postgres:15 environment: POSTGRES_USER: test POSTGRES_PASSWORD: test ports: - "5433:5432"

跑集成测试前先docker compose -f docker-compose.test.yml up -d，然后设置环境变量指向测试容器，测试结束后down掉即可。这样做虽然多了一层Docker操作，但环境一致性带来的收益远大于那一点点启动时间。

我个人的经验是：测试环境一定要能从零到一自动化搭建，别依赖某个同事手工配置好的机器。否则团队一扩大，新成员光是要跑通测试就得折腾半天。

4. 性能测试：从“能跑”到“跑得快”

4.1 性能测试的分类：基准测试与负载测试

很多人提到性能测试就想到压测接口、看QPS，但性能测试至少还分为两个层次。函数级性能测试（基准测试）和系统级压力测试（负载测试）。

基准测试关注“单个函数在一定输入下执行有多快”，通常用于优化代码时对比不同实现方案。负载测试关注“系统在高并发下表现如何”，通常用于评估容量、发现瓶颈。

这两个层次的目的不同、工具不同、触发时机也不同：基准测试可以跟随单元测试一起跑，负载测试则应该单独安排——因为负载测试会消耗大量资源，不宜频繁跑。

4.2 用pytest-benchmark做函数级基准

Python做函数级基准最方便的方式是pytest-benchmark插件，它把基准测试无缝融合进pytest体系里。

pip install pytest-benchmark

def test_discount_function_benchmark(benchmark): result = benchmark(calculate_discount, 100, 0.8)

跑的时候会额外输出一组性能数据：每个函数平均耗时、最大耗时、最小值、置信区间等等。还有一个隐藏功能是基准对比，你可以把两个不同实现同时跑一遍，pytest-benchmark会直接输出两者的耗时差异，这对优化代码特别有用。

实际使用时要注意：基准测试对机器状态很敏感，CPU降频、后台任务都会导致数据抖动。跑基准测试之前最好关掉浏览器、暂停自动更新，并且多跑几轮取中位数。在CI里跑基准测试时，不要跟单测混在一起，因为单测的机器负载会影响基准数据。

4.3 用Locust做HTTP接口压测

做HTTP接口的压力测试，我在项目里用得比较多的是Locust。它用Python写压测脚本，支持分布式生成负载，还能在Web界面实时看吞吐量和响应时间。

from locust import HttpUser, task, between class ApiUser(HttpUser): wait_time = between(1, 3) @task def get_home(self): self.client.get("/") @task(3) def query_order(self): self.client.get("/order/12345") class HeavyUser(HttpUser): wait_time = between(0.1, 0.5) @task def pay(self): self.client.post("/pay", json={"order_id": 123, "amount": 99})

Locust的wait_time模拟真实用户的思考时间；@task(数字)表示权重，数字大的执行频率更高。多个User类可以模拟不同类型用户的行为比例。

运行：

locust -f loadtest.py --host=http://localhost:8080 --headless -u 50 -r 10 --run-time 1m

这条命令的意思是用50个并发用户、每秒启动10个、持续压1分钟。实测下来，Locust的Web模式更适合调试脚本、观察指标；CI环境则用headless模式，输出文字报告。

4.4 性能报告怎么看：p50、p95、吞吐量

性能压测结束后会得到大量数据，不要只盯着“平均响应时间”。平均值很容易被少数慢请求拉高或拉低，不能反映真实体验。

更值得关注的是p50、p95甚至p99：p50表示一半请求的响应时间在这个值以下，p95表示95%的请求都优于这个值。p95和p99之间的差异能反映系统在极端负载下的稳定性。如果p50很低但p99很高，通常意味着存在“长尾延迟”——可能是一次GC、一次缓存失效或者某个线程竞争导致。

吞吐量同样关键，一般以“每秒请求数”（RPS）来衡量。我习惯把RPS和p99结合来看：一个系统可能RPS很高，但p99已经超时严重；另一个系统RPS虽然略低，但整体响应平稳。性能优化的目标不是单项指标拉满，而是找到满足业务需求的平衡点。

性能测试不是跑一次就完事。我强烈建议把基准测试写进CI的一个独立job，每次代码合并前跑一次，把关键接口的p50、p95、RPS和上一次结果做对比。一旦发现明显劣化，立刻阻止合并。

4.5 性能回归的守护：把基准测试放进CI

让基准测试自动跑、自动报警的思路很简单：在代码仓库里保存上一轮性能基准确认的基准数据，本轮跑完对比，劣化超过阈值就失败。

pytest --benchmark-enable --benchmark-autosave --benchmark-max-time=1

--benchmark-autosave会保存每次运行结果，配合--benchmark-compare可以对比历史数据。CI里维护这样的任务，相当于是给核心路径的性能上了一道自动回归保险。

不过要提醒的是，CI机器如果跟其他任务共跑，性能数据波动很大。最好用专有的Runner跑性能测试，或者至少保证跑性能测试时机器负载可控。

5. 真实项目中踩过的坑：问题排查与经验记录

5.1 测试不稳定：为什么昨天全绿今天挂

测试不稳定（flaky）是我见过最消耗团队信任感的问题。典型场景：本地跑全绿，CI上随机挂一两个，重跑一遍又全过了。这种测试比没写还糟，因为大家最后会选择“重跑一次试试”，而不是真正去排查和定位。

最常见的flaky来源是时间依赖：测试里用真实时间做断言，比如“订单创建时间应为今天”，但跑测试时跨越了午夜或者系统时钟不同步，断言就挂了。解决办法是用时间mock，固定一个时间值。另一个常见来源是依赖顺序：某个测试改动了全局状态，影响了另一个测试。解决办法是让每个测试都拥有独立的状态环境，fixture里显式清理。

我在一个项目里排查flaky测试时发现，根因是某个fixture用了session级，session里缓存了一个对象，但之前另一个测试修改了这个对象的属性——后跑的测试拿到的是被污染的对象。改成function级fixture，问题就彻底解决了。

5.2 mock用不对：我mock掉了整个测试

mock是强大工具，也是最容易滥用工具。一个常见的笑话式错误是：因为mock得太彻底，测试实际上没有测任何代码。比如把被测函数内部调用的所有东西都mock掉，然后只验证“mock被调用了”——

@patch("order_service.payment_client") @patch("order_service.inventory_client") @patch("order_service.notification_client") def test_process_order(mock_notify, mock_inventory, mock_payment): result = order_service.process_order(...) assert mock_payment.call_count == 1

这样的测试确实能“过”，但它测的是“三个mock被调用了”，完全没覆盖订单状态是否正确、库存扣减逻辑是否正确、异常处理是否正确。真正的集成逻辑等于完全没测。

后来我给自己定了一条规矩：mock只用在“跨进程边界”的地方（网络IO、磁盘IO、时间），业务计算逻辑里的函数调用尽量真实执行。这样测试才保得住该有的价值。

5.3 数据库数据互相污染

多人协作项目里，数据库集成测试最常见的问题是一套测试数据被多个开发者共享。A同学跑测试往common_user里插了一条记录，B同学的测试因为同样user id跑了，直接失败。

这类问题的根治方案其实就是前面提到的“测试独立事务+每测试回滚”。但有另一个场景：测试里读取了外部系统填好的基础数据表，这些表经常变化，测试断言也会莫名失败。解决方式是基础数据表用测试专用的、固定不变的版本，而业务数据表由每个测试自行构造。不要让测试读生产库里动态变化的数据。

5.4 fixture范围设错了导致意外共享

fixture的scope是pytest里一个看似简单实则容易出错的地方。func级fixture每个测试执行一次，module级fixture每个模块执行一次，session级fixture整个测试会话只执行一次。如果某个fixture里维护了可变状态，比如一份缓存字典、一个计数器、一个数据库连接池，并把scope设成了session，那么测试之间的相互影响会变得极其隐蔽。

我曾经调试过一个报错：测试A和测试B单独跑都通过，合在一起跑就挂。最后发现是某个cache fixture缓存了用户信息，测试A改了内容，测试B读取时命中了被修改的缓存。修复方式就是把该fixture改为function级，或者在fixture里做好独立的副本。

5.5 性能测试的典型误区

性能测试如果没有做好数据准备，很容易得出误导性结论。最典型的是“空表压测”，数据库里没数据，接口性能当然好看，但这不代表真实场景。压测前要把数据量补到接近生产的水平，至少覆盖典型的表数据量。

另一个误区是压测脚本里“思考时间”设置不当。真实用户不会每秒钟点击一次接口，都是停顿几秒、思考一下再操作。如果压测脚本全是无间隔请求，压力会比真实场景大很多，结果参考价值有限。用Locust里的wait_time去模仿正常用户操作节奏，得到的指标才更接近生产。

还有一个容易忽视的点：性能测试完成后要关注错误率。有时候QPS看起来很高，但错误率也高，比如大量请求超时、服务器返回5xx，这时候的高吞吐量没有任何意义。每次压测都要同时记录成功率，成功率低于99.9%就已经说明系统有瓶颈了。

5.6 从“补测试”到“测试先行”的转变

体系搭起来很容易，难的是习惯的改变。早期我也经历过“项目急着上线，先写功能，之后再补测试”的阶段。结果“之后”基本不存在，等用户反馈bug再补用例，相当于给破房子刷漆。后来我强制自己在一个新功能开发时先写核心逻辑的失败用例，再实现功能，让用例由红变绿。这样写测试反而是自然的事。

一个具体的实用习惯是：每次修复bug，先写一个会触发这个bug的测试，再修实现代码。这样能确保修复真正覆盖问题，也防止以后回归。测试这件事，本质上不是开发流程的负担，而是把潜在问题提前暴露、把系统行为固化成文档的一种投资。

在我经历过的几个Python项目里，真正把单元测试、集成测试、性能测试跑顺之后，开发效率反而是提升的——因为改代码的底气更足，回归确认的时间更短，线上踩雷的次数也明显下降。如果你所在的项目还停留在“手动验证一下能跑就上线”的阶段，建议从单元测试开始，先给核心业务函数补一层用例，再逐步扩展集成测试和性能测试。别贪多，先把最祝福你踩的哪块骨头啃下来，后面的路会越走越顺。