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

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.

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.

Basically if you see message like this, it is not any internal LoadRunner error. It means that you made a mistake in your script and you need to fix it. But let’s start from the beginning with some example:

This small piece of code takes parameter MESSAGE with value “hello_world”, then search for the first space character and display the string starting from that place up to the end. Function strchr() is responsible for searches for the space character. If it’s found then strchr() will return a valid pointer (something like 0xb36ac56e). But if the space is not there (which is our case since there is no space in the hello message), strchr() will return NULL which refers to 0×0 memory address location.

Such memory address is a very special address. Basically any read attempt from there is threated as incorrect operation and results in memory access violation (not only in LoadRunner).

Now, howto deal with it? If you see ACCESS_VIOLATION, in most cases it means that your LR script is working on incorrect/incomplete values. You are responsible for error handling in your scripts and you should always:

• validate parameter’s values
• check results of C functions to handle any errors, unexpected conditions
• remember that you can’t always expect correct values and you need to handle it as well

Here is our example with fix showing howto deal with ACCESS_VIOLATION. We are calling strchr() function and checking if value returned is not NULL.

More details about NULL pointer here http://en.wikipedia.org/wiki/Pointer_(computing)#The_null_pointer

So how to deal with that?

LoadRunner finishes taking measurements when web page code and all non-HTML elements (jpg,gif,js) are download into the clients memory. But starting from that point the browser need to form UI and display it to the user. And that’s the part that LR is actually skipping. Full end-to-end test should measure time between clicking “submit” button (or whatever triggers a call) and displaying full page within the browser. So how to do it in LR? The quickest answer is “not possible”. For that you need to use QuickTest Professional.

In that case of course you need at least two scripts. One prepared in LoadRunner and second prepared in QTP. Each script will have different task to accomplish. LR script will generate the load on the server simulating different amount of remote users connecting with AUT. QTP script will measure times only for one user, and that’s what we actually need. I believe every single web user care only about how fast page works in his browser. Not how fast it works across all remote users together in average. Of course one is connected with the another.

LoadRunner and QTP have one thing in common – transactions. And basically to measure end-to-end time in QTP all you need to do is to use transactions and remember to synchronize each page correctly. By synchronize I mean to finish transaction when page is fully downloaded and displayed to the user. One solutions for checking when downloading is finished is to call WaitProperty on browser’s status bar element. Example QTP code:

If you have LR and QTP scripts already in place, now just add them in HP Controller into your scenario. To see QTP scripts in Browse window just change File Type from “Vuser Scripts” into “QuickTest scripts”. One think to remember is that you are allowed to run only single QTP instance at a time so hacks like few QTP scripts running simultaneously are not possible (unless you are using Citrix which is another story).

Only with such scenario you are able to measure full end-to-end performance.

First of all we need a web services. And there is one available exactly for training. Here is the WSDL http://soatest.parasoft.com/store-01.wsdl. I hope that folks from Parasoft don’t mind we are not using SOATest

In any case, we have an WSDL file. Now lets create new script.

Click File / New and select “Web Services” from list of available scripts types.

Now, when we have new script we should see new toolbar under the standard one. It allows to add Web Services description to the script (from WSDL file), add XML request using form and add XML request from file. So lets click on “Manage Services” button and then “Import”. Enter WSDL url http://soatest.parasoft.com/store-01.wsdl and click “Import”.

After WSDL file is imported, just click “Apply” and “OK”. From this point LoadRunner has description of our web services so we can use it send some requests. We will actually create two requests. One using “Add Service Call” and second using “Import SOAP” buttons from toolbar.

Click on “Add Service Call”. In “Operation” dropdown list select value “getItemById”. On left side select “id” under Input Arguments tree node. Then on right side type “1″ into Value editbox.

Now our script should look like this:

Now lets add Web Service request using Import SOAP. Lets assume we have XML request saved in file on the disk. Here is an example:

Click “Import SOAP” button and select your file. Change type from “Web Service Call (Recommended)” to “SOAP Request”. Select URL from the list, and type into SOAPAction this value “getItemByTitle”. Click OK.
Now we’ve added second call that ask for book details for title “Linux”. Our script should look like this:

As you can see, each request contain “ResponseParam=response”. LoadRunner will automatically save response XML into parameter with name “response”. We can easily display this parameter by addind

after each call. So at the end out script should look like this:

At the end lets run our script. Output should be something like this:

Now, lets say we have sample web service for on-line book store and we want to ask what is the author for book id 123. Our web service can send following XML as a response:

For checking if the “author” element within XML response contains “John Smith” value we will use lr_xml_get_values() function. Here is the code that calls web service and checks if the value is as expected:

First argument in lr_xml_get_values() call is parameter name that holds response XML. Second argument in name of new parameter that will hold author value extracted from response XML. Third argument is XPath query that extracts author element value.

Let’s say we have some fancy network infrastructure that cache some of our requests in the performance test. Because of that our results may be incorrect. To omit this issue we can change the IP address of each (e.g. HTTP) request that reaches the server and simulate load from multiple users not only on the application level but on the network level as well. In that case cache won’t affect performance tests. Fortunately folks from Mercury/HP implemented special function for IP spoofing in LoadRunner API.

To use it, first put your code between these to functions calls.
Second (before connecting to load generator!!!) enable IP Spoofer option in LR Controller (Scenario > Enable IP Spoofer).

Let the hacking begin

Tip:
There is an option in Controller (in Expert mode) to choose between multiple IP addresses per process or per thread (Tools > Options).

lr_wasted_times() removes time from all open transaction. If you want to make some calculation and don’t count them into overall transaction time then you should use this function.

Small example

On line 7 I’m starting one transaction. On line 8 I’m starting timer and stoping it at line 11. For loop between is used to generate my wasted time. After stopping the time, we need to subtract wasted time from open transaction by calling lr_wasted_time() on line 14. But before that on line 12 we need to change time units. lr_end_timer() returns time in seconds but lr_wasted_time() takes time in milliseconds. Thats why we need to multiply it by 1000. There is one more think. lr_wasted_time() is defined as

If you use long type variable to measure wasted time you will always get rounded results (e.g. 1000, 2000, 3000). Instead it is better to use double type variable so at the end the results are more precise.

Officially HP doesn’t support this small tool and they say it’s free and open source. There are two versions available. One for QC 9.0 and another for QC 8.2 SP1. If you want to find it on HP support page, just search for document ID KM191021.

cpt38343a – this is my local mirror for QC 9.0 version