Configuring Run time settings

General – Run Logic:

This lets you control the number of iterations. In simple terms it will decide how many times the vuser has to run / execute.

General – Pacing: This lets you decide how the different iterations have to run, how to control the time between the iterations.

As soon as the previous iteration ends:

If you choose this setting the next iteration begins immediately after the previous iteration ends.

After the previous iteration ends with a fixed or random delay of:

• New iteration is started after fixed delay of x secs only after the previous iteration ends.
• New iteration is started after random delay of x secs only after the previous iteration ends. The range of the random delay can be chosen.

At fixed or random intervals, every ... [to ...] seconds:

New Iteration begins every x seconds or at random rate. Each scheduled iteration will only begin when the previous iteration is complete. For example, assume that you specify to start a new iteration every four seconds:

• If the first iteration takes three seconds, the Vuser waits one second.
• If the first iteration takes two seconds to complete, the Vuser waits two seconds.
• If the first iteration takes 8 seconds to complete, the second iteration will start 8 seconds after the first iteration began. VuGen displays a message in the Execution Log to indicate that the iteration pacing could not be achieved.

See the log below:

Log:

Log files are very much required for debugging and correlation. Turning on the logs till you develop and fix your script helps you a lot. Log contains all the requests and responses made between client and the server.This is stored in a file called output.txt. You can either choose standard or extended log depending on how much information you want to log to output.You can enable and disable logging as and when required. When you have clean working script and running in the controller for volume /stress or load test its better to disable the logging .You can enable logging only when errors occurs.When you choose this you can set the size of log cache

Standard Log:

Creates a standard log of functions and messages sent during script execution to use for debugging

Extended Log:

Creates an extended log, including warnings and other messages. You can specify which additional information should be added to the extended log using the Extended log options:

• Parameter substitution: This option will log all parameters associted with the script along with their values.
• Data returned by server: This option will log all of the data returned by the server.
• Advanced trace: This option will log all of the functions and messages sent by the Vuser during the session. This option is useful when you debug a Vuser script.

Note:To get extended log for a section of you script during execution you should use lr_set_debug_message function to set the Extended log. You must call the function again to specify what type of extended mode (Parameter, Result Data, or Full Trace). Return to the Standard log mode by calling lr_set_debug_message,

Think Time:

This allows you to Ignore think time or replay think time. Think time in simple words means wait, wait for the specified time that has been defined in the script. Think time is very important in performance testing to emulate a real user. Consider an example where real user is checking mails, there might be some real fast user who logs into mail, checks mail. There might be some slow user who logs into mail, does wait or think before he checks mails. So in these kind of situations think times and pacing comes handy for emulating real users. To tell Vuser script to hold execution for some time we use think times.

Ignore Think time:

This completely ignores the think time even if a think time statement is recorded in the script.

Replay Think time:

As Recorded: Choosing this option wil make the vuser script wait for the specified think time in the script which is inserted either by recording or manually after recording. lr_think_time(5);

• Multiply recorded think time by: This option lets you multiply the think time present in the script by the value you specify. If you increase or decrease it. This is pretty straight forward.
• Use random percentage of the recorded think time:This option lets you choose the range of percentage that will be applied on the think time present in the script. For example, if the think time argument is 2, and you specify a minimum of 50% and a maximum of 150%, the lowest think time can be one (50%) and the highest value three (150%).
• Limit think time to: This option will Limit the maximum think time's value to the value specified in this option.

Error Handling :

• Continue on error: Choosing this option lets the script continue execution even if it encounters any errors. Vuser will exit if you enable this option.
• Fail open transactions on lr_error_message: Choosing this option will make transaction fail, if lr_error_message is placed inside the transaction. This is done using if statement when condition is met. See the ex below:

if (atoi(lr_eval_string("{rCount}")) == 0)

{ lr_error_message("s02_search failed for %s", lr_eval_string("{Id}"));

lr_end_transaction("search", LR_FAIL);

lr_exit( LR_EXIT_ACTION_AND_CONTINUE,LR_FAIL );

return(0); )

Generate Snapshot on Error:

This is pretty straight forward. Choosing this option generates a snapshot when an error occurs. To view the snapshot goto the Vuser Log and double-click on the line at which the error occurred.

Multithreading:

Vuser can be ran as thread or processor. Its always advantageous to run Vuser as thread as more number of vusers can be run per loadgenerator. Only Thread Safe protocols should be ran as threads.Note: The following protocols are not threadsafe: Sybase-Ctlib, Sybase-Dblib, Informix, Tuxedo, and PeopleSoft-Tuxedo.Controller uses a program called mdrv.exe to run Vusers. Lets see the difference between running vusers as thread and process:

Process: If you run as process mdrv.exe is launched into the memory repeatedly for every instance of Vuser. Loading mdrv.exe again and again utilises large amount of RAM and other system resources. This limits the vusers that can be run on a loadgenerator.

Thread: If you run Vuser as thread, once instance of mdrv.exe for every 50 Vuser. 50 Vuser is default setting. Each vuser runs as thread and these share memory segments of the parent driver. Re-loading of mrdv.exe again and again for every vuser is not required.Hence it saves utilization of RAM and other system resources. So more vusers can be run on loadgenerator compared to Process.

Automatic Transactions:

Define each action as transaction:

If you check this option each action is considered as a transaction along with the manually transactions you have inserted.

Define each step as transaction:

The Web_url’s, web_submit statements are considered as transactions and is displayed in the controller during executions. Its always better to have your own transactions manually inserted.

Browser Properties:

When Vuser run the script, it makes a request to the server. The request contains http header, resource name, protocol version. Vuser header also includes the type of browser details.Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; InfoPath.1)The information is what sent along with header. You can infact change the browser type that you may want vuser to use when running script.

Simulate Browser Cache:

Browser cache is used to store the resources accessed frequently and this reduces the time connected to the network. It is not required for the vuser to connect and request resource from the server when the same is available in the cache. If you consider in real time scenario some user may have enabled browser cache and some may not, so you can either choose or disable this option when running your scripts. When running multiple Vusers, every Vuser uses its own cache and retrieves resources from the cache.

Check for newer versions of stored pages every visit to the page:

This setting instructs the browser to check for later versions of the specified URL, than those stored in the cache. This option brings up the most recent version of the page, but also generates more traffic during the scenario execution.

Download non-HTML resources:

In real time when a user access a site, the page is available with all contents along with the graphic images if any. Download of the page to the user client machine is done when all these resources are downloaded. So if you want Vuser to emulate this kind of scenario you can check this option. Vuser will load all images when accessing a web page during replay. Therefore, enable this option if you are trying to test the entire system, including end-user time like a real time scenario or real user.Note: Disable this option if you experience discrepancies in image checks, since some images vary each time you access a Web page (for example, advertiser banners).

Simulate a new user each iteration:

Instructs VuGen to reset all HTTP contexts between iterations to their states at the end of the init section. This setting allows the Vuser to more accurately emulate a new user beginning a browsing session. It deletes all cookies, closes all TCP connections (including keep-alive), clears the emulated browser's cache, resets the HTML frame hierarchy (frame numbering will begin from 1) and clears the user-names and passwords. This option is enabled by default. Clear cache on each iteration: Clears the browser cache for each iteration in order to simulate a user visiting a Web page for the first time. Clear the check box to disable this option and allow Vusers to use the information stored in the browser's cache, simulating a user who recently visited the page.

Checks:

We have 2 checkpoints i.e text and image check point. Using checkpoints along with if statements are very important in tracking the script executions and failures. Text checkpoint checks whether particualar text is present on the particular page and image checkpoint checks for the image present. These check statements are executed during the script run, and they track the resoponse sent from the server to check the same.This option only applies to statements recorded in HTML-based mode. Vusers running with verification checks use more memory than Vusers who do not perform checks.

Generate Web Performance Graphs:

This option is useful when you want to generate graphs related to hits/sec, response/sec and pages/sec. Data required to display these graphs are captured during executions and displayed using online monitors. You can also display or get these metrics after the run using the analysis tool. Select the types of graph data for the Vuser to collect. Note: If you do not use the Web performance graphs, disable these options to save memory.

Advanced Web Run-Time Options:

WinInet Replay (instead of Sockets): Instructs VuGen to use the WinInet replay engine. VuGen has two HTTP replay engines: Sockets-based (default) or WinInet based. The WinInet is the engine used by Internet Explorer and it supports all of the features incorporated into the IE browser. The limitations of the WinInet replay engine are that it is not scalable, nor does it support UNIX. In addition, when working with threads, the WinInet engine does not accurately emulate the modem speed and number of connections. VuGen's proprietary sockets-based replay is a lighter engine that is scalable for load testing. It is also accurate when working with threads. The limitation of the sockets-based engine is that it does not support SOCKS proxy. If you are recording in that type of environment, use the WinInet replay engine.

File and line in automatic transaction names:

If you disable the automatic transactions option and check this option too then Unique transaction names are created by adding file name and line number to the transaction name.

Note: This option places additional information in the log file, and therefore requires more memory.

Non-critical item errors as warnings:

This option returns a warning status for a function which failed on an item that is not critical for load testing, such as an image or Java applet that failed to download. This option is enabled by default. If you want a certain warning to be considered an error and fail your test, you can disable this option. You can set a content-type to be critical by adding it to the list of Non-Resources. For more information, see Specifying Non-Resource Content Types.

Save snapshot resources locally:

Instructs VuGen to save the snapshot resources to files on the local machine. This feature lets the Run-Time viewer create snapshots more accurately and display them quicker.

Lets discuss few options which are important:

DNS caching:

Instructs the Vuser to save a host's IP addresses to a cache after resolving its value from the Domain Name Server. This saves time in subsequent calls to the same server. In situations where the IP address changes, as with certain load balancing techniques, be sure to disable this option to prevent Vuser from using the value in the cache (enabled by default).

HTTP version:

Specifies which version HTTP to use: version 1.0 or 1.1. This information is included in the HTTP request header whenever a Vuser sends a request to a Web server. The default is HTTP 1.1. HTTP 1.1 supports the following features:

Keep-Alive HTTP connections:

Keep-alive is a term used for an HTTP extension that allows persistent or continuous connections. These long-lived HTTP sessions allow multiple requests to be sent over the same TCP connection. This improves the performance of the Web server and clients. The keep-alive option works only with Web servers that support keep-alive connections. This setting specifies that all Vusers that run the Vuser script have keep-alive HTTP connections enabled (enabled by default).

Step timeout caused by resources is a warning:

Issues a warning instead of an error when a timeout occurs due to a resource that did not load within the timeout interval. For non-resources, VuGen issues an error (disabled by default).

HTTP-request Connect Timeout (seconds):

The time, in seconds, that a Vuser will wait for the connection of a specific HTTP request within a step before aborting. Timeouts provide an opportunity for the server to stabilize and respond to the user (default value is 120 seconds). Note that this timeout also applies to the time the Vuser will wait for a WAP connection, initiated by the wap_connect function.

HTTP-request Receive Timeout (seconds):

The time, in seconds, that a Vuser will wait to receive the response of a specific HTTP request within a step before aborting. Timeouts provide an opportunity for the server to stabilize and respond to the user (default value is 120 seconds). The timeout settings are primarily for advanced users who have determined that acceptable timeout values should be different for their environment. The default settings should be sufficient in most cases. If the server does not respond in a reasonable amount of time, check for other connection-related issues, rather than setting a very long timeout which could cause the scripts to wait unnecessarily.

Step download timeout (seconds):

The time that the Vuser will wait before aborting a step in the script. This option can be used to emulate a user behavior of not waiting for more than x seconds for a ಪೇಜ್

This options lets you choose from which URL/ Website vuser has to download the resouce from. You can also put the list of URL’s in the exclude resource, when you do so Vuser doesn’t donload’s resources from all sites except from those in the exclude list. VuGen filters out resources from all Web sites except for those in the Include list. The filter type available are URL, HOST, HOST-Suffix.

Note: The run time settings chosen for running a script are displayed in the replay log at the beginning.

Content Check

This helps you to identify specific error message during executions and take appropriate actions as defined. Vugen uses content check to search for specific test strings automatically during executions using the pre-defined rules in the response returned from the server. You have in-built content check for applications like Siebel which will help to track down the error messages returned from the server and analyse the cause for script failure.

Lets see how this works:Consider you have defined a content check rule to search for Error “HTTP 404”, this might be due to bad request to the server or page might be missing or broken links. But server return “HTTP 404” simple. You have recorded a script which will access your banking application and navigate across different pages. When you run this script, what content check does is it will look through the responses sent from the server for the text string “HTTP 404”. When it finds this specific string content check stops the script executions or passes a warning message to the log file. This is just a simple example and overview on content check. In real time its really useful in different ways. You can fail script if particular text string is found as well for not found.

You can create your own content check for your applications by using the “new application button”, and then you can add individual rules as many to this. You can export content check you created by using the export option which is saved as .xml file. You can import the content check from other applications. Content check is stored as .xml file.

Introduction to Transactions

Transactions are useful to measure performance of the server. It measures the time when a request is made to the server and response is sent back to the client. For eg if you are if you have a bank application and you are performing the following activity:

• Log in to bank application
• Check balance
• Transfer amount
• Log out

So in the above ativities you can measure how long it takes to log into application, how long it takes to check balance, transfer amount and log out.To measure the time taken we need to insert transactions. To measure the time you insert the transaction at the beginning of the activity and end the transaction at the end of the activity. You can have any number of transactions in your script. Its always useful to follow proper naming convention for your transactions so that it will be useful for tracking purposes. You will appreciate the use of transaction during load executions in the controller. You can create transaction when you are recording the script or you can insert manually after recording. You can inser transactions manually using the below function:

lr_start_transaction("Transfer_Amount");

{Transfer amount activity details………….…………………………………………….…………………………………………….}

lr_end_transaction("Transfer_Amount ", LR_AUTO);

Data Assignment methods

Data Assignment methods: In Vugen we have the option of selecting how to assign the value to the parameter. This is applicable for file and table type. Three methods are available:

• Sequential
• Random
• Unique

The above data assignment methods along with update method will decide what values vuser use to substitute parameters during the execution. We will discuss how these work in detail:

If the above table is not clear lets discuss taking an example:Lets consider table file with the following values:QQ, AA, ZZ, WW, SS, XX

Sequential:

If there are not enough values in the data table, VuGen returns to the first value in the table, continuing in a loop until the end of the test.

Unique :

When out of values we have the below options to choose:

• Abort Vuser : Vuser stops running when there are no unique values
• Continue with Last Value: Vuser uses the last value for all the remaining iterations when it runs out of unique values.
• Continue in cyclic manner: Vuser uses the values again from top for all the remaining iterations when it reaches the last unique value.
  

Note : Vuser Doesn’t really identify unique values, like for eg for unique you can have values like 1 2 3 4 2 6 7 4 Unique allocation in terms of blocks. See example below:

Number BlockNumber

1 1

2 2

1 3

2 4

5 5

6 6

If u have 2 Vuser and running for 3 iteration then

1st Vuser ( will be allocated block number from 1 to 3 irrespective of the values present)

2nd Vuser (will be allocated block number from 4 to 6 irrespective of the values present)

We can allocate Block size automatically or you can specify how many values have to be used for each vuser. This is applicable for only Unique type.

Note : Make sure you have enough values when you choose unique else you will end up getting “ No more unique values” error during executions.

File and table type parameters

Lets Go over all the important properties of Parameter list:

Creating parameters:

You can create parameters either from the script view or from the parameter list. In the parameter list click on the new button, give a name and select the parameter type according to your needs. You can also associate an existing parameter file for the parameter created by browsing and pointing to the file. Properties for File parameter type: After you select a source of data, you set the assignment properties for your file. These properties instruct VuGen how to use the data. For example, they indicate which columns to use, how often to use new values, and what do to when there are no more unique values.

As shown above you can add new column, new row, delete column / row using the corresponding buttons for a parameter with parameter file type. During the executions you can choose to select the column names using “By number” or “By name”. Vuser uses the selected column and corresponding values for the execution. Column delimiter is used to separate the columns in the table. You can specify a comma, tab, or space. First data line specifies from which row the values has to be used by vuser during execution. If u select 2, vuser uses the value from 2 row after header.

Table Type Paramater:

You can observe that there is difference between the file and table type parameter, In table type parameter you can fetch data either from data file (.dat) or from an external table using sql query. You can select all the coulmns of the table or few columns. In the Rows section, specify how many rows to use per iteration in the Rows per iteration box. Note: This only relevant when the Update value on field is set to Each iteration. If Update value on is set to Once, then the same rows will be used for all iterations. All other options works more or less like file type parameter.

Internal Type Paramater:

In this you can choose the range of random values you want Vuser to utilise during its executions. You can choose the number format. In the same way it works for other internal type paramaters

Introduction to Vuser Parameters

Why do you think we need the concept of parameterization? The answer for this question is simple humans get bored by doing monotonous job and also our application is just not just accessed by one person or is not just for one purpose. Consider the following example. You have recorded a script which will log into a bank application to check the balance of a person/account. If u replay the script, it checks the balance of the same person /account. But our goal of replaying the script is to check how application behaves when different user persons/ accounts check their balances. So to adopt our script to test for different accounts we need to implement the concept of parameterization. That means if we parameterize Account field then script uses different accounts for each of its iterations. For 1st iteration it may use to check account balance of Sam, for second iteration it may check for Mahesh and so on….

Lets go over in detail on the parameters: Inserting parameters in the script:

• Select the text you want to parametrize, right click and select replace with parameter
• Choose the parameter name (Please follow a standard naming convention) and parameter file type (which we will discuss in detail later). For now choose file.
• You can successfully parametrized the value in the script
• Open parameters list, click edit with notepad, enter multiple different values
• Now run the script, and you can observe that script uses different values for each iteration

Note: You need to set no of iterations more that 1 in the run time settings for the script to run multiple times.

Limitation of parameters:
You cannot parameterize text strings that are not function arguments.
You cannot parameterize all function arguments.

Parameter Types:

The following are the parameter types we have in loadrunner:

• File or Table parameter types
• User Defined Parameter types
• Internal type Parameter types
  

File or Table Parameter types:

This is the very common method for using parameters in Vugen. Vugen fetches data from external file or data table. We can edit/open this file using notepad. You can also use data wizard to fetch data from database. We can also create new file for storing the data. Vugen access this file during the script execution. One data file can contain multiple columns (each column equivalent to one parameter), and under each columns you have different values. Comma, Tab, Space suffice the job of column delimiters. In the below example a new data file created contains number, firstname, lastname

Number FirstName LastName

1 mm kk

2 00 pp

3 dd ss

User Defined Parameter types:

An external DLL is loaded and data is generated using a function from this DLL. A user-defined function replaces the parameter with a value returned from a function located in an external DLL.. Before you assign a user-defined function as a parameter, you create the external library (DLL) with the function. The function should have the following format: __declspec(dllexport) char *(char *, char *)

Internal type Parameter types:

Data is generated automatically and used for the parameter. For eg if u define data/time then today’s data is used for the parameter (today’s date is replaced for the parameter in the script when the Vuser runs). The other different internal type parameters are : Group name, Iteration number, Load generator Name, random number, Unique Number and Vuser Id. If you choose random as parameter type then for each iteration a random value is substituted in the script during execution. You can choose the max and min value range.

Using Existing Parameters

Paramater is automatically added to the parameter list whenever you create a new parameter. You can use this existing parameter to replace any value in the script or to replace multiple occurrences of that value. Restoring Original StringsYou can also restore original value after undoing the parameterizationTo restore a parameter to its original value:In Script view, right-click on the parameter and select Restore original value. Paramater List:Here You can create new paramaters, edit paramaters, delete parameters, edit parameter values, choose parameter types, set/edit parameter properties, choose data assignment method, data update modes,

Actions in Depth

As discussed earlier when we record a script we have 3 section Vuser_init, Action and Vuser_end.Lets discuss about the action in detail: There can be more than one action in a script. Its always help to have multiple actions in your script. Eg : If you are recording logging into mail, checking mails, sending mails, checking the sent mails, deleting mails then you could arrange / record in the below way:
Action 1:Checking mails
Action 2:Sending mails
Action 3:Checking sent mails
Action 4:Deleting mails

You can also rename the actions as you wish, if you want to follow specific naming conventions. I always suggest to follow specific naming conventions.

• You can rename during recording or by right clicking on the particular action after recording.
• You can always delete the actions which you don’t require in your scripts.
• You can always create new action even after recording.
• You can import action from other scripts too. Parameters associated with the imported action, will be merged with the existing script.
• You Can insert action blocks which are group of actions and you can configure each action block independent of each other.

See the below example:

• This script is developed to just open the Google page. This is placed in the Vuser_init.
• We have created action block(0) under Action section.
• Inside action block(0) we have inserted Vuser_init (Which infact calls / runs the Vuser_init section of our script , opening of google page)
• We have choosen to run the main action for 2 iteration and the action block for 3 iterations.
• When we kick off this run, you can observe the way it goes as explained below:

How the script is executed is explained below:

• Main Vuser_Init runs for one iteration.
• Run (x2) which is shown below has to execute twice.
• First time Run (x2) executes, under this the Action is executed once and Block0 (x3) is executed for 3 times as we have set the property of this such that it executes for 3 times. That means our original Vuser_init ( which opens google page) is executed thrice.
• Second time Run (x2) executes, under this the Action is executed once for second time and Block0 (x3) is executed for 3 times as we have set the property of this such that it executes for 3 times. That means our original Vuser_init ( which opens google page) is executed thrice for second time.
• As Run(x2) has executed for 2 times it comes out of Run action and moves to Vuser_end action.
• Vuser_end is executed for one time and the run is completed. Note: You can set the actions inside the action block to execute randomly or sequentially. This is self explanatory guys and I hope you understand it.

Streamlining Recording

Settings Before recording: Lets go over record setting that you need to be aware of before recording any script: General – Script:

Scripting Language:

The Default script generation language when you record is C. For some protocols Vugen can also generate script in other languages. The details are as below: C Language - For recording applications that use complex COM constructs and C++ objects. Visual Basic for Applications - For VB-based applications, using the full capabilities of VB (unlike VBScript). Visual Basic Scripting - For VBscript-based applications, such as ASP. Java Scripting - For Javascript-based applications such as js files and dynamic HTML applications. After the recording session, you can modify the script with regular C, Visual Basic, VB Script, or Javascript code or control flow statements.

Close all AUT processes when recording stops:

Checking this automatically closes all of the application that has been opened for recording when VuGen stops recording. (disabled by default)

Generate fixed think time after end transaction:

Checking this automatically add’s a fixed think time in seconds after the end of each transaction. You can specify a value for the think time. The default is 3 seconds. (disabled by default) Generate recorded events log:

Generate a log of all events that took place during recording. (disabled by default) . This adds a new Recorded events log tab and displays all the events. Find the sample screen shot below:

Generate think time greater than threshold:

You can instruct loadrunner to insert /generate think time if its more than the threshold value. The default values is 3—if the think time is less than 3 seconds, VuGen does not generate think time statements. If you disable this option, VuGen will not generate any think

Maximum number of lines in action file:

Create a new file if the number of lines in the action exceeds the 60000 lines. (C Language only) Track processes created as COM local servers:

Track the activity of the recorded application if one of its sub-processes was created as a COM local server. (enabled by default)

General – Protocol:

Adding and Removing Protocols:

You can choose / Modify the protocol list for which Vugen will generate code during recording session.Internet Protocol: recording

Recording levels or Modes:

There are basically 2 modes of recording namely URL and HTML modes. Let’s go over them and understand the difference:

HTML:

This mode is called sometimes context sensitive and is usually preferred for several reasons. One of the reasons is because it is "context sensitive" , i.e.each mouse click recorded in the script is made in the context of the previous step/page. In order to maintain context it looks through the previous page to make sure the current operation is available. This adds extra overhead because it is performed by a background utility called the runtime parser. Although the parser uses extra overhead, it does saves us work in correlation and page checks. This because if a link/request is not available, the runtime parser will see that and throw an error telling us that the request is not there. (The old "Requested Form Not Found" error).

URL Mode:

This mode, does not check the context of the previous request. It will simply make each recorded request individually regardless of whether the request is still available on the page or logically follows in context. That's why URL mode requires more in the way of page checks and correlation. Look at these examples for a better illustration: HTML (Context Sensitive) Mode. Step 1: Goto www. yahoo.com Step2: Click the email button. Of course mouse clicks/buttons are really just requests for a web address. In this HTML mode, the second step will show up as "web_link" "Email" statement directing you to the email page. Upon script replay the runtime parser will search through the 1st www.yahoo.com page to see if the "email button" is located on the page. If it is there it will request that URL. If not, the script will fail.(Requested Form/link not found). Exact Same Script Recorded in URL Mode:www. yahoo.com ----- click email button. Again, Both steps are really just web addresses. In URL mode however, the second step will show up as a "web_url" statement that directs you to your email. BUT!!!! The script will STILL make the request for the URL that take us to the email page regardless whether the link is a available on the page or not!! There's no Context!! This causes us to have to add more page checks since an application change or failure may take us to a location that is not expected; but may still return a 200 Server code!! For example, It probably couldn't happen in this particular example, but let's say in place of the EMAIL button on the main yahoo page it said: "Email temporarily unavaible." What would happen...in our URL based script with no context..is it would STILL make the http request for URL address of the missing email button. The subsequent web page may come up with a 200 server response but instead of the right content it may say something like "TRY AGAIN LATER." If we have no page checks; we would fool ourselves into thinking our script is working when in actuality we are not emulating a real user.

This content provided by cheney whom I consider my mentor.

• For browser applications without JavaScript, use the HTML-based level.

• For non-browser applications, use the URL-based level.

The HTML-based script level generates a separate step for each HTML user action. The steps are also intuitive, but they do not reflect true emulation of the JavaScript code. The URL-based script mode option instructs VuGen to record all browser requests and resources from the server that were sent due to the user's actions. It automatically records every HTTP resource as URL steps (web_url statements). For normal browser recordings, it is not recommended to use the URL-based mode since is more prone to correlation related issues. If, however, you are recording pages such as applets and non-browser applications, this mode is ideal. URL-based scripts are not as intuitive as the HTML-based scripts, since all actions are recorded as web_url steps instead of web_link, web_image, and so on.

Note : You can switch recording levels and advanced recording options while recording, provided that you are not recording a multi-protocol script. You can also regenerate a script after recording, using a different method than the original recording. For example, if your record a script on an HTML-based level, you can regenerate it on a URL-based level. To regenerate a script, choose Tools > Regenerate Script and click Options to set the recording options for the regeneration.

HTML Advanced Option:

Lets go over the Script type options:

1. A Script describing user actions ( e.g web_link, web_sumit_form) :When you check this option and start recording, Vugen generates functions for all the actions done during the process of recording. Functions are generated corresponding to the actions. For eg :

If user open / requests a web page web_URL function is generated

If user clicks on any links on the page web_link function is generated

If user clicks on any image links on the page web_link function is generated

If user clicks on any submit button on the page web_submit_form function is generated.

Ex: See below recording on google:

2. A script containing explicit URLs only:

This setting records all links, images, url’s as web_url statements. And for form submission its recorded as web_submit_data. It does not generate the web_link, web_image, and web_submit_form functions.

This mode is useful for instances where many links within your site have the same link text. If you record the site using the first option, it records an ordinal (instance) for the link, but if you record using the second option, each link is listed by its URL. This facilitates parameterization and correlation for that step.

Non HTML generated elements:

Web pages may contain non-HTML elements like XML, applets, ActiveX elements, and javascript. These non-HTML elements usually contain their own resources. For example, a javascript js file, may contain several images when called from recorded web page. An applet may contain an external text file. Using the following options, you can control how VuGen records non HTML-generated elements.
a. Record within Current steps:

When you use this option new function is not generated for each of non-html resources. These become part of web_url , web_link and web_submit_data etc functions.These non-html resources are indicated by Extras flag.

b. Record in separate steps using concurrent groups

Checking this option makes each of the non-html elements to be recorded / generated as new function. It does not become part of functions (such as web_url, web_link, and so on). All of the web_url functions generated for a resource, are placed in a concurrent group (surrounded by web_concurrent_start and web_concurrent_end).

c. Do not record:

Instructs VuGen not to record any of the resources generated by non-HTML elements.

Let’s go over in detail on the web_URL function:

web_url(http://www.google.com/, "URL=http://www.google.com/", "TargetFrame=main","Resource=0", "RecContentType=text/html", "Referer=", "Snapshot=t1.inf", "Mode=HTML", )

• URL: This attribute is used to load the particular page. This value is very much required for this function to work.
• Target Frame: This attribute instrusts where the results page/file should be loaded. For eg if taget frame=blank then its loaded in a new window.
• Resource : This attribute indicates whether URL is a resource (Value=1) or not a resource (Value=0)
• RecContentType: The type of resource that was recorded. For example, "RecContentType=text/html" indicates navigation to html text. "RecContentType=application/msword" indicates the use of the MS Word application.
• Referer: This describes the page that referred to the current page. Like for searching the web_submit_data function in google the referrer page is http://www.google.com/
• Snapshot : This name of the snapshot file which is used for correlation.
• Mode : This describes the recording modes for web scripts. We have http and html modes.
  

HTML : Records all user actions as web_url, web_link, web_image and web_submit_form HTTP: Records all user actions as only web_url functions.

Note:When you work in HTML-Based mode, VuGen inserts the TargetFrame attribute in the web_url statement. VuGen uses this information to display the Web page correctly in the run-time browser and Test Result report. When you record the URL-based mode, VuGen records the content of all frames on the page and therefore omits the TargetFrame attribute.

URL MODE

Setting Advanced URL-Based Options:

The URL-based mode option instructs VuGen to record all requests and resources from the server. It automatically records every HTTP resource as URL steps (web_url statements), or in the case of forms, as web_submit_data. It does not generate the web_link, web_image, and web_submit_form functions, nor does it record frames. See the example below recorded in url mode with above setting:

You can observe above that script has captured/recorded all the resources like .gif and other files that are downloaded when browser makes a request. These reqources are placed in a concurrent group.
Use Web_Custom_Request_Only:

When you choose this option VUGEN records all HTTP requests as custom requests. Regardless of the content all request are generated as web_custome_request functions. See example below:

Difference Between Single and Multi Protocol:

• If you record using Single Protocol then Vugen records on specific protocol only which is chosen.
• If you record using Multi Protocol then Vugen records activity in several protocols which are chosen to record.

Eg : If you application communicates with web(HTTP/HTML) protocol initially and during the proceeding recording stages if it uses oracle or other protocol then to generate/ record the activities on both these protocols we should be using web(HTTP?HTML) and ODBC protocols. TO conclude which protocol to use for your application , you should know the type of communication method / Protocol your application uses to communicate with the server. It doesn’t matter what kind of language was used for development of the application, you need to sit with the development team , System architects to understand this.

Understanding the VUSER script

If you look at the basic script you recorded any you might have observed the following functions in the script.:

• web_url for a URL in the Address field on the internet browser.
• web_link for clicking a text link between 'a href= ...' and 'a'
• web_image for clicking an HTML 'img href= link'.
• web_submit_form for pressing "submit" of a GET or PUT form obtained in the context of a previous operation — perhaps recorded by VuGen in HTML-based recording mode.
• web_submit_data for pressing "submit" of a GET or PUT form without the context of a previous operation — perhaps recorded by VuGen in URL-based recording mode or in HTML-based recording mode with the "A script containing explicit URLs only" option checked.

Introduction to Output window in VUGEN

Out Put window in Vugen: The main windows in the output window section of Vugen are :

• Replay Log
• Recording Log
• Generation Log
• Correlation Results
• Run time data

Replay Log:

This log gives the details as the vuser runs. This Log provides the details like the requests that vuser has sent to the server and corresponding responses server has sent back. This helps you to validate your script whether it ran without any errors.It helps you a lot to debug your script if script is failing. If you double-click on a line beginning with the Action name, the cursor jumps to the step within the script that generated. This log is generated when you run your script. It also shows the parameter substitutions, you can pass custom messages into this log. You will really appreciate the importance of this log going forward.

Recording Log:

You can view information about the recording and the script generation by viewing the logs in the bottom window. This log has all the communication messages that happened between the client and the server during recording. You can set the level of detail for this log in the Advanced tab of the Recording options. Deleting this file will not affect script’s replay.

Generation Log:

This log is used to view a summary of the script’s settings used for generating the code.This view shows the recorder version, the recording option values, and other additional information. This log is generated after recording. This log is also helps in correlation (Which is a very important concept in loadrunner which I would be explaining futher)

Correlation results:

This tab displays the differences between recorded and replay snapshots. This is helpful in deciding which values to correlate when you want to perform automatic correlation. Auto correlation is not always advisable, manually correlating yields best results and helps in developing a stable script. Run time data:You can track the script information like iteration, action and line number it’s executing. The Parameters section under this displays the value that is being substituted based on their update modes for all the parameters defined in this script

About VUGEN

VUGEN is component of loadrunner used to develop scripts for performance testing your business critical scenarios. After business critical scenarios are identified VUGEN is used to record / Develop script for all you scenarios. Vugen is a protocol based record and playback tool. VUSER concept is one which you wil be hearing very often. Well what is a vuser? The answer is one VUser is equivalent to one human. VUSER is used to emulate the actions performed by human and VUGEN helps vuser to successfully perform this emulation. The actions Vusers Perform are described/develope in the Vuser Script.

How Loadrunner VUGEN works:

loadrunner records / playbacks scripts at protocol level and it doesn’t work at your GUI level (Unlike QTP), it doesn’t perform any gui operations when you play back the script.GUI is not at all important to loadrunner. Loadrunner doesn’t record any client activity. Vugen during recording automatically generates functions that emulate your manual actions instead of manually coding the application’s API function calls to the server. When you start your recording activity in VUGEN, VUGEN captures all interactions between the client and the server. Events like mouse movement, editing data, entering data on the web form or client side is not recorded because these events do not interact with the server. VUGEN pays special attention for all the requests sent by the user and received from the user to the server. When you playback the recorded script from vugen ,the script communicates directly with the server using the Server API calls. Client system resources are not much utilised for this operation.

Lets see how this works when we record on google:

• Internet explorer opens up and tries to establish connection with google
• After successfully connection google page is displayed
• Enter name in the search box and click search
• Clients again sends request to the server
• Server responds back to client by displaying the results

Same thing how VUGEN interprets:

• Add Cookies that google uses for each header
• Make http request on URL http://www.google.com/
• Make http request for each of the gifs on that page
• Above 2 requests may be embedded in one web_url ( Please refer on the modes of recording for the same)
• Web_submit form is inserted for pressing “Submit” of a get or put form.

Vuser Types:

VuGen enables you to record on different protocols. A variety of Vuser types, each suited to a particular load testing environment or topology is used for the same.

Below is the list of protocols used:

• Application Deployment Solution: For the Citrix protocol.
• Client/Server: For DB2 CLI, DNS, MS SQL, ODBC, Oracle (2-tier), Sybase Ctlib, Sybase Dblib, and Windows Sockets protocols.
• Custom: For C templates, Visual Basic templates, Java templates, Javascript, VBscript, and VBNet type scripts.
• Distributed Components: For COM/DCOM, Corba-Java, and Rmi -Java protocols.
• E-business: For FTP, LDAP, Microsoft .NET, Palm, Web (GUI level), Web (HTTP/HTML), Web Services, and the dual Web/Winsocket protocols.
• Enterprise Java Beans: For EJB Testing and Rmi-Java protocols.
• ERP/CRM: For Baan, Oracle NCA, Oracle Web Applications 11i,Peoplesoft Enterprise, Peoplesoft-Tuxedo, SAP-Web, SAPGUI, dual SAPGUI/SAP-Web, and Siebel (Siebel-DB2CLI, Siebel-MSSQL, Siebel- Oracle, and Siebel-Web) protocols.
• Legacy: For Terminal Emulation (RTE).
• Mailing Services: Internet Messaging (IMAP), MS Exchange (MAPI), Post Office Protocol (POP3), and Simple Mail Protocol (SMTP).
• Middleware: Jacada and Tuxedo (6, 7) protocols.
• Streaming: For MediaPlayer and RealPlayer protocols.
• Wireless: For i-Mode, VoiceXML, and WAP protocols.
  

First touch to VUGEN

Following is the requirement for Installing loadrunner on windows machine










Note: Please see the loadrunner help file for more details. The following table describes the system requirements for each platform supported by Mercury for LoadRunner UNIX Vusers. Note that LoadRunner supports all X Servers.


Platform Hardware Version
Solaris Ultra Sparc Solaris 2.8 or higher
HP HP 9000 series 700, 800, HP-UX 11.x or higher
IBM IBM RS/6000 AIX 4.3.3 or higher
Linux PC i486 Red Hat 9.0 or higher

System Resources:The following describes the system resources required for each platform or operating system. The actual resources may vary depending on the number of Vuser licenses purchased. The resources for Vusers listed below apply to each virtual user. If you are installing multiple virtual users, you must multiply the figure by the number of virtual users. Disk Space required for program installation 22 MB (34 for Linux) Memory Space each Vuser if run as thread 300 KB (at least). This amount may vary, depending on the operating system and platform, and does not include the memory used by the process. Memory Space each Vuser if run as process 1.5 MB (2.5 MB for Solaris) Swap Space approximately 1:7 memory/swap ration Free Process Entries each Vuser if run as process 1 File Descriptors each Vuser if run as thread 2 (see below) The Memory Space above describes a general C-Vuser type. Other types may take up more memory space. For example, each Web Vuser uses at least 500 KB.

A load generator additionally uses the following File Descriptor resources:

1. 14 file descriptors for the LoadRunner launch service
2. 20 file descriptors for the LoadRunner agent
3. 30 file descriptors for each Vuser driver. By default, there is a driver for every 50 Vusers.

For example, to compute the number of file descriptors used in running 100 threaded Vusers the load generator requires:Total: 294 File DescriptorsIf Vusers are run as processes instead of threads, one driver is run per Vuser. Therefore, each Vuser requires 30 file descriptors. You can increase the number of file descriptors, process entries, and amount of swap space by configuring the kernel.

Process of developing / creating Vuser Script:

• Open Vugen
• Choose a protocol depending on your application
• Record the scenario you have identified
• Enhance / Edit the script
• Configure the run time settings
• Run the script for single iteration
• Integrate the Vuser script in the controller to the scenario

Lets go in detail on all these steps:

1. Open VUgen

2. Click on the New button 3. Select web (HTTP/HTML) from the list of single protocol






4.Click ok button
5. Start record window is displayed. Provide the URL you want to record on, for now keep the settings as shown below
6. Click ok button


7.New IE page opens with http://www.perfload.com/
8. Enter name in the search field
9. Stop recording
10.Script is generated
11.Click on the run button or F5This is a high level picture of recording and running a basic Web Protocol script.You might have observed in the above script there are 3 sections in the script as follows:

• Vuser_init
• action
• Vuser_end

Lets analyze the importance of each one and when we have to use it:
Vuser_Init:This section is mostly used to record the login part of your application. This section is executed only one during the run irrespective of the number of iterations you choose in the run time settings. In simple words no matter how many times you execute the script this section runs only once. This section is executed when Vuser is initialized Action:This section is used to record all the activities you perform once you login to the application. This section is executed multiple times. it depends on the run time settings. In simple words this will run as many numbers of times you want provided you make the specific changes in the run time settings.This section is executed when Vuser is in running status Note: There can be multiple actions in the script. Use multiple actions according to your needs. Vuser_end:This section is used to record your logout part of the application. This runs only once like Vuser_init. This is executed when Vuser finishes/stopped. Example: If you consider logging into your mail account, checking mails, sending mails and logging out then : Vuser_init : Logging into mail Action : Checking mails, sending mails Vuser_end : Logging out