You can add test scenarios and test suites on SOAtest Server directly from the Test Scenarios page, which is accessed by opening the API Testing module.

Creating New Test Scenarios (.tst files)

A test scenario is the smallest unit that can be executed in a job or during provisioning. It is stored as a .tst file within the SOAtest workspace.

To add a new .tst from CTP:

  1. In the left pane, select the server or folder where you want the new test scenario added.
  2. Choose Create Test Scenario from the page-level action menu.
  3. (Optional) Specify a name for the scenario and add a description.
  4. Choose a test scenario type from the Create menu. See Test Scenario Creation Options for details about scenario types.
  5. (Optional) Associate a work item from your ALM system with the test scenario. See Work Item Associations for details.
  6. Click Save.

The .tst (included any generated SOAP Client tools) will be added to the specified SOAtest server. You can review the added SOAP Clients by selecting the associated tree node. 

After creating a test scenario from a WSDL definition file, the tool’s name, request message, endpoint, and SOAP action will be configured automatically. A variable is created for the endpoint value. With the endpoint set to a flexible variable rather than a hard-coded value, you can run the same test versus different environments without modifying the test itself. Generated variables are defined in the generated variable set.

After creating a test scenario from a RAML or OpenAPI definition file, a REST Client for each resource/method pair in the definition will be created. Each REST Client's resource URL, HTTP method, and payload (if applicable) are configured accordingly.

The service's base URL will be configured as a "BASEURL" variable. Each resource URL is parameterized with the "BASEURL" variable. Query parameters are included with default or sample values (if available) as defined by the service definition. A sample message (if available) is included in the payload. If the service definition includes a JSON schema, a sample payload is constructed from that JSON schema.

Variables values can be adjusted at the test job level, as well as the component instance level.

Test Scenario Creation Options 

You can create scenarios from the following inputs from the test scenario creation screen.

Empty

Choose Empty to create a skeleton scenario that you can manually add tests to later. 

To add a skeleton test suite within an existing test scenario (.tst file):

  1. In the left pane, select the .tst or test suite where you want the new test suite added.
  2. Choose Add Test Suite from the page-level action menu.
     
  3. (Optional) Modify the name of the newly-created test suite.

The test suite will be added to the specified SOAtest server within the designated .tst file.

RAML

Choose From RAML and enter the absolute URI to a RAML definition file to automatically-generate a test scenario based on the endpoints found in a RAML description. RAML 0.8 and 1.0 are supported.

OpenAPI (Swagger)

Choose From OpenAPI (Swagger) and enter the absolute URI to an OpenAPI definition file to automatically-generate a test scenario based on the endpoints found in a Swagger description. OpenAPI 1.0 - 2.0 is supported.

WSDL

Choose From WSDL and enter the absolute URI to WSDL definition file to automatically-generate a test scenario based on the endpoints found in a WSDL description. 

Traffic

You can generate a test scenario based on traffic captured by a Parasoft proxy or other utility. Access to a running Parasoft data repository server and at least one traffic file must be saved in the VirtualAssets project. The traffic’s message contents must be well-formed (e.g., if XML, it must be well-formed). SOAP messages must have only one top-level XML element.

  1. Choose From Traffic from the Create drop-down menu and browse for the traffic file.
  2. (Optional) If you want the scenario to conform to a template file, enable the Apply a template file option and browse to the template. Templates are stored in the traffic_templates folder on the SOAtest server by default
  3. Choose a data repository server from the Repository server drop-down menu. A data repository server must be running and registered with CTP to connect the test scenario with it.
  4. Choose a repository from the Repository name drop-down menu or enter the name of a new repository to create for the scenario. If you specify an existing repository, existing data will be overwritten.

The tools will be automatically configured and parameterized with values stored in the specified Parasoft data repository.

Work Item Associations

You can associate tests in the new scenario with a work item stored in your application lifecycle management (ALM) or requirements management (RMS) system.

  1. In the Work items section, click the add button to create a new row in the table.
  2. Specify an artifact type to associate with the work item. Terminology across ALM/RMS systems vary, but the following types are supported by default:
    • @fr - Use this type to associate the tests with a feature request work item
    • @pr  - Use this type to associate the tests with a defect work item
    • @req  - Use this type to associate the tests with a requirement or user story work item
    • @task  - Use this type to associate the tests with a task work item
    • @test  - Use this type to associate the tests with a test work item 
  3. Specify the work item ID.
  4. Specify the URL of your ALM/RMS.
  5. Click the check button to accept the association.

You can click on the trash icon to delete existing associations. 

Adding Tools

You can add commonly-used API Testing tools (such as REST Client, SOAP Client, Diff, and XML/JSON Assertor, and XML/JSON Data Bank tools) directly from the CTP interface. Additional tools can be added from SOAtest desktop.
For details, see:

You can parameterize tool values using data sources or extracted values. See Parameterizing with Data Source and Data Bank Values for details.

  • No labels

Need assistance? Visit our support page