17 Setting Up The STAP Environment

Learn about setting up the Oracle Communications Solution Test Automation Platform (STAP) environment in your system.

Setting Up STAP Configuration

Learn about setting up the configuration for STAP. This includes the config folder that contains the main configuration properties config.properties file. Ensure the attribute home location is set for the config.properties file. For more information on how to set the the attribute home location, see "STAP Synthetic Data Generation".

Using the configuration.properties File

The config folder contains the primary configuration file titled config.properties. This file contains the configurations required to run STAP.

The following is the setup for the configuration folder:
#-------------------------------------------------------------------------------
# STAP Environment Configuration
# Version 1.2.0
#-------------------------------------------------------------------------------
# Scenarios location
scenarios.home=${WORKSPACE}/scenarios
 
#-------------------------------------------------------------------------------
# Environment configurations location
environments.home=${WORKSPACE}/config/environments
 
#-------------------------------------------------------------------------------
# Execution configurations location
execution.Config.file=${WORKSPACE}/config/execution/execution.config.json
#-------------------------------------------------------------------------------
# Actions location
actions.home=LOAD_FROM_LIBRARY
#
#actions.home=${WORKSPACE}/actions
 
#-------------------------------------------------------------------------------
# Results storage location
#results=results
results.home=${WORKSPACE}/results
results.publish=NO
#results.publish.file=C:\software\Servers\apache-Server-1\webapps\STAPReports\reports\SE2EReports\results.js
#-------------------------------------------------------------------------------
# Context Configuration
#-------------------------------------------------------------------------------
# Context Storage Location
context.home=${WORKSPACE}/context
# Scenario Context
# Load Context for the test case
# Default NO
context.load=NO
context.save=NO
# Global Context
context.global.load=NO
context.global.save=NO
#-------------------------------------------------------------------------------
engine.configuration=${WORKSPACE}/config/engine.config.properties
#-------------------------------------------------------------------------------
 
 
 #-------------------------------------------------------------------------------
 # JMeter Configuration
 #-------------------------------------------------------------------------------
 # JMeter threads
 tools.jmeter.thread=4000
 # JMeter rampup(seconds)
 tools.jmeter.rampup=150
 # JMeter result location
 tools.jmeter.results.home=${WORKSPACE}/results/tools/jmeter
  
 #-------------------------------------------------------------------------------
 # Plugin Configuration : INTERNAL
 # List of Supported Plugins : REST,SOAP,SSH,Kafka
 #-------------------------------------------------------------------------------
 plugin.internal=REST,SOAP,SSH,Kafka
 #-------------------------------------------------------------------------------
 # Plugin Configuration : CUSTOM
 # Provide plugin configuration in config/plugin folder
 #-------------------------------------------------------------------------------
 #plugin.custom=
  
 #-------------------------------------------------------------------------------
 # Attribute Home
 # Provide location to load attribute data
 #-------------------------------------------------------------------------------
 attributeData.home=${WORKSPACE}/config/attributeData

Setting Up Environments

The environments folder contains the various testing environments in STAP. This folder is a subfolder under the configuration folder.

Note:

You can organize environment configurations into distinct folders within the environment_configurations sub directory.
You create the environments folder under the configuration folder and create folders for each separate environment. Under each environment folder, create individual files for each product API.
The following is the location for adding the environment details in the config.properties folder:
environments.home=${WORKSPACE}/config/environments

In STAP, environment configuration involves defining and managing the settings and parameters needed to run automation tests across different environments, such as development, testing, and production. This ensures that tests run correctly and produce accurate results across various target systems. Each environment has its own environment.properties file.

Setting Up Execution

The execution folder contains an execution.config.json configuration file. This file contains details of scenarios to run. For more information about scenarios, see "Setting Up Scenarios".

Scenarios are run in various execution groups. You can modify this file to group multiple automation scenarios and run them at the same time. A minimum of one group is required to run a scenario.

The execution.config.json contains these components:

  • group

    Groups are defined under the group keyword, and each group can contain subgroups or scenario folder entries. Each group has a unique name and its own execution mode. At least one group entry is required to define the scenario list.

  • name

    Groups can be identified by user-entered names. If no name is provided, a unique group ID is assigned.

  • execution (Optional)

    Execution can be configured as serial or parallel for each group or subgroup. This parameter controls whether the scenarios within the group run one after another (serial) or at the same time (parallel). If not defined, groups default to serial execution.

  • description (Optional):

    Provides a textual description of the scenario or group.

  • release (Optional):

    Indicates the associated release identifier or version, which can help organize or filter results by release.

  • milestone (Optional):

    Specifies the milestone connected to the group or scenario.

  • build (Optional):

    Specifies the build ID for the scenarios.

  • level (Optional):

    Indicates thehierarchy level for the scenarios.

  • reportTitle (Optional):

    Sets a custom title that will appear in generated reports. If this field is not set, the default report title is Automation Report.

The following is an example of the execution.config.json file when a single scenario is run:
{
        "name": "STAP Sample Tests",
        "execution": "serial",
        "group" : [
                {
					"name" : "STAP Sample Tests",
					"scenarios" : [
						"1.ABC"

				]
                }
        ]
}

Creating different groups of scenarios allows independent execution of groups, and the failure of one group does not halt the execution of others.

When grouping multiple scenarios, each group contains a scenarios list, which specifies the parent folder names where .scenario files reside.

If .scenario files are located in nested folders, the parent folder names of the scenarios folder should be specified.

Note:

If multiple .scenario files exist in a single folder, only the first .scenario file is run.

The following is an example of the execution.config.json file when multiple scenarios are run: 

{
    "execution" : "parallel",
    "group" : [
        {
            "name" : "groupOne",
            "execution" : "serial",
            "scenarios" : [
                "ToDo-E2E-Automation",
                "ToDo-FunctionsAndOperators"
            ]
        },
        {
            "name" : "groupTwo",
            "execution" : "parallel",
             
            "group" : [
                {
                    "name" : "subGroupOne",
                    "execution" : "serial",
                    "scenarios" : [
                        "ToDo-E2E-Automation",
                        "ToDo-FunctionsAndOperators"
                    ]
                },
                {
                    "name" : "subGroupTwo",
                    "execution" : "serial",
                    "scenarios" : [
                        "ToDo-E2E-Automation"
                    ]
                }
            ]
        }
    ]
}

Setting Up Scenarios

A scenario outlines the conditions and expected outcomes of a test, focusing on the overall flow and user interactions. The file extension for a scenario in Solution Test Automation Platform is .scenario.

You must create a README.md file in each scenario folder. This file should include the following details:
  • Author
  • Supported product versions
  • Revision history
  • Exceptions (cases where the scenario may fail)
  • FAQ for troubleshooting failures
  • Other relevant notes

You can use tags to categorize scenarios for easy identification. For more information, see "Using Tags to Filter Components".

For more information about scenarios in STAP and how to create them, see "Creating Scenarios".

Scenarios Folder

The scenarios folder contains the different scenarios to be run. Each scenario is stored in a separate folder within this folder.

Each scenarios folder has the following components:
  • Header.info: Contains the scenario details in the following format:
    Scenario: Name of the E2E Scenario
Description: Description of the E2E Scenario
Tags: Tag1, Tag2
  • Case files: Each .case file covers a specific logical step in a scenario. For more information on the contents of the .case file, see "Creating Scenarios".

    Note:

    You only create a separate .case file if your scenario contains multiple cases. If you have a single case, you can define it within the .scenario file.
  • scenario.config: Contains the list of .case files to be merged to create the .scenario file at run time. This is only applicable for multiple .case files. Use the following format when creating a scenario configuration file:
    Header.info
1.Launch.case
2.Buying.case
3.fusionCDM.case
4.BRM.case
5.Care.case
The following is the configuration for adding the scenario details in the config.properties folder:
scenarios.home=${WORKSPACE}/scenarios

For more information on creating scenarios, see Creating Scenarios.

Setting Up Simulation

Enter a short description of your topic here (optional).

This is the start of your topic.

Setting Up Actions

The Action component provides all input required to the respective plug-in. This input specifies how and with what data the plug-in should run the action. For more information on plug-ins, see "STAP Action Plug-ins".

The structure of the Action folder is in the following hierarchy:
  • Product Folder: The folder for the product containing the respective plug-in.
  • Plug-In Folder: The type of plug-in. For example, REST.
  • Path Folder: The folder containing it's respective actions. For example, bill.
  • Action: The action file. Use lowercase letters with hyphens to separate words in action file names. File names should be self-descriptive and end with the .action.json extension. For example, create-bill-by-ID.json.

Action files contain common information, such as Name, BDD, Type, and Product. For more information on creating an action for a specific plug-in, see "Action Execution".

You can share actions across automation projects as libraries by storing and publishing them as JAR files. For instructions on using action library JARs instead of folders, see "unresolvable-reference.html#GUID-68EC0926-48E6-4FE3-9963-7E832263A86F". Ensure to provide a default request/data for the action.

The following example shows how to create an action using the REST plug-in:
{
"path":"subscription/create-new-subscription",
"name":"Create a new subscription",
"bdd":"create a new subscription",
"description":"Create a new subscription in the billing system",
"product":"billing",
"actionType":"REST",
"tags":["billing","subscription","create","new"],
"resource":"subscription",
"method":"POST",
"requestType":"FILE",
"request":"create-new-subscription.request.json",
 "expectedStatusCode":201
}

Setting Up Context

The context folder stores the data of previous steps, enabling the simulation of scenarios where only the current step needs execution. This eliminates the need to repeatedly run prior steps, as the context provides the necessary values for the current step.

You configure the location of the context folder in config.properties. The parameters used in the configuration are described below:

  • context.home: Defines the directory where context data is stored.
  • context.load: Determines whether to load context data while running (YES/NO).
  • context.save: Specifies whether to save context data for a scenario, useful for debugging (YES/NO).
  • context.global.load: Controls whether global context data (shared across scenarios) should be loaded.
  • context.global.save: Controls whether global context data (shared across scenarios) should be saved.
Configuration Sample:
context.home=${WORKSPACE}/context
context.load=NO
context.save=NO
context.global.load=NO
context.global.save=NO

Context manages two types of variables:

  • Local Variables: These are available only during the execution of a single scenario. They are not preserved outside the scenario run.
  • Global Variables: Global variables are prefixed with an underscore and exist for the duration of the entire job run, across scenarios and steps.

For more information on variables, see "unresolvable-reference.html#GUID-964C7F5D-F5B7-4597-9C37-FC9F543F0A9E".

Setting Up Reports

Results of the test run are stored in the results folder. The path to this folder can either be relative to your workspace or a direct path to store the results outside your workspace.

The results of each test run are created under this folder with its relative timestamp. The format of this timestamp is $results/<timestamp>. To view the execution report, you open the report.html file.

The following is the configuration for adding the result details in the config.properties folder:
#-------------------------------------------------------------------------------
# Results storage location
#-------------------------------------------------------------------------------
results.home=${WORKSPACE}/results