From time to time there are situations where you work on a script, and it looks fine, compiles with no issues but simply doesn’t work as you expect. In such case there is no other option than just knuckle down and get a little bit dirty. That’s the right time for debugging.
And here some tips from me that (hopefully) will help you making this step less painful.
1) Increase log level
By default, VuGen report only standard information. If you want to see more verbose details, then go to Vuser -> Run-Time settings -> Log and enable “Extended log” option.
2) Use HTTP Proxy
Another option is to find by checking what exactly LoadRunner sends to the server. Personally I use WebScarab and Fidler (from time to time) to sniff network traffic and to check what data my script generate. You can setup proxy in VuGen by going to Vuser -> Run-Time settings -> Proxy.
Below is a setup for WebScarab running locally:
and sample traffic as seen in WebScarab:
3) Use text tools to compare HTTP requests from LR and from real browser
Lets say you sniffed LR HTTP call and browser HTTP call e.g. with local proxy and you want to compare both to search for any differences. Sometimes your HTTP call fails only because of e.g. missing dot somewhere. And such bugs are even harder to find because there is no obvious “Hello, I’m here” error type of message. Try to use Notepad+ or ConTEXT (http://www.contexteditor.org).
Sample results of HTTP requests comparison in ConTEXT editor:
4) Use breakpoint
Breakpoint is a place in script where LR will pause running so you can see all runtime values. Howto setup a breakpoint? Simply right click line where you would like to pause and select “Toggle Breakpoint”. This will put red dot at the beginning of line. It looks like that:
Now, simply start the script, and wait until script reaches this breakpoint. When it’s done, in output window you can switch to “RunTime Data” and see detailed information like which iteration is running currently, which action, line number and (most interesting) all parameter with their current values:
To resume running, simply hit run button once again. To disable a break point, also right click the line and select the same “Toggle Breakpoint”.
5) Run script step by step
Running step by step means that instead of going from one call to another automatically, you need to hit F10 in order to perform next call. This is actually helpful when running with Browser preview or when you have lots of if/while/do…while/for loops and you want to see exactly what LR is doing and where.
To run scrip in step by step mode you just simply hit F10 or select Vuser -> Run Step by Step.
6) Force script to run with specific parameters values
This is actually a trick, definitely not something described in VuGen manual. Lets say your script use parameters very heavily and depends on them as well. Now, you have e.g. parameter USERNAME with lots of accounts to use but you want to use one very specific account. One method is to update/change the parameter so it will pick up correct account. But in such case you need to remember to undo your changes after you are done with the test. Another method is to leave parameter unchanged, and just override it’s value during runtime. For that you can use lr_save_string() function and place it somewhere at the beginning.
One could say that it’s even more dangerous than first method since it always overrides param value so when left unchanged could fail every future load test. But even for than there is a solution. Trick that I use looks like this:
lr_whoami(&id, NULL, NULL);
if(id < 0)
And basically you can leave it in your script because LR will reach this lr_save_string call only in VuGen. When running in LR Controller, lr_save_string() won’t be reached (lr_whoami called in VuGen always return -1).