As I began to discuss in the last article, I have a working version of a java-based jmeter-runner from a colleague that’s operating in eclipse so happy days. I have no idea yet how it works, but I’ll get to it eventually.
I also created the excel version of the same, for the largest set of tests (21 groups within a single test). And that is operating more-or-less successfully at the moment – I had some fun with deleting the temporary batch file created – since early deletion stopped the test – so I created a simple time-counter to make it wait. This is not ideal as it hogs processor time for no real reason so I’ll be revisiting that approach eventually. As a proof of concept I’m happy with it.
I’ve added links to both of them in this article.
Java swing UI example
ExcelJMeterRunner
Working on them made me conceptualise my requirement a bit more deeply.
- At least 8 areas of testing – Let’s call this X
- At least 1 jmx file to each area – And Y
- At least 1 thread group to each area – And Z
Obvously I dislike hard-coding, and as an automater, I don’t want to limit the scope of my executable(s). So I need to build a mechanism or set of tools which derive – from a given point – the values of X, Y, and Z.
That’s requirement 1 (or 1,2 and 3). Additionally, with those values known or derivable, the mechanism must construct itself a user-facing tool to allow the declaration of the JMeter runtime settings for each thread group.
As I work in scrum a lot lately but with my limited understanding* user stories…
As a performance tester, I want to declare 1 user does 1 iteration for 22 groups simulatenously
I’ll need to spend some time thinking about this but I’ve realised that each JMX is readable via text editor and that a test represented something like this:
${__P(threads1,1)}
${__P(ramp1,0)}
${__P(duration,)}
looks like this in textpad:
<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="New Account New Quote 1d1v" enabled="true">
<stringProp name="ThreadGroup.on_sample_error">continue
<elementProp name="ThreadGroup.main_controller" elementType="LoopController" guiclass="LoopControlPanel" testclass="LoopController" testname="Loop Controller" enabled="true">
<boolProp name="LoopController.continue_forever">false
<intProp name="LoopController.loops">-1
</elementProp>
<stringProp name="ThreadGroup.num_threads">${__P(threads1,1)}
<stringProp name="ThreadGroup.ramp_time">${__P(ramp1,0)}
<longProp name="ThreadGroup.start_time">1422024713077
<longProp name="ThreadGroup.end_time">1422024713077
<boolProp name="ThreadGroup.scheduler">true
<stringProp name="ThreadGroup.duration">${__P(duration,)}
<stringProp name="ThreadGroup.delay">
</ThreadGroup>
I can parse directories looking for JMX files – that’ll be part of the solution
I can look for "<ThreadGroup guiclass="ThreadGroupGui" testclass="ThreadGroup" testname="New Account New Quote 1d1v" enabled="true">
” to get the names and the other lines for number of threads, ramp etc. (And I can insert variables on the fly to minimise editting effort).
The start_time / end_time may or may not need to be fed in, and may or may not be epoch time. I’ve not looked yet but it looks likely. And that’ll be part of the solution.
I can derive X, Y, and Z – and build appropriate numbers of controls to allow the user to enter thread numbers, ramp settings, durations etc. Although with specific regard to duration, I’ve concluded this is a unique, declared-once, global variable for all modules.
First of all, if I tell the “mechanism” to look on C:\PerformanceTest under which are 8 directories – 1 per system and I’ll see if I can make it output that nicely.
(*or concern for)