A year in review and a consolidated approach

Wow, wasn’t that long ago when I was promising things that were harder, better, faster and stronger. I think I got part of the way there. The core reason I set up Altentee was to provide reliable (and potentially cheaper) alternatives to traditional licensed performance testing tool sets. There’s no doubt Altentee can test at the limits of your typical web app using tools that cost zilch. The bigger challenge I’ve found this year is convincing potential clients that they really don’t need to spend that much. I’ve even offered a free load test on our homepage to help illustrate this point.

We were lucky to be selected by the development team at Cordelta to help them automate and performance test a high profile public website called MyHospitals. We were able to test millions of hits per hour from domestic and international locations in a wide variety of load scenarios. The success of this approach was underpinned by the following:

  1. An open minded project / development team not coupled to a ‘must-have-most-expensive-toolset-to-do-job’ mentality
  2. An open minded performance test analyst (me!) who believes Excel really is the grandpa of charting, R is the grandma of stats, Sparklines are the only way to present time series data to management, ANY tool can simulate load via HTTP/S and that there is no real distinction between good software testers or developers (only hard work separates the best from the worst).
  3. That 2010 come-no-doubt 2011 buzz word… Cloud

As I sit here pluggin’ our alternative approach at Altentee, I can see the rise of other more successful punters taking on the big kids. I sit and [continue to] chuckle at the reaction to LR pricing and LR zealots who will fall on their swords over LR itself. I have come to realise one thing though, it is not about the tool, or even the alternate tool like perhaps I first thought. It is more about the freedom of choice.

To tackle MyHospitals I was free to choose and implement the following tools:

  1. WatirGrid to orchestrate a small flotilla of IE and FireFox based browsers based on Watir
  2. JMeter to add more at the protocol level of performance testing
  3. httperf to do some basic benchmarking, similar to my front page
  4. numbrcrunchr to pull together system metrics and make for easier analysis
  5. A variety of Australian cloud providers and of course Amazon EC2 to host the test environment

It has been a great year. I’m not entirely free of the commercial chains just yet and am still needing the LR type work to prop up this approach, but I hope 2011 brings about some fresh thinking in performance and test automation with hopefully me somewhere amidst that space.

Read More

How to spoof Google Analytics traffic with JMeter

Recently a client asked Altentee to generate some load against their subscription to Google Analytics (GA). Calls to GA and other 3rd party monitoring tools are typically requests we blacklist or consider out of scope. So it was unusual to think the other way around, how would you performance test GA?

The solution as it turns out is quite simple. Google Analytics is well documented here in terms of what query parameters constitute the GIF request that registers traffic.

The key parameters which need to be catered for when spoofing traffic are:
utmn => Unique ID generated for each GIF request to prevent caching of the GIF image.
utmhid => Another unique ID not documented but I think is related to AdSense
plus all the GA cookies including utma, utmb, utmc and utmz

The best way to parametize this is to observe real traffic with a tool like FireBug in the Net(work) panel. That way you can make a copy of a real GIF request. Essentially you are going to fake the call to __utm.gif. An example request looks like this:

http://www.google-analytics.com/__utm.gif?utmwv=4.7.2&utmn=123456789&utmhn=www.altentee.com&utmcs=UTF-8&utmsr=1920×1200&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.0%20r45&utmdt=AlteneeBlog&utmhid=1697634062&utmr=-&utmp=%2F&utmac=UA-12345678-3&utmcc=__utma%3D199946558.28502083.1280297456.1280637882.1281056979.6%3B%2B__utmz%3D199946558.1280297456.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B&gaq=1

All you need to do to spoof traffic or generate page views to your GA account is make repeated calls to this URL after parametizing key fields previously mentioned. An example request in JMeter with corresponding parametized functions in bold (random and time) looks like this:

/__utm.gif?utmwv=4.7.2&utmn=${__Random(10000000,60000000,utmn)}&utmhn=www.altentee.com&utmcs=UTF-8&utmsr=1366×768&utmsc=24-bit&utmul=en-us&utmje=1&utmfl=10.1%20r53&utmdt=PerformanceTest&utmhid=${__Random(100000000,900000000,utmhid)}&utmr=-&utmp=%2F&utmac=UA-12345678-3&utmcc=__utma%3D199946558.1448353202.${__time()}.${__time()}.${__time()}.4%3B%2B__utmz%3D199946558.${__time()}.1.1.utmcsr%3D(direct)%7Cutmccn%3D(direct)%7Cutmcmd%3D(none)%3B&gaq=1

You could also build this URL from scratch although it’s much easier to copy and modify the target URL for the site you’re actually testing. Please don’t use the URLs above as I’ve faked other things like the Google Analytics account code (utmac). It’s also worth changing the page title (utmdt) so you can separate real traffic from the fake traffic generated during performance testing.

Build a simple test plan in JMeter with a HTTP sampler generating requests to the aforementioned URL, put in a constant timer (or similar) so you don’t spam GA’s servers and away you go. You can then measure response time to this service for as many threads as you like. I generated 10K page views in 5 minutes which was more than sufficient to satisfy the client’s requirements.

Read More

Dynamic Data from JMeter JDBC Requests

A common requirement when load testing is to populate subsequent requests with dynamic data from previous requests. If you’re thinking about using a database to store static test data, such as usernames, paswords, credit card numbers etc then read on to find out how to extract this data at runtime and populate JMeter variables.

Read More

A Framework for JMeter using GitHub and Ruby

Version control is not something you often associate with performance testing scripts. The reasons generally vary. A significant one is the lack of any version control support in commercial toolsets like LoadRunner. Another reason is the perceived short-term shelf life of test scripts. You tend to write them once and throw them away right?

If you work with more agile teams/developers you will probably start to require a lot of re-use out of your scripts, especially when the release cycle increases in terms of frequency. It starts to make sense to use version control and some form of scripting framework.

In this post I’m going to use JMeter as the tool of choice here and I’m going to re-introduce concepts which I normally force upon others whilst contracting. That is, use of Application Simulation Models (ASMs) to hep define the load and use of the Application Performance Index (Apdex) to help present results. I’m also going to use GitHub (or git) as my tool for maintaining version control and implementing a wiki as a dashboard replacement for other test management tools.

Read More

Testing SAP Web Portals with JMeter

A colleague recently asked me if it was possible to test SAP portals using JMeter. The short answer is yes.

Some people get confused with the additional protocols that LoadRunner sports for SAP, particularly the SAP GUI. But if your SAP portal uses plain old HTTP (or HTTPS) then JMeter can do the job.

There are a few gotchas which I will continue to update on this post, namely around correlation. In JMeter, correlation is particularly *easier* because you don’t have to worry about where to position a correlation rule. The equivalent function to use is a Post Processor -> Regular Expression Extractor.

Read More