The Repository

The Repository contains all the web pages used to set up the Virtual Users. It is also the place where the web page's settings, such as request definition and content assertion, may be configured. During a recording, all the recorded pages are created in a container, which is stored in the Repository. See the section called “Recording a Test Scenario” for further details.

Servers

The servers pane is used to declare and modify the web servers used in the scenario. The servers are automatically created when the scenario is recorded. The server settings are centralized, which means the target server for the test can be quickly changed. It is possible, for example, to quickly switch from the development to the pre-production server.

Select the server to bring up its settings pane:

  • Http server definition. Displays the server definition. Change hostname and port to switch physical server for all requests using the current server.

  • Authorizations. Settings for basic HTTP and NTLM-type authentications. The password-protected zones (realms and domains) are detected during the recording and automatically added. The accounts may be dynamic and changed for each user being simulated, using variables.

  • HTTP URL rewriting. Session tracking is automatically enabled when cookies are used. For servers that use URL rewriting to track a session, the session argument must be defined (e.g. SESSIONID or JSESSIONID for most servers). When detected during recording, the argument is automatically filled in.

Web pages

The web pages is the page as it is composed in a web browser. It consists of the HTML page and its sub-components, such as image files and CSS style sheets.

  • Name - The name of the web page in NeoLoad.

  • URL - The URL of the first HTTP request forming the page is displayed here for information purposes.

  • Description - A description of the web page can be entered here if required.

  • Think time - The think time is the interval before a web page is accessed. This corresponds to the time a real user will spend reading the page displayed by the browser before clicking on a link. Use this box to set the think time for this page or click on the link to the Runtime Policy pane to set a global think time for all pages. The default policy is to use the think time defined for each page (to change this policy, click on the same link).

  • Web page screenshot - A screenshot of the browser content at the instant the web page was recorded.

    Please note that this function is only available in Windows and is merely a reminder of what was displayed in the browser window when the web page was recorded. Screenshots are only available for web pages with an HTML content. If the screenshot does not mirror the actual web page, it may be deleted.

    Automatic screenshots during recording may be turned off by changing the value of the recorder.screenshot.enabled key in the GUI section of the /conf/controller.properties file to false.

HTTP requests

In NeoLoad, an HTTP request is the sending of a request over a network using the HTTP or HTTPS protocol. Normally the request is followed by a server response, which can be in the form of an HTML web page, image or CSS file among others.

Type

The request type can be defined in three ways:

  • Manual definition. A static definition of the request. Define the URL and the parameters.

  • HTTP redirect. Indicates that the current request is the target of an HTTP redirect command contained in the server response to the previous request. When a request is defined as an HTTP redirect, the Load Generator plays the request ignoring the recorded URL and parameters. It uses the result of the previous request dynamically. (The previous request must be of the "302 Moved Temporarily" type). This is very useful for pages which include redirects containing dynamically-generated parameter values (for example: /searchresult.jsp?searchID=481825).

  • Link extractor. Extracts and follows a link matching a dynamic definition. It is also called a form extractor in the case of form POST-type requests. It should be used when a test scenario simulates a click on a dynamically-generated link. The Load Generator extracts the link dynamically from the results of the previous request (referrer) and follows it. The extraction is carried out using regular expressions (regexes).

    One typical instance is where one or several parameters are dynamic. Use the "Set as dynamic value" button to create the regex by default.

    ".*" indicates a wildcard character. In the previous example, the first link encountered, in the form /petsore/search.screen?searchID=<anyvalue>, matches the regular expression and is extracted. Regular expressions enable advanced extraction to be carried out.

    Note that all the parameters, in addition to the URL, may contain regular expressions. Consequently, the following special characters reserved for regular expressions must be escaped using the '\' character: [ ] ^ \ { } ( ) + ? . *

    When extracting a link or form, NeoLoad variables may be automatically created, containing the parameter values of the link when run. The dynamic element of a link can thus be extracted and used in other requests. For example, if your application frequently uses a same dynamic parameter, you can define a link extractor for the first use of that parameter, then use the variable in all the other requests that use the parameter. This avoids multiple searches in server responses and thus enhances the efficiency of the Load Generators.

    Refer to the sections on link and form extractors for further details and examples.

Request parameters

Parameters can be defined for the submission of forms by the POST or GET methods. Some can have static values assigned to them and others dynamic values, using variables. When the encode checkboxes are checked, the specified values are converted to the application/x-www-form-urlencoded MIME format before being submitted (encode space as %20 for example). Clear the checkbox if either the name or value is already encoded.

POST requests with binary content

POST requests with an "application/octet-stream" -type content or non-standard charset are processed by NeoLoad as if they were binary content. This ensures that no URL or charset encoding is carried out on the contents before playing.

POST requests with text content

POST requests with a "text/..." -type content. The contents of these requests may contain NeoLoad variables for generating dynamic content.

Multi-part POST parameters

POST requests with a "multipart/form-data" -type content have modifiable parameters and use a specific interface.

Each part is described by a name attribute and a value. It also features an optional specific content type, charset and transfer encoding. Refer to RFC1867 for more details. Each field may be replaced by a variable. The value may be a string or a file input.

Fields specific to the file part

The filename field describes the file name within the part. The part's content data is described by the source file field. The file may be identified using a set path or one related to the project. The files are automatically copied to all the Load Generators when the test is started.

Advanced parameters

The advanced parameters pane includes:

  • Request headers. HTTP request headers. Existing headers may be edited or deleted or new headers added. A variable may be used as a header value.

  • Advanced settings. 

    • Request parameters. Specifies whether or not a sent request should include an equals character after the parameter name if its value is empty (e.g.: a request may be sent as /page.jsp?myparam= rather than /page.jsp?myparam).

    • Advanced definition. Enables the user to configure the referrer of the current request. The referrer is the request containing the link to the current request. By default, the referrer is established during the recording phase. You may alter the referrer by clicking on the Change referrer button. When altering the referrer, make sure that the new referrer's request call precedes the current request's call in the Virtual User definition.

      The referrer is used when a request is:

      • a link or form extractor

        In this case, NeoLoad fetches the link or form definition in the server response to the referrer.

      • a redirect

        In this case, NeoLoad fetches the value of the Location header in the server response to the referrer.

    • Form charset. Denotes the charset used to encode the form parameters (UTF-8, ISO-8859-1, ...). By default, NeoLoad uses an algorithm similar to the one used by web browsers to determine which charset to use: NeoLoad uses the charset of the HTML page containing the form. If the charset is not found, "iso-8859-1" is used.

      Do not confuse this charset, used to convert characters into bytes, with plain URL Character Encoding, which converts, for example, the space character into %20. Specifically, URL Character Encoding differs according to the charset used.

  • Variable extractors. Extracts a string from the server response to this request and assigns the string to a variable. See the section called “The variable extractor”

  • Request content. The request content that was recorded when recording the scenario.

  • Response content. The response content that was returned by the server when recording the scenario.

The variable extractor

The variable extractor extracts a string from the server's response to the request and assigns the string to a variable. The variable extractor features two operating modes, simple and advanced. In simple mode, the user defines the string to be extracted; in advanced mode, the user can define more complex extractions using regular expressions.

  • Definition (Simple mode). Used to define the extractor.

    • Variable name. The name of the variable automatically created to contain the value extracted.

    • Starting with. The phrase in the server response appearing immediately before the value to be extracted.

    • Followed by. The definition of the string's main body. The extracted string is the concatenation of all the parts selected for extraction.

    • Ending with. The phrase in the server response appearing immediately after the value to be extracted.

    • Occurrence to extract in the page. If the definition is matched more than once, select the occurrence to be used. The default value is 1. To use a random occurrence, enter 0. To use all occurrences (useful with loops) use a negative value such as -1.

      When the occurrence number is negative, all the matched occurrences are processed. The following variables are automatically created:

      • <VariableName>_matchNr - the number of occurrences found; can be 0.

      • <VariableName>_n, where n = 1,2,3 etc - the strings as generated by the value template.

      • <VariableName>_n_gm, where m=0,1,2 - the groups matching n

      • <VariableName> - always attached to the default value

    Note: When switching to advanced mode, the definition is automatically converted from simple to advanced.

  • Definition (Advanced mode). Extraction is carried out on the server response using a regular expression.

    • Variable name. The name of the variable automatically created to contain the value extracted.

    • Extract the value from. Extract the value from either the body of the server response, the headers of the server response or the content of a NeoLoad variable. Extracting a variable from the content of another variable, allows to extract a content with several steps. First extract a part of the response based on a regular expression, then use another regular expression to extract a part of it.

      Note

      The extractors are ordered and executed in the definition order. You can reorder the extractors using the arrows buttons.

    • Regular expression to match. The regular expression used to extract the value. Within the expression, the parts to be extracted must be enclosed in brackets (valid: value="(.+?)", invalid: value=".+?"). Please refer to the Regular Expressions Guide for help on regular expressions.

    • Occurrence to extract in the page. If the definition is matched more than once, select the occurrence to be used. The default value is 1. To use a random occurrence, enter 0. To use all occurrences (useful with loops) use a negative value such as -1.

      When the occurrence number is negative, all the matched occurrences are processed. The following variables are automatically created:

      • <VariableName>_matchNr - the number of occurrences found; can be 0.

      • <VariableName>_n, where n = 1,2,3 etc - the strings as generated by the value template.

      • <VariableName>_n_gm, where m=0,1,2 - the groups matching n

      • <VariableName> - always attached to the default value

    • Value template. The template used to construct the value. This is an arbitrary string containing special elements that refer to groups within the regular expression (a group is a dynamic portion of the regular expression set within brackets): $0$ refers to the entire text matching the expression, $1$ refers to group 1, $2$ refers to group 2, and so on. Using an illegal group will return an error of the type <NL-Illegal-groupIndex> during the test. This typically arises when no brackets are specified in the regular expression to be matched.

    Note: When switching to simple mode, the last simple definition is used, since advanced-simple conversion is impossible.

    Examples

    • Extracting from the server response body. Given the following content: Your order number Mr Smith is:12345; and that the string to be extracted is '12345', to be used in a subsequent request.

      The variable extractor is defined thus:

      Variable name: 'MyVariable'
      Extract from: 'Message body'
      Regular expression to be matched: 'Your order number(.+)? is:([0-9]+);'
      Occurrence within the page: '1'
      Value template: '$2$' as it's the order number that must be extracted and not the name of the person. Use $1$ to obtain the name. ($0$ would return the complete matched text: 'Your order number Mr Smith is:12345;')
      Default value: '-1' for example.
      

    • Extracting from the server response header: 

      Extract from: 'Header'
      Regular expression to be matched: 'MyHeader: (.*)'
      Occurrence within page: '1'
      Value template:'$1$'
      

  • Test. This tab allows you to test the variable extractor. Enter the text corresponding to the server response in the text box. The "value extracted from page" field value contains the value extracted from the page.

  • Error. This tab allows the user to define the default value to be used when the definition is not matched in the server response. By default, an assertion fails when the definition is not matched, allowing the request to be treated as an error in the test results.

Validation

Allows the user to add assertions to the server responses. The content returned by the server may be treated as an error using the following criteria: delay, page size or page content.

Delay

Specifies the maximum delay tolerated in ms.

Page size

Defines the minimum and maximum sizes, or length, of the server response's body. HTTP header lengths are disregarded. The default length is the length of the server response's content at the time of recording. "Greater than" denotes greater than or equal to; "Smaller than" denotes smaller than or equal to.

Page content

Checks whether or not the server response contains a certain content. The server response is composed of the HTTP response's headers and content. The server response is considered valid if all the content conditions are satisfied.

The conditions available are:

  • contains: checks if the body of the server response contains the specified text. (Example: "<span class="welcome">Welcome</span>")

  • contains regular expression: checks if the body of the server response contains the specified regular expression. (Example: "<span class="welcome">Welcome \w+ \w+ </span>")

    Note that the content assertion may contain variables.

    Please refer to the Regular Expressions Guide for help on regular expressions.

Flag specific requests

To help find specific requests quickly and easily, NeoLoad can add a flag to the action's icon in the tree.

These may be requests that include a response validation, a variable extractor, or a link or form extractor. You may also flag all form POST requests, and all requests using parameters or containing a specific text.

When searching custom text in the request definition, NeoLoad looks in the path, the parameters, the headers, the name of the Variable Extractors, and the content validations.

Procedure 7.1. To configure request flagging policy

  1. Click on the "Repository" node in the tree.

  2. The pane to the right of the tree displays a "flag" box.

  3. Select the type of requests to be flagged.

Link and form extractors

Link extractors and form extractors search for and extract a link or form from a preceding HTML request, for easy handling of server-generated dynamic parameters.

Please refer to the Regular Expressions Guide for further details on regular expressions .

Link extractor

In this mode, the HTTP request definition is interpreted as a regular expression, which is used to find the link within the page. Before playing the request, NeoLoad replaces the dynamic values in the definition with the values extracted from the corresponding link in the previous page (referrer). Perl-type regular expressions are used.

The HTTP request parameters interpreted as regular expressions are: path, URL parameters (name and value) and server. If the server name is dynamic, manually create a server in NeoLoad whose hostname is the regular expression to be matched in the page.

If several links match the definition, NeoLoad will select one at random.

Note:

  • The link parser searches for links whose form resembles <a href="http://mydomain/mypath"></a> and takes into account the base URL (<a base="mybaseUrl"></a>).

  • The following special characters in the link extractor's definition must be escaped using the '\' character: [ ] ^ \ { } ( ) + ? . *

Once the link is found, the parameter values can be placed in a NeoLoad variable. To do this, simply enter the name of the variable in the Extract to variable column in the parameters table (this column is only displayed in link extractor mode). Note that only the variable name should be used, not the syntax: use "varname" and not "${varname}".

Example

Let's consider the following example: the web application generates a searchID, and this number is transferred from page to page as a request parameter. The recorded HTTP request looks like:

If you launch the test, NeoLoad will play the request with the recorded searchID. Therefore, the searchID must be replaced by the appropriate value. The previous page contains the following link: <a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=2">Page2</a>

Now let's convert this manual request into a link extractor:

In this example, the searchID value has been set as ".*", which means the searchID may contain any value.

The "page" parameter may also be set as ".*" or"\d" (for a single digit). So, if you have several different links such as:

<a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=2">page2</a>
<a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=3">page3</a>
<a href="http://myHost/search.php?searchID=<mygoodsearchid>&page=4">page4</a>
they will all match the definition. In this case, NeoLoad selects one of the links at random.

Form extractor

The Form Extractor -type HTTP request is used to retrieve a form in the previous HTML page and play it back.

The HTTP request parameters interpreted as regular expressions are: path, form parameters (name and value) and server. If the server name is dynamic, manually create a server in NeoLoad whose hostname is the regular expression to be matched in the page.

If several forms match the definition, NeoLoad will select one at random.

Note: The following special characters in the form extractor's definition must be escaped using the '\' character: [] ^ \ { } ( ) + ? . *

Once the form is found, the parameter values can be placed in a NeoLoad variable. To do this, simply enter the name of the variable in the Extract to variable column in the parameters table (this column is only displayed in form extractor mode). Note that only the variable name should be used, not the syntax: use "varname" and not "${varname}".

Example

Let's consider an application containing the following search form:

<form name="searchform" method="POST" action="search.php">
	<input type="text" name="name" size="30" value="">
	<input type="text" name="city" size="30" value="NY">
	<select name="country" id="country">
		<option value="US">US</option>
		<option value="Canada">Canada</option>
		<option value="China">China</option>
		<option value="France">France</option>
		<option value="UK">UK</option>
	</select>
	<input type="radio" name="fastsearch" value="YES">
	<input type="radio" name="fastsearch" value="NO">
	<input type="hidden" name="computedValue" value="4235">
	<input type="submit" name="Submit" value="Submit">
</form>

In this example, the "computedValue" hidden field is server-generated and differs with each request call.

The recorded HTTP request looks like this:

If you launch the test, NeoLoad will play the request using the recorded "computedValue" parameter value. This needs to be replaced by the appropriate value, so let's convert this manual request into a form extractor:

Using ".*" as the value for computedValue will extract the value generated by the server.

Furthermore, if ".*" is used as the country field value, a random value from the option list will be returned. In the same way, the "fastsearch" field will randomly return "YES" or "NO" upon running the test.

As can be seen, the form extractor not only extracts server-generated dynamic values, but also allows random choices to be made in the form's option-based elements.

SOAP requests

NeoLoad's optional SOAP module can be used to load test Web services using the SOAP protocol.

There are two ways of using this NeoLoad module:

  • Declare, then enter, the SOAP request's call parameters (manually or using a WSDL description file)

  • Record a SOAP request played by an existing client application, then modify its parameters.

Creating a SOAP request

This section describes how to create a SOAP request from the ground up. To record a request using an existing client, see the next section

Procedure 7.2. Creating a SOAP request in the NeoLoad Repository

  1. In the Design section, click on the Repository tab.

  2. Right-click on the Repository node, then select Add/New SOAP request. You can also create a SOAP request by clicking on the "New SOAP request" button in the Repository node's pane

  3. Follow the wizard to select the parameter editing mode:

    1. Create a SOAP request using a WSDL description file:

      1. Enter the URL containing the WSDL. Use the file browse button to select a file on the hard drive, or enter a web server URL, for example: http://myserver/app/myservice?WSDL.

      2. In the drop-down list, select the method (or operation) to be tested.

      3. Choose a pertinent name for the SOAP request.

      4. Enter the URL of the web service ("Endpoint"). The URL defined in the WSDL is displayed by default.

    2. Create a SOAP request by manually editing an XML request.

      1. Choose a pertinent name for the SOAP request.

      2. Enter the URL of the web service ("Endpoint").

Recording a SOAP request

This section describes how to record the interaction between an existing SOAP client and the web services server.

Procedure 7.3. Recording a SOAP request.

  1. Alter the SOAP client's settings so that it uses NeoLoad as a proxy:

    • hostname: name or IP address of the machine currently running the NeoLoad Controller.

    • port: the NeoLoad HTTP recorder's port, 8090 by default. This setting can be changed in the NeoLoad preferences.

    Please refer to the documentation accompanying your web services framework for instructions on how to change the proxy settings. As a guide:

    1. Axis: Modify the http.proxyHost and http.proxyPort system properties.

      For example, place the following lines in your code:

      System.setProperty("http.proxyHost", "localhost");
      System.setProperty("http.proxyPort", "8090");

      or modify the command line as follows:

      java -Dhttp.proxyHost=localhost -Dhttp.proxyPort=8090 ...

    2. .Net. The configuration file may be modified as follows:

      <configuration>
         <system.net>
            <defaultProxy>
               <proxy
                  usesystemdefault = "false"
                  proxyaddress="http://localhost:8090"
                  bypassonlocal="true"
               />
            </defaultProxy>
         </system.net>
      </configuration>

      For further information, please see http://support.microsoft.com/default.aspx?scid=kb;[LN];318140

  2. Run NeoLoad

  3. Start a recording (See the section called “Recording a Test Scenario”). Since the recording does not require a browser, we recommend clearing the "Launch browser" option .

  4. Launch your SOAP client application. Since the application has been configured to use the NeoLoad recorder as a proxy, NeoLoad records the request.

  5. Stop the recording.

Editing a SOAP request

Description of the SOAP request editing pane:

  • Name. Name of the request

  • Description. Optional comments or notes.

  • URL. Web service's URL, cannot be edited.

  • Server. Web service server.

  • Path. Path to the web service, depending on the selected server.

  • WSDL. URL for the WSDL. For a file on the hard drive, the URL will take the form file:/C:/... Use the file browse button to select the file. For an online file, use the standard http://myserver/myapp/myservice?WSDL.

    The Reload button allows the WSDL to be reloaded and the request parameters reconfigured. After confirmation, the request's original parameters are deleted.

  • Edit mode. 

  • Contents. Edit the WSDL parameters or XML content, depending on the mode selected.

  • Test. Provides a quick way to test the request. Clicking on the "Validate" generates a temporary Virtual User containing the edited request, then launches the validation of the Virtual User.

Note

The "Advanced..." and "Validation..." buttons provide the same features as for a standard HTTP request, allowing HTTP headers to be edited, variable extractors to be created or contents to be validated.

Editing the parameters extracted from the WSDL

When NeoLoad loads the WSDL file, it generates a default tree structure for the parameters and SOAP headers. Optional parameters may be deleted and other parameters added if the WSDL description permits.

Parameters

The parameters tab allows the user to edit, delete or add parameters.

Parameter editing is limited by the restrictions imposed by the WSDL description.

There are two types of parameters:

  • leaf elements, such as a text or numeric value which can be edited.

    This value may be an actual value or a variable. Encoding allows special characters such as '>' and '<' to be encoded. If the value is a variable, the "encode value" option may be cleared if the variable's value is already encoded

    The value type displayed is the 'type' in the WSDL sense of the term, for example: {http://www.w3.org/2001/XMLSchema}string. The user must ensure that the value type syntax is adhered to.

  • containers that contain other elements:

    • sequence elements contain other elements in a specific order and follow the cardinality described in the WSDL. For example, the S sequence must contain between zero and three A elements and at least one B element, in that order;

    • All elements contain other elements once, and only once, in an unspecified order;

    • Choice elements contain a single child element among the various child elements allowed.

    The container element's restrictions are displayed for information purposes in the "Child elements" section at the bottom of the container's edit pane.

To add an element to a container , either click on the '+' button, or right-click on the element, then select "Add". In either case, the list of elements to be added is limited by the child elements allowed by the WSDL. The element is automatically inserted in the appropriate place, among the other child elements where an order constraint exists.

To delete an element from a container , either click on the '-' button, or right-click, then select "Delete".

To move an element within a container , use the appropriate direction button, or right-click, then select "Move up" or "Move down".

Note

If a restriction imposed on the container by the WSDL is not complied with, an error icon is added to the container's icon. An error message also appears in the "Child elements" section of the appropriate container's edit panel.

The attributes section allows the user to edit the parameter's attributes. The permitted attributes are listed in the table. The first column, "Use", allows the attribute to be added to the parameter. Entering a value in the value column automatically adds the attribute to the parameter. It is not possible to add attributes not intended by the WSDL.

Headers

This tab is used to configure the SOAP headers declared in the WSDL.

Its use is similar to that of the Parameters tab.

The specific SOAP Headers section allows the user to define the SOAP protocol's "Actor" attribute.

Advanced

This tab is used to define the following two parameters:

  • message style. The styles supported are: RPC/Encoded, RPC/literal, Document/literal and Wrapped Document/literal. The style selected is the one declared in the WSDL. Normally, this parameter should not be changed, as the web service expects to be contacted using the predetermined style (as set in the WSDL).

  • encapsulation format for the binary attachments: MIME or DIME. As with the message style, this parameter is extracted from the WSDL and should not normally be changed.

XML preview

This allows the user to preview the XML body of the request exactly as it will be generated. The preview cannot be edited and only includes the XML body of the message (not the binary attachments, where present).

Carry out a request validation to obtain a preview of the complete HTTP request.

Editing the XML content

If the WSDL file is not defined, or if the WSDL parameters cannot be edited, the XML body of the message may be defined manually.

To do this, edit either the XML text or the XML tree.

XML text

This tab allows the user to edit the XML text.

Tip

Right click or use 'Ctrl-F' to search.

XML tree

This tab is used to edit the nodes of the XML tree using the open tree view. The variable picker in this view makes it especially useful when using variables.

If a node value contains a variable, and this variable is already encoded, the option not to encode it XML-wise is available. In this case, NeoLoad adds the attribute NeoLoad-encode="false" to the corresponding node, visible in the XML text tab view. This additional attribute will be deleted during the XML encoding phase of the test and will not be sent to the server.

Preview

This tab provides a read-only preview of the body of the request to be sent.

The variables are interpreted and the carriage returns deleted (see tip below).

Tip

The request has the carriage returns removed to make it more compact for the test; right click and select "Indent XML" to obtain a more readable presentation.

Configuring the "SOAPAction" HTTP header

SOAP 1.1requires the presence of the SOAPAction HTTP request header. This header is automatically added, with the appropriate value, when the WSDL is loaded, or recorded if the request is recorded.

Edit the request's HTTP headers to modify this value. To do this, click on the "Advanced..." button and select the "Request header" tab .

Testing a SOAP request

Click on the Validate button in the Test section to test the current SOAP request.

NeoLoad generates a temporary Virtual User containing the single request, then displays the validation window for that Virtual User. Click on the Start validation button.

The Details section provides details of the request sent and of the server's response, and access to the assertion messages.

Tip

Right click and select "Indent XML" in the text field to obtain a more easily-readable detail report for the sent request. Right click and select "Find..." or use Ctrl-F to search.