It is important to check that the server response is valid under load. This is to make sure not only that the scenario works as expected, but also that the load imposed does not cause errors in the application
NeoLoad automatically detects requests containing errors, in particular using the HTTP response code. For example, NeoLoad will log a request error if the response contains a
500 internal error. However, many web applications do not return the appropriate HTTP error code when handling an error, which means that for these, NeoLoad cannot automatically detect the fault.
These cases must be processed individually by checking the validity of the content returned by the server at key points within the application. This may entail checking for the presence of an expected text, for example "The operation was successful", or making sure the response does not contain "Error".
Once the test is finished, select the requests containing errors, or those where the validation failed, in the errors panel. The content of the corresponding server response may then be analyzed to determine the cause of the problem.
Note that validation uses up resources (CPU, memory) on the Load Generator, and that it is usually wiser to restrict its use to testing key pages only (for example, those that provide access to a database, or those more likely to produce errors).
Proceed step by step:
When a Virtual User receives an error, it should normally stop running. If this does not happen, it could continue playing requests that have no meaning. For example, if the user login fails, there is little point sending further browsing or search requests to the application as it will only distort the response time statistics for those pages.
Each Virtual User type may be configured to stop running in case of error or failed assertion.
Each transaction (registration, on-line purchase...) may be composed of several web pages. Statistics may be obtained by transaction by grouping these pages in a Container.
NeoLoad allows you to retrieve performance data from most server infrastructures using Monitors. Configure Monitors on all your infrastructure key servers to monitor: CPU, memory, hard disk and network usage on the web, application and database servers. For more information, see Monitors.