Andrew Maurer

 

Begin using JMeter for your testing!
11/04/2011 03:33:15 PM

JMeter - Powerful but Not Intuitive

I started using JMeter about a month ago. Creating a basic test plan was a cinch! I was all finished with my test and I ran it a few million times. Then I noticed that the variables weren't updating over each iteration... UH-OH... Back to the drawing-board.

So my new preferred method...

Since these variables weren't updating over every interation and I also got the feeling that things were getting a bit messy, I decided to look into BSF scripts. Turns out, this is a great solution to put all your logic into the same file as well as have the ability to change user variables as often as needed. Doin this gives you the greatest flexability and control over your tests that you can get.

BSF Options

When writing BSF scripts, you have several options to choose from...

  • JavaScript (Rhino)
  • Jexl
  • XSLT
  • Beanshell

I know JavaScript very well so it was a no-brainer as to what language to choose. While its the same JavaScript you know and love, writing BSF scripts is not for the faint of heart. You are going to drive yourself mad if you aren't extremely confident in your JavaScript syntax and coding skills. I say this because debugging JMeter is a rather difficult task. If something isn't coded right, JMeter is NOT going to throw an exception. Instead, JMeter will happily ignore your script and continue processing.

Here are a few recommendations...

Using User Defined Variables

Create a user variables config element to setup some variables to be used throughout your scripts. These can be called later like so...

${bsfFilePath}

Using User Defined Variables

HTTP Request Sampler

Create a HTTP Request Sampler Default. This is handy because you would have to specify these details for every HTTP Request Sampler if you didn't. Now that you have this configured, you can leave most fields blank in your subsequent HTTP Request Handlers because they consume the defaults.

HTTP Request Sampler

Response Code Assertion in Sampler

For every sampler, I suggest at least some simple assertion to verify everything is OK. For EVERY HTTP Request Sampler I create a statusCode assertion. This verifies that the header status code has a value of 200 and not something else. If it were a different, status, then your flow or variables are likely incorrect.

Response Code Assertion in Sampler

BSF Post-Processor - JavaScript

This is where I do my heavy lifting. I write a script for each type of Sampler as a post-processor. This allows me to have the greatest flexibility when managing the response content and getting/setting variables. I always create an external script and concatenate the user variable that has my script path and my script name. Inside my script, I can change the response code to 500 if something goes wrong too.

BSF Post-Processor - JavaScript

Using Variables Set by the BSF Post-Processor

No different then using User Defined Variables. Set them in the script and consume them normally.

Using Variables Set by the BSF Post-Processor

Use Results Tree For Testing

When building your script, you'll want to use the results tree listener to debug your code. If you add the debug sampler, it will show you the variables in this view.

Use Results Tree For Testing

Performance Summary of Maurer.me running Node.js

In Summary, here is my test and a list of JS files I created.

Test
Scripts
Reference

Performance Summary of Maurer.me running Node.js