Understanding User Sessions

To understand user management in WebSurge is somewhat complex as there are a few interdependent moving pieces to make it work. Setting up and using users is not, as the User Configuration Form makes it relatively easy to create Users with custom state or specific request data to send.

This topic aims to provide more background of how Users, Threads, Sessions and the Http Execution Context relate and affect each other and how the process works behind the scenes.

How it works

When running load tests, WebSurge fires up multiple simultaneous Threads to run a Session of requests on each thread.

Threads - A container of Execution Context for User and Http State

When you specify 20 threads, you're telling WebSurge to run 20 simultaneous Sessions, each running through the Session of its individual requests repeatedly, until the test is done.

This gives you a simulation of 20 simultaneous Web clients using your application.

Users - Application Specific User State

Each Thread of operation also has an associated User that stores some optionally customizable state for requests in a session. It allows you override functionality in the Http Requests you created, or allows you to capture information in one request and provide in subsequent requests.

User Configuration is Optional

By default WebSurge creates an internal user. If you don't need any special user state and you can run your tests off the raw Http data in each of your Session requests for many simultaneous clients, you don't need to worry about users.

If you need to simulate specific users or user behavior in your application you can create custom users. With a user you can create custom behavior for your Http requests that includes:

Global Cookie Replacement
Global Authorization Header Replacement
Per Url Overriding of Form Variables or Data
Per Url Overriding of Http Headers
Capture Form Variables or Json Values
Apply Captured form Variables or Json Values

You can create as little as two users and they are applied across all running Threads of a test. Although you can create a single user, that doesn't make much sense.

One User doesn't make much sense: If you create a single user, you might as well just set up any custom state directly in your Http requests. Although it doesn't make much sense, it is possible to set up a single user.

When you run a load test, the number of Users you've created are spread across the number of Threads that your test runs. So if you've created 5 users and run your test with 20 threads, your 5 users are spread across 4 threads each. This means there are multiple threads that use a copy of the same user. If you have 4 threads and 5 users, the first 4 users are applied - 1 user will not be applied.

Note that I say a copy of the same user. This means that the user is duplicated and has the same starting behavior, but the captured state both User and Http for each of these same user objects are completely separate regardless.

Users are assigned on a thread when Test Sessions start and persist for the duration of the test - on that specific thread.

Users in the Interactive Session

When running individual requests for API or Web testing in the interactive session, a global User is created and assigned to the interactive session. To reset this global state and recreate the user and clear the Http Request Context, click on the icon in the toolbar.

User Configuration Form

User management by necessity is a bit complex as it manages a few moving parts, but the User Configuration form makes the process fairly straight forward. you can create new users easily and set global properties and create multiple urls to override requests for.

Use Custom Users Configuration Option to enable/disable Users

If you create a full set of users you can optionally disable them from being used either for individual request processing or for load tests. Using the Use Customer Users checkbox on the User Configuration or Session Configuration forms you can temporarily disable applying users to your requests.

This can be useful if you're doing interactive request testing, where you actually may not want to override individual requests with data from users. By default - if users exist and the option is enabled - users are always applied even in the interactive session.

The checkbox gives you quick way to temporarily disable custom users without having to remove users.

User JSON Storage Format

User information is stored in the Session Configuration in your .websurge file that holds all your Http Request and Session Configuration data. User information is stored in this JSON file and looks something like this:

----- Start WebSurge Options -----

{
  "ThreadCount": 3,
  
  ... more settings omitted here 
  
  "UseCustomUsers": true,
  "Users": [
    {
      "Id": "user-2",
      "IsActive": true,
      "HttpForms": [
        {
          "Url": "/api/authenticate",
          "Headers": [],
          "FormVariables": [
            {
              "Key": null,
              "Value": "{\r\n  \"username\": \"Bogus-test\",\r\n  \"password\": \"Bogus-test\"\r\n}",
              "BinaryValue": null,
              "MultiPartContentType": null,
              "MultiPartFileName": null
            }
          ],
          "ContentType": "application/json",
          "HttpVerb": "POST"
        }
      ],
      "AuthCookie": null,
      "Authorization": ""
    },
    {
      "Id": "user-1",
      "IsActive": true,
      "HttpForms": [
        {
          "Url": "/api/authenticate",
          "Headers": [
            {
              "Name": "Content-Type",
              "Value": "application/x-www-form-urlencoded"
            },
            {
              "Name": "Accept",
              "Value": "application/json"
            },
            {
              "Name": "Accept-Encoding",
              "Value": "gzip, deflate, br"
            }
          ],
          "FormVariables": [
            {
              "Key": "username",
              "Value": "test",
              "BinaryValue": null,
              "MultiPartContentType": null,
              "MultiPartFileName": null
            },
            {
              "Key": "password",
              "Value": "test",
              "BinaryValue": null,
              "MultiPartContentType": null,
              "MultiPartFileName": null
            },
            {
              "Key": "btnSubmit",
              "Value": "Login",
              "BinaryValue": null,
              "MultiPartContentType": null,
              "MultiPartFileName": null
            }
          ],
          "ContentType": "application/x-www-form-urlencoded",
          "HttpVerb": "POST"
        }
      ],
      "AuthCookie": null,
      "Authorization": null
    },
    {
      "Id": "user-3",
      "IsActive": true,
      "HttpForms": [
        {
          "Url": "/api/authenticate",
          "Headers": [],
          "FormVariables": [
            {
              "Key": "",
              "Value": "{\r\n  \"username\": \"test\",\r\n  \"password\": \"test\"\r\n}",
              "BinaryValue": null,
              "MultiPartContentType": null,
              "MultiPartFileName": null
            }
          ],
          "ContentType": "application/json",
          "HttpVerb": "POST"
        }
      ],
      "AuthCookie": null,
      "Authorization": null
    }
  ]
 
}

----- End WebSurge Options -----

Note: null values don't have to be specified - only provide what you need.

As with all settings in WebSurge, you can make changes to these settings directly in the JSON file or generate this data externally for automation of user creation. If you manually edit, any changes that you make are applied immediately in the WebSurge UI as soon as you save the file to disk.