Performance test types (load, stress, spike, soak) in Testing Fundamentals - Framework Patterns

Framework Mode - Performance test types (load, stress, spike, soak)

Folder Structure for Performance Testing Framework

performance-testing-project/
├── tests/
│   ├── load_tests/
│   │   └── load_test_scenario_1.js
│   ├── stress_tests/
│   │   └── stress_test_scenario_1.js
│   ├── spike_tests/
│   │   └── spike_test_scenario_1.js
│   └── soak_tests/
│       └── soak_test_scenario_1.js
├── scripts/
│   └── setup_environment.sh
├── reports/
│   └── latest_report.html
├── config/
│   ├── environments.json
│   └── test_config.json
├── utils/
│   ├── data_generators.js
│   └── metrics_collector.js
└── README.md

Test Framework Layers

• Test Scripts Layer: Contains test scripts for each performance test type (load, stress, spike, soak). Each script defines the test scenario and expected behavior.
• Utilities Layer: Helper functions for generating test data, collecting and processing performance metrics, and logging.
• Configuration Layer: Holds environment settings, test parameters like user load, duration, and thresholds for pass/fail criteria.
• Reporting Layer: Generates human-readable reports and dashboards from raw test results.
• Setup/Environment Layer: Scripts or tools to prepare the test environment, such as starting/stopping servers or clearing caches.

Configuration Patterns

• Environment Configurations: Use JSON or YAML files to define different environments (dev, staging, production) with URLs, credentials, and resource limits.
• Test Parameters: Define user load, ramp-up time, test duration, and thresholds in separate config files to easily adjust test intensity without code changes.
• Credentials Management: Store sensitive data securely using environment variables or encrypted files, never hard-coded in scripts.
• Browser/Client Settings: If applicable, configure client simulation parameters like browser type or network speed in config files.

Test Reporting and CI/CD Integration

• Automated Reports: Generate HTML or JSON reports summarizing key metrics like response time, error rates, throughput, and resource usage.
• Dashboard Integration: Push results to dashboards (e.g., Grafana) for real-time monitoring and historical comparison.
• CI/CD Integration: Integrate performance tests into pipelines (Jenkins, GitHub Actions) to run tests on code changes or scheduled intervals.
• Alerts: Configure alerts for threshold breaches to notify teams immediately.

Framework Design Best Practices

1. Separate Test Types: Organize tests by type (load, stress, spike, soak) for clarity and easier maintenance.
2. Parameterize Tests: Use configuration files to control test parameters, enabling flexible test runs without code edits.
3. Use Realistic Scenarios: Model user behavior and system usage patterns closely to get meaningful results.
4. Automate Reporting: Always generate clear, actionable reports to quickly understand test outcomes.
5. Integrate with CI/CD: Run performance tests regularly to catch regressions early and ensure system reliability.

Self-Check Question

Where in this folder structure would you add a new test script for a spike test scenario?

Key Result

Organize performance tests by type with clear layers for tests, utilities, config, and reporting to enable flexible, maintainable, and automated performance testing.

Practice

1. Which type of performance test checks how a system handles normal user traffic over a period?

easy

A. Load test

B. Stress test

C. Spike test

D. Soak test

Solution

1. Step 1: Understand the purpose of load testing

   Load testing measures system behavior under expected normal traffic to ensure it can handle typical user demand.

2. Step 2: Differentiate from other test types

   Stress tests push beyond normal limits, spike tests check sudden jumps, and soak tests check long-term stability, not normal traffic.

3. Final Answer:

   Load test -> Option A

4. Quick Check:

   Normal traffic = Load test [OK]

Hint: Normal user traffic means load test [OK]

Common Mistakes:

• Confusing stress test with load test
• Thinking spike test handles normal traffic
• Mixing soak test with short-term tests

2. Which of the following is the correct description of a spike test?

easy

A. Testing system reaction to sudden traffic increase

B. Testing system under gradually increasing load

C. Testing system limits by pushing beyond capacity

D. Testing system stability over a long period

Solution

1. Step 1: Define spike test

   Spike testing checks how a system reacts to sudden, sharp increases in traffic or load.

2. Step 2: Compare with other test types

   Gradual increase is load test, pushing beyond capacity is stress test, and long period stability is soak test.

3. Final Answer:

   Testing system reaction to sudden traffic increase -> Option A

4. Quick Check:

   Sudden jump = Spike test [OK]

Hint: Sudden traffic jump means spike test [OK]

Common Mistakes:

• Confusing spike test with load test
• Mixing stress test with spike test
• Thinking soak test is about sudden changes

3. Consider this scenario: A system is tested by gradually increasing users from 100 to 1000 over 30 minutes, then holding steady at 1000 users for 2 hours. Which test types are being combined?

medium

A. Load test and stress test

B. Stress test and spike test

C. Load test and soak test

D. Spike test and soak test

Solution

1. Step 1: Identify gradual increase phase

   Gradually increasing users from 100 to 1000 is typical of a load test to check normal traffic handling.

2. Step 2: Identify steady high load phase

   Holding 1000 users for 2 hours tests long-term stability, which is soak testing.

3. Final Answer:

   Load test and soak test -> Option C

4. Quick Check:

   Gradual increase + long hold = Load + Soak [OK]

Hint: Gradual rise + long hold = Load and soak tests [OK]

Common Mistakes:

• Confusing spike test with gradual increase
• Thinking stress test applies to steady load
• Mixing soak test with short duration tests

4. A tester wrote this description: 'Stress testing is done by suddenly increasing the load to check system limits.' What is wrong with this statement?

medium

A. Stress testing uses gradual load increase, not sudden

B. Stress testing checks long-term stability, not limits

C. Stress testing pushes beyond limits but not suddenly

D. Sudden load increase describes spike testing, not stress testing

Solution

1. Step 1: Understand stress testing

   Stress testing pushes the system beyond its limits to find breaking points, usually by increasing load beyond normal gradually or rapidly.

2. Step 2: Identify sudden load increase meaning

   Sudden load increase is characteristic of spike testing, which tests system reaction to abrupt changes.

3. Final Answer:

   Sudden load increase describes spike testing, not stress testing -> Option D

4. Quick Check:

   Sudden jump = Spike test, not stress test [OK]

Hint: Sudden jump means spike, not stress test [OK]

Common Mistakes:

• Mixing stress and spike test definitions
• Thinking stress test is only gradual
• Confusing soak test with stress test

5. A web app must be tested to ensure it can handle 500 users normally, survive sudden spikes to 2000 users, and remain stable under 500 users for 24 hours. Which combination of tests should be planned?

hard

A. Stress test, spike test, soak test

B. Load test, spike test, soak test

C. Load test, stress test, soak test

D. Stress test, load test, spike test

Solution

1. Step 1: Identify normal user handling test

   Testing 500 users normally is a load test to check typical performance.

2. Step 2: Identify sudden spike handling test

   Handling sudden spikes to 2000 users requires spike testing to check system reaction.

3. Step 3: Identify long-term stability test

   Remaining stable under 500 users for 24 hours is soak testing for endurance.

4. Final Answer:

   Load test, spike test, soak test -> Option B

5. Quick Check:

   Normal + sudden spike + long run = Load + Spike + Soak [OK]

Hint: Normal + spike + long run = Load, spike, soak tests [OK]

Common Mistakes:

• Replacing spike test with stress test incorrectly
• Confusing soak test with stress test
• Ignoring long-term stability requirement