Academy

of Economic Studies Cybernetics and Economic Informatics Faculty

Academy of Economic Studies

Cybernetics and Economic Informatics Faculty
Computer Science Department

Laboratory 3

Functional Test Automation

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Table of Contents
1. What is Functional Test Automation?
1.1. Overview
1.2. Why using Test Automation
1.3. When to use Test Automation
1.3.1. When to Automate
1.3.2. When NOT to Automate
1.4. Return on Investment
2. Automation Tools
2.1. Tools for Code-driven Testing
2.2. Tools for GUI-Testing
3. Automation Frameworks
3.1. Framework Approach in Test Automation
3.1.1. Why Implement a Framework?
3.2. Types of Automation Frameworks
3.3. General Framework architecture
3.3.1. Master Test Scripts
3.3.2. Common Functions/Tasks (Script Functions)
3.3.3. Data-pools (BD Layer)
3.3.4. Application Map (Object Repository)
3.3.5. Logging Module
4. Selenium-IDE
4.1. Introduction
4.2. Installing the IDE
4.3. Opening the IDE
4.4. IDE Features
4.4.1. Menu Bar
Toolbar
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Test Case Pane
Log/Reference/UI-Element/Rollup Pane
4.4.2. Log
4.4.3. Reference
4.5. Building Test Cases
4.5.1. Recording
4.5.2. Adding Verifications and Asserts With the Context Menu
4.6. Editing
4.6.1. Insert Command
4.6.2. Insert Comment
4.6.3. Edit a Command or Comment
4.7. Opening and Saving a Test Case
4.8. Running Test Cases
4.9. Commonly Used Selenium Commands
Verifying Page Elements
4.10. Assertion or Verification?
verifyTextPresent
verifyElementPresent
verifyText
4.11. Locating Elements
4.11.1. Locating by Identifier
4.11.2. Locating by Id
4.11.3. Locating by Name
4.11.4. Locating by XPath
4.11.5. Locating Hyperlinks by Link Text
4.11.6. Locating by CSS
4.12. Store Commands and Selenium Variables
storeElementPresent
storeText
storeEval
4.13. Using while loops in Selenium
4.14. Refferences

Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Theoretical Part

1. What is Functional Test Automation?

1.1. Overview
Test Automation is a complex process that has the result of using a computer’s program to execute
system or user transactions against an IT system. This is typically achieved by using an automated test tool.
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Automated testing is typically used in functional regression testing, performance testing, load testing, network
testing and security testing. This laboratory is intended to cover the main aspects of the Functional Test
Automation.
Manual testing is performed by a human sitting in front of a computer carefully executing the test
steps. This may prove very costly in terms of time and money for repetitive tasks. A manual approach might
not always be effective in finding certain classes of defects, too.
Test automation offers a possibility to perform repetitive testing effectively. Once tests have been
automated, they can be run quickly and repeatedly. Many times, this can be a cost effective method for
regression testing of software products that have a long maintenance life.

1.2. Why using Test Automation

Automated testing is important due to following reasons:

● Manual Testing of all work flows, all fields , all negative scenarios is time and cost
consuming
● It is difficult to test for multi lingual sites manually
● Automation does not require Human intervention. You can run automated test unattended
(overnight)
● Automation increases speed of test execution
● Automation helps increase Test Coverage
● Manual Testing can become boring and hence error prone.

So, automated delivered software present the following key benefits:
➢ Cumulative Coverage
It is a fact that applications change and gain
complexity over their useful life. As depicted in the
figure, the feature set of an application grows
steadily over time. Therefore, the number of tests
that are needed for adequate coverage is also
constantly increasing. Just a 10% code change still
requires that 100% of the features be tested. That
is why manual testing can’t keep up – unless you
constantly increase test resources and cycle time,
your test coverage will constantly decline.
Automation can help this by allowing you to
accumulate your test cases over the life of the
application so that both existing and new features can always be tested.
➢ Faster time to market
Automation can help reduce time to market by allowing test execution to happen 24X7. Once the test
library is automated, execution is faster and run longer than manual testing. Of course, this benefit is only
available once your tests are automated.
➢ Reduce cost of failure
Software is used for high risk, mission critical applications that represent revenue and productivity. A
single failure could cost more than the entire testing budget for the next century! In one case a single bug
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

resulted in costs of almost $2 billion. Automation can reduce the cost of failure by allowing increased coverage
so that errors are uncovered before they have a chance to do real damage in production.

1.3. When to use Test Automation

Automated tests are a very useful and impressive tool used to make testing more efficient. However,
automated tests are not suited to all projects – this may be due to lack of time available, or due to technical
limitations. Automated tests take time to create. Depending on the testers, it can take 3-10 times the amount
of time to create an automated test as it takes to run the same test manually. Therefore, automated tests will
only start to be valuable when they are run more than 3-10 times.

1.3.1. When to Automate

✓ When spending a lot of time by testing manually.
✓ When regression testing is essential.
✓ When checking the functionality with huge sets of data.
✓ When verifying database, which contains additional data.
✓ When code coverage is vast.
✓ When the life span of the product is long

1.3.2. When NOT to Automate

✗ When application is not stable.
✗ When regression test is not necessary.
✗ When the application has lot of interdependency with other applications which in turn cannot be
automated.
✗ When time and resources are a constraint.
✗ When the complexity of application and of technologies used to develop is very high
✗ For applications with short life span.

1.4. Return on Investment

Return on investment (ROI) is a performance measure used to evaluate the efficiency of an
investment or to compare the efficiency of a number of different investments. In our case, we are interested how
much we gain by implementing Test Automation in comparison with the benefits of Manual Testing.
Let’s have as an example the automation of testing for a small website that gets weekly content
updates. We would start by looking at the costs for the effort in terms of time.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

If we know the timeline for the project, let’s say we knew this website would be updated weekly for the
next year, we can calculate the return on investment for automation.

Cost of automation = price of hardware + price of software + time to develop scripts + (time to maintain scripts x
number of times scripts are executed) + (time to execute scripts x number of times scripts are executed)
Cost of automation = 2 computers @ $1,000 ea + 2 licenses @ $2,000 ea + 10 days @ $50 hr +
(1 day @ $50 hr x 52 weeks) + (1 hr @ $50 x 52 weeks)
Cost of automation = $2,000 + $4,000 + $4,000 + $20,800 + $2,600
Cost of automation = $33,400

Cost of manual = time to develop test cases + (time to maintain test cases x number of times tests are
executed) + (time to execute manual testing x number of times tests are executed)
Cost of manual = 4 days @ $50 hr + (1 day @ $50 x 26 weeks) + (1 day @ $100 x 52 weeks)
Cost of manual = $1,600 + $10,400 + $41,600
Cost of manual = $53,600

ROI = benefit / cost

ROI = (cost of manual – cost of automation) / cost of automation
ROI = ($53,600 - $33,400) / $33,400
ROI = about 61% over the course of the year
Observation: If the project life-span was larger than an year, then this rate would become bigger, due
to the cumulative coverage advantages of the test automation.

2. Automation Tools
2.1. Tools for Code-driven Testing
A growing trend in software development is the use of testing frameworks such as the xUnit
frameworks (for example, JUnit and NUnit) that allow the execution of unit tests to determine whether
various sections of the code are acting as expected under various circumstances. Test cases describe tests that
need to be run on the program to verify that the program runs as expected.
● JUnit is a unit testing framework for the Java programming language. JUnit has been important
in the development of test-driven development, and is one of a family of unit testing
frameworks collectively known as xUnit that originated with SUnit. JUnit is linked as a JAR at
compile-time; the framework resides under packages junit.framework for JUnit 3.8 and earlier
and under org.junit for JUnit 4 and later.
● NUnit is a unit-testing framework for all .Net languages. Initially ported from JUnit. It is written
entirely in C# and has been completely redesigned to take advantage of many .NET language
features, for example custom attributes and other reflection related capabilities. NUnit brings
xUnit to all .NET languages.

2.2. Tools for GUI-Testing

Many test automation tools provide record and playback features that allow users to interactively
record user actions and replay them back any number of times, comparing actual results to those expected.
The advantage of this approach is that it requires little or no software development. However, reliance on
these features poses major reliability and maintainability problems. Relabeling a button or moving it to
another part of the window may require the test to be re-recorded.
Popular Test Automation Tools:
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

● IBM Rational Functional Tester is a software test automation tool used by quality assurance teams to
perform automated regression testing. Testers create scripts by using a test recorder which captures a
user's actions against their application under test. The recording mechanism creates a test script from
the actions. The test script is produced as either a Java or Visual Basic.net application. Testers can edit
the script using standard commands and syntax of these languages. Typically, test scripts are run in a
batch mode where several scripts are grouped together and run unattended.
● HP Professional is automated testing software designed for testing various software applications and
environments. It performs functional and regression testing through a user interface such as a native
GUI or web interface. It works by identifying the objects in the application user interface or a web page
and performing desired operations, it can also capture object properties like name or handler ID. It
uses a VBScript scripting language to specify the test procedure and to manipulate the objects and
controls of the application under test. To perform more sophisticated actions, users may need to
manipulate the underlying VBScript.
● Selenium is a portable software testing framework for web applications. Selenium provides a
record/playback tool for authoring tests without learning a test scripting language (Selenium IDE). It
also provides a test domain-specific language (Selenese) to write tests in a number of popular
programming languages, including C#, Java, Groovy, Perl, PHP, Python and Ruby. The tests can then be
run against most modern web browsers. Selenium deploys on Windows, Linux, and Macintosh
platforms.
● Robot Framework is a generic test automation framework for acceptance testing and acceptance
test-driven development. It has easy-to-use tabular test data syntax and utilizes the keyword-driven
testing approach.
● FitNesse an automated testing tool for software. It is based on Ward Cunningham's Framework for
Integrated Test. FitNesse is designed to support acceptance testing rather than unit testing in that it
facilitates detailed readable description of system function.

3. Automation Frameworks
3.1. Framework Approach in Test Automation
A simplified scheme of the Test Automation Process will look like in the picture below. In the Design &
Develop phase, it is strongly recommended to implement a Test Automation Framework, or to design a
customized one that would fit best for the tasks it is intended to perform.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

A Test Automation Framework is a set of assumptions, concepts or practices that provide support for
automated software testing. It includes test objects, library files, reusable scripts, or anything which helps in
capturing and controlling the test activity. Developing an automated solution is very similar to developing
software. In software development, it is always good to start the development activity with a design in place

3.1.1. Why Implement a Framework?

• Provide overall structure for test library – Automation engineers will use the same library files or
methods across the test scripts.
• Drive greater consistency – There is consistency in the entire testing process – test scripts, test case
design, test flow, and so forth. Hence, it is easy to maintain and manage the process.
• Reduce amount of code to develop and maintain – A method (e.g. logging test results) is written in one
library file which everyone uses. There is no need for an automation engineer to write his or her own code.
• Maximize reusability – Test components (e.g. library files and test objects) are reusable. This activity
should be decided in advance. You have to analyze the application and identify the reusable components.
• Shield non-technical testers from code – When you have a framework, there is a well-defined interface
to all the library files and everyone (including non- technical testers of the application) will know where and
how to use them.
• Enable automation using data – Testing is data-driven where the test input data is separated from the
test scripts and it can be an efficient way to run tests that must be repeated many times using different sets of
data every time.

3.2. Types of Automation Frameworks

● Modular Framework:
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

➢ Most basic of the frameworks
➢ Programming strategy to build an abstraction layer in a front of a component and provides
modularity in the application design
➢ Create small scripts that represent modules and functions to construct larger tests
➢ Are combined in a hierarchical fashion to construct larger tests

★ This kind of framework if most suitable for applications that have low variety in terms of use
case flows. Where there is a core of common actions/flows of actions, from which the test
cases are derived.


● Test Library Architecture Framework
➢ Very similar to the script modularity framework
➢ Divides the AUT into procedures and functions instead of scripts
➢ Library files represent modules, section, and function of AUT
➢ The library files are called directly from the master test case script

★ This kind of framework if most suitable for the same type of applications as for the modular
one.

● Keyword-Driven Testing Framework
➢ Requires the development of data tables and keywords
➢ Tests looks very similar to manual test cases
➢ The data table and keywords are independent of the automation tool

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

★ This kind of framework if most suitable for application against whom there are not a lot of
actions to be performed. It can be easily used to automate against web-applications, as most
actions can be performed on any type of web-page.\

● Data-Driven Testing Framework
➢ Inputs and outputs are read from data files
o Database, excel files, xml files etc.
➢ Data is loaded into variables in captured or manually coded scripts
➢ It can be implemented using data-pools in the Rational Functional Tester

★ This kind of framework if most suitable for applications that have reached a stability in terms of
functional flows. It is very effective for improving test coverage, negative testing, or boundary
testing. Banking applications would fit to this.

● Hybrid Automation Framework
➢ It is a combination of all above techniques
➢ Allows data driven scripts to take advantage of the powerful libraries and utilities that usually
accompany a keyword driven architecture
➢ Combining the above types of framework, it may result in a structure that allows a large coverage,
using a wide variety and complex actions.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

★ This is an ideal type of framework that would ensure coverage, easy maintenance for
changing flows as well as a friendly layout so that non-technical users would be able to read
de code lines.

3.3. General Framework architecture
3.3.1. Master Test Scripts
The test Script is where all the framework components combine. At this level code lines represent
specific actions performed on the Application Under Test. By running a scripts a entire test case flow should
be performed on the application and at the end of the run, results of the actions and verifications performed
should be delivered.

3.3.2. Common Functions/Tasks (Script Functions)

This is an area containing small modules representing short and common flows actions performed on
the application. It is used for modular frameworks. These are called in the Master Test Script in an abstract
way.
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Example:
login (username, password){
fillUserSection(username);
fillPasswordSection(password);
clickLoginButton();
}

3.3.3. Data-pools (BD Layer)

Data-pools are files that contain necessary test data which is retrieved by the Master Test Script or by
a module from the “Tasks” area. These data may be used as an input data (like user names and password), or
as expected data that is compared with the information extracted from the Application Under Test.
This data may be stored in files with the extensions .csv, .xls, .xml, .txt, .ini etc. It is retrieved using
special methods, or keywords.

3.3.4. Application Map (Object Repository)

The Application map is an essential section of the framework. This is where all the identification
properties of the objects present in the application are stored. In order that an action is performed in the AUT
the tool must firstly identify the desired object to test against. It is using special “find methods” that have as
parameters the attributes retrieved from the Application Map.
As an example for a .html application Fire Bug, or Development Tools may be used to see these
attributes and store them in the application map. As you can see the object represented by the highlighted
image has properties like: .itemprop=”image” ; .class=”poza_produs” etc.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

3.3.5. Logging Module

The Logging module is a part of the framework that enables the user to insert verification lines in the
Master Test Script. The results of these verifications will be stored after the script is run in a specific log file.
The files may include snapshots of the application, or information about the manual step corresponding to the
verification performed.
The logging module may also include a screen video capture feature.

4. Selenium-IDE
4.1. Introduction
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.
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

4.2. Installing the IDE
Using Firefox, first, download the IDE from the SeleniumHQ downloads page
Firefox will protect you from installing addons from unfamiliar locations, so you will need to
click ‘Allow’ to proceed with the installation, as shown in the following screenshot.

When downloading from Firefox, you’ll be presented with the following window.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Select Install Now. The Firefox Add-ons window pops up, first showing a progress bar, and
when the download is complete, displays the following.

Restart Firefox. After Firefox reboots you will find the Selenium-IDE listed under the Firefox Tools
menu.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

4.3. Opening the IDE

To run the Selenium-IDE, simply select it from the Firefox Tools menu. It opens as follows with an
empty script-editing window and a menu for loading, or creating new test cases.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

4.4. IDE Features
4.4.1. Menu Bar
The File menu has options for Test Case and Test Suite (suite of Test Cases). Using these you
can add a new Test Case, open a Test Case, save a Test Case, export Test Case in a language
of your choice. You can also open the recent Test Case. All these options are also available for
Test Suite.
The Edit menu allows copy, paste, delete, undo, and select all operations for editing the
commands in your test case. The Options menu allows the changing of settings. You can set
the timeout value for certain commands, add user-defined user extensions to the base set of
Selenium commands, and specify the format (language) used when saving your test cases.
The Help menu is the standard Firefox Help menu; only one item on this menu–UI-Element
Documentation–pertains to Selenium-IDE.

Toolbar
The toolbar contains buttons for controlling the execution of your test cases, including a step
feature for debugging your test cases. The right-most button, the one with the red-dot, is the
record button.

Speed Control: controls how fast your test case runs.

Run All: Runs the entire test suite when a test suite with multiple test cases is loaded.

Run: Runs the currently selected test. When only a single test is loaded this button and the
Run All button have the same effect.

Pause/Resume: Allows stopping and re-starting of a running test case.

Step: Allows you to “step” through a test case by running it one command at a time. Use for
debugging test cases.

TestRunner Mode: Allows you to run the test case in a browser loaded with the Selenium-Core
TestRunner. The TestRunner is not commonly used now and is likely to be deprecated. This
button is for evaluating test cases for backwards compatibility with the TestRunner. Most
users will probably not need this button.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Apply Rollup Rules: This advanced feature allows repetitive sequences of Selenium commands
to be grouped into a single action. Detailed documentation on rollup rules can be found in the
UI-Element Documentation on the Help menu.

Record: Records the user’s browser actions.

Test Case Pane

Your script is displayed in the test case pane. It has two tabs, one for displaying the command
and their parameters in a readable “table” format.

The other tab - Source displays the test case in the native format in which the file will be
stored. By default, this is HTML although it can be changed to a programming language such
as Java or C#, or a scripting language like Python. See the Options menu for details. The
Source view also allows one to edit the test case in its raw form, including copy, cut and paste
operations.
The Command, Target, and Value entry fields display the currently selected command along
with its parameters. These are entry fields where you can modify the currently selected
command. The first parameter specified for a command in the Reference tab of the bottom
pane always goes in the Target field. If a second parameter is specified by the Reference tab,
it always goes in the Value field.

If you start typing in the Command field, a drop-down list will be populated based on the first
characters you type; you can then select your desired command from the drop-down.

Log/Reference/UI-Element/Rollup Pane
The bottom pane is used for four different functions–Log, Reference, UI-Element, and Rollup–
depending on which tab is selected.

4.4.2. Log
When you run your test case, error messages and information messages showing the progress
are displayed in this pane automatically, even if you do not first select the Log tab. These
messages are often useful for test case debugging. Notice the Clear button for clearing the
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Log. Also notice the Info button is a drop-down allowing selection of different levels of
information to log.

4.4.3. Reference
The Reference tab is the default selection whenever you are entering or
modifyingSelenese commands and parameters in Table mode. In Table mode, the Reference
pane will display documentation on the current command. When entering or modifying
commands, whether from Table or Source mode, it is critically important to ensure that the
parameters specified in the Target and Value fields match those specified in the parameter list
in the Reference pane. The number of parameters provided must match the number specified,
the order of parameters provided must match the order specified, and the type of parameters
provided must match the type specified. If there is a mismatch in any of these three areas,
the command will not run correctly.

While the Reference tab is invaluable as a quick reference, it is still often necessary to consult
the Selenium Reference document.

4.5. Building Test Cases

There are three primary methods for developing test cases. Frequently, a test developer will
require all three techniques.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

4.5.1. Recording
Many first-time users begin by recording a test case from their interactions with a website.
When Selenium-IDE is first opened, the record button is ON by default. If you do not want
Selenium-IDE to begin recording automatically you can turn this off by going under Options >
Options... and deselecting “Start recording immediately on open.”
During recording, Selenium-IDE will automatically insert commands into your test case based
on your actions. Typically, this will include:
● clicking a link - click or clickAndWait commands
● entering values - type command
● selecting options from a drop-down listbox - select command
● clicking checkboxes or radio buttons - click command
Here are some “gotchas” to be aware of:
● The type command may require clicking on some other area of the web page for it to
record.
● Following a link usually records a click command. You will often need to change this
toclickAndWait to ensure your test case pauses until the new page is completely loaded.
Otherwise, your test case will continue running commands before the page has loaded all its
UI elements. This will cause unexpected test case failures.

4.5.2. Adding Verifications and Asserts With the Context Menu

Your test cases will also need to check the properties of a web-page. This
requires assertand verify commands. We won’t describe the specifics of these commands
here; that is in the chapter on Selenium Commands – “Selenese”. Here we’ll simply describe
how to add them to your test case.
With Selenium-IDE recording, go to the browser displaying your test application and right click
anywhere on the page. You will see a context menu showing verify and/or assertcommands.
The first time you use Selenium, there may only be one Selenium command listed. As you use
the IDE however, you will find additional commands will quickly be added to this menu.
Selenium-IDE will attempt to predict what command, along with the parameters, you will
need for a selected UI element on the current web-page.
Let’s see how this works. Open a web-page of your choosing and select a block of text on the
page. A paragraph or a heading will work fine. Now, right-click the selected text. The context
menu should give you a verifyTextPresent command and the suggested parameter should be
the text itself.
Also, notice the Show All Available Commands menu option. This shows many, many more
commands, again, along with suggested parameters, for testing your currently selected UI
element.
Try a few more UI elements. Try right-clicking an image, or a user control like a button or a
checkbox. You may need to use Show All Available Commands to see options other
thanverifyTextPresent. Once you select these other options, the more commonly used ones
will show up on the primary context menu. For example, selecting verifyElementPresent for an
image should later cause that command to be available on the primary context menu the next
time you select an image and right-click.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Again, these commands will be explained in detail in the chapter on Selenium commands. For
now though, feel free to use the IDE to record and select commands into a test case and then
run it. You can learn a lot about the Selenium commands simply by experimenting with the
IDE.

4.6. Editing
4.6.1. Insert Command

Table View
Select the point in your test case where you want to insert the command. To do this, in the
Test Case Pane, left-click on the line where you want to insert a new command. Right-click
and select Insert Command; the IDE will add a blank line just ahead of the line you selected.
Now use the command editing text fields to enter your new command and its parameters.

Source View
Select the point in your test case where you want to insert the command. To do this, in the
Test Case Pane, left-click between the commands where you want to insert a new command,
and enter the HTML tags needed to create a 3-column row containing the Command, first
parameter (if one is required by the Command), and second parameter (again, if one is
required to locate an element) and third parameter(again, if one is required to have a value).
Example:
<tr>
<td>Command</td>
<td>target (locator)</td>
<td>Value</td>
</tr>

4.6.2. Insert Comment

Comments may be added to make your test case more readable. These comments are
ignored when the test case is run.
Comments may also be used to add vertical white space (one or more blank lines) in your
tests; just create empty comments. An empty command will cause an error during execution;
an empty comment won’t.

Table View
Select the line in your test case where you want to insert the comment. Right-click and select
Insert Comment. Now use the Command field to enter the comment. Your comment will
appear in purple text.

Source View
Select the point in your test case where you want to insert the comment. Add an HTML-style
comment, i.e., <!-- your comment here -->.

4.6.3. Edit a Command or Comment

Table View
Simply select the line to be changed and edit it using the Command, Target, and Value fields.
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Source View
Since Source view provides the equivalent of a WYSIWYG (What You See is What You Get)
editor, simply modify which line you wish–command, parameter, or comment.

4.7. Opening and Saving a Test Case

Like most programs, there are Save and Open commands under the File menu. However,
Selenium distinguishes between test cases and test suites. To save your Selenium-IDE tests
for later use you can either save the individual test cases, or save the test suite. If the test
cases of your test suite have not been saved, you’ll be prompted to save them before saving
the test suite.
When you open an existing test case or suite, Selenium-IDE displays its Selenium commands
in the Test Case Pane.

4.8. Running Test Cases

The IDE allows many options for running your test case. You can run a test case all at once,
stop and start it, run it one line at a time, run a single command you are currently developing,
and you can do a batch run of an entire test suite. Execution of test cases is very flexible in
the IDE.
Run a Test Case
Click the Run button to run the currently displayed test case.

Run a Test Suite

Click the Run All button to run all the test cases in the currently loaded test suite.

Stop and Start

The Pause button can be used to stop the test case while it is running. The icon of this button
then changes to indicate the Resume button. To continue click Resume.

Stop in the Middle

You can set a breakpoint in the test case to cause it to stop on a particular command. This is
useful for debugging your test case. To set a breakpoint, select a command, right-click, and
from the context menu select Toggle Breakpoint.

Start from the Middle

You can tell the IDE to begin running from a specific command in the middle of the test case.
This also is used for debugging. To set a startpoint, select a command, right-click, and from
the context menu select Set/Clear Start Point.

Run Any Single Command

Double-click any single command to run it by itself. This is useful when writing a single
command. It lets you immediately test a command you are constructing, when you are not
sure if it is correct. You can double-click it to see if it runs correctly. This is also available from
the context menu.

4.9. Commonly Used Selenium Commands

To conclude our introduction of Selenium, we’ll show you a few typical Selenium commands.
These are probably the most commonly used commands for building tests.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

open
opens a page using a URL.

click/clickAndWait
performs a click operation, and optionally waits for a new page to load.

verifyTitle/assertTitle
verifies an expected page title.

verifyTextPresent
verifies expected text is somewhere on the page.

verifyElementPresent
verifies an expected UI element, as defined by its HTML tag, is present on the page.

verifyText
verifies expected text and its corresponding HTML tag are present on the page.

verifyTable
verifies a table’s expected contents.

waitForPageToLoad
pauses execution until an expected new page loads. Called automatically when clickAndWait is
used.

waitForElementPresent
pauses execution until an expected UI element, as defined by its HTML tag, is present on the
page.

Verifying Page Elements

Verifying UI elements on a web page is probably the most common feature of your automated
tests. Selenese allows multiple ways of checking for UI elements. It is important that you
understand these different methods because these methods define what you are actually
testing.
For example, will you test that...
1. an element is present somewhere on the page?
2. specific text is somewhere on the page?
3. specific text is at a specific location on the page?
For example, if you are testing a text heading, the text and its position at the top of the page
are probably relevant for your test. If, however, you are testing for the existence of an image
on the home page, and the web designers frequently change the specific image file along with
its position on the page, then you only want to test that an image (as opposed to the specific
image file) exists somewhere on the page.

4.10. Assertion or Verification?

Choosing between “assert” and “verify” comes down to convenience and management of
failures. There’s very little point checking that the first paragraph on the page is the correct

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

one if your test has already failed when checking that the browser is displaying the expected
page. If you’re not on the correct page, you’ll probably want to abort your test case so that
you can investigate the cause and fix the issue(s) promptly. On the other hand, you may want
to check many attributes of a page without aborting the test case on the first failure as this
will allow you to review all failures on the page and take the appropriate action. Effectively an
“assert” will fail the test and abort the current test case, whereas a “verify” will fail the test
and continue to run the test case.
The best use of this feature is to logically group your test commands, and start each group
with an “assert” followed by one or more “verify” test commands. An example follows:
Command Target Value
open /download/
assertTitle Downloads
verifyText //h2 Downloads
assertTable 1.2.1 Selenium IDE
verifyTable 1.2.2 June 3, 2008
verifyTable 1.2.3 1.0 beta 2
The above example first opens a page and then “asserts” that the correct page is loaded by
comparing the title with the expected value. Only if this passes will the following command
run and “verify” that the text is present in the expected location. The test case then “asserts”
the first column in the second row of the first table contains the expected value, and only if
this passed will the remaining cells in that row be “verified”.

verifyTextPresent
The command verifyTextPresent is used to verify specific text exists somewhere on the page.
It takes a single argument–the text pattern to be verified. For example:
Command Target Value
verifyTextPresent Marketing Analysis
This would cause Selenium to search for, and verify, that the text string “Marketing Analysis”
appears somewhere on the page currently being tested. Use verifyTextPresent when you are
interested in only the text itself being present on the page. Do not use this when you also
need to test where the text occurs on the page.

verifyElementPresent
Use this command when you must test for the presence of a specific UI element, rather than
its content. This verification does not check the text, only the HTML tag. One common use is
to check for the presence of an image.
Command Target Value
verifyElementPresent //div/p/img
This command verifies that an image, specified by the existence of an <img> HTML tag, is
present on the page, and that it follows a <div> tag and a <p> tag. The first (and only)

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

parameter is a locator for telling the Selenese command how to find the element. Locators are
explained in the next section.
verifyElementPresent can be used to check the existence of any HTML tag within the page.
You can check the existence of links, paragraphs, divisions <div>, etc. Here are a few more
examples.
Command Target Value
verifyElementPresent //div/p
verifyElementPresent //div/a
verifyElementPresent id=Login
verifyElementPresent link=Go to Marketing Research
verifyElementPresent //a[2]
verifyElementPresent //head/title
These examples illustrate the variety of ways a UI element may be tested. Again, locators are
explained in the next section.

verifyText
Use verifyText when both the text and its UI element must be tested. verifyText must use a
locator. If you choose an XPath or DOM locator, you can verify that specific text appears at a
specific location on the page relative to other UI components on the page.
Command Target Value
This is my text and it occurs right
verifyText //table/tr/td/div/p
after the div inside the table.

4.11. Locating Elements

For many Selenium commands, a target is required. This target identifies an element in the
content of the web application, and consists of the location strategy followed by the location in
the format locatorType=location. The locator type can be omitted in many cases. The various
locator types are explained below with examples for each.

4.11.1. Locating by Identifier

This is probably the most common method of locating elements and is the catch-all default
when no recognized locator type is used. With this strategy, the first element with the id
attribute value matching the location will be used. If no element has a matching id attribute,
then the first element with a name attribute matching the location will be used.
For instance, your page source could have id and name attributes as follows:
1 <html>
2 <body>

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

3 <form id="loginForm">
4 <input name="username" type="text" />
5 <input name="password" type="password" />
6 <input name="continue" type="submit" value="Login" />
7 </form>
8 </body>
9 <html>

The following locator strategies would return the elements from the HTML snippet above
indicated by line number:
● identifier=loginForm (3)
● identifier=password (5)
● identifier=continue (6)
● continue (6)
Since the identifier type of locator is the default, the identifier= in the first three examples
above is not necessary.

4.11.2. Locating by Id
This type of locator is more limited than the identifier locator type, but also more explicit. Use
this when you know an element’s id attribute.
<html>
1 <body>
2 <form id="loginForm">
3 <input name="username" type="text" />
4 <input name="password" type="password" />
5 <input name="continue" type="submit" value="Login" />
6 <input name="continue" type="button" value="Clear" />
7 </form>
8 </body>
9 <html>
10

● id=loginForm (3)

4.11.3. Locating by Name

The name locator type will locate the first element with a matching name attribute. If multiple
elements have the same value for a name attribute, then you can use filters to further refine
your location strategy. The default filter type is value (matching the value attribute).
1 <html>
2 <body>
3 <form id="loginForm">
4 <input name="username" type="text" />
5 <input name="password" type="password" />
6 <input name="continue" type="submit" value="Login" />
7 <input name="continue" type="button" value="Clear" />
8 </form>
9 </body>

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

10 <html>

● name=username (4)
● name=continue value=Clear (7)
● name=continue Clear (7)
● name=continue type=button (7)
Note
Unlike some types of XPath and DOM locators, the three types of locators above allow
Selenium to test a UI element independent of its location on the page. So if the page
structure and organization is altered, the test will still pass. You may or may not want to also
test whether the page structure changes. In the case where web designers frequently alter
the page, but its functionality must be regression tested, testing via id and name attributes,
or really via any HTML property, becomes very important.

4.11.4. Locating by XPath

XPath is the language used for locating nodes in an XML document. As HTML can be an
implementation of XML (XHTML), Selenium users can leverage this powerful language to
target elements in their web applications. XPath extends beyond (as well as supporting) the
simple methods of locating by id or name attributes, and opens up all sorts of new possibilities
such as locating the third checkbox on the page.
One of the main reasons for using XPath is when you don’t have a suitable id or name
attribute for the element you wish to locate. You can use XPath to either locate the element in
absolute terms (not advised), or relative to an element that does have an id or name
attribute. XPath locators can also be used to specify elements via attributes other than id and
name.
Absolute XPaths contain the location of all elements from the root (html) and as a result are
likely to fail with only the slightest adjustment to the application. By finding a nearby element
with an id or name attribute (ideally a parent element) you can locate your target element
based on the relationship. This is much less likely to change and can make your tests more
robust.
Since only xpath locators start with “//”, it is not necessary to include the xpath= label when
specifying an XPath locator.
<html>
1 <body>
2 <form id="loginForm">
3 <input name="username" type="text" />
4 <input name="password" type="password" />
5 <input name="continue" type="submit" value="Login" />
6 <input name="continue" type="button" value="Clear" />
7 </form>
8 </body>
9 <html>
10

● xpath=/html/body/form[1] (3) - Absolute path (would break if the HTML was changed only
slightly)
Laboratory 3 – Functional Test Automation


Academy of Economic Studies Cybernetics and Economic Informatics Faculty

● //form[1] (3) - First form element in the HTML
● xpath=//form[@id='loginForm'] (3) - The form element with attribute named ‘id’ and the
value ‘loginForm’
● xpath=//form[input/@name='username'] (3) - First form element with an input child
element with attribute named ‘name’ and the value ‘username’
● //input[@name='username'] (4) - First input element with attribute named ‘name’ and the
value ‘username’
● //form[@id='loginForm']/input[1] (4) - First input child element of the form element with
attribute named ‘id’ and the value ‘loginForm’
● //input[@name='continue'][@type='button'] (7) - Input with attribute named ‘name’ and
the value ‘continue’ and attribute named ‘type’ and the value ‘button’
● //form[@id='loginForm']/input[4] (7) - Fourth input child element of the form element
with attribute named ‘id’ and value ‘loginForm’
These examples cover some basics, but in order to learn more, the following references are
recommended:
● W3Schools XPath Tutorial
● W3C XPath Recommendation
There are also a couple of very useful Firefox Add-ons that can assist in discovering the XPath
of an element:
● XPath Checker - suggests XPath and can be used to test XPath results.
● Firebug - XPath suggestions are just one of the many powerful features of this very useful
add-on.

4.11.5. Locating Hyperlinks by Link Text

This is a simple method of locating a hyperlink in your web page by using the text of the link.
If two links with the same text are present, then the first match will be used.
<html>
1 <body>
2 <p>Are you sure you want to do this?</p>
3 <a href="continue.html">Continue</a>
4 <a href="cancel.html">Cancel</a>
5 </body>
6 <html>
7

● link=Continue (4)
● link=Cancel (5)

Locating by DOM
The Document Object Model represents an HTML document and can be accessed using
JavaScript. This location strategy takes JavaScript that evaluates to an element on the page,
which can be simply the element’s location using the hierarchical dotted notation.
Since only dom locators start with “document”, it is not necessary to include the dom= label
when specifying a DOM locator.
1 <html>

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

2 <body>
3 <form id="loginForm">
4 <input name="username" type="text" />
5 <input name="password" type="password" />
6 <input name="continue" type="submit" value="Login" />
7 <input name="continue" type="button" value="Clear" />
8 </form>
9 </body>
10 <html>

● dom=document.getElementById('loginForm') (3)
● dom=document.forms['loginForm'] (3)
● dom=document.forms[0] (3)
● document.forms[0].username (4)
● document.forms[0].elements['username'] (4)
● document.forms[0].elements[0] (4)
● document.forms[0].elements[3] (7)
You can use Selenium itself as well as other sites and extensions to explore the DOM of your
web application. A good reference exists on W3Schools.

4.11.6. Locating by CSS

CSS (Cascading Style Sheets) is a language for describing the rendering of HTML and XML
documents. CSS uses Selectors for binding style properties to elements in the document.
These Selectors can be used by Selenium as another locating strategy.
<html>
1 <body>
2 <form id="loginForm">
3 <input class="required" name="username" type="text" />
4 <input class="required passfield" name="password" type="password" />
5 <input name="continue" type="submit" value="Login" />
6 <input name="continue" type="button" value="Clear" />
7 </form>
8 </body>
9 <html>
10

● css=form#loginForm (3)
● css=input[name="username"] (4)
● css=input.required[type="text"] (4)
● css=input.passfield (5)
● css=#loginForm input[type="button"] (7)
● css=#loginForm input:nth-child(2) (5)
For more information about CSS Selectors, the best place to go is the W3C publication. You’ll
find additional references there.
Note

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

Most experienced Selenium users recommend CSS as their locating strategy of choice as it’s
considerably faster than XPath and can find the most complicated objects in an intrinsic HTML
document.

4.12. Store Commands and Selenium Variables

You can use Selenium variables to store constants at the beginning of a script.
Also, when combined with a data-driven test design (discussed in a later
section), Selenium variables can be used to store values passed to your test
program from the command-line, from another program, or from a file.
The plain store command is the most basic of the many store commands and
can be used to simply store a constant value in a selenium variable. It takes
two parameters, the text value to be stored and a selenium variable. Use the
standard variable naming conventions of only alphanumeric characters when
choosing a name for your variable.
Command Target Value
store [email protected] userName
Later in your script, you’ll want to use the stored value of your variable. To
access the value of a variable, enclose the variable in curly brackets ({}) and
precede it with a dollar sign like this.
Command Target Value
verifyText //div/p ${userName}
A common use of variables is for storing input for an input field.
Command Target Value
type id=login ${userName}
Selenium variables can be used in either the first or second parameter and are
interpreted by Selenium prior to any other operations performed by the
command. A Selenium variable may also be used within a locator expression.
An equivalent store command exists for each verify and assert command.
Here are a couple more commonly used store commands.

storeElementPresent
This corresponds to verifyElementPresent. It simply stores a boolean value–
”true” or “false”–depending on whether the UI element is found.

Laboratory 3 – Functional Test Automation

Academy of Economic Studies Cybernetics and Economic Informatics Faculty

storeText
StoreText corresponds to verifyText. It uses a locater to identify specific page
text. The text, if found, is stored in the variable. StoreText can be used to
extract text from the page being tested.

storeEval
This command takes a script as its first parameter. Embedding JavaScript
within Selenese is covered in the next section. StoreEval allows the test to
store the result of running the script in a variable.

4.13. Using while loops in Selenium

Please check the following links for tutorials:
http://www.testingdiaries.com/selenium-ide-loop/
https://www.youtube.com/watch?v=SbN92y7JMxM

4.14. Refferences

http://www.seleniumhq.org/docs/02_selenium_ide.jsp
https://www.youtube.com/watch?v=IhJgrLjljpc
https://www.youtube.com/watch?v=N06S26yo8jg

Laboratory 3 – Functional Test Automation