How to Deal with Timeline Crunch request

1. Understand the request. - for eg, finish 5 days of execution in 2 days
2. Run it through the team and estimate the efforts required.
1. note if extra resources would be required
2. note if extra time would be required.
3. take the requirement to the PM. if not approved take to the leadership.
4. if that is not approved, discuss with the team about the critical scenarios and high priority tests; involve architecture and business teams for approval on the decision. 
1. not testing less important scenarios (if any)
2. not performing any particular type of test(if any)
5. Document the conditions and get the approval from leadership.
6. Document the risks. update the test plan, publish the impact and risks to all the project stakeholders.  

 

Performance Testig with Citrix Protocol - Recording and Replay Procedure + Tips

These steps/procedures written were used during year 2012 when I have worked on Performance Testing of multiple citrix applications for customer [With HP Load runner 11.0]. Please follow up all these steps, It will make easy to work with citrix application for performance testing using HP tools such as Load Runner [LR] and Performance Center [PC]. It will be updated/modified in future If there will be any enhancement by HP for citrix in LR [Load Runner] and PC [Performance Center]. 

Pre-Condition [Environment]

1. Check availability of LR or PC for Performance Testing. 

2. Verify the license availability for Citrix ICA protocol 

3. Verify all the latest patches available for Citrix in LR or PC. 

4. Collect .ica file from Citrix admin. 

5. Verify the latest Citrix online plug in installed in the machine, where LR installed or user will do the performance testing. 6. Verify multiple Load generators available with latest load runner Citrix patches and Citrix online plug in.  

Citrix Scripting & Debugging 

Because the Citrix protocol relies heavily on bitmaps and coordinates to work correctly, there are few things to keep in mind when recording and editing the scripts.

Display and Resolution Setting 

When writing Citrix scripts in Load Runner, check the display settings of the generators where the scripts will be run. The color depth and resolution of the generators need to be the same as the settings on the computer where the scripts are written. If the settings are different, any sync_on_bitmap functions will fail. 

Also make sure resolution settings are consistent. To insure successful bitmap synchronization, make sure that the resolution settings match. On the recording machine, check the settings of the ICA client, the Recording Options, and the Run Time settings. On the Injector machines, check the settings of the ICA client, and make sure that they are consistent between all injector and recording machines. 

Recording Procedure 

a) Use 1024 x 768 Resolutions 
Supported resolutions (window sizes) are 640 x 480, 800 x 600, and 1024 x 768. Display settings of 1024 x 768 are recommended on the recording machine as it allows the Citrix window, whose default size is 800 x 600, to be displayed properly. Note that VuGen uses the Desktop's color settings. 

b) Do not resize Windows

It is recommended that you do not move or resize windows during the recording session. 

c) Disable Client Updates 

Disable client updates when prompted by the Citrix client.  

d) Windows Style 

Record all windows in the "classic" windows style—not the XP style. This is relevant for ctrx_sync_on_bitmap functions. 

To change the Windows style to "classic": 

• Click in the desktop area. 
• Choose Properties from the right-click menu. 
• Select the Theme tab. • Choose Windows Classic from the Theme drop down list. 
• Click OK. 

e) Keyboard Entry vs. the Mouse 

During the recording of a business process, navigate the application being recorded using the keyboard instead of the mouse. When Load Runner captures mouse clicks, it records the coordinates that were clicked on the screen. Replaying these coordinates is not very reliable. If your script relies heavily on coordinates, the scripts are more susceptible to being broken by application changes. As opposed to mouse clicks, navigate the application using the tab key or shortcut keys. Even if the application changes later, the script can be easily fixed by adding or deleting tab key entries in the script. 

f) Connection options 

ICA Files ICA files contain connection information for Citrix applications. Double-clicking on an ICA file will launch the application. A Citrix administrator can create this file for the person writing the Load Runner script. When setting up connection information inside of Load Runner, it is best to use an ICA file to connect. This makes the script more portable and more resilient to server change. If any of the connection information changes, in order to point the script to the new location, put the new ICA file in the script directory and replace the old one. For good housekeeping, it is a good idea of keep a copy of the ICA file that is currently in use in the root folder of the scripts folder. For example, if you are putting all of your scripts in c:\LoadRunner scripts\Project Name, you should put a copy of the ICA file in c:\LoadRunner scripts\Project Name. 

Recording Tips : 

• When recording a session, make sure to perform the complete business process, starting with the connection and ending with the cleanup. End your session at a point from where you could start the entire process from the beginning.
• Configure the Citrix server to completely close a session. Open the Citrix Connection Configuration dialog box. Choose Start > Programs > Citrix > MetaFrame XP > Citrix Connection Configuration. Double-click on the ica-tcp connection name. The Edit Connection dialog box appears. Click on the Advanced button. In the bottom section of the dialog box, clear the inherit user config check box adjacent to the On a broken or timed-out connection list box. Change the entry for this list box to reset. 
• Record the connection process into the vuser_init section, and the closing process in the vuser_end section. This will prevent you from performing iterations on the connection process.
• Display settings of 1024 x 768 are recommended on the recording machine. This will allow the Citrix window, which is 800 x 600 to be displayed properly.
• When opening expanded menu options, click explicitly on each option—do not depend on the expanding menu. For example, Start > Programs > Microsoft Word, be sure to click on the word Programs.
• If having trouble with window or dialog box names not being consistent, edit the script to use wildcards (*). For example, ctrx_set_window("Spelling and Grammar:*”);

Replay Procedure 

a) Set Initialization Quota 
To prevent overloading by multiple Vusers while connecting, set an initialization quota of 4 to 10 Vusers (depending on the capacity of the server) or apply ramp-up initialization using the Scheduler. 

b) Enable Think Time 
For best results, do not disable think time in the Run-Time settings. Think time is especially relevant before the ctrx_sync_on_window and ctrx_sync_on_bitmap functions, which require time to stabilize. 

c) Set Consistency between Machines 
If you intend to replay the script on another machine, make sure that the following items are consistent between the record and replay machines: Window Size (resolution), Window Colors, System Font and the other Default Options settings for the Citrix client. These settings affect the hash value of bitmaps, and inconsistencies may cause replay to fail. To view the Citrix Client settings, select an item from the Citrix program group and choose Application Set Settings or Custom Connection Settings from the right-click menu. Select the Default Options tab. Consult Application support group how to change settings if you are not able to do so.

d) Logging 
Logs help for debugging the script by returning values and information in play back. During development of the script, enable Standard or Extended log for debugging the script. But once you verify that script is functional and running as expected, it is advisable to disable log to conserve resource on injector machine. When running for large no of users via controller or performance centre, make sure that you disable the log. 

e) Run Vuser as thread Enable 
multithreading to run more Vusers per injector machines 

f) CITRIX Configuration 
Speed Screen Latency Reduction. 

For unknown network speed set it to Auto. It will turn it ON or OFF based on current network speed. 

Use Data Compression 
Enable it when working with limited bandwidth. But it is always advisable to set this option ON. 

g) Internet Protocol – Proxy 
Set the option as No Proxy

Debugging Procedure 

a) Debugging Vusers in the Controller 
Sometimes Citrix scripts do not work the same on different computers. Most of the time it is because of problems like color depth. If the Citrix scripts have problems running in the Controller during the debug run, there is a way to see visually what the scripts are doing. In the Controller, bring up the details for the group that is having problems. Under the Details section, make sure that “More” has been selected so that all of the options are shown. In the “Command line” text box, type –lr_citrix_vuser_view. 

If the scenario is ran with this option, it will bring up a Citrix window and show the virtual user as it is executing the script. When using this option, do not run a test scenario with many virtual users because the Controller will open one Citrix window for every user in the group. Because this is so resource intensive, it may crash the Controller if used with too many users. Set aside one group with a few users with this setting while the rest of the users are in different groups with standard settings. 

b) Generate Snapshot on error 
The “snapshot on error” feature run-time setting is very helpful when debugging Citrix virtual users. It is found in the miscellaneous options of the Run Time Settings. Anytime a virtual user fails, a screenshot is sent to the Controller which contains an image of what the screen looked like at the point of failure. It is a great way to diagnose syncing problems, or to troubleshoot other strange Citrix errors. 

c) Continue on error  
Load Runner provides a “Continue on error “option available for several Citrix functions. It allows individual functions to continue when sync does not work properly. There are several uses for this option. The most important use is for error trapping. If there is a potential for a function failing, Continue on Error option can be used on the function. In the subsequent lines of the script, the error can be handled appropriately and lines can be written to the log file to assist in debugging. 

d) Single Client Installation 
If you are unsuccessful in recording any actions in your Citrix session, verify that you have only one Citrix client installed on your machine—the Mercury version of the client. To verify that only one client is installed, open the Add/Remove Programs dialog box from the Control Panel and make sure that there is only one entry for the Citrix ICA client. 

e) Extended log 
You can view additional replay information in the extended log. To do this enable extended logging in the Run-Time settings (f4 Shortcut key) Log tab. You can view this information in the Execution Log tab or in the output.txt file in the script's directory. 

This technology can cut website load time by 30%

Based on a research done at Harvard University students... ...

Slow-loading Web pages are surely one of the top frustrations on the Internet today, but new technology from MIT and Harvard promises to change all that. Announced on Wednesday, Polaris is a framework that determines how to sequence the downloading of a page's objects for faster load times overall.

Created by researchers from MIT’s Computer Science and Artificial Intelligence Laboratory (CSAIL) and Harvard University, the new system promises to decrease page-load times by more than 30 percent -- with the potential for reductions of almost 60 percent -- by minimizing the number of network "trips" the browser must make.

When asked to load a given Web page, the browser must reach across the network to fetch objects such as HTML files, JavaScript source code and images. Sometimes, thanks to what are known as dependencies, evaluating one object requires fetching and evaluating others as well. A browser might have to execute a file’s JavaScript code in order to discover more images to fetch and render, for example.

“It can take up to 100 milliseconds each time a browser has to cross a mobile network to fetch a piece of data,” says doctoral student Ravi Netravali, lead author on a paper he'll present at next week’s Usenix Symposium on Networked Systems Design and Implementation.

"As pages increase in complexity, they often require multiple trips that create delays that really add up," Netravali added. "Our approach minimizes the number of round trips so that we can substantially speed up a page’s load time.”

Polaris automatically tracks all of the interactions among objects, which can number in the thousands for a single page, and creates a “dependency graph” for that page, enabling objects to be loaded in the optimal order for fastest speed overall.
Polaris is particularly well-suited for large and complex websites as well as mobile networks, because they tend to have larger delays than wired networks do, the researchers said.

Researchers evaluated the system across a range of network conditions on 200 of the world’s most popular websites, including ESPN.com, NYTimes.com and Weather.com.

Source:
http://www.computerworld.com/article/3042416/internet/this-tech-can-cut-website-load-times-in-half.html

Why the web pages will not be correctly displayed in the Vugen Run-Time Viewer?

Of lately I was asked (especially from a young team), Why the run-time viewer does not display anything (blank) for few responses? Why the pages appear differently in the run-time viewer?

Below is something I found on the HP Support site, Knowledge Article - KM171870. Thought of sharing as a Post so that it will be helpful to all Perf. testers.

In some cases, because of the limitations of the Run-Time Viewer it is not always possible to use it as a final verification tool. There are numerous complex Web applications that will not be correctly displayed in the Run-Time Viewer or errors may even be generated by the Run-Time Viewer in response to running the script. These problems do not necessarily point to problems with the script itself. It is important to be able to distinguish and isolate Run-Time Viewer errors from script errors (which can often be two distinct events).
The first step in understanding this is to gain an understanding of the basics of the way LoadRunner Web replay works when running in VuGen.
When a Web Vuser is run through VuGen, the default is to have the Run-Time Viewer open and also to have resources downloaded automatically by the script. These two settings coincide with what the user sees -- that is the script runs through and the resources are downloaded and displayed graphically in the Run-Time Viewer. Now, what is really happenning here are two seperate things (that areonly slightly related).
The first thing that is happening is that the VuGen Web replay engine is running the script through the Mercury Driver process (mdrv.exe), which actually takes the script and interprets it to run the script. This process happens independently of whether the Run-Time Viewer is opened or closed and is done the same way in VuGen as it is in the Controller (which runs a multithreaded version of the the driver process called mmdrv.exe).
The script's statements are executed and requests are sent to the server so it can return the data to the client. Note that with a website the normal progress of events goes like this:
1. Client connects to the server.
2. Client requests a document (usually an HTML file such as index.html).
3. Server responds by sending the requested document if it is found.

Example:
Here is a sample document.
<PRE>
<CODE>
<HTML>
<BODY>
<TABLE BORDER="2" NAME="happy_table" ROWS="3" COLS="2">
<TD>
< TABLE>
<TD><IMG SRC="Sample.gif" WIDTH="100" HEIGHT="150" ></TD>
</TABLE>
</TD>
<TD>
<TABLE>
<P><TR><TD><A HREF="./JDBC">JDBC</A></TD> </TR></P>
<P><TR><TD><A HREF="assign2.xml">Assign2.xml</A></TD></TR></P>
</TD>
</TABLE>
</BODY>
</HTML>
</CODE>
</PRE>

This document is returned by the server when a request is made for it by the client. The browser (client) then does a couple things with this returned document to process it for the user. In particular, with this example, the HTML document contains a table with two sub tables (one with a reference to an image and one with two hyper references.)
The browser constructs the tables and it sees that in one of these tables an image is being included in the table (note the IMG tag that specifies this). If image downloading is turned on in the browser (which in most browsers it is) then the following additional activities occur:
4. Client reconnects (if necessary) to the server.
5. Client requests the resource (the image specified in the <PRE><CODE><IMG ...></CODE></PRE> tag).
6. Server responds by sending the requested resource if it is found.

So, for one simple request to the server made by the user, two requests are actually generated by the client application (the browser) in order to display the complete webpage.

All of this happens in the background by the client in order to download ALL of the resources that may be referenced on a given webpage. This continues for any objects on the page including images (e.g., .gifs, .jpgs, etc.) as well as other objects like ActiveX controls and Java Applets in addition to other requests generated by JavaScript activities (such as rollover images). In general, the user is unaware these extra requests are being generated.

During replay with LoadRunner the same basic series of events is happenning. If Resource Downloading is turned on in the Vuser Run-Time Settings each resource mentioned on the webpage will be downloaded automatically by the LoadRunner Run-Time Engine during replay. Typically, what happens at this point is the webpage is downloaded and saved to a file (with a name like t#.html) in the "Result1Iteration#" directory that gets created in the Vuser script directory during execution. LoadRunner also stores the HTML in memory and parses through it to download all of the resources that are mentioned in that page. At this point if the Run-Time Viewer is turned OFF that would be the end of the replay events. However, if the Run-Time Viewer is turned ON, then the following happens. A reference to the document to retrieve is passed to the Run-Time Viewer as an input so that it will then go out to the network and retrieve the same document for display. It does the same thing as the LoadRunner Run-Time Engine and what a browser does -- that is, it will download all of the resources referenced on the page as well.

It is important to note that the Run-Time Viewer download of the page is secondary to the actual replay engine. There is no dependency between the two entities. To actually see the data being retrieved by the Vuser (using the replay engine) you can change the Vuser Logging options to enable "Data returned by server" under the Log tab. This will then print to the execution log all of the data returned by the server at run-time (again, regardless of the status of the Run-Time Viewer). This log is an authoritative account of the activity of the Vuser and the data being sent to it during execution.

One reason this is so important is the fact that errors can appear in the Run-Time Viewer that do not necessarily indicate script level problems. Because the Run-Time Viewer is an embedded browser component (basically built off of Internet Explorer components available within the system) it does not feature all of the capabilities of a real browser (like support for frams, complex scripting, andsome Applets and ActiveX controls). Also, because it is making requests outside of the Virtual User script there may be pop-up messages boxes prompting for user authentication (even though usernames/passwords may be included in the script via a web_set_user() function). Again, this is because the Run-Time Viewer is actually making requests independent of the script and thus the server demands authentication as though the request is coming from a seperate browser instance (which it is).

One way to see that this is true is to run the script with the Extended Execution Log and with the Resource Downloading in the Run-Time Settings turned OFF. When the script is replayed no resources will be downloaded by the script but the Run-Time Viewer will still display the resources (like images).

Troubleshooting the Run-Time ViewerIn general, problems and error messages that appear as pop-up messages boxes are limited in scope to being Run-Time Viewer limitations. With the Run-Time Viewer disabled, these same message boxes (usually reporting such things as scripting errors or asking for user authentication) will not be generated by the script replay. Although they appear as errors during script execution they are really display limitations of the Run-Time Viewer itself and not necessarily representative of script failure.
In addition, although there is some basic support for ActiveX controls, Applets and JavaScript, all of the functionality of these technologies will not work all of the time in the Run-Time Viewer. It is possible for simple instances to work in this environment (see http://java.sun.com when replayed in a Web script and you can see the applets displayed) but sometimes the application is to complex for proper support.

Problems that do get reported in the Run-Time Viewer as actual text displayed in the Viewer itself can indicate a problem during script execution. This may be because the requested page actually generates the same problem in the Run-Time Viewer as the underlying LoadRunner Run-Time Engine. As always, the best way to determine replay failure is to go back to the Extended Log that can be generated during script execution. This reports the client/server communication in full (with all extended log options checked) and can be used as a reference for understanding more about what the error that was generated was. A simple text search through the Extended Execution Log for some error message appearing in the Run-Time Viewer can show whether the problem reported in the Run-Time Viewer is actually occurring at the network level for the vuser itself.

Summary
The Run-Time Viewer displays the Web documents secondarily to the underlying Run-Time Engine and there is no interdependence on the two to operate properly.
Pop-up messages are often related to this because seperate requests are being made by the Run-Time Viewer from the Vuser.
There is some support for scripting and client side objects (like applets) but it also suffers some limitations (cannot display multiple frames, etc.).
Errors can best be diagnosed thoroughly through the use of the Extended Execution Log (which contains all the information about the requests and responses made during script execution). Generally, for easier debugging it can be helpful to turn OFF Resource Downloading (under the Browser emulation tab in the Run-Time Settings) so that the resources (usually binary data) are not recorded into the Execution Log (which clutters it with useless data).

Source: HP Knowledge Article - KM171870

String Manipulation Functions in Loadrunner scripting.

Business Scenario: correlate middle name from xml response. appending space to the string, string manipulation functions used

xml response :

<FullName>first middle last</FullName>

<FirstName>first</FirstName>

<MiddleName>middle</MiddleName>

<LastName>last</LastName>

OR 

<FullName>first middle last</FullName>

<FirstName>first</FirstName>

<\MiddleName>  (No Middle name)

<LastName>last</LastName>

place to substitute:

some places "first middle last" (2 space appearing in full name)

if there is no middle name "first last" (only 1 space)

so we decided to correlate the middle name (with "Notfound=warning"), 

if it exist append a space to it else no operation to be done.

below is the code:

Put a text checkpoint for <MiddleName> with savecount. if the middlename exists for the customer, "MiddleNameCount" will have a +ve non zero number. 

 if (atoi(lr_eval_string("{MiddleNameCount}")) > 0) //atoi function converts string to number.

    { 

lr_output_message ("MiddleName %s", lr_eval_string("{MiddleName}"));

                lr_output_message("appending space as middlename exist"); 

strcpy(Mname,lr_eval_string("{MiddleName}")); //copying the value

strcat(Mname,"%20"); //appendign space, %20 is the url format of space.

lr_save_string(Mname,"MiddleName"); //saving the appended string.

                lr_output_message("MiddleName is %s", "{MiddleName}");

    }  

explanation of notfound attribute in web reg save param : 

NOTFOUND: The handling option when a boundary is not found and an empty string is generated. 
"Notfound=error", the default value, causes an error to be raised when a boundary is not found. 
"Notfound=warning" ("Notfound=empty" in earlier versions), does not issue an error. If the boundary is not found, it sets the parameter count to 0, and continues executing the script. The "warning" option is ideal if you want to see if the string was found, but you do not want the script to fail.
Note: If Continue on Error is enabled for the script, then even when NOTFOUND is set to "error", the script continues when the boundary is not found, but an error message is written to the Extended log file. 
This attribute is optional.

Working with Multiple Actions

This Post will explain how to create block and to work with multiple actions.

We had received a request to carryout performance testing on a Russian marketing site, where users search for some Center information like shown in below snapshot.

While recording we found out that the Search strings actually recorded in junk characters, hence we couldn’t parametrize these Junk Char to randomize the search operations, Loadrunner couldn’t support parametrization for the junk characters.

"Name=region", "Value=ВолгогÑ\x80адÑ\x81каÑ\x8F облаÑ\x81Ñ‚ÑŒ

Either we should carryout the test with single query which would send only single string for search every time Or we can create multiple actions to perform search by creating multiple scripts with multiple search strings.

Solution we preferred:

1. We recorded multiple actions with multiple search strings on application.
2. We created a block in Run Time Settings under RUNLOGIC and assigned % that has to be run during the load test.

Refer Below snap shot for more details:

 

The Total % of block must be 100. For each action we can define our own % depending on volume you are retrieving from DB by running search operations.