EXERCISE NO: 1

AIM: Write program in ‘C’ Language to demonstrate the working of the following constructs:
i)do…while
ii)while…do
iii)if…else
iv)switch
v)for
i) PROGRAM→do..while
#include<stdio.h>
int main()

int i=2,n;

printf(“Enter Number: ”);

scanf(“%d”,&n);

do

(i%2==0 )? printf(“%d is Even\n”,i) : printf(“%d is Odd\n”,i);

i++;

} while(i<=n);

INPUT OUTPUT

6 2 is Even

3 is Odd

4 is Even

5 is Odd

6 is Even

1
TEST CASES:

Test Input Expected Actual

TC_ID Description Status
Output Output
2 is Even 2 is Even
3 is Odd 3 is Odd
TC-- Postive Enter 4 is Even 4 is Even Pass
001 Values Number:6
5 is Odd 5 is Odd
6 is Even 6 is Even

- 2 is Even 2 is Even
-3 is Odd ---------
TC-- Negative Enter - 4 is ---------- Fail
002 Values Number:- Even
6
-5 is Odd ----------
-6 is ---------
Even

2
ii) PROGRAM:→while…
#include<stdio.h>
int main()

int i=2,n;

printf(“Enter Number: ”);

scanf(“%d”,&n);

while(i<=n)

(i%2==0 )? printf(“%d is Even\n”,i) : printf(“%d is Odd\n”,i);

i++;

INPUT OUTPUT

6 2 is Even

3 is Odd

4 is Even

5 is Odd

6 is Even

3
TEST CASES:

Test Input Expected Actual

TC_ID Description Status
Output Output
2 is Even 2 is Even
3 is Odd 3 is Odd
TC-- Postive Enter 4 is Even 4 is Even Pass
001 Values Number:6
5 is Odd 5 is Odd
6 is Even 6 is Even

- 2 is Even --------
-3 is Odd ---------
TC-- Negative Enter - 4 is ---------- Fail
002 Values Number:- Even
6
-5 is Odd ----------
-6 is ---------
Even

4
iii) PROGRAM:→if….else
#include<stdio.h>
int main()

int i=2,n;

printf(“Enter Number: ”);

scanf(“%d”,&n);

while(i<=n)

if(i%2==0)

Printf(“%d is Even”,i);

else

printf(“%d is Odd”,i);

i++;

INPUT OUTPUT

6 2 is Even

3 is Odd

4 is Even

5 is Odd

6 is Even

5
TEST CASES:

Test Input Expected Actual

TC_ID Description Status
Output Output
2 is Even 2 is Even
3 is Odd 3 is Odd
TC-- Postive Enter 4 is Even 4 is Even Pass
001 Values Number:6
5 is Odd 5 is Odd
6 is Even 6 is Even

- 2 is Even --------
-3 is Odd ---------
TC-- Negative Enter - 4 is ---------- Fail
002 Values Number:- Even
6
-5 is Odd ----------
-6 is ---------
Even

6
iv)PROGRAM:→switch
#include<stdio.h>
int main()

int i=2,n,c;

printf(“Enter Number: ”);

scanf(“%d”,&n);

do
{
c=(i%2==0 )? 0 : 1;
switch(c)
{
case 0: printf(“%d is Even\n”,i);
break;
case 1:printf(“%d is Odd\n”,i);
break;
}
i++;
}while(i<=n);
}
INPUT OUTPUT

6 2 is Even

3 is Odd

4 is Even

5 is Odd

6 is Even

7
TEST CASES:

Test Input Expected Actual

TC_ID Description Status
Output Output
2 is Even 2 is Even
3 is Odd 3 is Odd
TC— Postive Enter 4 is Even 4 is Even Pass
001 Values Number:6
5 is Odd 5 is Odd
6 is Even 6 is Even

- 2 is Even 2 is Even
-3 is Odd ---------
TC-- Negative Enter - 4 is ---------- Fail
002 Values Number:- Even
6
-5 is Odd ----------
-6 is ---------
Even

8
v) PROGRAM:→for
#include<stdio.h>
int main()

int i,n;

printf(“Enter Number: ”);

scanf(“%d”,&n);

for(i=2;i<=n;i++)

(i%2==0) ? printf(“%d is Even\n”,i) : printf(“%d is Odd\n”,i);

INPUT OUTPUT

6 2 is Even

3 is Odd

4 is Even

5 is Odd

6 is Even

9
TEST CASES:

Test Input Expected Actual

TC_ID Description Status
Output Output
2 is Even 2 is Even
3 is Odd 3 is Odd
TC— Postive Enter 4 is Even 4 is Even Pass
001 Values Number:6
5 is Odd 5 is Odd
6 is Even 6 is Even

- 2 is Even --------
-3 is Odd ---------
TC-- Negative Enter - 4 is ---------- Fail
002 Values Number:- Even
6
-5 is Odd ----------
-6 is ---------
Even

10
 EXERCISE-02
AIM :A program written in c language for matrix multiplication fails “Introspect the causes for its
failure and write down the possible reasons for its failure”.
PROGRAM:
#include<stdio.h>
void main()
{
int r1,r2,c1,c2,i,j,k,a[5][5],b[5][5],c[5][5];
printf("enter no of rows and columns for matrix 1");
scanf("%d%d",&r1,&c1);
printf("enter no of rows and columns for matrix 2");
scanf("%d%d",&r2,&c2);
printf("enter elements for matrix1:");
for(i=0;i<r1;i++){
for(j=0;j<c1;j++){
scanf("%d",&a[i][j]);
}
}
printf("enter elements for matrix2:");
for(i=0;i<r2;i++){
for(j=0;j<c2;j++){
scanf("%d",&b[i][j]);
}
}
for(i=0;i<r2;i++)
{
for(j=0;j<c2;j++)
{
c[i][j]=0;
for(k=0;k<c1;k++){
c[i][j]=c[i][j]+a[i][k]*b[k][j];

11
 }
}
}
for(i=0;i<r1;i++){
for(j=0;j<c2;j++){
printf("%d",c[i][j]);
}
printf("\n");
}
return (0);
}
Input Output
Enter rows and cols of 1st matrix:2 2 9 8
Enter rows and cols of 2nd matrix:2 2 12 12
Enter elements for matrix 1
12
23
Enter elements for matrix 2
23
45

12
 TEST CASES:
TC_I Input Test Expect Actual status
D ed output
Descripti output
on

Enter rows and cols of 1st

matrix:3 2
Enter rows and cols of 2nd
Matrix
matrix:
Multipl
rows of
33 ication
1st matrix
is not 111621
Enter elements for matrix 1 not equal
possibl
TC- to cols of 213141
12 e
001 2nd Fail
23 matrix

34
Enter elements for matrix 2
123
234
345
Enter rows and cols of 1st
matrix:2 2
Enter rows and cols of 2nd
Matrix
matrix:2 2
Multipl
out of -183024498
Enter elements for matrix 1 ication
range
TC_0 is not -
1111111 2111111 values
02 possibl 294256796 Fail
testing
2222222 3111111 e

Enter elements for matrix 2

3999990 4666666
1222222 2333333

13
 EXERCISE NO:03
AIM: Take any system (e.g. ATM system) and study its system specifications and report the
various bugs.
SYSTEM SPECIFICATIONS:
1)Card validation.
2)Print Receipt.
3)Dispense cash from account.
4)Account type Validation.
5)Money Denomination.
6)Pin validation.
7)Authentication of user.
8)Balance Enquiry.
BUGS IDENTIFIED:
BUG_ID BUG_NAME
ATM_01 Invalid card
ATM_02 Invalid pin
ATM_03 Invalid account type
ATM_04 Insufficient Balance
ATM_05 Withdraw limit per transaction
ATM_06 Day Limit
ATM_07 Receipt not printed
ATM_08 Invalid money denomination
ATM_09 Pin change Mismatch

14
BUG REPORT:
BUG_ID DESCRIPTION STEPS EXPECTED ACTUAL STATUS
TO RESULT RESULT
PRODUCE
Due to invalid Invalid Card
card warning results in
Invalid Card Keep the PASS
message is warning
ATM_01 card in the
displayed. message.
ATM.
Repeat the
process with
valid card.
As invalid pin Invalid pin
is entered results in
1.Keep the
warning warning
card in the
ATM_02 Invalid pin message is message. PASS
ATM.
displayed.
2.Enter the Repeat the
ATM card process again
pin. within limited
no.of times.
1.keep the Due to Invalid Invalid
card in type selection Acccount
theATM. red flag is type results
ATM_03 displayed on in display of PASS
2.Enter the
the system. warning
Invalid account ATM card
message.
type pin.
3.Select the
type of the
account.
1.First Transaction Warning
check the falied message Message is
Insufficient PASS
amount is displayed. Displayed.
Balance
ATM_04 available in
card
2.Enter
amount to
withdraw.

15
 1.Enter Limited Insufficient
card,pin exceeded balance
Withdraw limit PASS
details. results in results in
per transaction
ATM_05 trasaction warning
2.Enter
falied. message.
amount to
withdraw.

1.Enter the Limit Transaction

amount to exceeded falied
withdraw message is message is
ATM_06 Day limit displayed as displayed. PASS
2.Enter
day limit
amount for
transaction
transaction
crossed.
within day
limit.
1.Enter Due to Receipt not
card,pin technical issue printed
details. receipt hasnot
ATM_07 Receipt not generated. PASS
2.Enter
printed
amount to
withdraw.
3.request for
receipt.
1.Enter Invalid money Incorrect
card,pin denomination. money
details. denomination
Invalid money PASS
2.select
ATM_08 denomination
account
type.
3.select
transcation
Pin change 1.Insert card Invalid Invalid pin
mismatch into ATM. Pin(previous results in
PASS
pin). warning
ATM_09 2.Enter the
message .
pin. Repeat the
process with
authorized pin

16
 EXERCISE NO: 04
AIM: Write the test cases for any known application(e.g.Banking Application).

TEST CASES:
TC_ID Test Test Steps Data Expected Actual Statu
Scenari s
o
Valid 1:Enter User name (like Customer Customer
Login user name Likitha) and is allowed is allowed
TC_001 PASS
Detalis and password(.....). for futher for futher
password. process of process of
transactio transactio
n. n.
Invalid 1:Enter User name (like Customer Customer
Login user name likitha) and is not is not
TC_002 PASS
Detalis and password(.....). allowed allowed
password. for futher for futher
process of process of
transactio transactio
n. n.
Transact 1: User name (like Transactio Transactio
ion EnterUserna Likitha),passwo n n
TC_003 PASS
Limit me and rd(.....) successful successful
password. . .
Amount(6000)
2:Enter
amount to
be
transferred.
Transact 1.Enter User name (like Transactio Transactio
ion Username Likitha),passwo n exceeds n
TC_004
Limit and rd(.....) leads to unsuccess
Exceed password. display of ful. PASS
Amount(60000)
2:Enter warning
amount to message.
be
transferred.
1: Enter User name (like Updation Updation
Username Likitha),passwo successful successful
TC_005 Profile PASS
and rd(.....), . .
Update
password.
Change pin,...
2:Enter

17
 detalis to be
update.

1: Enter User name (like Updation Updation

User name Likitha),passwo can’t be Unsuccess
TC_006 Profile PASS
and rd(.....), possible ful.
Update
password. for IFSC
IFSC code
code
2:Detalis to (2134 to 1234)
which
be update.
results
unsuccess
ful.
1: Enter User name (like Transactio Transactio
User name Likitha),passwo n n
TC_007 Tranfer
and rd(.....), successful successful
amount
password. . . PASS
Account
2Enter number and
details like IFSC code
Account
Amount(like
number and
20000)
IFSC code
1: Enter User name (like Transactio Transactio
Username Likitha),passwo n is n
TC_008 Transfer
and rd(.....), unsuccess unsuccess
amount
password. ful due to ful. PASS
Account
exceed
2:Enter number and
amount
details like IFSC code
transfer.
Account
Amount(1,20,0
number and
00)
IFSC code
Transact 1: Enter User name (like Transactio Transactio
ions Username Likitha),passwo ns ns
TC_009
Limit and rd(.....) Successful Successful
password. . . PASS
Amount(10003,
2:Transactio
2300,5000,....)
n based on
amount
limit.
Transact 1: Enter User name (like Transactio Transactio
ions valid user Likitha),passwo n ns
TC_001
Limt name and rd(.....) unsuccess Unsuccess
0
password. ful due to ful. PASS
Amount(10003
18
 2:Transactio 0,2000,50000,1 high
ns based on 0000....) amount
amount transfer.
limit..
TC_011 Balance 1:Enter user Detalis like Balance Balnace PASS
Enquiry name,passw User name (like Displayed Displayed
ord. Likitha),passwo
rd(.....)
2.Detalis to
check
balance.

19
 EXERCISE:05
AIM: Create a test plan document for any application (e.g. Library Management System).

VERSION HISTORY:

Version #ImImplemented By Revision Approve d Approval Date Reason

Date By

1.0 P.J.VARMA 01-01- P.J.VARM 02-07-2020 Explaining the

2020 A information very
easy to
understand able.

1.INTRODUCTION:

Purpose: The Library Management System application for assisting a librarian in managing library
books. The system would provide basic set of features to add/update clients, add/update books,
search for books, dues if any and manage check-in / checkout processes. This test plan is a basic
guideline for future testing in the LMS.
Scope: The system would provide basic set of features to add/update members, add/update books,
dues if any and manage check in specifications for the systems based on the client’s statement of
need.
Environment :

Hardware : Three Dual Core or above machines needed. Software : Microsoft Windows XP
installed.

1.Testing Strategies:

Test Strategy:
1. Unit Testing:

Definition: Test smallest testable parts of an application, called units, are individually and
independently scrutinized for proper operation.

Participants/Tested By: Developers.

Methodology: Used for the Database test, records in each table, Basic function test, add a student,
add a book, Network test.

Items to be Tested: Login Module, Issue Module, Renewal Module, Return Module ,Fine
Calculation Module etc.
20
 2.Integration and System Testing :

Definition: Integration testing is the phase in software testing in which individual software modules
are combined and tested as a group. System integration testing (SIT) is a high-level software testing
process in which testers verify that all related systems maintain data integrity and can operate in
coordination with other systems in the same environment. Participants/ Tested by : System Tester.

Methodology : It is used for the Database test, Queries for insert, update, delete the Records.
Items to be Tested:
Integration Testing: Login and Issue Module, Issue and Renewal Module, Renewal and Return
Module, etc.,
Sytem Testing:Entire Sytem.
2. Performance and Stress Testing :
Definition : Determine how a system performs in terms of responsiveness and stability under a
particular workload. Stress testing tries to break the system under tests by overwhelming its
resources or by taking resources away from it.
Participants/ Tested by : Tester.
Methodology : It is used for the Database test, records in each table, Basic function test, Network
test.
Items to be Tested: Entire System Performance .
3. User Acceptance Testing :
Definition : Formal testing with respect to user needs, requirements, and business processes
conducted to determine whether or not a system satisfies specifications. Participants/ Tested by :
Users / End Users.
Methodology : It is used for Whole System Test.
Items to be Tested:Login, Return, Issue, Renewal etc.

1. TEST RISKS :
Risk Mitigation
Design and implementation The design of project must be easy to understand.

21
 Maintenance problem
Inexperience instructor
High work load
Training support
Software corruption
Maintenance should be proper (day to day
evolution).
Instructor must have full knowledge on particular
project.
The work should complete in the given time.
Employees must be supported by the trainers
(clarifying doubts) .
The product must have security to protect from
corruption.

Hardware failure The requirements that we considered should be

good that never fail to complete the product.
Operating environment Software should be user friendly.
Completion time The product must be completed on time.

2. ITEMS TO BE TESTED:
Item to Test Test Description Test Date Responsibility

User account Checks the user has account for 11-01-2020 Tester
form book issue or not if the user has ,Designer
account then issued the book
otherwise create a
new account.
Book issue form If the user has the valid account 18-01-2020 Tester
without fine the book issue will ,Designer
be done and also book limited
hasn’t
exceeded.
Book return User has to return the book in 24-01-2020 Tester
form time. ,Designer
Renewal form A book must be renewed if it is 27-01-2020 Tester
within renewal limit and with no ,Designer
due.
Fine form Fine will be incurred rupees one 30-01-2020 Tester,
per day. Designer
After one month fine will be
rupees 50 are more.

1. Define Test Criteria: Test Criteria is a standard or rule on which a test procedure or test
judgment can be based.

22
 Item: User account.
Pass Criteria: Account validity done.
Fail Criteria: Account login failed.

Item: Book issue.

Pass Criteria: Book issued successfully.
Fail Criteria: If user has fine book not issued.

Item: Book return.

Pass Criteria: Book returned successfully.
Fail Criteria: If user lost the book then book cannot be returned.

Item: Renewal.
Pass Criteria: Renew successful.
Fail Criteria: Renewal limit exceeded.

2. Resource Planning: Resource plan is a detailed summary of all types of resources required to
complete project task. Resource could be human, equipment and materials needed to complete a
project .The resource planning is important factor of the test planning because helps
in determining the number of resources (employee, equipment…) to be used for the project.
Therefore, the Test Manager can make the correct schedule & estimation for the project.

This section represents the recommended resources for your project .

Human Resource:

No. Member Tasks

1. Test Manager Manage the whole project.

Define project directions. Acquire appropriate resources.

23
 2. Tester Identifying and describing appropriate test
techniques/tools/automation architecture.

Verify and assess the Test Approach

Execute the tests, Log results, Report the defects.

Tester could be in-sourced or out-sourced members, base

on the project budget.

For the task which required low skill, I recommend you

choose outsourced members to save project cost.
3. Developer in Implement the test cases, test program, test suite etc.
Test
4. Test Builds up and ensures Test Environment and assets are
Administrator managed and maintained.

Support Tester to use the test environment for test

execution.
5. SQA members Take in charge of quality assurance.

Check to confirm whether the testing process is meeting

specified requirements.

System /Environment Resource:

3. Setting up the environment:

To finish this task, you need a strong cooperation between Test Team and Development Team.

You should ask the developer some questions to understand the web application under test clearly.
Here’re some recommended questions. Of course, you can ask the other questions if you need.

• What is the maximum user connection which this website can handle at the same time?
• What are hardware/software requirements to install this website?
• Does the user's computer need any particular setting to browse the website?

4. TEST SCHEDULE:
S.No Module/Item Estimated Estimated Actual Actual End
Start Time End Time Start Time Time
LM_001 Login Details 05|01|2020 10|01|2020 06|01|2020 11|01|2020
LM_002 Book Issue 07|01|2020 17|01|2020 08|01|2020 18|01|2020

24
 LM_003 Book Return 09|01|2020 24|01|2020 09|01|2020 24|01|2020
LM_004 Renewal 11|01|2020 27|01|2020 12|01|2020 27|01|2020
LM_005 Fine 13|01|2020 31|01|2020 13|01|2020 31|01|2020
5. Test Deliverables:
a. Before Testing:
1) Test plans document.
2) Test cases document.
3) Test Design specifications.

b. During Testing:
1) Test tool.
2) Simulators.
3) Test Data.
4) Test Trace-ability Matrix.
5) Error logs and execution log.
c. After Testing:
1) Test results/reports.
2) Defect report.
3) Installation manual.
4) Release notes.

TEST PLAN APPROVAL

The undersigned acknowledge they have reviewed the Test Plan document and agree with the
approach it presents. Any changes to this Requirements Definition will be coordinated with and
approved by the undersigned or their designated representatives.

Print Name:Test Plan Document.

Title:Test Plan for Library Mangement System.
Signature: P.Jagannadha Varma Date:

25
 EXERCISE - 6
a) Aim: Win runner Testing Process and Win runner User Interface

TESTING PROCESS:

The WinRunner Testing Process consists of 6 main phases:

1 Running the RapidTest Script wizard on your application

You run the RapidTest Script wizard on your application to teach WinRunner the physical
description of every GUI object the application contains. The wizard automatically generates a
series of tests that you can immediately run on your application.

2 Creating additional tests scripts that test your application’s functionality

WinRunner writes scripts automatically when you record actions on your script,or you can
program directly in Mercury Interactive’s Test Script Language (TSL).

3 Debugging the tests

You debug the tests to check that they operate smoothly and without interruption.

4 Running the tests on a new version of the application

You run the tests on a new version of the application in order to verify the application’s
behaviour.

5 Examining the test results

You examine the test results to pinpoint defects in the application.

6 Reporting defects

If you have the Web Defect Manager or the Remote Defect Reporter, you can report any
defects to a database. The Web Defect Manager and the Remote Defect Reporter are included in
TestDirector, Mercury Interactive’s software test management tool.

26
WinRunner User Interface:
The first time you start WinRunner, the Welcome to WinRunner window opens. From the
welcome window you can create a new test, open an existing test, or run the RapidTest Script
wizard

Figure: Welcome Screen

Figure: WinRunner User Interface.

1 The WinRunner window displays all open tests.

2 Each test appears in its own test window. You use this window to record, program, and edit test
scripts.
3 Buttons on the Standard toolbar help you quickly open, run, and save tests.
4 The User toolbar provides easy access to test creation tools.
5 The status bar displays information about selected commands and the current test run.

27
b) Aim: How winrunner identifies GUI objects in an application

GUI applications are made up of GUI objects such as windows, buttons, lists, and menus. Before
you begin creating and running tests on an application, you should use the RapidTest Script wizard,
which learns the description of all the GUI objects your application contains. The wizard opens
windows, examines their GUI objects, and saves the object descriptions in a GUI map file. Later, when
you run tests, WinRunner uses this file to identify and locate objects.
When WinRunner learns the description of a GUI object, it looks at the object’s physical properties.
Each GUI object has many physical properties such as “class,” “label,” “width,” “height”, “handle,”
and “enabled” to name a few. WinRunner, however, only learns the properties that uniquely
distinguish an object from all other objects in the application.
Spying on GUI Objects

28
29
c) Aim: Describes the two modes for organizing GUI map files
Global GUI Map File mode: You can create a GUI map file for your entire application, or for each
window in your application. Different tests can reference a common GUI map file.
GUI Map File per Test mode: WinRunner automatically creates a GUI map file that corresponds to
each test you create. For more information, see “Working in the GUI Map File per Test Mode.”

d) Aim: How to record a test script and explains the basics of Test Script language(TSL)

Recording Modes

Basically, It allows you to record the manual operations in two types of modes namely Context
Sensitive mode and analog mode.

A. Context Sensitive Mode: It is the default mode in WinRunner. For this reason, win Runner records
mouse and keyboard operations with respect to objects and windows in your application build.
Then, it records the operations you perform on your application by identifying graphical user interface
GUI objects.

TEST->Record-Context sensitive mode

OR
.Click on the toolbar’s record button once to record in Context sensitive mode
OR
.F2 as the short key can be used to switch to the context-sensitive recording mode

B. Analog Mode:

In this mode, The WinRunner records mouse pointer movements on the desktop. Especially analog
Recording Option Records Keyboard input, mouse click, and the precise x- and y- coordinates
traveled by the mouse pointer across the screen. To select analog mode, follow any one of the
navigation paths

30
click start recording button twice

OR

-Test Menu->Record-Analog

OR

-F2 as short key to switch over from context Sensitive mode to analog mode

Stop Recording

If all required actions or operations are recorded, you can go to stop recording using any of the
following options.

-Test Menu->Stop Recording

Or

-Click on the Toolbar’s stop button

Or

-CTRL+F3 as the short key

31
 e) Aim: How To Synchronize A Test When The Applicaton Responds Slowly

In WinRunner, it takes by default one second to execute the next statement. But sometimes there
may be a case where the WinRunner has to wait for a few seconds to accept the data from the user
or wait till the current operation is completed, before executing the next statement.
The Synchronization is required in the following cases:
• When data has to be retrieved from the database.
• When a progress bar has to reach 100%.
• To wait till some message appears.

Though, by default, WinRunner takes one second to execute the next statement, it is
possible to change the default time to any desired value. Changing the value of the "Timeout for
Checkpoints and CS Statement" option in the Run tab of the General option's dialog can do this.

Settings -> General Options.

In such a case, it will affect the entire application and as a result the entire process of testing
becomes very slow. To avoid this, we find out the statement in the test script where the problem
may occur and create a synchronization point. The synchronization point tells WinRunner to wait
for specified interval for the specified response.
Creating the synchronization point is explained here with the example of a database application.
This application is used to create, open, modify, and delete the employee details. The first screen of
EmpDB is shown in Figure.

Creating the Test Case

Step 1: Open WinRunner application and create a new test case.
Step 2: Open the EmpDB application.
Step 3: Start recording the test case in Context Sensitive mode
Create -> Record - Context Sensitive or click the button from WinRunner toolbar.
Step 4: Create a new Employee record as shown in Figure.

32
Step 5: When you click "New" menu option, a dialog is displayed where the Emp No. is
automatically incremented and prompts you to enter the remaining details such as Emp Name, Emp
Salary, Designation as shown in Figure.

Step 6: After entering all the details click on "Add" button to insert the record into the database as
shown in Figure.

Step 7: When the insertion is completed, "Insert Done" message appears in the status bar as shown
in Figure.

33
Step 8: Select File -> Exit and close the EmpDB application.
Step9:Stop the recording process.
Stepl0: Save the test script with name "sync_before". The test script is displayed as shown in
Figure.

Step 11: Run the test case by selecting "Run from Top" option from the Run menu or Click button
on WinRunner toolbar. An error message, as shown in Figure appears because WinRunner fails to
select the menu option "File - Exit". The error occurred because WinRunner did not wait until the
insertion action is completed. Click "Pause" button.

If you click on the "Continue" button, it executes the remaining lines in the test script and displays
the error report as shown in Figure

34
To avoid such kind of problems, synchronizing the test cases is required. WinRunner application
captures the bitmap image of the "Insert Done" and when you run the test script, it waits for the
"Insert Done" message to appear in the status bar.
Synchronizing the Test Cases
We will now create a synchronization point into the test script..
StepI: Open the test script if it is closed.
File -> Open and select the "sync_be-fore" file.
Step 2: Place the cursor at the point where the test has to be synchronized.Insert a line after the
statement
Step 3: Insert a synchronization point as shown in Figure to make WinRunner wait
until the insertion is completed.

Step 4: By default one-second delay time will be inserted. Manually change the wait time to 10
seconds as it takes about 10 seconds for the insertion action to be completed. The time indicated by
you is added to the default time interval. So totally WinRunner waits for 11 seconds.
Step 5: Run the test script and observe that, WinRunner waits for the image to appear in the
application. If the image does not appear before the timeout time, it displays an error message;
otherwise it executes all the statements in the test script and displays the test result as shown in
Figure

35
 f) Aim:How to create a test that checks GUI objects and compare the behaviour of GUI
objects in different versions of the sample application in winrunner

You can use GUI checkpoints in your test scripts to help you examine GUI objects in your
application and detect defects. For example, you can check that when a specific dialog box opens,
the OK, Cancel, and Help buttons are enabled.
You point to GUI objects and choose the properties you want WinRunner to check. You can check
the default properties recommended by WinRunner, or you can specify which properties to check.
Information about the GUI objects and the selected properties is saved in a checklist. WinRunner
then captures the current property values for the GUI objects and saves this information as expected
results. A GUI checkpoint is automatically inserted into the test script. This checkpoint appears in
your test script as an obj_check_gui or a win_check_gui statement.

When you run the test, the GUI checkpoint compares the current state of the GUI objects in the
application being tested to the expected results. If the expected results and the current results do not
match, the GUI checkpoint fails. Your GUI checkpoint can be part of a loop. If a GUI checkpoint is
run in a loop, the results for each iteration of the checkpoint are displayed in the test results as
separate entries. The results of each iteration of the checkpoint can be viewed in the Test Results
window.
Note that any GUI object you check that is not already in the GUI map is added automatically to the
temporary GUI map file.
You can use a regular expression to create a GUI checkpoint on an edit object or a static text object
with a variable name.
WinRunner provides special built-in support for ActiveX control, Visual Basic, and PowerBuilder
application development environments. When you load the appropriate add-in support, WinRunner
recognizes these controls, and treats them as it treats standard GUI objects. You can create GUI
checkpoints for these objects as you would create them for standard GUI objects. WinRunner
provides additional special built-in support for checking ActiveX and Visual Basic sub-objects.
You can also create GUI checkpoints that check the contents and properties of tables.

Setting Options for Failed GUI Checkpoints

You can instruct WinRunner to send an e-mail to selected recipients each time a GUI checkpoint
fails and you can instruct WinRunner to capture a bitmap of your window or screen when any
checkpoint fails. You set these options in the General Options dialog box.
To instruct WinRunner to send an e-mail message when a GUI checkpoint fails:
1. Choose Tools > General Options. The General Options dialog box opens.
2. Click the Notifications category in the options pane. The notification options are displayed.
3. Select GUI checkpoint failure.
4. Click the Notifications > E-mail category in the options pane. The e-mail options are
displayed.
5. Select the Active E-mail service option and set the relevant server and sender information.

36
6. Click the Notifications > Recipient category in the options pane. The e-mail recipient options
are displayed.
7. Add, remove, or modify recipient details as necessary to set the recipients to whom you want to
send an e-mail message when a GUI checkpoint fails.
The e-mail contains summary details about the test and checkpoint and details about the expected
and actual values of the property check.
To instruct WinRunner to capture a bitmap when a checkpoint fails:
1. Choose Tools > General Options. The General Options dialog box opens.
2. Click the Run > Settings category in the options pane. The run settings options are displayed.
3. Select Capture bitmap on verification failure.
4. Select Window, Desktop, or Desktop area to indicate what you want to capture when
checkpoints fail.
5. If you select Desktop area, specify the coordinates of the area of the desktop that you want to
capture.
When you run your test, the captured bitmaps are saved in your test results folder.

37
g) Aim:How to create and run a test that checks bitmaps in your application in winrunner

When working in Context Sensitive mode, you can capture a bitmap of a window, object, or of a
specified area of a screen. WinRunner inserts a checkpoint in the test script in the form of either
a win_check_bitmap or obj_check_bitmap statement.

To check a bitmap, you start by choosing Insert > Bitmap Checkpoint. To capture a window or
another GUI object, you click it with the mouse. To capture an area bitmap, you mark the area to be
checked using a crosshairs mouse pointer.

Note that when you record a test in Analog mode, you should press the CHECK BITMAP OF
WINDOW softkey or the CHECK BITMAP OF SCREEN AREA softkey to create a bitmap
checkpoint. This prevents WinRunner from recording extraneous mouse movements. If you are
programming a test, you can also use the Analog function check_window to check a bitmap.

If the name of a window or object varies each time you run a test, you can define a regular
expression in the GUI Map Editor. This instructs WinRunner to ignore all or part of the name. For
more information on using regular expressions in the GUI Map Editor, see “Editing the GUI Map.”
Your can include your bitmap checkpoint in a loop. If you run your bitmap checkpoint in a loop, the
results for each iteration of the checkpoint are displayed in the test results as separate entries. The
results of the checkpoint can be viewed in the Test Results window.

38
h) Aim:Check points in bitmaps run the test on different versions of the sample application
and examine any differences pixel by pixel in winrunner

You can check an object, a window, or an area of a screen in your application as a bitmap. While
creating a test, you indicate what you want to check. WinRunner captures the specified bitmap,
stores it in the expected results folder (exp)of the test, and inserts a checkpoint in the test script.
When you run the test, WinRunner compares the bitmap currently displayed in the application
being tested with the expected bitmap stored earlier.

In the event of a mismatch, WinRunner captures the current actual bitmap and generates
a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), you can
identify the nature of the discrepancy.
Suppose, for example, your application includes a graph that displays database statistics. You could
capture a bitmap of the graph in order to compare it with a bitmap of the graph from a different
version of your application. If there is a difference between the graph captured for expected results
and the one captured during the test run, WinRunner generates a bitmap that shows the difference,
pixel by pixel.

39
i)Aim: How to create Data-Driven Tests which supports to run a single test on several sets of
data from a data table in winrunner
When you test your application, you may want to check how it performs the same operations with
multiple sets of data. You can create a data-driven test with a loop that runs ten times: each time the
loop runs, it is driven by a different set of data. In order for WinRunner to use data to drive the test,
you must link the data to the test script which it drives. This is called parameterizing your test. The
data is stored in a data table. You can perform these operations manually, or you can use the
DataDriver Wizard to parameterize your test and store the data in a data table. For additional
information, see, “Creating Data-Driven Tests.”

j) Aim: How to read and check text found in GUI objects and bitmaps in winrunner
You can capture a bitmap of any window or object in your application by pointing to it. The method
for capturing objects and for capturing windows is identical.

You start by choosing Insert > Bitmap Checkpoint > For Object/Window. As you pass the
mouse pointer over the windows of your application, objects and windows flash. To capture a
window bitmap, you click the window’s title bar. To capture an object within a window as a bitmap,
you click the object itself.
Note that during recording, when you capture an object in a window that is not the active window,
WinRunner automatically generates a set_window statement.

k) Aim:How to create a batch test that automatically runs the test in winrunner

You execute a batch test in the same way that you execute a regular test. Choose a mode (Verify,
Update, or Debug) from the list on the toolbar and choose Test > Run from Top.

When you run a batch test, WinRunner opens and executes each called test. All messages are
suppressed so that the tests are run without interruption.

If you run the batch test in Verify mode, the current test results are compared to the expected test
results saved earlier.

If you are running the batch test in order to Update expected results, new expected results are
created in the expected results folder for each test.

Note that if your tests contain TSL texit statements, WinRunner interprets these statements
differently for a batch test run than for a regular test run. During a regular test run, texit terminates
test execution. During a batch test run, texit halts execution of the current test only and control is
returned to the batch test.

40
l)Aim: How to update the GUI object description which in turn supports test scripts as the
apllication changes in winrunner
In Context Sensitive As you record, WinRunner writes a unique description of each selected object
to a GUI map. The GUI map consists of files maintained separately from your test scripts. If the
user interface of your application changes, you have to update only the GUI map, instead of
hundreds of tests. This allows you to easily reuse your Context Sensitive test scripts on future
versions of your application.

41
 EXERCISE – 7

AIM:TESTING AN CALCULATOR APPLICATION USING WINRUNNER TESTING

TOOL
Procedure:
After installing the WinRunner on your computer, invoke the WinRunner application:
We will now illustrate using WinRunner to test the "Standard Calculator" application available on
your Windows system. You can invoke the calculator application from the desktop Start ->
Programs -> Accessories -> Calculator. The GUI of the "Calculator" application is shown in Fig.

The symbols on the buttons of Calculator application represent the following functions:
+ : To perform addition
- : To perform subtraction
* : To perform multiplication
/ : To perform division
. : Decimal point
sqrt : To find square root of a number
% : To find percent
1/x : To find inverse of a number
MC : To clear the memory
MR : To recall from memory
MS : To save in the memory
M+ : To add to the memory
C :To clear the current calculation
CE :To clear the displayed number
+/- : To give sign to a number (positive or negative)
Backspace: To remove left most digit

42
To test the functionality of the application perform the following steps:
Test Case #1: To test the Inverse operation (inverse of 4 using 1/x button)
Step 1: Open WinRunner application.
Step 2: Open Calculator application.
Step 3: Create a new document as shown in Figure.
File -> New or Click Q (New) on tool bar or press Ctrl+N

Step 4: Start recording

Create -> Record-Context Sensitive (or) press F2 (or) Click # on the toolbar
Click the (Record-Context Sensitive) button on the toolbar of WinRunner as shown in Figure or
Select "Record - Context sensitive" option from the "Create" menu as shown in Figure.

43
Step 5: Select the Calculator application and start recording the actions. a Click "4" on the
Calculator
• Click the "1/x" button on the Calculator to find the inverse of 4.
• The result, 0.25 will be displayed on the Calculator.
Step 6: Stop the Recording process.
Create -> Stop Recording (or) Click (Stop) on toolbar
Click (Stop Recording) button on the toolbar of WinRunner as shown in Figure or Select the "Stop
Recording" option from the "Create" menu as shown in Figure.

Step 8: Save the file as "inverse" in the selected folder.

File -» Save
In the "Save" dialog box that appears, save the test script with name "inverse".
Step 9: Run the test script generated by WinRunner.
Run -> Run from Top or press F5 or Click (Run from Top) on the toolbar
Click the (Run from Top) button on the toolbar of WinRunner as shown in Figure or select the "Run
from Top" option from the "Run" menu as shown in Figure.

44
 Step 10: After executing the TSL statements, WinRunner generates test results as shown in Figure.
The Results column indicates whether the test has "Passed" or "Failed". The test results also give
useful information such as the name of the test case, the line numbers in the test script and the time
taken for executing the test case.

Calling the Test Cases using "call" Function

The "call" function can oeused to execute a series of test cases without any user interaction. The
syntax of call function is:
call<test-case name> for example, call testl();
• Create a new document
• Write the following test script
• Save the file as "callAll"
45
• Execute the test case
All the preceding test cases can be combined into one file as follows:
call inverseO;
call sqrootO;
call clearO;
call MultiplayO;
call divideO;
call add_subtract()
call PercentO;
call msjnrO;
call maddmrO;
call mclearO;
call backspaceO;

When you execute this test script, all the earlier test cases are executed in one shot. The test results
screen will be as shown in Figure. As you can see from the table, the "Details" column gives the
various test cases executed. The "Result" column shows whether the test has passed or failed. The
"Time" column gives the time taken to execute the test case.

When you have to retest the application using the same test cases, you can run the script in
unattended mode. You can save the script in a file and run the script at specified time.
This feature of WinRunner is extremely useful for regression testing. When you are developing the
software, you need to run the same set of test cases many times. So, you can run the application
once, generate the test script and then keep doing the regression testing. Obviously, the productivity
of the test engineers will be very high when this tool is used.

46