Script structure

This topic describes the layout of the main.js file used for DevWeb scripts. It also describes some of the important YAML and other files available for the DevWeb scripts. These files control the execution of the DevWeb engine and scripts.

main.js file

The main.js file contains the main code for your DevWeb script.

main.js can contain three types of sections: initialize, action, and finalize. These can appear more than once and are executed in the order that they appear in the script.

initialize (optional)

Executed only once at the beginning of the script.

action (mandatory)

Executed in iterations throughout the duration of the script.

Note: The script must contain at least one action section.

finalize (optional)

Executed only once at the end of the script, when all the action sections are finished running.

Tip: You can implement run logic to determine the order in which actions run during a test. For details, see Implement run logic.

The following is an example of the action section for a typical DevWeb script. An HTTP request is sent to a server and then uses some values from the response to determine if the transaction around that HTTP request has passed.

load.action("Main", () => { //(A)

  const productTransaction = new load.Transaction("Product"); //(B)

  productTransaction.start(); //(C)
  const myPageRequest = new load.WebRequest({ //(D)
	url: "http://myServer.com/main/product.html", //(E)
	method: "GET",
	returnBody: true,
	headers: {
	   "Accept-Language": "en-US,en;q=0.8",
	   "Accept-Encoding": "gzip, deflate, sdch",
	   "Accept": "*/*"
	},
	resources: [
	   "http://my.server.net/sources/Caching/oldnavy.css"
	]
  });

  const myPageResponse = myPage.sendSync(); //(F)

  /*Expected result is :
  <html>
     <body>
	<h1>My product</h1>
	<span productId="12">Very nice product</p>
     </body>
  </html>
  */

  const productId = load.utils.getByBoundary(myPageResponse.body,'productId="','"'); //(G)
  if (productId === null){ //(H)
     productTransaction.stop(load.TransactionStatus.Failed);
  }  else {
     productTransaction.stop(load.TransactionStatus.Passed);
  }
});

The flow:

Declare a new action (A), Main, with a function containing all the code that will be executed as part of this action.

All the elements of the SDK are within the load namespace (object), therefore the load. prefix is needed to access them.

Note: The action name is mandatory and used internally only.
Declare a new transaction (B), Product, and store it in the productTransaction variable. This variable allows for obtaining information about the transaction and performing operations on it.
Start the transaction (C).
Declare a web request using the WebRequest constructor (D). The WebRequest constructor takes an object that configures the web request.

For example, you can declare the URL for the web request (E). You can also set other properties for the request such as the header and extra resources. See WebRequest in the DevWeb JavaScript SDK.
Send the request synchronously (F). The script stops and waits to receive a response, and stores the response in the myPageResponse variable. Because the returnBody property is set to true in the web request options, you can access the full response body.
Use the getByBoundary function (G) to extract the product ID from the response. Using the product ID (H), you can determine if the Product transaction should pass or fail.

Note: After receiving the web response, you can view additional web request headers (on the WebRequest headers object) added during replay.

Scenario resource file

The scenario.yml file defines the scenario settings when running a DevWeb script in load mode. For details, see Run scripts.

Note: This file is used for LoadRunner Developer only. When running a test in LoadRunner Professional or LoadRunner Enterprise, the scenario is defined in the testing tool itself.

The scenario run settings include pacing. Pacing controls the timing of iterations, by setting the pace for the Vuser to wait between iterations of the script actions. You can define the pacing as follows:

Property	Description
type	Pacing type. Possible values: delay. A delay after the previous iteration ends. interval. The interval from the beginning of one iteration to the next. Note: New iterations will not begin until the previous one completes, even if it exceeds the interval time.
mode	Pacing duration. Possible values: fixed. A fixed amount of time is used for the defined pacing type (delay or interval). random. An amount of time is selected at random for the pacing type (delay or interval), from a defined range of values.
value	The amount of time to use with fixed mode (in seconds).
min/max	The time range to use with random mode (in seconds).

Example of a scenario.yml file:

Copy code

# All times are defined in seconds
vusers: 1        #The number of Vusers that will be run during the test
pacing:          #The period of time to wait between iteration of each Vuser
  type: delay    #The Pacing type, valid values: delay or interval 
  mode: random   #The Pacing mode, valid values: fixed or random
  min: 3         #The min and max are valid on mode: random.
  max: 6         #The min and max determine the range of values
rampUp: 2        #The number of seconds it will take to start all the Vusers
                 #The starting of Vusers that will be distributed equally throughout this time frame
duration: 20     #The number of seconds to run Vuser iterations after all the Vusers have started running
tearDown: 0      #Not used

Runtime settings resource file

The optional rts.yml contains the default runtime settings for test runs, for example, timeouts for HTTP connections and logger settings.

The runtime settings are specific to each Vuser. If you want to customize these settings, you can do so in a local runtime settings file that you create in the script's folder. For details, see Customize runtime settings.

Parameter resource file

The optional parameters.yml contains the parameter descriptions for your script. This file is user-defined in the script folder.

The parameters file defines the parameters that can be used in the script and various aspects of how and when new values are retrieved.

For more information, see Parameterize values.

Transactions resource file

The optional transactions file, transactions.yml, is relevant for LoadRunner Cloud users only.

To enable the SLA feature of LoadRunner Cloud, populate this file with a list of transaction names for which to calculate the SLA.

Note: The script must contain transactions with names that match the ones in transactions.yml.

Format the list as shown in the following example, where two transactions are defined, named foo and bar:

- name: foo

- name: bar

Rendezvous resource file

The optional rendezvous.yml file is created automatically in the script directory during replay, if the main script contains rendezvous points. When a rendezvous point is reached, the Vuser stops running and waits for permission to continue.

Note: Rendezvous points are supported when running scripts in LoadRunner Professional or LoadRunner Cloud. They are not supported when executing scripts locally using LoadRunner Developer.

The rendezvous.yml file provides a list of rendezvous names, required by LoadRunner Cloud to define the rendezvous policy. The file uses the following format:

- name: foo

- name: bar

In the above example, the file contains two rendezvous points with the names foo and bar. The script must contain rendezvous with matching names for the rendezvous functionality to work in LoadRunner Cloud.

Before uploading a script to LoadRunner Cloud, you must replay the script once so that the rendezvous.yml file is included in the zip file for the script.

For details on adding the rendezvous function to your script, see the JavaScript SDK Rendezvous section.

User arguments resource file

The optional user arguments file, user_args.json, contains arguments that are used in the script for execution. These arguments are equivalent to the custom command line options used for VuGen scripts.

For argument properties, see Config in the SDK documentation.

The file is in a key-value JSON format (string values):

{
    "key": "value",
    "hello": "world"
}