如何使用jMeter对需要CSRF token验证的OData服务进行并发性能测试

Jerry Wang

发布于 2020-08-31 10:35:10

9950

发布于 2020-08-31 10:35:10

In my previous blog JMeter beginner – how to use JMeter to measure performance of OData service accessed parallelly I have demonstrate the way how to generate a large number of parallel request to a given OData service endpoint to measure the performance how this OData service implementation behaves via:

Write a Java program by yourself, using standard API HttpClientBuilder provided by JDK.
Use Open source tool JMeter

In that blog, the type of HTTP request I perform is “GET”, in that simple case no XSRF token generation and validation is necessary. Now in this blog we will deal with more complex stuff: initiate a large number of Service request creation request via HTTP post. In this case it is necessary to:

get a valid XSRF token from server
send the actual HTTP post request to server by appending the XSRF token in request header field which is got from previous step I will show two different approaches to achieve the goal.

Develop a Java Program to send HTTP post request

In the past I have once developed a ABAP program to create Opportunity via OData service. The main logic is still very clear as already explained above:

get a valid XSRF token from server
send the actual HTTP post request to server by appending the XSRF token in request header field which is got from previous step The source code of that ABAP program could be found from my blog Consume standard C4C OData service via ABAP code.

Now I just simply translate the code using Java language, and enhance it a little bit so that a given number of parallel HTTP request could be sent via separate thread to perform the Service request creation via OData service.

In my example, I send three parallel request to server and could see the average response time printed out in console.

And since in my Java code, I use “Jerry OData Ticket” plus uuid as postfix for Service Request Name:

So finally I could find the created Service Requests with given name in UI:

Use JMeter to handle with XSRF Token stuff

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.

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”:

Create a Regular Expression Extractor to parse the XSRF token from response header and stored it to a variable named “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:

(3) Create another HTTP request with type POST.

Just paste the following text to the tab “Body Data”:

--batch_1
Content-Type: multipart/mixed; boundary=changeset_1

--changeset_1
Content-Type: application/http
Content-Transfer-Encoding: binary

POST ServiceRequestCollection HTTP/1.1
Content-Length: 5000
Accept: application/json
Content-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.

(4) As the last step, create a user variable by using JMeter built-in function __Random, to create a random number between 1 ~ 100 as 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:

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: