Regardless of the tools for Load Testing, you are creating, it is always important to ensure the quality of the product by making a battery of tests before placing it on the market. When it comes to software development, some metrics are essential to make clear to everyone involved in the project, which could include its users and how reliable a particular system/application is to support public use.
Within the area of software quality, several types of tests aim to achieve the objective mentioned above. This is to show everyone that the product is stable and robust. Some of these tests are integration tests, unit tests, penetration tests and regression tests.
Load testing a website
A load test focuses on testing the performance of the requests to your backend. The two most fundamental aspects to analyze are the server response time and the number of returned errors.
For example, a load test simulating hundreds of concurrent users could validate that:
- Your server doesn’t respond with errors.
- The response time for 95% of your users should be below 400ms.
- The response time of your images must always be below 600ms.
Below, some common recommendations that you could consider when load testing a website:
- Decide what to test first
- Calculate the number of concurrent users
- Load test your website in pre-production
- Start recording your user journey
- Do not include third-party requests
- Do not include your CDN assets
- Parsing HTML content
- Tag different types of resources
- Group the different webpages
Some open source tools for load testing are:
Let’s look at the load testing tools with example
- Downloading a series of large files from the internet.
- Running multiple applications on a computer or server simultaneously.
- Assigning many jobs to a printer in a queue.
- Subjecting a server to a large amount of traffic.
- Writing and reading data to and from a hard disk continuously.
The objectives of tools for load testing
This blog aims to talk a little about the tools for load testing; the one we create in essence to simulate different amounts of the attempt to access a given system or device and to have as output a report of how the software behaved in a given scenario.
When we talk about APIs and infrastructure escalation, it’s interesting to know the exact number of requests that the server (or servers) can respond correctly at an acceptable time for its clients. In case you’ve ever tried to do something like that, you’ve probably come across JMeter. JMeter is one of the most famous and complete tools for this kind of work.
However, the learning curve with JMeter is a bit long, as there are many settings/options that the user ends up getting lost at the beginning until they find what they need for their case. In an attempt to make this load testing process a little more user-friendly, Artillery, a tool that with a few steps allows you to simulate various types of scenarios for testing services. They are used for HTTP communication and/or web sockets.
You need to have the node and npm installed to be able to start the game
To install Artillery:
npm install -g artillery
To test your installation:
If a dinosaur has appeared in your terminal, it’s all right and you can move on.
To start running your load tests, you need to create a configuration file. You can give it any name, but for this article, I’ll create one called artillery.yml.
In this, you will put all the information about your API, such as endpoints, routes, and scenarios.
You can both test isolated routes/features, and more complex scenarios, such as a purchase process in e-commerce which would have one route to search for products, another for checkout, and another for payment.
Below is an example of this file:
In the file above, we put the endpoint of our API, the duration attribute represents the duration of this test cycle in seconds, and the arrival rate is the number of new users per second.
To run the test, run the following command:
artillery run artillery.yml
After execution, we have the following result:
All-time metrics are in Millis, RPS (request per second), codes are HTTP codes, and the number of responses with the same, in the case above.
We had 1200 (60×20, as we configured) requests in 60 seconds, and all returned 200. Scenarios launched are the ‘virtual users’ created and Completed Scenarios are how many of them have managed to run the scenario successfully.
Important: While the test is running, a preview of the result is being printed on the terminal every 10 seconds, but only at the end do you have the consolidated numbers of the full test.
Load Testing Soapui
SoapUI is an open-source desktop application first released in 2005.
It is focused on API Quality Assurance and is used for functional and load testing of REST and SOAP-based Web Services over HTTP. Let’s look at features:
- Functional API testing,
- Web Service simulation,
- Security QA,
- and Load Testing.
SoapUI also supports many protocols and application types:
- SOAP/REST Web Services over HTTP/HTTPS,
- JDBC database connections,
- AMF (Adobes ActionScript Messaging Format used by Flash/Flex applications),
- and OAuth 1 & 2 authentications.
But don’t be fooled by its name, SoapUI not only supports SOAP but also REST, JMS, AMF, as well as make any HTTP(S) and JDBC calls.
Its basic version is a free open source application. But a commercial edition that offers automation and productivity improvements, called SoapUI NG Pro, is also available. Both versions are primarily developed by SmartBear Software. The SoapUI documentation is also well made. It includes several tutorials that are great to get started. You may find SoapUI’s blog handy during your API testing journey as well as Ole Lensmar’s blog (creator of SoapUI).
Now you can go on changing competing user numbers, amount of test time, new scenarios, simulating more complex flows, and so on.