Using parameters in Loadrunner VuGen script

Parameterizing is a powerful thing in LoadRunner!
Now, I'm going to demonstrate some tips and uses of them.

Well, imagine the following situation...

Let's we have created VuGen script, which emulates the one user:

The problem: script runs correctly in VuGen for one user, but it fails for several concurrent users. This happens since we recorded the VuGen script for the specific user:
I marked "username" and "password" parameters and values with red lines.
Application under test (AUT) does not allow several sessions of the same user.
So, if second concurrent VuGen user logs in to application, he gets an error:
The solution: to parameterize the VuGen script.

Implementation:

1. Right click on a value we want to parameterize (in our case this is a username - "load1") and select "Replace with a parameter" menuitem:
   
   
2. Name the new parameter as "UserName" and click OK btn:
   Please, pay attention to "Parameter type" combobox. It contains interesting possible types, such as: "Date/Time", Iteration Number, Random number, even XML, and others.
   I will not describe them in the present post... I hope, I will have a chance to describe parameter types later. In any case, it depends on the opinion of the blog readers :)
   
   
3. Wow! the value "load1" will be changed with a UserName parameter:
   We have just added the new parameter! It's wonderful, isn't it, dear friend? :)
   But where can we specify the real values for our parameter? How to configure it?
   Let's continue...
   
   
4. Right click on the just added parameter and select "Parameter properties":
   By the way, this menu allows others operations with parameters. You can:
   
   • "Restore original value (load1)"
     In other words, rollback your changes
   • "Replace more occurrences" This menuitem will find for the initial string ("load1") in the script and will propose to replace it with the new parameter ({UserName}).
     
     Tips: Please, use this feature carefully. For example, let's there is "http://server/load1.htm" link in the script. Here, "load1.htm" is a name of page, but user. "Replace All" will produce incorrect link - "http://server/{UserName}.
     
     
5. "Parameter properties" will be shown:
   
6. This dialog is a "heart" of any parameter. You can here:
   
   • specify the type of the parameter
   • create the pool of values for any parameter (add new values for any parameter)
   • specify, how the parameter will be changed against interations and users
   • and other different settings...
   
   Tips: You can open dat-file (UserName.dat) and edit its content in the Notepad or Excel. MS Excel is useful if file contains values for several parameters.
   
   Tips: I recommend to read the LR Function Reference, topic "Data Assignment and Update Methods for File/Table Parameters". It contains the excellent table describing Update and Data Assignement methods ("Update value on" combobox and "Select next row" combobox correspondingly). There are explanations with examples which describes - what settings should be applied for your case.
   
   In the issue, the filled dialog will look like:
   These settings specify:
   
   • the list of values to be used ("load1", "load2", "John21", etc.)
   • update method ("Once") and data assignment method ("Unique").
     The combination means: "The unique value assigned in the first iteration is used for all subsequent iterations of the Vuser"
     So, that's exactly the same we need.
     
     
7. After that I perform the similar procedure (steps 1-6) for "Password" parameter:
   Please, note:
   
   • You can store parameters in the one dat-file. As for me, I prefer this way. Separating test data from the code is a good idea. And using one data-file is very convenient.
   • In this post I use two dat-file. Just for demonstration...
     
     
8. Ooh! Everything is completed I hope. Now, we have to create a scenario, add parameterized LoadRunner VuGen script and execute it :)
   Here you are:
   All transactions passed. In other words, all concurrent user logged with their unique login/password combination. Each user had his own session.

The summary: Parameterizing allows simplify load/performance testing:

1. Instead of writing a separate LoadRunner VuGen script for each virtual user, we added parameters for specific information (username & password) and used the one script for all users.
2. Parameterizing allows decrease maintenance cost. If application under test is changed, one test should be updated for 100 (e.g.) users, but 100 tests for each user
3. Supporting of tests is a real pleasure :) To add new user, a test has to update dat-files only.

All three advantages is the result of data-driven testing methodology.
I plan to describe later how to write data-driven tests, what concepts should be used, and so on.

---

Related articles:

• Using Correlation in LoadRunner scripts - visual tutorial
• What are LoadRunner parameter and parameterization?
• Boundaries for web_reg_save_param LoadRunner function?
  
• How to perform basic operations on LoadRunner parameters?
• LoadRunner Correlation - How to capture an array of dynamic data with web_reg_save_param function
• How to get LoadRunner iteration number - using LoadRunner parameter?

---

How to detect memory leaks with LoadRunner - visual tutorial

Today, I plan to share my experience on the memory leaks detecting. This article is a step-by-step instruction on how to use HP/Mercury LoadRunner to perform load testing for the purpose of memory leaks discovering.


The task:
It needs perform testing of Web server to discover memory leaks.

The solution:

1. Create LoadRunner VuGen script for your application (Web server in my script)
   Let's suppose, we have done it:
   
   Actually, I will explain different tricks and features of VuGen scripts in the further posts.
   
2. Create LoadRunner Controller scenario for your application using the VuGen scripts.
   Here it is:
   
   
3. The next step is to add measurement monitors which are quantitative indicators of resources being monitored (for example, memory usage, CPU usage, handle and thread count, and so on).
   For that, on "Run" tab in the LoadRunner Controller, drag "Windows Resources" item from the "Available Graphs" tree and drop it to graphs area.
   See the screenshot:
   
   Then right-click on the just added graph ("Windows Resources") and select "Add Measurements" from the pop-up menu.
   "Windows Resources" dialog will be shown:
   
   The following actions are easy. I will add the name of server where the application (Web server in my case) will be run. This server can be a remote one. In this case, you have to make sure that LoadRunner will have an access to get info from the remote computer. Usually, I provide administrator rights for user which executes LR scripts.
   After that I select counters I want to measure during the load testing:
   
   So, "Windows Resources" dialog looks like:
   
   I selected the following counters:
   
   • % User Time for two processes (RService & tomcat5) and the whole system (_Total)
   • Available bytes in the system
   • Handle counts
   • Thread counts
     
   • Working Sets
   Also you may wish to add "Private Bytes" counter. Description for each counter is available on "Windows Resources" dialog. Obviously that the set of counters depends on the requirements and software to be tested.
   
   Pay attention... If you select the "Windows Resources" graph, the list of counters will be shown in the lower part of the LoadRunner Controller:
   
   
4. Our mission is almost complete :) We have to run the scenario against a number of concurrent users (I user 30 users) and observe the graph displaying info on memory, CPU, handles and so on...
   I will show the result graph after 4 hrs of execution:
   
   Pay attention to the yellow dotted line (memory usage of "RService" process) and the brown dotted line (habdle count counsumed by "RService" process) trends. They grow constantly during ~ 4.5 hours. I marked them out with red lines.
   So, this graph provides proofs that the application, I tested, contains memory leaks in the "RService" process.
   
   Several words about useful tricks and hints, connected to measurements ans graphs:
   
   • It is possible to export graphs to HTML from the LR. For that, right-click on the graph and select "Export to HTML...". It will generate HTML report containing the graph and a legenda for it. Very useful feature :)
   • I recommend to set the range of time to be shown on the graph, to "Relative to scenario start". To perform this, right-click on the graph and select "Configure...". That allow to display statistics for the whole execution, but the latest N minutes.
     
   • Sometimes, it is convenient to show more detailed graph. For that, double click on the graph - one big graph will be shown. To revert, double-click again. Also, you can change the number of graphs displayed - open menu View/View Graphs and set the required number.
     
     
5. So, now Dev team has to fix the problem in the "RService" process.. The last graph shows the results of load testing perfomed on the fixed application:
   
   No any memory leaks found during 10 hrs.
   
   Memory leaks fixed! Isn't it a progress? :)

I hope, my explanation will be helpfull for you :)
Please, share your comments and thoughts. Ideas for further topics - welcome :)

---

Do you like this LoadRunner visual tutorial? Would you like to receive them in the future?
If yes, please subscribe to this blog RSS feed or by Email. (How to subscribe? VIDEO guide)

---

Dmitry Motevich,
QA / Automated testing specialist