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
- Dynamic Value Substitution: Variables can dynamically replace parts of URLs, headers, and payloads during runtime, ensuring tests can adapt to changing data.
- Support for External Data Sources: Variables can reference external files (e.g., CSV, JSON) to inject large datasets into tests.
- Environment-Specific Variables: Variables can be scoped to specific environments (e.g., production, staging) for targeted configurations.
- 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
$placeholderNamefor 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.
${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 sentDataReceived— total bytes receivedAverageDataSent— avg bytes sent per requestAverageDataReceived— avg bytes received per requestUpstreamThroughputBps— 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 attemptedActiveRequestsCount— requests currently in-flightSuccessfulRequestCount— successful requestsFailedRequestsCount— failed requestsRequestsRate— requests/sec (over 1s window)RequestsRatePerCoolDownPeriod— requests per cooldown interval (for DCB/CRB/CB modes)ErrorRate— ratio of failed requests to total completed requestsTotalDataTransmissionTimeInMilliseconds— 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.