stress-testing
Test system behavior under extreme load conditions to identify breaking points, capacity limits, and failure modes. Use for stress test, capacity testing, breaking point analysis, spike test, and system limits validation.
By aj-geddes · 479 installs
npx skills add aj-geddes/useful-ai-prompts --skill stress-testing
Source repository · Upstream listing
Stress Testing
Table of Contents
[Overview]( overview)
[When to Use]( when to use)
[Quick Start]( quick start)
[Reference Guides]( reference guides)
[Best Practices]( best practices)
Overview
Stress testing pushes systems beyond normal operating capacity to identify breaking points, failure modes, and recovery behavior. It validates system stability under extreme conditions and helps determine maximum capacity before degradation or failure.
When to Use
Finding system capacity limits
Identifying breaking points
Testing auto scaling behavior
Validating error handling under load
Testing recovery after failures
Planning capacity requirements
Verifying graceful degradation
Testing spike traffic handling
Quick Start
Minimal working example:
Reference Guides
Detailed implementations in the references/ directory:
Guide Contents
[k6 Stress Testing](references/k6 stress testing.md) k6 Stress Testing
[Spike Testing](references/spike testing.md) Spike Testing
[Soak/Endurance Testing](references/soakendurance testing.md) Soak/Endurance Testing
[JMeter Stress Test](references/jmeter stress test.md) JMeter Stress Test
[Auto Scaling Validation](references/auto scaling validation.md) Auto Scaling Validation
[Breaking Point Analysis](references/breaking point analysis.md) Breaking Point Analysis
Best Practices
✅ DO
Test in production like environment
Monitor all system resources
Gradually increase load to find limits
Test recovery after stress
Document breaking points
Test auto scaling behavior
Plan for graceful degradation
Monitor for memory leaks
❌ DON'T
Test in production without safeguards
Skip recovery testing
Ignore warning signs (CPU, memory)
Test only success scenarios
Assume linear scalability
Forget database capacity
Skip monitoring third party dependencies
Test without proper cleanup