WebSocket Load Testing

Configuring a WebSocket Request

URL

To open a WebSocket connection, you are required to enter the WebSocket URL of the endpoint or IP address of the WebSocket URL you wish to check (the ws:// and encrypted wss:// protocols are supported). For example, wss://echo.websocket.org/

To turn on a more visually-friendly input mode, click the Detailed switch on the top of the section.

You can convert the URL to a dynamic value or context parameter here. For example, to dynamically change the target URL.

Send Data

If you need to transfer data to the target endpoint, in the Send Data field, specify a message in a string or binary format. Dotcom-Monitor will send the message to the target endpoint using the WebSocket protocol and wait for the response.

Dotcom-Monitor supports Razor expressions in the WebSocket messages. To send a string that contains a Razor expression, enter it in the Send Data field and use the Prepare Script to set the message type to Razor expression. Otherwise, the message will be parsed and sent as text. Use the following snippet in the Prepare Script field to notify the system that the message must be parsed with the Razor engine:

ProcessPostDataByRazor(currentTask);

In addition to the Razor engine, Dotcom-Monitor enables dynamically changing request body data by using data masks. To learn how to use the Razor syntax and data masks in sent data, and configure dynamically changing payload, see How to Dynamically Change Payload in HTTP Request.

Response Validation (Content Validation)

To validate a message string received from the WebSocket, you can assert keywords in the call execution scenario. The system will wait for the response from the target endpoint, and check the received message for the presence of the specified keyword in the string. If the keyword was not detected in the responses from the socket, an error will be generated.

In the Keyword fields, you can specify one word or phrase that you wish to search for in the response message. Use the plain text to specify a keyword:

Prepare Script and Post Script

The fields can contain C# code, which can be used for specific requests and URL data or for validating or publishing custom headers. Please see the Using Prepare Script and Post Script article or contact technical support for more details on usage.

The dynamic scenario of the WebSocket call execution can be specified in the Prepare Script field. The dynamic scenario can include a number of operations with binary or string data.

Binary formatted operations (msg as Base64 encoded):

• ValidateBinary(string msg) – checks if a WebSocket response is equal to specified binary data.
• ValidateBinaryContains(string msg) – checks if a WebSocket response contains specified binary data.
• SendBinary(string msg) – sends a binary message to a WebSocket.

Text formatted operations:

• SendText(string msg) – sends a text string to a WebSocket.
• ValidateText(string msg) – checks if a response from a WebSocket is equal to a specified string.
• ValidateTextContains(string msg) – checks if a WebSocket response contains a specified string.

In cases where any assertion was specified in the Prepare Script field, the system will wait for the specified assertion in the response and proceed with the script execution once the validation is successful. If a message with the specified assertion is not received, and the task completion timeout is reached, we will generate the validation error.

LoadView allows you to include as many operations as necessary in the Prepare script. However, if the task completion timeout is reached, the script execution will be terminated. The task completion time is counted from the start of the script execution.

currentTask.SendText("This is a test");
currentTask.ValidateText("This is a test");

SSL/Certificate Check

Secure Socket Layer SSL Certificate Check includes the following validation options:

• Authority: verifies whether a certificate chain contains a root certificate that is trusted, or not trusted.
• Common Name (CN): validates that an address you navigate to matches the address certificate the address was signed to.
• Date: verifies the certificate expiration date.
• Revocation: validates that the certificate’s chain of trust doesn’t contain a revoked certificate.
• Usage: verifies a certificate chain for the improper use of an intermediate certificate.
• Expiration Reminder in Days: a reminder that notifies (as an error) about certificate expiration.
• Client Certificate: client certificate name.

Time Validation Threshold (in seconds)

Enter the number of seconds the service should wait for a response from the server before ending the request execution and returning an error. If this is left blank the default timeout for a request is 60 seconds.

Basic Authentication

The HTTP authentication protocol is used to allow users to access content on some websites.

The following authentication schemes are available:

• Basic Authentication: This method encodes the username and password in base64 and sends them in the request header. It’s simple but not secure unless used with HTTPS.
• Digest Authentication: This scheme hashes credentials using a nonce (a random value) before sending them over the network, providing better security than Basic Authentication by preventing replay attacks.
• NTLM Authentication: A challenge-response mechanism developed by Microsoft, NTLM is used for securing credentials in Windows environments. It provides strong security by using multiple hashing and challenge-response protocols.

Once provided, login credentials will be passed along with the request header to the web server.

• Username: contains a username for HTTP/S  authentication.
• User Password: contains a password for HTTP/S authentication.

Do not confuse HTTP authentication with other authentication schemes such as Bearer Authentication that involves bearer tokens and OAuth 2.0 that uses access tokens.

Read the articles on Basic Authentication Username and Password and Monitoring OAuth 2.0-based APIs for more information.

Headers

The option enables adding any additional custom headers if it is necessary.

• Header Name: specify the name of the parameter as it will appear in the request.
• Value: enter the value associated with the name of the parameter.

DNS Options

The DNS Options feature allows users to choose how domain name server (DNS) requests are conducted during a test.

The Custom DNS Hosts section allows setting up the mapping of IP addresses to hostnames. IPv6 and IPv4 DNS resolutions are supported.

To specify the mapping, enter the IP address and the hostname in the corresponding fields.

See also: DNS Mode Options.

Note that the option is not supported by LoadView On-site Agents. To find detailed guidelines on how to set up custom DNS hosts for On-site Agent, visit the How to Set Up Custom DNS Hosts for Load Testing with On-site Agent article of our Knowledge Base.

Error Filter

If you want to ignore an error with a specific code and type while testing, you can configure the Ignore Error Codes option in the test target settings. If the system detects a response with the specified error type and code, the response will be considered as successful and its status will be changed to OK. Note that ignored errors will not be reflected on the reports and can’t be tracked down.

You can find a comprehensive list of Error Codes in the HTTP Status Codes List | HTTP Error Codes Explained article of this wiki.