Thursday, May 2, 2013

Let’s use web_save_timestamp_param function for something it doesn’t mean to do ;).

In my previous article, I have shown how to create unique file names in LR. Now, let’s see a simpler way using web_save_timestamp_param function. This function saves the current timestamp to a LR parameter. Timestamp is the number of milliseconds since 00.00 January 1st, 1970.

Use the below code in script:

web_save_timestamp_param("TimeStamp", LAST);
lr_output_message("Timestamp: %s", lr_eval_string("{TimeStamp}"));








You will get the following result :





One more thing to get unique name for each user we have to use lr_whoami function. So we can change our unique name generation script to following:

char uniquefilename[256];
int univuserid, uniscenarioid;
char *unigroupid;

lr_whoami(&univuserid, & unigroupid, & uniscenarioid); web_save_timestamp_param("TimeStamp", LAST);

sprintf(uniquefilename, "%s_%d_%d_%s",lr_eval_string("{TimeStamp}"),
univuserid, uniscenarioid, unigroupid);

lr_output_message(" Unique File name is: %s", uniquefilename);

Isn’t it the simplest way to generate unique names? You decide
J

How to verify the correct business flow at run time? Web_reg_find function explained.

As explained in my earlier post the web_reg_find function registers a request to search for a text string on a Web page retrieved by the next action function, such as web_url.

This function helps you verify whether or not the page you received is the desired page by searching for an expected text string. For example, you can search for the text "Welcome" to check if your home page opened properly. You can check for the word "Error" to check if the browser encountered an error. You can also use this function to register a request to count the number of times the text appeared.

If the check fails, the error is reported after the next action function executes. This function only registers requests, but does not perform them. Thus, the return value of web_reg_find indicates only if the registration succeeded, and not if the check succeeded.
Click here to know more

Attribute List
The attributes are passed in Name=Value pairs, for example: "Text=string". Either Text, or TextPfx and TextSfx is required. The rest of the attributes are optional.

Text: The text string to search for. Text is a non–empty, null–terminated character string. You can further customize your search by using text flags.

Text searches for a known string. TextPfx and TextSfx are used when the string is not known in advance, but you know what strings will precede and follow it. For example, when a user is issued a loginID, the server may return "Your new loginID is <loginID>". The loginID changes, but to confirm that a loginID was issued it is sufficient to confirm that there is some string preceded by "Your new loginID is ".

You must specify the following two attributes if you do not specify Text. You can further customize your search by using text flags with these attributes.

TextPfx: The left boundary for the search. This is the text immediately preceding the text string for which you are searching.

TextSfx: The right boundary for the search. This is the text immediately following the text string for which you are searching.

Search: The scope of the search—where to search for the string. The possible values are Headers (search only the headers), Body (search only the Body data), Noresource (search only the HTML body, excluding headers and resources), or ALL (search body , headers, and resources). The default value is BODY.

SaveCount: The number of matches that were found are stored in a parameter.

The SaveCount attribute assigns the number of matches that were found to a parameter. To use this attribute, specify "SaveCount=param". When the check is performed, param is assigned a null–terminated string representing a numerical value.

When the SaveCount argument is used, and the Fail argument is not used, the check does not fail whether the text is found or not. To check whether the text has been found, examine the value of the SaveCount parameter. If it is "0", the string was not found.

If both SaveCount and Fail are used, the Fail handling option specified works together with the SaveCount. Thus, if SaveCount is used with "Fail=NotFound" and the text is found, the SaveCount parameter is assigned the number of occurrences and the check succeeds. If the text is not found, the SaveCount parameter is assigned "0" and the check fails. Of course, if the text is not found and "Fail=NotFound" has been specified, the value "0" of the parameter is only useful if the run–time setting Continue on error is selected.

The value assigned to the parameter is retained between iterations until the first action function following the web_reg_find of the next iteration. Once the script perfoms the first action function following the web_reg_find of the next iteration, the count is updated. Alternatively, you can use the lr_save_string function to change the value of the parameter at the end of the current interation—for example, with lr_save_string("0", "Count").

Fail: The handling method that sets the condition under which the check fails.

Fail can be either "Found" or "NotFound". The default is NotFound.

"Fail=NotFound" indicates that an error occurs when the text is not found. You use NotFound when searching for the text you expect to find if the Web request succeeds.

"Fail=Found" indicates that the check fails when the text is found. You might use Found, for example, searching for the word "Error". If you find "Error", the Web request did not succeed, and you want the check to fail.

When "Fail = Found" is specified with TextPfx and TextSfx and the left and right boundaries are found more than once, each match is issued as an error up to the maximum number of errors configured in the Run-Time Settings > Preferences > Advanced Options. Subsequent matches are logged as informational messages.

ID: An identifying string that associates the entry in the log file with the call to web_reg_find.

How to verify the correct business flow at run time?

The basic prerequisite for load testing is you should be assured that your application works correctly. The business flow verification can be performed by using LR content verification function web_reg_find.
So let’s see how to add LR content verification?
Take an example of banking application record a simple flow of opening start page, log in the application, and log out.

Now, open the script in Tree View (with menu 'View/Tree View')

1.    Select initial step ('Url: Banking Application).

2.    Select the text you would like to check on the page and right click; use default settings in 'Find Text' dialog.

3.    Open LR script in Script View (menu 'View/Script View')

You will see that web_reg_find function has been just added before the first function as shown below:
web_reg_find("Text=Welcome", "Search=Body", LAST);
web_url("Banking Application", "URL=...", ...

Lets check out web_reg_find function.
Click here to know more

The web_reg_find function registers a request to search for a text string on a Web page retrieved by the next action function, such as web_url.

This function helps you verify whether or not the page you received is the desired page by searching for an expected text string. For example, in this example you can search for the text "Welcome" to check if your home page opened properly. You can check for the word "Error" to check if the browser encountered an error. You can also use this function to register a request to count the number of times the text appeared.

If the check fails, the error is reported after the next action function executes. This function only registers requests, but does not perform them. Thus, the return value of web_reg_find indicates only if the registration succeeded, and not if the check succeeded.
Please note if the string is not found, it fails and the script execution stops.

I will explain various attributes of web_reg_find function and also show how to handle the above situation using error handling code.

So stay tuned for next post J…Happy Load running!!!

How to save value of one parameter to another?

It’s so simple to save value of one parameter to other parameter.

1.    Evaluate value of first parameter using lr_eval_string function.
lr_save_string("Parameter Value of param1", "param1");
lr_output_message(lr_eval_string("Value of param1: {param1}"));

2.    Save the evaluated string to a second parameter using lr_save_string function.
lr_save_string(lr_eval_string("{param1}"), "param2");
lr_output_message(lr_eval_string("Value of param2: {param2}"));

Click here to know more
Now execute the script and check the result. Both parameters (param1 & param2) have the same values - "Parameter Value of param1".

Mission Accomplished!!!

Can we define our own header files and functions in Load runner? Yes, the art of reusing special codes in LR scripts.

Suppose, while working in Loadrunner, you create lots of scripts and you face a situation when your code is repeated in many scripts. In this case you have a choice to reuse the code and reusing is a better move. Write once use many times that’s how smart people work.

Click here to know more
How?

Create a header file with the function or code you have written. Let's write a function for calculating sum of three values:
my_sum(2, 6, -4)

Open your notepad, create new file and write this code:
#ifndef _MYSUM_H_
#define _MYSUM_H_
int my_sum(int nArg1, int nArg2, int nArg3)
{
return nArg1 + nArg2 + nArg3;
}
#endif // _MYSUM_H_

Now, save this file as "mysum.h" into "<Loadrunner installation directory>\include” folder. You can give any name to this header file here I have given it mysum as I have defined it and it is performing sum operation.
 
We have created the library file and to include it in script, use #include
preprocessing directive in Action part:
#include "mysum.h"

It’s over. I mean it’s done ;)

Write the below code in action and run the script:

int sum;
sum=my_sum(3,4,-5);
lr_output_message(“The sum is %d”,sum);

Now I will tell you why we should take pain to reuse the code, I have damn strong point to support my idea:

1.    If you use duplicated code, you have to edit each occurrence of this code.

2.    If you decide to change something as if an algorithm, implemented in a duplicated code, you are unwilling to find and edit it in each occurrence of this code.

3.    If you have tens or hundreds scripts, containing duplicate code. Rework will cost you lot of $s. So, avoid it as prevention is always better than cure. J

How to check for HTTP errors while recording scripts?

This is much easier than it sounds, by HTTP errors I mean the page which has images which do not get displayed or which gives HTTP status codes 404 i.e. page not found.

You just have to do some settings in the recording options.

Click 'Options' button from 'Start Recording' window. 'Recording Options' window appears.

Go to ‘Advanced’ tab and check the box specifying 'Add comment to script for HTTP errors while recording'.

Mission Accomplished!!!
Click here to know more

Click ‘OK’ to start recording.

Whenever LR will find any HTTP errors that will be included as comments into script.
These inserted comments will describe all occurred HTTP errors and contain URL and server response which can be used to determine reasons of HTTP errors.

How to generate unique file names?

While running load test it is quite possible that two or more users will create a file so to make it unique, we need some parameters that are able to differentiate these created files and this can be done by using Vuser ID, Iteration Number, Date and Time stamp.

Again, just a three step process ;)
Click here to know more

Step 1: Go to tab Vuser > Parameter list and create three parameters:
  1.  First one: Name unique_vuser; Type Vuser ID.
  2. Second one: Name unique_ itr; Type Iteration.
  3. Third one: Name unique_ dt; Type Date/Time.
Note: Use the Date/Time format - "%Y%m%d_%H%M%S.000".
This format means Years Months Days Hours Minutes Seconds Milliseconds. Using this we will get string like:  
20130421_100523.786

Step 2: Write the below code in the script:
lr_output_message(lr_eval_string("{unique_vuser} _{unique_itr}_{unique_dt}"));
This will generate unique string for the current LR Vuser and you can save the current file as “5_4_20130421_100523.786.pdf”.This implies 5th Vuser 4th iteration and 21st April 2013, ten past five twenty three seconds and 786 milliseconds.


Wow, you did it in two steps only. Congrats!!! Nice move ;)

How to get iteration number of the current running iteration?

Hey friends, sometimes we have to know the current iteration number, while running the test. We can get the current iteration number by using LR parameter of 'Iteration Number' type.

Step 1: Go to tab Vuser > Parameter list and create parameter setting name as ‘current_ itr’ and select its type Iteration.

Step 2: Click 'Close' button in 'Parameter List' dialog.
Step 3:  Now, we have to insert the below code into LR script lr_output_message("Current iteration number is: %s", lr_eval_string("{current_ itr}"));


Click here to know more
Bingo! Script is ready to be served. Just a bit of garnishing is required to make it fool proof. Press F4 runtime settings window opens go to run logic tab and set the number of iterations to 6(my lucky number ;)). Click ok and press F5 and see the results in the replay log.

Why we have to parameterize the values in LR scripts?

As already mentioned in the previous article () we have the below four situation, where we need to parameterize the values.
1.    Unique constraint
2.    Date constraint
3.    Data dependency
4.    Data caching
Click here to know more

1.    Unique constraint: This is the first reason to parameterize is to accommodate any field that requires a unique value. Suppose we take banking application while a virtual user is logged in with the username ‘Sam’, any other user who tries to log in with the same username will get an error, causing a failure in the execution of the test script. Since each login attempt needs unique value we have to provide a unique username, a static value in a script will not work.

2.    Date constraint: A date recorded into a script yesterday may be invalid today. This is a problem that can be remedied through the use of parameterization. For example take an example of gym application for setting up meeting with physical trainer in this case it is quite possible that a script generated a week prior to the test run worked fine on that day, but is now causing errors in the test execution. This can be fixed with a parameter that will always select a current date +1 for the meeting schedule.

3.    Data Dependency: In this case the parameterized value for an object on the application determines what values are valid for another object on the application. As we take the example above, the login Password is dependent on the User Name. If the username does not change, then the password will always match. If the User Name field is parameterized, however, then the value will change during test iterations. Since there will only be one valid password for each given User Name, the Password field is data-dependent on the User Name field. Hence, the Password field must also be parameterized with passwords that match the usernames.

4.    Data caching: Parameterization reduces or eliminates the effects of data caching. Data caching problems will not cause your script to fail, but they may cause load test result to be misleading. For example, an application is being tested to ensure that data requests return results within an average of 2 seconds. First, we run an unparameterized search, then a parameterized one. When the first virtual user makes a request, the information is retrieved from the database and is returned in 3 seconds. Since the data was just retrieved, a copy is now available in the data cache. When the second and third users request the same data, they retrieve the data from the cache at a much faster rate. The average seek time for these three users is 1.5 seconds, which would appear to be under the benchmark. But since real users will not always request the same data, the average seek time is unrealistically low. With a parameterized script, each virtual user is searching for a different string of data, so requests are processed by the database instead of the cache.

Stay tuned for more funJ.  Yes, of course Load running is always a fun ;)

What are LR parameters and how they differ from variables that we declare?

When recording a script, any selection we make is recorded as part of the script. If we are viewing a banking site and transferred $250 then the value $250 is hard-coded into the script. To parameterize the script, we replace hard-coded data, such as the value $250 with a placeholder. This placeholder, called a parameter, is then used to introduce a variety of input values into the application during testing. Parameterizing the script eliminates problems that can cause errors in your testing or produce misleading load test results.

There are four situations where we need to parameterize the values.
1.    Unique constraint
2.    Date constraint
3.    Data dependency
4.    Data caching
Click here to know more

I will explain all these constraints in my next post J. You have to believe me.

Now, the difference between LR parameters and variables that we declare (stack variable)
1.    Allocated Memory: For LR parameters we never have to give the memory size that we need to allocate for it, that is defined automatically by LR but for stack variables that we declare we have to give memory size.
2.    Types: The types of LR parameter are different from that of stack variables. For example iteration number and int are different types.
3.    Data Value source: The values of parameters are stored in a file (most of the cases) and best part is that we don't have to write additional code for file processing. LR does all that by itself.

Thank you so much Mr. Loadrunner for making my life so easyJ.