Load RunnerTraining

© Xavient Information SystemsThis document contains the confidential and proprietary information of Xavient Information Systems, the disclosure of which would provide a competitive advantage to others. As a result, no part of this document should be disclosed, used, duplicated, reproduced, stored, copied, or transmitted, in whole or in part, in any form or means, electronic, mechanical, photocopying or otherwise without the express consent of Xavient Information Systems. This document shall remain the property of Xavient Information Systems.This restriction does not limit the rights of the recipient to use information contained within the document if it is rightfully obtained from the source without restriction. The data subject to this restriction are contained in the entire document

Xavient Information Systems2125 C Madera Road; Simi Valley, C.A 93065.

Main Line: 1.805.955.4111, Fax Line: 1.805.955.4144 Visit us: www.xavient.com

1 | P a g e

Version Summary

Version No. Prepared By Reviewed By Approved By Release Date

1.0 Syed Faeez Sultan Vandana Negi

2 | P a g e

ContentsWhat is testing.............................................................................................................................................5

Software testing is divided into two categories:..........................................................................................6

Functional testing:...............................................................................................................................6

Non Functional Testing:.......................................................................................................................7

Performance Testing...................................................................................................................................8

Performance testing can serve different purposes..............................................................................8

Why Do Performance Testing?....................................................................................................................9

Performance Testing Sub-Genres......................................................................................................10

Performance Testing Approach.................................................................................................................12

Terminologies............................................................................................................................................15

Throughput:-......................................................................................................................................15

Latency:-............................................................................................................................................15

Concurrent User:-..............................................................................................................................15

State Full:-..........................................................................................................................................15

State Less:-.........................................................................................................................................15

Cookies:-............................................................................................................................................15

Persistent Cookie:-.............................................................................................................................16

Non Persistent Cookie:-.....................................................................................................................16

Cache:-...............................................................................................................................................16

Paging: -.............................................................................................................................................16

Response Time:-................................................................................................................................17

Dead Lock:-........................................................................................................................................17

Multithreading:-................................................................................................................................18

Process:-............................................................................................................................................18

Client Server Architecture.........................................................................................................................19

Two tier architecture.........................................................................................................................19

Three tier architecture.......................................................................................................................20

LOAD RUNNER...........................................................................................................................................22

Components of Load Runner.............................................................................................................23

3 | P a g e

Lab Setup:..................................................................................................................................................25

Scripting.....................................................................................................................................................26

Recording Option...............................................................................................................................26

Customization of Script......................................................................................................................31

Parameterization...............................................................................................................................31

Correlation:........................................................................................................................................34

Runtime settings................................................................................................................................36

Debug Function.........................................................................................................................................47

lr_set_debug_message..................................................................................................................51

Controller..................................................................................................................................................53

Controller Functionality.....................................................................................................................53

Types of Scenarios.............................................................................................................................54

Vuser Groups.....................................................................................................................................54

Adding Vuser Group..........................................................................................................................55

Analysis......................................................................................................................................................57

Creating Analysis Session...................................................................................................................57

How to Collate the Results................................................................................................................59

Analysis Graphs.................................................................................................................................59

Adding New Graph............................................................................................................................60

4 | P a g e

What is testingIt is the process used to help identify the correctness, completeness,

security, and quality of developed computer software. Testing is a process of technical investigation, performed on behalf of stakeholders, that is intended to reveal quality-related information about the product with respect to the context in which it is intended to operate. This includes, but is not limited to, the process of executing a program or application with the intent of finding errors. Quality is not an absolute; it is value to some person. With that in mind, testing can never completely establish the correctness of arbitrary computer software; testing furnishes a criticism or comparison that compares the state and behavior of the product against a specification. An important point is that software testing should be distinguished from the separate discipline of Software Quality Assurance

(SQA), which encompasses all business process areas, not just testing.

5 | P a g e

Software testing is divided into two categories:

Functional Testing Non Functional Testing

Functional testing:Functional testing is testing the application against business

requirements. It is done using the functional specifications provided by the client or by using the design specifications like use cases provided by the design team.

Functional Testing covers:

Unit Testing Smoke testing / Sanity testing Integration Testing (Top Down, Bottom up Testing) Interface & Usability Testing System Testing Regression Testing Pre User Acceptance Testing(Alpha & Beta) User Acceptance Testing White Box & Black Box Testing Globalization & Localization Testing

Non Functional Testing:In contrast to functional testing, which establishes the correct

operation of the software (correct in that it matches the expected behavior defined in the design requirements), non-functional testing verifies that the software functions properly even when it receives invalid or unexpected inputs. Software fault injection, in the form of fuzzing, is an example of non-functional testing.

The non functional aspect of software components involves things or criteria which judges the operation of the system, rather than specific behavior.

Non-Functional Testing covers:

6 | P a g e

Load and Performance Testing Ergonomics Testing Stress & Volume Testing Compatibility & Migration Testing Data Conversion Testing Security / Penetration Testing Operational Readiness Testing Installation Testing Security Testing (Application Security, Network Security, System

Security)

7 | P a g e

Performance TestingPerformance testing is type of Non functional testing. It is used to

determine the speed or effectiveness of a computer, network, software program or device. This process can involve quantitative tests done in a lab, such as measuring the response time or the number of MIPS (millions of instructions per second) at which a system functions. Performance testing is often done in conjunction with stress testing.

Performance testing can serve different purposes It can demonstrate that the system meets performance criteria. It can compare two systems to find which performs better. Or it can measure what parts of the system or workload causes

the system to perform badly.

8 | P a g e

Why Do Performance Testing?At the highest level, performance testing is almost always conducted

to address one or more risks related to expense, opportunity costs, continuity, and/or corporate reputation. Some more specific reasons for conducting performance testing include:

Assessing release readiness by: Enabling you to predict or estimate the performance

characteristics of an application in production and evaluate whether or not to address performance concerns based on those predictions. These predictions are also valuable to the stakeholders who make decisions about whether an application is ready for release or capable of handling future growth, or whether it requires a performance improvement/hardware upgrade prior to release.

Providing data indicating the likelihood of user dissatisfaction with the performance characteristics of the system.

Providing data to aid in the prediction of revenue losses or damaged brand credibility due to scalability or stability issues, or due to users being dissatisfied with application response time.

Assessing infrastructure adequacy by: Evaluating the adequacy of current capacity. Determining the acceptability of stability. Determining the capacity of the application’s infrastructure, as

well as determining the future resources required to deliver acceptable application performance.

Comparing different system configurations to determine which works best for both the application and the business.

Verifying that the application exhibits the desired performance characteristics, within budgeted resource utilization constraints.

Assessing adequacy of developed software performance by: Determining the application’s desired performance

characteristics before and after changes to the software. Providing comparisons between the application’s current and

desired performance characteristics. Improving the efficiency of performance tuning by:

Analyzing the behavior of the application at various load levels. Identifying bottlenecks in the application. Providing information related to the speed, scalability, and

stability of a product prior to production release, thus enabling you to make informed decisions about whether and when to tune the system.

9 | P a g e

Performance Testing Sub-Genres

Load Testing

Load testing is the simplest form of performance testing. A load test is usually conducted to understand the behavior of the application under a specific expected load. This load can be the expected concurrent number of users on the application performing a specific number of transactions within the set duration. This test will give out the response times of all the important business critical transactions. If the database, application server, etc. are also monitored, then this simple test can itself point towards any bottlenecks in the application software.

Stress Testing

Stress testing is normally used to understand the upper limits of capacity within the application landscape. This kind of test is done to determine the application's robustness in terms of extreme load and helps application administrators to determine if the application will perform sufficiently if the current load goes well above the expected maximum.

Endurance Testing (Soak Testing)

Endurance testing is usually done to determine if the application can sustain the continuous expected load. During endurance tests, memory utilization is monitored to detect potential leaks. Also important, but often overlooked is performance degradation. That is, to ensure that the throughput and/or response times after some long period of sustained activity are as good as or better than at the beginning of the test.

Spike Testing

Spike testing, as the name suggests is done by spiking the number of users and understanding the behavior of the application; whether performance will suffer, the application will fail, or it will be able to handle dramatic changes in load.

Configuration Testing

Configuration testing is another variation on traditional performance testing. Rather than testing for performance from the perspective of load you

10 | P a g e

are testing the effects of configuration changes in the application landscape on application performance and behavior. A common example would be experimenting with different methods of load-balancing.Isolation Testing

Isolation testing is not unique to performance testing but a term used to describe repeating a test execution that resulted in an application problem. Often used to isolate and confirm the fault domain.

11 | P a g e

Performance Testing Approach

The performance testing approach:

1. Activity 1. Identify the Test Environment.  Identify the physical test environment and the production environment as well as the tools and resources available to the test team. The physical environment includes hardware, software, and network configurations. Having a thorough understanding of the entire test environment at the outset enables more efficient test design and planning and helps you identify testing challenges early in the project. In some situations, this process must be revisited periodically throughout the project’s life cycle.

2. Activity 2. Identify Performance Acceptance Criteria.  Identify the response time, throughput, and resource utilization goals and constraints. In general, response time is a user concern, throughput is a business concern, and resource utilization is a system concern. Additionally, identify project

12 | P a g e

success criteria that may not be captured by those goals and constraints; for example, using performance tests to evaluate what combination of configuration settings will result in the most desirable performance characteristics.

3. Activity 3. Plan and Design Tests.  Identify key scenarios, determine variability among representative users and how to simulate that variability, define test data, and establish metrics to be collected. Consolidate this information into one or more models of system usage to be implemented, executed, and analyzed.   

4. Activity 4. Configure the Test Environment.  Prepare the test environment, tools, and resources necessary to execute each strategy as features and components become available for test. Ensure that the test environment is instrumented for resource monitoring as necessary.

5. Activity 5. Implement the Test Design.  Develop the performance tests in accordance with the test design.

6. Activity 6. Execute the Test.  Run and monitor your tests. Validate the tests, test data, and results collection. Execute validated tests for analysis while monitoring the test and the test environment.

7. Activity 7. Analyze Results, Report, and Retest.  Consolidate and share results data. Analyze the data both individually and as a cross-functional team. Reprioritize the remaining tests and re-execute them as needed. When all of the metric values are within accepted limits, none of the set thresholds have been violated, and all of the desired information has been collected, you have finished testing that particular scenario on that particular configuration.

13 | P a g e

TerminologiesThroughput:-

Throughput or network throughput is the average rate of successful message delivery over a communication channel. This data may be delivered over a physical or logical link, or pass through a certain network node. The throughput is usually measured in bits per second (bit/s or bps), and sometimes in data packets per second or data packets per time slot. The system throughput or aggregate throughput is the sum of the data rates that are delivered to all terminals in a network.

Latency:- In general, the period of time that one component in a system is

spinning its wheels waiting for another component. Latency, therefore, is wasted time. For example, in accessing data on a disk, latency is defined as the time it takes to position the proper sector under the read/write head.

Concurrent User:-It’s that when a number of users try to Access a Particular Action at

one Time. A computer operating system that allows several users to access a resource on the computer at the same time is a multiuser multitasking operating system, historically called a time-sharing operating system. The capacity of a system can also be measured in terms of maximum concurrent users, at which point system performance begins to degrade noticeably.

State Full:- State full means that some device is keeping track of another device

or a connection, either temporarily or over a long period of time. A state full connection is one in which some information about a connection between two systems is retained for future use.

State Less:- Previous access methods do not maintain a session between the server and the database.

Cookies:- A cookie, also known as a web cookie, browser cookie, and HTTP

cookie, is a piece of text stored on a user's computer by their web browser. A cookie can be used for authentication, storing site preferences, shopping cart

14 | P a g e

contents, the identifier for a server-based session, or anything else that can be accomplished through storing text data. A cookie consists of one or more name-value pairs containing bits of information, which may be encrypted for information privacy and data security purposes. The cookie is sent as a field in the header of the HTTP response by a web server to a web browser and then sent back unchanged by the browser each time it accesses that server. Cookies may be set by the server with or without an expiration date. Cookies without an expiration date exist until the browser terminates, while cookies with an expiration date may be stored by the browser until the expiration date passes. Users may also manually delete cookies in order to save space or to address privacy issues.

Persistent Cookie:- These cookies are stored in Hard disk. If a Persistent Cookie has Max-

age Set to 1 year, then within a Year, the initial value Set in that Cookie would be sent back to Server Every time, User is Visiting the server.

Non Persistent Cookie:-These Cookies are Stored in Web Browser. A session Cookie Will Expire if a

User closes the Browser or if a User Haven’t visited the server for Certain Period of Time.

Cache:- It’s is a component that transparently stores data so that future

requests for that data can be served faster. The data that is stored within a cache might be values that have been computed earlier or duplicates of original values that are stored elsewhere. If requested data is contained in the cache (cache hit), this request can be served by simply reading the cache, which is comparatively faster. Otherwise (cache misses), the data has to be recomputed or fetched from its original storage location, which is comparatively slower. Hence, the more requests can be served from the cache the faster the overall system performance is. To be cost efficient and to enable an efficient use of data, caches are relatively small. Nevertheless, caches have proven themselves in many areas of computing because access patterns in typical computer applications have locality of reference. References exhibit temporal locality if data is requested again that has been recently requested already. References exhibit spatial locality if data is requested that is physically stored close to data that has been requested already.

15 | P a g e

Paging: - Paging is one of the memory-management schemes by which a

computer can store and retrieve data from secondary storage for use in main memory. In the paging memory-management scheme, the operating system retrieves data from secondary storage in same-size blocks called pages. The main advantage of paging is that it allows the physical address space of a process to be noncontiguous. Before the time paging was used, systems had to fit whole programs into storage contiguously, which caused various storage and fragmentation problems. Paging is an important part of virtual memory implementation in most contemporary general-purpose operating systems, allowing them to use disk storage for data that does not fit into physical random-access memory (RAM).

Response Time:- In real-time systems the response time of a task or thread is defined

as the time elapsed between the dispatch (time when task is ready to execute) to the time when it finishes its job (one dispatch).

Dead Lock:- Deadlock is a common problem in multiprocessing where many

processes share a specific type of mutually exclusive resource known as a software lock or soft lock. Computers intended for the time-sharing and/or real-time markets are often equipped with a hardware lock (or hard lock) which guarantees exclusive access to processes, forcing serialized access. Deadlocks are particularly troubling because there is no general solution to avoid (soft) deadlocks.

Example:-

This situation may be likened to two people who are drawing diagrams, with only one pencil and one ruler between them. If one person takes the pencil and the other takes the ruler, a deadlock occurs when the person with the pencil needs the ruler and the person with the ruler needs the pencil to finish his work with the ruler. Neither request can be satisfied, so a deadlock occurs.

Connection Pooling Connection pooling is maintaining a pool of connection which will allow us to resume the connection without creating a new one.The most time consuming process when we work with a database is to create a connection object. When application goes out of scope the object becomes a candidate for garbage collector. Every time we create and every time will be destroyed. This was effect on a distributed application, where n

16 | P a g e

no clients are waiting for the response. Connection pooling is a concept of object reusability. This is a service provided by application servers.

Multithreading:-Multithreading is the ability of a program or an operating system

process to manage its use by more than one user at a time and to even manage multiple requests by the same user without having to have multiple copies of the programming running in the computer. Each user request for a program or system service (and here a user can also be another program) is kept track of as a thread with a separate identity. As programs work on behalf of the initial request for that thread and are interrupted by other requests, the status of work on behalf of that thread is kept track of until the work is completed.

Process:- Process is defined as the virtual address space and the control

information necessary for the execution of a program while Threads are a way for a program to split itself into two or more simultaneously running tasks. In general, a thread is contained inside a process and different threads in the same process share some resources while different processes do not.

17 | P a g e

Client Server ArchitectureTwo tier architecture

In modern two-tier architecture, the server holds both the application and the data. The application resides on the server rather than the client, probably because the server will have more processing power and disk space than the PC.

Two tier architecture

18 | P a g e

Three tier architectureThree-tier is a client–server architecture in which the user interface,

functional process logic ("business rules"), computer data storage and data access are developed and maintained as independent modules, most often on separate platforms.Three-tier architecture has the following three tiers:

Presentation tierThis is the topmost level of the application. The presentation tier

displays information related to such services as browsing merchandise, purchasing, and shopping cart contents. It communicates with other tiers by outputting results to the browser/client tier and all other tiers in the network.

Application tier

(Business logic, logic tier, data access tier, or middle tier)The logic tier is pulled out from the presentation tier and, as its own layer, it controls an application’s functionality by performing detailed processing.

Data tierThis tier consists of database servers. Here information is stored and

retrieved. This tier keeps data neutral and independent from application servers or business logic. Giving data its own tier also improves scalability and performance.

19 | P a g e

Three tier architecture

20 | P a g e

LOAD RUNNERPerformance testing cannot be done manually. We cannot say

1000 users to click on the same button at a same time. We need a tool to do performance testing. Load runner is a tool for the performance testing. There are many tools available in the market for the performance testing but Load runner is the best amongst them.

Manual Testing Is Problematic

21 | P a g e

Components of Load Runner

22 | P a g e

Testers

Load Generation

System Under Test

Do you have the testing resources? Testing personnel Client machinesHow do you synchronize users?How do you collect and analyze results?How do you achieve test repeatability?

Analysis?123.20

All of you,

click the GO

button again

Web server Databas

e server

Coordinator

Types of Components VuGen (Virtual User Generator) Load Generator Controller Analysis

VuGen (Virtual User Generator)

The VuGen is used to emulate the steps of real human users. VuGen lets the user record and/or script a test to be performed against an application under test, and play back and make modifications to the script as needed, such as defining Parameterization (selecting data for keyword-driven testing). HP LoadRunner supports more than 51 protocols including Web HTTP/HTTPS, Remote Terminal Emulator, Oracle and Web Services. A protocol acts as a communication medium between a client and a server.

Load Generator

Load generators (also known as hosts) are used to run the Vusers that generate load on the application under test.

Controller

Once a script is prepared in Vugen, it is run via the Controller. Each run is called as a scenario with some preset settings. As a single point of control, it provides complete visibility of the tests and the virtual users. The Controller facilitates the process of creating a load test scenario by allowing us to:

Assign scripts to individual groups. Define the total number of virtual users needed to run the tests. Define the host machines on which virtual users are running.

Controller provides a suite of performance monitors to monitor the performance of individual components. Some monitors include Oracle Monitors, WebSphere Monitors, etc. Once a scenario is set and the run is completed, the result of the scenario can be viewed via the Analysis tool.

Analysis

23 | P a g e

Once the results are ready, analysis is the most important job in the whole performance test if the requirements of performance test are not defined. The main criteria for analysis should be to find out the bottlenecks and we should be able to track the transactions / users / hits that create the highest level of performance reduction. Based on the test run, Load Runner will generate various graphs and reports. This phase contains.

Lab Setup:

24 | P a g e

Lab Setup

ScriptingRecording OptionBroadly divided into three categories:-

General Network HTTP Properties

General:-

Script:When you record a session VuGen creates a script that emulates your

actions. The default script generation language is C or C# for MS .NET. For the FTP, COM/DCOM, and mail protocols (IMAP, POP3, and SMTP), VuGen can also generate a script in Visual Basic, VB Script, and JavaScript.

25 | P a g e

Protocols:Before recording a multi-protocol session, VuGen lets you modify the

protocol list for which to generate code during the recording session. If you specified certain protocols when you created the script, you can enable or disable them using the Protocol Recording options.

Recording:HTML

The HTML-based script level generates a separate step for each HTML user action. The steps are also intuitive, but they do not reflect true emulation of the JavaScript code.

URLThe URL-based script mode option instructs VuGen to record all

browser requests and resources from the servers that were sent due to the

26 | P a g e

user's actions. It automatically records every HTTP resource as URL steps (web_url statements). All actions are recorded as web_url steps instead of web_link, web_image, and so on.

Network:-VuGen uses the Port Mapping settings to direct traffic via a specific

server:port combination to the desired communication protocol. You can configure the Port Mapping settings in the following areas:

Capture level. The level of data to capture (relevant only for HTTP based protocols):

Socket level data. Capture data using trapping on the socket level only. Port mappings apply in this case (default).

WinINet level data. Capture data using hooks on the WinINet.dll API used by certain HTTP applications. The most common application that uses these hooks is Internet Explorer. Port mappings are not relevant for this level.

Socket level and WinINet level data. Captures data using both mechanisms. WinINet level sends information for applications that use the WinINet DLL. Socket level sends data only if it determines that it did not originate from the WinINet dll. Port mapping applies to data that did not originate from WinINet.

HTTP Properties

27 | P a g e

Advanced

Correlation

28 | P a g e

VuGen's correlation engine allows you to automatically correlate dynamic data during your recording session

29 | P a g e

Customization of Script

ParameterizationParameters are like script variables. They are used to vary input to the

server and to emulate real users. Parameter is not a dynamic value captured from server response but it is something for which the user has predefined data values available. There is different type of parameters in Load Runner, Different types of Parameters.

Types of Parameter list:FileDate/timeUser IDGroup NameIteration numberLoad Generator nameRandom Number parameterUnique numberUser Defined FunctionUser File path

Data Files: Data that is contained in a file either an existing file or one that we create with VuGen. Data files hold data that a Vuser accesses during script execution. Data can be stored in local or global files. Data files are useful if we have many known values for parameter. The data in a data file is stored in the form of a table. One file can contain values for many parameters. Each column holds the data for one parameter.

30 | P a g e

31 | P a g e

32 | P a g e

Correlation:Correlation is use to handle dynamic content. Dynamic content refers

to page components that are dynamically created during the execution of a business process, and the value may differ from the value generated in a previous run. Examples of dynamic content include the ticket number in an on-line reservation system, a transaction ID in an on-line banking application and most importantly the unique session ID that is created each time a user logs in. Such dynamic values must be correlated in order to run the recorded script. The script while running will return an error if such a dynamic value has not been correlated, since the value changes each time the user logs in.

Correlation can be done in two ways:1. Automatic Correlation2. Manual Correlation

Automatic Correlation:VuGen's correlation engine allows you to automatically correlate

dynamic data during your recording session

33 | P a g e

Manual CorrelationManual Correlation is done by using the LR inbuilt function given below: web_reg_save_param("When_Txt", "LB= ", "RB= ", LAST);

Runtime settings

Broadly divided into four categories: General Network Browser Internet Protocol

General

Run LogicYou can instruct a Vuser to Repeat the Run section when you run the

script. Each repetition is known as iterationNumber of Iterations

Load Runner repeats all of the actions, the specified number of times.If you specify scenario duration in the controller, the duration setting overrides the Vusers iteration settings.

34 | P a g e

Pacing Control the time between iterations. The pace tells the Vuser how long to wait between iterations of Vuser

You can instruct Vuser by following any of the method below As soon as the previous iteration ends. After the previous iteration ends with a fixed / random delay At fixed / random intervals

Log Vusers log information about themselves and their communication between serverTwo types of Logs

Standard Extended

VuGen writes log messages that we can view in execution log.

35 | P a g e

lr_log_message. Messages sent manually, using lr_message, lr_output_message, and lr_error_message, are still issued

Think TimeWhen you run a Vuser script, the Vuser uses the think time values that

were recorded into the script during the recording session. VuGen allows you to use the recorded think time, ignore it, or use a value related to the recorded time:

36 | P a g e

MiscellaneousWe can set the following miscellaneous run-time options for a Vuser script:

Error Handling Multithreading

Vusers support multithreaded environments. The primary advantage of a multithread environment is the ability to run more Vusers per load generator. Automatic Transactions

37 | P a g e

NetworkUsing the Speed Simulation settings, you can select a bandwidth that best emulates the environment under test. The following options are available:

Use maximum bandwidth. By default, bandwidth emulation is disabled and the Vusers run at the maximum bandwidth that is available over the network.

Use bandwidth. Indicate a specific bandwidth level for your Vuser to emulate. You can select a speed ranging from 14.4 to 512 Kbps, emulating analog modems, ISDN, or DSL.

Use custom bandwidth. Indicate a bandwidth limit for your Vuser to emulate. Specify the bandwidth in bits, where 1 Kilobit=1024 bits.

38 | P a g e

BrowserWe can use the Browser: Browser Emulation node in the Run-Time Settings tree to set the browser properties of your testing environment.

39 | P a g e

Internet

Proxy

Types of Proxy settingNo proxy:

All Vusers should use direct connections to the Internet. This means that the connection is made without using a proxy server.Obtain the proxy settings from the default browser:

All Vusers use the proxy settings of the default browser from the machine upon which they are running.Use custom proxy:

All Vusers use a custom proxy server. You can supply the actual proxy server details or the path of a proxy automatic configuration script (.pac file) that enables automatic configuration

40 | P a g e

PreferenceImage and Text Checks:

Image and text checks option allows the Vuser to perform verification checks during replay by executing the verification functions. This option only applies to statements recorded in HTML-based mode. Vusers running with verification checks use more memory than Vusers who do not perform checks.

41 | P a g e

Download FiltersWe can specify the Web sites from which Vusers should download

resources during replay. You can indicate either the sites to exclude or the sites to include. You control the allowed or disallowed sources, by specifying a URL, host name, or host suffix name.

42 | P a g e

Content CheckVuGen's Content Check mechanism allows you to check the contents

of a page for a specific string. This is useful for detecting non-standard errors. In normal operations, when your application server fails, the browser displays a generic HTTP error page indicating the nature of the error. The standard error pages are recognized by VuGen and treated as errors, causing the script to fail. Some application servers, however, issue their own error pages that are not detected by VuGen as error pages. The page is sent by the server and it contains a formatted text string, stating that an error occurred.

43 | P a g e

44 | P a g e

Debug FunctionWhen we perform load testing, we have to be fully confident, that our application works correctly. It may be very useful to check UI of application - is it shown correctly or not.

This verification can be performed with 2 ways: Using LoadRunner content verification with web_reg_find function Running LoadRunner GUI Vusers (QTP or WR scripts)

How to add Load Runner content checkpoint?

Let's start with Load Runner demo Web application - Web Tours.I will show how to check that a greeting 'Welcome to the Web Tours site' is shown on a start page:

I've recorded a simple script on Web Tour application - it just opens a start page, logs in, and logs out:

45 | P a g e

After that: open the script in Tree View (with menu 'View/Tree View') select initial step ('Url: WebTours') select the text I would like to check on the page and right mouse click:

Use default settings in 'Find Text' dialog:

46 | P a g e

Then open LoadRunner script in Script View (menu 'View/Script View') and i will see that web_reg_find function has been just added before the first function:

web_reg_find("Text=Welcome to the Web Tours site", "Search=Body", LAST); web_url("WebTours", "URL=...", ...LAST);

Please, note:

web_reg_find function has been added before the page opening function (web_url)!This is because LoadRunner web_reg_find function does not search for text on a page; it just registers a search request for a text string on an HTML page.

This is very important and I would like to pay your attention - web_reg_find function should be placed before the function, which loads a page.

Description of web_reg_find function attributesThe simplest web_reg_find function can look like:

web_reg_find("Text=Welcome to the Web Tours site", LAST);

This form means 'register a request to search for a "Welcome to the

47 | P a g e

Web Tours site" text on a next Web page retrieved from a server.

Attribute 'Text=' contains a text, that should be searched.If the check fails, the error is reported after the next action function executes:

Attribute 'Search=' defines the scope of the search:o Body (default value) means to search in a body of server's response and its

resourceso Headers means to search within a pages headers o No resource means to search in a body of HTML page retrieved from server

and do not search in its resources

Example:Please, see a server response:

The following web_reg_find function checks that server's name is 'Xitami':

web_reg_find("Text=Server: Xitami", "Search=Headers", LAST);

The next important attribute of web_reg_find function is 'SaveCount='. Use it to save a number of matches that were found.

Imagine, that we have to get a number of 'A Coach class ticket for:' text on Itinerary page:

48 | P a g e

The following code: uses web_reg_find function with "SaveCount=" attribute (3rd line) before

the Itinerary page loads then loads Itinerary page (6th line) extracts number of matches (8th line) and compares it to an expected value (9th line):

1. int nFound; 2.3. web_reg_find("Text=A Coach class ticket for :",

"SaveCount=TextPresent_Count", LAST); 4.5. // open Itinerary page6. web_image("Itinerary Button", "Alt=Itinerary Button", LAST); 7.8. nFound = atoi(lr_eval_string("{TextPresent_Count}")); 9. if (nFound == 11) 10.     lr_output_message("Correct number of 'Coach class ticket' text:

%d", nFound); 11. else 12. { 13.     lr_error_message("Incorrect number of 'Coach class ticket' text: %d",

nFound); 14.     return 0; 15. } 16.

If we have additional info on 8th line:

17. nFound = atoi(lr_eval_string("{TextPresent_Count}"));

49 | P a g e

lr_set_debug_message

It sets the message level for the script execution. Syntax:-

3. int lr_set_debug_message (unsigned int message_level, unsigned int on_off);

Example   In this example, the lr_set_debug_message function enables the full trace option just before a call to lrd_fetch, which the user needs to debug because it has been giving unexpected results. The second invocation of lr_set_debug_message resets the debug level to what it was formerly, by turning off (LR_SWITCH_OFF) the extended message level.

4. lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_FULL_TRACE, LR_SWITCH_ON );

rc = lrd_fetch(Csr1, 1, 1, 0, PrintRow3);

if (rc>2000) 5.   lr_debug_message(LR_MSG_CLASS_FULL_TRACE,

             "Fetch failed returned %d", rc);

/* Now reset message class to former level */lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG | LR_MSG_CLASS_FULL_TRACE, LR_SWITCH_OFF );

50 | P a g e

ControllerOnce a script is prepared in VuGen, it runs using the LoadRunner

Controller. The Controller manages and maintains the scenarios that are run. During a scenario run, the Controller allows monitoring of network and server resources. The Controller assigns virtual users and load generators to specific scenarios.

Multiple machines can be set up to act as load generators in concert. For example, to run a test of 1000 users, three or more machines can be set up with an HP LoadRunner agent installed on them. These machines are known as load generators because the actual load is generated from them. Each run is configured with a scenario that describes which scripts will run, when they will run, how many virtual users will run, and which load generators will be used for each script. The tester connects each script in the scenario to the name of a machine that is going to act as a load generator and sets the number of virtual users to be run from that load generator. HP LoadRunner can control multiple load generators and collect results, and it can control load generators located at remote networks (through a firewall) if required.

HP LoadRunner uses monitors during a load test to monitor the performance of individual components under load. HP LoadRunner supports more than 60 monitors, including Oracle and other database server monitors, WebSphere and other web application server monitors, transaction and run-time monitors, system resource monitors, network delay monitors, firewall monitors, web server resource monitors, streaming media monitors and ERP/CRM server resource monitors. Once a scenario has been created and run in the Controller, results can be viewed and analyzed using the Analysis tool

Controller Functionality

Controller organizes and manages scenario elements During scenario execution the controller :

Runs Vuser Groups Controls the initialize, run, pause, and stop conditions of each Vuser Displays the status of each Vuser Displays any messages from Vusers Monitors system and network resources

51 | P a g e

Types of Scenarios Manual Scenario

Manage your Load Test by specifying the number of Virtual users to run

Goal-Oriented Scenario Allow LoadRunner Controller to create a Scenario based on the

goals you specify

Manual Scenario

You control the number of Running Vusers at the time which they run. You can specify how many Vusers run simultaneously Allows you to run the Vuser in Percentage mode

Goal-Oriented Scenario

Determine your system to achieve the particular goal The goal may be number of hits per second, Number of transaction per

second, etc., Manages Vusers Automatically to maintain and achieve the goal

Vuser Groups Scenario consists of group of Vusers which emulate the Human users

to interact with your application Each script you select is assigned a Vuser group Each Vuser group is assigned a number of Vusers You can Assign different script to each Vuser or You can assign the

same script to all the Vusers

52 | P a g e

Adding Vuser Group Group Name Vuser Quantity Load Generator name

53 | P a g e

54 | P a g e

Analysis

Reports and Analysis

Creating Analysis Session When you run a scenario, data is stored in a result file with an .lrr

extension. Analysis is the utility that processes the gathered result information and generates graphs and reports.

When you work with the Analysis utility, you work within a session. An Analysis session contains at least one set of scenario results (lrr file). Analysis stores the display information and layout settings for the active graphs in a file with an .lra extension.

Analysis provides graphs and reports to help you analyze the performance of your system. These graphs and reports summarize the scenario execution.

55 | P a g e

To view a summary of the results after test execution, we can use one or more of the following tools:

• Vuser log files contain a full trace of the scenario run for each Vuser. These files are located in the scenario results directory.

• Controller Output window displays information about the scenario run.

• Analysis graphs help you determine system performance and provide information about transactions and Vusers.

• Graph Data and Raw Data views display the actual data used to generate the graph in a spreadsheet format.

Report utilities enable us to view a Summary HTML report for each graph or a variety of Performance and Activity reports. You can create a report as a Microsoft Word document, which automatically summarizes and displays the test’s significant data in graphical and tabular format

How to Collate the Results• When you run a scenario, by default all Vuser information is stored

locally on each Vuser host

56 | P a g e

• After scenario execution the results are automatically collated or consolidated – results from all the hosts are transfer to results directory

• You disable automatic collation by choosing Results > Auto collate Results from the controller window

• You can collate manually by selecting Results > Collate Results• If your results are not collated Analysis will automatically collate the

results before generating the analysis data

Analysis GraphsAnalysis graphs are divided into the following categories:

Vuser Graphs - Provide information about Vuser states and other Vuser statistics.

Error Graphs - Provide information about the errors that occurred during the scenario.

Transaction Graphs - Provide information about transaction performance and response time.

Web Resource Graphs - Provide information about the throughput, hits per second, HTTP responses per second, number of retries per second, and downloaded pages per second for Web Vusers.

Web Page Breakdown Graphs - Provide information about the size and download time of each Web page component.

User-Defined Data Point Graphs - Provide information about the custom data points that were gathered by the online monitor.

System Resource Graphs - Provide statistics relating to the system resources that were monitored during the scenario using the online monitor.

Network Monitor Graphs - Provide information about the network delays.

Firewall Server Monitor Graphs - Provide information about firewall server resource usage.

Web Server Resource Graphs - Provide information about the resource usage for the Apache, iPlanet/Netscape, iPlanet(SNMP), and MS IIS Web servers.

57 | P a g e

Adding New GraphGraph > Add Graph, or click <New Graph>

Graphs that contain data are listed in blue. By default, only graphs that contain data are listed. To view the entire list of LoadRunner graphs, clear Display only graphs containing data.

Use the Scenario Elapsed Time field to limit the time range for which graph data is displayed.

58 | P a g e