作为有9年经验的Python后端开发者今天用真实项目案例带你打通测试的任督二脉。1. 为什么测试总是“说起来重要做起来次要”先问一个问题你最近一次因为测试不充分导致的线上事故是什么时候我的是3个月前一个看似简单的用户注册逻辑因为缺少对第三方短信服务异常的测试导致在服务商故障时用户无法注册直接损失了当日的30%新用户。测试不是写给别人看的是给自己买的保险。今天这篇文章不讲那些“测试金字塔”的理论这些你早就听腻了只讲我在真实项目中踩过的坑、总结出的实战经验以及那些能让测试真正发挥价值的技术细节。2. unittest vs pytest到底该选谁我选pytest的5个理由很多团队在选择测试框架时左右为难。让我直接告诉你结论选pytest。理由不是因为它“流行”而是因为它解决了unittest的几个核心痛点。2.1 真实踩坑案例为什么unittest让我们团队集体加班2025年我们接手了一个老项目用的是unittest。当时要加一个简单的用户积分功能测试用例是这样的import unittest from user_service import UserService class TestUserService(unittest.TestCase): def setUp(self): self.service UserService() # 这里需要连接真实数据库 self.db connect_to_production_db() # 错误示范 def test_add_points(self): user self.service.get_user(1) old_points user.points self.service.add_points(1, 100) new_user self.service.get_user(1) self.assertEqual(new_user.points, old_points 100)问题来了测试依赖真实数据库数据库一挂测试全挂测试会修改生产数据是的我们真的犯过这种低级错误每个测试都要手动写断言代码冗长2.2 我的解决方案切换到pytest的真实迁移路径迁移到pytest后同样的测试变成了这样import pytest from unittest.mock import MagicMock from user_service import UserService class TestUserService: pytest.fixture def mock_db(self): 模拟数据库连接 mock MagicMock() mock.get_user.return_value {id: 1, name: Alice, points: 500} return mock pytest.fixture def service(self, mock_db): 注入模拟的数据库依赖 service UserService() service.db mock_db return service def test_add_points(self, service, mock_db): # 执行测试 result service.add_points(1, 100) # 更简洁的断言 assert result is True # 验证是否正确调用了数据库方法 mock_db.update_user.assert_called_once_with( user_id1, updates{points: 600} )pytest的3个核心优势维度unittestpytest实际影响代码量平均多30-50%简洁维护成本降低40%断言语法self.assertEqual(a, b)assert a b可读性提升调试更容易夹具管理setUp/tearDownpytest.fixture依赖注入代码复用率提升60%插件生态有限丰富700插件可扩展性强参数化测试需要第三方库原生支持测试场景覆盖更全面2.3 你可能不知道的pytest陷阱我踩过的陷阱1fixture作用域混乱# 错误示例每个测试都重建数据库连接太慢 pytest.fixture(scopefunction) def db_connection(): return create_expensive_db_connection() # 正确示例测试会话共享连接 pytest.fixture(scopesession) def db_connection(): conn create_expensive_db_connection() yield conn conn.close() # 整个测试结束后才清理陷阱2assert失败信息不清晰# 错误示例只显示AssertionError不知道具体哪里错了 assert user[points] 1000 # 正确示例失败时显示详细对比 assert user[points] 1000, \ f用户积分错误期望1000实际{user[points]}3. 单元测试中的Mock实战隔离外部依赖的艺术单元测试的核心原则是“隔离”。但现实是我们的代码充满了外部依赖数据库、API、消息队列、文件系统...3.1 真实案例支付服务测试如何不真的扣钱我们有一个支付服务需要调用第三方支付网关# payment_service.py import requests class PaymentService: def __init__(self, api_key: str): self.api_key api_key self.base_url https://payment-gateway.com def charge(self, user_id: int, amount: float) - dict: 调用真实支付网关扣款 payload { user_id: user_id, amount: amount, currency: CNY } headers { Authorization: fBearer {self.api_key}, Content-Type: application/json } # 这里会真的发起网络请求 response requests.post( f{self.base_url}/charge, jsonpayload, headersheaders, timeout10 ) response.raise_for_status() return response.json()问题测试会真的扣钱而且依赖网络不稳定。解决方案使用unittest.mock全面隔离# test_payment_service.py import pytest from unittest.mock import patch, MagicMock from payment_service import PaymentService class TestPaymentService: pytest.fixture def service(self): return PaymentService(api_keytest_key) def test_charge_success(self, service): # 模拟requests.post方法 with patch(payment_service.requests.post) as mock_post: # 配置模拟响应 mock_response MagicMock() mock_response.status_code 200 mock_response.json.return_value { transaction_id: txn_123456, status: success } mock_post.return_value mock_response # 执行测试 result service.charge(user_id1, amount100.0) # 验证结果 assert result[status] success assert transaction_id in result # 验证请求参数 mock_post.assert_called_once() call_args mock_post.call_args assert call_args[0][0] https://payment-gateway.com/charge assert call_args[1][json][amount] 100.0 def test_charge_network_error(self, service): # 测试网络异常场景 with patch(payment_service.requests.post) as mock_post: mock_post.side_effect requests.exceptions.ConnectionError(网络超时) with pytest.raises(requests.exceptions.ConnectionError): service.charge(user_id1, amount100.0)3.2 你可能忽略的Mock细节细节1patch路径是使用处而非定义处# 错误patch标准库路径 with patch(requests.post): # 可能不生效 ... # 正确patch当前模块中导入的requests with patch(payment_service.requests.post): # 一定会生效 ...细节2side_effect的多种用法from unittest.mock import Mock # 1. 抛出异常 mock Mock() mock.method.side_effect ValueError(参数错误) # 2. 返回序列值 mock Mock() mock.method.side_effect [1, 2, 3] assert mock.method() 1 assert mock.method() 2 assert mock.method() 3 # 3. 动态计算返回值 mock Mock() mock.method.side_effect lambda x: x * 2 assert mock.method(5) 104. 集成测试环境配置Docker Compose的5大陷阱集成测试需要真实的外部服务。Docker Compose是首选方案但坑也最多。4.1 真实案例为什么我们的集成测试总是随机失败去年我们项目集成测试的失败率高达40%大部分是“服务未就绪”错误。核心问题是服务启动顺序和健康检查。错误的docker-compose.ymlversion: 3.8 services: app: build: . depends_on: - postgres - redis ports: - 8000:8000 postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password redis: image: redis:7问题depends_on只保证容器启动不保证服务就绪。PostgreSQL容器启动了但数据库还没初始化完成应用就已经开始连接了。解决方案健康检查 条件依赖version: 3.8 services: app: build: . depends_on: postgres: condition: service_healthy redis: condition: service_healthy environment: - WAIT_FOR_ITpostgres:5432,redis:6379 command: sh -c wait-for-it postgres:5432 --timeout30 wait-for-it redis:6379 --timeout30 python app.py ports: - 8000:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 10s timeout: 5s retries: 3 start_period: 40s postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password POSTGRES_DB: myapp healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 5s timeout: 5s retries: 5 redis: image: redis:7 command: redis-server --requirepass password healthcheck: test: [CMD, redis-cli, -a, password, ping] interval: 5s timeout: 3s retries: 54.2 Docker Compose集成测试最佳实践实践1分层配置文件docker-compose.base.yml # 基础服务定义 docker-compose.test.yml # 测试环境配置 docker-compose.ci.yml # CI环境配置实践2测试数据隔离import pytest import docker import time pytest.fixture(scopesession) def docker_compose(): 启动测试环境 client docker.from_env() # 使用唯一的项目名避免冲突 project_name ftest_{int(time.time())} # 启动服务 client.containers.run( postgres:15, environment{ POSTGRES_PASSWORD: testpass, POSTGRES_DB: testdb }, namef{project_name}_postgres, detachTrue ) yield project_name # 测试结束后清理 for container in client.containers.list(): if container.name.startswith(project_name): container.remove(forceTrue)5. 性能测试Locust从入门到实战性能测试不是“跑一下看看会不会挂”而是要回答系统瓶颈在哪里能承受多少并发何时需要扩容5.1 真实案例双十一大促前我们如何发现系统瓶颈去年双十一前我们用Locust对电商系统进行压测发现了3个关键瓶颈Redis连接池耗尽默认配置只能支持5000并发数据库慢查询商品列表接口没有索引服务雪崩一个服务挂掉导致整个链路崩溃Locust测试脚本# locustfile.py from locust import HttpUser, task, between, events import json import random from datetime import datetime class ECommerceUser(HttpUser): wait_time between(1, 3) # 模拟用户思考时间 def on_start(self): 用户登录 login_data { username: fuser_{random.randint(1, 10000)}, password: test123 } response self.client.post(/api/login, jsonlogin_data) if response.status_code 200: self.token response.json()[token] self.headers {Authorization: fBearer {self.token}} task(3) def browse_products(self): 浏览商品高频操作 category random.choice([electronics, clothing, books]) params { category: category, page: random.randint(1, 10), page_size: 20 } self.client.get(/api/products, paramsparams, headersself.headers) task(1) def place_order(self): 下单低频但关键 product_id random.randint(1, 1000) order_data { product_id: product_id, quantity: 1, address: 测试地址 } with self.client.post(/api/orders, jsonorder_data, headersself.headers, catch_responseTrue) as response: if response.status_code ! 200: response.failure(f下单失败: {response.text}) task(2) def view_product_detail(self): 查看商品详情 product_id random.randint(1, 1000) self.client.get(f/api/products/{product_id}, headersself.headers)5.2 Locust实战技巧技巧1分布式压测# 主节点 locust -f locustfile.py --master --hosthttp://api.example.com # 工作节点可以启动多个 locust -f locustfile.py --worker --master-host192.168.1.100技巧2自定义监控指标from locust import events events.request.add_listener def track_performance(request_type, name, response_time, response_length, exception, context, **kwargs): 自定义指标采集 if name /api/orders: # 记录下单接口性能 if response_time 1000: # 超过1秒 print(f警告下单接口慢耗时{response_time}ms)技巧3渐进式加压from locust import LoadTestShape class SpikeLoadShape(LoadTestShape): 模拟流量突增场景 stages [ {duration: 300, users: 1000, spawn_rate: 100}, # 5分钟到1000用户 {duration: 600, users: 5000, spawn_rate: 200}, # 10分钟到5000用户 {duration: 900, users: 10000, spawn_rate: 500}, # 15分钟到10000用户 ]6. 测试覆盖率不只是数字游戏很多人把覆盖率当成KPI导致出现大量“为了覆盖而覆盖”的无效测试。我见过一个项目覆盖率95%但线上事故频发——因为关键路径没测到。6.1 覆盖率配置最佳实践**.coveragerc配置文件 **[run] source my_project omit */tests/* */migrations/* */venv/* */__pycache__/* setup.py manage.py branch True # 启用分支覆盖率 [report] fail_under 80 # 覆盖率低于80%则失败 show_missing True # 显示未覆盖的行 exclude_lines pragma: no cover def __repr__ def __str__ raise NotImplementedError if __name__ .__main__.: [html] directory coverage_html # HTML报告目录 title My Project Coverage Report6.2 覆盖率陷阱与应对陷阱1覆盖率虚高# 错误只调用函数不验证功能 def test_add_user(): add_user(test, testexample.com) # 调用了但没验证结果 # 正确验证业务逻辑 def test_add_user(): result add_user(test, testexample.com) assert result[id] is not None assert result[username] test陷阱2忽略异常路径# 错误只测正常情况 def test_divide(): assert divide(10, 2) 5 # 正确测试异常情况 def test_divide(): assert divide(10, 2) 5 # 测试除数为0 with pytest.raises(ValueError, match除数不能为0): divide(10, 0)7. 9年经验总结让测试真正产生价值的7个原则**测试是设计工具不是质量保证 **如果写测试时发现代码难测说明设计有问题**速度就是生命 **测试运行超过5分钟开发人员就不想运行了**覆盖关键路径而非所有代码 **20%的代码承载80%的业务价值**测试数据要真实 **用生产数据的脱敏样本不要用随机生成的数据**集成测试要有价值 **不是为了集成而集成要验证真实的业务场景**性能测试要可重复 **每次结果应该一致否则测试就不可信**覆盖率是手段不是目的 **追求有价值的覆盖而不是数字的覆盖7.1 我的测试金字塔实际项目比例/-----------\ | E2E测试 | 5% - 验证关键用户旅程 \-----------/ /-------\ | 集成测试 | 15% - 验证服务间协作 \-------/ /-----\ |单元测试| 80% - 验证业务逻辑正确性 \-----/**单元测试 **验证算法、业务规则、边界条件**集成测试 **验证数据库操作、第三方API集成**E2E测试 **验证核心用户流程如注册-登录-下单-支付8. 互动与思考问你们三个问题评论区见你们项目现在测试覆盖率多少是真覆盖还是“数字游戏”我见过最离谱的项目为了凑覆盖率把测试代码也计入覆盖率统计...最近一次因为测试不充分导致的线上事故是什么我们的是短信服务异常导致注册失败。你们的呢如果只能选一个测试框架你选unittest还是pytest为什么别只说“因为流行”说具体的技术理由。给初学者的3个建议**从今天开始 **不要等“项目稳定了再补测试”现在就开始。哪怕只有一个测试也比没有强。**从核心业务开始 **先测试用户注册、登录、支付这些关键路径。工具类函数可以往后放。**建立持续集成 **GitHub Actions或GitLab CI配置测试自动化。每次提交都跑测试问题早发现早解决。9. 结语测试是开发者的“职业素养”写了9年代码我最大的体会是** 代码质量不是靠review出来的是靠测试保障的 **。一个没有测试的项目就像没有安全网的高空作业——今天不出事是运气好明天出事是必然的。测试不是负担是投资。今天花1小时写测试明天可能节省10小时排查bug的时间。
Python测试实战：单元测试、集成测试与性能测试全解析
作为有9年经验的Python后端开发者今天用真实项目案例带你打通测试的任督二脉。1. 为什么测试总是“说起来重要做起来次要”先问一个问题你最近一次因为测试不充分导致的线上事故是什么时候我的是3个月前一个看似简单的用户注册逻辑因为缺少对第三方短信服务异常的测试导致在服务商故障时用户无法注册直接损失了当日的30%新用户。测试不是写给别人看的是给自己买的保险。今天这篇文章不讲那些“测试金字塔”的理论这些你早就听腻了只讲我在真实项目中踩过的坑、总结出的实战经验以及那些能让测试真正发挥价值的技术细节。2. unittest vs pytest到底该选谁我选pytest的5个理由很多团队在选择测试框架时左右为难。让我直接告诉你结论选pytest。理由不是因为它“流行”而是因为它解决了unittest的几个核心痛点。2.1 真实踩坑案例为什么unittest让我们团队集体加班2025年我们接手了一个老项目用的是unittest。当时要加一个简单的用户积分功能测试用例是这样的import unittest from user_service import UserService class TestUserService(unittest.TestCase): def setUp(self): self.service UserService() # 这里需要连接真实数据库 self.db connect_to_production_db() # 错误示范 def test_add_points(self): user self.service.get_user(1) old_points user.points self.service.add_points(1, 100) new_user self.service.get_user(1) self.assertEqual(new_user.points, old_points 100)问题来了测试依赖真实数据库数据库一挂测试全挂测试会修改生产数据是的我们真的犯过这种低级错误每个测试都要手动写断言代码冗长2.2 我的解决方案切换到pytest的真实迁移路径迁移到pytest后同样的测试变成了这样import pytest from unittest.mock import MagicMock from user_service import UserService class TestUserService: pytest.fixture def mock_db(self): 模拟数据库连接 mock MagicMock() mock.get_user.return_value {id: 1, name: Alice, points: 500} return mock pytest.fixture def service(self, mock_db): 注入模拟的数据库依赖 service UserService() service.db mock_db return service def test_add_points(self, service, mock_db): # 执行测试 result service.add_points(1, 100) # 更简洁的断言 assert result is True # 验证是否正确调用了数据库方法 mock_db.update_user.assert_called_once_with( user_id1, updates{points: 600} )pytest的3个核心优势维度unittestpytest实际影响代码量平均多30-50%简洁维护成本降低40%断言语法self.assertEqual(a, b)assert a b可读性提升调试更容易夹具管理setUp/tearDownpytest.fixture依赖注入代码复用率提升60%插件生态有限丰富700插件可扩展性强参数化测试需要第三方库原生支持测试场景覆盖更全面2.3 你可能不知道的pytest陷阱我踩过的陷阱1fixture作用域混乱# 错误示例每个测试都重建数据库连接太慢 pytest.fixture(scopefunction) def db_connection(): return create_expensive_db_connection() # 正确示例测试会话共享连接 pytest.fixture(scopesession) def db_connection(): conn create_expensive_db_connection() yield conn conn.close() # 整个测试结束后才清理陷阱2assert失败信息不清晰# 错误示例只显示AssertionError不知道具体哪里错了 assert user[points] 1000 # 正确示例失败时显示详细对比 assert user[points] 1000, \ f用户积分错误期望1000实际{user[points]}3. 单元测试中的Mock实战隔离外部依赖的艺术单元测试的核心原则是“隔离”。但现实是我们的代码充满了外部依赖数据库、API、消息队列、文件系统...3.1 真实案例支付服务测试如何不真的扣钱我们有一个支付服务需要调用第三方支付网关# payment_service.py import requests class PaymentService: def __init__(self, api_key: str): self.api_key api_key self.base_url https://payment-gateway.com def charge(self, user_id: int, amount: float) - dict: 调用真实支付网关扣款 payload { user_id: user_id, amount: amount, currency: CNY } headers { Authorization: fBearer {self.api_key}, Content-Type: application/json } # 这里会真的发起网络请求 response requests.post( f{self.base_url}/charge, jsonpayload, headersheaders, timeout10 ) response.raise_for_status() return response.json()问题测试会真的扣钱而且依赖网络不稳定。解决方案使用unittest.mock全面隔离# test_payment_service.py import pytest from unittest.mock import patch, MagicMock from payment_service import PaymentService class TestPaymentService: pytest.fixture def service(self): return PaymentService(api_keytest_key) def test_charge_success(self, service): # 模拟requests.post方法 with patch(payment_service.requests.post) as mock_post: # 配置模拟响应 mock_response MagicMock() mock_response.status_code 200 mock_response.json.return_value { transaction_id: txn_123456, status: success } mock_post.return_value mock_response # 执行测试 result service.charge(user_id1, amount100.0) # 验证结果 assert result[status] success assert transaction_id in result # 验证请求参数 mock_post.assert_called_once() call_args mock_post.call_args assert call_args[0][0] https://payment-gateway.com/charge assert call_args[1][json][amount] 100.0 def test_charge_network_error(self, service): # 测试网络异常场景 with patch(payment_service.requests.post) as mock_post: mock_post.side_effect requests.exceptions.ConnectionError(网络超时) with pytest.raises(requests.exceptions.ConnectionError): service.charge(user_id1, amount100.0)3.2 你可能忽略的Mock细节细节1patch路径是使用处而非定义处# 错误patch标准库路径 with patch(requests.post): # 可能不生效 ... # 正确patch当前模块中导入的requests with patch(payment_service.requests.post): # 一定会生效 ...细节2side_effect的多种用法from unittest.mock import Mock # 1. 抛出异常 mock Mock() mock.method.side_effect ValueError(参数错误) # 2. 返回序列值 mock Mock() mock.method.side_effect [1, 2, 3] assert mock.method() 1 assert mock.method() 2 assert mock.method() 3 # 3. 动态计算返回值 mock Mock() mock.method.side_effect lambda x: x * 2 assert mock.method(5) 104. 集成测试环境配置Docker Compose的5大陷阱集成测试需要真实的外部服务。Docker Compose是首选方案但坑也最多。4.1 真实案例为什么我们的集成测试总是随机失败去年我们项目集成测试的失败率高达40%大部分是“服务未就绪”错误。核心问题是服务启动顺序和健康检查。错误的docker-compose.ymlversion: 3.8 services: app: build: . depends_on: - postgres - redis ports: - 8000:8000 postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password redis: image: redis:7问题depends_on只保证容器启动不保证服务就绪。PostgreSQL容器启动了但数据库还没初始化完成应用就已经开始连接了。解决方案健康检查 条件依赖version: 3.8 services: app: build: . depends_on: postgres: condition: service_healthy redis: condition: service_healthy environment: - WAIT_FOR_ITpostgres:5432,redis:6379 command: sh -c wait-for-it postgres:5432 --timeout30 wait-for-it redis:6379 --timeout30 python app.py ports: - 8000:8000 healthcheck: test: [CMD, curl, -f, http://localhost:8000/health] interval: 10s timeout: 5s retries: 3 start_period: 40s postgres: image: postgres:15 environment: POSTGRES_PASSWORD: password POSTGRES_DB: myapp healthcheck: test: [CMD-SHELL, pg_isready -U postgres] interval: 5s timeout: 5s retries: 5 redis: image: redis:7 command: redis-server --requirepass password healthcheck: test: [CMD, redis-cli, -a, password, ping] interval: 5s timeout: 3s retries: 54.2 Docker Compose集成测试最佳实践实践1分层配置文件docker-compose.base.yml # 基础服务定义 docker-compose.test.yml # 测试环境配置 docker-compose.ci.yml # CI环境配置实践2测试数据隔离import pytest import docker import time pytest.fixture(scopesession) def docker_compose(): 启动测试环境 client docker.from_env() # 使用唯一的项目名避免冲突 project_name ftest_{int(time.time())} # 启动服务 client.containers.run( postgres:15, environment{ POSTGRES_PASSWORD: testpass, POSTGRES_DB: testdb }, namef{project_name}_postgres, detachTrue ) yield project_name # 测试结束后清理 for container in client.containers.list(): if container.name.startswith(project_name): container.remove(forceTrue)5. 性能测试Locust从入门到实战性能测试不是“跑一下看看会不会挂”而是要回答系统瓶颈在哪里能承受多少并发何时需要扩容5.1 真实案例双十一大促前我们如何发现系统瓶颈去年双十一前我们用Locust对电商系统进行压测发现了3个关键瓶颈Redis连接池耗尽默认配置只能支持5000并发数据库慢查询商品列表接口没有索引服务雪崩一个服务挂掉导致整个链路崩溃Locust测试脚本# locustfile.py from locust import HttpUser, task, between, events import json import random from datetime import datetime class ECommerceUser(HttpUser): wait_time between(1, 3) # 模拟用户思考时间 def on_start(self): 用户登录 login_data { username: fuser_{random.randint(1, 10000)}, password: test123 } response self.client.post(/api/login, jsonlogin_data) if response.status_code 200: self.token response.json()[token] self.headers {Authorization: fBearer {self.token}} task(3) def browse_products(self): 浏览商品高频操作 category random.choice([electronics, clothing, books]) params { category: category, page: random.randint(1, 10), page_size: 20 } self.client.get(/api/products, paramsparams, headersself.headers) task(1) def place_order(self): 下单低频但关键 product_id random.randint(1, 1000) order_data { product_id: product_id, quantity: 1, address: 测试地址 } with self.client.post(/api/orders, jsonorder_data, headersself.headers, catch_responseTrue) as response: if response.status_code ! 200: response.failure(f下单失败: {response.text}) task(2) def view_product_detail(self): 查看商品详情 product_id random.randint(1, 1000) self.client.get(f/api/products/{product_id}, headersself.headers)5.2 Locust实战技巧技巧1分布式压测# 主节点 locust -f locustfile.py --master --hosthttp://api.example.com # 工作节点可以启动多个 locust -f locustfile.py --worker --master-host192.168.1.100技巧2自定义监控指标from locust import events events.request.add_listener def track_performance(request_type, name, response_time, response_length, exception, context, **kwargs): 自定义指标采集 if name /api/orders: # 记录下单接口性能 if response_time 1000: # 超过1秒 print(f警告下单接口慢耗时{response_time}ms)技巧3渐进式加压from locust import LoadTestShape class SpikeLoadShape(LoadTestShape): 模拟流量突增场景 stages [ {duration: 300, users: 1000, spawn_rate: 100}, # 5分钟到1000用户 {duration: 600, users: 5000, spawn_rate: 200}, # 10分钟到5000用户 {duration: 900, users: 10000, spawn_rate: 500}, # 15分钟到10000用户 ]6. 测试覆盖率不只是数字游戏很多人把覆盖率当成KPI导致出现大量“为了覆盖而覆盖”的无效测试。我见过一个项目覆盖率95%但线上事故频发——因为关键路径没测到。6.1 覆盖率配置最佳实践**.coveragerc配置文件 **[run] source my_project omit */tests/* */migrations/* */venv/* */__pycache__/* setup.py manage.py branch True # 启用分支覆盖率 [report] fail_under 80 # 覆盖率低于80%则失败 show_missing True # 显示未覆盖的行 exclude_lines pragma: no cover def __repr__ def __str__ raise NotImplementedError if __name__ .__main__.: [html] directory coverage_html # HTML报告目录 title My Project Coverage Report6.2 覆盖率陷阱与应对陷阱1覆盖率虚高# 错误只调用函数不验证功能 def test_add_user(): add_user(test, testexample.com) # 调用了但没验证结果 # 正确验证业务逻辑 def test_add_user(): result add_user(test, testexample.com) assert result[id] is not None assert result[username] test陷阱2忽略异常路径# 错误只测正常情况 def test_divide(): assert divide(10, 2) 5 # 正确测试异常情况 def test_divide(): assert divide(10, 2) 5 # 测试除数为0 with pytest.raises(ValueError, match除数不能为0): divide(10, 0)7. 9年经验总结让测试真正产生价值的7个原则**测试是设计工具不是质量保证 **如果写测试时发现代码难测说明设计有问题**速度就是生命 **测试运行超过5分钟开发人员就不想运行了**覆盖关键路径而非所有代码 **20%的代码承载80%的业务价值**测试数据要真实 **用生产数据的脱敏样本不要用随机生成的数据**集成测试要有价值 **不是为了集成而集成要验证真实的业务场景**性能测试要可重复 **每次结果应该一致否则测试就不可信**覆盖率是手段不是目的 **追求有价值的覆盖而不是数字的覆盖7.1 我的测试金字塔实际项目比例/-----------\ | E2E测试 | 5% - 验证关键用户旅程 \-----------/ /-------\ | 集成测试 | 15% - 验证服务间协作 \-------/ /-----\ |单元测试| 80% - 验证业务逻辑正确性 \-----/**单元测试 **验证算法、业务规则、边界条件**集成测试 **验证数据库操作、第三方API集成**E2E测试 **验证核心用户流程如注册-登录-下单-支付8. 互动与思考问你们三个问题评论区见你们项目现在测试覆盖率多少是真覆盖还是“数字游戏”我见过最离谱的项目为了凑覆盖率把测试代码也计入覆盖率统计...最近一次因为测试不充分导致的线上事故是什么我们的是短信服务异常导致注册失败。你们的呢如果只能选一个测试框架你选unittest还是pytest为什么别只说“因为流行”说具体的技术理由。给初学者的3个建议**从今天开始 **不要等“项目稳定了再补测试”现在就开始。哪怕只有一个测试也比没有强。**从核心业务开始 **先测试用户注册、登录、支付这些关键路径。工具类函数可以往后放。**建立持续集成 **GitHub Actions或GitLab CI配置测试自动化。每次提交都跑测试问题早发现早解决。9. 结语测试是开发者的“职业素养”写了9年代码我最大的体会是** 代码质量不是靠review出来的是靠测试保障的 **。一个没有测试的项目就像没有安全网的高空作业——今天不出事是运气好明天出事是必然的。测试不是负担是投资。今天花1小时写测试明天可能节省10小时排查bug的时间。
