As part of my work within the University, it has become necessary to build up Load Tests of business critical systems, so when releasing an upgrade to one of the systems, it is possible to identify our maximum possible load, whilst also seeing areas of improvements.
There were a number of possible Load Testing tools available, however the two most notable are
- Visual Studio Web Performance Testing (VS-WPT) Tools
These two attracted the most attention for a number of reasons.
- Visual Studio is a hugely adopted IDE across enterprises and specifically within the University Establishment it is the main development tool for Web Applications.
- jMeter was an existing load testing tool utilised by prior colleagues before my promotion to the post I am now situated in, although the load testing tool never really got it’s chance to shine due to configuration changes that left the existing load testing development redundant.
- Both tools can be incorporated within Visual Studio Team Services (VSTS) and run via Azure.
Initially, VS-WPT was used as this is the easiest tool to pick up and start using, the difficulty with this tool became apparent soon after trying to development tests past login screens. Documentation and user adoption was lacking for this tool at the time of writing and made it extremely difficult to progress.
Once the frustration set in, I turned my attention to jMeter to try and combat this issue, as I had been informed of prior success with the tool. After a few hours of patience and YouTube videos, the understanding of jMeters power begun to set in. It’s simplicity started to come to light, minus a few frustrations with the tool.
File and Folder Structure
During development of load tests it became apparent of the ever growing need for some form of configuration that would allow for reuse of load test functions across all load tests, most notably the login function.
I chose to use my understanding of the MVC framework and structured my folders in a manor that allowed reusable functions to be stored and controlled much easier. An important thing to mention is the adoption of MVC was around the API version of MVC where the View (V) section isn’t really required, essentially forming a MC framework.
Each load test project would use two main folders:
- Modules (M)
- Load Tests (C)
The Modules folder is designed for the reusable files, where they can all be stored and called as necessary. In the future, this folder may need folders within it, to facilitate more file clarity, but at the time of writing, the folder structure is perfect for its requirements.
The Load Tests folder is designed to house the load tests that have been developed. Providing a one-stop-shop for load tests related to a specific service.
Ease of Environment Variables
jMeter surprised me from the first time I used it’s “Include Modules” functionality where I was able to call jMeter files from around my pc. When calling these files during runtime, jMeter automatically adds the file to scope of the parent file and allows the child files to use Variables defined in the parent layer without the need to pass any variables in a command line or function call. That being said, I’m sure a number of people would find this worrying however on an implementation level, it is also possible to have local variable definition should the need suit you.
My main issue with jMeter
Why can’t I create dynamic file paths in the “Include Modules” function? It would make scalability a lot better as the need to rename each functions folder structure will be much easier when it occurs due to changing potentially one variable which would span across all “Include Modules”.
jMeter as a tool is fantastic for very in-depth load testing, whilst at the same time giving a level of simplicity that you aren’t grinding your teeth at the sight of a bug in your development. I will be continuing to use the tool and hope to develop a suite of resources within the department I work for to provide an easy adoption of load testing.