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 years 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.

+ 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.

+ Reproducible load simulation
+ Verification of response time thresholds
+ Identify bottlenecks under production like load conditions
+ Realistic end-to-end test scenarios

Stress Tests

Consider a stress test if you have to proof reliability of your application under peak load conditions. In this type of test, you specify mainly the max number of users and the time over which the ramp up and the steady state load should be on your application. The goal is to identify the breaking points of your application under test. Often this type of inspections are not 1:1 reproducible because the simulated load varies based on the actual response time of the application under test.

+ 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.


Posted by JM

Resourceful, solution-focused and intuitive reliability engineer with over 15 years of demonstrated success in architecting, developing and maintaining effective testing and monitoring solutions. Offers a wealth of knowledge and experience surrounding modern application architecture and development of best practices.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s