The HTTP protocol, by its very nature, is stateless. HTTP follows a simple request/response paradigm. The client (the browser or other application/applet that uses HTTP for communication with a server) opens a TCP/IP connection to the server, sends a request, and receives a response from the server. Different requests from the same client to the same server, either on the same TCP/IP connection or on another connection, have no relationship to one another.
Web applications on the other hand need to embed single requests within larger entities such as complete HTML pages, user sessions initiated on Web servers, shopping carts, and registered customers.
To do this there must be some means of transferring state information from the server to the client that allows for the information to be returned back to the server within subsequent HTTP requests so that the server can associate the request with a specific user session (for example, a virtual shopping cart used by a registered customer.) and respond appropriately.
The techniques that Web applications use to transfer state information can be used with any Web browser.
A load-testing project that is to deliver useful results must simulate real users accessing Web servers with real browsers. Otherwise results will be meaningless.
Results may be invalid - Poor context management can result in load-testing scripts in which, amongst other issues, each virtual user logs in to the same session, uses the same account, or uses the same shopping cart. In such cases, the impact on the Web/application server is quite different from a comparable load that might be experienced by a live application. Therefore the test results will be meaningless.
Errors go unnoticed - Web servers often do not use HTTP status codes properly when indicating errors. Instead, HTTP status codes that indicate success are returned within HTML documents describing application-level error conditions (for example, server overloaded and session timed out). If the next instruction in the script does not refer to previous results (for example, by requiring that a link be present), such application level errors may go unnoticed. There is no way for testers to inspect millions of lines of code in thousands of log files to find such errors.
Therefore, context management support contributes directly to improved error detection by providing "auto-verifying" scripts.
Scripts can not be replayed - While replay errors that arise from the auto-verifying functions of advanced context management can be productive, replay errors that arise from improper context management can cause problems, leading to tedious manual customization and debugging of scripts that waste QA resources.
Advanced context management eliminates such annoyances, leading to improved productivity and reduced testing costs.