tutorial parasoft

Parasoft SOAtest Tutorial

Table of ContentsTable of Contents ...................................................................... 2

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

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

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

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

Creating and Deploying Stubs ................................................. 32Creating Stubs 32Viewing Deployed Stubs 33Using the Deployed Stubs 33Modifying Deployed Stubs 34

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

Custom Scripting....................................................................... 38

Asynchronous Testing.............................................................. 41

WS-Security................................................................................ 45Unlimited Strength Java Cryptography Extension 45

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

Design and Development: Policy Enforcement ................................................................... 57

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

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

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

Automation/Iteration (Nightly Process) ................................... 74Running a Test Suite From the Command Line 74Running SOAtest From the Command Line Using Scripts 74

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

Introduction

4

IntroductionParasoft 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 TutorialThe topics presented in this document represent key areas of Web services testing and will give you a guide on SOAtest’s 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 PackTo 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 PracticesWhile 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

WSDL VerificationWSDL verification can be considered as the first step in testing Web Services. Although WSDLs are generally created automatically by various tools, it doesn’t 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 SuiteFor 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 SOAtest’s 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.

5

WSDL Verification

3. Specify the WSDL in the WSDL URL field or Browse to the WSDL file on your machine.

4. Uncheck the Create functional tests from the WSDL check box and select the Create tests to validate and enforce policies on the WSDL check box.

5. Click Finish.

Because you selected the Create tests to validate and enforce policies on the WSDL check box, four WSDL tests are automatically created in a separate test suite called WSDL Tests.

SOAtest automatically creates the following WSDL tests from a WSDL URL.

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

• Test 2: Semantic Validity: Checks the correctness of the WSDL by parsing and 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.

6

WSDL Verification

Add Test

The Add Output wizard displays.

The Add Output wizard displays a list of available tools. In addition, a description of the selected tool displays in the Tool Description field.

7. In the Add Output wizard, select Conformance Report from the left pane, select the All Tools checkbox and then select Browse from the right pane, and click the Finish button. This will send a WS-I Conformance report to your internet browser when you run the test.

8. Select the Test Suite: WSDL Tests node and click the Run Tests toolbar button.

If any errors occur, they will display in the right GUI panel. You can double-click the errors in the right GUI panel for additional information and you can also examine the conformance report that was opened in your internet browser.

7

Functional Tests

Functional TestsFor 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 TestsFor 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.

8

Functional Tests

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

4. If it is not already selected, enable the Create functional tests from the WSDL checkbox and then click the Next button four times to proceed to the Layout dialog.

5. Enable the Organize as Positive and Negative Unit Tests checkbox.

9

Functional Tests

6. Click the Finish button. The newly created test suite displays in the left GUI panel of SOAtest and the Test Suite configuration controls display in the right GUI panel.

7. In the right GUI panel, enter Functional Tests in the Name field. Within the Functional Tests test suite, there is a Test Suite: store-01.wsdl node within which there are seven other test suites that test each operation of the WSDL.

8. Expand each test suite node within the newly-created Functional Tests branch until all seven test suites are visible and each test within each test suite is displayed.

10

Functional Tests

Each of the seven test suites contain both a positive and negative test for each operation since it is important to test situations where we send expected data as well as unexpected data to the server.

9. Select the Test 1: getItemByTitle node underneath the Test Suite: getItemByTitle Positive Test node.

11

Functional Tests

10. In the titleKeyword entry field type Linux. We will be searching for books with keyword Linux.

11. Click the Run Tests tool bar button. The getItemByTitle operation is invoked with the 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 Update 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.

12

Functional Tests

Ignoring XPath ValuesWhen 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 Test Results panel because the price element has changed. In this case we want to ignore the value of the price element.

2. Right-click on the error message in the Test Results panel and select Ignore XPath from the shortcut menu.

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

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

13

Functional Tests

4. In Test 1: getItemByTitle, select the Response SOAP Envelope> Diff control node. The Diff control parameters display in the right GUI panel.

5. Select the Ignored Differences tab in the right GUI panel. The Ignored Differences dialog 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.

14

Functional Tests

Validating Specific ElementsIn 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.

15

Functional Tests

4. Select the title element from the Select Parameter dialog and click the Next button.

5. Select Create Regression Control and click the Finish button. A Response SOAP 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.

Using the XML AssertorSimilar to the Response Validation wizard, you can use the XML Assertor tool to enforce the correct-ness of data in an XML message. It is most commonly connected to a SOAP Client or Messaging Cli-ent in order to verify the data returned by a service. The XML Assertor provides support for complex message validation needs without the need for scripting, and allows you to easily create and maintain validation assertions on your XML messages. To use the XML Assertor, complete the following:

1. Right-click the Response SOAP Envelope> XML Transformer node from the previous exer-cise and select Delete from the shortcut menu.

2. Right-click the Test 1: getItemByTitle node and select Add Output from the shortcut menu. The Add Output wizard displays.

16

Functional Tests

3. In the Add Output wizard, select Response> SOAP Envelope from the left GUI pane, select XML Assertor from the right GUI pane, and click the Finish button. A Response SOAP Envelope> XML Assertor node is added underneath the Test 1: getItemByTitle node.

4. Select the Response SOAP Envelope> XML Assertor node and select the Assertions tab in the Project Configuration panel.

5. Click the New button in the Assertions tab. The Add New Assertion wizard displays.

17

Functional Tests

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

18

Functional Tests

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

19

Functional Tests

8. Enter Linux in the Expected Value field of the Assertion tab and click the Run Tests button. The test succeeds.

You may add additional assertions to apply to the message (such as a Numeric assertion to enforce on the price element) by clicking the New button in the Assertion tab.

Automate Testing Using Data SourcesNow 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.

20

Functional Tests

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

5. Go back and select the Test 1: getItemByTitle node from the previous exercise. Books should already be selected from the Data Source drop-down menu that is now present in the right GUI panel.

6. For the titleKeyword drop-down menus at the bottom of the right GUI panel, select Parame-terized and Keywords.

21

Functional Tests

7. Click the Run Tests tool bar button and notice the error messages that appear in the Test Results panel. The test ran one time for each row in the Keywords column, but failed due to the XML Assertor we created previously. Now we need to update our regression control.

8. Right-click the Response SOAP Envelope> XML Assertor node and select Delete from the shortcut menu.

9. Right-click the Test 1: getItemByTitle node and select Update Regression Control> Multi-ple Controls> Remove Existing Controls. SOAtest adds new regression controls for each test run - in this case 4 regression controls, one for each row of the data source.

10. Select the Traffic Object> Traffic Viewer node beneath the Test 1: getItemByTitle node and notice that the test ran four times, once for each keyword value in the Keyword column.

22

Functional Tests

Separating Tests into Positive and Negative Test CasesWhen 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

23

Functional Tests

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

Testing Invalid DataIt 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.

24

Functional Tests

9. Click the Run Tests toolbar button and view the response from the server in the Traffic Viewer. Notice that an exception is thrown and displayed in the Response traffic.

10. Right-click the Test 1: getItemById node within the Sending Bad Data test suite and select Create Regression Control from the shortcut menu.

25

Scenario Testing

Scenario TestingFor 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 SuiteTo create this scenario, perform the following:

1. Select the Test Suite: Test Suite node from the previous exercise and click the Add Test Suite button. The Add Test Suite wizard displays.


3. Enter Scenario Test - Search, Place Order, and Remove into the Name field

4. Copy the positive getItemByTitle, placeOrder, and removeOrder nodes from the previously created Functional Tests test suite and paste them into the Scenario Test - Search, Place Order, and Remove test suite.

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

26

Scenario Testing

Configuring an XML Data BankTo 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 cor-responding 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 Sce-nario Test - Search, Place Order, and Remove test suite.

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

27

Scenario Testing

When this test is run, the value stored from Test 1 will be automatically inserted as the value for the itemId element.

5. Select the Test 3: removeOrder node.

6. Select Books from the Data Source drop-down menu in the right GUI panel and select Parameterized and Use Data Source Wizard from the orderNumber element drop-down menus. After selecting Use Data Source Wizard, the Parameterize with value from exist-ing test response dialog displays.

28

Scenario Testing

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

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

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

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

29

Scenario Testing

When this test is run, the order_number element value stored from Test 2 will be 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.

10. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node and click the Run Tests toolbar button. Notice that all the tests now fail.

Examine the error messages that appear in the right GUI panel. These regression failures are due to dynamic content that appears within the response messages. In the following steps we will ignore elements with this type of dynamic data.

11. In the right GUI panel, right-click on each of only the first errors under each Test Suite node and select Ignore XPath from the shortcut menu. In the Ignore XPath Settings dialog that displays, click the OK button. You should ignore two XPaths in this step.

12. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node and click the Run Tests toolbar button. All the tests should now succeed.

You have now created a fully functional scenario test that tests one possible business transaction that may occur during normal usage of the book store service. For extra practice you can try to create other

30

Scenario Testing

scenarios that may possibly occur. Negative test cases could also be created for expanded test cover-age.

31

Creating and Deploying Stubs

Creating and Deploying StubsEvolving services in a distributed SOA environment, and across multiple teams, is a complex endeavor due to the interdependencies between the system and business processes. For example, in a system that incorporates multiple endpoints such as credit card processing, billing, shipping, etc., it may be dif-ficult for one team to test the responses from another team without interrupting normal business trans-actions.

With SOAtest’s stub generation capability we can test complex and distributed environments by auto-matically generating server stubs based on existing test suites. SOAtest can quickly and easily auto-mate server emulation across multiple environments, thereby streamlining the collaborative development and testing activities of multiple teams and ultimately speeding the SDLC.

In the following exercises, we will create stubs that emulate an existing Web service. The stubs will be created automatically from an existing SOAtest test suite that tests the existing Web service. We will also deploy the stubs locally and use the stubs for testing.

Creating StubsTo create a stub, complete the following:

1. Open the Test Suite named StubClient.tst in the examples/tests directory. This is a Test Suite comprised of three tests driven by a data source of three rows. The test suite con-sumes the actual Book Store web service described by the WSDL at http://soat-est.parasoft.com/store-01.wsdl.

2. Select the main Test Suite: StubClient node and click the Run Test toolbar button. Nine tests will run and succeed. From these tests, we will automatically generate a stub.

3. Right-click the Test Suite: StubClient node and select Create Stub from the shortcut menu. The Create SOAtest Stub wizard displays.

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

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

32


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

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

Viewing Deployed StubsTo view the stubs deployed in the previous exercise, complete the following:

1. Select View> Show Tomcat Server. The Tomcat Server tab displays in the left GUI panel.

2. Expand the Stubs folder beneath the Tomcat Server node and select the StubClient node. The settings for the StubClient stub display in the Project Configurations panel.

Using the Deployed StubsTo use the previously created stubs to test the client, perform the following:

1. Select the Environments tab located at the bottom of the SOAtest GUI.

33


2. Select Stub Environment from the left pane of the Environments tab and click the Set but-ton. The test suite will now send messages to, and receive messages from, the emulated stub.

3. Click the Run Tests toolbar button. Nine tests will run and succeed.

Modifying Deployed StubsTo modify deployed stubs, complete the following:

1. Open the Test Suite named StubClientStub.tst in the examples/tests directory.

2. Select the Test 1: getItemByTitle node. This is the stub for the getItemByTitle operation.

3. In the Project Configuration panel, select Response 1 within the Message Body tab. Notice the end of the XPath Function: *[local-name(.)="titleKeyword"]/text()="Linux". This stub returns the specified XML if the XPath function succeeds on the request XML. In other words, if the getItemByTitle is Linux.

34


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

5. Save the Test Suite.

6. In the Tomcat Server tab, right-click the Tomcat Server node and select Deploy Stubs from the shortcut menu to re-deploy the modified stub.

7. Click the Run Test toolbar button.

Now when you run the StubClient.tst test suite, the response for getItemByTitle(Linux) will contain the modified title. In this way, you can modify the behavior of the stubs. You can also modify the XPath functions in a similar fashion.

35

Testing Plain XML Services

Testing Plain XML ServicesParasoft 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.

36

Testing Plain XML Services

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

8. Click the Finish button. Three tests are created.

37

Custom Scripting

Custom ScriptingPlease 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 SOAtest’s 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 SOAtest’s current tool set.

In this example you will create a Scenario Test using the book store service used in previous exam-ples. 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.


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.

38

Custom Scripting

10. Right-click the Test 1: Validate Price Value node and select Add Output. The Add Output wizard displays.

11. In the Add Output wizard, select Response> SOAP Envelope from the left pane, and XML Data Bank from the right pane, and click Finish. An XML Data Bank is chained to the XML Response output of the SOAP Client.

12. Select the XML Data Bank node beneath the Test 1: Validate Price Value node.

13. Select the price element in the XML Tree view in the right GUI panel and click the Add button. The value stored in Test 1: price will be used in the next test.

14. Select the Test Suite: Custom Scripting node and click the Add Test button. The Add Test wizard displays.

15. In the Add Test wizard, select Standard Test from the left pane, and Method from the right pane, and click Finish. A Method tool is added to the test suite.

16. Select the Method Tool node and enter Price Logger Method in the Name field.

17. Select Python from the Language drop-down menu and enter the following script in the Text field:def checkPrice(input, context):

price = float(input.toString())

if price > 0:

return 0

else:

return 1

39

Custom Scripting

This script ensures that the price value is positive.

18. Right-click the Method Tool Text window and select Evaluate from the shortcut menu.

If any syntax errors are present, they will be displayed in the Message window at the bottom of the GUI. Otherwise, the method name will appear in the Method drop down box. Make sure that the method checkPrice() is the selected method.

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

40

Asynchronous Testing

Asynchronous TestingFor 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 echo’s 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).

1. Select the Test Suite: Test Suite node and click the Add Test Suite button. The Add Test Suite wizard displays

2. Select New Project from the Add Test Suite wizard and click Next twice to advance to the WSDL dialog.

3. Enter the following into the WSDL URL field: http://bpel.parasoft.com:8888/bpel/echoAsync?WSDL

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

41


5. Click Next until you 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.

42


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.

43


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

44

WS-Security

WS-SecurityFor 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 ExtensionImportant: 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\[SOAtest version number]\JRE\1.5.0\lib\security.

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

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

45

WS-Security

Message Layer Security with SOAP Headers:In this example we will use a book store web service, which requires a Username and Password to be submitted within the SOAP Header element according to the WS-Security specification. SOAtest 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.

1. Select the Test Suite: Test Suite node and click the Add Test Suite button. The Add Test Suite dialog box displays.

2. Select Empty Test Suite and click Finish. An empty test suite folder is created.

3. Type WS-Security into the Name field in the right GUI panel.

4. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add Test Suite dialog box displays.


6. Type Username Tokens into the Name field in the right GUI panel.

7. Select the Test Suite: Username Tokens node and click the Add Test button. The Add Test wizard displays.

8. In the Add Test wizard, select Standard Test from the left pane, and SOAP Client from the right pane, and click Finish. A SOAP Client tool is added to the test suite.

9. Select the Test 1: SOAP Client node beneath the Test Suite: Username Tokens node and complete the following in the right GUI panel:

• Enter SOAP Client – getItemByTitle operation in the Name field.

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

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

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

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

10. Click the Run Tests toolbar button. Notice that the test fails because it did not have the required Security Header.

11. Select the Test 1: SOAP Client node.

12. Select the Header tab in the right GUI panel and then click the Add button. A Choose Header Type dialog appears.

46

WS-Security

13. Select WS-Security and click OK. The WS-Security GUI displays in the right GUI panel.

14. In the Timestamp tab in the right GUI panel, uncheck the Send Timestamp checkbox.

15. Select the Username Token tab in the right GUI panel and complete the following:

• Enter soatest in the wsse:Username field.

• Enter soatest in the wsse:Password field.

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

47

WS-Security

Now you can create a Regression Control to alert you to any changes in the server response in the future.

17. Right click on Test 1: SOAP Client – getItemByTitleOperation node and select Create Regression Control> Multiple Controls from the shortcut menu. A regression control is 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.

48

WS-Security

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.

4. Select the Test Suite: WS-Security node and click the Add Test Suite button. The Add 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.

49

WS-Security

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

• Select the Encrypt radio button.

• Select the WS-Security Mode check box.

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

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

• Choose X509BinarySecurityToken from the drop-down menu in the WS-Security Options. The XML Request is now set up to be encrypted when the request is sent to the service.

Now you can add an XML Encryption Tool to the XML Response of the SOAP Client test to enable Decryption of the XML response.


14. Select Response> SOAP Envelope from the left pane, and select XML Encryption from the right pane, and click the Finish button. An Encryption Tool is chained to the SOAP Client.

50

WS-Security

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

• Select the Decrypt radio button.

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

16. Click the Run Tests toolbar button and then select the Traffic Viewer node to view the encrypted data.

17. Right-click the Test 1: SOAP Client - getItemByID operation node and select Create Regression Control -> Multiple Controls. A Regression Control is created and automatically chained to the Response SOAP Envelope -> XML Encryption. Notice that the decrypted responses are shown in the Regression Control.

Finally, you want to ignore dynamic values from the XML Response so that the Regression Control does not fail each time.

18. Select the XML Document -> Diff Control node and complete the following in the right GUI panel:

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

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

• Repeat the previous step for the CipherValue element.

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

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

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

Using the XML Signer ToolIn 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.


51

WS-Security


• Select placeOrder from the Operation drop-down menu.

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

• Select the count parameter and enter 1 as its Fixed value

7. Right-click the Test 1: SOAP Client - placeOrder operation node and select Add Output from the shortcut menu. The Add Output wizard displays.

8. Select Request> SOAP Envelope from the left panel, and select XML Signer from the right panel, and click Finish. An XML Signer Tool is chained to the SOAP Client.

9. Select the Request SOAP Envelope> XML Signer node beneath the Test 1: SOAP Client - placeOrder operation node and complete the following in the right GUI panel:

• Select RSAwithSHA1 (PKCS1) – http://www.w3.org/2000/09/xmldsig#rsa-sha1 from the Algorithm drop down menu.

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

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

• Select the WS-Security Mode check box and choose X509IssuerSerial from the drop down menu.

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

Now you can add an XML Verifier Tool to the XML Response of the SOAP Client test to enable Signature Verification of the XML response:

10. Right-click the Test 1: SOAP Client - placeOrder operation node and select Add Output from the shortcut menu. The Add Output wizard displays.

11. Select Response> SOAP Envelope from the left pane, and select XML Signature Verifier from the right pane, and click Finish. An XML Encryption Tool is chained to the XML Signer.

12. Select the XML Response -> XML Signature Verifier tool node beneath the Test 1: SOAP Client - placeOrder operation node and complete the following in the right GUI panel:

52

WS-Security

• Choose PKCS12 Keystore from the drop-down menu.

• Select the WS-Security Mode check box.

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

XML Encryption and Signature CombinedIn 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.

53

WS-Security

10. Right-click the Request SOAP Envelope> XML Signer node and select Add Output from the shortcut menu. The Add Output wizard displays.

11. Select XML Encryption and click the Finish button. An XML Encryption Tool is chained to the SOAP Client.

12. Select the Signed XML Document> XML Encryption Tool node and complete the following in the right GUI panel:

• Select the Encrypt radio button.

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

• Select AES 256 from the Algorithm drop down menu.

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

13. Click the Run Tests button. The XML Request is first signed and then encrypted.

14. Click the Traffic Viewer node to view the server response.

Automatically Generating WS-Security Tests with WS-SecurityPolicyParasoft enables automatic test creation to enforce runtime security policies. This helps users auto-matically 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 man-age various policy variations in order to test the services properly, both positive and negative.

SOAtest recognizes WS-SecurityPolicy assertions in the WSDL when using the WS-PolicyAttachment standard. In order to automatically generate tests from a WSDL with WS-SecurityPolicy assertions, complete the following:

1. Select the Test Suite: Test Suite node and click the Add Global Property button. The Add Global Property wizard displays.

54

WS-Security

2. Select Add WS-Policy Bank and click the Finish button. A WS-Policy Banks node is added to the test suite tree.

3. In the Project Configuration panel, enter http://soatest.parasoft.com/store-wss-04.wsdl in the WSDL URL field and click the Refresh from WSDL button. The Global Policies are populated.

55

WS-Security

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

56

Design and Development: Policy Enforcement

Design and Development: Policy EnforcementFor 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 enforce-ment over these components will help to ensure interoperability, consistency, and re-usability through-out 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 ConfigurationA 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 ManagerThe Team Configuration Manager (TCM) helps you standardize team-wide settings for Parasoft AEP (Automated Error Prevention) technologies. For instance, TCM can manage and automate the sharing of team-standard test settings, custom coding standard rules, tests, and general preferences. It also helps control access to the modification of coding rules.

Once TCM is installed and deployed, the team architect or manager can configure the appropriate team-standard settings and upload the necessary files (team rule sets for example) needed for policy enforcement. Finally, testers and developers can reference files on the TCM server to ensure that everyone on the team is using the same team configurations.

57


Enforcing Design-time SOA PoliciesFor this example we will create policy enforcement tests for a book store service with the WSDL located at http://soatest.parasoft.com/store-01.wsdl.

1. Select the root Test Suite: Test Suite node and click the Add Test Suite button. The Add Test Suite wizard displays.

2. Select New Project from the Add Test Suite wizard and click the Next button twice to advance to the WSDL dialog.

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

4. Check the Create tests to validate and enforce policies on the WSDL check box and make sure the Create functional tests from the WSDL check box is also checked.

5. Click Next until you advance to the Policy Enforcement dialog.

58


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.

59


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 User’s 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 PoliciesIn the previous exercise, we enforced policies using a default policy configuration. For this example, we will define a custom SOA policy.

60


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 SOAtest’s 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.

61

Load Testing

Load TestingOnce 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 TestFor 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. Right-click the Test Suite: Test Suite node and select Create Load Tests from the shortcut menu. The New Load Test wizard opens with the VU Profiles panel.

62

Load Testing

3. Select the desired test suites for which you would like to assign virtual users and click Next.4. In the Schedule & Distribution panel, enter 2 Minutes for the Duration, select Linear

Increase for the Distribution, and click Next until you reach the Other Options panel.

Note: In order to select the Linear Increase option, you must have the appropriate Load Test-ing license. If you do not have Virtual Users enabled on your license, you will only be able to generate the Steady Load scenario.

5. In the Other Options panel, select the Start Load Test immediately checkbox and click Fin-ish. SOAtest will begin the Load Test of the Store Web service. A new Load Tests tab dis-plays in the left GUI panel and the Graph tab displays in the Load Test progress panel.

Note: For more information on the New Load Test wizard, see the SOAtest User’s Guide.

63

Load Testing

The load test can be stopped at any time, but we will let it run the full 2 minutes while monitor-ing and manipulating the in-progress details of the test.

6. At the bottom of the Results panel, notice all of the Plotted parameters checkbox options. The curve for each of these parameters displays in the in the Graph tab.

By monitoring the details in the Graph tab, you will notice the following:

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

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

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

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

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

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

8. If the load test is still running, click the Stop toolbar button.

After the load test is complete, a Test Information summary is displayed in the Results panel which includes the name of the project, when the load test was started and finished, the sce-nario you chose, as well as any machines and profiles.

64

Load Testing

In addition to viewing the Test Information summary, you can also choose to view different statistical reports of the load test as well. To view detailed statistics of the load test, complete the following:

1. Select Statistics from the Views menu in the Results panel.

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

65

Load Testing

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

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

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

2. To access details about a specific test failure, double-click the related report row. You can determine whether a given test failed by locating the row that represents that test, then check-ing the number in that row’s Failure Count column.

For more information on viewing load test results, see the SOAtest User’s Guide.

Customizing Load Test Profiles and ScenariosYou can customize how a particular load test is run by customizing the profiles and scenarios you plan to use. You can determine the length of time a load test lasts, the distribution of virtual users, the hit rate over time and machines, and the distribution of user profiles over time.

To customize the load test, complete the following:

1. Double-click the Profiles folder in the Load Tests tab and select the Test Suite node. The Test Suite controls display in the Results panel.

2. At the bottom of the Results panel, change the Delay Value to 3 seconds. This may simulate how a user hesitates before making a decision about ordering a book.

3. Select Linear Increase beneath the Scenarios node. The Linear Increase scenario controls display in the Results panel and the User graph displays the localhost curve.

66

Load Testing

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

5. At the bottom of the right GUI panel, change the Duration of the load test from 10 to 2 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.

67

Load Testing

9. Click the Scenarios folder in the Load Tests tab of the left GUI panel. The Report Settings controls display in the right GUI panel.

Select both the Record graph data and error details and Record individual hits 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 User’s 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.

68

Load Testing

12. Select Statistic Metric from the Add Metric wizard and click Finish. The new metric displays in the right GUI panel.

13. Enter Execution Time Requirement in the Name field.

14. For the Statistic drop-down menus in the right GUI, select Avg. Exe. Time (ms) and the less than symbol (<), and then enter 200 in the text field.

This will cause the load test result to “fail” if the execution time is measured above 200 millisec-onds. For more information on configuring QoS metrics, see the SOAtest User’s Guide.

69

Load Testing

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 ReportsOnce the load test is completed, collected data must be analyzed in order to see how the Web service performed under load. SOAtest gives you the ability to configure and generate load test reports.

In this section, you will learn how to view the Detailed Report and how to generate an HTML Report.

To view detailed reports, complete the following:

1. Select Detailed Report from the Views drop-down menu in the Results panel. A Graph tab displays with various parameters.

2. Within the graph you can perform the following:

• To view different parameters to graph and view:

70

Load Testing

• 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 User’s Guide.

3. Save this test suite by clicking the Save Project Toolbar button.

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

5. Select File> Close Project.

71

Reporting

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

Functional Testing ReportsSOAtest 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 ReportsIt is often helpful to save information about your functional test runs in order to analyze this data. In this example we will save report information from the tests that were run in previous examples:

1. Open your test suite of examples which were created in the previous exercises. If you did not remember to save these tests please open the sample project file named SOATestTutorial.tst in the examples/reports directory within the SOAtest installation directory.

2. Select the Test Suite: Scenario Test - Search, Place Order, and Remove node that was created in the Scenario Testing section of this Tutorial.

3. Click the Run Tests toolbar button.

4. Right-click in the right GUI panel and select View Report> Detailed or View Report> 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 ReportsSOAtest has the ability to generate detailed load test reports at the conclusion of a load test. These reports can be fully customized and can contain graphs as well as detailed statistical information. These reports can be generated in HTML, XML, CSV, and a SOAtest readable binary format. To view sample reports please view the files in the examples/reports directory.

For more information on how to create Load Test reports, see “Viewing Reports”, page 70.

For command line options, see “Automation/Iteration (Nightly Process)”, page 74.

72

Reporting

Structure ReportsNew 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.

73

Automation/Iteration (Nightly Process)

Automation/Iteration (Nightly Process)For this section of the tutorial, please reference the report files “functional_script.txt”, loadtest_script.txt”, and “readme.txt” in the folder examples/scripts within the SOAtest installation directory.

SOAtest gives you the ability to completely automate the testing process by running your tests on a nightly basis from the command line. This allows you to fully automate the testing process. Once your tests are built using the SOAtest GUI, they can be saved into project files which can then be run in a nightly process.

Running a Test Suite From the Command LineIn 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 ScriptsTo 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 ScriptUsing a script file which references a particular project file, tests can be run nightly using the following command:

On Windows: st.exe -cmd -run SCRIPT

On UNIX: soatest -cmd -run SCRIPT

Where the contents of SCRIPT are:runtest <"LocationOfProjectFile\ProjectFileName.tst"> [-reportHTML | -reportXML | -reportPDF] <"LocationToWriteReport\reportFile">

This script file specifies the location of the project file you wish to run. Using the - report and –outputErrors options and supplying an HTML or XML file name and directory location, SOAtest will automatically generate reports in these formats. For example on Windows your script file could look like the following:

runTest "C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\exam-ples\tests\SOAtestTutorial.tst" -reportHTML "C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\exam-ples\reports\%d_report.html" -reportXML

74

Automation/Iteration (Nightly Process)

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

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

Running a Load Test Using a ScriptLoad 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\[SOAtest version number]\exam-ples\tests\SOAtestTutorial.tst"

loadtest -minutes 1 -report

"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\exam-ples\reports\loadtest.rpt" -html

"C:\Progra~1\ParaSoft\SOAtest\[SOAtest version number]\examples\reports" "Steady Load"

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

75

Running Regression Tests in Different Environments

Running Regression Tests in Different EnvironmentsIt 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.

3. Enter http://soatest.parasoft.com/calculator.wsdl in the WSDL URL field.

4. Select the Create functional tests from the WSDL check box, select the Generate Web 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.

76


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.

77


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.

78

tutorial parasoft

Documents

scenario testing

load testing reports

load tests

functional testing reports

functional tests

performance testing

asynchronous testing

testing web services