To verify whether the tested server processes simulated requests correctly, LoadComplete compares actual server responses against expected responses.
-
For HTTP traffic, LoadComplete compares the responses by their response codes. If the codes coincide, LoadComplete considers the request as simulated successfully. If the codes differ, LoadComplete believes that the request was not simulated or processed correctly, and posts a warning to the test log.
By default, the expected code is the recorded code. You can re-define the expected code and specify how LoadComplete should treat various codes when it receives them from the server. See Setting Expected Response Codes.
If a request is redirected unexpectedly during simulation (though it was not redirected during the recording) and a 3xx Redirection response is received, LoadComplete will automatically simulate a request to the resource's new location. It will then capture the server response and compare it with the recorded response code (rather than comparing the recorded code with the code of the Redirection response). See Handling Unexpected Redirects.
If a request is declined unexpectedly during simulation due to the absence of credentials (though it was accepted during the recording) and a 401 Unauthorized response is received, LoadComplete will attempt to send a proper authorization request automatically. If the authorization passes, LoadComplete will compare the code of the resulting server response and the code of the recorded response (rather than comparing the recorded code with the 401 Unauthorized response code. See Automatic Authentication.
-
For WebSocket traffic, LoadComplete compares the synchronous server messages by their Opcode field value. If the values coincide, LoadComplete considers the received server message as correct. Otherwise, LoadComplete posts an error to the test log.
Note: LoadComplete does not verify the contents of asynchronous server messages.
In some cases, this is not enough to determine whether the web application works properly. For instance:
-
The tested server can respond with code 200 (success) to a request but send inappropriate data in the response body. For example, web applications, like the Adobe Flash and Flex applications that use the AMF protocol, always return code 200; they pass information on errors, if any, within the response body.
-
The Opcodes of the actual and the expected server messages may coincide, but the data they contain may be different.
To get better control of the response verification, you can define validation rules:
-
Open your user scenario in the Scenario editor.
-
Find the needed request or server message and examine its contents.
-
Extract the data to be checked to variables:
-
For HTTP traffic and WebSocket traffic, extract the needed data to variables on the Data Selectors tab.
-
For Rich Internet Application traffic, extract individual parameters to variables on the Response Body tab.
-
-
On the Validators tab, create rules for checking variable values against expected data.
When you run the scenario, LoadComplete will check the received server responses by using the specified validation rules.
For detailed information, see:
