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