In this section:
A variable set (referred to as an "environment" in SOAtest) is a collection of variables that can be referenced within fields of your test scenario. For example, you might want to specify different values for the WSDL, host, and port for different test environments. When you specify these settings with variables, rather than hard-coding them in the tests, it is much easier to reuse the same test scenario across multiple environments.
If a .tst uses variable sets, you can specify how they are set within a specific component instance or test job. For example, you can have a single component instance or test job run the same .tst multiple times— each time with different variable settings.
Mapping Variables in Jobs
You can choose a variable set and map the variables that have been configured in the environment or component to the .tst so that it can run with alternate values.
The following table describes how variables used in the .tst are mapped to the configured sources:
| Type | Description |
|---|---|
| From tst | Uses the value defined in the test scenario (on the SOAtest server) at the time of test execution. |
| Literal value | Uses the literal value specified in the text field. |
| Environment (<NAME>) | Uses the selected variable from the current environment. |
| Component (<NAME>) | Uses the variable specified in an environment component—either the variable you are creating/editing in the field or another variable in the same environment. A new component instance variable will be created and used to determine the variable value. This way, you can use Environment Manager variables to set SOAtest environment variables—without going to the SOAtest UI. One variable will be created for each unique variable/value pair. For instance, if you have 6 test scenarios that use the WSDL SOAtest variable, and they are all set to the same WSDL value, one component instance variable will be created. If 2 of those test scenarios use one WSDL value and 4 others each use a different WSDL value, 5 component instance variables will be created: WSDL, WSDL_1, WSDL_2, WSDL_3, and WSDL_4. |
You can configure variables to be masked so that sensitive data, such as passwords, are not visible to other users who view the variables. Variables in .tst files will automatically be masked when environments with masked system/component variables are provisioned. For details on defining variables at the system, environment, component, or component instance level, see Working with Variables.
Confirming Variable Values
This section applies when you are adding SOAtest Test Executor components or custom health checks to an environment; it is not applicable to defining test jobs for on-demand execution.
In the Variables wizard page, you are presented an aggregation of all variables associated with the component instance—including the ones that were added to represent SOAtest environment variables (as described above).
If you want to change a variable value, check Override, then specify the new value in the text field.
