In order for your load tests to emulate user behavior as close to real life as possible, you need to insert appropriate data into simulated requests. Inappropriate data may cause errors and warnings during test execution and cause improper server functioning, that is, the test will load parts of the server code other than those that you were not going to test, and it is possible that the needed functionality will not be checked under load.
This topic explains typical cases when you need to pay attention to the contents of simulated requests.
Date/Time ValuesDate/Time Values
It is possible that your client/server traffic contains date/time values and you insert data/time values into simulated requests. If your computer and the tested web server reside in different time zones, the simulated requests will contain your local time which will differ from server time. This can cause problems as the server may consider these requests invalid and respond to them in a way different from the one you expect.
To solve the problem, you need to insert appropriate date/time values into requests. For instance, you may set the server’s time on the computer where you launch tests or insert date/time values that will match the server’s time.
Database Applications
Database applications use row identifiers to find records to be updated or deleted. Quite often row identifiers are database columns of the auto-increment type, and the database engine automatically sets the column value for each new row. It is important that your load tests use appropriate ids when simulating traffic of these applications. Else, the test behavior will differ from what you expect.
Consider the following typical situation. Suppose you are testing an application that displays information from a database table on a web page. The page contains code and UI elements that let you create, change and delete rows. Suppose you are recording a test that adds a new row to the table and then changes it. The application sends requests and new data to the server and the server part updates the database.
If you run the recorded test as it is, it may not work as expected: the new row will not contain changed data. This happens because the added row has a new identifier while your test uses the recorded row identifier that corresponds to the row that you added during the recording.
To work around the problem, you need to modify the traffic to be simulated by the test. You have to save the new row’s identifier to a variable and then insert the variable’s value into subsequent requests that pass data to the server. For more information on how to perform these actions, see About Data Correlation.
See Also
About Parameterizing Requests
About Data Correlation
About Variables
Editing Recorded Requests