Mercury LoadRunnerTutorial

Mercury LoadRunner

Mercury, Mercury Interactive, the Mercury logo, the Mercury Interactive logo, LoadRunner, WinRunner, SiteScope and TestDirector are trademarks of Mercury Interactive Corporation and maybe registered in certain jurisdictions. The absence of a trademark from this list does not constitute a waiver of Mercury's intellectual property rights concerning that trademark.

All other company, brand and product names may be trademarks or registered trademarks of theirrespective holders. Mercury disclaims any responsibility for specifying which marks are owned bywhich companies or which organizations.Mercury Interactive Corporation 379 North Whisman Road
Mountain View, CA 94043

Tel: (650) 603-5200

Toll Free: (800) TEST-911

Customer Support: (877) TEST-HLP

Fax: (650) 603-5300

© 2004 - 2005 Mercury Interactive Corporation, All rights reserved

If you have any comments or suggestions regarding this document, please send them via e-mail todocumentation@mercury.com. LRTUT8.1/01

Welcome to the LoadRunner Tutorial ................................................vii

Lesson 1: Introducing LoadRunner .......................................................1

Why should you automate performance testing? ...............................2
What are the LoadRunner components? ..............................................2

Understanding LoadRunner Terminology............................................3

What is the load testing process?..........................................................3

Getting Familiar with Mercury Tours ...................................................4

Application Requirements.....................................................................5

Lesson 2: The Power of LoadRunner.....................................................7

Creating the Load Test ..........................................................................8

Running the Load Test ........................................................................11

Monitoring the Load Test ...................................................................12

Analyzing Results ................................................................................15

Lesson 3: Building Scripts....................................................................17

Introducing the Virtual User Generator (VuGen)...............................17

How do I start recording user activities?.............................................18

Using VuGen Wizard Mode ................................................................20

How do I record a business process to create a script? .......................21

How do I view the script?....................................................................25

Lesson 4: Playing Back Your Script .....................................................29

How do I set the run-time behavior? ..................................................29

How do I watch my script running in real time? ...............................33

Where can I view information about the replay?...............................34

How do I know if my test passed?.......................................................36

How do I search in or filter the results?..............................................37

Lesson 5: Solving Common Playback Problems..................................41

Preparing Mercury Tours for Playback Errors......................................42

How do I work with unique server values?.........................................42

Table of Contents

7

How do I measure business processes?................................................47

How do I emulate multiple users?.......................................................50

How do I verify Web page content?....................................................53

How can I produce debugging information?......................................56

Did my test succeed? ...........................................................................58

Lesson 7: Creating a Load Testing Scenario .......................................61

Introducing the LoadRunner Controller.............................................62

What mixture of users should be part of the load test? .....................64

The Controller Window at a Glance...................................................66

How do I generate a heavy load? ........................................................67

How do I emulate real load behavior? ................................................68

How do I emulate different types of users?.........................................72

How do I monitor the system under load?.........................................75

Lesson 8: Running The Load Test .......................................................79

The Controller Run View at a Glance .................................................80

How do I run a load test scenario?......................................................81

How do I monitor the application under load?..................................83

How do I watch a user running in real time? .....................................85

Where can I view a summary of user actions?....................................86

How can I increase the load during the test?......................................87

How is the application coping under load?........................................88

Did the application encounter errors? ................................................89

How do I know that the test has finished running?...........................91

Did the application perform well under load? ...................................91

Lesson 9: Advanced Goal-Oriented Scenario......................................93

Which goal type should I use?............................................................94

How do I create a goal-oriented scenario? ..........................................95

The Controller Window at a Glance (Goal-Oriented Scenario) .........96

How do I define the goal? ...................................................................97

How do I determine load behavior?....................................................98

Which online graphs should I monitor? ..........................................100

How do I run a goal-oriented scenario?............................................101

Did I achieve my goal? ......................................................................104

Table of Contents

5 How does an analysis session work? .................................................106

How do I start my analysis session?..................................................107

The Analysis Window at a Glance ....................................................108

Did I reach my goals? ........................................................................110

Did my server perform well? .............................................................113

How can I pinpoint the source of the problem?...............................118

What other information can I gather about my scenario run?........122

How can I publish my findings? .......................................................124

Conclusion ........................................................................................127

Table of Contents

Welcome to the LoadRunner Tutorial, a self-paced printable guide, designed to lead you through the process of load testing and familiarize you with the LoadRunner testing environment. The first lesson provides an introduction to LoadRunner and testing concepts.

Lesson 2 provides a sample test that illustrates the power of the LoadRunnertool.

Lessons 3 through 6 describe how to create a script using the Mercury Virtual User Generator.

Lessons 7 through 9 explain how to design and run load tests using the LoadRunner Controller.

Lesson 10 introduces the Analysis tool, showing you how to create graphs and reports which will help you analyze your load test. At the conclusion of this tutorial, you will be ready to design, run, and monitor a simple test on your own application. It is recommended that you move through the tutorial in the order in which the information is presented. Welcome

Introducing LoadRunner While software development technologies have changed and matured tremendously in this time period, the complexity of modern applications has exploded. Applications may utilize tens and hundreds of components to do work once done with paper or by-hand. There is a direct correlation between the degree of application complexity and the number of potential points of failure in a business process. This makes it increasingly difficult to isolate the root cause of a problem.

Moreover, software applications aren’t like cars. They don’t have permanent parts that are replaced only when they wear out. Whether to deliver competitive advantage or to respond to changes in business conditions, software applications change weekly, monthly, and yearly. This stream of change introduces yet another set of risks that companies have to manage. The incredible pace of change and the explosion of software complexity introduce tremendous risk into the software development process. Rigorous performance testing is the most common strategy to both quantify and reduce this risk to a business. Automated load testing with Mercury LoadRunner is an essential part of the application deployment process.

LoadRunner Tutorial Automated Performance Testing is a discipline that leverages products, people, and processes to reduce the risks of application, upgrade, or patch deployment. At its core, automated performance testing is about applying production workloads to pre-deployment systems while simultaneously measuring system performance and end-user experience. A well-constructed performance test answers questions such as:

Does the application respond quickly enough for the intended users?  Will the application handle the expected user load and beyond? 

Will the application handle the number of transactions required by the business?

Is the application stable under expected and unexpected user loads? 

Are you sure that users will have a positive experience on go-live day?

By answering these questions, automated performance testing quantifies the impact of a change in business terms. This in turn makes clear the risks of deployment. An effective automated performance testing process helps you to make more informed release decisions, and prevents system downtime

and availability problems.

What are the LoadRunner components?

LoadRunner contains the following components:

The Virtual User Generator captures end-user business processes and creates an automated performance testing script, also known as a virtual user script.

The Controller organizes, drives, manages, and monitors the load test. 

The Load Generators create the load by running virtual users. 

The Analysis helps you view, dissect, and compare the performance results. 

The Launcher provides a single point of access for all of the LoadRunner components.

Lesson 1 • Introducing LoadRunner
A scenario is a file that defines the events that occur during each testing Scenarios session, based on performance requirements. In the scenario, LoadRunner replaces human users with virtual users or

Vusers emulate the actions of human users working with your application. A scenario can contain tens, hundreds, or even thousands of Vusers.

The actions that a Vuser performs during the scenario are described in a Vuser Scripts Vuser script.

To measure the performance of the server, you define transactions. A Transactionstransaction represents end-user business processes that you are interested in measuring.

What is the load testing process?

Load testing typically consists of five phases: planning, script creation, scenario definition, scenario execution, and results analysis.  Plan Load Test Cr eat e Vuser Scr i p t s Def i n e Scen ar i o An al yze Resul t s Run Scen ar i o Plan Load Test: Define your performance testing requirements, for example, number of concurrent users, typical business processes and required response times.

Create Vuser Scripts: Capture the end-user activities into automated scripts.

Define a Scenario: Use the LoadRunner Controller to set up the load test environment.

Run a Scenario: Drive, manage, and monitor the load test from the LoadRunner Controller.

Analyze the Results: Use LoadRunner Analysis to create graphs and reports, and evaluate the performance.

LoadRunner Tutorial To illustrate the Mercury solution, this tutorial uses sample performance

requirements for a sample application. This application, Mercury Tours, is a Web-based travel agency system. Mercury Tours users connect to a Web server, search for flights, book flights, and check flight itineraries.

While LoadRunner supports over 40 types of applications, this tutorial demonstrates load testing Web-based applications. If you are load testing applications that are not Web-based, please contact Mercury for assistance.

In this section, you will become familiar with the Mercury Tours application.

Opening Mercury Tours You will use the Mercury Tours application to experience hands-on

performance testing. Before proceeding with the tutorial, follow these steps to familiarize yourself with the look and feel of the application.

1 Make sure that the sample Web server is running. The Web server automatically starts after the LoadRunner installation and reboot. If you rebooted your system again, and the server is not running,

choose Start > Programs > Mercury LoadRunner > Samples > Web > Start Web Server.

Note: If you try to start the Web server and it is already running, an error message appears. You can disregard the message and continue with the Tutorial.

 2 Open the Mercury Tours application. Choose Start > Programs > Mercury LoadRunner > Samples > Web > Mercury Web Tours Application. A browser opens with the Mercury Tours opening page.

Type in the following information: Member name: jojo Password: bean

Click login in the left pane. Mercury Tours welcomes you to the application.

 4 Reserve a flight. Click Flights in the left pane. The Find Flight page opens. Change the

Destination to Los Angeles. Click continue.

 5 End your Mercury Tours session. Click Sign Off to log off. Application Requirements

Now that you are familiar with Mercury Tours, imagine that you are the performance engineer responsible for signing off that the application meets the needs of your business. Your project manager has given you 4 criteria for release:

 1 Mercury Tours must successfully handle 10 concurrent travel agents.

2 Mercury Tours must be able to process 10 simultaneous flight bookings with response time not exceeding 90 seconds.

 3 Mercury Tours must be able to handle 10 travel agents running simultaneous itinerary checks with response time not exceeding 120 seconds.

 4 Mercury Tours must be able to handle 10 agents signing in and signing out of the system with response time not exceeding 10 seconds. The tutorial will walk you through the process of building load tests that validate each business requirement, so that you can attach a pass or fail before release.

The Power of LoadRunner During the test, you will observe how the Web server behaves under load

using LoadRunner’s online monitors. In particular, you will see how an increase in load affects the time that it takes the server to respond to a user action (transaction response time) and causes errors.

After you have seen how LoadRunner can be used to generate load on a system and measure the responsiveness of the system to that load, you will learn how to use the LoadRunner components—VuGen, Controller, and Analysis—to create and run your own test, and analyze test results.

Note: LoadRunner allows you to purchase a license to use as many virtual users (Vusers) as you need to effectively test your application. For the purposes of this LoadRunner trial version, however, you are licensed to use 10 Vusers only.

LoadRunner Tutorial The Controller is the central console from which you build, manage, and

monitor your test. You will use the Controller to run a sample script that emulates the actions performed by a real user, and create load on the system by having a number of virtual users concurrently perform these actions.

 1 Open the Mercury LoadRunner window. Choose Start > Programs > Mercury LoadRunner > LoadRunner. The Mercury LoadRunner Launcher window opens.

Lesson 2 • The Power of LoadRunner

In the Load Testing tab, click Run Load Tests. By default, the LoadRunner

Controller opens with the New Scenario dialog box. Click Cancel.

 3 Open the sample test. Choose File > Open in the Controller menu, and open demo_scenario.lrs in

the <LoadRunner Installation>\Tutorial directory.

LoadRunner Tutorial

Scenario Groups section Design Tab

Note: If you didn’t install the tutorial to the default LoadRunner installation directory, the script path will be incorrect (indicated by the script path being displayed in red). To enter the correct path, select the script and click the down arrow. Click the Browse button and navigate to demo_script in the

<LoadRunner Installation>\Tutorial directory, and then click OK. You are now ready to run the test.

Click the Start Scenario button. The Controller run view is displayed, and the Controller begins the scenario. In the Scenario Groups pane, you can see as Vusers gradually start to run and generate load on the system. You can see the responsiveness of the server to the Vuser actions in the online graphs.

Start Scenario button Scenario Groups section Online Graphs area Run Tab Graph Measurements area

LoadRunner Tutorial While creating load on an application, you want to see how the application

performs in real time and where potential bottlenecks exist. You use LoadRunner’s suite of integrated monitors to measure the performance of every single tier, server, and component of the system during the load test. LoadRunner includes monitors for a variety of major backend system components including Web, application, network, database, and ERP/CRM servers.

 1 View the default graphs. By default, the Controller displays the Running Vusers, Transaction Response Time, Hits per Second, and Windows Resources graphs. The first three don’t require configuration. The Windows Resources monitor has been configured for you for this test. .

Running Vusers - Whole Scenario graph lets you monitor the number of Vusers that are running at a given time. You can see that the Vusers gradually start running at a rate of 2 Vusers every 1 minute.

Transaction Response Time - Whole Scenario graph lets you monitor the amount of time it takes for each transaction to be completed. You can see how long it takes for your customers to log on, search flights, purchase flights, check itineraries, and log off the system. You can see that as more and more Vusers work on the application under test, transaction response times increase and the level of service provided to the customer degrades.

Hits per Second - Whole Scenario graph lets you monitor the number of hits (HTTP requests) on the Web server made by Vusers during each second of the scenario run. This enables you to follow the amount of

load that is generated on the server. Windows Resources graph lets you monitor the Windows resource usage measured during a scenario (such as CPU, disk, or memory utilization). You will learn how to configure Windows Resources and other monitors in Lesson 7. Notice that each measurement appears on a color-coded row in the graph legend. Each row corresponds to a line in the graph with the same color.

Selecting a row highlights the corresponding line in the graph, and vice versa.

LoadRunner Tutorial

If your machine is handling a heavy load, you may encounter errors. Select the Errors Statistics graph in the Available Graphs tree, and drag it into the Windows Resources graph pane. The Error Statistics graph provides details about the number of errors and the time at which they occurred during the scenario. Errors are grouped by source—for example, the location in the script or the load generator name.

In this example, you can see that after 5 minutes, the system starts to encounter an increasing number of errors. These errors are caused by timeouts due to degrading response times.

Note: It will take your scenario a few minutes to run. You can go back and forth from the graphs to the Vusers as your scenario proceeds to display your results online.

Lesson 2 • The Power of LoadRunner At the conclusion of the test run, LoadRunner provides an in-depth analysis section composed of detailed graphs and reports. You can compare multiple graphs by combining results from several scenarios. Alternatively, you can use the Auto-correlate tool to merge all the graphs that contain data that could have had an effect on the response time, to pinpoint what was

happening at the moment the problem occurred. Using these graphs and reports, you can easily identify the bottlenecks in your application, and determine what changes need to be made to your system to improve its performance. You will learn how to use the Analysis tool in Lesson 10. You can open the Analysis with the scenario results by selecting Results >

Result Settings or clicking the Analyze Results button. The results are saved to the <LoadRunner installation>\Results\tutorial_demo_res directory. Where To Go From Here Now that you have discovered the power of LoadRunner’s automated testing process, you are ready to learn how to build a load-testing script, design and run your own test, and analyze the test results. The following lessons will

walk you through the process of achieving these results.

LoadRunner Tutorial

Building Scripts

In this lesson you will cover the following topics: Introducing the Virtual User Generator (VuGen)

How do I start recording user activities? 

Using VuGen Wizard Mode .

How do I record a business process to create a script?

How do I view the script? Introducing the Virtual User Generator (VuGen) In a testing environment, LoadRunner replaces human users at physical machines, with virtual users, or a Vusers. Vusers create load on a system by emulating actions of typical users in a repeatable and predictable manner.

The LoadRunner Virtual User Generator (VuGen) works on a record-andplayback principle. As you walk through a business process on your application, VuGen records your actions into automated scripts which will form the foundation of your load tests.

Note: If you have completed the Mercury LoadRunner Quick Start, you will notice that the script steps that you recorded there are identical to those that you will record in the following section. However, the overall recording process is explained here in greater detail.

LoadRunner Tutorial To begin recording user actions, you open VuGen and create a blank script.

You fill the blank script by recording events and adding manual enhancements.

In this section, you will open VuGen and create a blank Web script.

 1 Start LoadRunner. Choose Start > Programs > Mercury LoadRunner > LoadRunner. The Mercury LoadRunner Launcher window opens.

2 Open VuGen. In the Launcher window, click the Load Testing tab. Click Create/Edit Scripts. VuGen’s Start Page opens.

Lesson 3 • Building Scripts

Click New Vuser Script in the Scripts tab in the VuGen Start Page. The New Virtual User dialog box opens, displaying the options for a new single protocol script. A protocol is the language that your client uses to communicate with the back-end of the system. Mercury Tours is a Web-based application, so you

will create a Web virtual user script. Make sure the Category type is All Protocols. VuGen displays a list of all of the available protocols for a single protocol script. Scroll down the list, select

Web (HTTP/HTML), and click OK to create an empty Web script. Note: Advanced users can record several protocols during a single recording session in a multi-protocol script. In this tutorial, you create a single protocol script of Web type. The procedure for recording other types of single protocols or multi-protocol scripts is similar to the method you will use for recording a Web script.

LoadRunner Tutorial

The empty script opens in VuGen’s wizard mode with the Task pane displayed on the left. (If the task pane is not displayed click the Tasks button on the toolbar. If the start recording dialog box opens automatically, click Cancel).

VuGen’s wizard takes you through a step by step process of creating a script and then adapting it for your test environment. The Task pane lists each step or task in the script creation process. As you

proceed through each step, VuGen displays detailed instructions and guidelines in the main area of the window.

Toolbars

Task Pane

Instruction Pane

You can customize your VuGen window to show or hide the various toolbars. To show or hide a toolbar, choose View > Toolbars and toggle the check mark adjacent to the desired toolbar.

You return to the VuGen wizard at any stage by opening the task pane and clicking on one of the task steps.

The next step in creating user emulation, is recording the events performed by a real user. In the previous section, you created an empty Web script. Now you can begin to record events directly into the script. In this section, you will track the events of one passenger reserving a flight from Denver to

Los Angeles and then checking the flight itinerary.

To record the script:

 1 Start recording on the Mercury Tours Web site. Click Record Application in step 1 in the Task pane.

Click Start Recording at the bottom of the instruction pane. Alternatively you can choose Vuser > Start Record or click the Start Record button in the Toolbar at the top of the page.

 LoadRunner Tutorial

In the URL address box, type http://localhost:1080/MercuryWebTours/. In the Record into Action box, choose Action. Click OK. A new Web browser opens and displays the Mercury Tours site.

The floating Recording toolbar opens.

2 Log on to the Mercury Tours Web site. For the Member Name enter jojo and for the Password enter bean. Click Login. A welcome page opens.

 3 Enter flight details.

Click Flights. The Find Flight page opens: Departure City: Denver (default) 

Departure Date: Keep the default, current date 

Arrival City: Los Angeles 

Return Date: Keep the default, tomorrow’s date. 

Seating Preference: Aisle Keep the rest of the default settings and click Continue. The Search Results

page opens.

 4 Select a flight. Click Continue to accept the default flight selections. The Payment Details

page opens.

 5 Enter payment information and book flight. Enter 12345678 in the Credit Card box and type 06/06 in the Exp Date box. Click Continue. The Invoice page opens, displaying your invoice.

LoadRunner Tutorial

Click Itinerary in the left pane. The Itinerary page opens.

7 Click Sign Off in the left pane.

8 Click Stop on the floating toolbar to stop the recording process. The Code Generation pop up window opens while the Vuser script is being generated. The VuGen wizard then automatically proceeds to the next step in the task pane and displays the recording summary. (If you do not see the summary, click Recording Summary in the Task pane.)

The recording summary includes the protocol information and a list of the actions created during the session. For each step you performed during recording VuGen generated a snapshot, a picture of the window during recording. Thumbnails of these recorded snapshots are displayed in the right pane. If, for whatever reason, you want to rerecord your script, you can click the Record Again button at the bottom of the page.

9 Choose File > Save or click the Save button. Type basic_tutorial in the File name box and click Save. VuGen saves the file in the LoadRunner script folder and displays the test name in the title bar.

How do I view the script?

You have now recorded a travel agent logging in, booking a flight, and logging off. VuGen recorded your steps from the moment you clicked the Start Record button to the moment you clicked the Stop button.

You can now view the script inside VuGen. You can view the script in Tree view or Script view. Tree view is an icon-based view that lists the actions of the Vuser as steps while Script view is a text-based view that lists the actions of the Vuser as functions.

Tree View

To view the script in Tree view choose View > Tree View or click the Tree view button. To view the Tree View across the whole window, remove the Task pane by clicking the Task button.

Test Tree Snapshot

For each step you performed during recording, VuGen generated an icon and a title in the test tree. In Tree view, you see the actions of the user as script steps. Most steps are accompanied by a corresponding snapshot of the recording.

LoadRunner Tutorial

Click the plus (+) sign adjacent to any of the steps in the test tree. You now see the Think Time that was recorded while you were booking a flight. Think Time represents the actual time you waited between steps, and can be used to emulate fast and slow user behavior under load. Think time is a mechanism whereby you can make your load test more accurately reflect a real user’s behavior.

Script View

Script view is a text-based view that lists the actions of the Vuser as API

functions. To view the script in Script view choose View > Script View or

click the Script View. button. In Script view, VuGen shows the script in an editor with color coded

functions and their argument values. You can type C or LoadRunner API functions, as well as control flow statements, directly into this window.

VuGen

 Editor

Where To Go From Here

Now that you are familiar with recording and viewing a basic script, you can proceed to Lesson 4, Playing Back Your Script.

LoadRunner Tutorial

Playing Back Your Script

By recording a set of typical user actions such as booking a flight, you created a real user emulation. You replay your recorded script to verify that it runs properly before you incorporate it into a load testing scenario. During replay, you can view the actions in a browser and see if everything is

as you expect it be. If the script doesn’t replay properly, you may need to add correlation, as described in Lesson 5. Before replaying the script, you can configure run-time settings, which help

you set the behavior of the Vuser. In this lesson you will cover the following topics:

 How do I set the run-time behavior?

How do I watch my script running in real time? 

Where can I view information about the replay? 

How do I know if my test passed? 

How do I search in or filter the results?

How do I set the run-time behavior?

LoadRunner Run-Time settings let you emulate different kinds of real user activity and behavior. For example, you could emulate a user who responds immediately to output from the server, or a user who stops and thinks before each response. You can also configure run-time settings to specify how many times the Vuser should repeat a set of actions and how often. There are general run-time settings, and settings that are specific to certain Vuser types. For example, for a Web emulation, you could instruct your Vusers to replay your script in Netscape instead of Internet Explorer. Specific

settings will be covered in Lesson 6.

LoadRunner Tutorial .

Run Logic: the number of repetitions 

Pacing: the time to wait between repetitions

Think Time: the time the user stops to think between steps

Log: the level of information that you want to gather during playback Note that you can also modify the run-time settings from the LoadRunner Controller. This will be discussed in a later lesson.

 1 Open the run-time settings. Ensure that the Task pane is displayed (If not click the Task button). Click

Verify Replay in the task pane.

Under the heading Run Time Settings in the instruction pane click the Open Run-Time Settings hyperlink.

Alternatively you can press F4 or click the Run-Time Settings button in the toolbar. The Run-Time settings dialog box opens.

Lesson 4 • Playing Back Your Script

Select the Run Logic node. In this node you set the number of iterations, or the number of times to

repeat the activity in succession. Set the number of iterations to 2. 3 Set the Pacing settings. Select the Pacing node.

This node lets you control the time between iterations. You will specify a random time. This accurately emulates a real-life setting where the user waits between actions, but at random intervals—you don’t see real users waiting exactly 60 seconds between repetitions. Choose the third option and select the following: At random intervals every 60.00 to 90.00 seconds.

LoadRunner Tutorial

Select the Log node. The Log settings indicate how much information to log while running the test. During development, you may choose to enable some logging for debugging purposes, but once you verify that your script is functional, you can enable logging for errors only or disable it. Select Extended log and enable Parameter substitution. This option will be relevant for the following lesson at which point it will discussed.

 5 View the Think Time settings. Select the Think Time node.

6 Click OK to close the Run-Time Settings dialog box. How do I watch my script running in real time?

VuGen’s run-time viewer feature displays the Vuser activities in real time as you playback the recorded script. By default, VuGen runs your test in the background, without displaying an animation of the actions in your script. For this tutorial, however, you will instruct VuGen to display the actions in a viewer that lets you see how VuGen executes each step. The viewer is not an actual browser—it only

displays snapshots of the pages that are returned to the Vuser.

 1 Choose Tools > General Options and select the Display tab.

 2 Select the Show browser during replay and Auto arrange window options. Clear the Display report at the end of script execution option.

3 Click OK to close the General Options.

 4 Click Verify Replay in the task pane and then click the Start Replay button at the bottom of the instruction pane. Alternatively you can press F5 or click the Run button in the tool bar.

 5 If the Select Results Directory dialog box opens and ask you where you want to store the results directory, accept the default name and click OK.

LoadRunner Tutorial

Where can I view information about the replay?

When the script stops running, you can view a summary of the replay in the wizard. Click Verify Replay in the Task Pane to view the Last Replay Summary.

The Last Replay Summary, lists any errors that may have been detected and displays thumbnails of the Recording and Replay snapshots. You can compare snapshots and look for discrepancies between your recording and the replay. You can also look at the Vuser’s activity by reviewing a textual summary of

the events. VuGen’s Replay Log tab in the Output window shows this color-coded information.

To view the replay log:

 1 Click the replay log hyperlink in the instruction pane. Alternatively click the Show/Hide output button in the toolbar or choose View > Output Window from the menu. Then click the Replay Log tab.

2 Press Ctrl+F in the replay log to open the Find dialog box. Locate the following items:

Started, Terminated: the beginning and end of the script run—Virtual User Script Started, Vuser Terminated.

iteration: the beginning and end of the iteration and the iteration number (orange lettering).

VuGen displays successful steps in green and errors in red. For example, if your connection broke in the middle of the test, VuGen indicates the line number of the error and displays the whole line in red text.

 3 Double-click on a line in the replay log. VuGen takes you to the corresponding step in the script. A vertical black line on the left side of the script view indicates this step.

LoadRunner Tutorial

After you playback the events that you recorded, you need to look at the results and see if everything succeeded. If something failed, you want to know why and when it failed. In this section you will view and analyze the results of your script run. VuGen summarizes the results of the replay in the Test Results window.

To view test results:

 1 Click Verify Replay in the Task pane to return to the wizard.

 2 Click the visual test results hyperlink in the instruction pane under the heading: “Verification”. Alternatively choose View > Test Results. A new results window opens.

 The Tree pane contains the results tree. Each iteration is numbered. The Summary pane contains the details of the test. The top table indicates which iterations passed and which failed. The test is

considered to have passed when VuGen’s Vuser successfully navigates through the Mercury Tours site according to the original recording.

The bottom table indicates whether transactions and checkpoints passed or failed. You will add these features to your test later on in the tutorial.

In the next section, you will drill down into the test results to determine if the script reached the intended Web pages during replay.

How do I search in or filter the results?

If your test results indicate that something failed, you can drill down and locate the point of failure.

In the Test Results window, you can expand the test tree and view the results of each step separately. The Test Results window shows a snapshot of the replay during that iteration.

1 Expand an iteration branch.

Expand the branch Iteration 1 and then expand the Action Summary branch in the left pane by clicking the plus sign. The expanded branch now shows a list of the steps performed in that iteration.

LoadRunner Tutorial

Select the fourth step, Submit Form. The Test results window displays the replay snapshot associated with that step.

3 View the step summary. The top right pane of the Test Results window shows the step summary

information: the object or step name, the details about whether the page loaded successfully, the result (Passed, Failed, Done, or Warning), and the time that the step was performed.

In a case where the overall Results Summary indicates that the test failed, you need to determine where it failed. You can search the test results for the word Failed.

To Search the test results choose Tools > Find or click the Find button. The Find dialog box opens.

Select the Passed option, make sure no other options are selected, and click Find Next. The Results window shows the first step, where the status was Passed. Once again, choose Tools > Find or click the Find button. In the Find dialog box, select the Failed option, clear the Passed option, and click Find Next. The Results window cannot find any failed results.

LoadRunner Tutorial

You can filter the Test Results window to display a specific iteration or status. For example, you can filter it to show only Failed status. To filter the results choose View > Filters or click the Filter button. The

Filters dialog box opens. In the Status section, select the Fail option and clear all the other options. In

the Content section, select the All option and click OK. The left pane becomes empty, since there were no failures.

 6 Close the Test Results Window. Click File > Exit. Where To Go From Here You have now successfully run your test of the Mercury Tours application. You can proceed to Lesson 5, Solving Common Playback Problems.

Solving Common Playback Problems Many applications use dynamic values that change each time you use the application. For example, some servers assign a unique session ID for every

new session. When you try to replay a recorded session, the application creates a new session ID that differs from the recorded session ID.

LoadRunner addresses this issue through correlation. Correlation saves the changing values, in our case the session ID, to a parameter. When running the emulation, the Vuser does not use the recorded value—instead, it uses the new session ID, assigned to it by the server.

In this lesson you will observe how LoadRunner automatically solves the issue of dynamic values.

This lesson covers the following topics: 

Preparing Mercury Tours for Playback Errors .

 How do I work with unique server values?

LoadRunner Tutorial To illustrate a common playback failure, you need to modify a setting in the

Mercury Tours application. This setting tells the Mercury Tours Web Server not to allow duplicate session IDs.

 1 Open Mercury Tours. Choose Start > Programs > Mercury LoadRunner > Samples > Web > Mercury Web Tours Application. A browser opens with the Mercury Tours opening page.

 2 Change the server options. Click the administration link on the Mercury Web Tours opening page. The

administration page opens. Select the 3rd checkbox entitled: Set LOGIN form's action tag to an error

page. Scroll down to the bottom of the page and click Update. Scroll down to the bottom of the page and click the Return to the Mercury Tours Homepage link. This setting tells the server not to allow duplicate session IDs.

 3 Close the browser.

How do I work with unique server values?

In the modified configuration of Mercury Tours, the server assigns a unique session ID to the Vuser. If you try to play back the script, it will fail. To overcome this issue, you use VuGen to automatically detect the need to correlate the session ID. After you run the script, VuGen prompts you to scan the script for correlations.

Lesson 5 • Solving Common Playback Problems

 1 Record a new script with dynamic values. Record a new script with the same steps that you recorded previously in Lesson 3, (“How do I record a business process to create a script?” on page 21) and save the script as Basic_Tutorial_Cor.

 2 Replay the script. Click Verify Replay in the Task pane and click the Start Replay button at the

bottom of the instruction pane. VuGen runs the new script. You may notice several error messages in the Replay Log tab in the output window, indicated by the red-colored text.

 3 View the Replay Summary Click Verify Replay in the Task Pane to view the Last Replay Summary.

The summary shows that your script completed with errors.

LoadRunner Tutorial

Click the link Show and resolve dynamic server values in the instruction pane under the heading Dynamic Server Values. VuGen scans the script, searching for differences between the recorded values and the playback values. VuGen displays a list of these differences that may require correlation in the Correlation Results tab in the output window.

5 Correlate the Session ID. Select the first entry in the Correlation Results tab, and click Correlate. VuGen inserts a new step at the top of the script, that saves the original session ID to a parameter. In each replay session, VuGen saves the new unique session ID to a parameter. In the subsequent steps, it uses the saved value instead of the originally recorded value. Choose View > Tree View to view this new step in the test tree.

Choose View > Script View to view the correlation statement in the script. The statement that VuGen added to the script looks like this:

web_reg_save_param (“WCSParam_Diff1”, “LB=userSession value=”, “RB=>”, “Ord=1”, “RelFrameId=1.2.1”, “Search=Body”, LAST);

This statement means “Check the server response for data located between the following two strings” Left boundary userSession value= and right boundary >. Save the first occurrence of this data to a parameter called WCSParam_Diff1.”

 7 Play the script again. Choose Vuser > Run to replay the script again. When the replay ends,

choose View > Tree View. Look in the Replay Log tab. Note that VuGen no longer issues the red-colored error messages.

Right-click on the second step Service: Reg Save Param in the script and choose Go to step in Replay Log. VuGen places the cursor at the corresponding line in the replay log. The log indicates that function

web_reg_save_param succeeded, indicating that the correlation worked.

 8 Fix the server configuration. Reset the server to ignore unique session IDS. Choose Start > Programs > Mercury LoadRunner > Samples > Web > Mercury Web Tours Application to open Mercury tours. Click the administration link on the Mercury Web Tours opening page. In the administration page, clear the 3rd checkbox entitled: Set LOGIN form's action tag to an error page. Scroll down to the bottom of the page and click Update. Close the browser.

LoadRunner Tutorial

In this lesson, you scanned a script for correlations after recording the user actions.

VuGen also provides a set of configurable correlation rules to handle dynamic values during the recording session. For details on automatic correlation, refer to the Mercury Virtual User Generator User’s Guide.

Most servers have clear syntax rules, or contexts, that they use when creating links and referrals. If you are recording a session with a supported application server, you can use VuGen’s built-in correlation rules, and VuGen will detect and correlate the dynamic values during the recording stage. Where To Go From Here Now that you are familiar with some of the common playback problems, you can proceed to Lesson 6, Preparing a Script for Load Testing.

Preparing a Script for Load Testing

In the previous lessons, you verified that your script was an accurate emulation of your application. You watched the playback in real time and you verified that the Vuser performed a typical business process.

This, however, is true only for a single user emulation. Will the application work with many users working simultaneously? If so, will the application low down to an unacceptable level?

The next step, therefore, is to prepare the script for a load test and set it up to gather response time data. In this lesson you will learn about different methods to enhance the script and to make it more effective for the load testing process. This lesson covers the following topics:

How do I measure business processes?

How do I emulate multiple users?

How do I verify Web page content? 

How can I produce debugging information? 

Did my test succeed?

How do I measure business processes?

When preparing an application for deployment, you need to measure the duration of specific business processes—how long does it take to log in, book a flight, and so on. These business processes are normally made up of one or more steps or actions within your script. In LoadRunner, you designate a series of actions you want to measure by marking them as transactions.

LoadRunner Tutorial

You can manually insert a transaction anywhere in your script. The way to mark a user step as a transaction is to place a start transaction marker before the first step of the transaction and an end transaction marker after the last step.

In this section you will insert a transaction in your script to measure the amount of time it takes for the user to find and confirm a flight. Open the script Basic_Tutorial which you created in Lesson 3. If it is still

open you can select the tab displaying its name, otherwise you can open it from the File menu.

To insert a transaction:

 1 Open the Transaction Creation Wizard. Ensure that the Task pane is displayed (If not click the Task button). In the task pane under the heading Enhancements, click Transactions. The Transaction Creation wizard opens.

The Transaction Creation wizard displays thumbnails of the different steps in your script.

Lesson 6 • Preparing a Script for Load Testing

 2 Insert a start transaction and an end transaction marker. Using your mouse, place the marker before the third thumbnail entitled Search flights button and click. The wizard now prompts you to insert an

end point.

Using your mouse, place the marker after the fifth thumbnail entitled reservations.pl_2 and click.

 3 Specify a name for the transaction. The wizard prompts you to enter a name for the transaction. Type

find_confirm_flight and press ENTER. You have now created a new transaction. You can adjust the starting point or end point of the transaction by dragging the markers to different points in the script. You can also rename the transaction by clicking on the existing name above the start transaction marker and typing a new one.

LoadRunner Tutorial

Go to Tree view by choosing View > Tree View or by clicking on the Tree view button in the toolbar.

Notice how the Start Transaction and End Transaction markers have now been added to the tree as new steps at the precise points where you inserted them.

How do I emulate multiple users?

In your emulation, you tracked a user booking a flight and choosing an aisle seat. In a real-life setting, however, different users will have varying preferences. To improve your test, you therefore need to check if the booking will work when users choose different seating preferences (aisle, window, or none).

To accomplish this, you will parameterize the script. This means that you take the recorded value, Aisle, and replace it with a parameter. You will place values for the parameter in a parameter file. When you run the script, the Vuser will take values from the parameter file (aisle, window, or none) thereby emulating a true travel agency environment.

 1 Find the section where you want to vary the data. Go to Tree view by choosing View > Tree View.

In the Test Tree, double-click the Submit Data: reservations.pl step. The Submit Data Step Properties dialog box opens. The ABC icons in the right column indicates that the arguments are

constants.

 2 Indicate that the fixed value will be a varying value. Select the seatPref value in the seventh line, Aisle.

Click the ABC icon adjacent to Aisle. The Select or Create Parameter dialog box opens.

LoadRunner Tutorial

3 Create a parameter. Specify a parameter name, seat, using the File parameter type. Click OK.

VuGen replaces the ABC icon with a parameter icon.

 4 Click on the parameter icon adjacent to {seat}. Choose Parameter Properties from the popup menu. The Parameter Properties dialog box opens.

5 Specify some sample values to vary the data. Click Add Row. VuGen adds a row to the table. Replace the word Value with Window. Click Add Row. VuGen adds a row to the table. Replace the word Value with None.

Note that the values are not case sensitive. Keep the default settings in the Select column and File format sections of the dialog box.

6 Define how the test will vary the data. Keep the default setting that instructs VuGen to take sequential values for each iteration—not random values.

Select next row: Sequential Update value on: Each iteration

7 Click Close to close the Parameter Properties dialog box, and click OK to close the Step Properties dialog box. You have now created a parameter for the seating preference. When you run the load test, the Vusers will use the parameter values instead of the recorded value, Aisle. When you run the script, the replay log shows the parameter substitution that occurs for each iteration. You will see that for the first iteration, the Vuser chose Aisle and for the second iteration, the Vuser chose Window.

How do I verify Web page content?

When running a test, you often need to verify if certain content is found on the returned page. A content check verifies that expected information appears on a Web page while the script is running. You can insert two types of content checks: a text check and an image check.

A text check checks that a text string appears on a Web page.

An image check checks for an image on a Web page. Looking for Text In this section, you will add a text check that checks that the phrase "Find Flight" appears on the reservations page in your script. To insert a text check:

 1 Open the Content Check Wizard. Ensure that the Task pane is displayed (If not click the Task button). In the task pane under the heading Enhancements, click Content Checks.

LoadRunner Tutorial               

Select the Page View tab in the right pane to display snapshots of the thumbnails.

 2 Select the page containing the text you want to check. Click the fourth thumbnail entitled reservations.pl.

 3 Select the text that you want to check. Highlight the words Find Flight within the snapshot. With the words selected, right click and select Add a Text Check (web-reg-find).

The Find Text dialog box opens displaying the text you selected in the Search for specific Text box. Click OK.

 4 View the new step. In tree view (View > Tree View) you will notice that VuGen inserts a new

step, Service:Reg Find, into the script. This step registers the text check— LoadRunner checks for the text after running the step. During replay, VuGen will look for the text Find Flight and indicate in the replay log whether or not it was found.

In this section, you will insert an image check to verify that the image fmagateway.jpg appears on the page after the users log off. To insert an image check:

1 Choose View > Tree View to return to tree view.

 2 Select the page containing the image you want to check. Select the Image: SignOff Button step. Select the Page View tab in the right pane to view the step’s snapshot.

 3 Insert an image check step. Choose Insert > New Step. The Add Step dialog box opens.

Expand Web Checks and select Image Check. Click OK. The Image Check Properties dialog box opens.

LoadRunner Tutorial

In the Specification tab, check the option Image server file name, and enter the name of the image, fma-gateway.jpg, in the edit box. Click OK. Note that VuGen inserts the Image Check step as a sub-step of the

Image: SignOff Button step.

5 Save the script. During replay, VuGen will look for the image fma-gateway.jpg and indicate

in the replay log whether or not it was found.

How can I produce debugging information?

At certain points during the test run, you often need to send messages to the output, indicating your location and other information. These output messages will appear in both the replay log and in the Controller’s Output window. You can send a standard output message or a message that indicates that an error occurred. The recommended way to work with error messages is to check for a failed

status. If the status is failed, you instruct VuGen to issue an error message. Please refer to the examples in the Online Function Reference. In this section we will instruct VuGen to insert an output message after the application completes a full booking.

 1 Select a location. Select the last step, Image: SignOff Button. The snapshot opens on the right.

 2 Insert an Output message. Choose Insert > New Step. The Add Step dialog box opens. Scroll down and

select Output Message and click OK. The Output Message dialog box opens.

3 Type the message. Type The flight was booked into the Message Text box and click OK. The

Output Message is added to the tree.

 4 Save the script. Note: To insert an error message you would repeat the same process, except that you would select Error message instead of Output message in the Add Step dialog box.

LoadRunner Tutorial

In this section, you will run the enhanced script and view the replay log for text and image checks. You will view the text and image checks, the transactions, and the parameterization. By default, image checks are disabled during playback since they require more memory. If you want to perform an image check, you need to enable checks in the run-time settings.

 1 Enable image checks. Open the Run-Time settings (Vuser > Run-Time Settings) and select the Internet Protocol: Preferences node. Select the Enable image and text check option. Click OK to close the Run-Time Settings dialog box.

 2 Run the script.

Click the Run button or choose Vuser > Run. VuGen begins running the script, creating a replay log in the Output window. Wait for the script to finish running.

 3 Locate the text check. Ensure that the output window is open (View > Output Window). Click in

the Replay Log tab and press Ctrl+F to open the Find dialog box. Search for web_reg_find. The first instance says as follows: Registering web_reg_find was successful. This is not the actual text check—it only prepares VuGen to check for the text after the form submission. Search again (F3) for the next instance of web_reg_find. This instance indicates:

Registered web_reg_find successful for “Text=Welcome” (count=1).

This verifies that the text was found. If someone changes the Web page and removes the word Welcome, then in subsequent runs, the output will indicate that the text was not found.

4 Locate the image check. Press Ctrl+F and search for web_image_check. The search result indicates:

“web_image_check succeeded (1 occurrence(s) found. Alt=" ", Src="fmagateway.jpg")

This verifies that the image was found. If someone changes the Web page and removes the image, then in subsequent runs, the output will indicate that the image was not found.

5 Locate the beginning of a transaction. Click in the replay log and press Ctrl+F to open the Find dialog box. Search for the word Transaction. This notification is shown in blue.

6 View the parameter substitution. Click in the replay log and press Ctrl+F to open the Find dialog box. Search for the word Parameter. The log contains a notification “seat” = “Aisle”. Search again (F3) for the next substitution. Note how VuGen takes a different value for each iteration.

 7 Choose File > Save or click the Save button. Where To Go From Here Now that you have created a script and adapted it for a load test, you can proceed to Lesson 7, Creating a Load Testing Scenario. LoadRunner Tutorial

Creating a Load Testing Scenario

Creating a Load Testing Scenario

In this lesson you will cover the following topics:

 Introducing the LoadRunner Controller 

What mixture of users should be part of the load test?

The Controller Window at a Glance .

How do I generate a heavy load? 

How do I emulate real load behavior? 

How do I emulate different types of users? 

How do I monitor the system under load?

LoadRunner Tutorial

Load testing means testing your application under typical working conditions, for example, many travel agents reserving flights on the same flight reservation system at the same time. You design the test to emulate real-life situations. To do this, you need to be able to generate heavy load on an application and schedule when the load is applied (since users do not log on and off the system at precisely the same

time). You also need to emulate different kinds of user activity and behavior. For example, some users might be using Netscape instead of Internet Explorer to see the application’s performance, and using different network connections such as modem, DSL, or cable. You create and save these settings in a cenario. The Controller provides you with all the tools you need to help you build and run tests to accurately emulate your working environment.

Scenario Objectives In this lesson, the objective is to create a scenario that emulates the behavior of ten travel agents simultaneously logging on, searching flights, purchasing flights, checking itineraries, and logging off the system. Starting the Controller To begin creating a scenario, you open the Controller and create a new scenario.

 1 Open Mercury LoadRunner. Choose Start > Programs > Mercury LoadRunner > LoadRunner. The

Mercury LoadRunner Launcher window opens.

Lesson 7 • Creating a Load Testing Scenario

In the Load Testing tab, click Run Load Tests. The LoadRunner Controller opens.

By default, the Controller opens with the New Scenario dialog box.

3 Select a Scenario Type. Select Manual Scenario. A Manual Scenario gives you control over the number of running Vusers and the times at which they run, and lets you test how many Vusers your

application can run simultaneously. You can use the Percentage Mode to distribute the total number of Vusers among scripts based on a percentage specified by your business analyst.

A Goal-Oriented Scenario is used to determine if your system can achieve a particular goal. You determine the goal based on, for example, a specified transaction response time or number of hits/transactions per second, and LoadRunner automatically builds a scenario for you based on these goals. You will create a goal-oriented scenario in Lesson 9, Advanced Goal-Oriented Scenario.

LoadRunner Tutorial

In this tutorial, you will use just one Vuser script to model a single group of users performing identical actions. To emulate a real scenario with a more varied mix of user profiles, you would create different groups running several scripts with different user settings. The script that you previously recorded in VuGen contains the business processes that you want to test. They include logging on, searching for a

flight, buying a ticket, checking the flight itinerary, and then logging off the site. You will add a similar script to the scenario, and configure the scenario to emulate eight travel agents simultaneously performing these actions on the flight reservation system. You will add two more users during the test itself.

 1 Add a script to the load test. For the purpose of this tutorial, a script is provided that is similar to the one you created. We recommend that you use the sample cript. Click the Browse button, and navigate to basic_script in the <LoadRunner Installation>\Tutorial directory. The script is displayed in the Available Scripts section and in the Scripts in Scenario section. Click OK. The LoadRunner Controller opens your scenario in the Design tab.

 2 Begin designing the load test scenario. Check to see that the basic_script appears in the Group Name column of the Scenario Groups window.

3 Change the Group Name and number of Vusers. Click the Details button. The Group Information dialog box opens. In the Group Name box, enter a more meaningful name, for example travel_agent.

In the Vuser Quantity box, enter 8. This is the number of Vusers that will run on the Localhost load generator.

Click OK. The scenario settings are displayed in the Controller window.

LoadRunner Tutorial

The Controller window’s Design tab contains two primary sections:

Scenario Schedule 

Scenario Groups

Design Tab

Scenario Groups

section (Manual Scenario)

Scenario Schedule section (Manual Scenario)

Edit Scenario

Schedule

Scenario Schedule: In the Scenario Schedule section, you set the load behavior to accurately portray user behavior. You determine the rate at which load is applied to the application, the load test duration, ad how the load is stopped.

Scenario Groups: You configure the Vuser groups in the Scenario Groups section. You create different groups to represent typical users of your system. You define the actions that they will run, the number of Vusers that will run, and the machine that they will run on.

After you have added your scripts and defined the number of Vusers that you want to run in the scenario, you can configure the load generator machines. Load generators are the machines that create load on the application by running Vusers. You can use a number of load generator machines, each

hosting many virtual users. In this section, you will learn about adding load generators to the scenario and testing the load generator connection.

1 Add a load generator.

Click the Generators button. The Load Generators dialog box opens, showing details for the localhost load generator machine.

In this tutorial, you will use your local computer as the load generator (included in the scenario by default). The status of the localhost load generator is Down. This indicates that the Controller is not connected to the load generator.

Note: In a typical production system, you would have a few load generator machines, each hosting many Vusers. You would add additional machines by clicking the Add button in the Load Generators dialog box, and entering the machine name and platform type in the Add New Load Generator dialog

box.

LoadRunner Tutorial

When you run a scenario, the Controller connects to the load generators automatically. However, you can test the connections before trying to run a scenario.

Select the localhost load generator and click Connect. The Controller attempts to connect to the load generator machine. When a connection has been made, the status changes from Down to Ready.

Click Close.

How do I emulate real load behavior?

After you have added your load generator machines, you are ready to configure load behavior.

Typical users do not log on and off the system at precisely the same time. LoadRunner allows users to gradually log on to and off the system. It also lets you determine the duration of the load test, and the way in which the scenario is stopped.

You will now change the default load settings using the Controller Schedule Builder.

1 Change the Scenario Schedule default settings. Click the Edit Schedule button. The Schedule Builder opens.

 2 Specify a gradual start. Starting Vusers at intervals allows you to examine the gradual increase of

Vuser load on the site over time, and helps you pinpoint the exact point at which a system response time slows down. In the Ramp Up tab, change the settings to: Start 2 Vusers every 30 seconds.

LoadRunner Tutorial

Initialization means preparing the Vusers and the load generators for a load test run. Initializing Vusers before ramp up reduces CPU consumption and helps provide more realistic results.

Select Initialize all Vusers before Run.

4 Schedule the duration. You specify a duration to make sure that the Vusers continue performing the business processes for a specific duration so you can measure continuous load on the server. Note that if you set a duration, the test will run for as many iterations as necessary for the duration, disregarding the number of iterations set in the test’s run-time settings.

In the Duration tab, change the settings to: Run for 10 minutes after the ramp up has been completed.

5 Schedule a gradual closure. Gradually stopping Vusers is recommended to help detect memory leaks

and check system recovery, after the application has reached a threshold. In the Ramp Down tab, change the settings to: Stop 2 Vusers every 30 seconds.

The Load Preview graph shows the ramp up, duration, and ramp down for the scenario profile that you defined. Click OK.

LoadRunner Tutorial Now that you have configured load behavior, you will specify how your

Vusers will behave during the test. When emulating a real user, you need to consider the user’s actual behavior. Behavior refers to the time that a user takes to pause between actions, the number of times he repeats an action, and so on. In this section, you will learn more about LoadRunner’s run-time settings, and you will enable think time and logging.

 1 Open the Run-Time settings.

In the Design tab, select the script and click the Run-Time Settings button. The Run-Time settings are displayed. The Run-Time settings let you emulate different kinds of user activity and behavior. They include:  

Run Logic: the number of times a user repeats a set of actions Pacing: the time to wait before repeating the action

Log: the level of information that you want to gather during the test The first time you run a scenario, it is recommended to generate log messages to make sure that you have debugging information in case the first run fails.  

Think Time: the time the user stops to think between steps Since users interact with the application according to their experience level and objectives, more technically proficient users may work more

quickly than new users. Vusers can be made to emulate their real-world counterparts more accurately during a load test by enabling think time.

Speed Simulation: users using different network connections such as odem, DSL, and cable .

Browser Emulation: users using different browsers to see their application’s performance .

Content Check: for automatically detecting user-defined errors Suppose that your application sends a custom page when an error occurs. This custom page always contains the words “ASP Error”. You need to search all of the pages returned by the server and see if the text “ASP Error” appears.

You can set up LoadRunner to automatically look for this text during the test run, using the Content Check run-time settings. LoadRunner searches for the text and generates an error if it is detected. During the scenario run, you can clearly identify the content check errors.

LoadRunner Tutorial

Select the General:Think Time node. Select Replay think time, and select the Use random percentage of recorded think time option. Specify a minimum of 50% and a maximum of 150%.

You use a random percentage of the recorded think time to emulate users with a varying range of proficiency. For example, if the recorded think time for selecting a flight was 4 seconds, the random think time could be anything between 2-6 seconds (50% to 150% of 4).

 3 Enable logging. Select the General:Log node, and choose Enable logging. In the Log options, select Always send messages. Choose Extended log, and select Data returned by server.

Click OK to close the Run-Time settings.

How do I monitor the system under load?

Now that you have defined how your Vusers will behave during the test, you are ready to set up your monitors. While creating heavy load on an application, you want to see how the application performs in real time and where potential bottlenecks exist. You use LoadRunner’s suite of integrated monitors to measure the performance of every single tier, server, and component of the system during the load test. LoadRunner includes monitors for a variety of major backend system components including Web, application, database, and ERP/CRM servers.

For instance, you can select a Web Server Resources monitor according to the type of Web server that is running. You can purchase a license for the relevant monitor, for example IIS, and use this monitor to pinpoint problems reflected in the IIS resources. In this section, you will learn how to add and configure the Windows Resources monitor. You can use this monitor to determine the impact of load on your CPU, disk, and memory resources.

LoadRunner Tutorial

Click the Run tab in the Controller window to open the run view. The Windows Resources graph is one of four default graphs that is displayed in the graph viewing area. You will learn how to open other graphs in the next lesson.

Right-click the Windows Resources graph and choose Add Measurements. The Windows Resources dialog box opens.

In the Monitored Server Machines section of the Windows Resources dialog box, click Add. The Add Machine dialog box opens.

Type localhost in the Name box. (If your load generator was running off a different machine you would type the server name or IP address of that machine.) In the Platform box, enter the platform on which the machine runs. Click OK.

The default Windows Resources measurements are displayed in the Resource Measurements on <server machine> pane.

3 Activate the monitor. Click OK in the Windows Resources dialog box to activate the monitor.

Where To Go From Here Now that you have designed a load test scenario, you can proceed to

Lesson 8, Running The Load Test.

LoadRunner Tutorial

Running The Load Test

When you run the test, LoadRunner creates load on the application. You can then use LoadRunner’s monitors and graphs to observe the performance of the application under real-life conditions. In this lesson you will cover the following topics:  

The Controller Run View at a Glance .

How do I run a load test scenario?  

How do I monitor the application under load?  

How do I watch a user running in real time?  

Where can I view a summary of user actions?  

How can I increase the load during the test?  

How is the application coping under load?  

Did the application encounter errors?  

How do I know that the test has finished running?  

Did the application perform well under load?

LoadRunner Tutorial

The Run tab in the Controller window is the control center from which the test is managed and monitored. The Run view contains five main sections:  

Scenario Groups  

Scenario Status  

Available Graphs Tree  

Graph Viewing Area  

Graph Legend

Scenario Groups Scenario Status

Graph Viewing area

Graph Legend

Available Graphs Tree

Lesson 8 • Running The Load Test

Scenario Status: In the upper-right pane, you can view a summary of the load test, including the number of running Vusers and the status of each Vuser action. Available Graphs Tree: In the middle-left pane, you can see a list of the LoadRunner graphs. To open a graph, select a graph in the tree, and drag it

into the graph viewing area. Graph Viewing Area: In the middle-right pane, you can customize the display to view between one and eight graphs (View > View Graphs). Graph Legend: In the lower pane, you can view data from the selected graph.

How do I run a load test scenario?

In this section, you will start the scenario.

 1 Open the Controller Run view. Select the Run tab at the bottom of the screen. Notice that there are 8 Vusers in the Down column of the Scenario Groups area. These are the Vusers you created when you created the scenario. Since the scenario has not yet run, all other counters remain at zero and all

the graphs in the graph viewing area (except Windows Resources) are blank. When you start the scenario in the next step, the graphs and counters will begin to display information.

LoadRunner Tutorial

2 Start the scenario. Click the Start Scenario button or choose Start >Scenario to begin running

the test. If you are running the tutorial for the first time, the Controller begins the scenario. The result files are saved automatically to the load generator’s temp directory. If you are repeating the test, you will be prompted to overwrite the existing results file. Click No, since the results of the first load test should be used as baseline results to be compared with subsequent load test results.

The Set Results Directory dialog box opens.

Specify a new results directory. Enter a unique and meaningful name for each results set, since you may want to superimpose the results of several scenario runs when you come to analyze the graphs. You use the Controller’s online graphs to view performance data collected by the monitors. You use this information to isolate potential problem areas in your system environment.

 1 Examine the Performance graphs. The Run tab displays the following default online graphs:

Running Vusers - Whole Scenario graph displays the number of Vusers running at a given time. Transaction Response Time - Whole Scenario graph shows the amount of time it takes for each transaction to be completed. Hits per Second - Whole Scenario graph displays the number of hits (HTTP

requests) made to the Web server by Vusers during each seond of the scenario run.

Windows Resources graph displays the Windows resources measured during a scenario.

 2 Highlight individual measurements. Double-click the Windows Resources graph pane to enlarge it. Notice that each measurement appears on a color-coded row in the graph legend. Each row corresponds to a line in the graph with the same color.

Selecting a row highlights the corresponding line in the graph, and vice versa. Double-click the graph again to reduce it. Select the Throughput graph in the Available Graphs tree, and drag it into

the graph viewing area. The Throughput graph measurements are displayed in the display window and the graph legend. The Throughput graph shows the amount of data (measured in bytes) that the Vusers receive from the server at any given second. You can compare this graph with the Transaction Response Time graph to see how throughput affects transaction performance.

If the throughput scales upward as time progresses and the number of Vusers increases, this indicates that the bandwidth is sufficient. If the graph were to remain relatively flat as the number of Vusers ncreased, it would be reasonable to conclude that the bandwidth is constraining the volume of

data delivered.

When emulating users, you should be able to view their actions in real time and make sure they are performing the right steps. The Controller lets you view the actions in real time using the run-time viewer. To visually observe the Vuser’s actions:

1 Click the Vusers button. The Vusers window opens.

The status column displays the status of each Vuser. You can see in the example above that four Vusers are Running and four are in the Down status. The Ramp Up scheduling instructed the Controller to release two Vusers at a time. As the scenario progresses, Vusers will continue to be aded in groups of two at 30-second intervals.

2 Select a running Vuser in the Vuser list.

3 Click the Show the selected Vusers button on the Vusers toolbar. The Run-Time Viewer opens and displays the action currently being performed by the selected Vuser. The window is updated as the Vuser proceeds through the steps of the recorded scenario.

4 Click the Hide the selected Vusers button on the Vusers toolbar to close the Run-Time Viewer log.

LoadRunner Tutorial

To check the progress of an individual Vuser during a running test, you can view a log file containing a text summary of the Vuser’s actions. To review a text summary of the events:

Select a running Vuser in the Vusers window, and click the Show Vuser Log button. The Vuser log window opens. The log contains messages that correspond to the actions of the Vuser. For

example, in the window above, the message “Virtual User Script started” indicates the start of the scenario. Scroll to the bottom of the log and watch as new messages are added for each action performed by the selected Vuser.

Note: The Vuser log will only contain information if you enabled the logging feature in the Run-Time Settings Log tab. Close the Vuser log window and the Vusers window.

You can increase the load on the application during a running load test by manually adding more Vusers.

To increase load during a load test:

1 Click the Run/Stop Vusers button. The Run/Stop Vuser dialog box opens displaying the number of Vusers currently assigned to run in the scenario.

 2 In the # column, enter the number of additional Vusers to the group that you want to add. To run 2 additional Vusers, replace the number 8 with the number 2, in the # column.

 3 Click Run to add the Vusers. If some of the Vusers have not yet been initialized, the Run Initialized and

Run New options open. Select the Run New option.

These 2 additional Vusers are distributed to the travel_agent group and are run on the localhost load generator. The Scenario Status window shows thatthere are now 10 running Vusers.

Note: You may get a warning message that LoadRunner Controller cannot activate additional Vusers. This is caused by the fact that you are using your local machine as a load generator and it has very limited memory resources. In most situations you would use a dedicated machine as a load generator to

avoid such problems.

LoadRunner Tutorial

Check the Scenario Status window for a synopsis of the running scenario, and drill down to see which Vuser actions are causing the application problems. A high proportion of failed transactions and errors indicates that the application is not performing as expected under load.

1 View the test status. The Scenario Status window displays the overall status of the scenario.

2 View breakdown of Vuser actions. Click the Passed Transactions link in the Scenario Status window to view a list of transaction details. The Transactions dialog box opens.

If an application starts to fail under heavy load, you are likely to encounter errors and failed transactions. The Controller displays error messages in the Output window.

 1 Check for any error messages. Click View > Show Output or click the Errors link in the Scenario Status

window.

The Output window opens and lists a message text, the total number of messages generated, the Vusers and load generators that generated the error, and the scripts in which the errors occurred.

To view a message in detail, select the message and click Details. The Detailed Message Text box opens, displaying the complete message text. The example below shows a timeout error. The Web server is not responding to a request within a given time period.

LoadRunner Tutorial

You can view information about each message, Vuser, script, and load generator associated with an error code by clicking the blue link in the appropriate column. For example, to locate where in the script an error occurs, drill down on the Total Messages column. The Output window displays a list of all messages of the selected error code, including the time, iteration number, and line in the script where the error occurred.

Drill down on the Line Number column. VuGen opens displaying the line in the script at which the error occurred. You can use this information to identify transactions with slow response times that are causing the application to fail under load.

At the conclusion of the test run, the Scenario Status window shows the Down status. This indicates that the Vusers have stopped running. You can look in the Vuser window to see the status of each individual Vuser. LoadRunner displays the number of times a Vuser repeated a task (iteration), the number of successful iterations, and the elapsed time.

Did the application perform well under load?

To see how well the application performed under load, you need to look at the transaction response time and determine whether the transaction was within an acceptable limit for the customer. If the transaction response time degrades, you need to look for bottlenecks. You will learn more about this in

Lesson 10, “Analyzing your scenario.” Once a problem has been isolated, a corroborative effort involving

developers, DBAs, network, and other systems experts is required to fix the bottleneck. After adjustments are made, the load test is repeated to confirm that the adjustments had the desired effect. You repeat this cycle to optimize system performance. To save the scenario so that you can run it again with the same settings,

click File > Save or click the Save button, and enter a scenario name in the File name box.

Where To Go From Here

Now that you have learned how to run and view a simple load test scenario, you can proceed to Lesson 9, Advanced Goal-Oriented Scenario.

LoadRunner Tutorial

Advanced Goal-Oriented Scenario In the previous two lessons you learned how to manually create and run a load test. In this lesson, you will define a goal that you want your test to achieve.

Before deploying an application, you want to run an acceptance test to make sure that the system will stand up to the expected real-life workload. You have a rate at which you expect the server should perform, defined, for example, by the number of hits or transactions per second. This rate might

be determined by a business analyst defining the requirements for the application, or it might be taken from previous versions of the application in production, or other sources. You set a goal for the number of hits per second, transactions per second, or the transaction response time that you want to generate, and LoadRunner automatically generates the required goal for you, using the goal-oriented scenario. While the application is under constant load, you can monitor the transaction response time to see the

level of service provided to the customer.

In this lesson, you will create a goal-oriented scenario to generate three hits per second on your Web server, and to maintain this level of load for five minutes using a minimum of five Vusers and a aximum of ten. In this lesson you will cover the following topics:  

Which goal type should I use?  

How do I create a goal-oriented scenario?

The Controller Window at a Glance (Goal-Oriented Scenario)  

How do I define the goal?  

How do I determine load behavior?  

Which online graphs should I monitor?  

How do I run a goal-oriented scenario?  

Did I achieve my goal?

LoadRunner Tutorial

LoadRunner provides you with five different types of goals in a goal-oriented scenario: the number of concurrent Vusers, the number of hits per second, the number of transactions per second, the number of pages per minute, or the transaction response time that you want your scenario to reach.

If you know the total number of Vusers that can run your various business processes, you can use a Virtual Users goal type.  

If you know the strength of your server, you can use a Hits per Second, Pages per Minute, or Transactions per Second goal type.  

If you know the desired response time for completing a transaction, you can use a Transaction Response Time goal type. For example, if you do not want a customer to wait more than five seconds to log in to your e-commerce site, specify a maximum acceptable transaction response time of five seconds, and see how many actual Vusers can be served.

Lesson 9 • Advanced Goal-Oriented Scenario

To emulate a real-life system with a mix of user profiles, you can assign several scripts to the scenario and assign a percentage of the load between them. You should set the percentage according to the expected load. In this tutorial, you will use just one Vuser script to model a single group of users performing identical actions.

 1 Create a new scenario. Choose File > New, or click New, to open the New Scenario dialog box.

2 Select the scenario type. Select the Goal-Oriented Scenario option.

 3 Choose a script. Select basic_script from the Available Scripts list, and click the Add button.

The script is displayed in the Scripts in Scenario pane. Click OK. The LoadRunner Controller design view opens displaying the basic_script in the Script Name column.

LoadRunner Tutorial

The Controller window (goal-oriented) Design view contains two primary sections:

Scenario Goal  

Scenario Scripts

Design Tab

Scenario Scripts

section

Scenario Goal

section

Edit Scenario

Goal

Scenario Goal: In the upper pane, you can see your testing goal, the number of users that you want to use to reach that goal, the scenario duration, and load behavior. You define the goal settings from the Edit Scenario Goal dialog box.

Scenario Scripts: In the lower pane, you determine the Vuser scripts, their paths, the percentage of the total target assigned to each script, and the load generator machines. You configure the scenario settings from here.

Now that you have selected a script to run, you need to define the goal that you want to achieve.

In this section, you will create a goal profile, and define the scenario goal.

 1 Open the Edit Scenario Goal dialog box. lick the Edit Scenario Goal button or select Scenario > Goal Definition. The Edit Scenario Goal dialog box opens.

2 Specify a logical name for the Goal Profile. Click New, type the new goal profile name (for example: Hits per Second 3) in the New Goal Profile dialog box, and click OK. The new goal profile name appears in the selector.

3 Define the scenario goal. In the Goal Type box, select Hits per Second. In the Reach Goal of X Hits per Second box, enter 3.

 4 Set the minimum-maximum range of Vusers for LoadRunner to run. Enter 5 as the minimum and 10 as the maximum number of Vusers. This corresponds with the minimum-maximum range of travel agents that you want to create hits on the server simultaneously.

How do I determine load behavior?

Now that you have defined the test goal, you need to specify how and when you want the Controller to reach your target. Users do not log on and off the system at precisely the same time. To

emulate real users, LoadRunner provides the capability in the Load Behavior tab for users to gradually log on and off the system. You also want the server to remain under the load for a period of time. LoadRunner lets you specify in the Scenario Settings tab the time that the server remains under load.

To define load test behavior:

 1 In the Edit Scenario Goal dialog box, select the Load Behavior tab, and select Automatic. This instructs the Controller to run the required number of Vusers simultaneously.

Specify that the test should run for 5 minutes after the target has been achieved, and select Continue scenario without reaching goal. Once the load of three hits per second has been reached, the Controller

keeps running the scenario for an additional five minutes, adding or subtracting Vusers as needed to keep the actual measurement within 6% of the specified target. This is to ensure that the server can sustain the load for a period of time.

 3 Do not use recorded think time. In the lower-left corner of the Edit Scenario Goal dialog box, ensure that Do not change recorded think time is disabled. If you enable this option, LoadRunner runs the scenario using the think time recorded in your script, and you may need to increase the number of

Vusers in your scenario in order to reach your target.

LoadRunner Tutorial

Click OK to close the Edit Scenario Goal dialog box. The scenario target information you entered appears in the Scenario Goal window.

Which online graphs should I monitor?

After you have defined the test goal and load behavior, you are ready to configure the LoadRunner monitors. In this test, you should monitor the Hits per Second graph to follow the load that is generated on the server. You also want to monitor the Transaction Response Time graph to see what response times your customers will have when the server is under load. In addition, you can monitor the effect of load on the Throughput and Windows Resources graphs. The Hits per Second, Transaction Response Time, and Throughput monitors have been configured for you. To configure the Windows Resources

monitor, follow the procedures in Lesson 7.

Now that you have configured the scenario and goal settings, you are ready to start the test and monitor the application under load. In this section you will run your goal-oriented scenario and examine the test behavior.

1 Open the Controller window’s Run tab. Select the Run tab at the bottom of the screen. Since the scenario has not run yet, all the counters remain at zero and the graphs are blank. When you start the scenario in the next step, the graphs and counters will begin to display information.

 2 Specify a name for the Results directory. Choose Results > Results Settings to open the Set Results Directory dialog box, and enter a unique name for the result set (for example: travel_agent_3hps).

 3 Start the scenario Click the Start Scenario button or choose Scenario > StartThe Controller begins the scenario. You will see that 5 Vusers are ramped up and start running, as LoadRunner attempts to generate the required goal of three hits per second. During the test, the Controller automatically starts and stops Vusers to maintain the given goal.

LoadRunner Tutorial

The Hits per Second graph shows the number of hits (HTTP requests) made to the Web server by Vusers during each second of the scenario run. You can see that after a short period the required level of load is reached. The Transaction Response Time graph shows the amount of time it takes for each transaction to be completed. It is very important to watch transaction response time to see the response times your customers will have when the server is under load.

You can monitor the server’s Windows Resources usage for processor, disk, or memory utilization problems. Monitoring during a test can help you pinpoint the source of poor performance immediately.

LoadRunner Tutorial

Did I achieve my goal?

The objective of this lesson was to make sure that the system would provide an acceptable level of service to the customer under expected real-life workload. To emulate such conditions, you set a load target of three hits per second for the duration of the scenario, when running a minimum of five and maximum of ten Vusers. If three hits are made by Vusers on the server during each second of the scenario run when running between five and ten Vusers, then your goal parameters have been chieved. If your target of three hits per second is not reached, LoadRunner displays a message that the target you defined cannot be achieved. Note: Since the license limits you to running a maximum of ten Vusers, your goal might not be reached.

After you have run the test, you should save the scenario settings for future use. To save the scenario, click File > Save or click the Save button and enter a scenario name in the File name box.

Where To Go From Here Now that you have designed and run a goal-oriented scenario, you can

proceed to Lesson 10, Analyzing Your Scenario.

10 Analyzing Your Scenario In the previous lessons you learned how to design, control, and execute a

scenario run. Once you have loaded your server, you want to analyze therun, and pinpoint the problems that need to be eliminated to improve system performance.

The graphs and reports produced during your analysis session present important information about the performance of your scenario. Using these graphs and reports, you can easily pinpoint and identify the bottlenecks in your application, and determine what changes need to be made to your system to improve its performance. In this lesson you will cover the following topics: .

How does an analysis session work?  

How do I start my analysis session?  

The Analysis Window at a Glance

 Did I reach my goals?  

Did my server perform well?  

How can I pinpoint the source of the problem?  

What other information can I gather about my scenario run?  

How can I publish my findings?