Editing Virtual User Profiles

Click on any profile in the Navigation Pane and its properties will be displayed in the right pane. Here you can view and modify profile properties.

Name
Here you can change the name of user profile.

Filename
Here you can specify another file where the profile will be saved to.

General options

Authentication
WAPT Pro supports all security features related to basic authentication and Integrated Windows authentication (NTLM). Click the Credentials/Certificates button and provide the list of usernames/passwords.

WAPT Pro allows simultaneous authorization on different domains for any user. You can specify a group of logins, for example, 2 usernames, 2 passwords and 2 paths for the same user. Usernames, passwords and paths should be separated by a semicolon delimiter (;). Usernames should be entered with their domain names, for example: domain1\user1;domain2\user1 and so on. The entered logins will be used one by one in each new session.

Add: Adds a new string where you can specify login(s), password(s) and path(s) for a new virtual user.
Remove: Removes selected string from the list.

You can double-click any cell to edit user credentials. If you want to use the entered login not for the whole domain, but only for some part of it, use the Path column: enter a path where this login will be applied.

Import..: Using this button, you can load the list of usernames/passwords from a specified .csv or .txt file. Each string of that file should consist of username and password separated by some delimiter. You can use the following delimiters:

TAB
SPACE
;
,

Select a file and specify its encoding and delimiter between records in the displayed dialog:

In the preview box you will see file content. Click the Import button to import the data.

Different values for different users/sessions: Here you can choose a desired mode: users or sessions.

If you select "users", then the first pair of values (user-password) will be taken for the first virtual user, the second pair of values - for the second virtual user and so on.

If you select "sessions", then the first pair of values (user-password) will be taken in the first session for all virtual users, the second pair of values - in the second session for all virtual users and so on.

Besides, WAPT Pro supports form-based authentication via request parameters, for example, you include a username and password in the request. You can also test pages that require SSL connections. URL address of such pages will start with https://.

In case of NTLM and Kerberos authentication WAPT Pro Recorder adds a special header Proxy-Support: Session-Based-Authentication to the server response. You can see it on the Response Header tab of response processing:



This is done for correct recording and authentication.

Client Certificate

Some servers require client certificates to check your identity. The default certificate for such authorization that will be used for all users of all profiles is specified in program settings. However, you can use different certificates for different profiles/users - they should be specified in the properties of each profile.

Use client certificate: Check this option to use the SSL client-side certificates. The specified certificates will be used only for the current profile and only for the playback of test scenario (Recorder uses certificates specified in program settings).

Certificate file: Here you can specify a certificate file necessary to access the server being tested.

Private key is contained in a separate file: Private key which is necessary to access the certificate file can be stored either in a separate file, or in the same file with the certificate. You can check this option and specify a file with the private key in the Private key file field.

Password: Enter the password to get access to the private key.

These files can be stored either in a shared network folder (e.g.: \\Server\SharedFolder\Folder\File), or locally on the computer running load agent or WAPT Pro Workplace component. Note that:

If the option Read files directly from load agents is checked, then local paths are taken from the agent's computer.
If this option is not checked, then local paths are taken from the computer running WAPT Pro Workplace component.

Read files directly from load agents: This option allows reading certificate files directly from load agents. You can put all certificates to some shared folder and all load agents will read them from one place. Besides, you can use variables in the names of files, thus generating dynamic filenames (with the help of $Var(variable-name) function).

For example, you can use different certificates for different users. This can be done with the help of WAPT Pro internal variable User_number. Define the certificate file as \\Server\SharedFolder\Folder\certificate-$Var(User_number).cer and private key file as \\Server\SharedFolder\Folder\key-$Var(User_number).pvk:



As a result, the agent will take the following files from a shared network folder:

certificate-0.cer and key-0.pvk for the first virtual user,
certificate-1.cer and key-1.pvk for the second virtual user,
certificate-2.cer and key-2.pvk for the third virtual user and so on.

Note that if the option Read files directly from load agents is not checked, you cannot use variables in the names of files. In this case you can define only one certificate for the whole profile.

Use cookies
This option turns on/off the usage of cookies (both session and persistent). In particular, you can use it for emulation of browsers with the disabled cookies.

Some people use security options that disable cookies in their browsers. As a result, web applications have to use different methods to pass session variables to the server. To include such sessions in your test, you can disable cookies support in WAPT Pro for the corresponding profiles.

Cookies are small portions of text left in browser on user's computer by web servers. They are recorded to special files and in future could be transmitted back to web servers. There are two different types of cookies: session cookies and persistent cookies.

Session cookies are temporary and are erased when you close your browser at the end of browsing session. The next time you visit that particular site, it will not recognize you and will treat you as a completely new visitor, because there is nothing in your browser that tells the site that you have visited it before. Web sites typically use session cookies to ensure that you are recognized when you move from page to page within one session and that any information you have entered is remembered. For example, if an e-commerce site did not use session cookies then items placed in a shopping basket would disappear by the time you reach the checkout.

Persistent cookies remain on your hard drive until you erase them or they expire. The time during which a cookie remains on your browser depends on how long it is programmed to remain by the visited web site. A persistent cookie enables a web site to remember you on the next visits. For example, a web site may offer its contents in different languages. On your first visit, you may choose to display the content in French and the site may record that preference in a persistent cookie set on your browser. When you visit that site the next time, it will use the cookie and display the content in French.

WAPT Pro supports both session and persistent cookies. Besides, the program recognizes cookies having the "secure" attribute. They are used for secure web pages (starting with https://).

Use persistent cookies
This option turns on/off the usage of persistent cookies. It is available in case the option "Use cookies" is turned on.

You can provide different persistent cookies for different users. Click the Cookies... button to specify the list of cookies.

Add: Adds a new string to the list of cookies where you should specify cookie name and value: <name>=<value>. You can enter only cookie name (without a value) as well. It is possible to enter several cookies separated by semicolons for the same user. The count of virtual users begins from 1.
Remove: Removes a selected string containing virtual user's number and cookies from the list.
Import..: Imports cookies from a specified .csv or .txt file. In the displayed dialog, you should select a file. If you import a text file, each string of that file should consist of virtual user's number (starts from 1) and cookie separated by tabulator sign. You can enter several cookies for the same user separated by semicolons, for example:

1    SID=dghgf4RFjkh; PREF=k8uiu89jk;
2    SID=jhuh76ghRTYH7; PREF=jhni8;
3    SID=68hu78j90; PREF=nk8jhj;
4    asd;

Use HTTP redirect location as is
If you check this option, then HTTP redirect location will be taken in the form as it comes from the server. The program takes the string from redirect and uses it for sending a request. If you uncheck this option, then before sending a request the string will be first decoded, and then - encoded.

Emulate browser cache
WAPT Pro supports caching of requests. This option turns on the browser cache emulation. Behavior of WAPT Pro is different for different headers of server response.

Server response includes an "Expires" header
A web server uses the "Expires" header in the HTTP response to tell the client how long a component can be cached. For example:
Expires: Thu, 16 Aug 2012 20:00:00 GMT

If WAPT Pro recognizes that a page has expired, it is requested from the server. Otherwise, if the page is not expired, it is taken from cache.

Server response includes 2 headers: "Last-Modified" and "ETag"
(Last-Modified stores the date of last modification; ETag is a unique identifier)

In this case WAPT Pro sends a request to the server with the following cache-related header fields:
If-Modified-Since 'time' (where 'time' is the Last-Modified value)
If-None-Match 'ETag' (where 'ETag' was received in the previous response)

If the code of server response is 304 - Not Modified (it means that both headers: Last-Modified and ETag are the same), then the content of server response is taken from cache.

If the code of server response is 200, then the new response received from the server is used.

Server response includes "no-cache" directive (Cache-Control: no-cache)
In this case no caching is used.

Server response includes "s-maxage" or "max-age" cache-control directives, for example:
Cache-Control: max-age=3600
In this case the behavior of WAPT Pro is the same as for an "Expires" header.

Note that cache is available only within one user session. For each session of the same user a new cache is created.

Initial variables
You can use variables to calculate parameters and URL paths. Usually variables are defined using functions that parse the actual HTML code of response at run-time. But sometimes you may need to use variables just in the first request. For this purpose you can define the list of initial variables - click the Initial variables... button.

Add..: Opens the Add Variable dialog where you can create a new variable and select a function for its calculation.

Remove: Removes selected variable from the list.

Edit..: Opens the Edit Variable dialog where you can edit variable name and the function for its calculation.

Here you can read the description of WAPT Pro functions.

Besides, you can copy any variable from the list of variables of any request to the list of initial variables:

1. Select the necessary variable in the list of variables on the Response processing tab of any request.
2. Right-click it and select Copy on the pop-up menu.
3. Return to the dialog with the list of initial variables.
4. Select Paste on the right-click menu.

Default HTTP headers
When WAPT Pro records user profiles, it also records HTTP headers of all requests sent by the browser. When record is finished (after you click the "Stop Rec" button), the program parses all recorded requests and their HTTP headers. Some headers are unique for the certain requests; others are common for all requests. WAPT Pro looks for common headers. If the value of some header is the same for all requests, such HTTP header is removed from the list of request headers and placed to the list of default headers (HTTP headers of user profile). Other headers remain in the list of HTTP headers of individual requests.

There are several exceptions - headers which are not recorded by WAPT Pro Recorder. They are X-Forwarded-For, Host, Referer and Cookies. These headers are not included in the list of request headers. Thus they are not added to the list of default headers. There are special checkboxes and controls for such headers in the program. One more exception is User-agent: it is recorded and added as a separate control in profile properties.

Keep alive server connection: there is the corresponding checkbox in profile properties for this header.
Referer is calculated automatically during the test run and written to request properties.
Host is taken from the "Server" field of request properties.
User-agent and X-Forwarded-For are special controls in profile properties.
Cookies: there is the corresponding checkbox in profile properties and also a button opening a dialog to define cookie values.

Here you can see the list of default HTTP headers which are used for all requests of current user profile. To edit some string in the list, double-click its name or value, modify it and press Enter.
Add: Adds a new string to the list. Specify string name and value.
Remove: Removes selected string from the list.

Besides, you can edit HTTP headers of individual requests in request properties.

User-Agent: You can select a type of browser for your test. Check the "User-Agent" option, click the "Select" button and select a type of browser in the displayed dialog.

Add "X-Forwarded-For" HTTP header: Toggles the use of additional fields in HTTP header for imitating different users working through a proxy server. It is useful to emulate page requests coming from multiple computers.

Use mask: Select this option if you want to specify IP address mask for proxy emulation. You can use the following parameters in the mask:
$S1, $S2, $S3, $S4 - four bytes of session number, from the low one ($S1) to the high ($S4);
$U1 and $U2 - low and high bytes of virtual user's number;
$P - profile number.

All values span from 0 to 255. You can use any of these parameters in any position of the mask. WAPT Pro default proxy mask is 192.168.$U2.$U1. For example, for the first virtual user the directive "X-Forwarded-For: 192.168.0.0" will appear in the HTTP header.

Use the list of IP addresses: Select this option if you want to specify the list of IP addresses. Click the IP Addresses... button. In the displayed dialog, enter desired addresses.

Add: Adds a new string to the list of addresses. Specify there a desired IP address.
Remove: Removes selected address from the list.

Error handling options

Break user session on errors
This option defines how to process errors. If it is checked, then sessions will be aborted in case of an error. (Not the whole test will stop, but the current session. The next session will start up.) If you uncheck this option, sessions will continue regardless of an error. If an error occurs, the next page of the current session will be loaded. If this option is unchecked, then timings of all requests are included in statistics, both of successfully executed requests and executed with errors.

Note that errors of requests for page resources are not considered as errors of the whole session or even of the main request. The session continues in this case.

Ignore HTTP errors
This option allows to ignore HTTP errors, so that if some requests were executed with HTTP errors, they are considered successful and such errors are not included in test statistics. However, you can look at the Response codes table in the Errors report to know which pages have HTTP errors.

Make a pause after session failure from _ to _ ms.
Here you can specify how much time a virtual user will wait before running the next session of current profile in case some session fails.

Reconnect on network timeout
If connection was closed before WAPT Pro sends a request, it results in network timeout. If this option is checked, WAPT Pro tries to reconnect in this situation.

Response Validation Rules
WAPT Pro can make additional validity check of server response. Click the Response Validation Rules... button to define validation rules for requests of current profile.

Response body contains/does not contain the following text: You can turn this option on and enter some text to check. Then WAPT Pro will check whether HTML code of server response contains the text that you specify here, or not. You can enter any part of HTML code, for example: <TITLE>302 Found</TITLE>. You can also use variables. Enter the $ sign and you will see a prompt with the list of available variables. Select a desired variable in the list to insert it into the text.

You can select one of 2 options in the combo-box: either "contains", or "does not contain".

If you select "contains", WAPT Pro will check that HTML code of server response contains the specified text. If the program finds the text, response is considered valid. Otherwise, it is considered invalid.
If you select "does not contain", WAPT Pro will check that HTML code of server response does not contain the specified text. If the text is not found, response is considered valid. Otherwise, it is considered invalid.

In case the response is invalid, you will see the "Response body validation error" for this page request in a special table Validation errors on pages (hits) as a % of all completed pages (hits) of Errors Report, HTML Report and in the log.

Response time is less than _ ms: If you check this option, WAPT Pro will make additional validity check of response time. The program will treat server response valid if response time is less than the value specified here.
If response time exceeds this value, you will see the "Response time validation error" for this page request in a special table Validation errors on pages (hits) as a % of all completed pages (hits) of Errors Report, HTML Report and in the log.

Note that profile validation rules will be applied only to those requests of current profile which have the checked option Apply profile validation rules in request properties. You can uncheck this option for any request if you do not want to apply profile validation rules to it.

Intra-session load volume options

Think time after page load
During the recording process, WAPT Pro records delays between pages. Delays are used in tests to simulate user think time. This adds more reality to your tests.

Disable: The program will not use delays between requests of the current profile.
Specified in page properties: The program will use delay values specified in request properties. You will be able to enter delay values for individual requests.
Random from range: Delay values for requests of this profile will be taken from the specified range at random. Enter the limits of range. If you want to set equal delays for all pages, specify the same limits of range.

Load page resources
When you navigate through a web site in WAPT Pro Recorder, the program records the full content of web pages including all additional (external) resources: images, CSS, JavaScript, WOFF online fonts and others. You can configure each profile either to request the additional resources of web pages during test run or not.

If you check the Load page resources option, then pages of the current profile will be loaded together with their images, CSS, JavaScript, WOFF online fonts and other resources during the test run.

If you uncheck this option, then all pages of the current profile will be loaded without images and other resources, so they will be loaded faster. However, the load on the target server will be inadequate in this case: it will correspond to the situation when all users of this profile switch off the download of images, JavaScript etc.

Number of connections for HTTP/1.x (HTTP/2)
Browsers usually keep several open HTTP connections within the same user session. Additional connections are used to load page resources and send AJAX requests initiated by the open page. This reduces the total page download time and improves the overall web site performance from the user perspective. Here you can select the number of concurrent browser connections (HTTP/1.x and HTTP/2) that will be emulated for a single user session.

These options are important for the parallel execution of profile requests and better emulation of the real work of web browser.

User connection speed
This option adds more reality to your tests. Select the typical user connection speed in the combo-box.

Keep alive server connection
If this option is checked, the directive "Connection: Keep Alive" will be included in the header of each HTTP request.

Concurrency mode
You can run a test in 2 modes depending on selected option for concurrency.

Load page resources concurrently: This option applies concurrency only to page resources. Main page requests will be loaded sequentially, one after another.
Full concurrency for all requests: This option applies the feature of parallel execution to all requests. The order of requests execution is regulated by delays and dependencies between requests.

The properties specified for user profile will be used for all its requests. However, you will be able to change specific user think time, HTTP headers and validation rules for any request in its properties.