Script structure

This topic describes the code layout and resource files used for DevWeb scripts in LoadRunner Developer.

main.js layout

This section describes the layout of the main.js file. This file contains the script code.

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 a typical DevWeb script that sends an HTTP request 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:

  1. 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.

  2. 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.
  3. Start the transaction (C).

  4. 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.

  5. 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.
  6. 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.

Back to top

Script resources

The following describes some of the important YAML and other files available in LoadRunner Developer for your DevWeb scripts. These files control the execution of the DevWeb engine and scripts.

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.

Example of a scenario.yml file: 

# All times are defined in seconds
vusers: 1        #The number of Vusers that will be run during the test
pacing: 2        #The number of seconds to wait between iterations of each Vuser
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 Customizing 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 Transaction file, transactions.yml, is only relevant for LoadRunner Cloud users.

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 matching names

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 API properties, see Config in the SDK documentation.

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

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

Back to top

See also: