Again, as with my previous post, it's best to think of this as my course notes. These are meant for me to revisit and understand. I believe it's important to make your learning as accessible to you as possible. Often the way something's explained can be a barrier to your understanding, making it (usually unintentionally) sound more complicated than it actually is. Unfortunately, this puts a lot of people off learning, which is a shame.
Firstly, I want to record the commands for reports. Note: I'm on a Linux machine.
If you have an existing results file: sh jmeter -g somefile3.csv -o report-output/mytestreports1 -- this is really easy way to make pretty HTML reports out of existing results files.
This is how to run the whole kit and kaboodle from the command line. You will need to have created the test in JMeter.
sh jmeter -n -t "location of jmx test file" -l "location of result file" -e -o "location of reports folder"
And below an actual example:
sh jmeter -n -t "TrainingHTTPTest.jmx" -l somefile9.csv -e -o "testreporting"
It's worth noting that, apart from the test file (the one with the jmx extension), the other files, if they don't exist will be created. So you could do it again, thus:
sh jmeter -n -t "TrainingHTTPTest.jmx" -l resultfile12.csv -e -o "testreporting1"
For this simple test, the result file looks like this:
And a report, like the one above, will be created in a folder called testreporting1.
Apparently, when you're running a real-world performance test, you shouldn't be doing it from the GUI with lots of listeners, since this produces overhead. I knew this, and I know it can be important to ring every millisecond out of a performance test.
So now to JMeter, which is where you create your case.
You will need the following:
- thread group (think users: this simulates the amount of users)
- a sampler to your thread group (sampler: think the request you want to make, the thing you want to do)
![](https://blogger.googleusercontent.com/img/a/AVvXsEip2xmUGMR7Q0D7FSEsZ3rFPmIjDxQzJ07q9M5d-UyI7ZiNeLdj_LvWnCFigJF9N_O_aYt3AezIh8jWCCgywvRnkN-n1bh6xkwlTHxWgLvnXTCOF3RdY85LHwjtO6plrVSwomZcQIwb6MFjjF4km8foyQp7RDkT01Qqk3rr13a2501Z8PfXlVTD4KovwNM)
- a listener (you need at least one of these to have any feedback. There are quite a few to choose from depending on the format you're after). Below is a listerner showing two runs, one that failed and one that passed:
You can use the following:
- assertions (for example, the right code is returned, or a certain word appears on a page)
- config element (these run before the sampler and set up initial conditions -- usually for the whole test plan (I think).
- pre-processors (things you want to have considered before the sampler runs)
- post-processors (essentially doing something with the response)
Order of execution of JMeter elements:
- Configuration elements
- Pre-processors
- Timers
- Samplers
- Post-processors
- Assertions
- Listeners
I went through Raghav Pal's JMeter Masterclass as a refresher course, which can be found here:
It was a good refresher course, and reminded me that I'd probably made a six course dinner of some things first time round, by which I mean I over-thought and over-complicated them. I must have been in a bad mood last time I installed the Plugins Manager because I remember it as a bit of a faff. It's actually straightforwardly downloading a jar file and putting in a specific folder (learning's all about being in the right mood):
Restart your JMeter and you'll see it under the Options menu, thus:
Performance testing is an important non-functional aspect of testing. Increasingly, customers for software are interested in questions like: How will this behave under load? How many users can I have use a single instance at one time? And more granular questions, such as how long does each process take, or how long does your web application take to move from one process to the other. Can it do parallel processing, etc? JMeter is a free open source tool to answer these question. It's also something of an industry standard.
I ignored the part of the course that referred to BlazeMeter, preferring to use the Test Script Recorder in JMeter instead.
The next part of the course covers using JMeter for API testing, which I'll cover in another post.
No comments:
Post a Comment