JMeter environment configuration

Question

I have several JMeter testing plans that should run in different environments, for example Dev, Test, UAT, Live. In each test plan, I would like to have an easy way to specify which environment to use. Each environment has a large configuration, such as host name, port, ssl-cert, username, password, account numbers and other test data.

One thing I'm trying to achieve is the ease of switching the environment when using the JMeter GUI or run scripts from build scripts.

One of my ideas is to use the "Include Controller" to include another jmx file that has a list of User Defined Variables and other configuration items. However, JMeter does not support variables in the included file name, so I cannot parameterize the script by the name of the environment. The Include Controller supports the JMeter parameter "includesecontroller.prefix", but it is not very flexible, for example. I cannot change it from the JMeter GUI, I have to change the JMeter configuration files and restart it.

I tried to use the Switch Controller, but with no luck, it does not switch the configuration items, but only samplers.

What is the best practice for externalizing an environment-specific configuration from test scripts and sharing it between multiple scripts?

Answer 1

I would suggest replacing all environment-specific variables or values ​​with JMeter properties. See the following functions for reference:

• __ property ()
• __ P ()

For example, you can define a property named hostname in the jmeter.properties file or as a JMeter command line argument as follows

 jmeter -Jhostname=169.140.130.120 -n -t yourscript.jmx -l yourscriptresults.jtl 

and see inside your script how:

• ${__P(hostname,)} or
• ${__property(hostname,,)}

See the Apache JMeter Property Configuration Guide for more information.

Answer 2

As mentioned by Manish Sapariya , the Parametrized Controller is very useful for preparing for more than one environment. I used it in the previous place where I worked, and started the setup now in a new place. It works a bit at first, but lately it’s easy to maintain. There is a little tutorial in the link above, but it will not take into account that you want to run only one env at a time. I will describe it a little lower, maybe it will be useful. So slowly, step by step:

• First of all, you need two groups of threads - one for environment profiles (no 1 in the first screenshot - Env Profiler) and one for your test cases , test plans included, etc. (no 2 - API Requests). The latter should be disabled , as it is a container that cannot be started right from here (right-click → disable or Ctrl + T)
• Then you need your User Defined Elements (no 3). I use three of them:
  • first, to determine which environment will be executed (environmentType var) and logins / passwords, tokens, etc.
  • the second with identifiers for the elements needed for testing
  • the third with IP addresses, ports, route prefixes, etc.

The most important thing is that at the moment I am separating them with prefixes in variable names, so in one UDV element I have variables such as dev.serverIP, dev.serverPort, preprod.serverIP , etc. (second screenshot) populated with values ​​relevant to this environment. Also, in one of these UDVs, I have an environment variable (mentioned earlier) with the default value of "dev" (which you can change manually here or provide a different value when launched via the / CI command line or something else)

3. Now in Env Profiler I have If Controllers (no 4 in the first screenshot). For dev env I have (no 5 on the first screen):

   "$ {environmentType}" == "dev"

For each env (if controller) you must provide an appropriate state similar to the one above.

4. Each IfController contains the previously mentioned "jp @gc - Parametrized Controller" (which you can download as part of the Extras Set here path). In each Parameter controller, you assign the variables that you use in the test plan variables specific to this environment, for example. name: serverIP, value: $ {dev.serverIP} for dev env (third screenshot)

5. And now the last one is the tests and plans that you want to fulfill.
   • In this disabled thread group (API requests), you add Simple controllers containing your tests, or Enable controllers that import some tests from other files.
   • When you have these tests, for each of them that you want to run in this particular environment, you need to add the Cotroller module in the parameterized controller using the path to this test (screenshot below)

And that is pretty much the case. Now we support:

• to add a new variable, you must add it to UDV with prefixes (dev.newVar, preprod.newVar) and fill in the corresponding values, and then add the corresponding entry to the parameterized controllers (those new Var = $ {dev.newVar}) and that it
• to add a new test from another test plan - add an Include controller with the path to this file and add a module controller in each parameterized controller, directing them to this inclusion controller
• to add a new environment, just copy the one you already have, change its If contr., Parametrized option and fill values ​​in UDV. It's nice that if you want, say, dev env with all the tests, and the other with just some then trial tests, you can prepare a copy, change If the controller takes a different value for the env variable (for example, dev for all tests, devsmoke for smoke tests) and add or remove some of the module controllers in this new profile. Of course, you can create it a little, and you can use different threads for different parts of the system to simplify maintenance, just remember to disable those threads that work as containers.

I know this a lot when you start, but it’s not so bad when you just add some things - perhaps the easiest way to do this anyway.

Answer 3

As the current solution, I use a JSR223 sampler with custom JavaScript code to configure variables from external file properties. Something like that:

 var file = new java.io.File(args[0]); var props = new java.util.Properties(); var is = new java.io.FileInputStream(file); props.load(is); is.close(); for(var it = props.entrySet().iterator(); it.hasNext();) { var entry = it.next(); vars.put(entry.getKey(), entry.getValue()); } 

Now I just need to add this code as the very first sampler in terms of testing and pass the path to a specific file as parameter sampler args[0] , it will load the variables from the file and put them into JMeter variables.

Answer 4

I have not used myself, but this jmeter-pluing can help you. Here is a snippet from the documentation

 Parameterized Controller since 0.1.0 When your JMeter test plan tree becomes like a sequoia or a banyan, you start feeling yourself like a monkey in a jungle, jumping from branch to branch, trying to support this important test consistent. You really need some way to have parameterized subroutines, to reuse parts of test plan like regular programming language functions and procedures. JMeter have out-of-box Module controller, but it has no parameters to pass to, so if you need to call repeating sequence of the same action with different parameters, your reflection in a mirror starts morphing into monkey. Parameterized Controller helps you stay human and sane. 

Answer 5

I have the same problem. My current approach is to have multiple user variables (UDVs) like DevVariables, TestVariables etc. Each of them has the same variables (host name, port, etc.). Then I will manually disable those UDV elements that are not used.

Edit:

The JMeter User Manual states, “The User Defined Variables element allows you to define the initial set of variables, as in the test plan. Note that all UDV elements in the test plan — regardless of where they are located — are processed from the very beginning.” I’m not sure what the “start” event is, but it looks like you cannot conditionally enable UDV, at least not through controllers.

You may have one UDV per test plan, where you set various variables (host, etc.). Perhaps you can set each variable value with an ugly JavaScript function that discards the property value of the passed object.

You can try asking a question in the Apache JMeter User mailing list . There must be a way to do what you want.