-
If the tested web server resides on the computer where you record the traffic, use the computer name rather than localhost to address web pages. This will make the recorded scenario computer-independent.
This way you can move your load tests to another computer and run them there without having to correct the tested host name in the scenarios.
-
If a tested web server provides authenticated access to web pages, it will show a dialog asking you to enter your user name and password to get access to the target contents.
To simulate scenarios recorded for such a server correctly, enter the server address, user name and password in the Authentication table.
-
Clear the cache or activate the browser’s private mode before the recording. This will help you avoid the effect of previous sessions on the recorded scenario. For instance, the browser can remember the account and password you used to log in to the tested web site during the previous session, and the recorded scenario will not contain “login” requests. However, there is no guarantee that these values will be in the cache later, during the test run, and the test will fail.
You can keep the browser’s cache if you are recording scenarios that will be simulated in series and you have already recorded a scenario that simulates logging in.
-
You can avoid recording unnecessary traffic (for example, requests that third-party applications on your computer send to the network during the scenario recording) by configuring LoadComplete to record only the traffic to a needed domain or only the traffic your application sends. See Excluding Undesirable Traffic.
-
Start recording a scenario from the web browser’s start.
If you start recording a scenario after you connect to the tested web site, enter the login data and open some pages, the scenario simulation may fail. This can happen because the recorded traffic will not reproduce the authentication procedure, and the tested web server will ignore the simulated requests.
-
If you use custom pages to group requests in your scenarios, we recommend that you specify an initial custom page before you navigate to your web application. You can do it right after the recording starts, by typing the custom page name in the Recording toolbar.
-
For WebSocket traffic, always start the recording with performing user actions that will send an opening handshake to your tested web server and open the WebSocket connection in your web browser. For example, depending on your web application, you may need to refresh the web page, or click some "connect" button, or log in anew to your application, and so on. Otherwise, LoadComplete will not be able to detect and record WebSocket messages.
If you record several scenarios in a row, always start the recording of each of the scenarios with performing user actions that will open the WebSocket connection.
-
In general, it is better to record several small scenarios and use the Call Scenario operation to combine them into a large scenario to perform testing, since updating small scenarios is much easier than updating large scenarios.