By Pallavi Sharma

If you are trying to automate your web application using selenium, a few things which you should know before you start the quest. For most of the selenium commands a “target” is required which is laymen terms is the object in your web-application on which you wish to perform a desired action.

Selenium follows a location strategy to locate the element in your application which consists of four modes:

1. Locating by Identifier.

2. Locating by XPath/CSS

3. Locating by DOM

4. Location by CSS

You will find detail description of the above locating techniques on the selenium website which are explained well there [http://seleniumhq.org/]. But what not is explained is when to use what and the negatives of each locating strategy.

1. Locating by Identifier: To locate an element using an identifier means that the element must have either an “ID” attribute or “NAME” attribute which should be unique on that page. You may use “type” or “index” property in combination with these identifiers to help selenium uniquely identify the element.

Selenium is right in expecting that if will find an element uniquely by locating using an identifier. The W3-standards also states that the “ID” attribute has to be provided for all elements and it should be unique. But since the HTML has no inherent check on such slip-ups, most of the developers end up doing so in their web applications while developing forgetting that it has to undergo testing also.

So if you know before hand that “Selenium” is the automation tool which suits your web application scenario the best; ensure your developers haven’t made such mistakes.

2. Locating by XPath: To locate an element using an Xpath, is not a very straightforward solution but it helps immensely when you have to use multiple attributes to help locating an element. Xpath is a powerful way of using any attribute by which you would want the tool to find the element and perform action on it. It is useful mostly in the cases when the developers have used same name, ids across the website and didn’t cared for the W3-standards.

But if you can expect your developers to overlook W3 standards for unique IDs you may very well expect them to give you “unclosed” tags in your application! And if your web application has even a single unclosed tag, Selenium won’t be able to detect the element using the “XPath”.

So if the above is the locating method, you expect to find an element ensure you don’t have unclosed tags in the application.

3. Locating by DOM: The last resort to find an element and weakest one to. It is not advisable to use especially if your website undergoes too many changes. And also if the intention of testing your web site is functional/regression.

4. Locating by CSS: If for initial thoughts you are thinking that what if my web-app doesn’t have CSS will this work, then the answer is “Yes”. This locator type works whether you have CSS or don’t have CSS. It is faster than X-Path, and as stated on the Selenium website, experience users like to use the CSS way of locating an element. This also doesn’t works if the DOM is broken, and also is browser depended, as different browsers have different way of handling CSS.

To summarize the above, it is vital to do a W3 standard check on your website so that you can throw all issues back at your developers to fix, before you jump in to testing your website using Selenium. A good starting point is the, W3-validator [http://validator.w3.org/] available freely online. It clearly list down the issues like duplicate ids, unclosed tags and other slip-ups. Selenium is a powerful tool to use to test your web application across operating systems and browsers but if the DOM is broken than none of the locators will work, coz selenium using the browsers java script engine so the results will also depend on which browser you are using for the test.

It is not mentioned clearly on the website www.seleniumhq.org when to use what locator strategy, and it is kind of overwhelming information why they have provided all such locator categories to the users? Couldn’t there have been a simpler and straight forward way of handling elements using just a single locator type which works under any circumstance. I don’t know the answer to this yet, but maybe will have….

Till the next blog happy testing your sites with Selenium.

By Pallavi Sharma

In this blog post we will understand how we use Rational SOA Tester tool to test our web services.

Pre Requisites:

1.    Rational Performance Tester to be installed on the system.
2.    Rational SOA Tester plug-in to be installed on it.
3.    The WSDL files of the web services you wish to test.

Once you have all these inputs in place you can start testing your web service right away. First of all you will create a Performance Test Project in RPT. We create a performance test project as RPT uses the same framework to test web service as it uses for performance testing. Once we are done with that we need to import our WSDL file from the file system to the project folder.

After we have imported the WSDL file, we will create our very first test for this web service. To do so, we need to start the Recorder, and chose Web Service Recording using the Web Services Explorer.

You will see your web service in the Web Service Explorer mode. The web service explorer mode will list down the methods and clicking on any method will ask you to input the method arguments, once done that click next and it will show you the output, meanwhile the recorder is recording all the request – responses and once done when you click on stop recording the test is generated.

Now you have in your hands a recorded web service test. In the next series we will see how do, we go about editing the web service test. Use datapool to parameterize the test, use verification points to validate the test etc.

References:

1. Soa Tester Tutorials: IBM.

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

In the last series we saw what are the various challenges which a tool should overcome to test a SOA based application. We saw a list of commercial and open source tools which can assist us in testing our web services.

From this series we will take each tool one by one and understand what all it has to offer us. The first solution to web service testing we will consider is the one provided by Rational. Rational offers the following solutions:

a. Rational Tester for SOA Quality
b. Rational Performance Tester Extension for SOA Quality.

Following are the list of features which they offer:

• Both built on Rational Performance Tester technology
• Support for Web Services standards UDDI, WSDL, SOAP, HTTP, HTTPS, WS-Security
• Integrated with Rational Test Management tools (Test Manager with ClearQuest)
• Monitoring tools (Tivoli) can be easily integrated with it.

The best part of this tool is for both functional and performance testing of the web service we can use the same interface of Rational Performance Tester. As shown in the figure below:

[Fig- 1a]

Following are the various advantages of Rational SOA Tester:

• Simplify testing of GUI-less service
o Automated generation of web service test client
o No programming knowledge necessary to create, comprehend, modify, and execute a functional or performance test
o Automated data correlation and data driven testing through a code-free test environment
• Simplify service integration testing
o Automated test creation from Web Sphere Business Process Execution Language resources
• Create, comprehend, modify, and execute a functional or performance test
o Graphical test editor enables both high-level and deeper detail views
o Support Web services standards (e.g. SOAP,HTTP(S), WS-Security, UDDI)

How to Get Rational SOA Tester:

You need to have Rational Performance Tester 7.01 installed on your system. Once you have that you can download the SOA Tester as an extension over RPT. The link for the same is as follows: http://www.ibm.com/developerworks/downloads/r/tsq/learn.html?S_TACT=105AGX15&S_CMP=ART

A simple tutorial explaining how you use the SOA tester will be the topic of our next blog series. Till then hopefully you have acquired the tool.
References:
1.http://www.ibm.com/developerworks/downloads/r/tsq/learn.html?S_TACT=105AGX15&S_CMP=ART

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

So far, we have undertaken the difficult voyage of web services, SOA-Architecture and have come out of it empowered with the knowledge of what this new buzz SOA is all about. In this series of blog we will delve deeper into SOA and understand how do, we go about testing SOA. We will also see what all tools both open source and commercial are available in the market to help us achieve it. We will also take each tool one by one and understand how to best utilize it to test SOA.

Let’s first understand what all issues needs to be considered when we test any web service: [Ref 1]
• Web Services are intrinsically distributed and are platform and language agnostic.
• Web Services can be chained with dependencies on other 3rd party Web Services that can change without notice.
• Web Services ownership is shared across various stakeholders.
• Web Services client developers typically only have access to interfaces (WSDLs) and lack access to code.
• High level of reuse of web services.

As we know web services are based upon loosely coupled architecture. They are platform and language independent which increases the complexity of testing them. A web service usually calls another web service which might be a third party service. Oftenly 3rd party web service changes without prior information resulting in your web service failure. Also, if you are using a 3rd party web service all you have access to is a WSDL document of the web service and no code is available. A 3rd party web service can be used by a large number of users raising performance and security concerns which needs to be taken care of also.

Keeping all this in mind we need to also judge a test tool which takes the following issues into consideration:

• No User Interface to easily play a test
• High level of reuse of the services
• Testing at the service and end-to-end levels
• Interoperability, conformance, security penetration…
• Support of SOA standards and specific implementations WSDL, SOAP, UDDI, HTTP, WS-Security, …

A test tool to test any web service should support the various SOA standards like WSDL, SOAP, XML. Usually there is no UI available to test a web service. So the test tool should provide a user friendly interface to test the GUI less service. It should also assist in testing the interoperability, conformance issues which do arises in web service testing.

The commercial tools which are available in the market to test web services are:

1. IBM : Rational SOA Tester
2. HP: LR and QTP
3. Crosschecknet
4. Parasoft

The open source tools for SOA testing are as follows: [Ref 2]

1. Eviware SoapUI 1.6
2. PushToTest TestMaker
3. WebInject

In the coming series we will take each tool one by one and understand how do, we test the web service using it.

References:

1. http://www.crosschecknet.com/soa_testing_black_white_gray_box.php
2. http://www.infoworld.com/article/07/05/11/19TCwebservicetest_1.html

(Copyrighted by CresTech Software Systems Pvt. Ltd.)

By Pallavi Sharma

In the last article ‘Series-I’ we got familiar with SOA architecture, and its some components. We saw how a web service ‘wsdl’ file looks like and learnt how we decipher the complex information present in the file, so that we understand the web service better. In this series we will dig deeper into SOA architecture and try to figure out how exactly the various components of SOA architecture communicate with each other to solve the complex business need.

Let us get back to our ‘MoneyConverter’ web service. I typed in the url on the browser http://localhost/MoneyConverter/Converter.asmx and this is what I got:

[Fig: 1a]
Now click on any of the method to find out the request and response format for them:

[Fig: 1b]
We will now test the web service method; the screen shot for the same is attached below:

[Fig: 2a]
Response:

[Fig: 2b]
Till now we saw what to expect if we open the web service in the browser. It displays the information about the various methods present in the service. The request and response format of each method of the service. And if the service is hosted locally on the system then you may invoke it and test its methods.

So far so good, but is it all to the complex web service architecture. Well no, what we just saw was the front end of the SOA architecture. Lets get to the back end of the architecture and understand how exactly the various components of the architecture communicate with each other to provide us with the result. Let’s take a good look at the diagram below before we move further:

[Fig: 2c]
As clear from the diagram we can see three components of the SOA architecture: Service Provider, Directory and Service Consumer. They communicate with each other in form of xml packets over the SOAP protocol. We will take each part of the figure and understand its role:

1. Service Provider: A service provider is the one who has actually built the web service to fulfill a business requirement. The web service will be hosted at the service provider location and the service consumer has to communicate with the provider to get its work done.
2. Directory: A directory is where the Service Provider publishes the ‘WSDL’ file related to the web service. Directory could be a local directory or UDDI. UDDI stands for Universal Description, Discovery, and Integration; it is defined as a directory of services. A service consumer first queries the directory for the wsdl file of the web service.
3. Service Consumer: A service consumer is the one who requires the web service to meet its business requirement. It has to first query the directory to get hold of the wsdl file of the web service. This is also known as discovering the web service. It then constructs its request to be queried directly against the service provider for the response.

The communication among the components is as follows:

1. The Service consumers, first queries the directory of services for the web service. This is also known as ‘Discovery’.
2. The Directory responses back using the WSDL file to the Service Consumer.
3. The Service Consumer now using the WSDL file generates the SOAP request which is sent to the Service Provider which in return responds back with the SOAP response based on the WSDL file.

Enlightened with the functioning of a web service architecture we come to the end of this series of the blog. In the next series we will start exploring how do we go about testing a web service and what all tools both open source and commercial are available for it.
References:

1. http://www.service-architecture.com/web-services/articles/web_services_explained.html

(Copyrighted by CresTech Software Systems Pvt. Ltd.)