Overwritting Parameters in JMeter

In one of the previous publications, we touched upon the topic of parameter cancellation. This was in the final part of the publication regarding how to save the results in CSV or XML format from the JTL file. I am once again placing the parameters and example:

Parameters:

-Jjmeter.save.saveservice.output_format=xml
-Jjmeter.save.saveservice.response_data=true

Execution on command line:

jmeter.sh  -n -t script.jmx -l resultados.jtl -j bitacora.log -Jjmeter.save.saveservice.output_format=xml -Jjmeter.save.saveservice.response_data=true

What Are These Parameters? #

Well, they are not parameters; they are properties. JMeter has two types of variables, just like any programming language. Local variables simply refer to them as variables, but global variables are called properties. Here you can see the definition in the JMeter User Manual.

What is the scope of a variable ? #

The simplest example to explain a variable is the correlation, correlations use local variables because these normally consume locally within a Thread Group or Group of Threads and are replaced by another value or destroyed afterwards. Variables can also be defined initially using the section for this purpose in the test plan or using an element of configuration user defined variables, so variables could have a scope for more than one group of threads, but it is not recommended. Variables are accessed via ${Name_of_the_variable}, if the variable is not defined and an attempt to access it is made, this will return a null value.

What is the scope of a property? #

Properties are defined in three different files: system.properties, jmeter.properties, and user.properties. The only file we should be able to modify is the third one, user.properties, because if we incorrectly modify any of the two previous ones, we run the risk of seriously altering the behavior of the tool. If we want to assign a value to an initially defined property, it can be done in the user.properties file. We have a wide range of values that we can change and for this reason we can review the user guide in the section of properties.

As we mentioned before, properties are global in scope and all the groups of threads contained within the test plan can access their value. Therefore, properties are an excellent medium for inter-group thread communication. To access the value of the properties, we can use the function __P as follows: ${__P(Nombre_de_la_Propiedad)}.

Example #

In the following example, we will parameterize the number of threads, ramp-up time, and total test duration. This same example can be found in English on the Flood.io site. We will replace the thread count group value with ${__P(threads,1)}, the ramp-up time with ${__P(rampup,1)}, and the total test duration with ${__P(duration,60)}.

The result will be that if the value of threads is not defined, it will be assigned a value of 1. This is very convenient when debugging or running locally, as well as for the ramp. If the duration is not defined, the property will be assigned a value of 60, so the test will run for 60 seconds.

To extract juice from this example of parameterization, we can run the test:

./jmeter.sh -n -t Script.jmx -l Script.jtl -Jthreads=10 -Jrampup=10 -Jduration=90

./jmeter.sh -n -t Script.jmx -l Script.jtl -Jthreads=20 -Jrampup=40 -Jduration=120

./jmeter.sh -n -t Script.jmx -l Script.jtl -Jthreads=50 -Jrampup=50 -Jduration=60

Conclusion #

Variables and properties are extremely useful and can help us solve complex logic in our tests. I recommend playing around with the values of variables and properties through the functions vars.get, vars.put, props.get, and props.put using mappers, preprocessors, and post-processors in Groovy.