Variables in LPS Tool

The LPS Tool supports the use of variables to dynamically inject values into test configurations, making them highly customizable and adaptable. Variables can be used in various contexts, such as HTTP headers, payloads, URLs, and conditions. This flexibility allows for efficient test design and execution.

Key Features

  1. Dynamic Value Substitution: Variables can dynamically replace parts of URLs, headers, and payloads during runtime, ensuring tests can adapt to changing data.
  2. Support for External Data Sources: Variables can reference external files (e.g., CSV, JSON) to inject large datasets into tests.
  3. Environment-Specific Variables: Variables can be scoped to specific environments (e.g., production, staging) for targeted configurations.
  4. Predefined and Generated Variables: Variables can be predefined in the configuration or generated dynamically during test execution.

Placeholders

Placeholders are used to reference variables, allowing you to access the value of a variable, such as jsonData, using $jsonData.

Placeholder Syntax

  • Use $placeholderName for simple substitutions, e.g., Authorization: $auth.
  • Use ${placeholderName} when referencing items from CSV, JSON, or XML data, e.g., https://api.example.com/user/${userData[$counter(start=0, reset=49),0]}.
  • Use ${placeholderName} for substituting parts of a URL, such as the hostname or schema, e.g., ${schema}://${hostName}/path.

Resolution Behavior

All variable placeholders (e.g $authToken, $userId) will be resolved before the plan execution starts and not during execution, except for placeholders used in the following contexts:

  • URL Pathes and Query Parameters
  • HTTP Method
  • Headers
  • HTTP Version
  • Payload of type Raw

For payloads of type multipart or binary, variables will be resolved just before the actual execution of the test plan.

Warning: To Ensure proper access to subitems like csv item, json item or XML item, wrap the placeholder with curly brackets e.g ${content[$index,$index]} as in the below examples.

Types and Quoting

  • String family: String, QString, Json, QJson, Xml, QXml, Csv, QCsv
    Q* types return quoted values (useful for string comparisons when used with the skipIf iteration feature ).
  • Numeric: Int, Float, Double, Decimal
  • Boolean
  • Optional Regex validation / post-filter where applicable

Scope Precedence

  • Session variables (e.g., LoginResponse) take precedence over Global for the same name in expressions.

Variable Declaration Syntax

Variables are declared in the variables section of the YAML configuration file. Below is an example:

variables:
- name: userId
    value: 1001
- name: productList
    value: $read(path=/path/to/products.csv)
    as: csv
- name: sessionToken
    value: Bearer abc123exampleToken
    as: text

Examples of Variable Usage

JSON Property Access

Variables containing JSON data can be accessed using dot notation or array indexing. Below are examples:

  • Access a property: ${content.property}
  • Access an array element: ${content.array[0]}
  • Access an array element with arithmetic: ${content.array[0+1]}
  • Access a nested property: ${content.array[0].item}
  • Access the last array element with length: ${content.array[$length($content.array)-1].item}
  • Access deeply nested properties: ${content.object.property.subProperty}

XML Property Access

Variables containing XML data can be accessed using XPath-like syntax. Below are examples:

  • Access a property: ${content/item}
  • Access a nested property: ${content/item/subitem}
  • Access an attribute: ${content/item/@attribute}
  • Access a specific element by index: ${content/item[1]/subitem}
  • Access a specific element using arithmetic: ${content/item[1+1]/subitem}

XML indexing follows XPath semantics, so the first repeated element is [1], not [0].

CSV Property Access

  • Access CSV item: ${content[0,0]}
  • Access using a placeholder as index ${content[$index,$index]}
  • Access using arithmetic expressions ${content[0+1,1*2]}

In URLs

url: https://api.example.com/resource/${productList[0,0]}

In HTTP Headers

httpHeaders:
    X-Client-Data: ${productList[0,$envConfig.items[0].someProperty]}
    X-Round-Name: $envConfig.rounds[0].name
    Authorization: $authToken

In Payloads

payload:
    type: Raw
    raw: "[$userId,${envConfig.items[0].someProperty}] ($generateRandom() $sessionToken)"

Examples of powerfull capabilities

Referencing External Files

You can use the $read function to load external data into a variable, such as CSV or JSON files:

- name: productList
    value: $read(path=/path/to/products.csv)
    as: csv

Dynamic Concatenation

Variables can combine multiple values dynamically:

- name: concatenatedValue
    value: ${productList[0,0]}_${productList[1,0]}

Regex and Transformation

Variables can apply transformations or constraints using regex:

- name: commandCode
    value: command42
    regex: \d+

Environment-Specific Variable Scoping

Environments can define their own set of variables, allowing configurations to adapt based on the environment. For example:

environments:
- name: production ## Production Environment
    variables:
    - name: minValue
        value: 10
    - name: maxValue
        value: 500
- name: staging ## Staging Environment
    variables:
    - name: minValue
        value: 100
    - name: maxValue
        value: 1000

Example YAML Configuration

variables:
- name: userId
    value: 1001
- name: productList
    value: $read(path=/path/to/products.csv)
    as: csv
environments:
- name: production
    variables:
    - name: authSchema
        value: Bearer
    - name: sessionToken
        value: abc123exampleToken

Special Built-in Variable Types

Response Variable

When you capture an HTTP response into a variable, it automatically contains:

  • Body — typed according to as: (Json, QJson, String, QString, Xml, etc.).
  • StatusCode${MyVar.StatusCode}
  • StatusReason${MyVar.StatusReason}
  • Headers${MyVar.Headers.Content-Type} or ${MyVar.Headers.Set-Cookie[0]}

Inline Capture Example

httpRequest:
    capture:
        to: LoginResponse
        as: Json
        regex: "optional-regex"
        makeGlobal: false

After this, you may use:

${LoginResponse.Body.token}
${LoginResponse.StatusCode}
${LoginResponse.Headers.Authorization}

Captured values also support arithmetic index expressions in the body path:

${UsersResponse.Body[0+1].id}
${UsersResponse.Body[$length($UsersResponse.Body)-1].id}
${CatalogResponse.Body/items/item[1+1]/name}
${CsvResponse.Body[0+1,1]}

Accessing Metrics

All metrics are automatically captured during execution and stored under the global Metrics namespace.

They are stored as JsonString variables, which means you can navigate into their fields using dot notation.

General format:

${Metrics.<RoundName>.<IterationName>.<MetricName>.<Field>}

Practical Patterns (Recommended)

You can access metrics in two ways:

1. Direct path access

${Metrics.TerminationRound.SearchIteration.Throughput.RequestsCount}

2. Indirect path access (nested placeholder)
Use this when a variable stores the metric path and you want to resolve it dynamically.

variables:
    - name: rpsPath
        value: "Metrics.TerminationRound.SearchIteration.Throughput.RPS"
        as: string

terminationRules:
    - expression: '${${rpsPath}} > 50'

This form ${${varName}} first resolves varName to a metric path, then resolves that metric value.

Available Metrics

1. Duration (Response Time)

Duration is a nested object. Pick a timing group first, then a statistic.

Timing groups

  • TotalTime
  • TimeToFirstByte
  • WaitingTime
  • ReceivingTime
  • SendingTime
  • TCPHandshakeTime
  • SSLHandshakeTime
  • ServerTime
  • DBServerTime
  • ServerCacheTime
  • ServerAppTime

Statistics per group

  • Sum
  • Average
  • Min
  • Max
  • P50
  • P90
  • P95
  • P99

Example

${Metrics.R1.GetUsers.Duration.TotalTime.P90}
${Metrics.R1.GetUsers.Duration.TimeToFirstByte.Average}

2. Response Code

Fields

  • ResponseSummaries — list of status codes with:
    • HttpStatusCode (e.g., 200, 404)
    • HttpStatusReason (e.g., OK, NotFound)
    • Count (number of responses with this code)

Examples

${Metrics.R1.GetUsers.ResponseCode.ResponseSummaries[0].HttpStatusCode}
${Metrics.R1.GetUsers.ResponseCode.ResponseSummaries[0].Count}

Safe access for ResponseSummaries

ResponseSummaries is an array. If you access [0] directly and the array is empty, the path may not resolve as expected.

Use a guard expression before indexing:

${length(${Metrics.R1.GetUsers.ResponseCode.ResponseSummaries})} > 0 & ${Metrics.R1.GetUsers.ResponseCode.ResponseSummaries[0].Count} > 50

Example using a variable that stores the base path:

variables:
    - name: responseCodeBase
        value: "Metrics.R1.GetUsers.ResponseCode"
        as: string

terminationRules:
    - expression: '${length(${${responseCodeBase}.ResponseSummaries})} > 0 & ${${responseCodeBase}.ResponseSummaries[0].Count} > 50'

3. Data Transmission

Fields

  • DataSent — total bytes sent
  • DataReceived — total bytes received
  • AverageDataSent — avg bytes sent per request
  • AverageDataReceived — avg bytes received per request
  • UpstreamThroughputBps — upload throughput (bytes/sec)
  • DownstreamThroughputBps — download throughput (bytes/sec)
  • ThroughputBps — overall throughput (bytes/sec)
  • TimeElpased — elapsed time in milliseconds (property name kept as implemented)

Example

${Metrics.R1.UploadFile.DataTransmission.DataSent}
${Metrics.R1.UploadFile.DataTransmission.DownstreamThroughputBps}

4. Throughput

Fields

  • RequestsCount — total requests attempted
  • CurrentActiveRequests — requests currently in-flight
  • MaxConcurrentRequests — max concurrent active requests observed
  • SkippedRequestsCount — skipped requests count
  • SuccessfulRequestCount — successful requests
  • FailedRequestsCount — failed requests
  • RPS — alias of RequestsRate.Value
  • RequestsRate.Value — requests/sec (over 1s window)
  • RequestsRate.Every — rate window label
  • RPSCD — alias of RequestsRatePerCoolDownPeriod.Value
  • RequestsRatePerCoolDownPeriod — requests per cooldown interval (for DCB/CRB/CB modes)
  • RequestsRatePerCoolDownPeriod.Value — numeric cooldown-period rate
  • RequestsRatePerCoolDownPeriod.Every — cooldown-period window label
  • ErrorRate — ratio of failed requests to total completed requests
  • TimeElapsed — elapsed time in milliseconds for throughput calculation

Example

${Metrics.R1.GetUsers.Throughput.RequestsCount}
${Metrics.R1.GetUsers.Throughput.ErrorRate}
${Metrics.R1.GetUsers.Throughput.RequestsRate.Value}
${Metrics.R1.GetUsers.Throughput.RPS}
${Metrics.R1.GetUsers.Throughput.RPSCD}

Scope and Precedence

  • Session variables (per-run, e.g., LoginResponse) override global ones with the same name.
  • Global variables are shared across the test (e.g., Metrics.*).

Resolution order: Session → Global.

Label: Nested placeholder metric resolution (for example ${${rpsPath}}) and throughput shortcut access (RPS, RPSCD) are currently available in lps.3.0.5.2-Preview.