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:

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).

I have recently started my first and tiny startup. Basically it’s RSS news aggregator based on K-I-S-S principle and few similar ideas already running on the net. Unfortunately for non-Polish readers it’s mainly focused on Polish news but there is “IT Eng” part which you can find interesting.

The whole thing is running on PHP, MySQL and jQuery. My main goal was to deliver the latest news in a very clear form. Hopefully I will try to run it without ads but we will see…

Feel free to step in: www.czytnik-newsow.pl (means “news reader” in Polish)

- Store URL of your application in one single parameter. In case you need to change it, it requires a single change in one place, not tons of them for every single web request.

- If you don’t know why your HTTP/HTTPS request is failing, use proxy to sniff it and them compare it with the same request but generated from real browser. As a proxy you can use WebScarab or Fiddler.

- Separate load logic using actions, don’t store whole load in a huge single action that LR created be default at the beginning.

- Create web_reg_find() checkpoint for every HTTP request that you make. You don’t want to pass failing transations.

- On parameter setup, beware using “Update value” set to “Once”. Rather use “Every iteration”. If you mess it up somehow, at least only current iteration will fail, not all of them.

- For scripts that handle UI actions (like Web Click&Script or AJAX Click&Script) use “Run every user as a process” instead of “Run every user as a thread”. LR is not very good at memory management for such scripts so it’s better to run each vuser separately.

- Don’t use extended log level while running test in a Controller. One more time LR is not very good at handling it. Rather use basic level and if there is an issue switch to VuGen to digg for it.

- In LR Analysis, check performance results on a summary graph instead of “Average transactions response times” graph.

- Place 1 second wait before first call to the server. If server breaks, you won’t flood it with bunch of requests.

- Try to avoid using standard C string functions (strcpy, strcat, etc…) if you can. Or if you really need, just remember about null pointer issue. More details here http://blog.testsautomation.com/2009/11/exception-access_violation/.

- Comment your code – at the end LR script is (most cases) a C program. So all programming best practices apply as well.

- Make your code to look nice (tabs, indents, etc…). It will be easier for you to work with it and spot any issue.

- Don’t hard code anything. Instead put it into parameter.

- If some calls repeat constantly, put them into separate action and call this action instead. It will help you during refactoring your tests.

- NEVER store Controller scenario in QualityCenter. It’s just bad idea. Use local hard drive for it. Controller can store really big files there.

- When you work on a script in VuGen, try to run it there at lest for 2 or 3 iterations. Sometimes errors occur only after the first iteration.

- If you want you can store LR script on a shared drive. It won’t affect your tests since Controller will always copy it to temp directory before running the scenario (even if the script is stored locally on the same drive).

- If you want to send LR script to someone use File -> Zip Operations -> Zip and Email. On popup select “Run-Time files” instead of “All files”. This second options can zip results as well which may generate really unnecessary huge file.

One of the solution is to run test cases in parallel. And that’s exactly what Selenium Grid is for. It allows to setup few remote boxes and run test cases on all boxes simultaneously at the same time.

There are two main parts of Selenium Grid: hub and remote control. You will run most probably one single hub and multiple remote controllers. Remote controllers are responsible for executing particular test cases using the browser like in regular Selenium. Hub is responsible for distributing test cases between remote controllers and collecting results.

Going back to our example. Lets use 10 remote controllers and lets run our 10 test cases. With such setup, running all test cases will take only 10 minutes (from 100 minutes) which is a huge improvement.

More info about Selenium Grid here : http://selenium-grid.seleniumhq.org/

As you can see between user and web server there are mainly 2 layers:

• Layer 1 is where user interacts with the browser by e.g. clicking a button, selecting values from the list or submitting a form
• Layer 2 is where browser communicates with web server which includes:
  • creating and sending HTTP requests to the web server based on user’s actions
  • receiving HTTP responses from the web server
  • rendering HTTP responses, forming an UI and displaying it to the user

Below I’m providing two scripts that do exactly the same thing but in slightly different way. The goal for each script is to search for a “linux” word using google search.

First, lets look at “Web (HTTP/HTML)” type of the script:

What happens here?

• In line 3 we are entering google.com web site
• In line 14 we are sending HTTP request that browser would generate after searching for value “linux”

Now, lets look at “Web (Click and Script)” type of the script:

• In line 4 we are entering google.com web site
• In line 10 we are typing value “linux” into the input field
• In line 19 we are clicking “Google Search” button that will move us to the page with search results

So what is the difference between these two scripts?

First script operates on much lover level comparing to second script. It deals with HTTP requests without taking care about what actions user actually performs. It doesn’t care how fast user’s browser renders and display the UI. It only checks how fast web server is able to response with correct message.

Second script operates only on UI level without taking care what happens underneath. Response time here includes not only time needed to send/receive HTTP traffic but also time needed to form/display UI to the user.

Basically second script approach is less error prone because you don’t have to deal with low level things like HTTP parameters. And You are replicating user’s actions in a natural way.

So if you need to choose, then I would recommend Web Click and Script type of the script.

Thanks to Zee Gao (高楼) some of my posts are now translated into Chinese language on 7dtest.com forum. Here are the links:

Web Services performance using LoadRunner HTTP Vuser script – http://www.7dtest.com/bbs/thread-3483-1-1.html

Don’t waste your time – http://www.7dtest.com/bbs/thread-3481-1-1.html

Cleaning browser cache – http://www.7dtest.com/bbs/thread-3482-1-1.html

HTTP POST or GET – http://www.7dtest.com/bbs/thread-3480-1-1.html

Thanks Zee & 7dtest.com users!

Here is a small description howto setup Eclipse and run Selenium script through it.

1) Download Eclipse IDE from http://www.eclipse.org/downloads/
2) Download Selenium RC from http://seleniumhq.org/download/
3) Download Junit from http://www.junit.org/
4) Create new project in Eclipse:

• Go to File -> New -> Java Project
• enter project name e.g. “Sample”
• Click “Finish” button

5) Import Selenium and JUnit packages into the project:

• In Package Explorer right click project “Sample” and select Properties
• Go to “Java Build Path” then select “Libraries” tab
• Click “Add External JARs” and import junit-4.7.jar and selenium-java-client-driver.jar

Now our Eclipse environment should be ready. Next step is to prepare a test case in Selenium IDE. I’ve prepared small test that searches for “linux” word in google. To export test case as Java, in Selenium IDE go to Options -> Format -> Java (Junit) Selenium RC. As a result you should get something like this:

Default Junit code generated by Selenium doesn’t use Selenium RC. Because of that I updated the code a little bit to connect to localhost Selenium RC on port 4444. Here is updated version:

Now, lets add it in our Eclipse project:

• In Package Explorer right click on our “Sample” project and select New -> Class
• Enter class name “Untitled” and package name “com.example.tests”
• Click “Finish” button

Before we run our test, we need to start Selenium RC. For that open command line and under selenium-remote-control-1.0.1/selenium-server-1.0.1 run command “java -jar selenium-server.jar”. It will run Selenium RC server on default port 4444.

Now, to start the test just select Run -> Run As -> Junit test. It should open two IE browsers. One for Selenium RC and second with Google results for “linux” word.

Because we run Java code, it’s only up to us how we want to run the test. Below is our example update to search for “linux” word in a loop 5 times with 5 seconds intervals.

I recently discovered that by changing granularity on average transaction response time graph, Analysis also recalculates average times under the graph. In my understanding granularity is responsible only for making the graph easier to read and thats all it should do. But by changing granularity we are also changing how many points LR actually counts which results in different average response times for different granularity.

So shame that this is not mentioned in the manual. Of course according to HP support it is mentioned there and this is a feature, not a bug

So my tip for today: be careful when looking at response times on average transaction response graph. Use “Summary” page if you want to omit any mistakes.