What is properties in SoapUI ? Properties in SoapUI is used to store and retrieve data. The data is stored as key,value format.

Default properties in SoapUI. SoapUI has properties at three levels by default. 1. Project level default/custom properties. User can add any number properties at project level and this can be accessed from any test steps from any test cases under any test suites. 2. Test suite level default/custom properties. User can add any number properties at test suite level and this can be accessed from any test steps from any test cases under this test suite. 3. Test Case level default/custom properties. User can add any number properties at test case level and this can be accessed from any test steps from this test case.

Where to use properties in SoapUI We can read the property values into test step endpoint, Header values, username, password, domain, GET, POST, PUT and DELETE method properties.

The above image shows how to use the properties in Header or inside the Post request. How to use default/custom properties. The default/custom values at three levels can be used for endpoint, Header values, username, password etc.. The general format for reading the default/custom property value is : ${#levelname#key} Ex : To read test case level property : ${#TestCase#param1} To read test suite level property : ${#TestSuite#param1} To read project level property : ${#Project#param1} The above image shows how to use the property at test case level. Read property using Groovy Script Reading property values from a script is straight-forward, to get a property value you first need to get hold of the containing object and then use the getPropertyValue("property name") method. Groovy script can be used in two places inside the SoapUI. 1. Groovy script test step 2. Script Assertion - within test step. The below code snippet can be used to read test case level property from Groovy script test step.
def param1 = context.testCase.getPropertyValue( "param1" ) log.info param1

Similarly the below code snippet can be used to read test case level property from Script Assertion.
def param1 = testRunner.testCase.getPropertyValue( "param1" ) log.info param1

We can read the property value from test suite level as well as project level in similar way. Code snippet to read test suite level property
def param1 = testRunner.testCase.testSuite.getPropertyValue( "param1" ) log.info param1

Code snippet to read project level property

def param1 = testRunner.testCase.testSuite.project.getPropertyValue( "param1" ) log.info param1

Set/Add property using Groovy Script As like reading property value, writing property values from a script is also straight-forward. we need to call setPropertyValue("property name","property value") method. If the property is not exist already then it will be created and the value will be assigned. If the property is already exist then its value will be updated. Code snippet to write test case level property
context.testCase.setPropertyValue( "param1","88" );

Similarly the code snippet to write values for testsuite and project level property are
context.testCase.testSuite.setPropertyValue( "param1","88" ); context.testCase.testSuite.project.setPropertyValue( "param1","88" );

Delete property using Groovy Script We can manually add any number of default or custom properties at all three levels. But the tool doesn't have the option to delete the properties manually. we need to use the script to delete the property.

using the below script we can delete the property.

context.testCase.removeProperty( "param1" );

similarly we can delete the properties in testsuite and project level

context.testCase.testSuite.removeProperty( "param1" ); context.testCase.testSuite.project.removeProperty( "param1" );

Delete/Remove all custom properties using Groovy Script. The below code snippet can be used to delete all the properties available in test suite level.
context.testCase.properties.each { k,v -> context.testCase.removeProperty(k); }

we can modify the above code to delete all the properties at different levels as discussed above.

SoapUI - Parametrize the endpoint

Wednesday, July 10, 2013

SoapUI is one the most famous Web Service testing tool in today's scenario. For all GUI Testing we have several environments. Similarly we have multiple environments for Web Service Testing. Parametrize the environment is most important and could be first task in automation testing. For that a more common scenario in a complex service environment is the need to change the endpoint of some of the services involved in your tests, for example between test, dev and staging environments. Manually changing endpoints is of course possible but far too tedious when there might be hundreds of request test steps involved, and using the command-line host override option does not allow you to change a single service endpoint if you have multiple ones in use. Changing the endpoint manually will take lot of time for more number of test cases. To overcome this issue SoapUI has the option called properties. Properties to the rescue; 1. Define a project property holding the endpoint:

2. Configure the endpoint to use this property via property-expansion

3. Make sure your requests are using the configured endpoint

4. Now when you run the request, the property will automatically be replaced with its current value. To use a different value just change the endpoint in the UI, or from the command-line you can use the -P option; -PServiceEndoint=dev.smartbear.com:8884 which would use the dev.smartbear.com:8884 endpoint instead (entirely fictional).

When to use RESTful Web Services

May 14, 2012

A RESTful style is appropriate when

The web services are completely stateless. Each request from client to server must contain all the information necessary to understand the request, and cannot take advantage of any stored context on the server. A caching infrastructure can be leverage for performance. A message sent using RESTful Web Services can be cached in the intermediaries, such as proxy servers, cache servers, gateways, etc, between the client and the Server to give high performance, so next time when the client request for the same data, data stored at the cache should be sent to the client.e.g Google Maps is using RESTful uris to provide cachable map tiles. The bandwidth needs to be limited. Since, there is no overhead of headers in the REST messages (unlike SOAP messages), REST messages would not need that high bandwidth as is required in case of SOAP Web Services. So, RESTful Web Services can be very useful for limitedprofile devices such as PDAs and mobile phones. RESTful Web Services can be consumed very easily by the clients. e.g using AJAX, Clients can consume RESTful Web Services directly on their Web pages with simplicity. Rather than starting from scratch, services can be exposed with XML and consumed by HTML pages without significantly refactoring the existing web site architecture. So, existing developers will be more productive because they are adding to something they are already familiar with, rather than having to start from scratch with new technology. I have always found, development with REST is easier and quicker than SOAP. Because, of this most of the vendors are adopting RESTful Web Services e.g Flickr, Google etc. RESTful Web Services supports a variety of data formats e.g HTML, XML, plain text, PDF, JPEG, JSON etc. RESTful interfaces can easily support different content-types/mime-types.

What are RESTful Web Services

REST is an architectural style which was brought in by Roy Fielding in 2000 in his doctoral thesis. Any software, technology adhering with the defination of REST would be considered as REST based. So, in the context of Web Services, RESTful Web Services are the one which supports REST concept.

What are RESTFull Web Services:

RESTFull Web Services refers to a stateless client-server architecture in which the Web Services (data, functionality on server side) are considered as resources and can be accessed using their uniform Resource Identifiers (URIs). The response from server is considered as the representation of the resources. This representation can be generated from one resource or more number of resources.

So, in RESTful Web Services, Server is viewed as a set of resources and can be accessed using Uniform Resource Identifiers (URIs). In the REST architectural style, clients and servers exchange representations of resources by using a standardized interface and protocol. HTTP protocol best describes REST, so all the existing vendors are supporting RESTfull Web Services using HTTP protocol. But, as such any other protocol can be used to realize RESTfull Web Services as long as it adheres with the REST principles. A resource can be any coherent and meaningful concept that may be addressed e.g an entry of student record in the database with roll number (23) as a primary key etc. A representation of a resource is typically a document that captures the current or intended state of a resource e.g HTML page, PDF etc. But, only thing to be noted is, this resource must be having a unique URI (like

Following are the features of RESTful Web Services:

Client directly access a Resource using its URI: Resources are identified by their URIs (typically links on internet). So, a client can directly access a RESTful Web Services using the URIs of the resources (same as you put a website address in the browsers address bar and get some representation as response). Uniform interface: Resources on the server can be manipulated by a client using a fixed set of four create, read, update, delete operations: PUT, GET, POST, and DELETE. PUT creates a new resource, which can be then deleted by using DELETE. GET retrieves the current state of a resource in some representation. POST transfers a new state onto a resource. Self-descriptive messages: Resources are decoupled from their representation so that their content can be accessed in a variety of formats, such as HTML, XML, plain text, PDF, JPEG, JSON, and others. Metadata about the resource is available and used, for example, to control caching, detect transmission errors, negotiate the appropriate representation format, and perform authentication or access control. Every such information will be available in the message itself.

RESTful applications are simple, lightweight and fast. Developers can expect a lot of performance and scalability enhancements. But, still there are many other factors which a developer needs to analyse before he decides to go for RESTful Web Services and not any other style of Web Services e.g SOAP Web Services.

What are web services

Web Services is a way to establish communication between softwares which could be running on differnt machines (different platforms or operating systems), having been developed using differnt languages e.g java, .net, c++ etc. e.g lets say you are a java developer. then using java web services you can publish your applications functions to other softwares on Internet or LAN or WAN. So any other software written in any language e.g .net, c++ etc on network can access functions of your java application.

But, why you should learn such a technology ??

Here is the list of some strong reasons to support web services:
Reason 1: Reusing functionality of already developed (old) systems in new softwares.

Lets say you are developing a Software weather forecasting analyzer using java and in this software you would need to get weather report of a particular date apart from other complex calculations. You have got one old softwrae written using .net technologies which performs the above task i.e if you pass date to one of its functions, it will return the weather report of that day. Now, my question to you is: would you really like to write the same code again in the new software or you would like to learn a technology which will allow your new software to call a function written in old .net software ? I belive you would definately support the idea of resuability.

Reason 2: Web Services A cross-platform, cross-language data model, facilitates the development of heterogeneous distributed applications.

Heterogenous distributed application means different softwares develped using different languages, platforms, operating sytems and running on different machines with varied geographic locations but can communicate through a compter network developed for a common goal.
Reason 3: Accessibility of applications through firewalls using Web protocols again sounds a very good reason as in the earlier technologies for interoperability like DCOM, CORBA etc, firewalls posed a serious blocker.

Applications interoperability is the goal of web services and Because you access and develop Web services using standard Web protocols such as XML and HTTP, the diverse and heterogeneous applications on the Web (which typically already understand XML and HTTP) can automatically access Web services and communicate with each other.

Using SSL in a SoapUI mock service (including client authentication)

without comments Not only can SoapUI mock a web service, it supports using SSL to connect to that service, and even to require client authentication via certificate. This post on the SoapUI support blog walks through the steps to enable SSL support, but doesnt handle client authentication. There are also a couple of tricky things that I wanted to mention. So heres a very short tutorial, which uses the same mock service I created in this post. The process to enable SSL is short:
1. Create the keyStore to use. 2. Configure SoapUI to use the created keyStore for mock services. 3. Restart SoapUI

If you want to require client authorization, then just add a few more steps:
1. Export client certificate and private keys into a keyStore. 2. Configure SoapUI to require client authorization and provide the client keyStore 3. Restart SoapUI

Enabling SSL in Mock Services

Create the keystore

Most of the keystore and certificate manipulation needed in this tutorial can be done using keytool, the command-line utility in the JDK. But thats really a pain in the neck, so Im going

to use Portecle instead, which is an open-source GUI keystore tool which hides most of the ugliness of keytool and provides some additional functionality. Using the tool, generate a new keystore. For this sample Ill use Suns keystore format. Ive found that SoapUI wont work with the PKCS #12 option in the mocks, though you can use keystores of that type in calls made to real services with SoapUI, which Ill show later.

Generate a key-pair in the keystore. First step is to select the algorithm and key size. I just leave these as default.

Now enter in the details about the key pair. If youve ever worked with LDAP, this should look familiar. Most of the fields are optional, but be sure to enter the Common Name.

Finally, specify the alias for the new key-pair:

Here is a shot of Portecle after the key-pair is generated.

All thats left is to save the keystore to wherever youd like. Youll need to enter and confirm the keystore password (I recommend using the same password as you did for the key-pair, just for simplicity later), then name the new keystore file. In my case, its called soapUIsslTest.pks.
Configure SoapUI to use the new keystore for mock services

All the SSL functionality in SoapUI is managed from preferences.

1. Select File: Preferences from the menus. Click on the SSL Settings tab 2. Make sure KeyStore and KeyStore Password are blank. 3. Check Enable Mock SSL

4. Enter a free port to use for accessing the mock via SSL 5. Enter the path to the keystore you just created as both the Mock Keystore and Mock TrustStore 6. Enter the password you used when saving the keystore (not when creating the key-pair!) as Mock Password, Mock TrustStore Password. 7. Enter the password you entered when creating the key-pair as the Mock Key Password 8. Do not check Client Authentication

Here is a screen capture after completing this process:

Restart SoapUI

Ive found that whenever you make changes to the Mock portion of the SSL settings, you need to restart SoapUI to get them picked up. Once SoapUI has restarted, you can start the mock service and use it however youd like.
Demonstrating that SSL is enabled

You wont actually see the traffic encrypted in SoapUI, but you can verify that SSL was used in two ways. Here is a screen capture showing the test request and the mock service response after a call was made that did not use SSL:

Note that the endpoint used in the request was http://localhost:8088/doMathStuff which specifies non-SSL traffic to the original port, not the port given in the SSL Settings tab. Also, you can see that the SSL Info section of the response received by the test request does not have any SSL information; its greyed out. Here is a screenshot of the same request sent using SSL (Note: As long as you arent concerned with client authentication via certificate, only the endpoint address needs to change!):

You can see that the endpoint used now specifies the https:// protocol and the port given in the preferences. Also, there is now data given on the SSL Info for the response. If you click on that, youll actually see details matching the key-pair you created earlier.

Requiring Client Authentication

These steps assume youve already enabled SSL for mock services, per the above tutorial.
Export client certificate and private keys into a keystore

You need to have a keystore that contains the client certificate youre planning to use for authentication, as well as the generated private keys. Ive had success using the same keystore as I created for the mock service, but only if I use the same password for the keystore and the keypair I generate. Im not sure why this is, but for completeness, Ill step through creating a new client keystore by exporting the needed data from the keystore already created above. Note: I dont believe you can do this sort of export using keytool; it takes extra coding. So Ill use Portecle, which offers this capability. In Portecle, right-click on the key-pair you created before, and select Export from the popup menu. Select Private Key and Certificates as the Export Type.

Enter the password for the key-pair, if prompted. If youve kept Portecle open throughout the tutorial, it may already be cached. Enter the password for the new keystore into which youre exporting the certificate. Save the new keystore wherever is convenient.
Configure SoapUI to require client authorization and provide the client keystore

In order to enable client authorization, youll first need to set up the mock keystore and truststore as listed above. Once thats done:
1. 2. 3. 4. Select File: Preferences from the menus. Click on the SSL Settings tab Check Client Authentication. Enter the path to the keyStore you created in the previous step. Enter the password for that keyStore

Restart SoapUI

Since you changed the Mock portion of the settings (by requiring client authentication), you need to restart SoapUI. Once SoapUI has restarted, you can start the mock service and use it however youd like. Your client certificate will be provided during authentication.
Demonstrating that client authentication with certificate is enabled

One way of checking whether authentication was used is to change the keystore or type in an incorrect password. This will fail, and youll be able to check the logs for the relevant stack traces. This might seem a little brutish, but it is a good way of attempting to replicate problems you may be seeing in your real service code when trying to use certificates. It doesnt take long, either. If you only change the KeyStore and KeyStore Password settings in SoapUI, you dont have to restart anything (since they arent part of the Mock settings). There is another way to verify the details of client authentication, however. The SoapUI display when using client authentication is no different than when just using SSL, but if you look at the SSL Info details in the response, you can confirm the certificate was used. Here is the SSL Info for a request that was sent without requiring client authentication (doing the first part of this tutorial):

Note that the first entry after CipherSuite is PeerPrincipal. By contrast, here is the SSL Info for a request sent while requiring client authentication:

You see that there is a LocalPrincipal given, and that it is the key-pair that you exported into the keyStore earlier. There will also be a PeerPrincipal entry which matches the details when not using client authentication.

Rest Service Part I

Posted by soapuitutorial on June 3, 2012 Posted in: REST Service. Tagged: Rest Service, Service Automation, SOAP UI, SOAPUI, Web Service Automation. Leave a Comment

REST (Representational State Transfer) Service, is an interaction method used in the Web Services industry design model. REST is catching up with its more popular contemporary, the SOAP service. REST uses a simpler less heavy style, unlike the XML driven services which weighs more due to the information it carries along with it. Cutting it straight, REST links the HTTP method to the CRUD logic. (CRUD is CREATE/READ/UPDATE/DELETE). The mapping goes as such: To create a component: POST To update a component: PUT (There are overrides in which this method can be used as a DELETE method) To retrieve a component: GET To delete a component: DELETE Any person who is familiar with the DDL (Data Definition Language), DCL (Data CreationLanguage), DML (Data Manipulation Language) concepts in SQL will find many things

common here. What can be observed here is that the high level behavioral attributes are almost the same. POST ==:> Create PUT ==:> Update GET ==:> Select DELETE ==:> Delete Note: Please do not consider the POST/PUT/GET/DELETE from the REST service to be part of an SQL based system. It has been used here for mere comparison of its individual attributes. Cloud Computing: Cloud Computing refers to accessing applications, data or services that are stored or running on remote servers over internet. The CLOUD in Cloud Computing refers to Internet (a network). So, in simple terms, you may define Cloud Computing as computing over internet. The companies which offer CLOUD based solutions in actual gives some kind of services over a network. The services can be: suppose you are running a company; and for some reason you need to buy costly servers (Hardware) for you business. Now, you can do two things: 1. You go and directly buy the hardware. 2. You do not buy the hardware but you use someone else hardware and pay them money based on your needs concerning the usage of hardware and the time frame for which you are going to use it. Hardware would not reside in you company physically but, over internet (on some network) you would be using this hardware for running your applications, storing data etc. If you go with the second option; this means that you are utilizing services offered by someone on the network. In this case, these services means providing hardware on subscription bases. The organizations who are offering such services are known as CLOUD service providers. But, Cloud computing is not really limited to providing hardware related services; it can be any service: you may utilize someone else Software and pay subscription fee for that or may be for developing your own web application you would utilize tools which are offered as a service on Internet by someone else. As a Cloud solution offering, an organization can broadly deliver three kind of services:

SaaS (Software as a Service):

software that is deployed over the internet With SaaS, a provider licenses an application to customers either as a service on demand, through a subscription, in a pay-as-you-go model, or (increasingly) at no charge when there is opportunity to generate revenue from streams other than the user, such as from advertisement or user list sales.

PaaS (Platform as a Service):

Platform as a Service (PaaS) brings the benefits that SaaS bought for applications, but over to the software development world. PaaS can be defined as a computing platform that allows the creation of web applications quickly and easily and without the complexity of buying and maintaining the software and infrastructure underneath it. PaaS is analogous to SaaS except that, rather than being software delivered over the web, it is a platform for the creation of software, delivered over the web.

IaaS (Infrastructure as a Service):

Infrastructure as a Service (IaaS) is a way of delivering Cloud Computing infrastructure servers, storage, network and operating systems as an ondemand service. Rather than purchasing servers, software, datacenter space or network equipment, clients instead buy those resources as a fully outsourced service on demand. In the subsequent posts, I would be writing a case study suggesting how Organizations are cutting down huge costs significantly around the world using the concept of Cloud Computing. - See more at: http://www.gontu.org/cloud-computing-difference-between-saas-paas-andiaas/#sthash.iUN6EPSm.dpuf

Cloud computing in plain English

Jun 13, 2012

Cloud Computing refers to the delivery of computing and storage capacity as a service to a heterogeneous community of end-recipients. Cloud is a computing model providing web-based software, middleware and computing resources on demand. By deploying technology as a service, you give users access only to the resources they need for a particular task. You pay for what you use! and prevents you from paying for idle computing resources. Cloud computing can also go beyond cost savings by allowing your users to access the latest software and infrastructure offerings to foster business innovation. This video talks about: what CLOUD Computing is all about! and of course its importance.
- See more at: http://www.gontu.org/cloud-computing-in-plain-english/#sthash.cJVIh9Rc.dpuf