Dynamic Targets

A Dynamic Target is a unique parameter or variable used by the application to generate information like a unique user ID or session ID. These values are generated by the web server and sent to the browser, which then later returns that value back to the server, so that the application can match the new request to a previous HTTP transaction. To accurately simulate users via virtual users, it is important to correctly return these Dynamic Targets during the load test execution.

Auto-detected Dynamic Targets

If Test Studio detected any possible Dynamic Targets in the HTTP traffic, a list of those targets will appear after you capture a user profile. In this screen, you can select which Dynamic Targets the load test should use while running the test by checking the box next to the name of the Dynamic Target.

Dynamic targets

In most situations, you should select all dynamic targets, unless you have a specific reason to deselect a particular dynamic target.


Each dynamic target lists four properties:

  • Target: The name of the parameter or variable from the original URL.
  • From: The step number of the response in which the target was detected.
  • To: The step number of the request in which the target will be used.
  • Original Context: The portion of the response URL containing the target.

Example Scenario: Session IDs

A typical situation using dynamic targets is load testing an application that provides a unique session ID for each user. In this scenario, the session ID dynamic target may appear in the Dynamic Targets view.

Session id

The step whose number appears in the From column will include the dynamic target in its response. Here, it appears in the headers.


The step whose number appears in the To column will include the dynamic target in its request. A special section appears in the Request tab indicating that this response is bound to a dynamic target.


Custom Dynamic Targets

Based on the HTTP traffic there might be targets which are not detected by Test Studio as dynamic but still these will be required to accomplish meaningful scenario. Or any of the auto-detected dynamic targets is not listed for transfer to a desired request.

To handle such scenarios Test Studio implemented the ability to add Custom Dynamic Targets. The Custom Dynamic Targets are available in the Choose Dynamic Targets view where all auto-detected are listed as well - once a user profile is captured or opened to be modified click the Choose Dynamic Targets button.

Choose Dynamic Targets

Once any custom targets are added to the user profile these will be displayed under the list with all auto-detected dynamic targets. To add a custom dynamic target use the Add Dynamic Target button.

Add Dynamic Targets

Source Section Properties

  • Step: Step to take the target from. Any step which contains a HTTP request can be selected. The Think time steps are filtered out and not displayed in the dropdown.
  • Response: Which part of the HTTP response to be used - Body, Headers or Cookie. Select the necessary part of the HTTP response and verify its content.
  • Content: Displays the content of the selected response part.
  • Search Type: The type of search to be used in the content of the selected response - FullText, Regex, JSON, XML. Select any of the provided options to search for the necessary value from the response.
  • Starts after/before|Regex|JSON path|XPath: Provide the search query to locate the desired value in the response.
  • Search Result: Click to show the reuslt based on the search query.
  • Current Value: Display the current reuslt based on the search query.

Source Body
Source Section Properties
Source Headers
Source Section Properties
Source Cookie
Source Section Properties

Search Options

  • FullText - use strings which surround the desired value to locate it in response.

Example: The head section of a HTTP response's body is:

<head><title>Example ASP Scripts</title></head>

To get the actual title you may use Starts after: <title> and Ends before: </title>

  • Regex - use regular expression to locate the desired value in response body, header or cookie.

Note! Test Studio uses <val> to express the first match in response!

Example: The cookie of a HTTP response is the following string and the requirement is to get the domain name value only:

_EDGE_S=SID=04D5974D8509631807D39B2484BF62E4; path=/; httponly; domain=bing.com

The only possible approach is to use the partial search using Regex. The standard regex for extracting the desired value looks like this:


This returns the following match information:

Full match  65-80   `domain=bing.com`
Group 1.    72-80   `bing.com`

Using that standard regular expression in Test Studio will return the Full match instead the value in Group 1. Therefore Test Studio uses <val> to express the first match group and the regular expression becomes:

  • JSON - use JSONPath to locate the desired value in response.

  • _XML - use XPath to locate the desired value in response.

Destination Section Properties

  • Step: Step to pass the target to. Any step that follows the selected one for source and contains a HTTP request could be selected for destination step. The Think time steps are filtered out and not displayed in the dropdown.
  • Field Type: In what part of the HTTP request to include the custom dynamic target - Query Paramater, Header, Cookie, POST data, URL.
  • Field Name: The name of the dynamic target which will be used in the HTTP request.

Destination Section Properties

Important Notes

Note! The custom dynamic value will be added to the destination HTTP request even if there is no such parameter, cookie or header existing in the recorded request.
Note! If there are both autodetected and custom dynamic values for a single destination step, the last set target will be used in the request. Disable/Enable of a dynamic target will update the order of set targets.
Note! As of now there is no visual representation for any custom dynamic targets within the Edit User Profile view. To verify if the HTTP requests are built as you expect you could use Fiddler to capture the traffic of a sample load test execution and inspect these.

In this article
Not finding the help you need? Improve this article