Waldemar’s blog

Few tips&tricks to make working with LoadRunner easy:

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

If you are familiar with Selenium test tool, you probably know that when running tests, you can run only one test case at a time. Lets say we have 10 test cases and running each takes about 10 minutes. In that case, running all test cases will take 100 minutes. Now, the question is how to speed it up? How to make it faster?

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/

Another issue that I’m facing from time to time is that LoadRunner stops 50% of running users without any notification, issue, error message etc. I’ve find out that it happens only when running with log level set to ‘always send a message’. Because of that, I suggest to run with log level set to ‘Send message only when error occur’.

Sometimes LoadRunner is not recording anything while browsing using IE. I have no idea why but the fastest solution is to restart whole LR. Maybe some of you have good explanation for that?

LoadRunner basically allows two approches for load testing your web application. Before going into details lets see how communication between user and web server looks like.

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.

Hi All

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!

Some of you may already know Selenium. Basically it’s free and open source tool for web application functional testing. It’s mainly know as replacement for HP’s QuickTestProfessional. I’ve recently discovered Selenium as very helpful for automating data setup for load testing.

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.

Correct me if I’m from but I always thought that for particular transaction there should be only ONE average response time. But it looks like it’s not the case in LR Analysis.

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.