Waldemar’s blog

As described here ip spoofing is a technique for hiding real identity of the attacker on the net. It is mainly used for hacking but it can be helpful for performance tests as well.

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

Waste time in Load Runner is a time spend on tasks that normal browser user wouldn’t perform like storing test results, performance monitoring, calculations, etc. Wasted time is measured by LR automatically but sometimes it is necessary to use it explicitly through lr_wasted_time() function .

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.

Fuzz testing is an automated way for checking how application reacts on unexpected input data. This is a type of negative testing. This is also very know technique for automated vulnerability finding.

But I didn’t hear anything about tool that will operate on the GUI in a fuzzy way (or maybe my Google search “kung-fu” isn’t so good). Instead of providing incorrect, trashy data we could provide input values correctly but in wrong order, etc. In general an application should receive not only correct data but correct data in correct order. Example: you shouldn’t be able to save child user while parent user is still not stored in db (this can end up with an exception).

Some kind of GUI fuzzing tool would find it by providing correct data and using correct steps but in completely unexpected order. The other problem is how to fuzz with application logic. Providing input data is simple, but providing steps that user performs on the GUI and then fuzzing the whole logic… hmmm… maybe I could use QTP.

There is a very nice tool provided by HP Support that allows running few LoadRunner scenarios from QualityCenter using command line. You can use it to run load tests in regression every night for example.

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

One (if not the biggest) anti pattern for me is when developer generates WSDL file from source code. Have you ever tried to create HTML page in MS Word? If so, then you know that 90% of the code is crappy. WSDL is a service description. How you want to understand or test it if the code looks like a mess?

Another thing – service description depends on your business. Do you really want to leave it for automated tools? Do they know your business area better?

So, next time when someone gives you WSDL generated from source code, you don’t even have to look at it to reject it.

My first script for WebSphere MQ testing was written in Java as Java Vuser script. It was pretty simple since I was using just MQ JMS API.  There is lots of examples howto connect to WebSphere in Java. Here is one http://hursleyonwmq.wordpress.com/2007/05/29/simplest-sample-applications-using-websphere-mq-jms/.

But howto test WebSphere MQ if you don’t have Java license in you LoadRunner?

There is a way to do that. LoadRunner API contains several JMS functions:

jms_receive_message_queue()
jms_send_message_queue()
jms_send_receive_message_queue()
jms_set_general_property()
jms_set_message_property()

First of all you need to have “Web Services” license to use them.

Here is what you need to do:

• Get details of your environment like: MQ server IP, port (probably 1414), Queue Manager name, Queue name and channel name.
  Install IBM WebSphere MQ Client on machine where you have LoadRunner Controller (or LoadRunner Generator if you are using remote one). MQ Windows Client for WebSphere 6.0 can be downloaded here.

• Setup details of our WebSphere MQ server on the client. We will use JNDI to store connection details (host, port, etc…)

• Edit file C:\Program Files\IBM\WebSphere MQ\Java\bin\JMSAdmin.config and set

INITIAL_CONTEXT_FACTORY=com.sun.jndi.fscontext.RefFSContextFactory
PROVIDER_URL=file:/C:/JNDI

• Create new .scp file and put there your MQ server details. Here an example

DELETE QCF(QueueConnectionFactory)
DEFINE QCF(QueueConnectionFactory) QMGR(QUEUE_MANAGER) tran(client) chan(SYSTEM.ADMIN.SVRCONN) host(192.168.12.13) port(1414)
DISPLAY QCF(QueueConnectionFactory)
DEFINE Q(MY_QUEUE) QUEUE(MY_QUEUE) QMGR(QUEUE_MANAGER)
DISPLAY Q(MY_QUEUE)
end

• Last step for MQ Client is to generate .bindings file (placed automatically in C:/JNDI) with JMSAdmin tool from C:\Program Files\IBM\WebSphere MQ\Java\bin directory. Assuming that your .scp file is named My_qm.scp, use this command:

JMSAdmin < My_qm.scp

Now in LoadRunner:

• Create new Web Services script

• Open Run-Time settings (F4) and go to JMS/Advanced

• Change JNDI initial context factory to “com.sun.jndi.fscontext.RefFSContextFactory”

• Change JNDI provider URL to “file:/C:/JNDI”

• Change JMS connection factory to “QueueConnectionFactory” and click OK

Use this sample code to send and receive a message from IBM WebSphere MQ:

//setting JMS message property JmsMessageID
jms_set_message_property("JMSMessageID","JMSMessageID", "12345");

//sending message
jms_send_message_queue("Sending message","My cool message", "MY_QUEUE");

//receiving message
jms_receive_message_queue("Receiving message", "MY_QUEUE");

//displaying message
lr_message(lr_eval_string("{JMS_message}"));

Received message is saved in “JMS_message” parameter automatically by LoadRunner.

Done. Smart and simple

Hello

As you know, browser can store some downloaded HTML/JPG/etc file from remote server on local hard drive so you can access it faster next time. This is called “cache”.

There is an option in LoadRunner VuGen to simulate browser cache behavior with your web performance testing. But how to use it and when? Here are my suggestions.

Don’t clean the cache
Your application is rather something internal used by (mostly) the same people in one company – In that case I suggest not to clean the cache because this will reflect users behavior in your tests. If you ask why? then ask yourself how often you clean your browser cache. Once a week? Once a month? Every login/logout? Are you getting the idea?

With such settings, your transaction performance graph would look like this:

After first iteration with cache enabled, transaction performance is much smaller. It’s because user gets most of the files from the cache.

Clean the cache:
Your application is accessible from the Internet, and your customers are basically everyones on the net – in that case I suggest to clean the cache because its more probable to have new person without cached content already.

This is example performance graph after tests with cleaning browser cache.

In each iteration, user has empty cache at the beginning so he need to get all the files from remote server.

Conclusion:

Only by cleaning/not cleaning the cache your transaction performance can vary significantly!!!

Some time ago I made a little test comparing web services performance using HTTP GET and POST methods. I used the same script, in the same environment with the same web service. HTTP method was the only difference.

I discovered that POST method is twice much faster than request sent using GET method.
You should also know that request size with GET method can be limited, although RFC2616 says:

The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs.

So if you are planning some web services performance testing or you want to speed up your tests a little bit before customer demo you should consider POST HTTP method.