Table of contents
Foreword:
It is an effective method to use JMeter to test the concurrency of the approval class interface, which can simulate multiple users to perform approval operations on the interface at the same time, so as to evaluate the performance and stability of the system under high load conditions.
Background :
In the document review operation on the page, multiple transactions will be successfully submitted when the documents are operated concurrently, resulting in the problem of submitting multiple payment applications
Difficulties :
- Data is created automatically
- Interface requests need to be executed after login
- Dynamically obtain request parameters for audit documents
-
Maximize the simulation of concurrent operations and reduce the request interval
Solution ideas: -
Create data using the data throwing interface
-
Save login session using jmeter headers and cookie manager
-
Obtain the parameters required by the audit request by querying the class interface
-
The thread group adds a synchronization timer to ensure the simultaneity of the request.
The specific implementation :
- Use the data throwing interface to create data, there are the following points to note
- Randomly generate the project document number to ensure that the data can be created successfully
- Save the project document number of the created data, which is convenient for later query interface use
- When implementing login and submit operations, two scenarios were simulated
Scenario a:
Use single-user login to simulate multiple browser logins by the same user for concurrent submissions. At first, the login and submission requests were placed in the same thread group, but it was found that when the same user was used for single sign-on within a short period of time, some login errors would be reported, so the login request was placed in a separate thread group, and the submission request was placed in Another thread group, and then transfer the cookie in the login thread group to the request thread group (this method is actually simulating multiple concurrent developments of a single user in the same browser).
Since different thread groups are set for login and sending requests, cookies need to be passed between thread groups. Specifically, it is necessary to modify the jmeter.properties file, set CookieManager.save.cookies=true, take out the cookie parameters after login, and pass them to the thread that executes the audit request Group
the whole frame:
Declare the parameter as a global variable:
Stitching cookie information:
Set a synchronization timer to ensure that documents are submitted concurrently:
Scenario b:
In real scenarios, there are few concurrent operations by a single user, and there are more scenarios where multiple different users operate on the same document at the same time. To simulate such a scenario, what needs to be done is that when multi-threading, each thread uses a different user to log in and operate. The implementation here is to obtain the thread number, and then specify the login account for the thread (for example, thread 1 reads account 1, and thread 2 reads account 2). Place them in the same thread group and execute operations sequentially
the whole frame:
Get the thread ID and specify the account:
As someone who has been here, I also hope that everyone will avoid some detours
Here I will share with you some necessities of the way forward in automated testing, hoping to help you.
(WEB automated testing, app automated testing, interface automated testing, continuous integration, automated test development, big factory interview questions, resume templates, etc.)
I believe it can make you better progress!
Click on the small card below
