Google December 2014

How to Install the Selenium IDE

Hi Webies, since excel automation has some limits in the web sites, Open Source tools like Selenium IDE has good exposure to web testing, so today I'm going to explain how to install the Selenium IDE (Integrated Developement Environment) in browser.

The Selenium-IDE (Integrated Development Environment) is the tool you use to develop your Selenium test cases. It’s an easy-to-use Firefox plug-in and is generally the most efficient way to develop test cases. It also contains a context menu that allows you to first select a UI element from the browser’s currently displayed page and then select from a list of Selenium commands with parameters pre-defined according to the context of the selected UI element. This is not only a time-saver, but also an excellent way of learning Selenium script syntax.
Step 1: Download the IDE from the SeleniumHQ downloads page
Step 2: Click ‘Allow’ to proceed with the installation.
Step 3: Select Install Now. The Firefox Add-ons window pops up, first showing a progress bar, and when the download is complete. Restart Firefox. After Firefox reboots you will find the Selenium-IDE listed under the Firefox Tools menu.

Dynamic Scripting Using Rational Functional Tester

**The following article provides brief introduction to a heavily used aspect of Rational Functional Tester(RFT).  The reader is expected to have basic knowledge of RFT**  .
Introduction -
Rational Functional Tester (RFT) provides user with a  "Recorder"  that, as the name suggests,  records user actions on an Application Under Test(AUT) to create a script and this script can be played back by RFT to perform the same actions back on the AUT.

The script when generated with the help of the Recorder is backed up by an Object Map which  consists of  Objects that correspond to the actual control that the recorder interacted with while recording.
These objects  in the object map are representations of the controls in the AUT and are stored with a hierarchy and set of properties ( called Recognition Properties for the object).
During Playback , the playback engine uses this hierarchy and recognition properties to find the control in the AUT and then performs the specified action on it.

For example, the following shows code snippet of a script that performs a click on a button.
This statement  has two parts to it , first one being the okbutton() , if you notice it is not a variable  but a method , this method (which is implemented by the Helper class of the script) finds the actual control in the AUT using the properties and hierarchy stored in the object map , once the object is found the the operation i.e  click() is performed on it.
Using  Dynamic Scripting -
The above mentioned scenario is a traditional usage of  the Rational Functional Tester as a testing tool. Now, lets proceed to the topic that is heart of this article ... Dynamic Scripting.
Rational Functional Tester also gives you capability to hand-code  your script  , so that you can define the object you are looking for and tell RFT to perform whatever action you wish to perform on the actual object.
When you do so you are no longer bound to a static object map , your script itself would determine what are the properties of an object and how to look for it.
 Let me explain it with an example again.
Following code snippet shows  how  we can use the find() api to find the  search Text box on the google search page.
                              public void testMain(Object[] args)
                                    Property p1 = new Property(".class","Html.INPUT.text");
                                    Property p2 =  new Property(".name","q");   
                                    Property[] properties = {p1, p2};       
                                    TestObject[] candidates = find(atDescendant(properties));
                                    System.out.println("Found "+ candidates.length + " objects");   
                                    if( candidates.length ==0)
                                         System.out.prinltn("No object found with the specified property set ");
                                     //Something found  , perform some action.
                                    ((TextGuiTestObject)candidates[0]).setText("hello world");                                

testMain()is a method that is invoked by RFT playback engine.
Property defines a property name-value pair ,these properties could be Properties that are exhibited by the control or may be defined by RFT.
For eg:   ".class" property is defined by RFT and corresponds to the "tag" of an element  , in the example above  ".class" "Html.INPUT.text" corresponds to the  html  tag <input type=text>
The second property that is being used above is  the  ".name" property which is same as the  "name" property of the <input tag>, so instead of using ".name"  you could very well use "name"  as the property name.
Next we have defined an array to hold this property which is what the one of the forms of find()api expects, there other forms of find()api which also expect  the  name and value pair directly  so you could specify the properties as :

The find()api returns an array of TestObject which match the specified property set so its upto you to decide which one to pick ,or perhaps you should give more properties or unique properties so that we get a single candidate as a result (if applicable).
Proceeding further, find() does not accept the property directly , the find expects a Subitem( a class that belongs to RFT)..this subitem  is what is returned by the method - atDescendant and the other like  atChild,atList etc.
These methods (atD
escendant,atChild,atList) tell whether to search for the given property set at  Descendant Level , or Child level, or through a list.
atChild() will be faster then atDescendant() as it will only search at the direct child level  unlike atDescendant() that is going to be exhaustive because it is going to drill down to each child and its children until there is none left.
atList() gives guided path for the object we are looking for.
You have to have good familiarity  with the Application Under Test(AUT)  in order to make a good use of the find()api.
find() api can also be called on another TestObject and in that case that TestObject becomes the  starting point for the search.
By default   RootTestObject becomes the parent for the find()api to start the search with.
so the  statement:  
is equivalent to
If  we were able to find the objects  (as returned by the find() API)  next we need to perform some action on it. 
Note that the find() api  returns an  Array of   TestObject   which  may not expose the required  functions  as it  plain test object   to perform some  GUI related action like click() ...
as done in the statement,
,we must typecast it to a ..   GuiTestObject .
The Next  statement :
                ((TextGuiTestObject)candidates[0]).setText("hello world");  
again  typecasts  the TestObject to TextGuiTestObject because now we want to invoke a "text" related operation .. i.e   setText().  
So you should know what kind of different TestObjects RFT provides( the  API help has documentation on  each one of them) .

Moving ahead there is a call to remove the binding of the returned testobjects as a result of find()api, through the call to :
 the other forms of this API are:
                                   unregister(candidates);  //where candidates is an Array of TestObject returned by the the find()api.
                                  TestObject.unregister(); //Where TestObject is an object found  by the find() api.
It is important to unregister the objects once done  using them because unless you free these objects which are returned by the find()api (or some other similar APIs like getChildren())  ,there will be some memory still held by these object to reference the actual controls in the application.  And it may have its effect on the application during long executions of scripts.(*Remember that the proxy gets loaded into the AUT process and hence using the memory allocated to the  AUT process )
So the conclusion is that RFT gives user the capability to do a custom search/find for the required object  along with a Recorder that generates the script and object map automatically.
A test-script  very well could be a combination of hand-coded  scripts and the code generated by the recorder.
On one hand using a recorder is pretty simple and straightforward  and may be sufficient  for most of the cases but Handed coded scripts give you the flexibility to find the objects the way you want(or in situations where recorder may not be able to detect a control or perhaps playback engine is not able to find the object the hierarchy and recognition properties of a mapped test object ) , however it would require you to have some coding skills (in Java or VB depending on the IDE you are using).
And last but important point to note is that when using the dynamic scripting  the onus of freeing the objects  found by the find() api is with the user.  Releasing object is as simple as just adding a call to  "unregisterAll() " (or other variants) once done with using the object.
The playback engine does this thing automatically  when the object  is a mapped test object thus explicit  release of objects is not required when using  traditional record and playback. 
Reference :