One of JMeter's most twisted areas to get accustomed to is the general concept of 'variables'.
There are four basic types of value holders most people would refer to as 'variables' in JMeter
- User Defined Variables (UDV)
- Properties
- User Parameters
- Sampler Response
Many things act on the Sampler Response, which is the data set returned from a sampler, but that one is a bit out side the notion of variables we are talking about here.
The main differences between UDV, Properties, and User Parameters are when the values are set, their scope, and when they can be updated.
UDVs are the most static of the bunch. UDVs are defined in a UDV Config Element. UDV elements are evaluated at the start of a test plan and not updated again during the run of the test. So putting a UDV in a loop controller is not going to re-evaluate the variable each pass of the loop. A UDVs value is also only relative to it own thread. So they can not be used to share the same result between threads, but they can be used as local data holder where each thread may have a different value. I use them for better readability in my scripts for initial setup values (test server IP, a username, etc) but they generally are of limited use beyond that due to the startup-only evaluation of the UDV elements.
UDVs are referenced by ${name}
Properties are the most general data holder in JMeter. There is also the distinction between system properties and user properties. I'll defer you to the JMeter documentation to look into system properties. I haven't had a need for them yet. Unlike UDV which are defined in a Configuration Element, properties are defined
- in a .properties file loaded at JMeter startup.
- by the __setProperty function
- by the command line option -Jpropertyname=value when starting JMeter
This exposure to taking input from outside of JMeter makes properties especially valuable. Properties also have a scope of the entire Test Plan, so you can share values between threads using Properties. Using __setProperty you can overwrite the existing value of a property as well to update some running value if needed.
I use properties to fill in test plan values, and use the default value argument to ensure if the property isn't defined, the test will still execute. Example, to fill in the UDV used for the server address in my test plan, I define the value to be:
${__P(p_tmsIP,10.1.2.183)}
If p_tmsIP is not defined in the .properties files or on the command line, 10.1.2.183 is used
When defining custom properties and I want to load them easily, I use the user.properties file. WARNING - this file is only read on JMeter startup! So if you are using the GUI and leave JMeter open, changing the file once JMeter is opened will not change the values JMeter uses.
User Parameters are a special type of user variable that have two cool features. First, they allow you to define a variable that has a different value per thread, and second, they allow you to define the variable's value to be updated either each time its referenced, or once each time the parent element is passed in the test plan. The first functionality allows you to define a variable and a list of values, each thread will take the next available value defined for the variable. You define multiple values by adding 'users' which adds a new column. I haven't had a need for this yet. The User Parameter is referenced just like a UDV: ${name}
The second notion of when the variable is evaluated is very valuable. If the 'Update Once Per Iteration' checkbox is left unchecked, the expression in the value definition of the variable will be re-evaluated each time the variable is used. So if you have a variable that needs to be evaluated each time its used.. say it includes a time function, that would be very helpful.
Where I have found use in User Parameters is to have the Update Once checkbox marked, this means the value expression will be updated only when the element is passed in the test plan, and the value remains the same until the next pass. This is very valuable in loops. It allows you to evaluate a variable at the start of the loop, maintain the value through, and get a new value on the next loop iteration.
An Example is below. I have a loop that runs a series of samplers that are related in they should use the same variable logid, but I need logid to be unique for each pass through the loop. Each time the loop runs, a new data set should be used. The test plan looks like this:
In this test, the variable logid is defined as $__time(HMS)} in the User Parameter element. This allows me to generate a pretty simple, unique Integer that is refreshed each time the loop is executed, but remain constant through the 3 samplers. This also allows this same block of code to be used by multiple threads and each executed loop will have a unique logid.
Mastering how to use the User Parameter Element has been key to building scripts with loops that are intended to run with multiple threads.
