Waldemar’s blog

This is something I worked on a while ago. It’s a testing tool (for windows) written in C++/QT and aimed to help during integration testing. If e.g. you create a solution based on IBM WebSphere MQ and you need a tool to test it (send messages back and forth, validate responses, etc…) feel free to use it.

Unfortunately I don’t have commercial license for WebSphere or MS Visual Studio so you have to build it yourself. For that you will need:
- QT 4
- WebSphere client libs
- MS Visual Studio (I used 2008)

Source code is available here: https://github.com/waso/MQTester

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:

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

Hi All readers

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)

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.