Parasoft SOAtest Tutorial

Table of Contents
Table of Contents ...................................................................... 2
Introduction................................................................................ 4
About this Tutorial 4
Obtaining the Latest Version and Service Pack 4
Parasoft SOAtest Best Practices 4

WSDL Verification...................................................................... 5
Creating a WSDL Verification Test Suite 5

Functional Tests ........................................................................ 8

Creating Test Suites for Unit Tests 8
Ignoring XPath Values 13
Validating Specific Elements 15
Using the XML Assertor 16
Automate Testing Using Data Sources 20
Separating Tests into Positive and Negative Test Cases 23
Testing Invalid Data 24

Scenario Testing........................................................................ 26
Creating a Scenario Test Suite 26
Configuring an XML Data Bank 27

Creating and Deploying Stubs ................................................. 32

Creating Stubs 32
Viewing Deployed Stubs 33
Using the Deployed Stubs 33
Modifying Deployed Stubs 34

Testing Plain XML Services ...................................................... 36

Custom Scripting....................................................................... 38
Asynchronous Testing.............................................................. 41
WS-Security................................................................................ 45
Unlimited Strength Java Cryptography Extension 45

Message Layer Security with SOAP Headers: 46

Using the XML Encryption Tool: 48
Using the XML Signer Tool 51
XML Encryption and Signature Combined 53
Automatically Generating WS-Security Tests with WS-SecurityPolicy 54

Design and Development:

Policy Enforcement ................................................................... 57
Rule Set Configuration 57
Parasoft Team Configuration Manager 57
Enforcing Design-time SOA Policies 58
Defining Custom SOA Policies 60

Load Testing .............................................................................. 62

Creating and Performing a Load Test 62
Customizing Load Test Profiles and Scenarios 66
Viewing Reports 70

Reporting.................................................................................... 72
Functional Testing Reports 72
Load Testing Reports 72
Structure Reports 73

Automation/Iteration (Nightly Process) ................................... 74

Running a Test Suite From the Command Line 74
Running SOAtest From the Command Line Using Scripts 74

Running Regression Tests in Different Environments .......... 76

Introduction

Introduction
Parasoft SOAtest is the most comprehensive tool for testing Web services. SOAtest allows users to
verify all aspects of a Web service, from WSDL validation, to functional testing of the client and server,
to performance testing. SOAtest addresses key Web service issues such as interoperability, security,
change management, and scalability. Because of its flexible nature, SOAtest is an ideal choice for
development engineers and QA professionals alike, since its functional tests can be leveraged into
scenario-based tests, as well as load tests, without any additional scripting or re-inventing of the wheel.
By utilizing SOAtest throughout the software development lifecycle, users can prevent errors, improve
quality and reliability, and accelerate the time to market for their Web service initiatives.

About this Tutorial

The topics presented in this document represent key areas of Web services testing and will give you a
guide on SOAtests support of these items. This tutorial is meant to be used along with the SOAtest
project file SOATestTutorial.tst located within the SOAtest examples directory. This directory also
contains specific examples referenced throughout this tutorial. Further information about each test is
given in the Notes section of each SOAtest test suite. It is recommended that while following the examples given in this tutorial, you save your project after each section or sub section is completed.

Obtaining the Latest Version and Service Pack

To ensure that you have the latest version and service pack of SOAtest, select Updates> Check for
Updates from the SOAtest menu. This checks for the most recent SOAtest version and allows you to
update your current version of SOAtest, or to download a service pack, if available.

Parasoft SOAtest Best Practices

While reading this document, you will find examples that show the recommended way of creating test
cases within SOAtest. When creating tests for your own Web service, you can utilize these examples
to create your tests in a similar fashion. The following list details the best practices for using SOAtest:

Using the SOAtest wizard, create a test suite of WSDL tests that should be run on a nightly
basis.

Using the SOAtest wizard, create a test suite of SOAP Client tests for each operation defined
within your WSDL. These test clients can then be moved into separate test suites for Functional Tests and Scenario Tests to optimize reusability and organization.

Positive and negative test cases should be created for each test case you create to fully maximize the testing coverage of the web service.

Regression tests should be created for both positive and negative test cases. Regression tests
alert you to any changes in Web service functionality over time as the service evolves.

When creating your project files (*.tst) within SOAtest, save often and make backups. If possible, check your project files into source control.

WSDL Verification

WSDL Verification
WSDL verification can be considered as the first step in testing Web Services. Although WSDLs are
generally created automatically by various tools, it doesnt necessarily mean that the WSDLs are correct. When WSDLs are manually altered, WSDL verification becomes even more important.
Ensuring correct and compliant WSDLs enables you service consumers to function correctly, and
avoids vendor lock-in, thus achieving interoperability and realizing SOA goals of service reuse.
SOAtest can automatically generate a test suite of comprehensive WSDL tests to ensure that your
WSDL conforms to the schema and passes XML validation tests. Additionally, it performs an interoperability check to verify that your web service will be interoperable with other WS-I compliant services.
When you complete this section of the tutorial, your test suite should resemble the test suite entitled
"WSDL Tests" in the SOATestTutorial.tst file.

Creating a WSDL Verification Test Suite

For this example we will create WSDL tests for a book store service with the WSDL located at
http://soatest.parasoft.com/store-01.wsdl.
To verify a WSDL using SOAtests WSDL Verification Tests, complete the following:
1. Click the New Project toolbar button. A New Test Suite wizard displays with WSDL already
selected.

2. Click the Next button. The WSDL dialog displays.

WSDL Verification

3. Specify the WSDL in the WSDL URL field or Browse to the WSDL file on your machine.
4. Uncheck the Create functional tests from the WSDL check box and select the Create tests
to validate and enforce policies on the WSDL check box.
5. Click Finish.
Because you selected the Create tests to validate and enforce policies on the WSDL
check box, four WSDL tests are automatically created in a separate test suite called WSDL
Tests.
SOAtest automatically creates the following WSDL tests from a WSDL URL.

Test 1: Schema Validity: Runs XML validation on the WSDL against WSDL schemas
from W3C.

Test 2: Semantic Validity: Checks the correctness of the WSDL by parsing and consuming it like an actual service consumer would, but with stricter adherence to standards.

Test 3: WS-I Interoperability: Verifies the WSDL against WS-I Basic Profile 1.1.

Test 4: WSDL Regression: Creates a regression control for the WSDL so that
changes in the WSDL document can be detected.

6. Select the Test 3: WS-I Interoperability Check node and click the Add Test button.

WSDL Verification

Add Test

The Add Output wizard displays.

The Add Output wizard displays a list of available tools. In addition, a description of the
selected tool displays in the Tool Description field.
7. In the Add Output wizard, select Conformance Report from the left pane, select the All
Tools checkbox and then select Browse from the right pane, and click the Finish button. This
will send a WS-I Conformance report to your internet browser when you run the test.
8. Select the Test Suite: WSDL Tests node and click the Run Tests toolbar button.
If any errors occur, they will display in the right GUI panel. You can double-click the errors in
the right GUI panel for additional information and you can also examine the conformance
report that was opened in your internet browser.

Functional Tests

Functional Tests
For this section of the tutorial, please reference the test suite entitled "Unit Tests" in the
SOATestTutorial.tst file.
The best way to ensure the correct functionality of your Web service is to start by creating unit tests for
each individual operation implemented by your service. Performing unit testing allows you to catch
errors at the component level, making development errors easier to identify and fix. The SOAtest test
creation wizard will automatically create a test client for each operation defined within your WSDL.
These tests can then be moved into separate test suites, creating one test suite for each test case,
allowing you to organize and structure your testing environment to maximize readability and reusability.
For example, if your WSDL defines five operations, the SOAtest wizard will generate five test clients in
a single test suite. These five test clients can then be separated into five separate test suites, each
containing a unit test for a single operation.
In this example a simple book store service is used. It provides the following operations:

placeOrder(int, int) - places an order for a book by its ID and quantity desired.

removeOrder(int) - removes an order with the specified order number..

getItemByTitle(String) - returns the book entry with the given title.

getItemById(int) - returns the book entry with the given item id.

getPendingOrders() - returns a list of orders that have been submitted using placeOrder.

addNewItem(Book) - adds a new book into the database.

confirm() - confirms the currently pending orders.

Creating Test Suites for Unit Tests

For this example, we will build upon the test suite created in the previous section.
1. Select the Test Suite: Test Suite node from the previous exercise and click the Add Test
Suite button. The Add Test Suite dialog box displays.
2. Select New Project from the Add Test Suite dialog and click the Next button twice to advance
to the WSDL dialog.

Functional Tests

3. Select http://soatest.parasoft.com/store-01.wsdl from the WSDL URL field.

4. If it is not already selected, enable the Create functional tests from the WSDL checkbox and
then click the Next button four times to proceed to the Layout dialog.
5. Enable the Organize as Positive and Negative Unit Tests checkbox.

Functional Tests

6. Click the Finish button. The newly created test suite displays in the left GUI panel of SOAtest
and the Test Suite configuration controls display in the right GUI panel.
7. In the right GUI panel, enter Functional Tests in the Name field. Within the Functional Tests
test suite, there is a Test Suite: store-01.wsdl node within which there are seven other test
suites that test each operation of the WSDL.
8. Expand each test suite node within the newly-created Functional Tests branch until all seven
test suites are visible and each test within each test suite is displayed.

10

Functional Tests

Each of the seven test suites contain both a positive and negative test for each operation since
it is important to test situations where we send expected data as well as unexpected data to
the server.
9. Select the Test 1: getItemByTitle node underneath the Test Suite: getItemByTitle Positive
Test node.

11

Functional Tests

10. In the titleKeyword entry field type Linux. We will be searching for books with keyword Linux.
11. Click the Run Tests tool bar button. The getItemByTitle operation is invoked with the parameter Linux.
12. Expand the Test 1: getItemByTitle node and select the Traffic Object> Traffic Viewer node
underneath. The HTTP Traffic that was logged from the test run displays in the right GUI
panel.
13. Right-click on the Test 1: getItemByTitle node and select Update Regression Control from
the shortcut menu. SOAtest automatically runs the test and creates a regression control populated with the value received from the server.
Regression Testing: When creating functional tests it is important to create regression tests
to ensure that your service continues to send the correct response to requests as it changes
and continues to evolve over time. This can be done in SOAtest simply by right clicking on a
test and choosing Create Regression Control from the shortcut menu.
We now have a functional test that tests the getItemByTitle operation of our web service on a single
input value. The same sequence of actions can be done to create functional tests for the other operations defined within the WSDL.

12

Functional Tests

Ignoring XPath Values

When creating regression controls, it may be helpful to ignore dynamic values such as timestamps or
session variables that can cause your regression test to fail. In the bookstore example, the price element is a dynamic value, with the price of the book increasing by $1 every few times the test is run. In
this example we will set up an XPath Property to globally ignore the price element value in all tests.
1. Run Test 1: getItemByTitle a few times. Notice that the regression test fails and an error message displays in the Test Results panel because the price element has changed. In this case
we want to ignore the value of the price element.
2. Right-click on the error message in the Test Results panel and select Ignore XPath from the
shortcut menu.

An Ignored XPaths Settings dialog displays.The XPath of the price element, /Envelope/
Body/getItemByTitleResponse/Result/i/price, is automatically populated in the XPath
field.

3. Make sure the Recursive, Text Content, and Modify checkboxes are selected and click OK.
This will instruct the regression test to recursively ignore any modifications to the text content
of the price element.

13

Functional Tests

4. In Test 1: getItemByTitle, select the Response SOAP Envelope> Diff control node. The
Diff control parameters display in the right GUI panel.
5. Select the Ignored Differences tab in the right GUI panel. The Ignored Differences dialog displays. Notice that the XPath of the price element has been added to the Ignored XPaths List.

All of the price element values with the specified XPath are now being ignored. Run the functional test
again and it will succeed.

14

Functional Tests

Validating Specific Elements

In some situations, you may only care about the values of one or two elements within an XML message
and do not want to spend time ignoring each individual element within the message. In such an
instance, you can use the Response Validation Wizard to validate a single element.
1. Right-click the Response SOAP Envelope> Diff control node underneath the Test 1: getItemByTitle node from the previous exercise and select Delete from the shortcut menu.
2. Right-click the the Test 1: getItemByTitle node and select Response Validation Wizard from
the shortcut menu. The Response Validation Wizard displays.

3. Select Select Parameter and click the Next button. The Select Parameter dialog displays a
tree view of the XML message from which you can select a single parameter to validate.

15

Functional Tests

4. Select the title element from the Select Parameter dialog and click the Next button.
5. Select Create Regression Control and click the Finish button. A Response SOAP Envelope> XML Transformer and Diff control are now added underneath the Test 1: getItemByTitle node. Because the title element was chosen, the Diff control only compares the title
element rather than all elements.

Using the XML Assertor

Similar to the Response Validation wizard, you can use the XML Assertor tool to enforce the correctness of data in an XML message. It is most commonly connected to a SOAP Client or Messaging Client in order to verify the data returned by a service. The XML Assertor provides support for complex
message validation needs without the need for scripting, and allows you to easily create and maintain
validation assertions on your XML messages. To use the XML Assertor, complete the following:
1. Right-click the Response SOAP Envelope> XML Transformer node from the previous exercise and select Delete from the shortcut menu.
2. Right-click the Test 1: getItemByTitle node and select Add Output from the shortcut menu.
The Add Output wizard displays.

16

Functional Tests

3. In the Add Output wizard, select Response> SOAP Envelope from the left GUI pane, select
XML Assertor from the right GUI pane, and click the Finish button. A Response SOAP
Envelope> XML Assertor node is added underneath the Test 1: getItemByTitle node.
4. Select the Response SOAP Envelope> XML Assertor node and select the Assertions tab in
the Project Configuration panel.
5. Click the New button in the Assertions tab. The Add New Assertion wizard displays.

17

Functional Tests

6. Select String Comparison Assertion and click the Next button. The String Comparison
Assertion dialog displays a tree view of the XML message from which you can select a single
value to enforce.

18

Functional Tests

7. Select the title element from the String Comparison Assertion dialog and click the Finish
button. The Assertions tab in the Project Configuration panel is now populated with a String
Comparison Assertion.

19

Functional Tests

8. Enter Linux in the Expected Value field of the Assertion tab and click the Run Tests button.
The test succeeds.
You may add additional assertions to apply to the message (such as a Numeric assertion to enforce on
the price element) by clicking the New button in the Assertion tab.

Automate Testing Using Data Sources

Now that we have a unit test created that tests a single input value, the next step is to add a data
source. Adding a data source will allow you to test multiple input values with a single test case.
1. Right-click on the root test suite node Test Suite: Test Suite and select Add to Project> Add
Data Source from the shortcut menu. The Add Data Source Wizard displays.

2. Select Excel Spreadsheet from the Add Data Source wizard and click the Finish button. A
Data Source node is added to the project under the root node and the Data Source configuration controls display in the right GUI panel.
3. In the right GUI panel, enter Books in the Name field.
4. Click the Browse button and navigate to the Books.xls file that is included in the SOAtest
examples/datasources directory.

20

Functional Tests

Notice that the column names from the Excel Spreadsheet appear in the Column Names box.

5. Go back and select the Test 1: getItemByTitle node from the previous exercise. Books
should already be selected from the Data Source drop-down menu that is now present in the
right GUI panel.
6. For the titleKeyword drop-down menus at the bottom of the right GUI panel, select Parameterized and Keywords.

21

Functional Tests

7. Click the Run Tests tool bar button and notice the error messages that appear in the Test
Results panel. The test ran one time for each row in the Keywords column, but failed due to
the XML Assertor we created previously. Now we need to update our regression control.
8. Right-click the Response SOAP Envelope> XML Assertor node and select Delete from the
shortcut menu.
9. Right-click the Test 1: getItemByTitle node and select Update Regression Control> Multiple Controls> Remove Existing Controls. SOAtest adds new regression controls for each
test run - in this case 4 regression controls, one for each row of the data source.
10. Select the Traffic Object> Traffic Viewer node beneath the Test 1: getItemByTitle node and
notice that the test ran four times, once for each keyword value in the Keyword column.

22

Functional Tests

Separating Tests into Positive and Negative Test

Cases
When creating test cases, it is important to test situations where we send expected data as well as
unexpected data to the server. It is important that the server sends the correct responses to valid
requests, and just as important that it knows how to handle invalid requests.
In this example we will examine the Negative Unit Test within the Test Suite: getItemByTitle Unit
Tests node.
1. Expand the Test Suite: getItemByTitle Negative Test node underneath the Test Suite: getItemByTitle Unit Tests node.
2. Select the Test 1: getItemByTitle node underneath the Test Suite: getItemByTitle Negative
Test node.
3. In the Test 1: getItemByTitle node located in the Negative Tests test suite, parameterize the
titleKeyword element using the Bad Keywords column.

In the negative test cases we are sending our service unexpected data and verifying that it
returns the correct response or error response.
4. Right-click the Test Suite: getItemByTitle Unit Tests node and select Update Regression
Controls> Multiple Controls> Remove Existing Controls from the shortcut menu.
The old regression controls are removed and a regression control is created for each test run.
Notice that errors are displayed in the right GUI panel. The SOAP Faults received from the
server for the negative test case are displayed. The negative test case still succeeds because

23

Functional Tests

it received the response it expected from the server according to the regression control that
was created.

Testing Invalid Data

It is useful to test situations in which invalid data is sent to your service. For example, sending a string
when your service expects an integer.
1. Select the Test Suite: Functional Tests node and click the Add Test Suite button. The Add
Test Suite wizard displays.
2. Select Empty Test suite from the Add Test Suite wizard and click the Finish button. A new
test suite is added to the test suite tree with the test suite configuration panel displaying in the
right GUI.
3. Enter Sending Bad Data in the Name field in the right GUI.
4. Copy the Test 1: getItemById from the Negative Test node underneath the Test Suite: getItemById Unit Tests node.
5. Paste the Test 1: getItemById into the new Sending Bad Data test suite.
6. Select the Test 1: getItemById node within the Sending Bad Data test suite.
7. In the Form Input view in the right GUI panel, right-click the id element and disable (uncheck)
Enforce Schema Type from the shortcut menu. This tells SOAtest to allow sending data for id
element that does not conform to the schema - in this case, the schema indicates that the id
element is an int, but we'll send a string instead.

8. Enter the literal string Bad Data as the Fixed Value for the id element.

24

Functional Tests

9. Click the Run Tests toolbar button and view the response from the server in the Traffic
Viewer. Notice that an exception is thrown and displayed in the Response traffic.
10. Right-click the Test 1: getItemById node within the Sending Bad Data test suite and select
Create Regression Control from the shortcut menu.

25

Scenario Testing

Scenario Testing
For this section of the tutorial, please reference the test suite entitled "Scenario Test - Search, Place
Order, and Remove" in the SOATestTutorial.tst file
After unit tests have been created, they can be leveraged into scenario-based tests without any additional work. Scenario tests allow you to emulate business logic or transactions that may occur during
normal usage of the web service. This also allows you to find bugs that may surface only after a certain
sequence of events.
NOTE: If at any time during this exercise you receive a session expiration error message from the
server, click on the Customize Preferences toolbar button. In the Misc tab of the SOAtest Preferences dialog box that opens, click the Reset Cookies button, and then click OK.
The scenario test example given in the test suite Scenario Test - Search, Place Order, and Remove
represents a typical sequence of operations that a customer may invoke when using a book store web
service. In this case it represents a situation where a customer searches for a book, places an order for
that book, and then removes the previously placed order.
This scenario test introduces a tool called the XML Data Bank. This tool allows you to extract XML element values and store these values in memory to be used in later tests. In this example you will be
storing the book ID returned by the service after searching for a book, and then in the subsequent test,
use that ID to purchase the book. You will also store the order number returned after placing an order
for the book, and then in the subsequent test, use that order number to remove the order from the system.

Creating a Scenario Test Suite

To create this scenario, perform the following:
1. Select the Test Suite: Test Suite node from the previous exercise and click the Add Test
Suite button. The Add Test Suite wizard displays.
2. Select Empty Test suite from the Add Test Suite wizard and click the Finish button. A new
test suite is added to the test suite tree with the test suite configuration panel displaying in the
right GUI.
3. Enter Scenario Test - Search, Place Order, and Remove into the Name field
4. Copy the positive getItemByTitle, placeOrder, and removeOrder nodes from the previously
created Functional Tests test suite and paste them into the Scenario Test - Search, Place
Order, and Remove test suite.

These three tests represent a typical business transaction a customer may invoke and will be
the basis for our scenario test.

26

Scenario Testing

Configuring an XML Data Bank

To configure the XML Data Bank, complete the following:
1. Select the Test 2: placeOrder node in the Scenario Test - Search, Place Order, and
Remove test suite.
2. Select Books from the Data Source drop-down menu in the right GUI panel and select
Parameterized and Use Data Source Wizard from the itemId element drop-down menus.
After selecting Use Data Source Wizard, the Parameterize with value from existing test
response dialog displays.

3. In the Parameterize with value from existing test response dialog, complete the following:

Select Test 1: getItemByTitle from the Test menu at the top of the dialog.

Select the id element from the Expected XML tree and click the Add button. The id
element displays in the Selected XPaths list with a Data Source column name corresponding to the selected test.

Click the OK button. Test 1:id now displays in the right GUI panel as a parameterized
value for itemId. You will also notice that a Response SOAP Envelope> XML Data
Bank node now appears underneath the Test 1: getItemByTitle node in the Scenario Test - Search, Place Order, and Remove test suite.

4. In the right GUI panel, enter a Fixed value of 3 for the quantity element.

27

Scenario Testing

When this test is run, the value stored from Test 1 will be automatically inserted as the value
for the itemId element.
5. Select the Test 3: removeOrder node.
6. Select Books from the Data Source drop-down menu in the right GUI panel and select
Parameterized and Use Data Source Wizard from the orderNumber element drop-down
menus. After selecting Use Data Source Wizard, the Parameterize with value from existing test response dialog displays.

28

Scenario Testing

7. In the Parameterize with value from existing test response dialog, complete the following:

Select Test 2: placeOrder from the Test menu at the top of the dialog.

Select the order_number element from the Expected XML tree and click the Add
button. The order_number element displays in the Selected XPaths list with a Data
Source column name corresponding to the selected test.

Click the OK button. Test 2:order_number now displays in the right GUI panel as a
parameterized value for orderNumber. You will also notice that a Response SOAP
Envelope> XML Data Bank node now appears underneath the Test 2: placeOrder
node in the Scenario Test - Search, Place Order, and Remove test suite.

29

Scenario Testing

When this test is run, the order_number element value stored from Test 2 will be automatically inserted as the value for the orderNumber element.
8. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node and click the
Run Tests toolbar button.
Examine the Traffic nodes and notice that the itemId of the book returned from Test 1 is used
as the input for Test 2. Also, the order_number of the order placed in Test 2 is used as the
input for Test 3.
9. Right-click the Test Suite: Scenario Test - Search, Place Order, and Remove node and
select Update Regression Controls> Multiple Controls> Remove existing controls from
the shortcut menu. The tests are run and a Regression Control is added to each SOAP Client
test.
10. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node and click the
Run Tests toolbar button. Notice that all the tests now fail.
Examine the error messages that appear in the right GUI panel. These regression failures are
due to dynamic content that appears within the response messages. In the following steps we
will ignore elements with this type of dynamic data.
11. In the right GUI panel, right-click on each of only the first errors under each Test Suite node
and select Ignore XPath from the shortcut menu. In the Ignore XPath Settings dialog that
displays, click the OK button. You should ignore two XPaths in this step.
12. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node and click the
Run Tests toolbar button. All the tests should now succeed.
You have now created a fully functional scenario test that tests one possible business transaction that
may occur during normal usage of the book store service. For extra practice you can try to create other

30

Scenario Testing

scenarios that may possibly occur. Negative test cases could also be created for expanded test coverage.

31

Creating and Deploying Stubs

Creating and Deploying Stubs

Evolving services in a distributed SOA environment, and across multiple teams, is a complex endeavor
due to the interdependencies between the system and business processes. For example, in a system
that incorporates multiple endpoints such as credit card processing, billing, shipping, etc., it may be difficult for one team to test the responses from another team without interrupting normal business transactions.
With SOAtests stub generation capability we can test complex and distributed environments by automatically generating server stubs based on existing test suites. SOAtest can quickly and easily automate server emulation across multiple environments, thereby streamlining the collaborative
development and testing activities of multiple teams and ultimately speeding the SDLC.
In the following exercises, we will create stubs that emulate an existing Web service. The stubs will be
created automatically from an existing SOAtest test suite that tests the existing Web service. We will
also deploy the stubs locally and use the stubs for testing.

Creating Stubs
To create a stub, complete the following:
1. Open the Test Suite named StubClient.tst in the examples/tests directory. This is a
Test Suite comprised of three tests driven by a data source of three rows. The test suite consumes the actual Book Store web service described by the WSDL at http://soatest.parasoft.com/store-01.wsdl.
2. Select the main Test Suite: StubClient node and click the Run Test toolbar button. Nine tests
will run and succeed. From these tests, we will automatically generate a stub.
3. Right-click the Test Suite: StubClient node and select Create Stub from the shortcut menu.
The Create SOAtest Stub wizard displays.

By default, SOAtest will create a stub Test Suite named StubClientStub.tst.

4. Click the Next button. The Deploy Stub panel displays.

32

Creating and Deploying Stubs

By default, SOAtest will deploy the stub at the Endpoint http://localhost:9080/servlet/StubEndpoint?stub=StubClient.

5. Click the Finish button. SOAtest automatically creates the stub based on the existing Test
Suite and saves it as StubClientStub.tst. It then deploys the stub on the local Tomcat
Server at the default endpoint.

Viewing Deployed Stubs

To view the stubs deployed in the previous exercise, complete the following:
1. Select View> Show Tomcat Server. The Tomcat Server tab displays in the left GUI panel.
2. Expand the Stubs folder beneath the Tomcat Server node and select the StubClient node.
The settings for the StubClient stub display in the Project Configurations panel.

Using the Deployed Stubs

To use the previously created stubs to test the client, perform the following:
1. Select the Environments tab located at the bottom of the SOAtest GUI.

33

Creating and Deploying Stubs

2. Select Stub Environment from the left pane of the Environments tab and click the Set button. The test suite will now send messages to, and receive messages from, the emulated stub.
3. Click the Run Tests toolbar button. Nine tests will run and succeed.

Modifying Deployed Stubs

To modify deployed stubs, complete the following:
1. Open the Test Suite named StubClientStub.tst in the examples/tests directory.
2. Select the Test 1: getItemByTitle node. This is the stub for the getItemByTitle operation.
3. In the Project Configuration panel, select Response 1 within the Message Body tab. Notice
the end of the XPath Function: *[local-name(.)="titleKeyword"]/
text()="Linux". This stub returns the specified XML if the XPath function succeeds on the
request XML. In other words, if the getItemByTitle is Linux.

34

Creating and Deploying Stubs

4. Click on the Text area and modify the title element to return Linux Hacking Handbook
instead of Linux Administration Handbook.

5. Save the Test Suite.

6. In the Tomcat Server tab, right-click the Tomcat Server node and select Deploy Stubs from
the shortcut menu to re-deploy the modified stub.
7. Click the Run Test toolbar button.
Now when you run the StubClient.tst test suite, the response for getItemByTitle(Linux)
will contain the modified title. In this way, you can modify the behavior of the stubs. You can
also modify the XPath functions in a similar fashion.

35

Testing Plain XML Services

Testing Plain XML Services

Parasoft SOAtest can be used to test POX (Plain Old XML) services that are not necessarily SOAP
Web services. Many legacy system integration initiatives have relied on plain XML messaging, or
sometimes plain XML is preferred over SOAP Web services for performance reasons to reduce complexity. If a schema for the XML messages is available, tests can be generated automatically by SOAtest, without the need to provide sample XML messages.
Parasoft SOAtest support for plain XML services includes emulating a client that sends XML over one
of the supported protocols and APIs (e.g. HTTP, JMS, etc.), or emulating a server that responds with
XML over HTTP.
To generate a set of new tests using a schema:
1. Select the Test Suite: Test Suite node from the previous exercise and click the Add Test
Suite button. The Add Test Suite wizard displays.
2. Select New Project from the Add Test Suite wizard and click the Next button.
3. Select XML Schema from the Add Test Suite wizard and click the Next button. The XML
Schema dialog displays.

4. Enter http://soatest.parasoft.com/schema.xsd in the Schema Location field, or

Browse to a Schema on your machine.
5. Select Generate Messaging Client, to send plain XML messages.
6. Enter http://ws1.parasoft.com:8080/examples/servlets/Echo in the Endpoint field.
This specifies where XML messages are sent to. This field can be left blank if another protocol
is desired or if the URL is to be provided later.

36

Testing Plain XML Services

7. Click the Next button. A list of elements that are defined in the schema (directly, as well as
indirectly via imports) displays. You may select one or more of these elements, and a Messaging Client test will be generated for each selection. Select all by pressing CTRL while clicking
or pressing CTRL+A.
8. Click the Finish button. Three tests are created.

37

Custom Scripting

Custom Scripting
Please reference test suite Custom Scripting in SOATestTutorial.tst.
In the ever changing world of web services, there may be situations in which you have a testing
requirement which requires you to add custom functionality or logic to your tests cases. Due to the flexible nature of SOAtest, you can easily integrate custom scripts into your testing environment.
Using SOAtests Method tool, you can integrate custom scripts written in Jython (Java enabled
Python), Java, or Javascript into SOAtest. This means that almost any testing situation can be handled
with ease, even if the situation is not directly supported by SOAtests current tool set.
In this example you will create a Scenario Test using the book store service used in previous examples. In this Scenario you will search for a book by its title, save the price of that book in memory using
the XML Data Bank, and finally write the price of the book along with the current date to a file on disk.
1. Select the Test Suite: Test Suite node and click the Add Test Suite button. The Add Test
Suite wizard box displays.
2. Select Empty Test suite from the Add Test Suite wizard and click the Finish button. A new
test suite is added to the test suite tree with the test suite configuration panel displaying in the
right GUI.
3. Enter Custom Scripting in the Name field in the right GUI.
4. Select the Test Suite: Custom Scripting node and click the Add Test button. The Add Test
wizard displays.
5. Select SOAP Client from the right pane of the Add Test wizard and click Finish. A SOAP Client tool is added to the test suite.
6. Select the Test 1: SOAP Client node underneath the Test Suite: Custom Scripting node
and enter Validate Price Value in the Name field in the right GUI Panel.
7. In the WSDL URI field, enter the following:
http://soatest.parasoft.com/store-01.wsdl

8. Select getItemByTitle from the Operation drop down box in the right GUI panel.
9. Enter Linux as the Fixed value in the titleKeyword element entry box.

38

Custom Scripting

10. Right-click the Test 1: Validate Price Value node and select Add Output. The Add Output
wizard displays.
11. In the Add Output wizard, select Response> SOAP Envelope from the left pane, and XML
Data Bank from the right pane, and click Finish. An XML Data Bank is chained to the XML
Response output of the SOAP Client.
12. Select the XML Data Bank node beneath the Test 1: Validate Price Value node.
13. Select the price element in the XML Tree view in the right GUI panel and click the Add button.
The value stored in Test 1: price will be used in the next test.
14. Select the Test Suite: Custom Scripting node and click the Add Test button. The Add Test
wizard displays.
15. In the Add Test wizard, select Standard Test from the left pane, and Method from the right
pane, and click Finish. A Method tool is added to the test suite.
16. Select the Method Tool node and enter Price Logger Method in the Name field.
17. Select Python from the Language drop-down menu and enter the following script in the Text
field:
def checkPrice(input, context):
price = float(input.toString())
if price > 0:
return 0
else:
return 1

39

Custom Scripting

This script ensures that the price value is positive.

18. Right-click the Method Tool Text window and select Evaluate from the shortcut menu.
If any syntax errors are present, they will be displayed in the Message window at the bottom of
the GUI. Otherwise, the method name will appear in the Method drop down box. Make sure
that the method checkPrice() is the selected method.

19. Select the Test Suite: Custom Scripting node and click the Run Tests toolbar button. Look
in your user home directory for a file called priceLog.txt.

40

Asynchronous Testing

Asynchronous Testing
For this section of the tutorial, please reference the test suite entitled "Asynchronous Testing" in the
SOATestTutorial.tst file
In this age of flexible, high performance web services, asynchronous communication is often used to
exchange data, allowing the client to continue with other processing rather than blocking until a
response is received. SOAtest comes packaged with a Tomcat server that runs in the background and
manages the asynchronous Call Back messages received. SOAtest supports the major asynchronous
communication protocols including Parlay, SCP, and WS-Addressing.
In this example we will use a simple Web service which takes a string as input and then echos this
string back to the client in an asynchronous message exchange. This web service uses the WSAddressing protocol. We will need to send a Message ID which is used by SOAtest to identify the message when the Call Back Message is received and a Call Back URL so that the service knows where to
send the Call Back Message.
Note: It is likely that you will not be able to run the scenario in this exercise because of firewall restrictions. In order to successfully invoke this service, your machine would need to be accessible over the
Internet by the Parasoft machine which sends the asynchronous response (HTTP post to SOAtest).
1. Select the Test Suite: Test Suite node and click the Add Test Suite button. The Add Test
Suite wizard displays
2. Select New Project from the Add Test Suite wizard and click Next twice to advance to the
WSDL dialog.
3. Enter the following into the WSDL URL field:
http://bpel.parasoft.com:8888/bpel/echoAsync?WSDL

4. Make sure the Create functional tests from the WSDL checkbox is selected and Generate
Web Service Clients is the selected option. Create WSDL Tests should not be selected.

41

Asynchronous Testing

5. Click Next until you advance to the Layout dialog.

6. In the Layout dialog, choose the Asynchronous Messaging radio button and the WSAddressing radio button and click Finish. A test suite folder is created which contains automatically configured asynchronous test cases for each operation defined within the WSDL.
7. Enter Asynchronous Testing in the Name field in the right GUI panel.

Notice that two tests have been created under the echo(string) folder. The first test is a SOAP
Client test which will send an initial request to the asynchronous service. The second is a tool
called the Call Back tool. Using the Call Back tool, SOAtest is able to listen for call back messages that are sent in an asynchronous messaging exchange. A Tomcat server has been integrated into SOAtest, allowing the Call Back tool to listen for these incoming messages. For this
reason, it is important that the Tomcat server is running before executing these examples.
8. Select View> Show Tomcat Server from the SOAtest menu bar at the top of the GUI. The
Tomcat Server tab appears in the left GUI panel.
9. Right-click the root Tomcat Server node and select Start Tomcat. The light next to the node
should turn green indicating that the server has been started.

42

Asynchronous Testing

10. Click on the Tests tab to return to the Test Suite view.
11. Click on the Test 1: echo async node in the Asynchronous Testing test suite.
12. In the Form Input view in the right GUI panel, enter the fixed value Hello, world as the echoString input parameter to this operation.
13. On the right side of the SOAP Client GUI, change the selected tab from Body to Header.
Notice that the SOAP Headers defined within the WSDL have been automatically created and
added to this test case.

14. Click on the Test 2: echo call back node in the Asynchronous Testing test suite. In the right
GUI panel, notice that the Call Back Tool has been automatically configured to use the WSAddressing protocol. When this test case is run, the Call Back Tool will listen for incoming
messages with the same MessageID that was generated in Test 1: echo async.

43

Asynchronous Testing

15. Select the Test Suite: Asynchronous Testing node and click the Run Tests toolbar button.
All the tests should succeed and the Call Back XML Message should appear in the right GUI
panel.

44

WS-Security

WS-Security
For this section of the tutorial, please reference the test suite entitled "WS-Security" in the
SOATestTutorial.tst file
In the world of Web services, security has become an important issue in every day Web service transactions. Ensuring that your security measures work flawlessly, including encryption of data as well as
digital signatures on documents, is an important aspect of Web services security testing that must be
done thoroughly before your web service hits the production line.
SOAtest contains a vast array of security tools and options that fully supports the industry standard
WS-Security specification. In the example given in the WS-Security test suite, examples of encryption/
decryption, digital signature, and the addition of SOAP Headers are shown. The following are key
security tools and options that SOAtest supports:

XML Encryption Tool: The XML Encryption tool allows you to encrypt and decrypt entire messages or parts of messages using Triple DES, AES 128, AES 192, or AES 256. In WS-Security
mode, Binary Security Tokens, X509IssuerSerial, and Key Identifiers are supported.

XML Signer Tool: The XML signer tool allows you to digitally sign an entire message or parts
of a message depending on your specific needs. In some cases it may be important to digitally
sign parts of a document while encrypting other parts.

XML Verifier Tool: The XML verifier tool allows for the verification of digitally signed documents using a public/private key pair stored within a key store file.

Key Stores: The use of key stores in SOAtest allows you to encrypt/decrypt and digitally sign
documents using public/private key pairs stored in a key store. Key stores in JKS, PKCS12,
BKS, and UBER format can be used.

Username Tokens, SAML Tokens, X509 Tokens, or Custom Headers: SOAtest supports
sending custom SOAP Headers and includes templates for Username Tokens and SAML
tokens.

Unlimited Strength Java Cryptography Extension

Important: In order to perform security tests using the XML Verifier, XML Signer, or XML Encryption
tools, or if using Key Stores, you will need to download and install the Unlimited Strength Java Cryptography Extension. To do so, go to http://java.sun.com/javase/downloads/index_jdk5.jsp and
download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 5.0.
The files downloaded should be installed into the following directories on your machine:
For Windows:
C:\Program Files\Parasoft\SOAtest\[SOAtest version number]\JRE\1.5.0\lib\security.

For UNIX:
[JRE installation directory]/lib/security

or
[J2SDK installation directory]/jre/lib/security

45

WS-Security

Message Layer Security with SOAP Headers:

In this example we will use a book store web service, which requires a Username and Password to be
submitted within the SOAP Header element according to the WS-Security specification. SOAtest provides the ability to add Custom Headers and also provides pre-defined templates for creating Username Tokens and SAML Tokens. The following example uses a Username Token.
1. Select the Test Suite: Test Suite node and click the Add Test Suite button. The Add Test
Suite dialog box displays.
2. Select Empty Test Suite and click Finish. An empty test suite folder is created.
3. Type WS-Security into the Name field in the right GUI panel.
4. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add Test
Suite dialog box displays.
5. Select Empty Test Suite and click Finish. An empty test suite folder is created.
6. Type Username Tokens into the Name field in the right GUI panel.
7. Select the Test Suite: Username Tokens node and click the Add Test button. The Add Test
wizard displays.
8. In the Add Test wizard, select Standard Test from the left pane, and SOAP Client from the
right pane, and click Finish. A SOAP Client tool is added to the test suite.
9. Select the Test 1: SOAP Client node beneath the Test Suite: Username Tokens node and
complete the following in the right GUI panel:

Enter SOAP Client getItemByTitle operation in the Name field.

Enter the following in the WSDL URI field:

http://soatest.parasoft.com/store-wss-01.wsdl

Press the Tab button on your keyboard to populate the rest of the SOAP Client GUI
based on parsed values from the WSDL.

Select getItemByTitle(string) from the Operation drop-down menu.

For the title element, select Keywords as its Parameterized value.

10. Click the Run Tests toolbar button. Notice that the test fails because it did not have the
required Security Header.
11. Select the Test 1: SOAP Client node.
12. Select the Header tab in the right GUI panel and then click the Add button. A Choose Header
Type dialog appears.

46

WS-Security

13. Select WS-Security and click OK. The WS-Security GUI displays in the right GUI panel.
14. In the Timestamp tab in the right GUI panel, uncheck the Send Timestamp checkbox.
15. Select the Username Token tab in the right GUI panel and complete the following:

Enter soatest in the wsse:Username field.

Enter soatest in the wsse:Password field.

16. Click the Run Tests toolbar button. The test now succeeds. Select the Traffic Viewer node to
view the SOAP Header sent in the request and verify that the service returned information
about the specified books.

47

WS-Security

Now you can create a Regression Control to alert you to any changes in the server response in
the future.
17. Right click on Test 1: SOAP Client getItemByTitleOperation node and select Create
Regression Control> Multiple Controls from the shortcut menu. A regression control is created.
If you run the test a few more times you will notice that it fails because the price element has
changed. Follow the steps from previous exercises to ignore the dynamically changing price
value.

Using the XML Encryption Tool:

In this example, we will use a book store service similar to the service used in previous examples,
except that:

Request bodies must be encrypted using the key store soatest.pfx which is located in the
examples\keystores directory.

Responses are encrypted as well and can be decrypted using the same key store.

First you will need to set up the key store:

1. Right-click the Test Suite: WS-Security node and select Add to Project> Add Global. The
Add Global wizard displays.
2. Select Add Key Store and click Finish. A Key Store node displays. You will use this to access
the keys within the key store soatest.pfx which can be found in home\tests\tutorial\keystores.
3. Select the Key Store node and configure the following settings in the Key Store GUI:
a. Enter PKCS12 Keystore in the Name field in the GUI panel.
b. Make sure the Use same key store for private key checkbox is selected.
c.

Click the Browse button and navigate to the location of the key store soatest.pfx.

d. Enter security in the Key Store Password field and select the Save key store password check box. This will enable SOAtest to remember the keystore password the
next time the test suite is opened.
e. Select PKCS12 from the Key Store Type drop-down menu.
f.

Click the Load button. The list of available certificate aliases within the keystore are
populated into the Certificate Alias drop-down menu.

g. Select soatest in the Certificate Alias field.

h. Click the Private Key tab at the bottom of the Key Store configuration panel and enter
soatest for the Private Key Alias and enter security for the Private Key Password.
i.

Select the Save key store password check box.

48

WS-Security

Now we are ready to set up a test using the XML Encryption tool. To better organize our security tests, we will create a new folder for the encryption test.
4. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add Test
Suite wizard displays.
5. Select Empty Test Suite and click Finish. An empty test suite folder is created.
6. Type Encryption/Decryption into the Name field in the right GUI panel.
7. Select the Test Suite: Encryption/Decryption node and click the Add Test button. The Add
Test wizard displays.
8. Select Standard Test from the left pane, and select SOAP Client from the right pane, and
click Finish. A SOAP Client tool is added to the test suite.
9. Select the Test 1: SOAP Client node beneath the Test Suite: Encryption/Decryption node
and complete the following in the right GUI panel.

Enter SOAP Client getItemByID operation in the Name field.

Enter the following in the WSDL URI field:
http://soatest.parasoft.com/store-wss-03.wsdl

Press the Tab button on your keyboard to populate the rest of the SOAP Client GUI
based on parsed values from the WSDL.

Select getItemById from the Operation drop-down menu.

For the id element, select ID as its Parameterized value.

10. Right-click the Test 1: SOAP Client - getItemByID operation node and select Add Output
from the shortcut menu. The Add Output wizard displays.
11. Select Request> SOAP Envelope from the left pane, and select XML Encryption from the
right pane, and click the Finish button. An Encryption Tool is chained to the SOAP Client.

49

WS-Security

12. Select the Request SOAP Envelope -> XML Encryption node and complete the following:

Select the Encrypt radio button.

Select the WS-Security Mode check box.

Select AES 256 from the Symmetric (Block Encryption) drop down menu.

Select the Encrypt SOAP Body (WS-Security Mode) check box. This will encrypt the
XML Body element.

Choose X509BinarySecurityToken from the drop-down menu in the WS-Security

Options. The XML Request is now set up to be encrypted when the request is sent to
the service.

Now you can add an XML Encryption Tool to the XML Response of the SOAP Client test to
enable Decryption of the XML response.
13. Right-click the Test 1: SOAP Client - getItemByID operation node and select Add Output
from the shortcut menu. The Add Output wizard displays.
14. Select Response> SOAP Envelope from the left pane, and select XML Encryption from the
right pane, and click the Finish button. An Encryption Tool is chained to the SOAP Client.

50

WS-Security

15. Select the Response SOAP Envelope -> XML Encryption node and complete the following:

Select the Decrypt radio button.

Select the PKCS12 Keystore from the Key Store drop down menu.

16. Click the Run Tests toolbar button and then select the Traffic Viewer node to view the
encrypted data.
17. Right-click the Test 1: SOAP Client - getItemByID operation node and select Create
Regression Control -> Multiple Controls. A Regression Control is created and automatically
chained to the Response SOAP Envelope -> XML Encryption. Notice that the decrypted
responses are shown in the Regression Control.
Finally, you want to ignore dynamic values from the XML Response so that the Regression
Control does not fail each time.
18. Select the XML Document -> Diff Control node and complete the following in the right GUI
panel:

Select the Form XML tab. When the Form XML tab is selected, a popup will appear
asking whether to override with values from Literal XML view. Click Yes.

Right-click the price element and select Setup Ignored XPath from the shortcut
menu. An Ignore XPath Setting dialog appears. Click OK to ignore modifications to
the text content of the price element.

Repeat the previous step for the CipherValue element.

Right click on the DataReference element and select Setup Ignored XPath. An
Ignore XPath Setting Dialog appears. Select the Attribute check box to ignore
changes to the attributes of the DataReference element. Click OK.

Click on the Literal XML tab to switch back to Literal XML view.

19. Click the Run Tests toolbar button. The test succeeds and ignores dynamic values in the
Regression Control.

Using the XML Signer Tool

In the next example, we will use a book store service which requires request bodies to be signed with
the certificate in the key store soatest.pfx. Responses from this service are signed as well and can be
verified using the same key store. We will use the same key store settings from the previous example.
1. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add Test
Suite dialog box displays.
2. Select Empty Test Suite and click Finish. An empty test suite folder is created.
3. Type Sign/Verify into the Name field in the right GUI panel.
4. Select the Test Suite: Sign/Verify node and click the Add Test button. The Add Test wizard
displays.
5. Select Standard Test from the left panel and SOAP Client from the right panel and click Finish. A SOAP Client tool is added to the test suite.
6. Select the Test 1: SOAP Client node beneath the Test Suite: Sign/Verify node and complete
the following in the right GUI panel.

Enter SOAP Client placeOrder operation in the Name field.

Enter the following in the WSDL URI field:

http://soatest.parasoft.com/store-wss-02.wsdl

51

WS-Security

Press the Tab button on your keyboard to populate the rest of the SOAP Client GUI
based on parsed values from the WSDL.

Select placeOrder from the Operation drop-down menu.

Select the itemId parameter and select ID as its Parameterized value.

Select the count parameter and enter 1 as its Fixed value

7. Right-click the Test 1: SOAP Client - placeOrder operation node and select Add Output
from the shortcut menu. The Add Output wizard displays.
8. Select Request> SOAP Envelope from the left panel, and select XML Signer from the right
panel, and click Finish. An XML Signer Tool is chained to the SOAP Client.
9. Select the Request SOAP Envelope> XML Signer node beneath the Test 1: SOAP Client placeOrder operation node and complete the following in the right GUI panel:

Select RSAwithSHA1 (PKCS1) http://www.w3.org/2000/09/xmldsig#rsa-sha1

from the Algorithm drop down menu.

Select PKCS12 Keystore from the Key Store drop down menu.

Select the Sign SOAP Body (WS-Security Mode) check box. This will sign the XML
Body element.

Select the WS-Security Mode check box and choose X509IssuerSerial from the drop
down menu.
The XML Request is now set up to be signed when the request is sent to the service.

Now you can add an XML Verifier Tool to the XML Response of the SOAP Client test to
enable Signature Verification of the XML response:
10. Right-click the Test 1: SOAP Client - placeOrder operation node and select Add Output
from the shortcut menu. The Add Output wizard displays.
11. Select Response> SOAP Envelope from the left pane, and select XML Signature Verifier
from the right pane, and click Finish. An XML Encryption Tool is chained to the XML Signer.
12. Select the XML Response -> XML Signature Verifier tool node beneath the Test 1: SOAP
Client - placeOrder operation node and complete the following in the right GUI panel:

52

WS-Security

Choose PKCS12 Keystore from the drop-down menu.

Select the WS-Security Mode check box.

13. Click the Run Tests toolbar button and select the Traffic Viewer node to view the signed data.
Since the test succeeds this tells us that the server accepted our signed request and the
servers signed response was successfully verified.

XML Encryption and Signature Combined

In this example, we will create a more complex test using a book store service which combines the
security requirements of the previous two exercises. This service requires request bodies to be signed
and encrypted using the key store soatest.pfx. The responses from this service are signed and
encrypted as well and can be decrypted and verified using the same key store.
1. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add Test
Suite dialog box displays.
2. Select Empty Test Suite and click Finish. An empty test suite folder is created.
3. Type Encryption and Signature Combined into the Name field in the right GUI panel.
4. Select the Test Suite: Encryption and Signature Combined node and click the Add Test
button. The Add Test wizard displays.
5. Select Standard Test from the left pane, and select SOAP Client from the right pane, and
click Finish. A SOAP Client tool is added to the test suite.
6. Select the Test 1: SOAP Client node beneath the Test Suite: Encryption and Signature
Combined node and complete the following in the right GUI panel.

Enter SOAP Client getItemByTitle operation in the Name field.

Enter the following in the WSDL URI field:

http://soatest.parasoft.com/store-wss-04.wsdl

Press the Tab button on your keyboard to populate the rest of the SOAP Client GUI
based on parsed values from the WSDL.

Select getItemByTitle from the Operation drop-down menu.

Select the string title parameter and enter Linux as its Fixed value.

7. Right-click the Test 1: SOAP Client - getItemByID operation node and select Add Output
from the shortcut menu. The Add Output wizard displays.
8. Select Request> SOAP Envelope from the left pane, and select XML Signer from the right
pane, and click the Finish button. An XML Signer Tool is chained to the SOAP Client.
9. Select the XML Request -> XML Signer Tool node beneath the Test 1: SOAP Client - getItemByID operation node and complete the following in the right GUI panel:

Select RSA from the Algorithm drop down menu.

Select PKCS12 Keystore from the Key Store drop down menu.

Select the Sign SOAP Body (WS-Security Mode) check box. This will sign the XML
Body element.

Select the WS-Security Mode check box and choose X509IssuerSerial from the drop
down menu.
The XML Request is now set up to be signed when the request is sent to the service.

Next you can add an XML Encryption Tool to the XML Response of the XML Signer Tool to
encrypt the signed document.

53

WS-Security

10. Right-click the Request SOAP Envelope> XML Signer node and select Add Output from the
shortcut menu. The Add Output wizard displays.
11. Select XML Encryption and click the Finish button. An XML Encryption Tool is chained to the
SOAP Client.
12. Select the Signed XML Document> XML Encryption Tool node and complete the following
in the right GUI panel:

Select the Encrypt radio button.

Select the Use Key Store radio button and choose PKCS12 Keystore from the Key
Store drop down menu.

Select AES 256 from the Algorithm drop down menu.

Select the Encrypt SOAP Body (WS-Security Mode) check box and choose
X509IssuerSerial from the drop-down menu.

13. Click the Run Tests button. The XML Request is first signed and then encrypted.
14. Click the Traffic Viewer node to view the server response.

Automatically Generating WS-Security Tests with

WS-SecurityPolicy
Parasoft enables automatic test creation to enforce runtime security policies. This helps users automatically generate the correct tests with the correct settings so the services can be invoked instantly.
Furthermore, by managing the policies at the project test level, users can more easily create and manage various policy variations in order to test the services properly, both positive and negative.
SOAtest recognizes WS-SecurityPolicy assertions in the WSDL when using the WS-PolicyAttachment
standard. In order to automatically generate tests from a WSDL with WS-SecurityPolicy assertions,
complete the following:
1. Select the Test Suite: Test Suite node and click the Add Global Property button. The Add
Global Property wizard displays.

54

WS-Security

2. Select Add WS-Policy Bank and click the Finish button. A WS-Policy Banks node is added
to the test suite tree.
3. In the Project Configuration panel, enter http://soatest.parasoft.com/store-wss04.wsdl in the WSDL URL field and click the Refresh from WSDL button. The Global Policies
are populated.

55

WS-Security

Notice how there are policy nodes that include the WS-SecurityPolicy configuration that corresponds to the WS-SecurityPolicy assertions in the WSDL. Notice how the tests generated are
automatically configured with the signer and encryption tool on the request, because the policy
dictates so. Since a keystore has already been added to the test suite, the tests are ready to
run. If you have not added a keystore, one needs to be configured. For more information on
adding a keystore, see Using the XML Encryption Tool:, page 48.

56

Design and Development: Policy Enforcement

Design and Development:

Policy Enforcement
For this section of the tutorial please reference the test suite titled Governance in the SOAtestTutorial.tst file.
As a greater number of Service Oriented Architectures (SOA) are deployed throughout the industry,
the need arises to enforce policies and best practices on all components of the SOA. Policy enforcement over these components will help to ensure interoperability, consistency, and re-usability throughout the life cycle of the SOA.
SOAtest provides SOA architects the ability to create and manage design-time SOA policies. A SOAtest policy now combines both static analysis policy configurations for XML artifacts (WSDLs, schemas and SOAP) as well as semantic and schema validation tests.
SOAtest allows an architect to create a policy configuration which combines CodeWizard rule assertions with test assertions such as Schema validity and WS-I interoperability. The new SOA policy configuration interface is very similar to rule configurations in Parasoft's language products. SOAtest
saves and loads policies in an XML format which extends on WS-Policy.

Rule Set Configuration

A rule is a representation of a pattern that you do not want to appear in your XML. A rule set allows for
the grouping of rules by containing a collection of rule references.
Note: Detailed information about creating rules can be found in the SOAtest RuleWizard documentation (press shift+F1 in the SOAtest GUI).
Custom rule sets are created by adding a group of rules to a RuleEnforcer tool, then clicking the Save
Rule Set button in the RuleEnforcer panel. If you want to add rules from a custom rule set, such as a
rule set that contains team guidelines, you must have the rule set (.rs) file and the related rule (.rule)
files. When adding a rule set, SOAtest references the rules listed in the rule set, however, if the related
rule files are not available, SOAtest cannot enforce those rules.
A rule set contains a grouping of rules, each of which can be enabled or disabled. Rules that are disabled have an unselected check box adjacent to their name. A disabled rule will not be executed when
the corresponding RuleEnforcer tool is run. This is an effective way of enforcing policy on SOA components which may change depending on the testing environment.

Parasoft Team Configuration Manager

The Team Configuration Manager (TCM) helps you standardize team-wide settings for Parasoft AEP
(Automated Error Prevention) technologies. For instance, TCM can manage and automate the sharing
of team-standard test settings, custom coding standard rules, tests, and general preferences. It also
helps control access to the modification of coding rules.
Once TCM is installed and deployed, the team architect or manager can configure the appropriate
team-standard settings and upload the necessary files (team rule sets for example) needed for policy
enforcement. Finally, testers and developers can reference files on the TCM server to ensure that
everyone on the team is using the same team configurations.

57

Design and Development: Policy Enforcement

Enforcing Design-time SOA Policies

For this example we will create policy enforcement tests for a book store service with the WSDL
located at http://soatest.parasoft.com/store-01.wsdl.
1. Select the root Test Suite: Test Suite node and click the Add Test Suite button. The Add
Test Suite wizard displays.
2. Select New Project from the Add Test Suite wizard and click the Next button twice to
advance to the WSDL dialog.

3. Select http://soatest.parasoft.com/store-01.wsdl from the WSDL URL field.

4. Check the Create tests to validate and enforce policies on the WSDL check box and make
sure the Create functional tests from the WSDL check box is also checked.
5. Click Next until you advance to the Policy Enforcement dialog.

58

Design and Development: Policy Enforcement

6. Select the Apply Policy Configuration check box. This will create WSDL and functional tests
that will enforce the assertions defined in the specified policy configuation.
The default policy configuration, soa.policy, is a collection of industry-wide best practices. To
use a custom policy configuration, you can either use the Browse button to select a policy
configuration (see Defining Custom SOA Policies for more information) or the policy configuration's path can be entered in the text field.
7. Click the Finish button. The newly created tests display in the left GUI panel of SOAtest and
the Test Suite configuration controls display in the right GUI panel.
8. In the right GUI panel, enter Policy Configuration in the Name field.

59

Design and Development: Policy Enforcement

9. Expand the Test Suite: WSDL Tests node beneath the Test Suite: Policy Configuration
node. Notice that Test 4: Policy Enforcement has been added to Test Suite: WSDL Tests.
10. Expand the Test 4: Policy Enforcement test to view its chained tools. You will see two Rule
Enforcer tools, one for enforcing rules on the WSDLs and one for enforcing rules on the schemas.
The first tool, WSDL> WSDL Policy Enforcer, is chained to the WSDL Output of the Test 4:
Policy Enforcement test and thus is passed the base WSDL and all imported WSDLs for rule
enforcement. The second Rule Enforcer tool titled Schema> Schema Enforcer is chained to
Test 4: Policy Enforcement's Schema Output and thus is passed all schema files referenced in
the WSDL for rule enforcement.
11. Expand one of the tests in the Test Suite: store-01.wsdl node and notice that a referenced
Rule Enforcer tool titled Response SOAP Envelope> SOAP Policy Enforcer has been
chained to the Test. This tool will apply its contained policy configuration on the messages
received by this test client. The tool is a reference to a Global Tool in the Tools Test Suite
under the root Test Suite. For more information on Global Tools see the SOAtest Users
Guide.
12. In the Test Suite: WSDL Tests node beneath the Test Suite: Policy Configuration node,
select the Test 4: Policy Enforcement Test and click the Run Tests toolbar button. This will
run policy enforcement tests on the WSDL and schema files. If any errors occur, they will display in the Test Results panel. Some failure messages, such as Schema Validity and Semantic Validity failures, can be double-clicked for more information. Otherwise, you can right-click
and select View Help File.

Defining Custom SOA Policies

In the previous exercise, we enforced policies using a default policy configuration. For this example, we
will define a custom SOA policy.

60

Design and Development: Policy Enforcement

1. Select File> New> Policy Configuration. The Policy Configuration panel displays in the
right GUI pane of SOAtest and lists assertions that correspond to policy enforcement rules and
WSDL tests.

2. From the Policy Configuration panel, you can configure the following:

Sort the rules by Artifact (default) or Category from the Sort by drop-down menu.

Enable/disable individual assertions by selecting or unselecting corresponding check

boxes. You may also select assertions by using the arrow keys on your keyboard and
enable/disable by using the space bar.

Edit or Remove an assertion by right-clicking it and selecting accordingly from the

shortcut menu, then click the Reload button to update accordingly.

Access help documentation for assertions by right-clicking and selecting View Documetation from the shortcut menu.

Create new rules or import rules using SOAtests RuleWizard feature by selecting
File> New> Rule or pressing Ctrl+Shift+R.

3. Click Save to save the custom policy to the default SOAtest rules folder. The policy configuration you define can be used later to automatically create tests to enforce policies.

61

Load Testing

Load Testing
Once unit tests and functional tests have been created, the next step is to load test your web service.
Load testing your web service allows you to emulate conditions of heavy usage, which can expose
bugs that may only surface under these conditions. The SOAtest Load Testing Solution allows you to
have full control over all aspects of the load testing process including the following areas:

Enslaving Multiple Machines (Clustering): Using this option you can enslave multiple
machines (running SOAtest) on your network allowing you to generate larger amounts of load
than what a single machine can generate. Click on the Machines folder in the load test window and explore the GUI that appears. For each machine, users have the option for High
Throughput mode, which generates higher load intensities using the same hardware by disabling certain response processing operations.

User Profiles: Creating user profiles allows you to directly relate your load test back to your
functional tests. This means that once you have created your functional tests, no further work
is required to begin load testing your service. Double Click on the Profiles folder in the load
test window and view each of the profiles that have been created.

Custom Scenarios: SOAtest provides four default load testing scenarios (Bell, Buffer Test,
Linear Increase, and Steady Load) or allows you to create your own custom scenario. These
scenarios can be created to emulate possible real life scenarios that may occur during normal
usage of your web service. Click on the Scenarios folder and view the scenarios that are provided for this example.

Monitors: Monitors can be added to SOAtest to monitor various system resources as your
load test occurs. Right Click on the Monitors folder to view the monitors that are available to
be added. SOAtest supports SNMP, Windows Perfmon, and JMX monitors.

Creating and Performing a Load Test

For this example, we will create a load test using the test cases we have created in the previous exercises. To perform a simple load test, complete the following:
1. Make sure the test suite from the previous exercise is loaded.
2. Right-click the Test Suite: Test Suite node and select Create Load Tests from the shortcut
menu. The New Load Test wizard opens with the VU Profiles panel.

62

Load Testing

3. Select the desired test suites for which you would like to assign virtual users and click Next.
4. In the Schedule & Distribution panel, enter 2 Minutes for the Duration, select Linear
Increase for the Distribution, and click Next until you reach the Other Options panel.
Note: In order to select the Linear Increase option, you must have the appropriate Load Testing license. If you do not have Virtual Users enabled on your license, you will only be able to
generate the Steady Load scenario.
5. In the Other Options panel, select the Start Load Test immediately checkbox and click Finish. SOAtest will begin the Load Test of the Store Web service. A new Load Tests tab displays in the left GUI panel and the Graph tab displays in the Load Test progress panel.
Note: For more information on the New Load Test wizard, see the SOAtest Users Guide.

63

Load Testing

The load test can be stopped at any time, but we will let it run the full 2 minutes while monitoring and manipulating the in-progress details of the test.
6. At the bottom of the Results panel, notice all of the Plotted parameters checkbox options. The
curve for each of these parameters displays in the in the Graph tab.
By monitoring the details in the Graph tab, you will notice the following:

The Virtual Users curve climbs in a steady, linear fashion, in accordance to the Linear
Increase scenario chosen in Step 4 of this procedure.

The Test Errors curve should remain at zero if no errors are encountered during the
load test.

The Tests Completed and the Tests Started curves should closely match each
other, indicating that the tests are being served quickly (i.e. the responses are
received quickly). If there is a wider gap between these curves, the execution time of
the tests is longer.

7. In the right GUI panel, you can view additional details about the load test in the Snapshot and
Log tabs.

The Snapshot tab displays the current active virtual users and the operations they are
invoking. During test execution, the information in this tab is updated every three seconds.

The Log tab displays information about errors that occur during test execution.

8. If the load test is still running, click the Stop toolbar button.
After the load test is complete, a Test Information summary is displayed in the Results panel
which includes the name of the project, when the load test was started and finished, the scenario you chose, as well as any machines and profiles.

64

Load Testing

In addition to viewing the Test Information summary, you can also choose to view different statistical
reports of the load test as well. To view detailed statistics of the load test, complete the following:
1. Select Statistics from the Views menu in the Results panel.

When viewing the Statistics report, an Output Types menu is available. The Output Types
menu determines what type of output report is displayed. Two types of reports are available

65

Load Testing

from this menu, each of which displays different columns of information. The differences
between report types are:

Generic Reports: Contains Test Suite name, Test Index, Test Name, Min/Max/Avg
Time (ms), Run Count, and Failure Count.

SOAP Reports: Contains all of the information in Generic Reports plus Min/Max/Avg
Ping (ms), Min/Max/Avg Request Size (bytes), Min/Max/Avg Response Size (bytes)
Min/Max/Avg Total Size (bytes).

2. To access details about a specific test failure, double-click the related report row. You can
determine whether a given test failed by locating the row that represents that test, then checking the number in that rows Failure Count column.
For more information on viewing load test results, see the SOAtest Users Guide.

Customizing Load Test Profiles and Scenarios

You can customize how a particular load test is run by customizing the profiles and scenarios you plan
to use. You can determine the length of time a load test lasts, the distribution of virtual users, the hit
rate over time and machines, and the distribution of user profiles over time.
To customize the load test, complete the following:
1. Double-click the Profiles folder in the Load Tests tab and select the Test Suite node. The
Test Suite controls display in the Results panel.

2. At the bottom of the Results panel, change the Delay Value to 3 seconds. This may simulate
how a user hesitates before making a decision about ordering a book.
3. Select Linear Increase beneath the Scenarios node. The Linear Increase scenario controls
display in the Results panel and the User graph displays the localhost curve.

66

Load Testing

4. Drag and drop the endpoint of the localhost curve to the coordinates of 10 users at 10 minutes.

5. At the bottom of the right GUI panel, change the Duration of the load test from 10 to 2 minutes. Normally, you may want your load tests to run for longer periods of time. But for this exercise, we will keep the duration period short.
6. From the Vertical scale drop-down menu, select 20.
7. Click the More Points button. A point will appear at the center of the localhost line.
8. Click and drag the new point to the coordinates of 10 users at 1 minute.

67

Load Testing

9. Click the Scenarios folder in the Load Tests tab of the left GUI panel. The Report Settings
controls display in the right GUI panel.
Select both the Record graph data and error details and Record individual hits checkboxes in the right GUI panel. These options will enable you to view graph data within the
Detailed Report of the load test even after it is completed.
You have now created a customized load test to meet your anticipated loads. For more
detailed information on customizing load test scenarios, see the SOAtest Users guide.
10. Expand the Linear Increase node and select the QoS node beneath it. Summary and Details
tabs display in the right GUI.
11. Select the Details tab in the right GUI and click the New button. The Add Metric wizard displays.

68

Load Testing

12. Select Statistic Metric from the Add Metric wizard and click Finish. The new metric displays
in the right GUI panel.
13. Enter Execution Time Requirement in the Name field.
14. For the Statistic drop-down menus in the right GUI, select Avg. Exe. Time (ms) and the less
than symbol (<), and then enter 200 in the text field.

This will cause the load test result to fail if the execution time is measured above 200 milliseconds. For more information on configuring QoS metrics, see the SOAtest Users Guide.

69

Load Testing

15. Select the Linear Increase node beneath the Scenarios branch and click the Load Test toolbar button. SOAtest will begin the customized load test and the Graph tab displays in the right
GUI panel.
16. Wait (2 minutes) for the load test to complete. While the load test is running, you can view various parameters within the Graph tab by selecting the appropriate checkboxes.
After the load test is complete, a Test Information summary is displayed in the right GUI panel
which includes the name of the project, when the load test was started and finished, the scenario you chose, as well as any machines and profiles.

Viewing Reports
Once the load test is completed, collected data must be analyzed in order to see how the Web service
performed under load. SOAtest gives you the ability to configure and generate load test reports.
In this section, you will learn how to view the Detailed Report and how to generate an HTML Report.
To view detailed reports, complete the following:
1. Select Detailed Report from the Views drop-down menu in the Results panel. A Graph tab
displays with various parameters.

2. Within the graph you can perform the following:

To view different parameters to graph and view:

70

Load Testing

To view multiple parameters in a logarithmic scale:

Select the Log Scale checkbox. A logarithmic scale allows you to see the
shape of multiple curves on the same graph (even if the displayed values are
very far from one another).

To view errors for the entire graph:

Select the desired parameter checkbox located at the bottom of the Results
panel.

Right-click any area of the graph, then choose Show errors from the shortcut
menu.

To view an HTML version of the Detailed Report:

1. Right-click any area of the graph, then choose View Report from the shortcut
menu. An HTML Report displays.
2. To configure the report before viewing it, select View Report Configuration.

As you can see, you can gather various details of a load test from the Graph tab of the
Detailed Report. However, additional information is available through the Histogram and
Table tabs as well. For more information on these tabs and the Load Test Detailed Reports,
see the SOAtest Users Guide.
3. Save this test suite by clicking the Save Project Toolbar button.

4. In the dialog box that opens, enter a name for the project in the File name field and click the
Save button. SOAtest saves the project and adds a .tst extension to the file name.
5. Select File> Close Project.

71

Reporting

Reporting
For this section of the tutorial, please reference the report files in the examples/reports directory within
the SOAtest installation directory.

Functional Testing Reports

SOAtest has the ability to generate functional test reports containing information about test runs including success/failure information along with test data. These reports can be generated in HTML, XML,
PDF, and CSV formats. To view sample reports please view the files in the directory examples\reports\. To find out how to create these reports please follow the example below:

Saving Functional Test Reports

It is often helpful to save information about your functional test runs in order to analyze this data. In this
example we will save report information from the tests that were run in previous examples:
1. Open your test suite of examples which were created in the previous exercises. If you did not
remember to save these tests please open the sample project file named SOATestTutorial.tst
in the examples/reports directory within the SOAtest installation directory.
2. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node that was
created in the Scenario Testing section of this Tutorial.
3. Click the Run Tests toolbar button.
4. Right-click in the right GUI panel and select View Report> Detailed or View Report> Summary from the shortcut menu. In addition, custom configurations defined in the Report Preferences will show up as choices under View Report. An HTML report is generated and
automatically opened in your internet browser. Depending on the report configuration chosen
you will be able to see things like failure information, successes and various other statistics..
5. Select the Test Suite: Negative Test node that was created in the Functional Tests section of
this tutorial.
6. Click the Run Tests toolbar button. Notice that several errors appear in the right GUI panel.
7. Right-click the Test Results panel and select Save As> XML from the shortcut menu. A Save
As XML dialog appears. Save the file into the reports directory (examples\reports) within the
SOAtest installation directory.
These Reports can also be generated when SOAtest is run in command line mode which is discussed
in the Automation/Iteration (Nightly Process) section.

Load Testing Reports

SOAtest has the ability to generate detailed load test reports at the conclusion of a load test. These
reports can be fully customized and can contain graphs as well as detailed statistical information.
These reports can be generated in HTML, XML, CSV, and a SOAtest readable binary format. To view
sample reports please view the files in the examples/reports directory.
For more information on how to create Load Test reports, see Viewing Reports, page 70.
For command line options, see Automation/Iteration (Nightly Process), page 74.

72

Reporting

Structure Reports
New design-time report type exports test structure details to an XML or HTML document. Also provides
details about the test setup which allows managers and reviewers to determine whether specified test
requirements were accomplished.
You can now right-click the test tree panel and select the View Structure Report option from the shortcut menu. This item will show a sub-menu of all the possible Structure type configurations that were
packaged with SOAtest, as well as user-defined configurations from the Report Preferences. When a
configuration from the list is chosen, SOAtest will generate the HTML structure report and automatically open the report in your browser.
You can also save reports by choosing the Save As option within the same shortcut menu. A submenu will appear displaying the formats SOAtest currently supports. Once you decide on a format,
another sub-menu will appear. This menu will display all the possible configurations that you can generate from. Once selected, a Save As dialog will appear.

73

Automation/Iteration (Nightly Process)

Automation/Iteration (Nightly Process)

For this section of the tutorial, please reference the report files functional_script.txt,
loadtest_script.txt, and readme.txt in the folder examples/scripts within the SOAtest installation
directory.
SOAtest gives you the ability to completely automate the testing process by running your tests on a
nightly basis from the command line. This allows you to fully automate the testing process. Once your
tests are built using the SOAtest GUI, they can be saved into project files which can then be run in a
nightly process.

Running a Test Suite From the Command Line

In this example, we will run SOAtestTutorial.tst from the command line which can be found in the
examples directory.
1. Close SOAtest and open a command line window.
2. Switch to the directory where SOAtest is installed.
3. From the command line window type the following command:
On Windows:
st.exe -cmd -runtest "C:\Location Of SOAtestTutorial.tst"

On UNIX:

soatest -cmd -runtest "/Location Of SOAtestTutorial.tst"

Where Location Of SOAtestTutorial.tst represents the location of SOAtest on disk.

Running SOAtest From the Command Line Using

Scripts
To run SOAtest from the command line mode we will need to create a script and then we will run the
script.

Running a Test Suite Using a Script

Using a script file which references a particular project file, tests can be run nightly using the following
command:
On Windows:
st.exe -cmd -run SCRIPT

On UNIX:
soatest -cmd -run SCRIPT

Where the contents of SCRIPT are:

runtest <"LocationOfProjectFile\ProjectFileName.tst">
[-reportHTML | -reportXML | -reportPDF] <"LocationToWriteReport\reportFile">

This script file specifies the location of the project file you wish to run. Using the - report and
outputErrors options and supplying an HTML or XML file name and directory location, SOAtest will
automatically generate reports in these formats. For example on Windows your script file could look
like the following:
runTest "C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\tests\SOAtestTutorial.tst" -reportHTML
"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\reports\%d_report.html" -reportXML

74

Automation/Iteration (Nightly Process)

"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\reports\%d_report.xml"

To try running SOAtest from the command line using a script file, open the files
functional_script.txt and readme.txt located in the scripts folder. You can modify
functional_script.txt to run the file SOAtestTutorial.tst from the command line.

Running a Load Test Using a Script

Load testing scenarios which you have set up in your project files can be run on a nightly basis using a
script file. To try this you can use the following command:
On Windows:
st.exe -cmd -run SCRIPT

On UNIX:
soatest -cmd -run SCRIPT

Where the contents of SCRIPT are:

open <"LocationOfProjectFile\ProjectFileName.tst">
loadtest [-minutes] <# of minutes> [-report]
<"LocationToSaveBinaryReport\loadtest.rpt"> [-html]
<"LocationToSaveHTMLReport"> <"ScenarioName">

This script file specifies the location of the project file containing load test data which you wish to run.
Using the loadtest command and supplying the above parameters, SOAtest will run the load test scenario specified and will then generate any report files which were specified.
For example, on Windows your script file could look like the following:
open "C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\tests\SOAtestTutorial.tst"
loadtest -minutes 1 -report
"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\reports\loadtest.rpt" -html
"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\reports"
"Steady Load"

To try running a load test from the command line using a script file, open the file
loadtest_script.txt and readme.txt located in the scripts folder. You can modify
loadtest_script.txt to run the file SOAtestTutorial.tst from the command line.

75

Running Regression Tests in Different Environments

Running Regression Tests in Different

Environments
It is common for Web service applications to be developed and maintained by different teams under
different environments. For example, a developer may start with tests on a server deployed on his or
her local machine, then as the server is deployed to a development build server, the same tests would
need to be executed against that server, then QA and testing teams would need to run the same
regression tests on their own integration server. Parasoft SOAtest includes an Environments management feature which makes such tasks easy, because reusing and sharing test assets is critical for
achieving a highly efficient process.
The New Test Suite wizard includes an option to create an environment configuration for the tests that
are generated automatically.
Creating a new test suite with preconfigured environment variables:
1. Select the Test Suite: Test Suite node from the previous exercise and click the Add Test
Suite button. The Add Test Suite wizard displays.
2. Select New Project from the Add Test Suite wizard and click the Next button twice to
advance to the WSDL dialog.
3. Enter http://soatest.parasoft.com/calculator.wsdl in the WSDL URL field.
4. Select the Create functional tests from the WSDL check box, select the Generate Web service clients radio button, and click the Next button. The Create Environment dialog opens.

5. Select the Add endpoint variables to your existing environments checkbox and click Finish. A new test suite displays and the Environments tab appears at the bottom of the SOAP
GUI.

76

Running Regression Tests in Different Environments

Notice how the environment configuration now includes variables for the HOST, PORT and PATH to
the service defined in the environment. The same variables are referenced by name in each of the
automatically generated SOAP Client tests (look under the Transport tab).
To create a new environment configuration, complete the following:
1. Right click on the Default Calculator Environment node in the left pane of the Environments
tab and duplicate it (copy/paste).
2. Rename the new environment configuration by entering Echo Environment in the Environment Name field in the right panel of the Environments tab.
3. Enter the following values to the corresponding variable names:

CALCULATOR_HOST: bpel.parasoft.com

CALCULATOR_PORT: 8080

CALCULATOR_PATH: examples/servlets/Echo

4. Save the test project into calculator_environments.tst

With the new Echo Environment node selected, click the Set button. This will set that new environment as the new configuration for the test project. Running the tests again will cause the SOAP messages to be sent to the Echo servlet on bpel.parasoft.com instead of the original calculator service.
Environment configurations can be exported and imported into external XML files, as well as uploaded
and referenced to the Parasoft Team Configuration Manager.
Environment variables can be referenced from most of the fields in the test settings GUI, not just URL
fields.

77

Running Regression Tests in Different Environments

Applying an environment configuration to a regresion test from the command line:

The greatest benefit of environments is the ability to rerun the same regression suites from the command line without the need to open the SOAtest GUI and modify host or URL settings.
From the command line, run:
st.exe -cmd -runTest -environment "Default Calculator Environment"

Then try:
st.exe -cmd -runTest -environment "Echo Environment"

This will run the same suite with the second environment applied to it.

78