Multiple accounts using the Post-recording wizard and a CSV file

This section of the tutorial describes the steps you will need to take to use multiple accounts based on a CSV file for your load scenario. The steps described here are those you will take after having gone through the Post-recording Wizard.

The Wizard does most of the job so these steps are simple and few. This is all the more true in comparison to the "manual" procedure which entails declaring a variable and linking it to login elements in the configuration. To fully understand how using multiple accounts can be achieved without using the Post-recording Wizard, see Create and link a CSV variable to login information.

The steps you need to take boil down to correctly defining the contents of a CSV file. This section will however precisely show you the login related elements that the wizard creates and configures. It will also detail how these elements relate to each other. For more information about the Post-recording Wizard, see Post-recording wizard.

Each time you record a set of interactions with your application, the Post-recording Wizard is launched at the end of the recording. This wizard analyzes and pre-configures login elements for you. Depending on the type of authentication your server is using, the wizard will create and configure different elements:

  1. For Basic authentication or NTLM authentication: the wizard automatically detects these authentication policies and configures Authorization elements related to the server you are connecting to.

  2. For Form based authentication: the wizard automatically detects the HTTP request that authenticates to your server and configures elements related to that particular request.

The first part of this section goes through the steps of the Post-recording wizard and describes the elements related to basic and NTLM authentication. In most situations the wizard does the whole job on its own and you just have to confirm what the wizard has detected and decided. The second part of this section details the configuration elements the wizard has created and the information you will need to provide.

The first two steps of the Post-recording wizard are left aside to focus on step 3. This is where basic and NTLM authentication information is used and can be configured through the wizard. The example is based on basic authentication but the NTLM authentication procedure is identical.

To set multiple accounts with basic or NTLM authentication, follow these steps:

  1. Post-recording wizard step 3 is the basic authentication. The wizard automatically detects that basic authentication has been used. You indicate that multiple accounts should be used by checking the Use multiple accounts option.

  2. Define the type of variable to use: The wizard needs to determine the type of variable used to store the multiple accounts. You choose the CSV alternative by checking the Use the accounts from a CSV file option.

  3. Define the variable:

    • To be able to replace the recorded parameters with dynamic values, you need to define the file-type variable that will be used. This step in the wizard allows you to select the variable parameters. Select the CSV file to use by clicking on the picker button. The first few values are displayed to check the file content.

    • Double-click on the column headers to change the names to more meaningful names.

    • The Value change policy selected by the wizard is for "Each Virtual User". This is consistent with the behavior you are looking to create, since you may want a new value to be used each time a Virtual User connects to the application.

  4. Set the Login configuration: In this last step, the wizard prompts you to specify which column to use for the login, which column to use for the password and then recaps the created configuration. Here, it has created an "Accounts" variable that has been assigned to the login and password authentication parameters. The "Accounts" variable has two columns: the first column, ${Accounts.login}, must contain login values; the second, ${Accounts.password}, must contain password values.

During the recording phase NeoLoad automatically detects basic or NTLM Authentication and correctly configures the Authorization elements of the server. As detailed previously, the Post-recording wizard configures and links Authorization elements to a variable.

For example, your server may use basic authentication. The wizard has detected this and has configured the Authorization panel accordingly by adding a line with type, Realm/Domain, login and password information. The login and password are both linked to values of a variable called "Accounts". More precisely, the login is linked to the ${Accounts.login} expression and the password to the ${Accounts.password} expression.

The first part of this section goes through the steps of the Post-recording wizard and describes the elements related to form-based authentication. In most situations the wizard does the whole job on its own and you just have to confirm what the wizard has detected and decided. The second part of this section details the configuration elements the wizard has created and the information you will need to provide.

The first two steps of the Post-recording wizard are put aside to concentrate on step 3. This is where form-based authentication information is used and can be configured through the wizard.

To set multiple accounts with form-based authentication, follow these steps:

  1. The Post-recording Wizard step 3 is the form-based authentication.

  2. For example, you check the accountBean form as being used for authentication. This basically tells the wizard to look for HTTP authentication related parameters in the associated HTTP request.

  3. Define the login field: The wizard automatically detects and identifies the username HTTP parameter as the login field for the form-based authentication.

  4. Define the password field: The wizard automatically detects and identifies the password HTTP parameter as the password field for the form-based authentication.

  5. Define multiple accounts: At this stage the wizard needs to determine whether you want to use multiple accounts to login. You select the Use multiple accounts option accordingly.

  6. Select a CSV file based variable: The wizard now wants to determine if account information (login and password) should be read from a CSV file, or be entered explicitly in the project configuration. You choose the Use the accounts from a CSV file option.

  7. Define the CSV file-type variable:

    • To be able to replace the recorded parameters with dynamic values, you need to define the file-type variable that will be used. This step in the wizard allows you to select the variable parameters. Select the CSV file to use by clicking on the picker button. The first few values are displayed to check the file content.

    • Double-click on the column headers to change the names to more meaningful names: Accounts.login and Accounts.password.

    • The Value change policy selected by the wizard is for "Each Virtual User". This is consistent with the behavior you are looking to create, since you may want a new value to be used each time a Virtual User connects to the application.

  8. The Post-recording wizard Step 4 is the login configuration. In this last step, the wizard prompts you to specify which column to use for the login, which column to use for the password and then recaps the created configuration. Here, it has created an "Accounts" variable that has been assigned to the login and password HTTP parameters. The "Accounts" variable has two columns: the first column, ${Accounts.login}, must contain login values; the second, ${Accounts.password}, must contain password values.

The Post-recording wizard has also configured the HTTP request doing the authentication.

The username parameter is associated with the ${Accounts.login} expression and the password parameter associated with the ${Accounts.password} expression. The "Accounts" variable is automatically created and configured by the Post-recording wizard. The ${Accounts.login} value will be read from a CSV file and is expected to contain a login value. The ${Accounts.password} value will be read from the same CSV file and is expected to contain a password value.