Blog

Using comparisons to identify dynamic values

  • 8 September 2023
  • 0 replies
  • 117 views
Using comparisons to identify dynamic values
Userlevel 4
Badge +2

Scripting is the cornerstone of load testing. There are many factors, methods, and testing philosophies that go into designing load test scripts. If you don’t have clean, accurate, stable designs for running your load test, you are destined to fail. This means ensuring your test runs on your application server with fresh, dynamic data every time. To do so, it’s essential to be able to identify what parameters have dynamic values in your user scripts. You will need to perform a correlation to handle the values and make them dynamic so that they are unique and different with each iteration of your script.

So, how do we identify what is dynamic in a recorded script through “comparisons”? Use a process to compare either two recorded scripts or a recorded script to a live playback. There are compelling load testing tools that have features to help with this, saving time and money. We will explore this technique using Tricentis NeoLoad.

NeoLoad’s load testing software has a powerful feature that allows you to compare two recorded scripts, or compare a recorded script with the live playback to the application server. By using this feature, you will be able to identify dynamic values within your application. This can range from common session IDs to security tokens, from unique universal identifiers (UUIDs) to transaction IDs and timestamp values, etc. Let’s take a look at using the feature with two recordings to identify something dynamic:

NeoLoad - Two recorded scripts

As you can see, when using two recorded scripts with the same transactions and requests, you can compare the request information side-by-side. In the screenshot above, we are comparing two requests. There is a cookie header with a JSESSIONID parameter. The value is highlighted in gray, which indicates that the value is different between the two. Those not highlighted are the same between the two comparisons. NeoLoad will highlight parts in green that are added to the other. From the example above, we know that the JSESSIONID value is different between the two, so it is a dynamic value each time the user performs the transaction and is linked to the user session. NeoLoad handles most cookie parameters and values, but if not, you know from this comparison that you have to manually do the correlation (extraction and replacement through regular expression).

Let’s take our next step, and focus on comparisons of a recorded script to its playback. If you believe or know a parameter value is dynamic, you can run a playback, or validation, of the script using the checkVU feature (Check User Path). This will execute the recorded script live, as is. You will then have the ability to confirm that NeoLoad is handling a dynamic parameter, checking other parameters for their dynamic makeup. Using the same example script, we will perform playback of User Path “Recording1,” reviewing the same parameter, JSESSIONID, to validate that NeoLoad is automatically handling it. Please refer to the following:

NeoLoad - Comparison between a recorded request and its playback

The above illustrates a comparison between a recorded request and its playback. The compare option will allow you to see the two requests side-by-side.

It is observed that the JSESSIONID value is gray, which means it is different between the two requests and is being dynamically handled by NeoLoad without requiring manual correlation. By selecting the “Parameters and cookies” tab in the same window . . .

NeoLoad raw content tab

. . . you can focus on just the known POST parameters of the request. This is helpful, because sometimes there are many parameters, and they are in one long cookie string, making them hard to decipher and separate. Here is the view, which is easier to understand all of the parameters:

NeoLoad - Parameters and cookies tab

It is easier to see the list of parameters and to determine those handled and dynamic vs. those that may be static (white) needing to be addressed with correlation. In the above, both parameters seem to be dynamically handled, as their values are different between the recording and the playback of the same script. No correlation between them is needed. If there were, you would only need to look for the value in a previous response.

Putting it all together

The handling of request parameter values is essential to ensure that data being sent to the application server is unique and fresh for every user iteration and session (playback). The critical piece is being able to identify what is dynamic in a recorded script. Using software like NeoLoad makes this much easier through the robust side-by-side comparison of two recorded requests from two very similar recorded scripts, or between a recorded script and playback of that same script. It goes without saying that when you have the right tool for the job, you can save significant time while generating increased accuracy of your load tests.

This post was originally published in April 2018 and was most recently updated in July 2021.


0 replies

Be the first to reply!

Reply