A Practical File

On
Software Testing and Validation Lab

Submitted In Partial Fulfilment of the requirements for the award of degree of

Bachelor of Technology
In
Computer Science & Engineering
From

University College of Engineering and Technology, Bikaner

Affiliated to

Bikaner Technical University, Bikaner

Session: 2022-2023

Submitted By: Sagar Narendra Solanki

Roll No.: 19ECTCS062
Branch and Year: 4 th Year and 8th Semester
 lOMoARcPSD|25743713

List of Experiments
1. (a) Write a program that calculates the area and perimeter of the circle. And find the
Coverage & Test Cases of that program using JaButi Tool.

(b) Write a program which read the first name and last name from console and matching with
expected result by using JaBuTi.

(c) Write a program that takes three double numbers from the java console representing ,
respectively, the three coefficients a ,b, and c of a quadratic equation.

(d) Write a program that reads commercial website URL from a url from file. you should
expect that the URL starts with www and ends with .com. retrieve the name of the site and
output it. For instance, if the user inputs www.yahoo.com, you should output yahoo. After
that find the test cases and coverage using JaBuTi.

(e) Write a program for a calculator and find the test case and coverage and Def-use-graph.

(f) Write a program that reads two words representing passwords from the java console and
outputs the number of character in the smaller of the two. For example, if the words
are open and sesame, then the output should be 4, the length of the shorter word, open. And
test this program using JaBuTi.

2. Analyze the performance of following website using JMeter.

3. Calculate the mutation score of programs given in 1(a) to 1 (f) using jumble Tool.

4. Calculate the coverage analysis of programs given in 1 (a) to 1 (f) using Eclemma Free open
source Tool.

5. Generate Test sequences and validate using Selenium tool for given websites below:

lOMoARcPSD|25
 lOMoARcPS

EXPERIMENT 1(a)

Name of Experiment: Write a program that calculates the area and perimeter of the circle.And
find the Coverage & Test Cases of that program using JaButi Tool.

Aim :

Steps to perform Experiment:

Program Code:AreaOfCircle.java
import java.util.Scanner;
import java.lang.Math;
public class AreaOfCircle
{
public static void main(String[] args)
{
int option;
double radius, circumference, diameter, area;
//object of the Scanner class
Scanner sc=new Scanner (System.in);
//options available
System.out.println("1. If the radius is known");
System.out.println("2. If the diameter is known");
System.out.println("3. If the circumference is known");
System.out.print("Enter your choice: ");
//taking an option as input from the user
option=sc.nextInt();
switch(option)
{
//Case statements
case 1:

System.out.print("Enter the radius of the circle: ");

radius=sc.nextDouble();
area=(Math.PI*(radius*radius));
System.out.print("The area of the circle is: "+area);
break;
case 2:

System.out.print("Enter the diameter of the circle: ");

diameter=sc.nextDouble();
area=Math.PI*(diameter*diameter)/4;
System.out.print("The area of the circle is: "+area);
break;
case 3:

System.out.print("Enter the circumference of the circle: ");

circumference=sc.nextDouble();
area=(circumference*circumference)/(4*Math.PI);
System.out.print("The area of the circle is: "+area); break;

//default case statement executes when an invalid choice is

entered default:System.out.println("invalid choice!"); }

}
}

Compile Java Program:>_ javac AreaOfCircle.java

It will create a new file AreaOfCircle.class

// BYTE CODE
Now assign this ByteCode to JaBUTi Tool for Coverage Testing by following steps
 EXPERIMENT : 1(b)

Name of Experiment: Write a program which read the first name and last name from console
and matching with expected result by using JaBuTi.

Steps to perform Experiment:

Program Code: AreaOfCircle.java

Import java.util.Scanner;

/**
* An example program to read a Name from console input in Java */
Public class Example {

Public static void main(String[] args) {

System.out.print("Enter a Name : ");
Scanner scanner = new Scanner(System. in);
String inputString = scanner. nextLine();
System.out.println("String read from console is : \n"+input
String);
}
}
Note : Repeat all step according to Experiment 1 in JABUTI

23
 EXPERIMENT : 1(c)

Name of Experiment: Write a program which read the first name and last name from console
and matching with expected result by using JaBuTi.

Steps to perform Experiment:

Program Code: qeqvation.java

public class q eqvation
{
public static void main(String[] args) {
// value a, b, and c
double a = 2.3, b = 4, c = 5.6;
double root1, root2;

// calculate the determinant (b2 - 4ac)

double determinant = b * b - 4 * a * c;

// check if determinant is greater than

0 if (determinant > 0) {

// two real and distinct roots

root1 = (-b + Math.sqrt(determinant)) / (2 * a);
root2 = (-b - Math.sqrt(determinant)) / (2 * a);

System.out.format("root1 = %.2f and root2 = %.2f", root1, root2);

}

// check if determinant is equal to

0 else if (determinant == 0) {

// two real and equal roots

// determinant is equal to 0
// so -b + 0 == -b
root1 = root2 = -b / (2 * a);
System.out.format("root1 = root2 = %.2f;", root1);
}
 // if determinant is less than
zero else {

// roots are complex number and distinct

double real = -b / (2 * a);

double imaginary = Math.sqrt(-determinant) / (2 * a);

System.out.format("root1 = %.2f+%.2fi", real, imaginary);
System.out.format("\nroot2 = %.2f-%.2fi", real, imaginary);
}
}
}

Note: Repeat all step according to Experiment 1 in JABUTI

 lOMoARcPSD|25743713

EXPERIMENT : 1(D)

Name of Experiment: Write a program that reads commercial website URL from a url from
file. You should expect that the URL starts with www and ends with .com. Retrieve the name
of the site and output it. For instance, if the user inputs www.yahoo.com, you should output
yahoo. After that find the test cases and coverage using JaButi.

Steps to perform Experiment:

Program Code:
package mypkg;

import java.io.*;

import javax.servlet.*;

import javax.servlet.http.*;

public class HelloServlet extends HttpServlet {

@Override

public void doGet(HttpServletRequest request, HttpServletResponse response)

throws IOException, ServletException {

// Set the response message's MIME type

response.setContentType("text/html;charset=UTF-8");

// Allocate a output writer to write the response message into the network
socket PrintWriter out = response.getWriter()
// Write the response message, in an HTML page

try {

out.println("<!DOCTYPE html>");
out.println("<html><head>");
out.println("<meta http-equiv='Content-Type' content='text/html; charset=UTF-8'>");

out.println("<title>Hello, World</title></head>"); out.println("<body>");

out.println("<h1>Hello, world!</h1>"); // says Hello // Echo client's request

information

out.println("<p>Request URI: " + request.getRequestURI() + "</p>");

out.println("<p>Protocol: " + request.getProtocol() + "</p>");

 out.println("<p>PathInfo: " + request.getPathInfo() + "</p>");

out.println("<p>Remote Address: " + request.getRemoteAddr() + "</p>");

// Generate a random number upon each request

out.println("<p>A Random Number: <strong>" + Math.random() + "</strong></p>");

out.println("</body>");

out.println("</html>");

} finally {

out.close(); // Always close the output writer

Note: Repeat all step according to Experiment 1 in JABUTI

 EXPERIMENT : 1(e)

Name of Experiment: Write a program for a calculator and find the test case and coverage and Def-use-
graph.

Steps to perform Experiment:

Program Code:
import java.util.Scanner;

class Main {

public static void main(String[] args) {

char operator;
Double number1, number2, result;

// create an object of Scanner class Scanner input =

new Scanner(System.in);
// ask users to enter operator System.out.println("Choose an

operator: +, -, *, or /"); operator = input.next().charAt(0);

// ask users to enter numbers

System.out.println("Enter first number"); number1

= input.nextDouble();

System.out.println("Enter second number");

number2 = input.nextDouble();
switch (operator) {

// performs addition between numbers

case '+':

result = number1 + number2;

System.out.println(number1 + " + " + number2 + " = " + result);
break;
// performs subtraction between numbers

case '-':

result = number1 - number2;

System.out.println(number1 + " - " + number2 + " = " + result);
break;
 // performs multiplication between
numbers case '*':

result = number1 * number2;

System.out.println(number1 + " * " + number2 + " = " + result);

break;
// performs division between numbers

case '/':
result = number1 / number2;
System.out.println(number1 + " / " + number2 + " = " + result);
break;
default:

System.out.println("Invalid operator!");

break;

input.close();

Note : Repeat all step according to Experiment 1 in JABUTI

 EXPERIMENT : 1(f)

Name of Experiment: Write a program that reads two words representing passwords from the
java console and outputs the number of character in the smaller of the two. For example, if the
words are open and sesame, then the output should be 4, the length of the shorter word, open.
And test this program using JaButi.

Steps to perform Experiment:

Program Code:
import java.util.Scanner;

public class Exercise11 {

public static final int PASSWORD_LENGTH = 8;

public static void main(String[] args) {

Scanner input = new Scanner(System.in);

System.out.print(
"1. A password must have at least eight characters.\n" +
"2. A password consists of only letters and digits.\n" +
"3. A password must contain at least two digits \n" +
"Input a password (You are agreeing to the above Terms and Conditions.): "); String
s = input.nextLine();

if (is_Valid_Password(s)) {
System.out.println("Password is valid: " + s);
} else {
System.out.println("Not a valid password: " + s);
}

public static boolean is_Valid_Password(String password) {

if (password.length() < PASSWORD_LENGTH) return false;

int charCount = 0;
int numCount = 0;
for (int i = 0; i < password.length(); i++) {

char ch = password.charAt(i);

if (is_Numeric(ch)) numCount++;
else if (is_Letter(ch)) charCount++;
else return false;
}

return (charCount >= 2 && numCount >= 2);

}
 public static boolean is_Letter(char ch) {
ch = Character.toUpperCase(ch);
return (ch >= 'A' && ch <= 'Z');
}

public static boolean is_Numeric(char ch) {

return (ch >= '0' && ch <= '9');

}

Note: Repeat all step according to Experiment 1 in JABUTI

 lOMoARcPSD|25743713

EXPERIMENT : 2

Name of Experiment: Analyze the performance of following website using JMeter.

Steps to perform Experiment:

JMeter Introduction
JMeter is a software that can perform load test, performance-oriented business (functional) test,
regression test, etc., on different protocols or technologies. Stefano Mazzocchi of the Apache
Software Foundation was the original developer of JMeter. He wrote it primarily to test the
performance of Apache JServ (now called as Apache Tomcat project). Apache later redesigned
JMeter to enhance the GUI and to add functional testing capabilities.
JMeter is a Java desktop application with a graphical interface that uses the Swing
graphical API. It can therefore run on any environment / workstation that accepts a Java virtual
machine, for example − Windows, Linux, Mac, etc.
The protocols supported by JMeter are −
• Web − HTTP, HTTPS sites 'web 1.0' web 2.0 (ajax, flex and flex-ws-amf)
• Web Services − SOAP / XML-RPC
• Database via JDBC drivers
• Directory − LDAP
• Messaging Oriented service via JMS
• Service − POP3, IMAP, SMTP
• FTP Service

JMeter Features
Following are some of the features of JMeter −
• Being an open source software, it is freely available.
• It has a simple and intuitive GUI.
• JMeter can conduct load and performance test for many different server types −
Web - HTTP, HTTPS, SOAP, Database via JDBC, LDAP, JMS, Mail - POP3, etc.
• It is a platform-independent tool. On Linux/Unix, JMeter can be invoked by clicking on
JMeter shell script. On Windows, it can be invoked by starting the jmeter.bat file.
• It has full Swing and lightweight component support (precompiled JAR uses packages
javax.swing.* ).
• JMeter store its test plans in XML format. This means you can generate a test plan using
a text editor.
• Its full multi-threading framework allows concurrent sampling by many threads and
simultaneous sampling of different functions by separate thread groups.
• It is highly extensible.
• It can also be used to perform automated and functional testing of the applications.
JMeter Working Techniques
JMeter simulates a group of users sending requests to a target server, and returns statistics that
show the performance/functionality of the target server/application via tables, graphs, etc.
Take a look at the following figure that depicts how JMeter works −
JMeter is a framework for Java, so the very first requirement is to have JDK installed in your
machine.
System Requirement

JDK 1.6 or above.

Memory No minimum requirement.

Disk Space No minimum requirement.

Operating System No minimum requirement.

Step 1: Verify Java Installation

First of all, verify whether you have Java installed in your system. Open your console and
execute one of the following java commands based on the operating system you are working on.

OS Task Command

Windows Open Command Console c:\> java -version

Linux Open Command Terminal $ java -version

Mac Open Terminal machine: ~ joseph$ java -version

If you have Java installed in your system, you would get an appropriate output based on the OS
you are working on.

OS Output

Windows java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Linux java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

Mac java version "1.7.0_25"

Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)

If you do not have Java installed, install the Java Software Development Kit (SDK)
from www.oracle.com/technetwork/java/javase/downloads/index.html. We are assuming Java
1.7.0_25 as the installed version for this tutorial.
 Step 2: Set Java Environment
Set the JAVA_HOME environment variable to point to the base directory location, where
Java is installed on your machine. For example −

OS Output

Windows SettheenvironmentvariableJAVA_HOMEtoC:\Program
Files\Java\jdk1.7.0_25

Linux export JAVA_HOME=/usr/local/java-current

Mac export JAVA_HOME=/Library/Java/Home

Append Java compiler location to System Path.

OS Output

Windows Append the string; C:\Program Files\Java\jdk1.7.0_25\bin to the end of the

system variable, Path.

Linux export PATH=$PATH:$JAVA_HOME/bin/

Mac not required

Verify Java Installation using java -version command as explained above.

Step 3: Download JMeter Download the latest version of JMeter from

https://jmeter.apache.org/download_jmeter.cgi. For this tutorial,we downloaded apache-jmeter-2.9
and copied it into C:\>JMeter folder.
The directory structure should look like as shown below −
• apache-jmeter-2.9
• apache-jmeter-2.9\bin
• apache-jmeter-2.9\docs
• apache-jmeter-2.9\extras
• apache-jmeter-2.9\lib\
• apache-jmeter-2.9\lib\ext
• apache-jmeter-2.9\lib\junit
• apache-jmeter-2.9\printable_docs

You can rename the parent directory (i.e. apache-jmeter-2.9) if you want, but do not change any
of the sub-directory names.
Step 4: Run JMeter
After downloading JMeter, go to the bin directory. In this case, it is /home/manisha/apache-
jmeter-2.9/bin.
After a short pause, the JMeter GUI should appear, which is a Swing application, as seen in the
following screenshot −

This is the main page and the default page of the tool.
Apache JMeter - User's Manual - https://jmeter.apache.org/usermanual/index.html
 EXPERIMENT : 3

Name of Experiment: Calculate the mutation score of programs given in 1(a) to 1 (f) using
jumble Tool.

Steps to perform Experiment:

Introduction to Jumble :
The primary entry point to Jumble is a single Java class that takes as parameters a class to be
mutation tested and one or more JUnit test classes. The output is a simple textual summary of
running the tests. This is in the style of JUnit test output and includes an overall score of how
many mutations were successfully caught as well as details about those mutations that are not.
This includes the source line and the mutation performed. Variants of the output include a
version compatible with Java development in emacs where it is possible to click on the line and
go to the source line containing the mutation point. A plugin for the Eclipse IDE [10] has been
provided. Currently it permits only jumbling of a single class. When running the mutation tests a
separate JVM [11] is used to prevent runaway or system-exiting code disturbing the testing
process. It is given a number which specifies the mutation to start at and it continues until all
mutations have been tested or some catastrophic failure occurs. It has been very important to
separate the test execution in this way for reasons discussed below. If a failure occurs in one
mutation then the child JVM can be restarted and testing continues with the next mutation.
Before running the mutation tests, a full run is done of the unit tests both to ensure that they all
pass, to ensure that there are no environmental problems when running the tests in this way and
to collect timing information to later detect mutations that lead to infinite loops. At Reel Two,
Jumble is integrated with an internal continual integration system, on several source code
repositories. Every fifteen minutes this checks out all the source code, clean compiles it and then
runs all the unit tests for packages that have been modified. It also places all modified classes on
a queue to be mutation tested. After the unit testing has been done, Jumble is used to test classes
until the fifteen minute time limit is exceeded. Overnight more time is dedicated to mutation
testing so that any tests that have been accumulated during the day can be cleared. The results of
the Jumble tests for a project are presented in a web interface. These give results for individual
classes and accumulate results over the package hierarchy. The web interface permits a manual
override of the test queuing so that classes which have not been modified can be retested. This is
sometimes necessary when the Jumble code itself has been modified or when a class needs to be
retested because of changes in other classes that it interacts with.
In summary we typically use three different ways of running Jumble:
• directly from the command line where the class com.reeltwo.jumble.Jumble is provided
with the name of the class to be tested and the class(es) which test it (among many other
options). Executing directly from the distributed jumble.jar will achieve the same effect.
• from the Eclipse IDE where there is a menu item for a class which runs Jumble on that
class (it is possible to configure other options for such runs)
• as part of a web based system where all classes are tested incrementally as they are
committed and results accumulated in a set of webpages.

Jumble System
In this section we discuss individual parts of the Jumble system and the issues that arose in
implementing them.

Byte code Mutation

Jumble performs its mutations by directly modifying Java byte codes using the BCEL package
[12]. This allows the mutation testing to be done with no compilations. The byte code translation
approach has been used before. Mothra used an intermediate code form to store and execute
mutants. The intermediate form was not a standard code form, however, and was directly
designed to represent mutations, which were still done by analyzing source code. MuJava also
used byte code translation for structural mutations. Behavioural mutations however are still done
with source code analysis using the MSG method [6]. The reason for this is that the behavioral
mutations in MuJava were intended to be the same mutations as those implemented in Mothra.
Thus, while MuJava manages to avoid multiple compilations, it still requires source code
analysis to perform the mutations. As mentioned above, Jester does not use any sophisticated
techniques and performs a compilation for every mutation. Basing the mutations entirely on byte
code also simplifies the implementation of Jumble and allows code to be tested even when the
source code is not available. Jumble mutates all the Java byte code instructions that can be
mutated safely in a context-free way. That is, each instruction eligible for mutation is replaced by
another instruction independently of the instructions around it. An instruction A can be replaced
by an instruction B if A and B operate on the operand stack in the same way – they expect the
same number and type of arguments on the stack before the operation and leave the same number
and type of arguments on the stack after operation. For example, the iadd (integer addition)
instruction can be replaced by the isub (integer subtraction), since both pop the top two operands
from the top of the stack and push the result of the computation (respectively the sum and
difference of the two operands) onto the stack. Particularly helpful is BCEL’s ability to generate
byte code for the negation of arbitrary conditionals. A wide range of byte code instructions are
mutated including conditionals, arithmetic operations including increments and decrements, and
switch statements. As well inline constants, class pool constants, and return values are mutated.
More details can be found in the “Mutations” link in [4]. The mutations are all implemented
using the facilities of BCEL and within the limitations of BCEL’s facilities the addition of new

mutations is straightforward. Care needs to be taken to avoid mutating instructions in some parts
of the code. For example, it makes no sense to mutate assertion statements. Detection of
assertion statements is done by their reference to the class level flag which indicates when
assertions are enabled. The pattern of code generated by the compiler is then used to detect the
end of the assertion. Unfortunately such patterns are compiler dependent and care is needed
when moving to new compilers and new JDK releases. Other code that needs to be excluded are
conditionals generated when class constants are accessed, lengths for certain array allocations,
and switch code generated for enumerations. A facility is provided to globally exclude certain
named methods from mutation. In practice this is used to exclude main methods (this is coupled
with a coding standard that main methods should be as short as possible and that they should call
another method with such things as input and output files as parameters). Also excluded are
“integrity” methods which can be called on a class to check that its internal state is currently

consistent. These effectively function as post conditions and like assertions should be excluded.
Jumble also mutates constants, both those that occur inline and those that occur in the constant
pool. An integer constant x is transformed to (-x + 1) which works correctly even when the
integer represents a boolean. In Java boolean, short, and char data types, are implemented in
bytecode as 32-bit ints. Consequently, Jumble cannot readily discriminate among these types.
Constants in the constant pool (such as String literals) are also mutated. The constant pool for a
class often contains entries not referenced by any line of code or only referenced by immutable
code such as assertions. Care is taken not to modify such literals.
Class Loader

One feature of the BCEL which has been extremely useful in the development of Jumble is its
customizable class loader. It allows classes to be modified as they are loaded into the JVM. The
process is much simpler than creating a class loader from scratch, as the processing of the actual
class file is done by the BCEL and the user only has to implement a modify Class method to
perform bytecode modifications on the fly. The Jumble class loader is derived from the BCEL
class loader. Given the name of the class to modify (the target class) and the mutation number, it
loads the class with the mutation inserted. All classes other than the target class are loaded
normally with no modifications. The Jumble test suite is an extension of the JUnit test suite. It
runs a JUnit test in a way suitable for Jumble testing, by running the tests until one fails.
A “PASS” message is returned at that stage and no further tests are run. If no tests fail, a
“FAIL” message is returned. The Jumble test suite is given the name of the test to run as a string
and loads the test class dynamically (using Class.forName). The Jumble test suite is intended to
be loaded in the Jumble class loader so that the tests are run with a mutated class. When running
several mutations inside a single JVM, a separate class loader must be used for each mutated
version of the class being tested. To ensure independence between mutation tests, the entire set
of (non-system) classes are reloaded in each class loader, and the classes being tested are not
available directly from the system class loader. Heavy usage of class loaders in this way can use
a lot of memory in the permgen space in the JVM, particularly for classes that make use of many
thirdparty libraries. In practice it has been difficult to prevent increasing usage of the permgen
space as the tests are run. This is dealt with in two ways. Firstly the child JVM that is used to run
the tests is given additional permgen space when it is started. Secondly after each test is run a
check is done to see if the available permgen space is nearly exhausted, if so the child process is
terminated and restarted (it will then start at the next mutation). Some code remains difficult to
run within the Jumble environment. Typically this involves code that attempts to directly access
the system class loader (such code is usually incorrectly written, and unlikely to function when
run in similar environments, such as within the Tomcat servlet container).

Detecting and Terminating Infinite Loops

Some mutations become stuck in an infinite loop. It is reasonable to consider an infinite loop as a
failed test and hence mutation points which cause infinite loops can be considered tested. Thus
Jumble needs to be able to detect infinite loops caused by mutations and terminate them. Infinite
loops are detected by timing the original test running on a class without any mutations. Timing
measurements are made using the System. Current Time Mill is method. This introduces two
difficulties. Firstly, the granularity of the value returned from the method is dependent on the
underlying operating system. Secondly, the value returned is a measure of elapsed time, not CPU
time allocated to the current process. Thus, the time measures obtained are somewhat imprecise
and nondeterministic. This is not a problem as long as the non determinism is accounted for.
Each mutated test run can then be timed and the runtime can be periodically compared against a
runtime limit and an infinite loop is considered detected if the limit is exceeded. The formula for
the runtime limit is: RUNTIME LIMIT = 10 x ORIGINAL RUNTIME + 2 s This formula is
somewhat arbitrary but works reasonably well in practice. The most difficult situation is when a
test is the first to be run, then effects such as classes being loaded and static code being executed
can increase the apparent execution time. Once an infinite loop is detected, it needs to be
terminated.
One option is to run the mutation testing in a separate Java thread, and terminate the thread when
an infinite loop is detected. The problem with this approach is that there is no inherently safe
way of terminating a Java thread while being guaranteed to leave the rest of the system in a
consistent state. Use of the Thread.stop() method is strongly discouraged. The method used in
Jumble is to terminate the child JVM that is running the tests and for it to note that the test has
been successful. Then the child JVM is restarted at the next mutation.

Applicability and Limitations

The Jumble system will run with code generated for Java 1.3 to 1.6. It has been run on code that
uses multi-threading and concurrent processes. The biggest difficulties have been with systems
that implement their own class loaders (see discussion above) and with variations of different
compilers. The greatest difficulties with compilers is in detecting code such as assertions where
the patterns may differ from compiler to compiler. Jumble has been successfully used with javac,
jikes and the Java compiler in the Eclipse IDE.
 EXPERIMENT : 4

Name of Experiment: Calculate the coverage analysis of programs given in 1 (a) to 1 (f)
using Eclemma Free open source Tool.
Steps to perform Experiment:

Eclemma is a free Java code coverage tool for Eclipse, available under the Eclipse Public
License. It brings code coverage analysis directly into the Eclipse workbench:
• Fast develop/test cycle: Launches from within the workbench like JUnit test runs can
directly be analyzed for code coverage.
• Rich coverage analysis: Coverage results are immediately summarized and highlighted in
the Java source code editors.
• Non-invasive: EclEmma does not require modifying your projects or performing any
other setup.
Since version 2.0 EclEmma is based on the JaCoCo code coverage library. The Eclipse
integration has its focus on supporting the individual developer in an highly interactive way. For
automated builds please refer to JaCoCo documentation for integrations with other tools.
Originally EclEmma was inspired by and technically based on the great EMMA library
developed by Vlad Roubtsov.
The update site for EclEmma is http://update.eclemma.org/. EclEmma is also available via the
Eclipse Marketplace Client, simply search for "EclEmma".

Features

Launching

EclEmma adds a so called launch mode to the Eclipse workbench. It is called Coverage mode
and works exactly like the existing Run and Debug modes. The Coverage launch mode can be
activated from the Run menu or the workbench's toolbar:

Simply launch your applications or unit tests in the Coverage mode to collect coverage
information. Currently the following launch types are supported:
• Local Java application
• Eclipse/RCP application
• Equinox OSGi framework
• JUnit test
• TestNG test
• JUnit plug-in test
• JUnit RAP test
• SWTBot test
• Scala application
Analysis
On request or after your target application has terminated code coverage information is automatically available in the
Eclipse workbench:

• Coverage overview: The Coverage view lists coverage summaries for your Java projects, allowing drill-
down to method level.
• Source highlighting: The result of a coverage session is also directly visible in the Java source editors. A
customizable color code highlights fully, partly and not covered lines. This works for your own source code
as well as for source attached to instrumented external libraries.
Additional features support analysis for your test coverage:

• Different counters: Select whether instructions, branches, lines, methods, types or cyclomatic complexity
should be summarized.
• Multiple coverage sessions: Switching between coverage data from multiple sessions is possible.

• Merge Sessions: If multiple different test runs should be considered for analysis coverage sessions can
easily be merged.

Import/Export
While Eclemma is primarily designed for test runs and analysis within the Eclipse workbench, it provides some import/export
features.

• Execution data import: A wizard allows to import JaCoCo *.exec execution data files from external
launches.
• Coverage report export: Coverage data can be exported in HTML, XML or CSV format or as JaCoCo
execution data files (*.exec).
 lOMoARcPSD|25743713

EXPERIMENT : 5

Name of Experiment: Generate Test sequences and validate using Selenium tool for given
websites below:

Steps to perform Experiment:

Selenium is an open-source and a portable automated software testing tool for testing web
applications. It has capabilities to operate across different browsers and operating systems.
Selenium is not just a single tool but a set of tools that helps testers to automate web-based
applications more efficiently.
Creating Selenium IDE Tests
The following steps are involved in creating Selenium tests using IDE:
Recording and adding commands in a test
Saving the recorded test
Saving the test suite
Executing the recorded test
Recording and Adding Commands in a Test
We will use www.ncalculators.com to demonstrate the features of Selenium.
Step 1 : Launch the Firefox browser and navigate to the website –
http://www.ncalculators.com/
Step 2 : Open Selenium IDE from the Tools menu and press the record button that is on the top-
right corner

Step 3 : Navigate to "Math Calculator" >> "Percent Calculator >> enter "10" as number1 and 50
as number2 and click "calculate".
 lOMoARcPSD|25743713

Step 4 : The recorded script is generated and the script is displayed as shown below.
 lOMoARcPSD|25743713

Saving the Recorded Test

Step 1 : Save the Test Case by navigating to "File" >> "Save Test" and save the file in the
location of your choice. The file is saved as .HTML as default. The test can also be saved with an
extension htm, shtml, and xhtml

Saving the Test Suite

A test suite is a collection of tests that can be executed as a single entity.
Step 1 : Create a test suite by navigating to "File" >> "New Test Suite" as shown below.
lOMoARcPSD|25743713

Step 2 : The tests can be recorded one by one by choosing the option "New Test Case" from the
"File" Menu.
Step 3 : The individual tests are saved with a name along with saving a "Test Suite"
Executing the Recorded Test
The recorded scripts can then be executed either by clicking "Play entire suite" or "Play current
test" button in the toolbar.
Step 1 : The Run status can be seen in the status pane that displays the number of tests passed
and failed.
Step 2 : Once a step is executed, the user can see the result in the "Log" Pane.
Step 3 : After executing each step, the background of the test step turns "Green" if passed and
"Red" if failed as shown below