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 Paths 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 a nested property: ${content.array[0].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}

CSV Property Access

  • Access CSV item: ${content[0,0]}
  • Access using a placeholder as index: ${content[$index,$index]}

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 Powerful 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}

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>}

Available Metrics

1. Duration (Response Time)

Fields

  • SumResponseTime — total accumulated response time (ms)
  • AverageResponseTime — average response time (ms)
  • MinResponseTime — minimum observed response time (ms)
  • MaxResponseTime — maximum observed response time (ms)
  • P90ResponseTime — 90th percentile response time (ms)
  • P50ResponseTime — 50th percentile (median) response time (ms)
  • P10ResponseTime — 10th percentile response time (ms)

Example

${Metrics.R1.GetUsers.Duration.P90ResponseTime}

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}

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)
  • TotalDataTransmissionTimeInMilliseconds — total measured duration

Example

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

4. Throughput

Fields

  • RequestsCount — total requests attempted
  • ActiveRequestsCount — requests currently in-flight
  • SuccessfulRequestCount — successful requests
  • FailedRequestsCount — failed requests
  • RequestsRate — requests/sec (over 1s window)
  • RequestsRatePerCoolDownPeriod — requests per cooldown interval (for DCB/CRB/CB modes)
  • ErrorRate — ratio of failed requests to total completed requests
  • TotalDataTransmissionTimeInMilliseconds — duration for throughput calculation

Example

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

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.