Build A Test of a SOAP-based
Web Service With Fast and Easy
Graphical Test Tools.

This article shows how to build a test in PushToTest TestMaker and soapUI in minutes. Working with WSDL has never been this fast and easy. This article shows the tremendous power to repurpose the test as a load and performance test and a business service monitor with no extra coding.

Note: Find all of the code and data described in this article in TestMaker_home/example_agents/SOAPWSDLTests.

BrewBiz Inc. is a beer manufacturer. BrewBiz provides its suppliers and vendors with a SOAP-based Web service interface to the inventory control system. BrewBiz provides its customers with a Web browser-based interface to search the product catalog and place orders. We will be using the SOAP/WSDL interface for this tutorial.

Tasks and Scenario

BrewBiz is a manufacuting organization. BrewBiz uses an Enterprise Resource Planning (ERP) application to add new products into inventory. Vendors of products use a SOAP-based service interface to manage the parts inventory. Customers access the catalog of parts and inventory through a Web browser-based user interface. We need to test the application using its SOAP services.

1. Build and run a functional test of the BrewBiz Web application.
2. Run the test in a TestNode.
3. Reuse the test as a data-driven test with a Data Production Library that reads data from a Comma-Separated-Value (CSV) file.
4. Reuse the test as a load and performance test.
5. Reuse the test as a business service monitor.
   
   

Test Use Case

A software quality tester needs to rapidly build a test of an ERP system. The tester follows these steps:

1. Identify a list of products to add to the BrewBiz inventory. Create a Comma-Separated-Value (CSV) file to hold the product orders. Use a PushToTest CSV Data Production Library (DPL) to enable the test to access the product orders at test runtime. PushToTest DPLs are a powerful and rapid way to build data-driven tests.
   
   
2. Access a Web page to confirm that the products are in inventory. Use soapUI to understand the services defined in a WSDL document for the SOAP interface. Use soapUI to define a test suite and test case of the ERP system. When the test operates PushToTest provides input parameters for the part number data and validation data to assert that the service responds with the correct response.

In all it should take you approximately 15 minutes to build and operate this test. The following sections show step-by-step instructions.

Implementation

File or Directory	Description
Tutorial_Calendar_ReadMe.html	This document
BrewBizService.wsdl	WSDL document for the BrewBiz service.
data.csv	Comma separated value (csv) file of data for the data driven tutorial examples.
BrewBizService-soapui-project.xml	SoapUI project that interoperates with the application under test.
BrewBizService-soapui-project-dataenabled.xml	SoapUI project ready to use TestMaker provided operational test data
BrewBiz_Functional_Test.scenario	Runs the BrewBiz-soapui-project test as a functional test in TestMaker.
BrewBiz_DataDriven.scenario	Runs the BrewBiz-soapui-project-dataenabled using operational test data from data.csv. A comma separated value (CSV) file inputs to the test and to validate the results.
BrewBiz_Load_Test.scenario	Repurposes BrewBizService-soapui-project-dataenabled.xml to be a data driven load and performance test.
BrewBiz_Monitor.scenario	Repurposes BrewBizService-soapui-project-dataenabled.xml to be a data driven service monitor.
images	A directory to store illustrations of this test

• soapUI project files end in .xml
• Test Scenario files end in .scenario

Task 1: Build A Functional Test Case From A WSDL Definition

1. Open soapUI. Use the TestMaker Tools menu -> Start soapUI command.
   
   
2. From soapUI, create a new project using the File menu -> New WSDL Project command.
   
   
   
   
   Name the new project BrewBizService. Type the following URL in the Initial WSDL text field http://localhost:8080/BrewBizWeb/BrewBizService.wsdl. Click OK.
   
   
3. soapUI will open a new project in the Navigation tree. Click the + icons next to BrewBizServivceSoapBinding, Change_Price, and Request 1. Double-click Request 1 to open the Request/Response editor panel.
   
   
   
   Click the + icon in the Editor panel window (the second icon to the right in the title bar on the top of the panel) to change the orientation of the panel to horizontal views (request on the top and response on the bottom.)
   
   
4. Test Request 1 by replacing the ? characters for your own values in the Request Editor panel. Enter product 1000, type AddProduct, quantity 50, and location 15. Then click the "Submit Request To The Endpoint" icon (a triangular icon in the upper left corner of the Request Editor panel.) Note the service response appears in the Response panel.
   
   
5. Right-click Request 1 and choose Add To TestCase.
   
   
   
   Enter "TestSuite" for the TestSuite name and "TestCase" as the TestCase name. Click OK to the Add Request To TestCase dialog.
   
   
6. Choose the File menu -> Save All command.
   
   
7. Run the TestSuite. Right click on TestSuite in the navigation panel and choose Launch TestRunner. Click the Launch button.
   
   
   
   

Task 2: Run The Test In A TestNode

1. Choose File -> Open and select TestMaker_home/example_agents/SOAPWSDLTests/FunctionalTest/BrewBiz_Functional_Test.scenario
   
   
2. TestMaker opens a new controller panel for the TestScenario. The controller panel includes icons to run, pause, and stop the test.
   
   
   
   
3. Click the Edit icon in the controller panel to view the source of the TestScenario document.
   
   
   
   
   
4. Editor displays the TestScenario. Use the tabs to view the parts of the TestScenario. For example, the TestScenario defines use of the Selenium test in the Use Cases tab.
   
   
   
   The TestNodes tab tells TestMaker to send the soapUI recorded test to the TestNode(s) that will operate the test.
   
   The UseCases tab tells TestMaker to run a use case that runs the soapUI test defined in BrewBizService-soapui-project.xml.
   
   The General tab tells TestMaker that this is a functional test and to run the use case once.
   
   
5. That's all! Click the PushToTest Run button and watch the results.
   
   
   
   Functional tests run a test as a single user. TestMaker displays check-marks next to each step of the soapUI test that operate successfully. TestMaker shows the amount of time to operate the use case and each step in the soapUI test.
   
   TestMaker displays an X mark for a step that fails. Use the Windows menu -> Output command to view the logs to learn the cause of the failure. Click the Local TestNode Error and Local TestNode Output tabs.
   
   
   

Task 3: Make A Data-Driven Functional Test

1. Create a Comma-Separated-Value file. Use your favorite text editor or spreadsheet program. Name the file data.csv. The contents must be in the following form.
   
   
   
   
   
2. Open soapUI. Use the TestMaker Tools menu -> Start soapUI command.
   
   
3. From soapUI, open the soapUI test project using the File menu -> Import command. Open SOAPWSDLTests/BrewBizService-soapui-project-dataenabled.xml.
   
   
4. soapUI will open a the project in the Navigation tree. Click the + icons next to BrewBizServivceSoapBinding, Change_Price, and Request 1. Double-click Request 1 to open the Request/Response editor panel. This project already has a defined TestSuite and TestCase.
   
   
5. Add an interface to the TestMaker-provided operational test data by right clicking on TestSuite -> TestCase -> Test Steps(1). Choose Add Step -> Properties.
   
   
   
   
6. We named the new properties step "DPL_Properties".
   
   
   
   
   
   
7. Notice the DPL_Properties already has 4 properties: Product, Operation, Quantity, and Location. We created these by clicking the + icon. We named the properties: Product, Operation, Quantity, Location to match the CSV datafile.
   
   
   
   
   We left the Value entries empty. TestMaker will fill-in the Values at test run time.
   
   
   
   
   
   
8. We checked check the order of the steps to make sure DPL_Properties is first and Change_Price is second. We used the mouse to click-and-drag the order of the steps.
   
   
   
   
9. Lastly, notice that we added assertion to validate the response. A valid response from a SOAP request to the service will include the Product Number we sent in the request. To add an assertion, open the Request editor by double-clicking on Change_Price - Request 1. Click the Assertions button, the Assertions panel will open at the bottom of the Change_Price editor panel.
   
   
   
   
   
10.  Click the Add Assertion button. Choose the XPath Match selection in the pop-up menu. Click OK.
    
    
    
    
    
11. Enter the following in the XPath Expression, Declare box:
    //change_price_response[1]/Inventory[1]/Product[1]/@number
    
    
12. Enter the following in the Expected Result, Select from current Test box:
    ${DPL_Properties#Product}
    
    
    
    
    
13. Close the Assertions box.
    
    
14. Connect the DPL_Properties step with the TestMaker Data Production Library (DPL.) In the Change_Price - Request 1 editor panel remove the ? characters from the <ProductNumber>, <Type>, <Quantity>, <Location> elements.Move the mouse to the <ProductNumber> element. Right click the mouse, choose Get Data -> Step 1: [DPL_Properties] -> Product.
    
    
    
    You will see the property look-up function as: <ProductNumber>${DPL_Properties#Product}</ProductNumber>
    
    
15. Repeat for the <Type>, <Quantity>, <Location> elements, choosing the corresponding DPL_Properties.
    
    
16. Finally, we need to connect the Data Production Library (DPL) to the soapUI test. The test operates in the TestMaker distributed test environment. Use the TestMaker Editor to tell PushToTest to get the CSV data file into a DPL and run the soapUI test.
    
    
17. Use TestMaker's File menu -> Open command to open the SOAPWSDLTest/BrewBiz_DataDriven.scenario. Click the Editor icon.
    
    
18. In the Use Cases tab click the Add DPL link. Set the DPL type to HashDPL. HashDPL reads data from a comma separated value (CSV) file and provides it at test run time to the ScriptRunner. Set the Action to Get Next Row of Data.
    
    
    
    
    A quick explanation: The TestScenario operates a functional test by running the soapUI test once. The data file we created contains 11 rows of data. Change the repeat value to have TestMaker repeat the test for each row of data in the Editor's General tab for the TestScenario.
    
    
    
19. That's all! Click the PushToTest Run button and watch the results.
    
    
    
    
    

Task 4: Reuse A Functional Test As A Load And Performance Tests

1. In the TestMaker window use the File -> Open TestScenario command. Use the file selector to choose SOAPWSDLTests/BrewBiz_Load_Test.scenario
   
   
2. Click the Edit icon in the TestScenario Controller panel.
   
   
3. Set the test to be a load test in the General tab.
   
   
   
   
   The settings tells TestMaker to operate a load and performance test at three levels of concurrently running simulated users (crlevel.) The test operates 2 users, then 4 users, and then 8 users.
   
   
   
4. That's all! Click the PushToTest Run button and watch the results.
   
   
   
   
   PushToTest operates the test in 1 concurrently running simulated users, then 2 users, then 4 users. The Real Time Scalability Index contrasts the Transaction Per Second (TPS) for each of the three user levels. A perfectly scalable system will increase TPS in linear proportion to the increase in users. For example, at 2 users doing 1.97 TPS a 4 user level should be twice the TPS, or 3.95 TPS or higher. The above chart shows an application with linear scalability. The Step Times chart shows the amount of time each step took to operate as the test proceeded.
   
   
   
   

Task 5: Reuse A Functional Test As A Business Service Monitor

1. In the TestMaker window use the File -> Open TestScenario command. Use the file selector to choose SOAPWSDLTests/BrewBiz_Load_Test.scenario
   
   
2. Click the Edit icon in the TestScenario Controller panel.
   
   
3. Set the test to be a load test in the General tab.
   
   
   The Editor defines this as a business service monitor. The monitor operates the test use case every 10 minutes. The monitor keeps running until it encounters an exception.
   
   
4. That's all! Click the PushToTest Run button and watch the results.