测试体系（QA / Quality Engineering）
目标：让质量前移、让缺陷止于发布之前
P0（测试基础）
├── 测试平台
├── 测试用例管理
├── 测试环境管理
P1（自动化）
├── 自动化测试（API / UI / E2E）
├── 测试数据平台
├── Mock / 虚拟服务
P2（规模化）
├── 性能 / 全链路压测
├── 缺陷管理 & 质量分析
├── 测试左移 / 右移
P3（质量工程）
├── 灰度实验 / A/B 测试
├── 质量度量 & 门禁
├── 测试资产复用
相关开源项目：
数据工厂：https://github.com/houbb/data-factory
性能压测：https://github.com/houbb/junitperf
chat
下面对 性能 / 全链路压测（Performance & End-to-End Load Testing）进行体系化、工程化、可落地的完整展开。整体目标不是“把 TPS 跑上去”，而是：
在发布前，用可控的方式暴露系统在真实负载下的瓶颈与失效模式。
一、性能 / 全链路压测的总体定位
一句话定位
性能压测是“容量与稳定性的预演系统”，而不是一次性的压测活动。
在测试体系中的角色
- 位于 P2（规模化） 的核心位置
-
承接：
- 自动化测试（功能正确）
- 测试数据平台（状态可控）
- Mock / 虚拟服务（依赖可控）
-
输出：
- 发布容量结论
- 架构瓶颈结论
- 风险清单
二、为什么一定要做“全链路”压测
单点压测 vs 全链路压测
| 维度 | 单接口 / 单服务 | 全链路压测 |
|---|---|---|
| 覆盖范围 | 局部 | 端到端 |
| 能发现的问题 | 算法 / SQL | 级联放大、雪崩 |
| 对架构的价值 | 低 | 极高 |
| 是否可替代 | 否 | 不可替代 |
现实结论
线上事故，90% 不是单点性能问题，而是链路放大效应。
三、性能 / 全链路压测的目标分层
1️⃣ 功能是否还能跑（Survivability）
- 高并发下是否功能失效
- 是否出现异常状态流转
2️⃣ 系统能扛多大（Capacity）
- 最大 TPS
- 拐点在哪里
- 限流是否生效
3️⃣ 系统如何失败（Failure Mode）
- 慢 → 堵 → 挂 的过程
- 是否有降级、熔断、隔离
四、压测能力分层模型（从浅到深）
性能 / 全链路压测
├── 接口性能压测
├── 服务级压测
├── 场景级压测
├── 全链路压测
└── 生产级压测（影子流量）
五、核心能力详解
1️⃣ 接口性能压测（基础层）
目标
- 验证单接口的性能上限
关注指标
- RT（P50 / P95 / P99）
- QPS / TPS
- 错误率
典型问题
- SQL 慢查询
- 序列化耗时
- 线程池配置不合理
2️⃣ 服务级压测（组件层）
目标
- 验证单服务在真实依赖下的表现
特点
- 多接口混合
- 真实 DB / Cache
- Mock 外部依赖
发现的问题
- 连接池耗尽
- JVM GC 抖动
- 本地资源瓶颈
3️⃣ 场景级压测（业务层）
目标
- 模拟真实用户行为
示例
登录 → 查询 → 下单 → 支付
关键点
- 不同接口比例
- 不同用户行为权重
- 并发用户数随时间变化
4️⃣ 全链路压测（系统级，核心）
什么叫“全链路”
API Gateway
→ 应用服务
→ MQ
→ 下游服务
→ DB / Cache
必须满足
- 真实链路
- 真实中间件
- 真实数据规模
能发现的典型问题
- MQ 堆积导致 RT 激增
- 下游慢导致上游线程池打满
- 一个非核心接口拖垮核心路径
5️⃣ 生产级压测（影子流量）
成熟企业的必备能力
方式
- 复制真实线上流量
- 打标识（Shadow / Test）
- 不影响真实用户
价值
- 最接近真实世界
- 发现“测试环境永远测不到的问题”
六、压测数据与依赖控制（否则结果不可信）
1️⃣ 测试数据平台配合
- 数据池（避免竞争）
- 数据隔离（tenant / tag）
- 大规模数据预置
2️⃣ Mock / 虚拟服务配合
- 屏蔽第三方依赖
- 控制异常比例
- 模拟慢服务
没有数据平台和 Mock 的压测，基本都是“假压测”。
七、性能指标体系（必须统一口径）
核心指标分类
| 类别 | 指标 |
|---|---|
| 吞吐 | TPS / QPS |
| 延迟 | P50 / P95 / P99 |
| 稳定性 | 错误率 |
| 资源 | CPU / 内存 / IO |
| 中间件 | 连接数 / 堆积 |
八、全链路压测的技术架构
1️⃣ 压测系统逻辑架构
压测平台
├── 场景编排
├── 流量发生器
├── 数据注入
├── 链路标记
├── 指标采集
└── 分析与报告
2️⃣ 可观测性强绑定（非常关键）
必须接入
- Metrics（Prometheus）
- Trace（全链路追踪）
- Logs（关键路径）
否则：
只能看到“慢了”，不知道“为什么慢”。
九、压测结果分析方法论
1️⃣ 看拐点，而不是峰值
- TPS 上升但 RT 突增的点
- 错误率开始抬头的点
2️⃣ 瓶颈定位顺序
网关 → 线程池 → DB → MQ → 下游
3️⃣ 结论必须工程化
- 当前安全容量
- 扩容后预期
- 风险清单
十、压测治理与发布联动
1️⃣ 压测作为发布门禁
- 核心链路必须通过
- 性能不能回退
- 容量必须有结论
2️⃣ 压测结果资产化
- 版本对比
- 架构演进对比
- 历史趋势
十一、成熟度分级
| 等级 | 特征 |
|---|---|
| L1 | 手工压接口 |
| L2 | 自动化压测 |
| L3 | 场景压测 |
| L4 | 全链路压测 |
| L5 | 生产影子压测 |
十二、总结一句话
性能 / 全链路压测的终极目标，不是证明系统“很快”，而是提前知道它“会在哪儿死”。
