# Testing Performance Tester

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

- Skill: `chendongqi/testing-performance-tester` (Agent Skill)
- Install (CLI): `npx skillmds@latest add chendongqi/testing-performance-tester`
- Raw SKILL.md: https://api.skillmd.com/api/skills/chendongqi/testing-performance-tester/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Integrations & APIs
- Author: chendongqi (https://skillmd.com/u/chendongqi)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/chendongqi/testing-performance-tester

---


# 性能测试助手

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

## 核心工作流程

### 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脚本示例：**
```javascript
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脚本示例：**
```python
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 | 异步化、调整线程数 |

**数据库性能分析：**
```sql
-- 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统计
```

## 输出模板

### 性能测试方案
```markdown
# 性能测试方案

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

## 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. 交付物
- 性能测试报告
- 监控数据
- 优化建议
```

### 性能测试报告
```markdown
# 性能测试报告

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

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

### 关键指标
| 指标 | 目标 | 实际 | 状态 |
|------|------|------|------|
| 平均响应时间 | <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. 引入消息队列异步处理

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

### 容量规划报告
```markdown
# 容量规划报告

## 当前状态
### 系统配置
| 组件 | 当前配置 | 资源利用率 |
|------|----------|------------|
| 应用服务器 | 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/月 |
```

## 最佳实践

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