Performance testing is meanwhile a fundamental step in many software development projects. Test early and repeat often is also true for load and performance testing. It’s not a one-time shot and there are some pitfalls involved. In this post, I will outline the three most frequently used performance test varieties.
Component Speed Tests
In recent year´s software development methods have moved in the agile direction. Short release sprints are essential. Developers and test engineers automate their quality assurance and performance checks. Typically, they implement service based performance tests on the protocol level, or they simulate real browser-based performance checks to compare end-to-end response times with agreed performance boundaries.
Objectives + Repeatability + Automated interface and end-to-end performance checks + Compare response times with agreed thresholds
Load Tests
Load tests are the ideal setting when it comes to verification of non-functional requirements. One being that response times can be verified under reproducible conditions. Another on being that those tests allow verification of speed thresholds. Realistic response time measurement is essential in load test scenarios. Therefore, test engineers use headless or real browser-based user simulation for their load test settings.
Objectives + Reproducible load simulation + Verification of response time thresholds + Identify bottlenecks under production like load conditions + Realistic end-to-end test scenarios
Stress Tests + Proof scalability and stability + Simulate peak load conditions + Exact reproducibility is not relevant
Choosing the wrong type of performance test can be mission critical and put your trustworthiness at risk. I highly recommend reviewing the goal of your performance test before you start with it’s implementation.