...
SOAtest can automatically create API tests for web applications from API traffic captured with SOAtest Smart API Test Generator. Tests created in this way are referred to as "smart" API tests. The out-of-the-box implementation is designed to help you quickly start testing your APIs, but you can also "teach" SOAtest how you want smart API tests to be generated.
You can also customize how tests are generated by configuring settings in tst_creation.properties, the test creation properties files shipped with SOAtest. See Test Creation Properties.
SOAtest will automatically create tests using the appropriate applicable test creation configuration file based on the Parasoft Recorder configuration. See SOAtest Smart API Test Generator for additional information.
About Smart Test Templates Templates
You can create Smart Test Template (.stt) files to define rules that determine test generation behaviors. These files contain one or more Resource Suites, which identify paths through the application to which your test generation rules will be applied.
...
When the SOAtest creates a new smart API test, it will read and apply the rules specified in the .sttfile.
Manually Creating and Configuring Test Templates
You can create and manage .stt stt files using the Smart Test Templates View. Additionally, you can add multiple .stt files and organize them into folders.
- Go to Parasoft > Show View > Smart Test Templates to open the Smart Test Templates view (if not already open).
- Click Add Template on the tool bar and specify a name and location for the .sttfile.
- (Optional) You can specify a path to create nested folders to organize your .sttfile.
e - Click Next.
Choose the type of Resource Suite to create. You can create an empty suite or initialize the suite based on a service definition.
If you are using a definition file, see the following sections for additional information:
Creating Tests from a Swagger Definition
- Click Next if you are creating a suite based on a service definition and specify the location of your definition file. Skip this step to create an empty suite.
- Click Finish.
- Expand the .sttfile and double-click the Resource Suite.
- (Optional) You can disable Use Default Name and specify a name for the file.
- Specify a pattern in the Match field to identify the endpoints you want the rules in this suite to apply to (see Defining Smart API Test Generation Scope). The Resolved field renders a preview of the pattern. Nested Resource Suites inherit the Match settings from the parent Resource Suite. You can determine how to structure template files and configure matching patterns accordingly. See Example Smart Test Template for for a common use - case.
- Right-click the Resource Suite and choose Add New > Resource Template.
- (Optional) Disable Use Default Name and specify a name for the Resource Template in the Name field.
Choose a method from the Method dropdown menu and specify a pattern in the Match field to identify the endpoints you want the rules in the template to apply to (see Defining Smart API Test Generation Scope). The Resolved field renders a preview of the pattern. Resource Templates inherit the Match settings from the parent Resource Suite. You can disable Exact Match if you want to allow SOAtest to generate tests for all subpaths sub-paths specified in the Match field. Exact Match is enabled by default.
When SOAtest determines a match in the Resource Template, configurations from all chained tools are applied. You can determine how to structure template files and configure matching patterns accordingly. See Example Smart Test Template for a common use-case.Info title Chaining JSON Assertors JSON Assertor tools chained to Resource Templates can be configured to use the values from traffic if present. See Adding JSON Assertions for additional information.
- Right-click the Resource Template and choose Add Output...
- Choose a tool to include in your generated test and configure the settings. For example, you can chain and configure an HTTP Authentication tool so that all test suites generated with the template automatically authenticate against the application under test (see Enabling Authentication for additional information).
- Add additional Resource Suites and Resource Templates as necessary. The .stt file is processed in order from first to last. Each Resource Suite is processed according to its hierarchy before the next suite is processed. You can add as many suites and templates and chain as many tools as necessary to train SOAtest.
- Save your changes.
...
- Curly braces (
{}) indicate wildcards and can contain any text. For example, you can specify a pattern that translates into scheme, host, and port:{scheme}://{host}:{port}
- Asterisks (
*) also indicate wildcards. A single asterisk and curly braces can be used interchangeably:{scheme}://{host}:*/parabank/*/accounts/{id} - You can use a double - asterisk to match multiple directories.
{scheme}://{host}:*/parabank/**/{id} - Excluding scheme, host, and port will match any scheme, host, and port. For example, the following pattern matches the specific path on any host, port, and method:
/parabank/services_proxy/bank/accounts/{id}
- Specifying a negative number or a number greater than
65535for the port treats the port as a wildcard. - Resource Templates and nested Resource Suites inherit the Match settings from the parent Resource Suite.
- You can disable the Exact Match option if can disable the Exact Match option if you want to allow the SOAtest to generate tests for all subpaths sub-paths specified in the Match field. The Exact Match option is enabled by default by default in Resource Templates.
Default Scope
...
SOAtest uses the HTTP Authentication tool for configuring authentication credentials for your tests. The HTTP Authentication tool is a special tool that you can only use in .stt files. When SOAtest matches the settings in the Resource Template tool, credentials configured in the HTTP Authentication tool are applied to the generated tests.
...
SOAtest uses the HTTP Header tool to add header fields to your tests. The HTTP Header tool is a special tool that you can only use in .stt files. When SOAtest matches the settings in the Resource Template tool, any headers configured in the HTTP Header tool will automatically be added to the generated tests. You also can use this tool to override header values captured during test creation.
...
You can apply assertion logic from an existing .tst file to train Smart API Test Generator. See Training Based on .tst Files.
...
You can reference other test suites in your .stt file, which enables you to include additional set-up steps that may be necessary for your tests to execute properly. Only one referenced test suite will be added per Resource Template tool. Tests included by reference are added as the first test in the generated suite.
Relative paths are relative to the TestAssets project. To reference tests in another project, use the ${project_loc} variable. See Reusing and Modularizing Test Suites for End to End Testing for additional information about references.
- Right-click a Resource Template tool and choose Add Output....
- Expand the Suite category and choose Beginning.
- Choose Test Suite Reference in the Smart category and click Finish.
- Specify the location of the test suite you want to reference in the Test Suite Reference editor.
You can click File System or Workspace to browse for the .tst file you want to reference. - Save your changes.
...
You can teach SOAtest to generate tests that include authentication settings and JSON assertion logic from existing REST Clients. SOAtest will create an HTTP Authentication or a JSON Assertor rule under the resource template that most closely matches the path specified in the REST Client. If no match is identified, new .stt files will be created that contain resource templates for each REST Client URL. The .stt file(s) will contain Resource Suites and Resource Templates with their Match settings configured to match the REST Client's endpoint.
The match pattern for new .stt files is based on the type of rule you are teaching SOAtest. For authentication, the parent suite match is set using the REST client's scheme, host, and port. The resource template contained in the parent suite will be configured to match to the REST client's basePath and all subpaths and method types.
The parent suite match is set using the REST client's basePath when teaching SOAtest assertion rules and the structure of the test suites. Subpaths Sub-paths are configured in a nested suite match and/or a resource template match. The resource template will be configured to match the "Exact" field at the specific method type.
- Right-click the .tst file, Test Suite, or REST Client node in the Test Explorer and choose Train Smart Test Template.
Review the summary when prompted. SOAtest will attempt to match resources in existing .stt files and add new rules accordingly. If a matching .stt is not found, a new file will be created.
Info title Training Smart API Test Generator with JSON Assertors Equality assertions (assertions configured with the
==orequalsoperator) with fixed values will be created based on traffic. If the value is parameterized with a non-equality assertions, the assertor chained to the resource will be a converted to a fixed value set to[Smart - User Input]. For parameterized equality assertions the value will be[Smart - From Traffic].New assertions will be added to existing assertors in the .stt file.
- Click OK to update or add a new .stt file to the Smart Test Templates view that contains the settings configured in the REST Client. If new .stt files are created, the files will be named according to the original client's URL. Template resources will be grouped by base path segment. You can right-click the file in the Smart Test Templates view and rename it.
- Double-click the Resource Suite and the Resource Template and configure their Match settings to define the test generation scope. See Defining Smart API Test Generation Scope.
- You can manually add additional resources to finish configuring the .stt file. See Manually Creating and Configuring Test Templates.
...
You can update existing tests to use the rules defined in a .stt file. You would commonly use the functionality This functionality is helpful if you already have REST Clients and want to quickly apply a standard set of assertions, authentication settings, and headers from a template.
- Right-click on the .tst file you want to apply rules to and choose Apply Smart Test Template.
- SOAtest will match resource paths to REST Client URLs and apply rules defined in the .stt to clients with matching URLs (see Defining Smart API Test Generation Scope for details about matching criteria). Review the updates when prompted and click OK.
Example Smart Test Template
The structure of your test templates will depend on how you want to test your application. The following example .stt represents one way that an application under test (CTP).
...
| applicationType | Defines a unique identifier for the configuration file so that it can be read from different SOAtest interfaces, such as the Generate Smart API Traffic wizard (see Creating Smart API Tests from Traffic). | ||||||
|---|---|---|---|---|---|---|---|
| includeContentTypes | Defines a comma-separated list of content types to include during traffic processing. Default is application/json,application/x-www-form-urlencoded | ||||||
| excludeContentTypes | Defines a comma-separated list of content types to exclude during traffic processing. Default is empty. | ||||||
| disableDiffCreation | Enables/disables diff creation. See Diff for additional information. Default is | ||||||
| disableDiffParameterization | Enables/disables diff parameterization. Parameterization enables you to use data banked values in the diff. If diff parameterization is disabled (setting this property to true), only static values will be available. Default is false. | ||||||
| disableEnvironmentCreation | Enables/disables the creation of an environment and environment variables. Default is false. | ||||||
| disableDataBankCreation | Enables/disables data bank creation. See Data Exchange Tools for additional information. Default is | ||||||
| disableAssertorCreation | Enables/disables the creation of JSON Assertor tools. Default is false. See JSON Assertor for additional information. | ||||||
| diffToolIgnoreNames.<number> | Defines a regex matching element names that should be ignored when creating diffs. Default is You can specify additional name patterns by adding properties and appending them with For example:
| ||||||
| diffToolIgnoreValues.<number> | Defines a regex matching values that should be ignored when creating diffs. Default is to ignore timestamps:
You can specify additional value patterns by adding properties and appending them with For example:
| ||||||
| assertorToolIgnoreQueryParameterNames.<number> | Defines a regex-matching query parameter names name that should be ignored when creating JSON Assertor tools. Default is to ignore query names starting with "maxResultsSize":
The property is not case sensitive. You can specify additional patterns by adding properties and appending them with | ||||||
| assertorToolIgnoreQueryParameterValues.<number> | Defines a regex matching query parameters values that should be ignored when creating JSON Assertor tools. Ignore query parameters when creating assertions based on parameter value pattern Default is to ignore timestamps:
You can specify additional patterns by adding properties and appending them with | ||||||
| assertorToolIgnoreFieldNames.<number> | Defines a regex matching values in the response payload that should be ignored when creating JSON Assertor tools. Default value is to ignore values in response payload that starts with time, date, url, href, SessionId, or transactionId. Default is to ignore timestamps:
The property is not case sensitive. You can specify additional patterns by adding properties and appending them with | ||||||
| assertorToolIgnoreFieldValues.<number> | Defines a regex matching values that should be ignored when creating JSON Assertor tools. Default is to ignore timestamps:
You can specify additional value patterns by adding properties and appending them with For example:
| ||||||
| includeURLPatterns | Defines a comma-separated list of resource URL patterns to include for test generation. You can define case-sensitive patterns using Ant-style syntax. Default is to include all URLs. The following examples describe common scenarios:
# include URLs that have a 'path' segment
| ||||||
| excludeURLPatterns | Defines a comma-separated list of resource URL patterns to exclude from test generation. You can define case-sensitive patterns using Ant-style syntax. Default is to include all URLs. The following examples describe common scenarios:
| ||||||
includeTextResponseValues.<number> | Defines a regular expression matching values that the test generator will consider for potential extraction to a data bank. If a match is found, the substring that matches the pattern enclosed in the parentheses will be considered. At least one set of parentheses is required to define the desired value and its boundaries. Two parameters are configured with the following regex patterns by default:
| ||||||
| includeTextResponseContentTypes | Defines a comma-separated list of content types the test generator will process against the includeTextResponseValues parameter. Default is text/html. | ||||||
| requestPayloadParameterizationExcludeNames.<number> | Defines a regex that matches field names in a request payload that should be excluded from parameterization. The following example excludes date and time field names from parameterization:
| ||||||
| requestQueryStringParameterizationExcludeNames.<number> | Defines a regex that matches field names in a request queries that should be excluded from parameterization. The following example excludes date and time field names from parameterization:
| ||||||
useServerSettings
| Enables/disables using the settings from the tst_creation.properties file on the SOAtest server, instead of the settings configured in the local tst_creation.properties file. Default is true. |
...
If the existing file is moved or deleted, all default settings, as well as new settings added from the latest update, will be applied. A back up of the original file will be applied with a .bak extensionbak extension.