Scripts in the LPS Tool

The LPS tool leverages YAML-based scripts to define test plans, including rounds, iterations, variables, environments, and HTTP requests. These scripts provide a flexible and human-readable way to configure load, performance, and stress tests.

Key Components of a Script

1. Name: The test plan name.
2. Variables: Global variables used in the test.
3. Environments: Environment-specific variables.
4. Rounds: Sequential test execution blocks.
5. Iterations: Test scenarios within a round.
6. HTTP Requests: Define the method, URL, headers, and payload.

Example Script Structure

name: MyTestPlan
variables:
- name: apiUrl
  value: https://api.example.com
rounds:
- name: LoadTestRound
  numberOfClients: 10
  arrivalDelay: 1000
  iterations:
  - name: GetResource
    httpRequest:
      url: ${apiUrl}/resource
      httpMethod: GET
      saveResponse: true
    mode: R
    requestCount: 100
environments:
- name: production
  variables:
  - name: apiUrl
    value: https://api.prod.example.com

Using Anchors to Reuse Objects

You can use YAML anchors (&) and aliases (*) to reuse objects like iterations or httpRequest. This approach minimizes duplication and simplifies maintaining large test plans. However, this feature has not been fully tested within the LPS tool, so its use is at your discretion.

Example: Reusing httpRequest using anchors

name: anchors
variables:
- name: url
  value: https://www.example.com?counter=$counter(0,10)
rounds:
- name: round1
  numberOfClients: 3
  arrivalDelay: 1500
  iterations:
    - name: iteration2
      httpRequest: &post
        uRL: $url
        httpMethod: post
        httpVersion: 2.0
        payload:
          type: Raw
          raw: '{"key": "value"}'
      mode: R
      requestCount: 100

# Reuse httpRequest
- name: reuseRound
  numberOfClients: 5
  arrivalDelay: 2000
  iterations:
    - name: iteration3
      httpRequest: *post
      mode: R
      requestCount: 100

Limitations

1. The LPS tool utilizes YamlDotNet for YAML serialization and deserialization. As a result, any features or syntax not supported by YamlDotNet are inherently not supported by our custom YAML serializer.
2. There is no built-in validation for variables, which means syntax errors or unresolved variables can result in runtime exceptions.
3. Field Names:
   • All field names in the YAML script must follow CamelCase conventions.
   • Using incorrect cases (e.g., snake_case or PascalCase) will cause serialization to fail.

Example of Incorrect Field Names:

httprequest: # Incorrect

Correct Field Names:

httpRequest:

Considerations

1. Mandatory Fields:
   • Certain fields (e.g., name, rounds) are required for the script to run successfully.
2. Indentation:
   • YAML scripts are indentation-sensitive. Incorrect indentation can lead to parsing errors.
3. Type Handling:
   • All fields in the YAML script are treated as strings. The tool internally resolves and converts values or the placeholders to their correct data types based on their context and usage.

Recommended Practices

1. Validation:
   • Validate scripts using a YAML linter before execution.
2. Comments:
   • You may add comments for clarity and maintainability.

# Define variables
variables:
- name: apiUrl
  value: https://api.example.com

This document emphasizes the importance of adhering to YAML syntax and CamelCase conventions to ensure the LPS tool processes the scripts correctly.