Jawaharlal Nehru Engineering College: Laboratory Manual
Jawaharlal Nehru Engineering College: Laboratory Manual
Jawaharlal Nehru Engineering College: Laboratory Manual
College
Laboratory Manual
For
It is my great pleasure to present this laboratory manual for Third year engineering
students for the subject of Software testing and Quality Assurance.
As a student, many of you may be wondering with some of the questions in your mind
regarding the subject and exactly what has been tried is to answer through this manual.
As you may be aware that MGM has already been awarded with ISO 9001:2000
certification and it is our endure to technically equip our students taking the
advantage of the procedural aspects of ISO
9001:2000 Certification.
Faculty members are also advised that covering these aspects in initial stage itself, will
greatly relieve them in future as much of the load will be taken care by the enthusiasm
energies of the students once they are conceptually clear.
Dr. S.D.Deshmukh
Principal
LABORATORY MANUAL CONTENTS
This manual is intended for the Third year engineering students in the subject of Software
Testing and Quality Assurance. This manual typically contains practical/lab sessions related to
Software Testing and Quality Assurance implemented in Winrunner covering various aspects
related the subject to enhanced understanding.
Students are advised to thoroughly go through this manual rather than only topics
mentioned in the syllabus as practical aspects are the key to understanding and
conceptual visualization of theoretical aspects covered in the books.
II. Preparing graduates for higher education and research in computer science and engineering
enabling them to develop systems for society development.
5. Modern tool usage: Create, select, and apply appropriate techniques, resources, and modern
engineering and IT tools including prediction and modeling to complex engineering activities
with an understanding of the limitations.
6. The engineer and society: Apply reasoning informed by the contextual knowledge to assess
societal, health, safety, legal and cultural issues and the consequent responsibilities relevant to
the professional engineering practice.
8. Ethics: Apply ethical principles and commit to professional ethics and responsibilities and
norms of the engineering practice.
9. Individual and team work: Function effectively as an individual, and as a member or leader
in diverse teams, and in multidisciplinary settings.
12. Life-long learning: Recognize the need for, and have the preparation and ability to engage in
independent and life-long learning in the broadest context of technological change.
SUBJECT INDEX
1. Introduction to winrunner.
3. Synchronizing test
8. Manual Testing
Experiment No.: 1
Theory:
To start WinRunner:
Choose Programs > WinRunner > WinRunner on the Start menu.
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 view an overview of WinRunner in your default browser.
The first time you select one of these options, the WinRunner main screen
opens with the “What’s New in WinRunner” section of the help file on top. If
you do not want the welcome window to appear the next time you start
WinRunner, clear the Show on startup check box.
Each test you create or run is displayed by WinRunner in a test window. You
can open many tests at one time.
The Standard toolbar provides easy access to frequently performed tasks,
such as opening, executing, and saving tests, and viewing test results
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.
Experiment No. :2
Theory:
WinRunner records your operations and generates statements in TSL, Mercury Interactive’s
Test Script Language. These statements appear as a script in a WinRunner test window.
Before you begin recording a test, you should plan the main stages of the test and select the
appropriate record mode. Two record modes are available: Context Sensitive and Analog.
Context Sensitive
Context Sensitive mode records your operations in terms of the GUI objects in your
application. WinRunner identifies each object you click (such as a window, menu, list, or
button), and the type of operation you perform (such as press, enable, move, or select).
For example, if you record a mouse click on the OK button in the Flight Reservation Login
window, WinRunner records the following TSL statement in your test script:
button_press ("OK");
When you run the script, WinRunner reads the command, looks for the OK
button, and presses it.
If you are testing an application that contains both GUI objects and bitmap areas, you can
switch between modes as you record.
Recording a Context Sensitive Test
In this exercise you will create a script that tests the process of opening an order in the Flight
Reservation application. You will create the script by recording in Context Sensitive mode.
1 Start WinRunner.
6 Stop recording.
4 Stop Recording.
Use Verify mode when running a test to check the behavior of your
application, and when you want to save the test results.
Use Debug mode when you want to check that the test script runs smoothly
without errors in syntax. See Lesson 7 for more information.
Use Update mode when you want to create new expected results for a GUI
checkpoint or bitmap checkpoint. See Lessons 5 and 6 for more information
1 Check that WinRunner and the main window of the Flight Reservation application
are open on
your desktop.
2 Make sure that the saved test window is active in WinRunner.
3 Make sure the main window of the Flight Reservation application is active.
Conclusion
============================================================
========================
Summary:
----------------
Test Result: OK
Total number of bitmap checks: 0
Total number of GUI checks: 0
Total Run Time: 00:00:04
============================================================
========================
Summary:
----------------
Test Result: OK
Total number of bitmap checks: 0
Total number of GUI checks: 0
Total Run Time: 00:00:04
WinRunner waits a set time interval for an application to respond to input. The default wait interval is up to 10
seconds. If the application responds slowly during a test run, WinRunner’s default wait time may not be
sufficient, and the test run may unexpectedly fail.
If you discover a synchronization problem between the test and your application,
you can either:
Increase the default time that WinRunner waits. To do so, you change the value of the Timeout for
Checkpoints and CS Statements option in the Run tab of the General Options dialog box (Settings >
General Options). This method affects all your tests and slows down many other Context Sensitive
operations.
Insert a synchronization point into the test script at the exact point where the problem occurs. A
synchronization point tells WinRunner to pause the test run in order to wait for a specified response in
the application. This is the recommended method for synchronizing a test with your application.
Creating a Test
In this first exercise you will create a test that opens a new order in the Flight Reservation application and
inserts the order into a database
8 Stop recording.
2 Place the cursor at the point where you want to synchronize the test.
3 Synchronize the test so that it waits for the “Insert Done” message to
appear in the status bar.
Summary:
----------------
Test Result: OK
Total number of bitmap checks: 0
Total number of GUI checks: 0
Total Run Time: 00:00:07
------------------------------------------------------------------------------
7 Create another GUI checkpoint for the Order No. check box.
10 Stop recording.
===========================================================================
=========
Summary:
----------------
Test Result: OK
Total number of bitmap checks: 0
Total number of GUI checks: 3
Total Run Time: 00:00:02
Theory:
13 Insert another bitmap checkpoint that checks the Agent Signature box.
Conclusion:
=========================================================================
Summary:
----------------
Test Result: OK
Total number of bitmap checks: 2
Total number of GUI checks: 0
Total Run Time: 00:00:38
------------------------------------------------------------------------------
Steps:
7 Stop recording.
9 Insert a blank line above the button_press ("Cancel"); statement and place
the cursor at the beginning of this line.
16 Place the cursor below the last edit_get_text statement in the saved script.
17 Add the following statements to the test script exactly as they appear
below. Note that the tabs or spaces at the beginning of the second and
fourth lines are optional.
if (tickets*price == total)
tl_step ("total", 0, "Total is correct.");
else
tl_step ("total", 1, "Total is incorrect.");
these statements mean: “If tickets multiplied by price equals total, report that the total is correct,
otherwise (else) report that the total is incorrect.
Conclusion:
================================================================
Summary:
---------------
Test Result: OK
Total number of bitmap checks: 0
Total number of GUI checks: 0
Total Run Time: 00:00:03
------------------------------------------------------------------------------
Theory:
Once you have successfully debugged and run your test, you may want to see how the same test performs with
multiple sets of data. To do this, you convert your test to a data-driven test and create a corresponding data
table with the sets of data you want to test.
You can convert your test to a data-driven test using the DataDriver Wizard or you can modify your script
manually.
When you run your data-driven test, WinRunner runs the parameterized part(s) of the test one time (called an
iteration) for each set of data in the data table, and then displays the results for all of the iterations in a single
Test Results window.
In Lesson 7 you created a test that opened a specific flight order and read the number of tickets, price per
ticket, and total price from a fax order dialog box in order to check that the total price was correct. In this
lesson you will create a test that performs the same check on several flight orders in order to check that your
application computes the correct price for various quantities and prices of tickets.
11Locate the Fax Order window in the flight1a.gui GUI map file.