SoapUI Tutorial in PDF - Learn SoapUI in simple and easy steps starting from basic to advanced concepts with examples including SOAP Introduction. SoapUI is an open-source tool used for functional and non-functional testing, widely used in this tutorial, please notify us at [email protected] Here contains SoapUI Functional Testing tutorials and step by step pdf training materials. Learn about what is SoapUI and its advantages.
|Language:||English, Spanish, German|
|Distribution:||Free* [*Register to download]|
SoapUI is the market leader in API Testing Tool. You can do functional, load, security and compliance tests on your API using SoapUI. ABSTRACT. In today's world, web services have become an integral part of web. A web service is a service offered by one device to another device. IBM Corporation. SoapUI - Step by Step Tutorial to Create a. WebServices Regression Test using XPath. Match Assertions: (SOAP:Envelope, Body.
RPC Remote procedure calls are sometimes blocked by firewalls and proxy servers. To overcome these issues, SOAP was designed. There are some standard rules to be followed while building SOAP requests. Followed by Envelope element, you see the header element that has header information. The Body element specifies the call and response information.
Finally, you have a Fault element which contains errors and status information. The above said elements should be declared with default namespace for the SOAP envelope. Generally, a protocol is a set of standard rules that transfer the data between two regions on the Internet over the web services. There are many protocols that are used in the Internet applications. Internet Protocol IP that sends and receives the messages between two destinations. This framework was designed so that computers can be read and understood easily by the web.
This table contains two fields, one called index and one called author. Like seen here: That is all we need, let's start soapUI and get testing! Step o: Start the project 1. In this well choose the itemSearch request and add this to a TestCase.
We can then trim the request down to containing what we want. We also have a second property, resultCount, which well use later, more about this later, and a Property named type referring to the type of search were doing, i. Lets go on to actually populating the request and get to the heart of this tutorial. Lets add a datasource. Query: 3. Then Please We environment. We can use the XPath Selector tool to make the transfer a breeze.
We have made a small movie showing this step.
Watch it here in a new window Step 4: Check the test What we have now should look like this. However, we will wait until we have completed the rest of the operations in RoomManagementService. After that, the deleteRoom TestCase will be executed. Finally, the getRoomDetails TestCase will be executed. Therefore, if were to execute this in the default order, after you add a room, it will be deleted instantly by the execution of deleteRoom TestCase.
Perform the following steps to update the getRoomDetails TestStep: 1. Double click on the getRoomDetails TestStep. The room which has been added after executing addRoom TestCase is supposed to be removed from the system by executing the deleteRoom TestCase. SoapUI provides users with the facility to execute each TestCase individually as well as everything together.
In each TestCase, you will find the small green arrow icon which can be used to execute the TestCase alone as shown in the following screenshot: [ 81 ] For More Information: www. We have completed updating all our TestSteps in the preceding section. Therefore, just click on the run icon the small green arrow which appears at the top-left corner of the TestSuite view. Once the test execution is over, you will see something similar to the following screenshot: 4.
All TestCases are marked in green denoting the success of the test. If you double-click on the green bars, the associated TestCase will be opened. Then click on the relevant TestStep. You can see the SOAP requests and responses which were submitted to the web service.
Now, is this the correct approach of verifying the success or failure of our test? Do we need to open the response messages of each and every request in TestSteps to find out what goes wrong or not? If this is the way we verify the status of tests, can this be considered as automated testing? By now, we all have a lot of questions like these. We expect to find answers for all of these concerns before ending this chapter.
Let's do another simple test. Add another room for example, room number by executing the TestSuite. After executing the test, you will notice that the new room is added to the system. Now, execute the TestSuite again. The test is successful again!
This will open the SOAP request and response as we saw earlier. This time, you will notice that we got a SOAP Fault as the response as we tried to add a room which has already been added.
We need to instruct it to fail tests if some conditions are not satisfied. In other words, we need to have a mechanism to validate the responses which we get as a result of TestStep execution. We can validate them by manually reading the responses as we did before. However, when executing complex test suites automatically, we cannot look and read each and every response manually to figure out the status of tests.
Test assertions come into action in this situation. In soapUI, assertions are applied to TestSteps. There are many predefined assertions available for us to use in soapUI tests.
Some assertions are applicable only for a specific set of TestSteps whereas some are common for any TestStep.
You can add any number of assertions to a TestStep. After the TestStep is executed, all of the associated assertions are applied to the response. The TestStep is failed if any of the assertions fail. Let's continue our discussion on assertions with our sample TestSuite. We are going to add an assertion to addRoom TestStep in our project as follows: 1.
You will notice the add an assertion to this item icon at the top-left corner of TestStep editor.
Click on that icon. The Select Assertion dialog box will open as shown in the following screenshot: 3. You can find all assertions provided by soapUI in the preceding dialog box. During the course of this book, we will cover most of these assertions. In this example, let's use a few simple assertions.
This time the status of the TestSuite will be marked as failed in a red color. The assertion result will be given at the bottom of the TestStep result view as shown in the following screenshot: 4.
In this case, the assertion evaluated the test to be failed as the response was a fault. We know that if we execute this particular TestSuite again and again without any modification, we should get a SOAP Fault as we did earlier.
In order to check that, we can use multiple assertions. We will use XPath Match assertion first. When you specify the XPath expression as shown in the preceding screenshot, make sure to declare any namespace prefix which you use in the expression. Note that all namespaces must be declared before they are used in the XPath expression. If you are adding an XPath assertion based on a valid response message, the namespaces can automatically be declared by selecting the Declare button in the XPath expression editor.
You can specify the expected result of the evaluation of the XPath expression in the Expected Result editor. Similar to the namespace declaration, if you specify the expected result based on a valid response message, the result can automatically be retrieved by clicking on Select from current button in the Expected Result editor.
After configuring the XPath expression and the expected result, click on Save to add the new assertion into the addRoom TestStep.
We have added two assertions for the addRoom TestStep. We have tested both of them for the failure case.
For now, just disable this XPath assertion by right-clicking on the assertion. You can add another XPath assertion to check the success case of our test. Let's add a Contains assertion to the getRoomDetails TestStep in our example by performing the following steps: 1.
The Contains Assertion dialog box will be shown where we can specify the content to be checked in response. The response of getRoomDetails can always contain a string value, Standard, Luxury or Suite depending on the room type.
In the Contains assertion, the content which we look for can either be a string value or a regular expression.
If we use a regular expression as in this example, we must check the Use token as Regular Expression check box, otherwise the expression we specify as the content will be considered as a pure string value. The getRoomDetails TestStep will be marked as passed.
We have done some preliminary modifications in our first TestSuite. However we are not done yet. We have not executed our whole test scenario yet. Before doing that, let's discuss another important construct in soapUI functional tests — properties.
Properties are used to parameterize the execution of tests. In soapUI, properties can be defined at many levels in a project. You can define the properties which are common to your project at the project level. TestSuite and TestCase specific properties can be defined at their respective levels. Let's dive into the details of properties with our example project.
In our project, the project specific properties can be defined in the Custom Properties tab as shown in the following screenshot: For example, we can define a property called Test at the project level as shown in the preceding screenshot. This property can be accessed from anywhere in our project through property expansions.