So A Tutorial

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
Automate Testing Using Data Sources 17
Separating Tests into Positive and Negative Test Cases 20
Testing Invalid Data 21
Scenario Testing........................................................................ 23
Creating a Scenario Test Suite 23
Configuring an XML Data Bank 24
Client Testing (Emulating a Server) ......................................... 29
Configuring Server Stubs 29
Configuring the Client 30
Running Tests 32
Testing Plain XML Services...................................................... 33
Custom Scripting....................................................................... 35
Asynchronous Testing.............................................................. 38
WS-Security................................................................................ 42
Unlimited Strength Java Cryptography Extension 42
Message Layer Security with SOAP Headers: 43
Using the XML Encryption Tool: 45
Using the XML Signer Tool 48
XML Encryption and Signature Combined 50
Automatically Generating WS-Security Tests with WS-SecurityPolicy 51
Design and Development
Policy Enforcement ................................................................... 54
Rule Set Configuration 54
Parasoft Team Configuration Manager 54
Enforcing Design-time SOA Policies 55
Defining Custom SOA Policies 57
Load Testing .............................................................................. 59
Creating and Performing a Load Test 59
Customizing Load Test Profiles and Scenarios 62
Viewing Reports 67
Reporting.................................................................................... 69
Functional Testing Reports 69
Load Testing Reports 69
Structure Reports 70
Automation/Iteration (Nightly Process) ................................... 71
Running a Test Suite From the Command Line 71
Running SOAtest From the Command Line Using Scripts 71
Running Regression Tests in Different Environments .......... 73
Introduction
4
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 exam-
ples 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 Func-
tional 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 maxi-
mize 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 possi-
ble, check your project files into source control.
WSDL Verification
5
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 cor-
rect. 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 interoper-
ability 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
6
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 con-
suming it like an actual service consumer would, but with stricter adherence to stan-
dards.
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
7
The Add Output wizard displays.
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.
Add Test
Functional Tests
8
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
9
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 three times to proceed to the Layout dialog.
5. Enable the Organize as Positive and Negative Unit Tests checkbox.
Functional Tests
10

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 Funtional Tests
test suite, 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.
Functional Tests
11
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.
Functional Tests
12
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 parame-
ter 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 Create Regression Control from
the shortcut menu. SOAtest automatically runs the test and creates a regression control popu-
lated 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 opera-
tions defined within the WSDL.
Functional Tests
13
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 ele-
ment 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 mes-
sage displays in the right GUI 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.
4. In Test 1: getItemByTitle, select the Response SOAP Envelope> Diff control node. The Diff
control parameters display in the right GUI panel.
Functional Tests
14
5. Select the Ignored Differences tab in the right GUI panel. The Ignored Differences dialog dis-
plays. 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.
Functional Tests
15
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: get-
ItemByTitle 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.
Functional Tests
16
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 Enve-
lope> XML Transformer and Diff control are now added underneath the Test 1: getItemByTi-
tle node. Because the title element was chosen, the Diff control only compares the title
element rather than all elements.
Functional Tests
17
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 configura-
tion 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.
Notice that the column names from the Excel Spreadsheet appear in the Column Names box.
Functional Tests
18
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 Parame-
terized and Keywords.
Functional Tests
19
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 regression control we created previously. Now we need to update our regression control.
8. Right-click the Test 1: getItemByTitle node and select Update Regression Control> Multi-
ple Controls> Remove Existing Controls. SOAtest removes the existing regression control
and adds new regression controls for each test run - in this case 4 regression controls, one for
each row of the data source.
9. 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.
Functional Tests
20
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: get-
ItemByTitle 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
Functional Tests
21
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: get-
ItemById 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.
Functional Tests
22
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.
Scenario Testing
23
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 addi-
tional 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 Prefer-
ences 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 ele-
ment 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 sys-
tem.
Creating a Scenario Test Suite
To create this scenario, perform the following:
Suite button. The Add Test Suite wizard displays.
right GUI.
3. Enter Scenario Test - Search, Place Order, and Remove into the Name field
4. Copy the 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.
Scenario Testing
24
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 corre-
sponding 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.
Scenario Testing
25
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 exist-
ing test response dialog displays.
Scenario Testing
26
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.
Scenario Testing
27
When this test is run, the order_number element value stored from Test 2 will be automati-
cally 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.
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.
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
Scenario Testing
28
scenarios that may possibly occur. Negative test cases could also be created for expanded test cover-
age.
Client Testing (Emulating a Server)
29
The current methodology for client testing is first to generate Java stubs that return null, and then to
add logic to the stub so it can interact with the client. Not only is this methodology time consuming, but
it also rarely achieves what is expected, nor does it have enough test cases to test all aspects of the cli-
ent. With SOAtests client testing solution we can generate server stubs that are consistent with WSDL
and rapidly create various test cases to ensure that clients can handle all sorts of server responses (i.e.
correct messages, SOAP Faults, Malformed XML, etc.). Furthermore, server stubs can be created to
emulate plain XML services. The SOAtest Client Tester also verifies the incoming request, making sure
that the client serializes the SOAP messages correctly, and at the same time complies with WSDL.
In the following example, we will create server stubs with SOAtest to mock the behavior of a server that
performs simple calculations. By using server stubs generated by SOAtest, we can manipulate the
response and furthermore, monitor the clients behavior to the server responses. By combining SOAt-
ests Client Tester and server tests, we are able to emulate both the server and client of a Web service
invocation process and have a wide coverage of test cases.
With less emphasis on hard coding the test server, SOAtest interacts with the client by consuming the
incoming message, verifying it (Diff Tool, Check XML, etc.), and returning a message generated based
on the WSDL description and a Data Source (excel, Table, etc.). This process is simple, quick, and it
allows you to perform Client Testing and verification without any scripting.
Configuring Server Stubs
Note: The embedded Tomcat server needs to be enabled to properly configure the server stubs. To do
this, select Show Tomcat Server from the View menu. A Tomcat Server tab will display in the left GUI
panel.
1. Right-click the Tomcat Server node in the Tomcat Server tab and select Start Tomcat from
the shortcut menu. A green light next to the node indicates that the Tomcat server has been
successfully started.
2. Click the New Project toolbar button. The New Test Suite wizard displays.
3. Click the Next button.
4. Enter http://soatest.parasoft.com/calculator.wsdl in the WSDL URL field.
5. Select the Create functional tests from the WSDL checkbox and choose the Generate
Server Stubs radio button.
6. Click Finish. A new test suite is added to the test suite tree with the test suite configuration
panel displaying in the right GUI.
7. Enter Emulated Server in the Name field of the right GUI and select the Execution
Options tab.
8. Choose the Run Concurrently radio button in the right GUI panel.
9. Right-click the Test Suite: Emulated Server node and select Add to Project> Add Data
Source from the shortcut menu. The Add Data Source wizard displays.
data source is added to the project under the root node and the Data Source configuration con-
trols display in the right GUI panel.
11. In the right GUI panel, enter Client Test Data Source in the Name field and click the
Browse button to navigate to the Integer.xls file that is included in the SOAtest examples/
datasources directory.
30
12. Select the Test 1: Add Service node and select Parameterized and result from the Result
type drop-down menus in the right GUI panel.
13. Repeat step 12 for Tests 2 through 4 as well, choosing Parameterized and result from the
Result type drop-down menus in the right GUI panel.
14. Select the Test Suite: Emulated Server node and click the Run Tests toolbar button. The
server is now listening for incoming requests and all other operations are locked unless termi-
nated (Server is now up and running). To terminate simply click the STOP toolbar button.
Typically, you would test the client side by running your actual client against the emulated server stubs.
However, in the following procedure, we will emulate a client by opening another instance of SOAtest,
pointing it to the emulated server stubs you just created. Therefore, you will have two SOAtest win-
dows open at the same time. You will have to maneuver back and forth between these two SOAtest
windows to complete the next procedure.
Configuring the Client
You already have one instance of SOAtest open from the emulated server stubs you just created. We
will refer to that window as the SOAtest Emulated Server. In the next procedure, you will open another
instance of SOAtest. We will refer to that window as the SOAtest Emulated Client.
To emulate the client, complete the following:
31
1. Open another instance of SOAtest. For example, on a Windows machine choose Start> Pro-
grams> Parasoft> SOAtest 5.0> SOAtest. The SOAtest Emulated Client opens with the Wel-
come to SOAtest dialog.
2. Select New Project from the Welcome to SOAtest dialog and click the Next button twice to
advance to the WSDL panel.
4. Select the Create Functional Tests checkbox and choose the Create Clients radio button.
Click Finish. A new test suite is added to the test suite tree with the test suite configuration
panel displaying in the right GUI.
5. Enter Emulated Client in the Name field of the right GUI.
6. Right-click the Test Suite: Emulated Client node and select Add to Project> Add Data
Source from the shortcut menu. The Add Data Source wizard displays.
data source is added to the project under the root node and the Data Source configuration con-
trols display in the right GUI panel.
8. In the right GUI panel, enter Client Test Data Source in the Name field and click the
Browse button to navigate to the Integer.xls file that is included in the SOAtest examples/
datasources directory.
9. Open the SOAtest Emulated Server window and select the Test 1: addService node in the
Tests tab in the left GUI panel.
10. Select and copy (press ctrl+C) the Call Back URL in the right GUI panel of the SOAtest Emu-
lated Server.
Note: If this field is inactive, click the Stop toolbar button of the Emulated Server.
11. Open the SOAtest Emulated Client window and select the Test 1: add() node and uncheck the
Constrain to WSDL check box in the right GUI panel.
12. Select the Transport tab and paste the previously copied URL from step 10 into the Endpoint
text field in the right GUI panel of the Test 1: add() node in the SOAtest Emulated Client win-
dow.
13. Select the Request tab for the Test 1: add() node in the SOAtest Emulated Client window, set
the input type for the x parameter to Parameterized and the value to input1, and set the input
type for the y parameter to Parameterized and the value to input2.
32
14. Repeat steps 11 through 13 for each of the remaining tests in the SOAtest Emulated Client.
Running Tests
1. Select the Test Suite: Emulated Server node in the SOAtest Emulated Server window and
click the Run Tests toolbar button. The server is now listening for incoming requests and all
other operations are locked unless terminated (Server is now up and running).
2. Select the Test 1: add node in the SOAtest Emulated Client window and click the Run Tests
toolbar button. Note that the indication light turned green for Test 1: Add() Service on the
server side.
3. We can now view the traffic sent from the client to the server that weve created by selecting
the Traffic Object node underneath the Test 1: Add() Service node in the SOAtest Emulated
Server.
4. The clients request is now completed. Examine the traffic viewer under Test 1: add() (SOAtest
Emulated Client) and notice that the response from the server is in accordance with the table
weve set up on the server side.
5. Repeat steps 1 through 3 for the remaining tests.
Testing Plain XML Services
33
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 com-
plexity. If a schema for the XML messages is available, tests can be generated automatically by SOAt-
est, 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:
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.
34
7. Click the Next button. A list of elements that are defined in the schema (directly, as well as indi-
rectly 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.
Custom Scripting
35
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 flex-
ible 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.
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 Cli-
ent 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.
Custom Scripting
36
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
Custom Scripting
37
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.
Asynchronous Testing
38
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 WS-
Addressing protocol. We will need to send a Message ID which is used by SOAtest to identify the mes-
sage 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 restric-
tions. 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).
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.
39
5. Click Next three times to advance to the Layout dialog.
6. In the Layout dialog, choose the Asynchronous Messaging radio button and the WS-
Addressing radio button and click Finish. A test suite folder is created which contains auto-
matically 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 mes-
sages that are sent in an asynchronous messaging exchange. A Tomcat server has been inte-
grated 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.
40
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 echo-
String 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 WS-
Addressing 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.
41
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.
WS-Security
42
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 trans-
actions. 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 mes-
sages 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 docu-
ments 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 Cryptog-
raphy 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\5.0\JRE\1.5.0\lib\security.
For UNIX:
[JRE installation directory]/lib/security
or
[J2SDK installation directory]/jre/lib/security
WS-Security
43
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 pro-
vides the ability to add Custom Headers and also provides pre-defined templates for creating User-
name Tokens and SAML Tokens. The following example uses a Username Token.
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
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.
WS-Security
44
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.
WS-Security
45
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 cre-
ated.
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\key-
stores.
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 pass-
word 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.
WS-Security
46
Now we are ready to set up a test using the XML Encryption tool. To better organize our secu-
rity tests, we will create a new folder for the encryption test.
Suite wizard displays.
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.
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.
WS-Security
47
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 X509IssuerSerial 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.
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.
15. Select the Response SOAP Envelope -> XML Encryption node and complete the following:
WS-Security
48
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.
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 Fin-
ish. 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.
WS-Security
49
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
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
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:
Choose PKCS12 Keystore from the drop-down menu.
WS-Security
50
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.
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.
Select getItemByTitle from the Operation drop-down menu.
Select the string title parameter and enter Linux as its Fixed value.
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 - get-
ItemByID 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.
WS-Security
51
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
automatcally 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:
Suite wizard displays.
WS-Security
52
2. Select WSDL and click the Next button.
3. Enter http://soatest.parasoft.com/store-wss-04.wsdl in the WSDL URL field and
select the Create WS-Policy aware clients checkbox.
WS-Security
53
4. Click the Finish button. A new test suite is generated, including a WS-Policy Banks node at
the top test suite level. Notice how under this node, there is a policy node that includes 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 45.
Design and Development Policy Enforcement
54
Design and Development
Policy Enforcement
For this section of the tutorial please reference the test suite titled Governance in the SOAtestTuto-
rial.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 SOAt-
est policy now combines both static analysis policy configurations for XML artifacts (WSDLs, sche-
mas and SOAP) as well as semantic and schema validation tests.
SOAtest allows an architect to create a policy configuration which combines CodeWizard rule asser-
tions with test assertions such as Schema validity and WS-I interoperability. The new SOA policy con-
figuration 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 documenta-
tion (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 dis-
abled 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 compo-
nents 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.
55
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 twice. The Policy Enforcement dialog opens.
56
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 configu-
ration'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.
57
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 sche-
mas.
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 dis-
play in the Test Results panel. Some failure messages, such as Schema Validity and Seman-
tic 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.
58
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 Docu-
metation 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 configura-
tion you define can be used later to automatically create tests to enforce policies.
Load Testing
59
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 win-
dow 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 dis-
abling 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 pro-
vided 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 exer-
cises. To perform a simple load test, complete the following:
1. Make sure the test suite from the previous exercise is loaded.
2. Select the Test Suite: Test Suite node and click the Load Test toolbar button. The Confirm
Scenario dialog box displays.
Load Testing
60
3. Choose Linear Increase from the Scenario drop-down menu and click OK. 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 Results panel.
By default, this load test will run for 10 minutes. The load test can be stopped at any time, but
we will let it run for a few minutes while monitoring and manipulating the in-progress details of
the test.
4. At the bottom of the Results panel, select all of the Plotted parameters checkbox options. The
curve for each of these parameters displays in the Results panel 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 3 of this procedure.
Load Testing
61
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.
5. 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 sec-
onds.
The Log tab displays information about errors that occur during test execution.
6. 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 sce-
nario you chose, as well as any machines and profiles.
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.
Load Testing
62
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
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 check-
ing 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 Default User node. The
Default User controls display in the Results panel.
Load Testing
63
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.
4. Drag and drop the endpoint of the localhost curve to the coordinates of 10 users at 10 minutes.
Load Testing
64
5. At the bottom of the right GUI panel, change the Duration of the load test from 10 to 2 min-
utes. Normally, you may want your load tests to run for longer periods of time. But for this exer-
cise, 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.
Load Testing
65
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 check-
boxes 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 dis-
plays.
Load Testing
66
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 millisec-
onds. For more information on configuring QoS metrics, see the SOAtest Users Guide.
Load Testing
67
15. Select the Linear Increase node beneath the Scenarios branch and click the Load Test tool-
bar 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 var-
ious 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 sce-
nario 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:
Load Testing
68
Select the desired parameter checkbox located at the bottom of the Results
panel.
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:
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.
Reporting
69
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 includ-
ing 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 exam-
ples\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 cre-
ated 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> Sum-
mary from the shortcut menu. In addition, custom configurations defined in the Report Prefer-
ences 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 67.
For command line options, see Automation/Iteration (Nightly Process), page 71.
Reporting
70
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 short-
cut 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 automati-
cally open the report in your browser.
You can also save reports by choosing the Save As option within the same shortcut menu. A sub-
menu 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 gen-
erate from. Once selected, a Save As dialog will appear.
Automation/Iteration (Nightly Process)
71
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\5.0\examples\tests\SOAtestTutorial.tst"
-reportHTML
"C:\Progra~1\ParaSoft\SOAtest\5.0\examples\reports\%d_report.html" -reportXML
"C:\Progra~1\ParaSoft\SOAtest\5.0\examples\reports\%d_report.xml"
72
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 sce-
nario 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\5.0\examples\tests\SOAtestTutorial.tst"
loadtest -minutes 1 -report
"C:\Progra~1\ParaSoft\SOAtest\5.0\examples\reports\loadtest.rpt" -html
"C:\Progra~1\ParaSoft\SOAtest\5.0\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.
Running Regression Tests in Different Environments
73
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 man-
agement 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:
2. Select New Project from the Add Test Suite wizard and click the Next button twice to
advance to the WSDL dialog.
4. Select the Create functional tests from the WSDL check box, select the Generate Web ser-
vice 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 Fin-
ish. A new test suite displays and the Environments tab appears at the bottom of the SOAP
GUI.
74
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 Environ-
ment 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 environ-
ment as the new configuration for the test project. Running the tests again will cause the SOAP mes-
sages 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.
75
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 com-
mand 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.

So A Tutorial

Caricato da

Informazioni sul documento

Descrizione originale:

Titolo originale

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

So A Tutorial

Caricato da

Copyright:

Formati disponibili

Parasoft SOAtest Tutorial

Potrebbero piacerti anche