Shulou(Shulou.com)06/02 Report--

This article mainly introduces "how to use jMeter to construct a series of dependent concurrent requests". In daily operations, I believe many people have doubts about how to use jMeter to construct a series of dependent concurrent requests. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful to answer the doubts of "how to use jMeter to construct a series of dependent concurrent requests". Next, please follow the editor to study!

I believe that front-end development engineers are very familiar with the concept of CSRF (Cross-site request forgery) cross-site request forgery, and sometimes it is abbreviated to XSRF, which is a malicious use of the website.

Although it sounds like cross-site scripting (XSS), it is very different from XSS, where XSS leverages trusted users within the site, while CSRF leverages trusted sites through requests disguised as trusted users.

There are many ways to defend against CSRF attacks, and one of the simplest and easiest ways to implement is to put information that the attacker cannot forge in the requests made by the client to the server, and the information is not stored in cookie. Technically, before the client initiates a request to the server to perform some sensitive operations (such as transfer, deduction and other functions realized by HTTP post), the server randomly generates a token and returns it to the client. The next operation of the client must take the token issued by the server with it in the form of parameters in the HTTP request. At the same time, the server side not only assigns token to the client, but also adds a token verification mechanism. If there is no token in the request or the token content is incorrect, the request is rejected as a possible CSRF attack. This token is commonly referred to as CSRF token.

I have talked so much in order to introduce the topic that this article wants to discuss. Suppose I want to test the performance of an OOdata service creating Service Ticket with jMeter. Because the creation function is not like a read operation, it will have a persistent effect on the system (Persistence side-effect) after execution, so the server-side implementation adds CSRF token verification. That is to say, if we directly use jMeter to construct concurrent HTTP post requests, there is no way to complete the test, because these requests do not contain CSRF token, they will be rejected by the server directly.

According to the CSRF attack and defense principle described earlier, CSRF token is randomly generated on the server side, and the client cannot forge it with any technology, because in order to test the interface HTTP post operation for Service Ticket creation, we must construct a pre-HTTP GET request to get the CSRF token returned by the server, and then construct a real HTTP POST request for performance testing. Append the CSRF token obtained by the first step GET request to the header of the POST request.

This article describes how to maintain and configure this set of requests with dependencies in jMeter.

Of course, if you don't like using jMeter, you can write your own code to implement it. You can refer to the Java code implementation I put on github.

The advantage of using jMeter is that it does not require programming, and this performance testing requirement can be achieved through simple configuration, which can generally be done independently by testers without development background.

First let us have a look how JMeter could archive the same without even one line of programming.

My project in JMeter is displayed with the following hierarchy. I have configured with "Number of 5 threads" in my thread group, so once executed, the response time of these 5 threads are displayed in result table together with average response time.

As you can see from the figure below, because the HTTP GET of CSRF token must logically precede the HTTP POST request that actually needs to test performance, this actually constitutes a Transaction- transaction, so I use the Transaction Controller provided in jMeter to manage it.

Some key points for this JMeter project creation

(1) Since now one thread should cover both XSRF token fetch via HTTP get and Service request creation via HTTP post, so a transaction controller is necessary to include both request.

(2) Create the first HTTP request to fetch XSRF token. The setting could be found below: adding a http header field with name as

X-csrf-token and value as "fetch":

Add a field called x-csrf-token to the header of the HTTP GET request, and the value is assigned to fetch. In this way, the server receives the request and knows that it is a CSRF token request initiated by the client, so the server responds to the request and returns the created random CSRF token to the client through the HTTP response header field.

The next question is, after the server returns a legitimate CSRF token to the client, how does the jMeter read the token and use it for subsequent requests?

Fortunately, jMeter provides regular expression extraction, which makes it easy to extract token from the HTTP response structure.

Create a Regular Expression Extractor to parse the XSRF token from response header and stored it to a variable named "jerrycsrftoken".

The following figure constructs a jMeter regular expression extractor that works in the header field of the HTTP response, and the parsed token value is stored in the variable jerrycsrftoken.

Before you continue, please make sure that the XSRF token is correctly parsed from request header, which could be confirmed by printing it out in a debug sample:

After the request is constructed, let's try to run it once to make sure that we do see the parsed CSRF token in the variable jerrycsrftoken.

(3) Create another HTTP request with type POST.

Now that everything is ready, we can start to construct the HTTP post that we really want to do performance testing, that is, the creation request for Service Ticket.

The body of the requested message:

Just paste the following text to the tab "Body Data":

-- batch_1Content-Type: multipart/mixed Boundary=changeset_1--changeset_1Content-Type: application/httpContent-Transfer-Encoding: binaryPOST ServiceRequestCollection HTTP/1.1Content-Length: 5000Accept: application/jsonContent-Type: application/json {"ServicePriorityCode": "2", "Name": {"content": "Jerry Testing ticket creation via JMeter ${uuid}"}, ServiceRequestDescription: [{"Text": "Piston Rattling 1-Generic OData Test Create", "TypeCode": "10004"}, {"Text": "Piston Rattling 2-Generic OData Test Create" "TypeCode": "10007"}]}-changeset_1----batch_1--

In the body text I use a user-defined variable ${uuid} which we could create it in last step. And for this post request, use the XSRF token fetched from previous HTTP get request.

As mentioned earlier, the header of the POST request needs to be preceded by a legal CSRF token. Here we use the token value already obtained by the previous GET request and stored in the variable jerrycsrftoken:

I want the final description of Service Ticket generated through concurrent tests to be suffixed with random positive integers from 1 to 100, so I use a random number generator that comes with jMeter:

(4) As the last step, create a user variable by using JMeter built-in function _ Random, to create a random number between 1 ~ 100as a fragment of created Service Request description.

Now execute the Thread group, and the execution detail for these three HTTP request could be reviewed separately in tree view:

Try to run it and find that the POST operation does add the correct and legal CSRF token to the HTTP header field as we expected:

For example, the XSRF token is successfully fetched in the first request: rdPy7zNj_uKDYvQLgfQCFA==

And used as one header field in second HTTP Post request as expected:

And finally in UI we could find the created Service request with random number between 1-100 as postfix:

The Service Ticket created by five concurrent requests I constructed on UI is observed, which shows that the verification of CSRF token on the server side is successful. At the same time, it is found that the description information has random numbers, indicating that my jMeter random number generator is also correct.

At this point, the study on "how to use jMeter to construct a series of concurrent requests with dependencies" is over. I hope you can solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.