Quick Test Professional

Quick Test Professional enables you to test standard Windows applications, Web objects,
ActiveX controls, and Visual Basic applications. Quick Test Professional facilitates creating
tests and business components by recording operations as you perform them on your
application.

Test—A collection of steps organized into one or more actions, which are used to verify that
your application performs as expected

Business Component—A collection of steps representing a single task in your application.

Business components (also known as components) are combined into specific scenarios to
build business process tests in Mercury Quality Center with Business Process Testing.

Testing process in QTP

The quick Testing process consist of 7 main phases:
Preparing to record
Recording a session
Enhancing Your Test
Debugging your test
Running your test
Analyzing the Test Results
Reporting Defects

The Test pane contains two tabs to view your test or component—the Keyword View and the
Expert View.

Keyword View

The Keyword View enables you to create and view the steps of your test or component in a
keyword-driven, modular, table format. Each step in your test or component is a row in the
Keyword View, comprised of individual parts which you can easily modify. You create and
modify tests or components by selecting items and operations in the Keyword View and
entering information as required.

Expert View

In the Expert View, QuickTest displays each operation performed on your application in the
form of a script, comprised of VBScript statements. The Expert View is a script editor with
many script editing capabilities. For each object and method in an Expert View statement, a
corresponding row exists in the Keyword View.

Active Screen
The Active Screen provides a snapshot of your application as it appeared when you
performed a certain step during a recording session. Additionally, depending on the Active
Screen capture options that you used while recording, the page displayed in the Active
Screen can contain detailed property information about each object displayed on the page.
Recording Mode:

Analog Recording:

This enables to record the exact mouse and keyboard operations performed in relation to
either the screen or the application window.

Low level recording:

This mode records at the object level and records all the run time objects as window or
winobject test objects. This mode can be used if the co ordinates of the objects are important
for the test or component.

Synchronization Test:

We can insert a synchronization point which instructs the quick test to pause the test until an
object property achieves the value you specify. When doing this Quick test generates a wait
property statement in the Expert view. We can also insert Exist or wait statements that
instructs Quick test to wait until an object exists or to wait a specified amount of time before
continuing the test or component

Checkpoints:

Quick test provides many checkpoints to check if the application or the website functions
properly. A Checkpoint is a verification point that compares a current value for a specified
property with the expected value for that property.

Types of Checkpoint:

Standard Checkpoint - Checks values of an object’s properties.

Image Checkpoint - Checks the property values of an image

Table Checkpoint - Checks information in a table

Page checkpoint - Checks the characteristics of a Web page

Text /Text Area Checkpoint - Checks that a text string is displayed in the appropriate place in a
Web page or application window

Bitmap Checkpoint - Checks an area of a Web page or application after capturing it as a bitmap

Database Checkpoint - Checks the contents of databases accessed by an application or Web

site

Accessibility - Checkpoint Identifies areas of a Web site to check for Section 508 compliancy

XML Checkpoint - Checks the data content of XML documents

Data Driver:

Quick test enables to expand the scope of the basic test or component by replacing fixed
values with parameters. This process, known as parameterization, greatly increases the
power and flexibility of your test or component. A parameter is a variable that is assigned a
value from an external data source or generator. When testing the applications, we may want
to check how it performs the same operations with multiple sets of data. This can be done in
Quick test by the Data Driver.

Data Table parameters enable you to create a data-driven test (or action) that runs several
times using the data you supply. In each repetition, or iteration, QuickTest uses a different
value from the Data Table. When you parameterize a step in a test using the Data Table, you
must decide whether you want to make it a global Data Table parameter or an action Data
Table parameter.

Global Data Table parameters take data from the global sheet in the Data Table. The global
sheet contains the data that replaces global parameters in each iteration of the test. By
default, the test runs one iteration for each row in the global sheet of the Data Table.

Action Data Table parameters take data from the action’s sheet in the Data Table. The data
in the action’s sheet replaces the action’s parameters in each iteration of the action. By
default, actions run only one iteration.

Parameterize the value of a checkpoint property enables you to check how an application or
Web site performs the same operation based on different data.

Regular Expression Syntax

Regular expressions enable QuickTest to identify objects and text strings with varying values.
You can use regular expressions when defining the properties of an object, the methods of
an argument, when parameterize a step, and when creating checkpoints with varying values.
A regular expression is a string that specifies a complex search phrase. By using special
characters such as a period (.), asterisk (*), caret (^), and brackets ([ ]), you define the
conditions of the search.

Recovery Manager:

Unexpected events, errors, and application crashes during a run session can disrupt your
run session and distort results. This is a problem particularly when running tests or
components unattended—the test or component is suspended until you perform the
operation needed to recover.

The Recovery Scenario Manager provides a wizard that guides you through the process of
defining a recovery scenario—a definition of an unexpected event and the operation(s)
necessary to recover the run session.
A recovery scenario consists of the following:

Trigger Event—The event that interrupts your run session.

Recovery Operation(s)—The operation(s) that need to be performed in order to continue

running the test or component.

Post-Recovery Test Run Option—The instructions on how QuickTest should proceed once the
recovery operations have been performed, and from which point in the test or component
QuickTest should continue, if at all.

Load Runner

Mercury Load Runner is the performance testing tool for predicting system behavior and performance. Load
runner emulates an environment in which thousands of users work with client/server system concurrently.
For this load runner replaces the human user with virtual user (Vusers). Using limited hardware resources,
Load Runner emulates hundreds or thousands of concurrent users to put the application through the rigors
of real-life user loads.

Vugen: VuGen is also known as Vuser generator that enables to develop Vuser script for a variety of
application types and communication. VuGen creates the script by recording the activity between the client
and the server. It monitors the client end of the database and traces all the requests sent to, and received
from, the database server.

Vusers: Load Runner replaces the human users with virtual users or Vusers. The load on the system can be
increased by increasing the number of Vusers.

Load testing process:

Step 1: Planning the test.

A clearly defined test plan ensures the test scenarios developed to accomplish load-testing objectives.

Step 2: Creating Vusers.

Vuser scripts are that contain tasks performed by each Vuser, tasks performed by Vusers as a whole, and
tasks measured as transactions
Step 3: Define the scenario.

A scenario describes the events that occur during a testing session. It includes a list of machines, scripts,
and Vusers that run during the scenario. We create scenarios using Load Runner Controller. We can create
manual scenarios as well as goal-oriented scenarios. In manual scenarios, we define the number of Vusers,
the load generator machines, and percentage of Vusers to be assigned to each script. For web tests, we
may create a goal-oriented scenario where we define the goal that our test has to achieve. LoadRunner
automatically builds a scenario for us.

Step 4: Running the scenario.

We emulate load on the server by instructing multiple Vusers to perform tasks simultaneously. Before the
testing, we set the scenario configuration and scheduling. We can run the entire scenario, Vuser groups, or
individual Vusers.

Step 5: Monitoring the scenario.

We monitor scenario execution using the LoadRunner online runtime, transaction, system resource, Web
resource, Web server resource, Web application server resource, database server resource, network delay,
streaming media resource, firewall server resource, ERP server resource, and Java performance monitors.

Step 6: Analyzing test results.

During scenario execution, LoadRunner records the performance of the application under different loads.
We use LoadRunner’s graphs and reports to analyze the application’s performance.

A scenario defines the events that occur during each testing session. The action that a Vuser performs
during the scenario is described in Vuser Script. The Vuser scripts include functions that measure and
record the performance of your application’s components.

A controller reads a single scenario to co-ordinate several host machines which specify the use of different
run time settings, running different Vuser script and storing results in different locations.

Vuser types:

The Vuser types are divided into the following categories:

E-business: For Web (HTTP, HTML), COM/DCOM, CORBA-Java,

General-Java, Java(GUI), Jolt, LDAP, POP3, and FTP protocols.

Middleware: For Jolt, and Tuxedo (6.0, 6.3) protocols.

ERP: For SAP, Baan, Oracle NCA, and People soft (Tuxedo or Web) protocols.

Client/Server: For Informix, MSSQL Server, ODBC, Oracle (2-tier), Sybase Ctlib, Sybase Dblib, and
Windows Sockets protocols.

Legacy: For APPC and Terminal Emulation (RTE).

General: For C template, Java template, and Windows Sockets type scripts.
Creating the Vuser Scripts

Step-1: Record a basic Vuser script

Step-2: Enhance/edit the Vuser script

Step-3: Configure Run-Time settings

Step-4: Run the Vuser script in stand- alone mode

Step-5: Incorporate the Vuser script into a LoadRunner scenario

The process was started by developing a Vuser script by recording a basic script. LoadRunner provides
number of tools for recording Vuser scripts. Then enhancement in the basic script is done by adding control-
flow structures, and by inserting transactions and rendezvous points into the script. Then configure the run-
time settings. The run-time settings include iteration, log, and timing information, and define how the Vuser
will behave when it executes the Vuser script. To verify that the script runs correctly, run it in stand-alone
mode. When script runs correctly, incorporate it into a LoadRunner scenario.