testing-performance-tester

name	testing-performance-tester
description	性能测试助手 - 专业的软件性能测试与优化专家。适用场景： (1) 性能测试方案设计（负载测试/压力测试/稳定性测试） (2) 性能基准设定与SLA定义 (3) 性能测试脚本编写（JMeter/Locust/k6） (4) 性能瓶颈定位与根因分析 (5) 性能监控指标设计（响应时间/吞吐量/资源利用率） (6) 性能测试报告与优化建议 (7) 容量规划与扩展性评估 (8) 数据库/API/前端性能分析 触发关键词：性能测试、负载测试、压力测试、JMeter、Locust、k6、响应时间、吞吐量、TPS、QPS、并发、性能瓶颈、容量规划

性能测试助手

专业的软件性能测试与优化专家，帮助确保系统在各种负载下稳定运行。

核心工作流程

1. 性能测试类型

测试类型与目的：

测试类型	目的	场景	关注指标
基准测试	建立性能基线	单用户/空载	响应时间
负载测试	验证预期负载	正常业务量	吞吐量、响应时间
压力测试	发现系统极限	超出预期负载	崩溃点、恢复能力
稳定性测试	长时间运行稳定	持续中等负载	内存泄漏、资源消耗
峰值测试	突发流量处理	瞬间高并发	峰值承受能力
容量测试	扩展性评估	逐步增加负载	资源利用率拐点

测试选择决策：

性能测试选择
├── 新系统上线
│   ├── 基准测试：建立性能基线
│   ├── 负载测试：验证设计容量
│   └── 稳定性测试：长时间运行
├── 版本发布
│   ├── 回归测试：对比历史基线
│   └── 负载测试：验证性能无劣化
├── 容量规划
│   ├── 容量测试：确定资源配置
│   └── 扩展测试：验证扩展方案
└── 故障排查
    ├── 压力测试：复现问题
    └── 瓶颈分析：定位根因

2. 性能指标体系

核心指标：

响应时间指标
├── 平均响应时间（Avg）：整体表现
├── 中位数（P50）：典型用户体验
├── 90分位（P90）：90%用户体验
├── 99分位（P99）：长尾用户体验
└── 最大响应时间（Max）：极端情况

吞吐量指标
├── TPS：每秒事务数（Transaction Per Second）
├── QPS：每秒查询数（Query Per Second）
├── RPS：每秒请求数（Request Per Second）
└── 并发用户数：同时在线用户

资源指标
├── CPU使用率：<70%为健康
├── 内存使用率：<80%为健康
├── 磁盘I/O：读写等待时间
├── 网络带宽：吞吐量和延迟
└── 连接池使用率：数据库/HTTP连接

SLA定义模板：

指标	目标值	可接受值	告警阈值
平均响应时间	<200ms	<500ms	>1000ms
P99响应时间	<1s	<2s	>5s
TPS	>1000	>500	<200
错误率	<0.1%	<1%	>5%
可用性	99.9%	99%	<95%

3. 性能测试工具

主流工具对比：

工具	语言	适用场景	优势	劣势
JMeter	Java	综合测试	功能全面、GUI	资源消耗高
Locust	Python	API测试	代码驱动、分布式	无GUI
k6	JavaScript	云原生测试	轻量、CI友好	协议支持少
Gatling	Scala	大规模测试	高性能、报告美观	学习曲线
wrk	C	HTTP基准	极高性能	功能简单
Artillery	JavaScript	API/WebSocket	易用、YAML配置	功能有限

工具选择：

场景 → 推荐工具
├── API接口测试 → k6 / Locust
├── Web应用综合 → JMeter / Gatling
├── 简单基准测试 → wrk / ab
├── CI/CD集成 → k6 / Artillery
└── 分布式大规模 → Locust / Gatling

4. 测试脚本编写

k6脚本示例：

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Rate } from 'k6/metrics';

// 自定义指标
const errorRate = new Rate('errors');

// 测试配置
export const options = {
  stages: [
    { duration: '1m', target: 50 },   // 预热
    { duration: '3m', target: 100 },  // 负载
    { duration: '1m', target: 200 },  // 峰值
    { duration: '1m', target: 0 },    // 降载
  ],
  thresholds: {
    http_req_duration: ['p(95)<500'],  // 95%请求<500ms
    errors: ['rate<0.01'],              // 错误率<1%
  },
};

// 测试场景
export default function() {
  // 登录
  const loginRes = http.post('https://api.example.com/login', {
    username: 'testuser',
    password: 'testpass',
  });

  check(loginRes, {
    'login successful': (r) => r.status === 200,
    'has token': (r) => r.json('token') !== undefined,
  }) || errorRate.add(1);

  const token = loginRes.json('token');

  // 获取数据
  const params = {
    headers: { 'Authorization': `Bearer ${token}` },
  };

  const dataRes = http.get('https://api.example.com/data', params);

  check(dataRes, {
    'data retrieved': (r) => r.status === 200,
    'response time OK': (r) => r.timings.duration < 500,
  }) || errorRate.add(1);

  sleep(1);  // 思考时间
}

Locust脚本示例：

from locust import HttpUser, task, between
import json

class APIUser(HttpUser):
    wait_time = between(1, 3)  # 思考时间1-3秒
    token = None

    def on_start(self):
        """登录获取Token"""
        response = self.client.post("/login", json={
            "username": "testuser",
            "password": "testpass"
        })
        if response.status_code == 200:
            self.token = response.json().get("token")

    @task(3)  # 权重3
    def get_data(self):
        """获取数据"""
        headers = {"Authorization": f"Bearer {self.token}"}
        with self.client.get("/api/data", headers=headers, catch_response=True) as response:
            if response.status_code == 200:
                response.success()
            else:
                response.failure(f"Failed with {response.status_code}")

    @task(1)  # 权重1
    def create_item(self):
        """创建数据"""
        headers = {
            "Authorization": f"Bearer {self.token}",
            "Content-Type": "application/json"
        }
        payload = {"name": "test_item", "value": 100}
        self.client.post("/api/items", headers=headers, json=payload)

JMeter配置要点：

JMeter测试计划结构
├── 线程组
│   ├── 线程数：并发用户数
│   ├── Ramp-Up：启动时间
│   └── 循环次数：-1为持续运行
├── 配置元件
│   ├── HTTP请求默认值
│   ├── CSV数据文件
│   └── HTTP Header管理器
├── 取样器
│   ├── HTTP请求
│   └── JDBC请求
├── 断言
│   ├── 响应断言
│   └── JSON断言
└── 监听器
    ├── 聚合报告
    ├── 响应时间图
    └── TPS图

5. 性能瓶颈分析

瓶颈定位流程：

性能瓶颈分析
├── 1. 现象收集
│   ├── 响应时间突增
│   ├── 吞吐量下降
│   └── 错误率上升
├── 2. 资源检查
│   ├── CPU：是否满载
│   ├── 内存：是否耗尽
│   ├── 磁盘：是否I/O等待
│   └── 网络：是否带宽瓶颈
├── 3. 应用层分析
│   ├── 慢查询日志
│   ├── 应用日志
│   ├── APM追踪
│   └── 线程分析
└── 4. 定位根因
    ├── 代码问题
    ├── 配置问题
    ├── 架构问题
    └── 资源不足

常见瓶颈与解决：

瓶颈类型	症状	诊断方法	解决方案
CPU瓶颈	CPU>90%持续	top/htop	优化算法、水平扩展
内存瓶颈	OOM、频繁GC	jstat、堆分析	内存泄漏修复、增加内存
数据库瓶颈	慢查询、锁等待	慢查询日志、explain	索引优化、读写分离
连接池耗尽	连接等待超时	连接池监控	调整池大小、优化SQL
网络瓶颈	延迟高、丢包	ping、traceroute	带宽升级、CDN
线程池满	任务排队	线程dump	异步化、调整线程数

数据库性能分析：

-- MySQL慢查询分析
SHOW VARIABLES LIKE 'slow_query_log%';
SHOW VARIABLES LIKE 'long_query_time';

-- 执行计划分析
EXPLAIN ANALYZE SELECT * FROM orders WHERE user_id = 123;

-- 索引使用情况
SHOW INDEX FROM orders;

-- 连接数监控
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Max_used_connections';

-- 锁等待分析
SELECT * FROM information_schema.innodb_lock_waits;

6. 性能监控

监控指标体系：

监控层级
├── 基础设施层
│   ├── CPU/内存/磁盘/网络
│   └── 工具：Prometheus Node Exporter
├── 中间件层
│   ├── Nginx：连接数、请求率、响应时间
│   ├── Redis：命中率、内存、连接数
│   └── MySQL：QPS、慢查询、连接数
├── 应用层
│   ├── JVM：GC、堆内存、线程
│   └── 应用指标：TPS、响应时间、错误率
└── 业务层
    ├── 核心接口监控
    └── 业务成功率

Grafana仪表盘要素：

性能监控Dashboard
├── 概览
│   ├── 请求速率
│   ├── 平均响应时间
│   ├── 错误率
│   └── 活跃连接数
├── 响应时间
│   ├── 时间序列图
│   ├── 分位数（P50/P90/P99）
│   └── 按接口分组
├── 吞吐量
│   ├── TPS趋势
│   ├── 按接口分布
│   └── 成功/失败比例
└── 资源
    ├── CPU使用率
    ├── 内存使用率
    ├── 连接池使用率
    └── GC统计

输出模板

性能测试方案

# 性能测试方案

## 项目信息
| 项目 | 内容 |
|------|------|
| 项目名称 | |
| 测试版本 | |
| 编写人 | |
| 日期 | |

## 1. 测试目标
### 1.1 业务目标
- 预期并发用户数：XXX
- 预期日交易量：XXX
- 目标响应时间：<XXXms

### 1.2 性能指标
| 指标 | 目标值 | 可接受值 |
|------|--------|----------|
| 平均响应时间 | <200ms | <500ms |
| P99响应时间 | <1s | <2s |
| TPS | >1000 | >500 |
| 错误率 | <0.1% | <1% |
| CPU使用率 | <70% | <85% |

## 2. 测试范围
### 2.1 测试场景
| 场景 | 接口 | 占比 | 并发数 |
|------|------|------|--------|
| 登录 | /login | 10% | 100 |
| 查询 | /api/data | 60% | 600 |
| 创建 | /api/create | 20% | 200 |
| 其他 | - | 10% | 100 |

### 2.2 测试类型
- [x] 负载测试：验证1000并发
- [x] 压力测试：确定系统极限
- [x] 稳定性测试：持续8小时
- [ ] 峰值测试

## 3. 测试环境
### 3.1 服务器配置
| 角色 | 配置 | 数量 |
|------|------|------|
| 应用服务器 | 8C16G | 2 |
| 数据库 | 16C64G | 1 |
| 缓存 | 4C8G | 1 |

### 3.2 测试工具
- 负载工具：k6 / JMeter
- 监控工具：Prometheus + Grafana
- APM：SkyWalking

## 4. 测试设计
### 4.1 负载模型

用户数 1000 | ________ | /
500 | / _ | /
0 |/
0 5 10 15 20 25 min 预热 稳定负载 降载

### 4.2 数据准备
- 用户数据：10000条
- 业务数据：100万条
- 数据脱敏：是

## 5. 执行计划
| 阶段 | 内容 | 时间 |
|------|------|------|
| 准备 | 环境/脚本/数据 | X天 |
| 基准 | 单用户基准测试 | 1天 |
| 负载 | 多轮负载测试 | 2天 |
| 压力 | 极限测试 | 1天 |
| 稳定 | 8小时稳定性 | 1天 |

## 6. 交付物
- 性能测试报告
- 监控数据
- 优化建议

性能测试报告

# 性能测试报告

## 报告信息
| 项目 | 内容 |
|------|------|
| 项目名称 | |
| 测试版本 | |
| 测试周期 | |
| 报告日期 | |
| 测试人员 | |

## 执行摘要
### 总体结论
🟢 通过 / 🟡 有条件通过 / 🔴 未通过

### 关键指标
| 指标 | 目标 | 实际 | 状态 |
|------|------|------|------|
| 平均响应时间 | <200ms | 180ms | ✅ |
| P99响应时间 | <1s | 850ms | ✅ |
| TPS | >1000 | 1200 | ✅ |
| 错误率 | <0.1% | 0.05% | ✅ |

### 主要发现
1. [关键发现1]
2. [关键发现2]

## 测试环境
### 硬件配置
| 服务器 | 配置 | 数量 |
|--------|------|------|

### 软件版本
| 组件 | 版本 |
|------|------|

## 测试结果

### 负载测试
#### 测试场景
- 并发用户：1000
- 持续时间：30分钟
- 总请求数：XXX

#### 结果数据
| 接口 | 请求数 | 平均RT | P95 | P99 | 错误率 |
|------|--------|--------|-----|-----|--------|
| /login | 10000 | 150ms | 280ms | 450ms | 0.01% |
| /api/data | 60000 | 120ms | 200ms | 380ms | 0.02% |

#### 响应时间趋势
[插入图表：时间-响应时间]

#### TPS趋势
[插入图表：时间-TPS]

### 压力测试
#### 系统极限
- 最大并发：1500用户
- 崩溃点：2000用户时响应超时

#### 资源使用
| 资源 | 正常负载 | 极限负载 |
|------|----------|----------|
| CPU | 65% | 95% |
| 内存 | 70% | 88% |

### 稳定性测试
- 测试时长：8小时
- 平均TPS：1100
- 内存增长：无明显泄漏

## 瓶颈分析
### 发现的瓶颈
1. **数据库连接池**
   - 现象：高并发时连接等待
   - 原因：连接池配置过小
   - 建议：从50增加到100

2. **慢SQL**
   - 现象：部分查询>500ms
   - 原因：缺少索引
   - 建议：添加复合索引

## 优化建议

### 紧急优化
1. 增加数据库连接池大小
2. 优化慢SQL添加索引

### 建议优化
1. 引入Redis缓存热点数据
2. 考虑读写分离

### 长期规划
1. 服务拆分微服务化
2. 引入消息队列异步处理

## 附录
- 详细测试数据
- 监控截图
- 脚本代码

容量规划报告

# 容量规划报告

## 当前状态
### 系统配置
| 组件 | 当前配置 | 资源利用率 |
|------|----------|------------|
| 应用服务器 | 2 × 8C16G | CPU 60% |
| 数据库 | 1 × 16C64G | CPU 45% |

### 性能基线
| 指标 | 当前值 |
|------|--------|
| 日均TPS | 500 |
| 峰值TPS | 1000 |
| 平均响应时间 | 180ms |

## 业务增长预测
| 时间 | 业务量增长 | 预期TPS |
|------|------------|---------|
| 3个月 | 50% | 750 |
| 6个月 | 100% | 1000 |
| 12个月 | 200% | 1500 |

## 容量评估
### 瓶颈分析
- CPU瓶颈点：1200 TPS
- 数据库瓶颈点：1500 TPS
- 网络瓶颈点：2000 TPS

### 扩容建议
| 时间节点 | 扩容措施 | 成本估算 |
|----------|----------|----------|
| 3个月 | 增加1台应用服务器 | ¥XXX/月 |
| 6个月 | 数据库升级到32C128G | ¥XXX/月 |
| 12个月 | 数据库读写分离 | ¥XXX/月 |

最佳实践

• 基线先行：测试前建立性能基线，便于对比分析
• 渐进加压：逐步增加负载，观察系统响应
• 真实场景：模拟真实业务比例和用户行为
• 持续监控：测试期间全程监控系统资源
• 数据驱动：用数据说话，避免主观判断
• 迭代优化：性能优化是持续过程，非一次性工作