Site MapAccessibilityContact Us

Call us at (855) 254-1164 to learn more about Enterprise

PushToTest - Open Source Test



The soapUI TestMaker Tutorial

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.

Download TestMaker and Run SoapUI Tests  Watch the Tutorial Screencast

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.



Test flow for BrewBiz


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

This tutorial comes with pre-built tests that are found in the TestMaker_home/example_agents/SOAPWSDLTests directory. See the following files for the 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


This tutorial uses the following file name conventions:
  • soapUI project files end in .xml
  • Test Scenario files end in .scenario


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

In this task we will build a functional test of an application that uses SOAP-based Web service interfaces.
  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.

    Start a new soapUI project


    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.

    Start a new soapUI project

    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.

    Create a TestSuite

    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.

    Successful run of the testsuite


Task 2: Run The Test In A TestNode

PushToTest TestMaker makes it easy to run a test in a distributed set of TestNodes. PushToTest provides an easy-to-use central console that sends the test to one or more TestNodes. The TestNode operates the test. The test makes requests to the application or service to be tested. The test in this example makes requests using SOAP protocol. The TestNode logs the time it takes for the application or service to respond and returns the transaction logs to the PushToTest console.

PushToTest distributed test environment


The PushToTest console identifies the operating parameters of a functional test, load and performance test, and business service monitor in a TestScenario document. Build and operate the TestScenario in the TestMaker Editor. Find a TestScenario document already created for you in SOAPWSDLTests/BrewBiz_Functional_Test.scenario.
  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.

    soapUI controller

  3. Click the Edit icon in the controller panel to view the source of the TestScenario document.

    Editing the TestScenario


  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.

    Editing the TestScenario use case

    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.

    Showing results of running the test

    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

Task 3 enhances the functional test of the BrewBiz service from Task 1 and 2 to use a Data Production Library (DPL.) The DPL used in this task reads data from a comma separated value (CSV) flat file. TestMaker comes with many other DPLs. The values provide input to the test (id, password, product number for search) and validation data value.
  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.

    Comma separated file (csv)


  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.

    Add a Properties step

  6. We named the new properties step "DPL_Properties".


    soapUI project ready to test the service using DPL provided data


  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.

    Create a TestSuite


    We left the Value entries empty. TestMaker will fill-in the Values at test run time.


    Create a TestSuite


  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.

    Test step order

  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.

    Adding an assertion to check the response


  10. Click the Add Assertion button. Choose the XPath Match selection in the pop-up menu. Click OK.

    Adding an assertion to check the response


  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}

    Adding an assertion to check the response


  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.

    Connecting the DPL

    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.

    Editor showing data enabled used case


    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.

    Successful operation of a data enabled test




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

The test we built in Task 3 operated a functional test by a single user. Load and performance testing identifies the scalability index of a target host application by operating a test with multiple simultaneous concurrently running users. PushToTest reuses functional tests as load and performance tests without requiring any change to the test.
  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.

    Editor showing the General tab settings for a load test


    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.

    Test results from a load test


    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

The test we built in Task 3 operated a functional test by a single user. Business Service Monitor testing enforces and proves a Service Level Agreement (SLA) by operating a test periodically. For example, a monitor runs a test every 30 minutes. PushToTest reuses functional tests as a monitor without requiring any change to the test.
  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.

    Editor showing 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.

    Monitor running the test



Download TestMaker and Run SoapUI Tests  Watch the Tutorial Screencast