The web_url/web_custom_request/web_submit_data functions automatically detects a 302 response from the server and redirects to the location specified in the response header.

The problem with automatic redirection in LoadRunner is that you will NOT be able to figure out the amount of time it takes for each redirected request. Redirects are invisible to the user in LoadRunner. But in few test requirements you would want to know the break up of response timings between primary hit and the redirected server hits. The bigger problem comes in when you are dealing with recursive redirects.

To make an explicit redirect request you will first have to turn off automatic following of redirect instructions. This can be accomplished by setting MaxRedirectionDepth to ’0′. The key thing to remember is to identify redirected location by analyzing “Location: http://” line item in the HTTP response header of the request in question.

Example:

//In your action file
Place this in the beginning of the action file

web_set_option("MaxRedirectionDepth", "0", LAST ); //This is the key

recursiveRedirect_open();
web_url("url_which_gets_redirected","http://sampleredirect.com/",LAST);
recursiveRedirect_close();

Here is how you do it:

//place this in global.h

int HttpRetCode;
int i=0;
char depthVal[10];
char cTransactName[20000];

recursiveRedirect_open()
{
	web_set_max_html_param_len("10000");

	web_reg_save_param("cRedirectUrl",
			    "LB=Location: ",
			    "RB=\r\n",
			    "notfound=warning",
			    "Search=Headers",
			    LAST);

	web_reg_save_param("cTransactionName",
			    "LB=https://Domain.com/",
			    "RB=\r\n",
			    "Search=Headers",
			    "notfound=warning",
			    LAST);

	web_reg_save_param("httpCode",
			    "LB=HTTP/1.1 ",
			    "RB= ",
			    "Search=Headers",
			    "ORD=1",
			    "notfound=warning",
			    LAST);
}

recursiveRedirect_close()
{

	HttpRetCode = atoi(lr_eval_string("{httpCode}"));
	lr_output_message("xReturnCode=%d",  HttpRetCode);

	if(HttpRetCode == 302)//If redirect
	{
		i++;
		web_reg_save_param("cRedirectUrl",
			    "LB=Location: ",
			    "RB=\r\n",
			    "Search=Headers",
			    "notfound=warning",
			    LAST);

		web_reg_save_param("cTransactionName",
			    "LB=https://https://Domain.com/",
			    "RB=\r\n",
			    "Search=Headers",
			    "notfound=warning",
			    LAST);

		web_reg_save_param("httpCode",
			   "LB=HTTP/1.1 ",
			   "RB= ",
			   "ORD=1",
			   "notfound=warning",
			   LAST);

sprintf(cTransactName, "Redirect_depth_%d_%s", i,lr_eval_string("{cTransactionName}"));
lr_start_transaction(cTransactName);
web_url(cTransactName, "URL={cRedirectUrl}", "Mode=HTTP", LAST);
lr_end_transaction(cTransactName, LR_AUTO);
HttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);
recursiveRedirect_close();

}
else
{
	return;
}

}

The above code automatically generates new transactions for each unique follow redirect request’s made by the script. It keeps a track of the HTTP response code of each request and exits from recursion state when the response code is not 302.

The first challenge is to find the requests in the script which has URL redirections. If you find it hard to identify the locations where redirects are performed in the script, run the script after including web_set_option(“MaxRedirectionDepth”, “0″, LAST ); with standard log enabled. After the script completes executing, check the logs for “redirection depth exceeded” message, because whenever a web server prompts for a redirection of the resource, it sends back a 302 HTTP code with the new location, but since MaxRedirectionDepth is set to 0 in LoadRunner it will not explicitly hit the new URL. This is where the above script comes into play. Now, double click on that line, and Vugen will highlight the step where the redirection was attempted. Now place the recursiveRedirect_open() and recursiveRedirect_close() function call at the start and end of the concerned step/request and you should be good to go!

here is the code…

Note: To adjust the radix/floating point position...you will have to further customize this function.

ftoa(float floatNum, char *convFloatString)
{

 char new[10];
 float number,dTemp,temp_val;
 int base, floatVal, radxFlag;
 char *token;
 char *temp;
 char cfloatVal[10], cBase[10];
 char cfloatValx[10] = "0";
 
 int DEBUG = 1; //Turn DEBUG OFF/ON by switch 0/1

 radxFlag = 0;

 //Separate the number before and after the "."
 number = floatNum;
 base=number;
 dTemp = number-base;

 if(DEBUG == 1)
 {
   lr_output_message("Base Value = %f\n", number);
 }

 sprintf(cBase, "%d", base);

 if(DEBUG == 1)
 {
  lr_output_message("Floating Value = %.2f\n", dTemp);
 }

 if(dTemp == 0) //If number is a whole number then return!
 {
  lr_save_string(cBase, convFloatString);
  return 0;
 }

 sprintf(cfloatVal, "%.2f", dTemp); //Place the decimal point to suit your requirement. Default is 2

 temp = (char *)strtok(cfloatVal, "0.");

 temp_val = atoi(temp);

 if((dTemp - 0.1) < 0)
  radxFlag=1; 
 else
  radxFlag=0;

 if(temp_val == 0)//If decimal values equals to 0 then return!
 {
  strcat(cfloatVal, ".00"); //increase the number of zero to suit your requirement.
  lr_save_string(cfloatVal, convFloatString);
  return;
 }

 if (radxFlag ==1)
 {
  strcat(cfloatValx,temp);
  strcpy(temp,cfloatValx);
 }

 if(DEBUG == 1)
 {
  lr_output_message("Final decimal value  = %s\n", temp);
 }

 
 if(strlen(temp) == 1 && radxFlag == 0)
 {
  strcat(temp,cfloatValx);
  //strcpy(temp,cfloatValx);
  if(DEBUG == 1)
  {
   lr_output_message("Appending a 0 %s", temp);

  }

 }

 strcat(cBase, ".");
 strcat(cBase, temp);

 if(DEBUG == 1)
 {
  lr_output_message("Final decimal value  = %s\n", cfloatVal);
 }

 if(DEBUG == 1)
 {
  lr_output_message("Final coverted floating number = %s", cBase);
 }

 lr_save_string(cBase, convFloatString);

}

 Sample usage:

 float floatNum;

 floatNum = 34.102;
 
 ftoa(floatNum, "convFloatStr");

 lr_output_message("Converted String = %s", lr_eval_string("{convFloatStr}"));

 return 0;

void web_reg_save_param_custom(char *sourceStr, char* outpuStr, char *leftBdry, char *rightBdry)

{
	char *st1, *st2;
	int result, i = 0;

             i=strlen(leftBdry);
	st1 = (char*) strstr(sourceStr, leftBdry);

	if (st1 != NULL){
		st1 += i;
		st2 = (char*) strstr(st1, rightBdry);

		if (st2 != NULL){
			result = st2 - st1;
			*(st1 + result) = '\0';
		}
	}

	if ((st1 == NULL) || (st2 == NULL))
		lr_error_message("Error: No substring found for the specified boundary");
             else
    	             lr_save_string(lr_eval_string(st1), outpuStr);

}

Usage example:

web_reg_save_param_custom(lr_eval_string("{originalString}"),"outputString","token", "endKey" );

The function call shown above fetches a substring from the “originalString” parameter and saves it in “outputString” paramater based on the Left and Right boundary values – “Token” and “endKey”. So if “originalString” param had the value “xyzToken3234344endKey,” the outputString parameter will contain the value “3234344″

In the previous post I mentioned about Search And Replace function. To serve the purpose of an example, I have recreated the same Search And Replace function in VC++(2010) expresss edition and built a DLL file.

Below is the code that I created in VC++

#include "stdafx.h"
#include "C:\Program Files\HP\LoadRunner\include\lrun.h"

extern "C" __declspec( dllexport ) int lr_searchReplace(char* inputStr, char* outputStr, char lookupChar, char repChar);

int lr_searchReplace(char* inputStr, char* outputStr, char lookupChar, char repChar)
	{

    	char *ptr =inputStr;
		char xchar;
		int len=0;
		int i=0;

		lr_output_message("%s",inputStr);
		xchar = *ptr;//Copy initial
		len=strlen(inputStr);
		while (len>0)
		{

			len--;
			xchar = *ptr;
			if(xchar==' ')
			{
				inputStr[i]= repChar;

			}

			ptr++;
			i++;

		}

	  lr_save_string(inputStr,outputStr);
      lr_output_message("%s",inputStr);

	  return 0;
	}

Before attempting to build this dll project in VC++, ensure that you have included lrun50.lib in the aditional linker file settings which is in Project Options, else the project won’t successfully build/compile. lrun.lib should be present inside \lib folder. Also make sure you include the lrun.h header file as shown in the above code snippet.

After the project is built, dig into the debug folder to find the dll file and then copy it inside the LoadRunner script folder and use it as shown below:

Action()
{
   lr_load_dll("SearchNReplace.dll");
   lr_save_string("this is a dummy text", "cProjectName");
   r_searchReplace(lr_eval_string("{cProjectName}"), "convProjName", ' ', '+');
   lr_output_message("%s",lr_eval_string("{convProjName}"));
   return 0;
}

Download Link for Sample URL = SearchNReplace

Note: Space – ‘ ‘ is the input character or lookup character and ‘+’ is the character which will be replaced in the place of the lookup character.

Note that the input string is = “chaitanya m bhatt” . In this name the lookup character is space – ‘ ‘.
The expected output string is = “chaitanya+m+bhatt” since the variable repChar is set to ‘+’.

void lr_searchReplace(char* inputStr, char* outputStr, char lookupChar, char repChar)
	{

    		char *ptr =inputStr;
		char xchar;
		int len=0;
		int i=0;

		lr_output_message("%s",inputStr);
		xchar = *ptr;//Copy initial
		len=strlen(inputStr);
		while (len>0)
		{

			len--;
			xchar = *ptr;
			if(xchar==lookupChar)
			{
				inputStr[i]= repChar;

			}

			ptr++;
			i++;

		}

	  lr_save_string(inputStr,outputStr);
               lr_output_message("%s",inputStr);

	}

1.0 Plan your Business Process scripting effort

Successful performance testing relies on in-depth understanding of the application, the business requirements of the customer and careful planning of the script development phase.

1.1  Gather relevant data
Make sure you get the document that describes the business objectives of the application, maps the customer environment and provides the most appropriate solution at each stage of deployment. This document provides the foundation for the scripting effort and must be created before the script planning and development by the business analysts/Solution Architects.

• Understand the organization’s goals
• Identify the key IT-enabled business processes to achieve these goals
• Meet the stakeholders
• Identify pain points and current state of environment
• Map and analyze the tested applications
• Define the project deliverables and objectives
• Plan the test environment
• For further details refer to the Performance Testing Product Best Practices document.

1.2 Map the application
Get familiar with the application you’re about to test. Understanding the real user workflows that map together and form a business process is the most important step to creating the script design.   With a thorough script design, the emulation of real user interaction is legitimate, traceable, and logical.  Technical errors are more easily discovered through good test design, and logical errors do not become an issue. Additionally such step might be helpful to detect certain actions that may need special attention (e.g. a web page that often returns an error in a web based application). Interview the system administrator and the application developers (if available) and learn how the application works and its internal architecture. Focus on gathering the following data for each application:

• How the applications is being used by its regular users
• Application architecture (2/3 tier client/server, ASP/Java, etc)
• The internal process of the application and how they work
• Protocols used (HTTP, JavaScript/JSP, Tuxedo/JOLT, etc)
• Development Source: Vendor or in-house, or combination?
• Communication paths to the application (WAN/LAN, link speed, known congestion issues)
• Security issues (firewalls, username/passwords etc.)
• Data required to interact with the application.

1.3 Create the Performance Testing requirements document
The Performance Testing Requirements document is the cornerstone of any Performance Testing project. It must include precise definitions of what would be achieved during the project implementation and set the Performance Testing strategy. Within the Performance Testing Requirements document should reside Use Case scenarios that define the business processes necessary to emulate the load.  Thus, this document becomes the basis for the script design, and should contain the following aspects:

• Business processes that need to be tested.
• The flow of each business process.
• Key Performance Indicators (KPI)s per business process.  KPIs map what the expected results of the script execution should indicate.  For example, a KPI for a script that emulates a login-logout business process would be the number of seconds that is appropriate for the transaction to be considered acceptable.

Make sure you get the stakeholders approval for the test plan before moving forward.

1.4 Plan the Performance Testing
Performance testing in a pre-production environment should be the final step before deploying applications into production. One of the significant contributors to the high cost of application testing is duplication of script development efforts.  In order to reduce such inefficiencies, the planning phase should begin weeks before the actual script development and can be performed during other functional testing efforts. In this stage create the detailed Performance testing plan. The plan should cover the following aspects of performance testing:

• Decide which functions should be tested.  These functions represent the business processes of real users interacting with the system under test
• Identify the required Performance test types/Performance test cases.
• Align the application lifecycle with the available tests. Make sure that the performance tests you have chosen are suitable for the application lifecycle (development, pre-production or production).
• Define in detail the performance test scenarios.

1.5 Validate the test environment

1.5.1 Align with the production environment
It is important to run Performance tests against an environment that is as similar as possible to the production environment; otherwise this could lead to inaccurate test results.
The performance test environment requires at least two sets of testing environments:

• Production infrastructure
• Test environment

Note: Normally most of the performance testing would be done in the test environment; however there are situations where the business requirement would be to run certain performance tests on the production environment to validate its readiness for the next business day.

1.5.2 Decide what to script
Analyze the Use Case scenarios and understand the impact they have on the system under test.  Oftentimes, several Use Case scenarios have the same effect when executed, making the scripting of them redundant.  Therefore, it is efficient to identify these redundancies and decide to script only a small subset of the larger set of business processes.  For example, the “login” use case and the “logout” use case both impact the same middleware code and the same database tables, so it may not be necessary to script both processes and execute them.

There are three criteria for deciding what to script:

• Volume:  the most common business processes that generate the highest total number of interaction.
• Dynamic Content:  The business processes that cause the most workload for the system, especially workload that involves dynamic information to be produced.
• Mission Critical:  Not necessarily those business processes which fulfill the above two requirements, but are use cases that are considered the most important aspects of the application usage.

Normally you will find that the Pareto 80-20 rule applies in such situations: 20 percent of the transactions cause 80 percent of the system load. Identifying those 20 percent in the script design phase (and deciding they are the most relevant to your script) ensures that every performance test accurately mimics the load generated by users.

1.6  Scripting design document

Prepare a script design document which explains the Use Case Scenarios and fulfills the framework of the overall Performance Test Plan.

• The script design document should contain, at minimum, the following details:
• The Business Process name (and the technical script name that represents its emulation).
• The Performance Test to which the script is being executed for.
• The specific transactions within the script that are being measured for performance (the script may itself be measured, as well as individual steps within it).
• The KPIs that will contrast the results of the transactions against expectations.
• Technical issues (such as protocol considerations, network considerations, etc).
• Environmental configuration (mapped to the Run-Time Settings of the Performance test scenario).
• Data considerations.

Here is when “lr_set_debug_messag()” comes in handy. All you have to do is place this function above the request which generates the response from where you intend to debug your script.  Make sure that you turn off Extended Log option in the Run-Time settings when you use this function. This measure ensures that your extended log option is triggered only at places where you want them and hence will save you huge amount of time while debugging.

In the below example, I have created three functions and I generally place these functions inside global.h section of my script. During debug cycles, I just call “logs_on()” function when I need extended log(with data returned from server and parameter substitution details enabled) for a certain server response and I use “logs_off()” function at the line in the script from where I don’t want anymore logs to be displayed.  And I use “logclear()” function when LoadRunner doesn’t respond to logs_off() function(It is a known defect.)

logs_on()
{
lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |LR_MSG_CLASS_RESULT_DATA| LR_MSG_CLASS_PARAMETERS , LR_SWITCH_ON );
}

logs_off()
{
lr_set_debug_message(LR_MSG_CLASS_EXTENDED_LOG |LR_MSG_CLASS_RESULT_DATA| LR_MSG_CLASS_PARAMETERS , LR_SWITCH_OFF );
}

void logclear(void)
{
unsigned int log_options = lr_get_debug_message();
lr_set_debug_message(log_options, LR_SWITCH_OFF);
return;
}