5) Create a test plan document for any application (e.g.

Library Management System)

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

PROGRAM:

What are the requirements of library management system?

1. User able to register and login.

2. User can search the added books, and check in or out.
3. User can pay the fine or extend the duration of borrowed period.
4. User can change the password and other profile details.
5. User can add the books.
6. User can place the holds and modify existing holds.
7. User can manage the inventory of the books.

Testing Login of Library System

1. Check if the username field accepts valid username and password field accepts valid
password.
2. Check if the wrong username and valid password allows access to any specific
account.
3. Check if the valid username and wrong password allows access to any specific
account.

Testing User Management:

1. Check if the member can be searched using the firstname or lastname.

2. Check if the member transactions are updated.
3. Check if the user data can be modified if you are admin.

Testing Search system of Library

1. Check if the search function allows searching of books as per title, ISBN, author,
genre or all of the criteria.
2. Check if the search filter exists as per – books, cds, magazines, videos and software or
all of them.
3. Check if the search filter has categories feature.

Testing Library Resources Inventory:

1. Check if the resources can be searched using the search feature.

2. Check if you can add the resource using type, and other categorized information.
3. Check if the resources can be searched using barcode or the category title.
4. Check if you can modify or edit the resource.
TEST RESULT: UNIT TESTING
LOGIN FORM:

SL.No Test Case Excepted Result Test Result

1 Enter valid name and password Software should display Successful

& click on login button main window

2 Enter invalid Software should not successful

display main window

BOOK ENTRY FORM:

SL.No Test Case Excepted Result Test Result

1 On the click of At first user have to fill all fields with

ADD button proper data , if any Error like entering successful
text data instead of number or entering
number instead of text..is found then it
gives proper message otherwise Adds
Record To the Database
On the Click of This deletes the details of book by Successful
2.
DELETE Button using Accession no.
On the Click of Modified records are Updated in
3. Successful
UPDATE Button database by clicking UPDATE button.
On the Click of Displays the Details of book for Successful
4.
SEARCH Button entered Accession no. Otherwise gives
proper Error message.
On the Click of Clears all fields Successful
5.
CLEAR Button
6. On the Click of Exit the current book details form successful
EXIT button

7. On the Click of Display the next form successful

NEXT button
USER ACCOUNT FORM:

SL.No Test Case Excepted Result Test

Result

1 On the click of ADD At first user have to fill all fields with proper
button data , if any Error like entering text data instead successful
of number or entering number instead of
text..is found then it gives proper message
otherwise Adds Record To the Database
On the Click of This deletes the details of student by using Successful
2.
DELETE Button Register no.
On the Click of Modified records are Updated in database by
3. Successful
UPDATE Button clicking UPDATE button.
On the Click of Displays the Details of book for entered Successful
4.
SEARCH Button Register no. Otherwise gives proper Error
message.
On the Click of Clears all fields Successful
5.
CLEAR Button
6. On the Click of Exit the current book details form successful
EXIT button

7. On the Click of Display the next form successful

NEXT button

BOOK ISSUE FORM:

SL.No Test Case Excepted Result Test

Result

1 On the click of ADD At first user have to fill all fields with proper
button data ,if the accession number book is already successful
issued then it will giving proper msg.
On the Click of This deletes the details of book by using Successful
2.
DELETE Button Register no.
On the Click of Modified records are Updated in database by
3. Successful
UPDATE Button clicking UPDATE button.
On the Click of Displays the Details of issued Successful
4.
SEARCH Button book..Otherwise gives proper Error message.
On the Click of Clears all fields Successful
5.
CLEAR Button
6. On the Click of EXIT Exit the current book details form successful
button

7. On the Click of Display the next form successful

NEXT button
BOOK RETURN FORM:

SL.No Test Case Excepted Result Test

Result

1 On the click of ADD At first user have to fill all fields with proper
button data , if any Error like entering text data instead successful
of number or entering number instead of
text..is found then it gives proper message
otherwise Adds Record To the Database
On the Click of Which deletes the details of book by using Successful
2.
DELETE Button Register no.
On the Click of Modified records are Updated in database by
3. Successful
UPDATE Button clicking UPDATE button.
On the Click of Displays the Details of returned book ... Successful
4.
SEARCH Button Otherwise gives proper Error message.
On the Click of Clears all fields Successful
5.
CLEAR Button
6. On the Click of Exit the current book details form successful
EXIT button

7. On the Click of Display the next form successful

NEXT button
6)Aim:Study of Win Runner Testing Tool and its implementation
Program:
WinRunner is a program that is responsible for the automated testing of software.
WinRunner is a Mercury Interactive‘s enterprise functional testing
tool for Microsoft windows applications.

Importance of Automated Testing:

1. Reduced testing time

2. Consistent test procedures –
ensure process repeatability and resource
independence. Eliminates errors of manual testing
3. Reduces QA cost – Upfront cost of automated testing is easily
recovered over the lifetime of the product
4. Improved testing productivity – test suites can be run earlier and more often
5. Proof of adequate testing
6. For doing Tedious work – test team members can focus on quality areas.

WinRunner Uses:

1. With WinRunner sophisticated automated tests can be created and run on an

application.
2. A series of wizards will be provided to the user, and these wizards can create
tests in an automated manner.
3. Another impressive aspect of WinRunner is the ability to record various interactions,
and transform them into scripts. WinRunner is designed for testing graphical user
interfaces.
4. When the user make an interaction with the GUI, this interaction can be
recorded. Recording the interactions allows to determine various bugs that need
to be fixed.

5. When the test is completed, WinRunner will provide with detailed information
regarding the results. It will show the errors that were found, and it will also give
important information about them. The good news about these tests is that they
can be reused many times.
6. WinRunner will test the computer program in a way that is very similar to normal
user interactions. This is important, because it ensures a high level of accuracy
and realism. Even if an engineer is not physically present, the Recover manager
will troubleshoot any problems that may occur, and this will allow the tests to be
completed without errors.
7. The Recover Manager is a powerful tool that can assist users with various
scenarios. This is important, especially when important data needs to be
recovered.

The goal of WinRunner is to make sure business processes are properly carried out.
WinRunner uses TSL, or Test Script Language.

WinRunner Testing Modes

Context Sensitive

Context Sensitive mode records your actions on the application being tested in terms
of the GUI objects you select (such as windows, lists, and buttons), while ignoring the
physical location of the object on the screen. Every time you perform an operation on the
application being tested, a TSL statement describing the object selected and the action
performed is generated in the test script. 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.

To run a test, you simply play back the test script. WinRunner emulates a user by
moving the mouse pointer over your application, selecting objects, and entering keyboard
input. WinRunner reads the object descriptions in the GUI map and then searches in the
application being tested for objects matching these descriptions. It can locate objects in a
window even if their placement has changed.

Analog

Analog mode records mouse clicks, keyboard input, and the exact x- and y-
coordinates traveled by the mouse. When the test is run, WinRunner retraces the mouse
tracks. Use Analog mode when exact mouse coordinates are important to your test, such as
when testing a drawing application.

The WinRunner Testing Process

Testing with WinRunner involves six main stages:

1. Create the GUI Map:

The first stage is to create the GUI map so WinRunner can recognize the GUI objects in the
application being tested. Use the RapidTest Script wizard to review the user interface of
your application and systematically add descriptions of every GUI object to the GUI map.
Alternatively, you can add descriptions of individual objects to the GUI map by clicking
objects while recording a test.
2. Create Tests

Next is creation of test scripts by recording, programming, or a combination of both.

While recording tests, insert checkpoints where we want to check the response of the
application being tested. We can insert checkpoints that check GUI objects, bitmaps, and
databases. During this process, WinRunner captures data and saves it as expected results—
the expected response of the application being tested.

3. Debug Tests
Run tests in Debug mode to make sure they run smoothly. One can set breakpoints,
monitor variables, and control how tests are run to identify and isolate defects. Test results
are saved in the debug folder, which can be discarded once debugging is finished. When
WinRunner runs a test, it checks each script line for basic syntax errors, like incorrect syntax
or missing elements in If, While, Switch, and For statements. We can use the Syntax
Check options (Tools >Syntax Check) to check for these types of syntax errors before
running your test.

4. Run Tests

Tests can be run in Verify mode to test the application. Each time WinRunner
encounters a checkpoint in the test script, it compares the current data of the application
being tested to the expected data captured earlier. If any mismatches are found, WinRunner
captures them as actual results.

5. View Results

Following each test run, WinRunner displays the results in a report. The report
details all the major events that occurred during the run, such as checkpoints, error
messages, system messages, or user messages. If mismatches are detected at checkpoints
during the test run, we can view the expected results nd the actual results from the Test
Results window. In cases of bitmap mismatches, one can also view a bitmap that displays
only the difference between the expected and actual results.

We can view results in the standard WinRunner report view or in the Unified report
view. The WinRunner report view displays the test results in a Windows-style viewer. The
Unified report view displays the results in an HTML-style viewer (identical to the style
used for QuickTest Professional test results).

6. Report Defects

If a test run fails due to a defect in the application being tested, one can report
information about the defect directly from the Test Results window.
This information is sent via e-mail to the quality assurance manager, who tracks the
defect until it is fixed.
Using Winrunner Window

Before you begin creating tests, you should familiarize yourself with the
WinRunner main window.

To start WinRunner:

Choose Programs > WinRunner > WinRunner on the Start menu.

The first time you start WinRunner, the Welcome to WinRunner window and the
―What‘s New in WinRunner‖ help open. From the Welcome window you can create a
newtest, open an existing test, or view an overview of WinRunner in your default
browser.
CASE TOOLS & SOFTWARE TESTING LAB MANUAL

If you do not want this window to appear the next time you start WinRunner,
clear the Show on Startup check box. To show the Welcome to WinRunner window
upon startup from within WinRunner, choose Settings > General Options, click the
Environment tab, and select the Show Welcome screen check box.

The Main WinRunner Window

The main WinRunner window contains the following key elements:
WinRunner title bar

Menu bar, with drop-down menus of WinRunner commands

Standard toolbar, with buttons of commands commonly used when running a
test User toolbar, with commands commonly used while creating a test
Status bar, with information on the current command, the line number of the
insertion point and the name of the current results folder

The Standard toolbar provides easy access to frequently performed tasks, such as
opening, executing, and saving tests, and viewing test results.
Standard Toolbar

The User toolbar displays the tools you frequently use to create test scripts. By
default, the User toolbar is hidden. To display the User toolbar, choose Window > User
Toolbar. When you create tests, you can minimize the WinRunner window and work
exclusively from the toolbar. The User toolbar is customizable. You choose to add or
remove buttons using the Settings > Customize User Toolbar menu option. When you
re-open WinRunner, the User toolbar appears as it was when you last closed it. The
commands on the Standard toolbar and the User toolbar are described in detail in
subsequent lessons.
Note that you can also execute many commands using softkeys. Softkeys are
keyboard shortcuts for carrying out menu commands. You can configure the softkey
combinations for your keyboard using the Softkey Configuration utility in your
WinRunner program group. For more information, see the ―WinRunner at a Glance‖
chapter in your WinRunner User’s Guide.

Now that you are familiar with the main WinRunner window, take a few minutes
to explore these window components before proceeding to the next lesson.

The Test Window

You create and run WinRunner tests in the test window. It contains the following key
elements:

Test window title bar, with the name of the open test
Test script, with statements generated by recording and/or programming in TSL,
Mercury Interactive‘s Test Script Language
Execution arrow, which indicates the line of the test script being executed during
a test run, or the line that will next run if you select the Run from arrow option
Insertion point, which indicates where you can insert or edit text
 7)Apply Win Runner testing tool implementation in any real time applications.

Aim: Apply Win Runner testing tool implementation in any real time applications.

After installing the WinRunner on your computer, invoke the WinRunner application:
 Start -> Programs ->WinRunner ->WinRunner
The opening screen of the WinRunner application is displayed, prompting you to select
one of the three options:
 New Test: To create a new test script
 Open Test: To open an existing test script
 Quick Preview: To view the quick preview of WinRunner

Recording Test Cases

To test any application, first you can run the application and understand its operation.
Then, you can invoke WinRunner, again run the application and record the GUI
operations. During the recording mode, WinRunner will capture all your actions, which
button you pressed, where you clicked the mouse etc. You need to work with the
application as usual and perform all the actions to be tested. Once the recording is
completed, WinRunner generates a script in TSL (Test Script Language). You can run
this test script generated by WinRunner to view the results. The test results will show
whether the test has passed or failed.

There are two modes of recording:

1. Context Sensitive mode: This mode of recording is used when the location of the
GUI controls (i.e. X and Y coordinates) or the mouse positions are not necessary.
2. Analog mode: This mode of recording is used when the mouse positions, the
location of the controls in the application, also play an important role in testing
the application. This mode of recording has to be used to validate bitmaps,
testing the signature etc.
The procedure for recording a test case is as follows:
Step 1: Open a new document: File -> New (or) Select "New Test"
from the WinRunner's Welcome screen.
Step 2: Open (run) the application to be tested.

3.On selecting the GUI Map Editor.The screen as shown in figure is displayed

Step 4: Save the GUI Map file.

File -> Save As
A File dialog appears and you need to enter the filename.
Step 5: Close the GUI Map Editor window.
The procedure for loading the GUI map file is as follows:

Step 1: Open the GUI Map Editor.

Tools -> GUI Map Editor
Step 2: Close all the opened GUI Map files
File -> Close all.

The procedure for running a test case is as follows:

Step 1: Open the test script to be executed.

Step 2: Run the test

Run -> Run from top (or) press F5 to run the test.
WinRunner executes the generated script and displays the results in the Test Results
window.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
To test the complete functionality of the application, we need to generate test cases in
such a way that all the buttons are made use of. We need to generate some test cases
which will give correct output and also some test cases which will give error
messages. Table gives such test cases and the expected output for each test case.
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.
 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.
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.
 You can use the same procedure explained above for recording the test case. The
following test script will be generated:
#Calculator winactivate("Calculator"); set_window("Calculator",1);
obj_mouse_click("Button_38",20,12,LEFT);
objmousedrag("Button_35",10,15,11,14,LEFT);
obj_mouse_click("Button_60",20,11,LEFT);
When you run the test script again, you can see the test results, as in Figure.

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"
 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.