一、测试策略总览：分布式系统的测试变形记
做分布式系统测试，跟做单体应用完全是两码事。
我刚开始带团队那会儿，照搬了传统测试金字塔。结果呢？上线前三天，压测一跑，全崩了。说白了，分布式系统的测试，你得重新理解「测试」这两个字。
1.1 测试金字塔的变形
传统测试金字塔长这样：底层单元测试多，中间集成测试，顶层端到端测试少。但在分布式系统里，这个金字塔得「压扁」再「拉宽」。
为什么会这样？因为分布式系统的核心问题是网络、一致性、容错。这些问题，单元测试根本测不出来。
分布式测试金字塔（我自己的版本）
- 底层：单元测试 + 合约测试（Contract Test）—— 保证单个服务逻辑正确
- 中层：集成测试 + 组件测试 —— 验证服务间交互、数据一致性
- 顶层：端到端测试 + 混沌工程 —— 模拟真实流量、网络故障、节点宕机
我个人习惯把合约测试单独拎出来。你想想看，微服务之间靠 API 通信，接口变了都不知道，那还玩什么？合约测试就是给每个接口「上锁」，谁改谁负责。
1.2 分层测试策略
分层不是分家。每一层都有它的职责，也有它的盲区。
单元测试
测什么？单个函数、单个方法、单个服务内的逻辑。比如一个订单服务的价格计算函数。
我在项目中遇到过一个问题：单元测试全绿，但上线后订单金额总差几分钱。后来发现是浮点数精度问题。单元测试能测出逻辑错误，但测不出「精度陷阱」。
我的建议：单元测试覆盖率目标 80% 以上，但别追求 100%。那 20% 往往是 UI 层或外部依赖，不值得。
集成测试
测什么？服务之间的交互。比如订单服务调用库存服务，数据库读写，消息队列收发。
集成测试最头疼的是「环境依赖」。我记得有一次，测试环境数据库连接池配得太小，压测时频繁超时。代码没问题，配置有问题。所以我现在做集成测试，一定会把配置也纳入测试范围。
# 一个简单的集成测试示例（Python + pytest）
def test_order_creation_integration():
# 启动依赖服务（用 Testcontainers）
with PostgresContainer("postgres:15") as pg:
with RedisContainer("redis:7") as redis:
# 初始化服务
order_service = OrderService(
db_url=pg.get_connection_url(),
redis_url=redis.get_connection_url()
)
# 执行测试
result = order_service.create_order(user_id=1, product_id=100, quantity=2)
assert result.status == "success"
assert result.order_id is not None
注意：集成测试不要依赖真实的外部服务。用 Testcontainers 或 Mock Server。否则你的测试会变成「环境测试」—— 测的是网络通不通，而不是代码对不对。
端到端测试
测什么？完整的用户流程。从用户下单到支付成功，再到库存扣减、物流生成。所有服务都跑起来，模拟真实用户操作。
端到端测试有个大坑：太慢、太脆弱。我曾经维护过一套端到端测试，跑一次要 40 分钟，还经常因为某个服务重启失败而全红。后来我砍掉了 70% 的端到端用例，只保留核心流程。
端到端测试的「二八原则」：
- 20% 的核心流程覆盖 80% 的用户场景
- 剩下的 80% 场景，用集成测试 + 单元测试覆盖
- 端到端测试数量控制在 10-20 个以内
1.3 测试环境规划
环境规划做不好，测试就是纸上谈兵。我见过太多团队，开发环境、测试环境、预发环境混在一起，最后上线前才发现问题。
| 环境 | 用途 | 数据 | 稳定性要求 | 典型配置 |
|---|---|---|---|---|
| 开发环境 | 开发自测、本地调试 | 伪造数据 / 脱敏数据 | 低（可以随时重启） | 单机部署、Mock 外部依赖 |
| 测试环境 | 集成测试、功能测试 | 脱敏数据 + 构造数据 | 中（允许短暂中断） | 多节点部署、Testcontainers |
| 预发环境 | 端到端测试、性能测试 | 脱敏生产数据（子集） | 高（尽量接近生产） | 与生产同配置、独立数据库 |
| 生产环境 | 线上运行、监控告警 | 真实用户数据 | 极高（7x24 可用） | 多机房、多副本、自动扩缩容 |
这里有个细节：预发环境要不要连生产数据库？我的答案是「绝对不要」。预发环境的数据应该是生产数据的脱敏子集，但数据库实例必须独立。否则一个测试用例写坏了数据，线上用户就遭殃了。
避坑指南：我曾经在预发环境里跑了一个批量删除的测试用例，结果连到了生产数据库...嗯，从那以后我强制要求所有环境的数据库连接字符串必须用环境变量注入，并且预发环境的生产数据库地址要写在黑名单里。
1.4 环境治理的「三要三不要」
- 要：环境配置代码化（用 Ansible、Terraform 管理）
- 要：环境间数据隔离（每个环境独立数据库、独立缓存）
- 要：环境可快速重建（容器化部署，一键拉起）
- 不要：开发环境直连测试数据库
- 不要：测试环境使用生产流量
- 不要：预发环境与生产环境共享任何资源
说白了，环境规划的核心就一句话：让每个环境只做它该做的事。开发环境只管写代码，测试环境只管找 bug，预发环境只管验证上线流程，生产环境只管服务用户。
做到这一点，你的测试策略就成功了一半。