Your privacy is important to us. We will never share your data.
Thank you!
Your message is highly valuable for us. One of our experts will follow up with you within 1-2 business days to discuss your request or to inquire for additional information if needed.
In the meantime, you might be interested in learning more about the following:
Our Blog
Check out new ideas and best practices for the IT world. Read more >
* Required fields
Your privacy is important to us. We will never share your data.
Thank you!
Dear %name%,
Thank you for your interest in our vacancies. You will receive weekly notifications based on your career preferences. We are looking forward to getting in touch with you.
Best regards, Recruiting Team
* Required fields
Your privacy is important to us. We will never share your data.
Thank you!
You are now subscribed to Infopulse Newsletter. Please look out for our email occasionally (and don’t forget to check your junk folder).
In the meantime, you might be interested in the following:
When writing the first tests with Locust, I faced the need to get an authorization token on one server and then use it on the second one for performance testing. Here immediately arose the question — of how to do it, because the instrument is tuned to send all the requests to one resource, which we define in the console starting the test. There are several variants to solve the problem:
to disable authorization on the tested resource — if there is such a possibility;
to generate a token in advance and insert it into the text code before launch; it’s the worst variant, which demands manual work at each launch, but has the right to exist in several rare cases;
to send a request using library requests and receive a token in the response — luckily, the syntax is similar.
I have chosen the third variant. An example from the first article, which describes different possibilities of obtaining a token, is given below. The authorization server is google.com and, since there is no token, I will receive the simplest values:
from locust import HttpLocust, TaskSet, task
import requests
class UserBehavior(TaskSet):
def on_start(self):
response = requests.post("http://mysite.sample.com/login", {"username": "ellen_key", "password": "education"})
# get "token" from response header
self.client.headers.update({'Authorization': response.headers.get('Date')})
# get "token" from response cookies
self.client.cookies.set('Authorization', response.cookies.get('NID'))
# get "token" from response body
self.client.headers.update({'Authorization': str(response.content.decode().find('google'))})
As it’s clear from the example, before a work task begins, a user sends a request to an external server and processes an answer, placing the data to headers or cookies.
Headers
When working on the request headers, it is necessary to take into account several important details. For each particular request, it is possible to set its own headers in the following way:
Running the mentioned example, the hello header key will be added to already existing headers of a client’s session, but in this request only — in all subsequent requests it will be absent. To make the header permanent, you can add it into a session:
One more interesting finding is that if we mention a header, which already exists in the session in a request, it will be rewritten, but only for this request. So, don’t be afraid of erasing something important.
But there are some exceptions. If we need to send a multipart form, the request will automatically form a header Content-Type, where a form data divider will be indicated. But if we forcibly re-write the header with the headers argument, then the request will crush, because the form will not be able to be processed correctly.
Also, it is worth drawing attention to the fact that all the headers are strings in all cases. Trying to submit an integer, for example {‘aaa’: 123} the request will not be sent and the code will return exception InvalidHeader.
Distributed testing
For distributed testing, locust gives several CLI arguments: –master and –slave, for strict roles determination. With this, the machine with master will not simulate loading, but only gather statistics and coordinate the work. Let’s try to launch test server and several sessions in distributed mode executing commands in different consoles:
Opening the locust in a browser ( ), you can see that in the right upper corner we have the number of machines that will perform the loading.
Testing without UI
When all the tests are written and debugged, it is a good idea to include them in the regress automatic testing and simply periodically check results. With the following command, you can launch the locust test without UI:
–no-web — is an argument allowing to launch tests without UI
-c 10 — maximum number of users
-r 2 — users increase per second
–run-time 1m — test execution time (1 minute)
–csv=test_result — after the test execution in the current folder 2 csv files with results will be created and their names will begin with test_result.
Final facts, findings, and conclusions
Distributed testing can be combined with regression testing — to guarantee that all the nodes for loading are started, you can add the argument –expect-slaves=2 on the master’s; in this case the test will begin only when at least 2 nodes are launched.
Several times, I have faced the situation when the tested resource worked with HTTPS only; at the same, time the certificate was generated by a customer and an operating system marked it as suspicious. To make tests work successfully it is possible to add an argument ignoring the safety check to all the requests, for instance:
self.client.get("/posts", verify=False)
To hide multiple warnings about unsecure connection just add next lines in the locustfile start lines:
import urllib3
urllib3.disable_warnings()
Because I am not always sure in what environment the tests will be launched, I always mention this argument/moment.
That is all I wanted to share regarding performance testing with Locust, a simple and convenient tool with wide capabilities for testing and variability for creating requests and processing answers of the server. Thank you for reading it to the end.
About the Author
Oleksii Ostapov
Software Test Lead
Oleksii Ostapov is a software testing professional with 10 years of experience in the field. He contributed to a variety of complex projects, including Security, Telecommunication, and Finance. Oleksii is an accomplished expert having earned such international certifications as ISTQB Advanced Test Manager, ISTQB Advanced Technical Test Analyst, and ISTQB Foundation. He also conducts a QA course at one of the biggest Ukrainian universities, participates as a speaker on QA conferences, and has published a series of articles on software testing.
Originally published August 01, 2019 Updated October 22, 2020