关于 stress-testing
用于规划压力测试的技能,可探查系统容量上限、故障表现和恢复能力,适合验证高负载下系统行为的团队,并提供多种测试方法的参考指南。
主要功能
- 01分析容量上限与临界点
- 02峰值和持续负载测试指南
- 03验证自动扩缩容
- 04检查故障恢复能力
- 05负载监控与清理实践
适用场景
- 01部署前查明容量限制
- 02检查流量激增时的表现
- 03验证故障后的恢复能力
- 04规划容量和优雅降级
安装
复制下面的命令,在终端中运行。
$
npx skills add https:/ / github.com/ aj-geddes/ useful-ai-prompts --skill stress-testing安装后在 Claude Code 中输入/stress-testing确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/auto-scaling-validation.mdbreaking-point-analysis.mdjmeter-stress-test.mdk6-stress-testing.mdsoakendurance-testing.mdspike-testing.mdscripts/scaffold-tests.shtemplates/test-template.js详细介绍
压力测试
目录
概述
压力测试会让系统超出正常运行能力,以识别临界点、故障模式和恢复行为。它可以验证系统在极端条件下的稳定性,并帮助确定系统在性能下降或发生故障前的最大容量。
适用场景
- 查找系统容量上限
- 识别临界点
- 测试自动扩缩容行为
- 验证负载下的错误处理
- 测试故障后的恢复能力
- 规划容量需求
- 验证平稳降级能力
- 测试流量突增时的处理能力
快速开始
最简可运行示例:
// stress-test.js
import http from "k6/http";
import { check, sleep } from "k6";
import { Rate } from "k6/metrics";
const errorRate = new Rate("errors");
export const options = {
stages: [
// Stress testing: Progressive load increase
{ duration: "2m", target: 100 }, // Normal load
{ duration: "5m", target: 100 }, // Sustain normal
{ duration: "2m", target: 200 }, // Above normal
{ duration: "5m", target: 200 }, // Sustain above normal
{ duration: "2m", target: 300 }, // Breaking point approaching
{ duration: "5m", target: 300 }, // Sustain high load
{ duration: "2m", target: 400 }, // Beyond capacity
{ duration: "5m", target: 400 }, // System under stress
{ duration: "5m", target: 0 }, // Gradual recovery
],
thresholds: {
http_req_duration: ["p(99)<1000"], // 99% under 1s during stress
http_req_failed: ["rate<0.05"], // Allow 5% error rate under stress
errors: ["rate<0.1"],
},
// ... (see reference guides for full implementation)
参考指南
references/ 目录中的详细实现:
| 指南 | 内容 |
|---|---|
| k6 压力测试 | k6 压力测试 |
| 突增测试 | 突增测试 |
| 浸泡/耐久测试 | 浸泡/耐久测试 |
| JMeter 压力测试 | JMeter 压力测试 |
| 自动扩缩容验证 | 自动扩缩容验证 |
| 临界点分析 | 临界点分析 |
最佳实践
✅ 应该
- 在类似生产环境中进行测试
- 监控所有系统资源
- 逐步增加负载以找到上限
- 测试压力测试后的恢复能力
- 记录临界点
- 测试自动扩缩容行为
- 为平稳降级做好规划
- 监控内存泄漏
❌ 不应该
- 未采取防护措施就在生产环境中测试
- 跳过恢复测试
- 忽视警告信号(CPU、内存)
- 只测试成功场景
- 假设系统可线性扩展
- 忘记数据库容量
- 跳过对第三方依赖项的监控
- 未做好清理工作就进行测试
评论
支持 Markdown