This article is contributed. See the original author and article here.

Whenever you run load tests on your endpoints in Azure Load Testing, there might be a situation where your endpoints require an access token. We have seen that before load testing these endpoints, most users generate an access token and store it in the Azure Key Vault. They then pass this token as a variable in the Header of the request as a bearer token to authenticate at the endpoint. But there might be a few problems with this approach: 


 



  • Sometime has elapsed between the act of storing the token in the key vault and the start of execution of the test. There can be a case where the token might expire during the test run and the request at the endpoints start throwing errors. 

  • Only one static token is stored in the key vault and is used for all the requests. When we are load testing with multiple Virtual Users, we want a situation where all users have a unique access token while making the requests, as it will mimic a real-life scenario. Currently scaling is there, but the authenticity is lost. 

  • Most access tokens have a lifetime of around 60-75 minutes on an average. When we are running load tests for longer durations (E.g.- Soak Tests), it is almost certain that the access token will get expired during the execution of the test. We would like to have some sort of control where the service intelligently identifies when a token is going to get expired, and renews it, so that the test can carry on as usual. 


 


This blog covers how you can create a JMeter Test plan, where you can implement a mechanism to generate and refresh access tokens which are unique for every user and run it at scale in Azure Load Testing. 


 


PREREQUISITES 



 


CREATING THE TEST PLAN IN THE JMETER GUI 


Suvam_Mishra_0-1717145691185.png


 



  • Test Plan 


Create a Test Plan in JMeter. Add your variables in the “User defined variable section.” If you are testing an Azure endpoint, you may need to use the GetSecret function to store the client_ID, client_secret, tenant_ID etc. Proceed to the config elements and add a HTTP Cookie Manager and HTTP Cache Manager. Make sure to select the option to clear cache and cookies on each iteration. 


 


Suvam_Mishra_2-1717145749376.png


 



  • Thread Group 


Create a Thread Group and provide the required inputs. Enable the “Start Next Thread Loop” Option. Set the Loop Count to infinite and set the test duration.


 


Suvam_Mishra_3-1717145780095.png


 


 



  • Token Loop 


Inside the Thread Group, create a Loop Controller and set the loop count to infinite. Further, inside the loop controller, add two more controllers: The transaction controller, which will generate the token and the runtime controller, which will refresh the token.


 


Suvam_Mishra_4-1717145818548.png


 


 



  • Access Token Generation 


Inside the Transaction Controller, add an HTTP Sampler and setup a POST request to the token endpoint to fetch the access token. Set “grant type” as “client credentials” and “ignore Cache” as “true”. Add a HTTP Header Manager to the sampler and add the Content-Type as “application/x-www-form-urlencoded” and set the Authorization depending upon the configuration done at the token endpoint. 


 


Suvam_Mishra_5-1717145852227.png


 



  • Access Token Extraction 


Add a JSON extractor to extract the access token and set it in a variable which will be used going forward. 


 


Suvam_Mishra_6-1717145911474.png


 


 



  • Access Token Refresh  


Proceed to the runtime controller. In the Runtime section, specify the time after which you want the token to be refreshed. Usually token lasts for 60 minutes. Make sure to include some buffer time before token expiry. You can also extract the expiry time of the token, store it in a variable and pass it here.


 


Suvam_Mishra_7-1717145947107.png


 


 



  • Target Endpoint 


Add another HTTP Sampler, this time sending a GET request to the target endpoint. In the HTTP Header Manager, set Authorization to Bearer ${token}. 


 


Add some listeners like View Results tree, Summary Report etc to analyse the results locally. Results should look something like this. 


Suvam_Mishra_8-1717145981688.png


 


Now the JMeter script is complete and can be used in Azure Load Testing to run it at scale. 


Creating and Running the Load Test 


Suvam_Mishra_9-1717146016519.png


 


 



  • Upload the JMeter Script in the Test plan tab. 


Suvam_Mishra_10-1717146016521.png


 


 



  • Configure the Secrets section under the Parameters tab. Now, we are all set to launch the test. 


 


CONCLUSION 


Now you can run your load tests for an even longer duration without having to worry about the expiry of access tokens. 


 


Try this this out and let us know if this works for you. Please use the comments section or use our feedback forum. 


 


HAPPY LOAD TESTING!! 


 


 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.