User Configuration Form

The Session Users Management screen allows you to create custom users that are assigned to a Session as it is executed. Users are evenly spread across the full all of the executing threads of sessions to isolate each Session Http Execution Context.

Users also allow you override behavior for that User/Session either globally or for a specific request Url.

User Configuration is Optional

Users are optional - WebSurge automatically creates default users when you don't create any custom users. In tests where user state is not needed, you don't need to worry about custom users. Custom users are needed only if you need to override specific request functionality for specific users - most commonly for logins for multiple users or otherwise differentiating request behavior or data.

Session Users Management Form

You can access this form from the Session Configuration sidebar via the button next to Use Custom Users:

Note that you can disable using of custom users via the checkbox. When unchecked, custom users - even if defined - are not used for overriding requests.

The check box determines whether any users you've created are applied when requests are run. Users are applied for load tests and individual requests.

Here's what the Session User Management Form looks like:

The user form allows you to:

Add a custom User
Add global session state (Cookie and Authorization header overrides)
Add one or more Urls per user
Add custom Http Headers added the request
Create custom POST/PUT data to override request

Functionality

The form contains both global and Request specific overrides. The global settings are at the top, and the request specific ones are specified in the list of Urls and detail data for each on the bottom.

User Identifier

This is a unique username that you give the user. WebSurge creates a unique name for you, but you can change it as needed. If you map actual application users matching the user name might make it easier to identify.

Authorization

Allows you to specify a Cookie value that is appended to the request. This is an easy way to assign a previously logged in session via a cookie. Note that you have to capture this cookie and make sure it's not expired.

Authorization Header

Allows you to specify a specific Authorization header for this user. Similar to the cookie, you can capture a pre-defined auth bearer token and assign a unique one for each user.

There are other ways to capture auth tokens using WebSurge specific capture headers that can extract and assign Authorization tokens from login requests and into requests that require authorization, but they require a full authorization flow. Using the Authorization header is a simplified way of doing this, but you have to ensure that tokens are still valid for each user.

URL Form Data

The above settings are global settings that apply to all requests for the given user. The following section describes Url specific settings that override specific requests in your session. Note that you can create multiple Urls to override, but each has to match an exact Url in your Session request list.

Url

You can specify one or more Urls to override. Urls are listed in the list on the left with the override data on the right. The Url you specify has to match a Url in the Session request list.

Note the URL you enter has to match a Url in the Session Request List exactly, or else the data is not applied.

Request Headers

For each Url you can optionally add or override existing headers in the Session request that you specify. This should be rare, but is here for completeness.

Http Verb

You can specify the HTTP Verb for each Url specified. In most cases this will be POST or PUT since you're overriding form data most likely. This value has to be set as it overrides the request.

Form Data

The most common use case for users is to override form data for specific session Urls. Most commonly this will be a login Url where you send different credentials for each user. You can specify form data in 3 ways:

Raw Data for things like JSON, XML or Binary data (as base64)
HTML style Form Data in key/value format (application/x-www-form-urlencoded)
Multi-part Form Data in key/value + content type and filename (multipart/form)

Depending on the content type you choose the form's input fields change somewhat. Form variables get a Key field, while raw data does not. Multi-part forms get options for variable content type and file name.

How many Users do you need?

How many unique users you create depends on your testing scenarios and how many unique sessions you want to run.

For this feature to make sense you'd need at least two users as a single user provides no noticeable benefit over simply putting override values directly into the specific request data.

Other than that there is no specific requirements for any specific number of users.

Users are spread out evenly over the number of Threads that a test uses. It's not necessary to match users and threads, although you can do that if you like. If you have more threads than users, WebSurge will duplicate the number of user you have configured over the number of threads. Ideally the number of threads should be a multiple of the number of users, but it's not a requirement - you just end up with a few users that get one less session assigned. So if you have 20 threads and 4 users defined, the 4 users are assigned to 5 sessions each.

JSON Data Example

The following sends custom custom user login data in the form of a JSON request for an API request. You may end up creating 3 different users each with identical configuration, but different JSON data for each different user for example.

HTTP Form Data Example

The following example shows a similar setup, but rather than using JSON data, it uses Html Form data as would be used in a typical Html based Web interface.

Notice that the you can configure the content type (application/x-www-form-urlencded in this case) which determines how form variables are entered. For form and multi-part variables you get key and value fields, while for everything else you just get a single raw data field as shown in the first example.

Individual Request Testing and Custom Users

If you're testing individual requests via Run or Run All (once), WebSurge will assign the first user if users are defined and enabled. This can result in running a request that produces results different from what you see on the original request in the request viewer which can be counterproductive.

If that's not the behavior you want you can temporarily disable Custom Users for all requests using the Use Custom Users checkbox on the Session Configuration Sidebar.

This lets you test with your original data without overridden data from custom users. Just remember to re-enable if you run load tests.