Core Concept
Configuration is composed of environment, test, and scenario settings. A single test may define multiple scenarios, each using tool-specific configuration templates rendered with the Jinja2 engine.
Each test execution is created in a unique directory containing subdirectories for each scenario. These scenario directories store the generated procedural scripts required for execution.
The SG runner supports concurrent execution of multiple scenarios. In Kubernetes environments, it is recommended to execute one scenario per pod.
How to Setup Test
The system allows users to define tests composed of one or more scenarios. Each scenario represents a specific execution path and is configured independently using predefined templates.
During setup, the system automatically combines environment, test, and scenario settings to generate the required scripts. Each test run is isolated in its own execution directory, ensuring clean separation between runs and scenarios. The setup scripts combine configuration inputs and apply them to tool-specific configurations
Scenarios can be executed in parallel to create well-balanced combinations of test scenarios. When deployed in a Kubernetes environment, each scenario is typically executed in its own pod to provide better isolation, scalability, and resource management.
Key Benefits
- Clear separation between environment, test, and scenario configuration
- Isolated and reproducible test runs
- Kubernetes-friendly execution model
- Template-driven and extensible design
Based on the test configuration, procedural scripts are generated in which the appropriate settings are applied.
In addition to managing the target tool, the SG Runner is responsible for handling auxiliary processes such as packet capturing (e.g., tcpdump), log analysis, and statistics generation.
Pre-processing scripts are responsible for fetching and preparing test data, while post-processing scripts handle report generation and synchronization with external repositories.
The system also includes common procedures for health checks of the SG Runner. These checks verify that all required tools are properly installed, the node is ready to execute scenarios, and sufficient system resources are available (i.e., the node is not resource-constrained or busy).
TE Directory Structure
The test execution script is created under the /opt/sea/sg-runner/shared/runs directory using the naming convention te-<test_name>-<date_time>-
In addition, corresponding symbolic links are created under hosts/
Please see the section below for details.
How Execution Works
The execution process begins with setup scripts, followed by the execution of procedural scripts in the defined order. Detailed information for each procedure is provided in the Procedures section.
The SG Orchestrator manages individual test executions by following this workflow and continuously monitoring the execution status of each test scenario. If the SG Orchestrator is not used, the same process can be performed manually.
Procedural scripts and common SG Runner scripts are executable through a REST API interface. For end-to-end testing, the REST API can be integrated with any test automation framework. For performance testing, the use of the SG Orchestrator is strongly recommended.