Run a performance test using LoadRunner Enterprise

This topic describes how to use LoadRunner Enterprise integration with Git plugin to run a test using LoadRunner Enterprise. You can also configure the plugin to fully automate all aspects of the testing process: create a test from a YAML file or YAML content, synchronize tests from YAML files saved in a GitHub repository to a LoadRunner Enterprise project, and then run the test in LoadRunner Enterprise.

Upload the plugin to the Jenkins server

The LoadRunner Enterprise-Git integration plugin enables you to synchronize performance test scripts from a Github repository to a project on the LoadRunner Enterprise server.

Install the Jenkins server.
Install the LoadRunner Enterprise integration with Git plugin.

For details on downloading and installing this plugin, see LoadRunner Enterprise Integration With Git.
1. Go to Jenkins home > Manage Jenkins > Manage Plugins > Advanced.
2. In the Upload Plugin section, select the micro-focus-performance-center-integration.hpi file and click Upload.
3. Restart Jenkins if required.

Set up a Jenkins job to run tests using LoadRunner Enterprise

Set up a Jenkins job to run a performance test using LoadRunner Enterprise as described in Set up a Jenkins job to run tests in LoadRunner Enterprise, with the following changes:

In the Build section, expand the Add build step drop-down and select Run Performance Test Using LoadRunner Enterprise (in step 6).
In the Run Test section (in step 11), select Run an existing test, and enter the Test ID. You can get the ID from LoadRunner Enterprise > Test Management > Test Lab > Performance Test Set view. If the column is not visible, you can select it by clicking the Select Columns button.

Create a LoadRunner Enterprise test from YAML input

Available in plugin versions: 1.1.0 and later

When setting up a Jenkins job to run a performance test using LoadRunner Enterprise, you can create a new LoadRunner Enterprise test from YAML files stored in Git.

Set up a Jenkins job to run a performance test using LoadRunner Enterprise as described in Set up a Jenkins job to run tests in LoadRunner Enterprise, with the following changes:

In the Build section, expand the Add build step drop-down and select Run Performance Test Using LoadRunner Enterprise (in step 6).
In the Run Test section (in step 11), select Create a new test, and in the Test To Create box, enter text in YAML syntax representing a LoadRunner Enterprise test, or provide a path to a YAML file relative to the workspace.

The content of the field must either be:
- Text in YAML syntax composed according to the parameters described in the tables below. You must set values to the test_name and test_folder_path parameters, and continue with the test_content parameter and its sub-parameters.
- You can also specify as a value a relative path to a YAML file within the workspace (or within your Git repository cloned within the workspace). In the YAML file, only specify the parameters defined in the test_content table. The following logic is used to create the LoadRunner Enterprise test:
  - The file name (without extension) is used as the test name.
  - The location of the file in the Git repository is the location of the test under the root folder ('Subject') in the test management tree.
  - The content of the YAML file must consist of the parameters, and their sub-parameters, listed in the test_content table below.

Note:

All parameters must be in lowercase.
When a backslash (\) occurs in a value provided to a parameter (for example, a folder separator in a file path), a double backslash (\\) must be used instead.

Root parameters of the field:

Parameter	Description	Required
test_name	The test name.	Yes
test_folder_path	The location of the test folder in the test management tree of the LoadRunner Enterprise project. Example: "MyMainFolder\\MySubfolder\\MySubSubFolder" Note: Use a double backslash (\\) to separate folders. Do not include the LoadRunner Enterprise root folder (named "Subject").	Yes
test_content	The content of the test that requires additional parameters specified in the test_content table below.	Yes

Parameter

Description

Required

test_name

The test name.

Yes

test_folder_path

The location of the test folder in the test management tree of the LoadRunner Enterprise project.

Example: "MyMainFolder\\MySubfolder\\MySubSubFolder"

Note:

Use a double backslash (\\) to separate folders.
Do not include the LoadRunner Enterprise root folder (named "Subject").

Yes

test_content

The content of the test that requires additional parameters specified in the test_content table below.

Yes

test_content

If a YAML file is specified in the field, these are the root parameter to be used in the file content:

Parameter	Description	Required
controller	Defines the Controller to be used during the test run (it must be an available host in the LoadRunner Enterprise project). If not specified, a Controller is chosen from the different controllers available in the LoadRunner Enterprise project. Available with plugin version 1.1.1 and later: You can provision a Controller as a Docker image by specifying the value "Elastic" and providing a value for the controller_elastic_configuration parameter (see controller_elastic_configuration table below).	No
scheduler	Defines the duration of a test, and determines whether virtual users are started simultaneously or gradually. See the scheduler table below.	No
group	Lists all groups or scripts defined in the test. The parameter to be used in each group are specified in the group table below.	Yes
lg_amount	Number of load generators to allocate to the test (every group in the test is run by the same load generators).	Not required if each group defined in the group parameter defines the load generators it uses via the lg_name parameter (see group table below).
lg_elastic_configuration (Available with plugin version 1.1.1 and later)	Defines the image to be used to provision load generators. See the lg_elastic_configuration table below.	Yes, if a load generator is defined to be provisioned from a Docker image.
controller_elastic_configuration (Available with plugin version 1.1.1 and later)	Defines the image to be used in order to provision the Controller. See the controller_elastic_configuration table below.	Yes, if the Controller is defined to be provisioned from a Docker image.

group:

Parameter	Description	Required
group_name	Name of the group (it must be a unique name if several groups are defined).	Yes
vusers	Number of virtual users to allocate to the group for running the script.	Yes
script_id	ID of the script in the LoadRunner Enterprise project.	Not required if the script_path parameter is specified.
script_path	Path and name of the script to be added to the group, separated by double backslashes (\\). For example "MyMainFolder\\MySubFolder\\MyScriptName'. Do not include the LoadRunner Enterprise root folder (named "Subject").	Not required if script_id parameter is specified
lg_name	List of load generators to allocate to the group for running the script. The supported values are: The hostname, as defined in LoadRunner Enterprise, of an existing load generator in LoadRunner Enterprise allocated as a host. "LG" followed by a number, to use an automatically matched load generator (recommended). "DOCKER" followed by a number, to use a dynamic load generator. This option requires that the lg_elastic_configuration parameter is defined (see the lg_elastic_configuration table below).	No
command_line	The command line applied to the group.	No
rts	Object defining the runtime settings of the script. See the rts table below.	No

rts:

Parameter	Description	Required
pacing	Can be used to define the number of iterations the script runs and the required delay between iterations (see the pacing table below).	No
thinktime	Can be used to define think time (see the thinktime table below).	No
java_vm	Can be used when defining Java environment runtime settings (see the java_vm table below).	No
jmeter	Can be used to define JMeter environment runtime settings (see the jmeter table below).	No

pacing:

Parameter	Description	Required
number_of_iterations	Specifies the number of iterations to run; this must be a positive number.	Yes
type	Possible values for type attribute are: immediately: ignores the delay and delay_random_range parameters. This is the default value when no type is specified. fixed delay: The delay parameter is mandatory. random delay: The delay and delay_random_range parameters are mandatory. fixed interval: The delay parameter is mandatory. random interval: The delay and delay_random_range parameters are mandatory.	No
delay	Non-negative number (less than delay_at_range_to_seconds when specified).	Depends on the value provided for the type parameter.
delay_random_range	Non-negative number. This is added to the value given to the delay parameter (the value is randomly chosen between the value given to the 'delay' parameter and the same value to which is added the value of this parameter).	Depends on the value provided for the type parameter.

thinktime:

Parameter	Description	Required
type	The thinktime type attribute is one of: ignore: This is the default value when no type is specified. replay: Provide the limit_seconds parameter with value (optional). modify: Provide the limit_seconds parameter with a value (optional). The multiply_factor parameter must be set with value. random: Provide the limit_seconds parameter with value (optional). The min_percentage and max_percentage parameters must be set with values.	No
min_percentage	This must be a positive number.	Depends on the value provided for the type parameter.
max_percentage	This must be a positive number (it must be larger than the value provided for the min_percentage parameter).	Depends on the value provided for the type parameter.
limit_seconds	This must be a positive number.	Depends on the value provided for the type parameter.
multiply_factor	The recorded think time is multiplied by this factor at runtime.	Depends on the value provided for the type parameter.

java_vm:

Parameter	Description	Required
jdk_home	The JDK installation path.	No
java_vm_parameters	List the Java command line parameters. These parameters can be any JVM argument. The common arguments are the debug flag (-verbose) or memory settings (-ms, -mx). In additional, you can also pass properties to Java applications in the form of a -D flag.	No
use_xboot	Boolean: Instructs VuGen to add the Classpath before the Xbootclasspath (prepend the string).	No
enable_classloader_per_vuser	Boolean: Loads each Virtual User using a dedicated class loader (runs Vusers as threads).	No
java_env_class_paths	A list of classpath entries. Use a double backslash (\\) to separate folders.	No

jmeter:

Parameter	Description	Required
start_measurements	Boolean value to enable JMX measurements during performance test execution.	No
jmeter_home_path	Path to JMeter home. If not defined, the path from the %JMETER_HOME% environment variable is used.	No
jmeter_min_port	This number must be lower than the value provided in the jmeter_max_port parameter. Both jmeter_min_port and jmeter_max_port parameters must be specified otherwise the default port values is used.	No
jmeter_max_port	This number must be higher than the value provided in the 'jmeter_min_port' parameter. Both jmeter_min_port and jmeter_max_port parameters must be specified otherwise the default port values is used.	No
jmeter_additional_properties	JMeter additional properties file. Use a double backslash (\\) to separate folders.	No

scheduler:

Parameter	Description	Required
rampup	Time, in seconds, to gradually start all virtual users. Additional virtual users are added every 15 seconds until the time specified in the parameter ends. If no value is specified, all virtual users are started simultaneously at the beginning of the test.	No
duration	Time, in seconds, that it takes to run the test after all virtual users are started. After this time, the test run ends. If not specified, the test runs until completion.	No

lg_elastic_configuration:

Available with plugin version 1.1.1 and later.

Parameter Description Required

Parameter	Description	Required
image_id	The image ID can be retrieved from: LoadRunner Enterprise Administration (contact your LoadRunner Enterprise administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Load Generator purposes with their ID. You can check that the images are available to your project from the Orchestrators tab. A LoadRunner Enterprise Rest API command applied on the project (replace the bracketed values): `GET - http(s)://(LR_Enterprise_Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/` and select any valid image that does not have the value 'controller' for purpose.	Yes if one of the load generator is defined to be provisioned from the Docker image.
memory_limit	This parameter can be retrieved from LoadRunner Enterprise. In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test. Click Assign LGs , and in the Elastic section, select DOCKER1 and select the relevant image (based on the image name). Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter).	Yes, if the image is defined with resource limits.
cpu_limit	This parameter can be retrieved from LoadRunner Enterprise. In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test. Click Assign LGs . In the Elastic section, select DOCKER1 and select the relevant image (based on the image name). Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter).	Yes, if the image is defined with resource limits.

image_id

The image ID can be retrieved from:

LoadRunner Enterprise Administration (contact your LoadRunner Enterprise administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Load Generator purposes with their ID. You can check that the images are available to your project from the Orchestrators tab.
A LoadRunner Enterprise Rest API command applied on the project (replace the bracketed values):

GET - http(s)://(LR_Enterprise_Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/

and select any valid image that does not have the value 'controller' for purpose.

Yes if one of the load generator is defined to be provisioned from the Docker image.

memory_limit

This parameter can be retrieved from LoadRunner Enterprise.

In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test.
Click Assign LGs , and in the Elastic section, select DOCKER1 and select the relevant image (based on the image name).
Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter).

Yes, if the image is defined with resource limits.

cpu_limit

This parameter can be retrieved from LoadRunner Enterprise.

In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test.
Click Assign LGs . In the Elastic section, select DOCKER1 and select the relevant image (based on the image name).
Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter).

Yes, if the image is defined with resource limits.

controller_elastic_configuration:

Available with plugin version 1.1.1 and later.

Parameter Description Required

Parameter	Description	Required
image_id	The image ID can be retrieved from: LoadRunner Enterprise Administration (contact your LoadRunner Enterprise administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Controller purposes with their ID. You can check that the images are available to your project from the Orchestrators tab. A LoadRunner Enterprise Rest API command applied on the project (replace the bracketed values): `GET - http(s)://(LR_Enterprise_Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/` and select any valid image that does not have the value 'controller' for purpose.	Yes if one of the Controller is defined to be provisioned from the Docker image.
memory_limit	This parameter can be retrieved from LoadRunner Enterprise. In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test. Click Assign LGs . In the Elastic section, select DOCKER1 and select the relevant image (based on the image name). Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter).	Yes, if the image is defined with resource limits.
cpu_limit	This parameter can be retrieved from LoadRunner Enterprise. In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test. Click Assign LGs , and in the Elastic section, select DOCKER1 and select the relevant image (based on the image name). Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter).	Yes, if the image is defined with resource limits.

image_id

The image ID can be retrieved from:

LoadRunner Enterprise Administration (contact your LoadRunner Enterprise administrator if you do not have admin permissions). Select Configuration > Orchestration, and click the Docker Images tab to display the list of all available Docker images for Controller purposes with their ID. You can check that the images are available to your project from the Orchestrators tab.
A LoadRunner Enterprise Rest API command applied on the project (replace the bracketed values):

GET - http(s)://(LR_Enterprise_Server):(PortNumber)/LoadTest/rest/domains/ (DomainName)/projects/(ProjectName)/dockerimages/

and select any valid image that does not have the value 'controller' for purpose.

Yes if one of the Controller is defined to be provisioned from the Docker image.

memory_limit

This parameter can be retrieved from LoadRunner Enterprise.

In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test.
Click Assign LGs . In the Elastic section, select DOCKER1 and select the relevant image (based on the image name).
Use the values provided in the Memory (GB) dropdown list (if none specified, ignore this parameter).

Yes, if the image is defined with resource limits.

cpu_limit

This parameter can be retrieved from LoadRunner Enterprise.

In the navigation toolbar, select Test Management. Select a performance test in the test management tree, and click Edit Test.
Click Assign LGs , and in the Elastic section, select DOCKER1 and select the relevant image (based on the image name).
Use the values provided in the CPUs dropdown list (if none specified, ignore this parameter).

Yes, if the image is defined with resource limits.

Example scripts

Example 1

##################################################
test_name: mytestname
test_folder_path: "Tests\\mytests" 
test_content:
  group:
    - group_name: "TEstInt"
      vusers: '20'
      script_path: "plugin\\TEstInt"
      lg_name:
	 - "LG1"
	 - "LG2"
    - group_name: "Mtours"
      vusers: '20'
      script_path: "plugin\\mtours"
      lg_name:
	 - "LG3"
	 - "LG4"
  scheduler:
     rampup: '45'
     Duration: '300'
##################################################

In the example above:

The test name is "mytestname" and it is placed in the LoadRunner Enterprise project under the folder path "Subject\\Tests\\mytests". Do not specify the root folder of the folders (which is "Subject"), in the parameter . The folder separator is a double backslash (\\).
In the content:
- Since no Controller and no load generator amount were specified, a random available Controller is allocated to the test just before it is run, and the lg_name parameter specified in each group is used.
- In the group parameter:
  - Two scripts are added, each with a unique value in the group_name parameter, and the number of virtual users to run the group (vusers).
  - Since the ID of the scripts in the LoadRunner Enterprise project is unknown, the script_path parameter (without "Subject") followed by the script name is used, with double backslashes for separators.
  - The load generators used by each group are specified (in this case, load generators are automatically matched because the 'LG' prefix is used).
In the scheduler, all Vusers are initialized gradually (every 45 seconds), and the test will stop after 5 minutes (300 seconds).

Example 2

##################################################
group:
  - group_name: "TEstInt"
    vusers: '20'
    script_path: "plugin\\TEstInt"
    lg_name:
	 - "LG1"
	 - "LG2"
  - group_name: "Mtours"
    vusers: '20'
    script_path: "plugin\\mtours"
    lg_name:
	 - "LG3"
	 - "LG4"
scheduler:
   rampup: '45'
   Duration: '300'
##################################################

In the example above, a YAML file location is specified as the value, and the content of the file contains the code below:

The plugin automatically assigns the file name as the test name, and the folder path of the file in the Git repository is used to create the location of the test under the root folder ('Subject') in the LoadRunner Enterprise project.
In the content:
- Since no Controller and no load generator amount were specified, a random available Controller is allocated to the test just before it is run, and the lg_name parameter specified in each group is used.
- In the group parameter:
  - Two scripts are added, each with a unique value in the group_name parameter, and the number of virtual users to run the group (vusers).
  - Since the ID of the scripts in the LoadRunner Enterprise project is unknown, the script_path parameter (without "Subject") followed by the script name is used, with double backslashes for separators.
  - The load generators used by each group are specified (in this case, load generators are automatically matched because the 'LG' prefix is used).
In the scheduler, all Vusers are initialized gradually (every 45 seconds), and the test will stop after 5 minutes (300 seconds).

Example 3

##################################################
controller: "mycontroller"
lg_amount: 3
group:
   - group_name: "JavaVuser_LR_Information_pacing_immediately_thinktime_ignore"
     vusers: 50
     script_id: 394     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "immediately"
	java_vm:
	   jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
	   java_vm_parameters: "java_vm_parameters"
	   enable_classloader_per_vuser: true
	   use_xboot: true
	   java_env_class_paths:
		- "java_env_class_path1"
		- "java_env_class_path2"
	thinktime:
	   type: "ignore"

   - group_name: "JavaHTTP_BigXML_pacing_fixed_delay_thinktime_replay"
     vusers: 50
     script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "fixed delay"
	   delay: 10
	java_vm:
	   jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"    java_vm_parameters: "java_vm_parameters"
	   enable_classloader_per_vuser: true
	thinktime:
	   type: "replay"
	   limit_seconds: 30

   - group_name: "JavaVuser_LR_Information_immediately_pacing_random_delay_thinktime_modify"
     vusers: 50
     script_id: 394     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "random delay"
	   delay: 10
	   delay_random_range: 20
	java_vm:
	   jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
	   java_vm_parameters: "java_vm_parameters"
	   enable_classloader_per_vuser: true
	   java_env_class_paths:
		- "java_env_class_path1"
		- "java_env_class_path2"
	thinktime:
	   type: "modify"
	   limit_seconds: 30
	   multiply_factor: 2

   - group_name: "JavaHTTP_BigXML_pacing_fixed_interval_thinktime_random"
     vusers: 50
     #script_id: 392
     script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "fixed interval"
	   delay: 10
	java_vm:
	   jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
	   java_vm_parameters: "java_vm_parameters"
	   enable_classloader_per_vuser: true
	   java_env_class_paths:
		- "java_env_class_path1"
		- "java_env_class_path2"
	thinktime:
	   type: "random"
	   limit_seconds: 30
	   min_percentage: 2
	   max_percentage: 3

   - group_name: "JavaHTTP_BigXML_pacing_random_interval"
     vusers: 50
     script_path: "scripts\\java_protocols\\JavaHTTP_BigXML"     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "random interval"
	   delay: 10
	   delay_random_range: 20
	java_vm:
	   jdk_home: "C:\\Program Files\\Java\\jdk1.8.0_191"
	   java_vm_parameters: "java_vm_parameters"
	   enable_classloader_per_vuser: true
	java_env_class_paths:
		- "java_env_class_path1"
		- "java_env_class_path2"

   - group_name: "Mtours_pacing_random_interval"
     vusers: 50
     script_path: "scripts\\Mtours"     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "random interval"
	   delay: 10
	   delay_random_range: 20
	jmeter:
	   start_measurements: true
	   jmeter_home_path: "c:\\jmeter"
	   jmeter_min_port: 2001
	   jmeter_max_port: 3001
	   jmeter_additional_properties: "jmeter_additional_properties"

   - group_name: "Mtours_pacing_random_interval_Jmeter_default_port"
     vusers: 50
     script_path: "scripts\\Mtours"     
     rts:
	pacing:
	   number_of_iterations: 2
	   type: "random interval"
	   delay: 10
	   delay_random_range: 20
	jmeter:
	   start_measurements: true

scheduler:
   rampup: 120
   duration: 600
##################################################

In the example above:

The plugin automatically assigns the file name as the test name, and the folder path of the file in the Git repository is used to create the location of the test under the root folder ('Subject') in the LoadRunner Enterprise project.
Since the controller and the lg_amount parameters are specified, the specified Controller is used to run the test, and three automatch load generators are used and shared by all groups.
The content of the file is defined with seven groups, all being set with the rts parameter:
- The pacing parameter is used with different options for all groups.
- The java_vm parameter is used for five scripts with JavaVM for protocol.
- The thinktime parameter is used with different options for four groups.
- The jmeter parameter is used for two scripts with JMeter for protocol.
In the scheduler:, all Vusers are initialized gradually (every 120 seconds), and the test will stop after 10 minutes (600 seconds).

Run the job

Run or schedule the job as you would with any standard Jenkins job.

Configure Trending Report Charts on Jenkins

For details, see Configure trending report charts on Jenkins.

Tips and troubleshooting

For details, see Tips and troubleshooting.

Run a performance test using LoadRunner Enterprise

Upload the plugin to the Jenkins server

Set up a Jenkins job to run tests using LoadRunner Enterprise

Create a LoadRunner Enterprise test from YAML input

Run the job

Configure Trending Report Charts on Jenkins

Tips and troubleshooting

Send Help Center Feedback