QALIPSIS core concepts

Overview

Once you have a minimal understanding of the core concepts, you will be ready to create a QALIPSIS scenario to verify that your software is performing as expected.

The aim of QALIPSIS is to execute actions that inject load into IT systems to monitor and validate their behaviors (latency, failure rates, availability, and data consistency).

The actions are performed by minions that inject load into a system and then run through a preconfigured scenario consisting of steps and assertions. If running QALIPSIS on a distributed system, you can create clusters with Head and Factory nodes to inject higher load.

Prior to configuring QALIPSIS to run on your system, it is crucial to understand the core concepts of the tool:

  • Minions - simulations of users/devices.

  • Scenarios - sequences of actions (steps) that can be executed by minions on the test system.

  • Steps - scripts within a scenario that define specific actions to be executed on the test system.

  • Assertions - steps that compare and validate data within a scenario.

  • Nodes - distributed instances within QALIPSIS clusters.

    • Head - responsible for orchestration and reporting.

    • Factory - host minions that execute load tests and assertions.

Minions

Minions are simulations of website users, IoT devices, or other systems. They each perform a complete scenario.

Any number of minions can act on a scenario. The minion count for a scenario is set during scenario configuration (refer to Scenario specifications) or at runtime (refer to QALIPSIS configuration).

Note that a minion count entered at runtime overrides the minion count set during scenario configuration.

Scenarios

A QALIPSIS scenario is the single largest component of a load test. It contains steps with a detailed description of all the operations to accomplish, their dependencies, as well as assertions to ensure everything performs as expected.

A simple scenario configuration includes the following:

  1. Declare to the scenario function and assign it a name.

    • Mandatory

    • QALIPSIS Signature: @Scenario("scenario name")

  2. Register the scenario.

    • Mandatory

    • QALIPSIS Signature: val myScenario = scenario()

  3. Define the total # of minions to be executed.

    • Optional

    • Value: positive number

    • Default = 1; Minimum = 1

    • QALIPSIS Signature: minionsCount = xxxxx

  4. Define the execution profile.

    • Mandatory

    • QALIPSIS Signature: profile { strategy( ) }

  5. Define the tree where the load will be injected.

    • Mandatory

    • QALIPSIS Signature: start()

  6. Call the Gradle Plugin for QALIPSIS.

    • Mandatory

      plugins {
    kotlin("jvm")
    kotlin("kapt")
}

  7. Add steps to your scenario.

Steps

Steps are the central components for working with QALIPSIS and can be developed in Kotlin using the fluent API.

Steps depend on data sources, results of other steps or assertions to execute or use their data.

A step specification is configured such that:

  • The step receives the configuration closure as a parameter.

  • .configure is called after the step parameters are set.

Refer to the Steps specifications section of this manual for details.

Each step has a unique configuration depending on the purpose of the step. The step configurations all follow the same logic:

  1. Declared as a root or successor step.

  2. Provided a name.

  3. Provided with step context.

  4. Delivers output data.

Steps are configured using core operators:

  • Assertions and verifications

  • Timing

  • Conditional

  • Converting

  • Error Handling

  • Filtering

  • Joining

  • Mathematical/Aggregate

  • Transforming

  • Flow

  • User-defined

Refer to the Steps specifications section of this manual for details.

Assertions

Assertions perform checks within the scenario by:

  • Providing validation of data persistence, message exchanges, and requests to remote systems.

  • Setting and testing durations to verify the system’s overall responsiveness.

Data generated by QALIPSIS and other systems, including the system under test, can be used for all assertion checks.

Each assertion failure is logged in QALIPSIS events, enabling you to track the cause of overall campaign failures.

Additionally, QALIPSIS can generate JUnit-like reports to simplify existence with CI/CD tools.

Nodes

Nodes are distributed instances within a QALIPSIS cluster. QALIPSIS nodes are designated as either a head or a factory.

head_factory

Head

The head node within a QALIPSIS cluster is responsible for orchestration and reporting.

  • It is the direct interface for all the interactions with QALIPSIS, via a graphical UI and a REST API.

  • It supports seamless integration with external third-party tools for reporting, notifications and analysis.

  • It ensures continuous access to QALIPSIS features and data, even when there are no active factory nodes.

QALIPSIS Commercial edition supports additional responsibilities for the head node, including:

  • Improved security with OAuth2 authentication support; users are able to authenticate using their existing credentials.

  • Head node redundancy; if one node fails, a backup is available to seamlessly take over, eliminating a single point of failure and enhancing the reliability of the system.

Factory

The factory nodes of a QALIPSIS cluster are distributed components that host the minions that execute load tests and assertions.

The factories are the "working" nodes of cluster, and contains the executable version of your scenarios.

Factories have a dual role: they inject load into the system under test and retrieve records from various data sources like databases and messaging platforms.

The retrieval of records enables you to compare data both within and outside the system. Importantly, setting up additional firewall rules for data reception in the factory is not necessary. QALIPSIS plugins are designed with specialized poll and search operations, simplifying the process of external data retrieval without requiring adjustments to your existing infrastructure.

You can add factories to your cluster to expand your load capacity; the factories can be synchronized and establish communication through low-latency messaging platforms such as Redis Pub/Sub and Kafka.

Unlike the head node, which remains a consistent presence in the cluster, factories can be dynamically added or removed as needed. This approach helps minimize resource consumption during periods when no campaign is running.