Amity University Madhya Pradesh

Gwalior

CSE 822
SOFTWARE TESTING & QUALITY ASSURANCE
LAB

Submitted to: Submitted by:

Ms. Arunima Shivhare Shruti Singh Kushwah
Assistant Professor A60205221243
ASET – CSE B-Tech CSE [E]
VIII Semester

1
 TABLE OF CONTENT

Exp. Name of Experiment Date Page No. Sign

No.
1. Design test cases using Boundary value analysis by taking 3-5
quadratic equation Problem.
2. Design test cases using Equivalence class partitioning 6-9
taking triangle problem.
3. Design test cases using Decision table taking date 10-18
problem.
4. Design independent paths by calculating cyclometric 19-25
complexity using date problem.
5. Design independent paths by taking DD path using date 26-30
problem.
6. Design the test cases for login page of AMIZONE. 31-35
7. Manual Testing for PAN card verification. 36
8. Generate test case for ATM machine. 37
9. Overview of Testing process using Rational Robot. 38-43
10. Write a script to record verification point using Rational 44-52
Robot (For GUI testing of single click on window OS).
11. Write a script to record verification point for Clip Board 53-55
and alphanumeric values using Rational Robot.
12. Write a script to record verification point for CASE 56-57
INSENSITIVE values using Rational Robot.
13. Write a script to record verification point for RANGE values 58-60
using Rational Robot.
14. Write a script to record verification point for OBJECT 61-62
PROPERTIES values using Rational Robot.

2
 EXPERIMENT No. 1

OBJECTIVE: Design test cases using Boundary value analysis by taking quadratic equation problem.
SOFTWARE REQUIRED: Turbo C++ Environment
THEORY: Boundary value analysis is a software testing (Black Box) technique in which tests are designed
to include representatives of boundary values. The idea comes from the Boundary (topology).
Given that we have a set of test vectors to test the system, a topology can be defined on that set. Those inputs
which belong to the same equivalence class as defined by the equivalence partitioning theory would
constitute the basis (topology). Given that the basis sets are neighbours as defined in neighbourhood
(mathematics) , there would exist boundary between them. The test vectors on either side of the boundary
are called boundary values. In practice this would require that the test vectors can be ordered, and that the
individual parameters follow some kind of order (either partial order or total order). The expected input and
output values to the software component should be extracted from the component specification. The values
are then grouped into sets with identifiable boundaries. Each set, or partition, contains values that are
expected to be processed by the component in the same way.

BOUNDARY VALUE ANALYSIS:

PROGRAM: Consider a program for the determination of the nature of roots of a quadratic equation. Its
input is a triple of positive integers (say a,b,c) and values may be from interval [0,200]. The program output
may have one of the following words.
• Not a quadratic equation
• Real roots
• Imaginary roots
• Equal roots

CODE:

#include<stdio.h>

3
#include<math.h>
#include<conio.h>
#include<iostream.h>
void main()
{
int a,b,c,d;
clrscr();
cout<<"The Quadratic equation is of the type a(x^2)+bx+c=0"<<endl;
cout<<"Enter the value of a: "<<endl;
cin>>a;
cout<<"Enter the value of b: "<<endl;
cin>>b;
cout<<"Enter the value of c: "<<endl;
cin>>c;
d=(b*b)-4*a*c;
if((a<0)||(b<0)||(c<0)||(a>100)||(b>100)||(c>100))
cout<<"Invalid input"<<endl;
else if(a==0)
cout<<"Not a quadratic equation"<<endl;
else if (d==0)
cout<<"Roots are equal"<<endl;
else if(d<0)
cout<<"Imaginary roots"<<endl;
else
cout<<"Real Roots"<<endl;
getch();
}
TEST CASES:

OUTPUT:

4
RESULT: The result interprets that the program used conforms to Boundary Value Analysis.

EXPERIMENT No. 2

5
OBJECTIVE: Design test cases using Equivalence class partitioning taking triangle problem.
SOFTWARE REQUIRED: Turbo C++ Environment
THEORY: Equivalence Class Testing
In this method, input domain of a program is partitioned into a finite number of equivalence classes such
that one can reasonably assume, but not be absolutely sure, that the test of a representative value of each
class is equivalent to a test of any other value.
Two steps are required to implementing this method:
1. The equivalence classes are identified by taking each input condition and partitioning it into valid and
invalid classes. For example, if an input condition specifies a range of values from 1 to 999, we identify one
valid equivalence class [1<item<999]; and two invalid equivalence classes [item<1] and [item>999].
2. Generate the test cases using the equivalence classes identified in the previous step. This is performed by
writing test cases covering all the valid equivalence classes. Then a test case is written for each invalid
equivalence class so that no test contains more than one invalid class. This is to ensure that no two invalid
classes mask each other.

Figure: Equivalence partitioning

Most of the time, equivalence class testing defines classes of the input domain. However, equivalence
classes should also be defined for output domain. Hence, we should design equivalence classes based on
input and output domain.
Consider a program for the classification of a triangle. Its input is a triple of positive integers (say a,b,c)
from the interval [1,100]. The output may be [Scalene, Isosceles, Equilateral, Not a triangle].

PROGRAM: write a program in C++ to find the area of a Triangle and perform Equivalence class
testing on it.
#include<iostream.h>
#include<conio.h>

6
#include<process.h>
void main()
{
clrscr();
int ch;
char c;
float b,h,a;
do
{
cout<<"\Enter the base of the triangle (1-200)";
cin>>b;
if((b<=0)||(b>200))
{
cout<<"\n Invalid entry for base \n";
goto b;
}
cout<<"\n Enter the height of the triangle (1-200)";
cin>>h;
if((h<=0)||(h>200))
{c
out<<"\n Invalid height\n Enter the valid height (1-200)";
goto h;
}
a= 0.5*b*h;
cout<<"\n The area is : "<<a;
cout<<"\n Want to enter more?(y/n)";
cin>>c;
}
while((c=='y')||(c=='y'));
getch();

7
}

Test cases: In Equivalence class testing, we find two types of equivalence classes; input domain and output
domain;
Input domain is formed from one valid sequence and two invalid sequences. The output domain is obtained
from different types of output of a problem.

For Triagle:
Input domain:::
I1 = {h : h<=0}
I2 = {h : H>200}
I3 = {h : 1<=h<=200}
I4 = {b : b<=0}
I5 = {b : b>200}
I6 = {b : 1<=b<=200}

Test cases:

Output domain:::
O1 = {<h,b> : triangle in h > 0,b>0}
O2 = {<h,b> : Not a triangle if h<=0, b<=0}

OUTPUT:

8
RESULT: The result interprets that the program used conforms to Equivalence Class Test.

9
 EXPERIMENT No. 3

OBJECTIVE: Design test cases using Decision table taking date problem.
SOFTWARE REQUIRED: Turbo C++ Environment
THEORY: Decision tables are a precise yet compact way to model complicated logic. Decision tables, like
flowcharts and if-then-else and switch-case statements, associate conditions with actions to perform, but in
many cases do so in a more elegant way.
Decision tables, especially when coupled with the use of a domain-specific language, allow developers and
policy experts to work from the same information, the decision tables them. Tools to render nested if
statements from traditional programming languages into decision tables can also be used as a debugging
tool.
Decision tables have proven to be easier to understand and review than code, and have been used extensively
and successfully to produce specifications for complex systems.

PROGRAM: Consider a program for the determination of Previous date. Its input is a triple of day, month
and year with the values in the range
1 ≤ month ≤ 12
1 ≤ day ≤ 31
2000 ≤ year ≤ 2030
The possible outputs are “Previous date” and “Invalid date”.

10
CODE:
#include<iostream.h>
# include<conio.h>
int leap(int year);
void main()
{
clrscr();
int dc,month,date,year,dm,dn,leap;
cout<<"Enter the date";
cin>>date;
cout<<"\nEnter the month";
cin>>month;
cout<<"\nEnter the year:";
cin>>year;
cout<<"\nEntered date is:"<<date<<"/"<<month<<"/"<<year;
if(leap==0)
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=59;
if(month==4)
dm=90;
if(month==5)
dm=120;
if(month==6)
dm=151;
if(month==7)

11
dm=181;
if(month==8)
dm=212;
if(month==9)
dm=243;
if(month==10)
dm=273;
if(month==11)
dm=304;
if(month==12)
dm=334;
}
else
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=60;
if(month==4)
dm=91;
if(month==5)
dm=121;
if(month==6)
dm=152;
if(month==7)
dm=182;
if(month==8)
dm=213;

12
if(month==9)
dm=244;
if(month==10)
dm=274;
if(month==11)
dm=305;
if(month==12)
dm=335;
}
dc=dm+date;
cout<<"The no of Day is:"<<dc;
dn=dc%7;
if(dn==0)
cout<<"\nSaturday";
else if(dn==1)
cout<<"\nSunday";
else if(dn==2)
cout<<"\nMonday";
else if(dn==3)
cout<<"\nTuesday";
else if(dn==4)
cout<<"\nWednesday";
else if(dn==5)
cout<<"\nThursday";
else if(dn==6)
cout<<"\nFriday";
getch();
}
int leap(int year)
{

13
if(((year%100==0) && (year%400==0)) || (year%4==0))
{
return 1;
}
else
return 0;
}

TEST CASES:

The input domain can be divided into following classes:

I1= {M1: month has 30 days}
I2= {M2: month has 31 days except March, August and January}
I3= {M3: month is March}
I4= {M4: month is August}
I5= {M5: month is January}
I6= {M6: month is February}
I7= {D1: day = 1}
I8= {D2: 2 ≤ day ≤ 28}
I9= {D3: day = 29}
I10= {D4: day = 30}
I11= {D5: day = 31}
I12= {Y1: year is a leap year}
I13= {Y2: year is a common year}

14
The decision table is given below:

15
16
17
RESULT: The result interprets that the program used conforms to Decision Table.

18
 EXPERIMENT No. 4

OBJECTIVE: Design independent paths by calculating cyclometic complexity using date problem.
THEORY: Cyclomatic complexity is computed using the control flow graph of the program: the nodes of
the graph correspond to indivisible groups of commands of a program, and a directed edge connects two
nodes if the second command might be executed immediately after the first command. Cyclomatic
complexity may also be applied to individual functions, modules, methods or classes within a program.
The cyclomatic complexity of a section of source code is the count of the number of linearly independent
paths through the source code. For instance, if the source code contained no decision points such as IF
statements or FOR loops, the complexity would be 1, since there is only a single path through the code. If
the code had a single IF statement containing a single condition there would be two paths through the code,
one path where the IF statement is evaluated as TRUE and one path where the IF statement is evaluated as
FALSE.
Mathematically, the cyclomatic complexity of a structured program [note 1] is defined with reference to the
control flow graph of the program, a directed graph containing the basic blocks of the program, with an edge
between two basic blocks if control may pass from the first to the second. The complexity M is then defined
as:[2]
M = E − N + 2P
where
E = the number of edges of the graph
N = the numb er of nodes of the graph
P = the number of connected components (exit nodes).

19
The same function as above, shown as a strongly connected control flow graph, for calculation via the
alternative method. For this graph, E = 10, N = 8 and P = 1, so the cyclomatic complexity of the program is
10 - 8 + 1 = 3.
An alternative formulation is to use a graph in which each exit point is connected back to the entry point. In
this case, the graph is said to be strongly connected, and the cyclomatic complexity of the program is equal
to the cyclomatic number of its graph (also known as the first Betti number), which is defined as: [2]
M=E−N+P
This may be seen as calculating the number of linearly independent cycles that exist in the graph, i.e. those
cycles that do not contain other cycles within themselves. Note that because each exit point loops back to
the entry point, there is at least one such cycle for each exit point.
For a single program (or subroutine or method), P is always equal to 1. Cyclomatic complexity may,
however, be applied to several such programs or subprograms at the same time (e.g., to all of the methods
in a class), and in these cases P will be equal to the number of programs in question, as each subprogram
will appear as a disconnected subset of the graph.
It can be shown that the cyclomatic complexity of any structured program with only one entrance point and
one exit point is equal to the number of decision points (i.e., 'if' statements or conditional loops) contained
in that program plus one. [2] [3]
Cyclomatic complexity may be extended to a program with multiple exit points; in this case it is equal to:
π-s+2
Where ð is the number of decision points in the program, and s is the number of exit points

PROGRAM: Consider a program for the determination of previous date. Its input is a triple of day,
month and year with the values in the range
1 ≤ month ≤ 12
1 ≤ day ≤ 31
1900 ≤ year ≤ 2025
The possible outputs are “Previous date” and “Invalid date”.

CODE:
#include<iostream.h>

20
# include<conio.h>
int leap(int year);
void main()
{
clrscr();
int dc,month,date,year,dm,dn,leap;
cout<<"Enter the date";
cin>>date;
cout<<"\nEnter the month";
cin>>month;
cout<<"\nEnter the year:";
cin>>year;
cout<<"\nEntered date is:"<<date<<"/"<<month<<"/"<<year;
if(leap==0)
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=59;
if(month==4)
dm=90;
if(month==5)
dm=120;
if(month==6)
dm=151;
if(month==7)
dm=181;
if(month==8)

21
dm=212;
if(month==9)
dm=243;
if(month==10)
dm=273;
if(month==11)
dm=304;
if(month==12)
dm=334;
}
else
{
if(month==1)
dm=0;
if(month==2)
dm=31;
if(month==3)
dm=60;
if(month==4)
dm=91;
if(month==5)
dm=121;
if(month==6)
dm=152;
if(month==7)
dm=182;
if(month==8)
dm=213;
if(month==9)
dm=244;

22
if(month==10)
dm=274;
if(month==11)
dm=305;
if(month==12)
dm=335;
}
dc=dm+date;
cout<<"The no of Day is:"<<dc;
dn=dc%7;
if(dn==0)
cout<<"\nSaturday";
else if(dn==1)
cout<<"\nSunday";
else if(dn==2)
cout<<"\nMonday";
else if(dn==3)
cout<<"\nTuesday";
else if(dn==4)
cout<<"\nWednesday";
else if(dn==5)
cout<<"\nThursday";
else if(dn==6)
cout<<"\nFriday";
getch();
}
int leap(int year)
{
if(((year%100==0) && (year%400==0)) || (year%4==0))
{

23
return 1;
}
else
return 0;
}

TEST CASES:

Number of edges (e) = 65

Number of nodes (n) =49

24
(i) V(G) = e – n + 2P = 65 – 49 + 2 = 18
(ii) V(G) = π + 1 = 17 + 1 = 18
(iii) V(G) = Number of regions = 18

RESULT: The result interprets that the program used conforms to cyclometic complexity with output being
18 as cyclometic complexity.

EXPERIMENT No. 5

25
OBJECTIVE: Design independent paths by taking DD path using Triangle program.
THEORY: A way of looking at paths is to analyse a methods' data flow. A well-researched metric for this
analysis is called 'Define Use', or DU. A simplistic definition of DU is that if a variable is defined, it should
be used, and if it is used, it should be tested.
Specifically, a DU path for a variable is a path from the defining node to the usage node, thus the "flow of
data". DU paths are very good at identifying problems because the error usually occurs between the
definition and usage.
CC, on the other hand, only looks at control flow. A DU path has a better chance of being executed compared
to a CC path, but there are also other factors that play into that as well. Which one is better for unit testing?
My personal opinion is a hybrid approach, one that looks at the linear combination of DU and CC paths.
PROGRAM: Consider the program given in Figure for the classification of a triangle. Its input is a triple
of positive integers (say a,b,c) from the interval [1,100].
The output may be:
Scalene
Isosceles
Equilateral
Not a triangle
Invalid inputs

CODE:
# include<iostream.h>
# include<conio.h>
void main()
{
clrscr();
int a,b,c,s1,s2,s3;
cout<<"Enter the 3 sides of the triangle:";
cout<<"\nEnter first side:";
cin>>a;
cout<<"\nEnter the second side:";
cin>>b;
cout<<"\n Enter the third side:";

26
cin>>c;
s1=a*a;
s2=b*b;
s3=c*c;
if((a+b<=c) ||(b+c<=a)|| (a+c<=b))
{
cout<<"\nIt is not a Triangle";
}
else
{
if((s3==(s2+s1)) ||(s2==(s1+s3)) || (s1==(s2+s3)) )
{
cout<<"\nIt is a Right Angled Triangle";
}
else if((s1<(s2+s3)) && (s2<(s1+s3)) && (s3<(s1+s2)))
{
cout<<"\nIt is an Acute Triangle";
}
else if((s1>(s2+s3))||(s2>(s1+s3))||(s3>(s1+s2)))
{
cout<<"\nIt is an Obtuse Trianlge";
}
}
getch();
}

TEST CASES:
Flow graph of triangle problem is:

27
DD Path graph is given in Figure

Independent paths are:

i. ABFGNPQR
ii. ABFGNOQR

28
 iii. ABCEGNPQR
iv. ABCDEGNOQR
v. ABFGHIMQR
vi. ABFGHJKMQR
vii. ABFGHJMQR

Step I: The program flow graph is given in Figure (a). The variables used in the program are a,b,c, valid
input.
Step II: DD Path graph is given in Figure (b). The cyclomatic complexity of this graph is 7 and thus, there
are 7 independent paths.
Step III: Define/use nodes for all variables are given below:

29
Step IV: The du-paths are identified and are named by their beginning and ending nodes using above table.

RESULT: The result interprets that the program used has total 18 du-paths out of which four paths are not
definition clear.

30
 EXPERIMENT No. 6

Objective: Design the test cases for login page of AMIZONE

Software used: Manual testing
Procedure:
HOME PAGE: test URL : https://www.amizone.net
Preconditions: Open Web browser and enter the given url in the address bar. Home page must be displayed.
All test cases must be executed from this page.
Observations/ discussions/ output:

31
32
33
34
Conclusions: Test cases have been formulated.

35
 EXPERIMENT No. 7

Objective: Manual testing for PAN card verification

Software used: Manual Testing
Procedure: A PAN card number is taken as an input and checked for errors.

Observations/ discussions/ output:

Conclusions: Test cases have been formulated and PAN card number has been checked.

36
 EXPERIMENT No. 8

Objective: Generate test case for ATM machine

Software used: Manual testing
Procedure: An ATM card is swapped and checked for errors.

Observations/ discussions/ output:

Conclusions: Test cases have been formulated and ATM card has been tested.

37
 EXPERIMENT No. 9

AIM: Overview of Testing process using Rational Robot

THEORY: Rational Robot is a complete set of components for automating the testing of Microsoft
Windows client/server and Internet applications running under Windows NT 4.0, Windows XP, Windows
2000, Windows 98, and Windows Me. The main component of Robot lets you start recording tests in as few
as two mouse clicks. After recording, Robot plays back the tests in a fraction of the time it would take to
repeat the actions manually.

Other components of Robot are:

_ Rational Administrator – Use to create and manage Rational projects, which store your
testing information.
_ Rational TestManager Log – Use to review and analyze test results.
_ Object Properties, Text, Grid, and Image Comparators – Use to view and analyze the results of
verification point playback.
_ Rational SiteCheck – Use to manage Internet and intranet Web sites.
You use the Rational Administrator to create and manage projects.
Rational projects store application testing information, such as scripts, verification points, queries, and
defects. Each project consists of a database and several directories of files. All Rational Test components on
your computer update and retrieve data from the same active project.
Projects help you organize your testing information and resources for easy tracking. Projects are created in
the Rational Administrator, usually by someone with administrator privileges.

Steps required to work on Rational Robot

Step 1: Click on Start >Rational Software > Rational Administrator

38
Step 2: On Admin Window right click on Project and enter Project name and Location

39
Step 3: Keep Password Blank and click on next>finish

Step 4: On a new Configuration Project Window under Test Assets click on Create

40
Step 5: Select the Microsoft Access as the Database and click on next >finish

41
Step 6: In the Rational Administrator window click on Rational Robot Icon that is 10th from right

Step 7: After giving the name a GUI Record Window is displayed as follows

42
Step 8: You may now perform any function on the operating system and this GUI will record each and every
event that occurs

Step 9: Stop the recording and click on third icon named Specify Log Information and make build file giving
your testing name and a new window will open containing log information specifying whether it is pass or
fail

Conclusion: We understood all the steps needed to work on Rational Robot

43
 EXPERIMENT No. 10

AIM: Write a script to record verification point using Rational Robot (For GUI testing of single click on
window OS)
THEORY: When you record a GUI script, Robot records:
_ Your actions as you use the application-under-test. These user actions include keystrokes and mouse clicks
that help you navigate through the application.
_ Verification points that you insert to capture and save information about specific objects. A verification
point is a point in a script that you create to confirm the state of an object across builds. During recording,
the verification point captures object information and stores it as the baseline. During playback, the
verification point recaptures the object information and compares it to the baseline.
The recorded GUI script establishes the baseline of expected behavior for the application-under-test. When
new builds of the application become available, you can play back the script to test the builds against the
established baseline in a fraction of the time that it would take to perform the testing manually.
You should plan to use Robot at the earliest stages of the application development and testing process. If
any Windows GUI objects such as menus and dialog boxes exist within the initial builds of your application,
you can use Robot to record the corresponding verification points. Set up test environment
Set recording options
Perform user actions
Start recording End recording
GUI Script Recording Workflow
Create verification points
Before You Begin Recording

Consider the following guidelines before you begin recording:

_ Establish predictable start and end states for your scripts.
_ Set up your test environment.
_ Create modular scripts.
_ Create Shared Projects with UNC.

Rather than defining a long sequence of actions in one GUI script, you should define scripts that are short
and modular. Keep your scripts focused on a specific area of testing — for example, on one dialog box or
on a related set of recurring actions. When you need more comprehensive testing, modular scripts can easily

44
be called from or copied into other scripts. They can also be grouped into shell scripts, which are top-level,
ordered groups of scripts.

The benefits of modular scripts are:

_ They can be called, copied, or combined into shell scripts.
_ They can be easily modified or rerecorded if the developers make intentional changes to the application-
under-test.
_ They are easier to debug.

Steps:
1.) File>New>Script.
2.) Name : Login1
Description=Log in to the Classics Online Application
3.) Press Ok
4.) In Rational robot main Window Place cursor at the beginning of blank line after start application
command
5.) Record>Insert at cursor
6.) On GUI Record toolbar click Display GUI Insert Toolbar
7.) click write to Log
Message=Verify the initial state of classics online application
Description=The next VP will verify initial state of classics Online.
Result option=None
Ok
8.) On GUI Record Toolbar click display GUI Insert Toolbar Click windows Existence
Name=Login1
Ok
Click Select
Drag Object Finder pointer to Classics Login Dialog Box and release the mouse Ok
Ok
9.) In classics Login dialog box,click ok
10.) On GUI Record toolbar , click Stop Recording button.

45
11.) Exit Classics Online.
12.) Playback the script file>Playback(Select Login1>ok,Accept default log info.)
13.) Look at the results.

1.we can do testing with our manual script file script1. click on insert-verification
point- 13 options are available like Alphanumeric, Object, Menu, Object
properties etc.

14. if we want to test object properties, select it

46
Click ok.

Object finder tool will available. Click on tool (hand icon) and drag on the object or

47
button where you want to test the properties of classic online script file.

Suppose I leave it on order it button. Click ok. Then its properties will detect.

All properties are identified and display.

48
We can do modifications in the properties. After that click ok. It will come to
normal windoe.

Now we have to run both of the script file. Click on playback script icon, that is

49
displayed on standard toolbar.

A playback window will open. Where we have to choose our script1 file.

Click ok

50
Click ok
12 result will display

Result as test pass or fail will be displayed.

51
EXPERIMENT No. 11

52
AIM: Write a script to record verification point for Clip Board and alphanumeric values
using Rational Robot
THEORY:
A verification point is a point in a script that you create to confirm the state of an object across builds of the
application-under-test. During recording, a verification point captures object information and stores it in a
baseline data file. The information in this file becomes the baseline of the expected state of the object during
subsequent builds.

Creating Verification Points in GUI Scripts

When you play back the script against a new build, Rational Robot retrieves the information in the baseline
file for each verification point and compares it to the state of the object in the new build. If the captured
object does not match the baseline, Robot creates an actual data file. The information in this file shows the
actual state of the object in the build. After playback, the results of each verification point appear in the
TestManager log. If a verification point fails (the baseline and actual data do not match), you can select the
verification point in the log and click View > Verification Point to open the appropriate Comparator. The
Comparator displays the baseline and actual files so that you can compare them.

Alphanumeric
Captures and tests alphanumeric data in Windows objects that contain text, such as edit boxes, check boxes,
group boxes, labels, push buttons, radio buttons, toolbars, and windows (captions). You can use the
verification point to verify that text has not changed, to catch spelling errors, and to ensure that numeric
values are accurate.

Clipboard
Captures and compares alphanumeric data that has been copied to the Clipboard. To use this verification
point, the application must supply a Copy or Cut capability so that you can place the data on the Clipboard.
This verification point is useful for capturing data from spreadsheet and word processing applications as
well as terminal emulators.

53
Testing the CLIPBOARD option

Testing the ALPHANUMERIC option

54
Conclusion: We checked the script and got the results in terms of pass/fail.

55
 EXPERIMENT No. 12

AIM: Write a script to record verification point for CASE INSENSITIVE values using Rational Robot

THEORY:
When you create certain verification points, you can select a verification method. The verification method
specifies how Robot compares the baseline data captured while recording with the data captured during
playback.

Case-Insensitive – Verifies that the text captured during recording matches the captured text during
playback in content but not necessarily in case. For example, if you capture Inches during recording, the
test passes during playback if the captured text is inches. If the text contains any other characters, the test
fails.

Testing the CASE INSENSITIVE option

56
Conclusion: We checked the script and got the results in terms of pass/fail.

57
 EXPERIMENT No. 13

AIM: Write a script to record verification point for RANGE values using Rational Robot

THEORY:
When you create certain verification points, you can select a verification method. The verification method
specifies how Robot compares the baseline data captured while recording with the data captured during
playback.

Numeric Range – Verifies that the values of the data captured during recording fall within a specified range
during playback. You specify the From and To values for the numeric range. During playback, the
verification point verifies that the numbers are within that range. For example, you can capture a list
containing a range of salaries and then set the high and low values of the range. The test passes during
playback only if all of the salaries are within the set range.

Testing the RANGE option

58
59
Conclusion: We checked the script and got the results in terms of pass/fail.

60
 EXPERIMENT No. 14

AIM: Write a script to record verification point for OBJECT PROPERTIES values using Rational Robot
THEORY:
A verification point is a point in a script that you create to confirm the state of an object across builds of the
application-under-test. During recording, a verification point captures object information and stores it in a
baseline data file. The information in this file becomes the baseline of the expected state of the object during
subsequent builds.

Creating Verification Points in GUI Scripts

When you play back the script against a new build, Rational Robot retrieves the information in the baseline
file for each verification point and compares it to the state of the object in the new build. If the captured
object does not match the baseline, Robot creates an actual data file. The information in this file shows the
actual state of the object in the build. After playback, the results of each verification point appear in the
TestManager log. If a verification point fails (the baseline and actual data do not match), you can select the
verification point in the log and click View > Verification Point to open the appropriate Comparator. The
Comparator displays the baseline and actual files so that you can compare them.

Object Properties
Captures and compares the properties of standard Windows objects. Also provides specialized support for
environment-specific objects such as Visual Basic Data controls, ActiveX controls, HTML and Java objects,
PowerBuilder DataWindows, and Oracle Forms base-table blocks.

Testing the OBJECT PROPERTIES option

61
Conclusion: We checked the script and got the results in terms of pass/fail.

62