Debugging a LoadRunner script

Each performance engineer has his own style of debugging and is comfortable one of the approaches. While the following approach doesn’t claim to be the best approach, it sure helps with an approach for the beginners and act as a quick reference for the hands on guys as well.

·         One request at a time - While some go with one concept at a time, this approach suggests to go with one request / transaction at a time. During the debugging process, place a return -1 or return 0; after the transaction to ensure that replay of the script goes only until the transaction that we are currently working. Apply all the concepts like parameterization, correlation, page verification, think time and transactions for this transaction and replay to ensure that the script is working fine until the current transaction.

Note: return -1 will stop the execution of the script whereas return 0 will stop only the current iteration. To understand the difference, try setting the Runlogic to more than 1 iteation.

·         Correlation Challenges: The most probable reasons that a dynamic data is not captured is

o   The Left and right boundaries defined in the correlation function can be wrong – Be sure to check for the additional spaces, Tab Vs. spaces, escaping the double quotes

o   The placement of correlation function – Majority of the cases, the dynamic data should be available in previous request’s response. However, this may not be true always. Be sure to identify the request that receives the response with dynamic data and the correlation function should be placed above such request

o   Size matters – if huge dynamic data (Ex: Viewstate) is to be captured, be sure to specify the max length of the LR parameter by using the function web_set_max_html_param_len() function before capturing the dynamic data

o   Ensure dynamic data is generated by server – While 95% of the cases the dynamic data is received in server response, there is also a chance that the dynamic data is generated by client side java script as well (Ex: Hashcode generator). In such cases, the java script code needs to be identified and integrated with the script using web_js_run() function

·         Headers are crucial – LoadRunner is able to handle all the standard headers by default. However, if the request contains custom headers, those need to be added in the script explicitly with the functions web_add_header() / web_add_auto_header(). The easiest way to identify if the script is missing on any custom headers is to compare the snapshot information / Advanced trace in Log settings with network sniffing data (either from Developer tools or Fiddler session’s data)

·         Encoding data – web_url() and web_submit_data are capable of handling URL encoding automatically whereas the web_custom_request expects the form data as is. Hence, if the raw data of the request contains the URL encoding, be sure to convert the text into URL encoded form by using the function web_convert_param()

     As long as the request triggered from LoadRunner is same as the one from the browser, the scripts should work fine without any issues. Simulating the exact same request to that of the browser is the key while debugging the script.

String Replacer function for LoadRunner scripting

This article discusses the replacer function that may be needed in LoadRunner scripting. We use web_reg_save_param_ex() / web_reg_save_param() function to capture the dynamic data from the server response. One of the attributes that this function supports is the "Convert" either from HTML_TO_URL or HTML_TO_TEXT.

One can also use the function web_convert_param() explicitly to convert the HTML content to either URL encoded format or to a Plain Text. However, this function may not serve purpose all the time and sometimes a performance tester may need to convert a captured value to something else by explicitly replacing a sub-string with another.

For example: The dynamic value captured from the server response is "Welcome To Performance Testing Training Online" and the next request sends the data Welcome**To**Performance**Testing**Training**Online". It is clear that the Space in the dynamic data is replaced by **.

To replace every space in the dynamic data with  **, the string replacer function below is helpful.


char *Replacer(char *capValue, char *replace, char *replacewith)
{
char *pos;
int offset;
char output[1000];

pos = (char *)strstr(capValue, replace);
strcpy(output, "");
while(pos!=0)
{
offset = (int) (pos - capValue);
strncat(output, capValue, offset);
strcat(output, replacewith);
capValue = (char *) (pos + strlen(replace));
pos = (char *)strstr(capValue, replace);
}
strcat(output, capValue);
//lr_output_message("%s", output);
return output;
}

All that is needed is you can add this code before your action function or you can Add new files to script and copy paste the code there so that the function can be reused any number of times.

All that you need to do is call the function as below:

temp = Replacer(lr_eval_string("{DynData}"), " ", "**");
lr_save_string(temp, "ModDynData");

With the above two statements in your action block, all the spaces in dynamic data are replaced with ** and the modified data is saved to an LR parameter called "ModDynData".

Please note that the above function primarily depends on the strstr function to identify all the spaces in the dynamic data. To understand better about the strstr function, please read my previous blog.

If you like this blog and article please click on +1 or comment. Please feel free to share about this blog with your friends.