The WebSocket Connection operation corresponds to an HTTP request that establishes a socket connection (opening handshake) between the client web application and the tested server in your scenario. These operations are recorded. You cannot create them manually in the scenario editor. However, you can move these operations between pages in the recorded scenario.
The request has, for example, WebSocket-specific headers:
Similarly, the response header also includes specific data:
|Number of occurrences:||Unlimited.|
|Parent operations:||Connection, Page (if HTTP(S) connections are hidden in the scenario editor), Scenario (if pages and connections are hidden), Group, If... Then and If... Else, Loop, While.|
|Child operations:||The operation does not have child operations.
The WebSocket client and server messages made through the WebSocket connection follows the connection at the same level. That is, in the request hierarchy they are followers, but not children.
The Think Time edit box at the top of the editor specifies the number of milliseconds the operation will wait before it starts executing.
The SLA edit box at the top of the editor specifies the maximum acceptable duration of the operation, in milliseconds. Since the operation corresponds to an HTTP request, its duration is estimated as the time to first byte.
Technically, the WebSocket connection is an HTTP request. That is why the operation editor’s panels and pages coincide with those of the Request operation editor. The request contents have WebSocket-specific data (see above).
On this page you can view and change the contents of the simulated request. The page contains the following panels:
|Request Header||Displays standard and custom headers of the request (including WebSocket-specific data).|
|Request Body||Displays the request body contents. Typically, for WebSocket connection requests, this panel is empty.|
|Data Replacers||Shows rules for replacing request contents and cookies with variables. You use this feature to insert needed data to your requests. For instance, to implement data-driven tests, you may replace recorded data with data loaded from a CSV file or Excel sheet.|
|Uses Data From||A list of variables that are used in the request headers and body. If a variable extracts data from some other request, the panel displays this variable as a child item of that request.|
On this page you can view and change the contents of the expected response, and save response data to variables. The page contains the following panels:
|Response Header||Displays the response header data (including WebSocket-specific data).|
|Expected Codes||Specifies whether LoadComplete treats this or that response code as an error, warning or success.|
|Response Body||Displays the response body contents (if any). You can also change response body data on this page (that is, you change the data that LoadComplete will expect to receive from the server in the response).|
|Data Selectors||A list of data selector rules (LoadComplete uses them to extract data from responses and save them to variables).|
|Provides Data For||Displays a list of requests that use variables, whose data you specify on the Data Selectors page.|
|Validators||A list of rules for checking the response contents.|
This page provides summary information on the operation and its child operations like the number of found errors, the list of variables used, and so on. Information on the page is read-only.
You can find information on issues in operation properties in the Summary page. Also, information about the erroneous settings is displayed in the editor’s header area.
LoadComplete treats WebSocket connections as an HTTP request. That is why it does not hide the operation when you uncheck the Connections button on the Scenario Explorer toolbar.