We do load tests in 5 minutes (well, almost)

Not long ago I shared a story about how we solved the problem of E2E autotests in a small project (see the article). Let's continue the story)
The beginning of the article is very similar, because the project and conditions are exactly the same.

Given:

A project with a small budget
Maximum possible number of testers on a project = 2
A team lead or automation engineer who has several other projects. That is, he cannot constantly write and maintain tests.

Find:

Regular stress tests
Spend the minimum amount of money/time/effort on it

Due to the low budget, we come to the conclusion that there is no possibility to hire full-fledged load testers. You can place an order with a specialized company and some other options, but we will go our own way

So, since we have already involved our manual testers in the development of automated tests, we really wanted to follow a similar path.
What can we do about this?

Choose ready-made tools and create a scenario from sequential API calls. But the tests will have to be constantly maintained, the API changes regularly. The scenario will have to be constantly changed
Train testers in the basics of developing load tests. Likewise, ongoing support for tests during any product changes
Come up with your own simple solution that will help us

What is important to us

Largely variable reading load
Tests should always be up-to-date. And if they break, updating the script takes no more than 30 minutes.
The test report should be saved in html or some other format to enable historical comparison of the system's behavior.
Updating/developing a new scenario should be available to any team member. Analyst, developer, tester, manager
Scenario prioritization. Scenarios should have a priority and be run according to that priority.

As a loading tool I have previously used Locust – a good, uncomplicated and very flexible loading tool.
Anything that can be written in Python can be loaded via Locust + Locust has script prioritization out of the box.
The only problem is that it is impossible for a person unfamiliar with code to develop test scripts on their own.

Information about the Locust tool:

What can any team member do to update the script?
Any team member can perform actions with the system in the browser, and accordingly can collect logs of “walking” through the system (har-log).
The question remains, how to turn the har-log into a script that will be eaten by Locust?
The answer was found quite quickly, you can write a script that will analyze the har log and based on it generate a scenario/scenarios

How the final solution works:

The tester collects the har-log in the system and saves it in the required location: FTP, git repository, on his PC (underline the appropriate). The file name must indicate the script weight and its name
The script takes, analyzes these har-logs and forms a load test for Locust. Here I use a completely self-written solution (I did not look for others, perhaps there are some)
Next, a load test is launched in the Jenkins assembly (previously configured once). And a report is attached there
Sending a notification to Telegram about launch, completion + you can also send a report to the chat. Convenient

I am making publicly available a version that is only suitable for user actions that are independent of each other (i.e. data is not passed between test steps)
All information on usage is available in readme.md in the project repository https://github.com/autotetst/simple.perfomance

We do 1 test locally
Let's try to do the 1st load test together on a local PC. You will see how easy it is

First, you need to install python on your local PC (python 3.10 or higher is supported). Download here https://www.python.org/downloads/ and install
Using pip install locust

For windows

pip install locust

For Linux/mac

pip3 install locust

Upload our public repository to a convenient directory

git clone https://github.com/autotetst/simple.perfomance.git

If you don't have git, you can simply download the zip archive from github and unzip it.
4. The most interesting thing is collecting the har log.

Open your application or website interface in Google Chrome.
Enable devtools (F12) and perform actions on the system that you want to add to the load scenario.
Try not to overload the script and do not make it large. There can be as many scripts in the test as you like.
Go to the network tab in your browser's devtools
Click Export HAR and save to a convenient directory
If you need another script -> delete the current requests from the network tab and we are ready to record the next one
Remember that each scenario is a separate har-log