Qtp&load Runner

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 controlflow structures, and by inserting transactions and rendezvous points into the script. Then configure the runtime 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.