By itay.mendel It might not be your preferred method, but sometimes black box testing is inevitable. Here’s an example of a scenario that I often encounter…
A client comes in and says: “Hey, I’ve got this web app. I’m not really sure exactly how it works, but…well, I need to load test it. Can you please help me script it and see how it handles load?”
The ideal process here is to get a technical expert to work with the performance engineer. This will ensure that you’ll finish the script in the fastest time and get the best results…but sometimes this just isn’t possible.
Here at BlazeMeter, we call such cases: “Black Box”. This is because we’re getting a “Black Box” that we don’t know how to trigger, or work with, but we still need to help our client test it.
When this happens, we overcome all the challenges that such a situation triggers by using key tools and looking at cases that we’ve successfully handled in the past.
In this article, I will show you one example of how I tackle Black Box testing – and the tools and approaches that I use to help me.
My Step-by-Step Guide to Successful Black Box Testing
First and foremost, at BlazeMeter, we believe in dogfooding – we use our own tools for our own needs. In this case, the best tool for the job is BlazeMeter’s Chrome Extension.
It’s super easy to use! This would be my configuration:
A few things to note:
1) The filter patterns need to include everything! I don’t want to miss any requests!
2) Uncheck ‘Record only top level requests’. Again, I want to get all the requests.
3) Record cookies to see every bit of data
Once my session is recorded, I just press the red ‘record’ button at the top, and hit the first page.
Even simple pages usually call various backend services. So, after the page has loaded, it’s worth checking that every http call has been made.
Once done, I export the script to a JMX file. When the export button is clicked, a dialog appears asking me to select the domains of the requests that I want to export.
There’s normally a long list of domain names because most of today’s applications use external services. However, in this scenario, I only want to test my application – and not create load on any third party. So, I’m only going to choose my domains.
Now I have my JMeter script… but there are too many samplers!
And, most of these samplers are just for embedded resources served by the page. I don’t want a unique http sampler for these ones (Ill use a different way to grab them!).
This is NOT a good test plan!
After clearing everything, I only got the real backend requests!
So, I need to find the right way to parameterize the script, remove duplicate header managers, and set up the AJAX calls asynchronously. Read our previous blog post, “How to Load Test AJAX/XHR Enabled Sites on JMeter’, for more details on this.
If any requests also return embedded content, the best way to test it is by using JMeter’s HTTPs sampler ‘Retrieve Embedded Resources’.
And that’s the first page done!
Once everything is cleaned up, the script can look as simple as this:
This is how I would test a normal one-page application which uses several backend services.
In this article, I covered the main tools that I use, but there are many more useful tools out there. Here’s a quick list of some great tools that can help you:
As you can see, if you really have to run Black Box Testing, there are tools out there to help you. Select the best ones for your task and follow tried and tested approaches – and you’ll be able to run these tests with relative ease.
In this post, I covered how to record a simple scenario that doesn’t require any user input. In my next blog post, I’ll cover the best way to run tests when your web or app does require data to pass between the user and the application (For example: when it contains a page with a registration form or some other kind of authentication requirement). Stay tuned!
black box testingperformance testingLoad testingApache JMeter 2.11