Modern web-based applications are getting more and more complex, which makes testing those applications very difficult. The web server or client-side javascript can generate unique hidden variables or separate URL paths for each user. Sessions can be specified not just through cookies, but hidden in the web page itself. Values from previous forms can be compressed, encoded, and stored inside variables with names like "__VIEWSTATE". Sometimes even the names of form variables changes from one user to another. Note that Application State Management does not deal with data that the user would enter in form fields or any other type of user-entered data. Application State Management is about all of the other complex variables changing behind the scenes. To change the input entered by the user in a form, see the section on Customizing a Testcase.
With a scripting-based load tester you'd have to find each dynamic variable and where it is used, and configure it by hand, if it is supported at all. A typical application could have hundreds of dynamic variables, which means developing the test case can take days even if you understand the scripting language. Load Tester's Application State Management wizard automatically finds and configures each dynamic variable for you. It locates where the variable is first used, and configures a parser to extract that value at runtime, and then detects where the value is used, and configures data replacement so that each virtual user gets its own unique runtime value.
The Application State will normally be automatically configured by the Testcase Configuration wizard before a replay can be attempted. To run the wizard again at a later time, select the testcase in the Navigator (or open the testcase in the Testcase Editor) and select the Configure → Application State option from the pop-up menu or toolbar.
After the ASM wizard has Finished configuring your testcase, you may inspect the results of the ASM wizard from the Fields View. The automatically configured fields will appear with a grey background, showing they have been automatically configured.
To override ASM's default handling of the field, simply right click on the field in the Fields View and select "Edit". Simply change the Datasource to "Recorded" to reset the field to its recorded value without any dynamic handling, or enter another datasource to send.
In addition to Form Fields and Application specific fields, the ASM wizard also manages state fields defined by the web server, such as E-Tag and If-Modified-Since. These configurations are visible from the Headers View:
The best way to determine if your application's getting the right values is to check your application state or database. For example, if you run a test case that supposed to purchase a product, check your database to see if there's a record of the purchase. If this shows there's a problem, the next step is to check your own application's error logs for trouble.
Once a problem has been verified, the next step is to walk through the pages in the replay, looking for error messages from the server. It may be useful later to configure validators (from the Validators View) to flag the same errors again during further replays. If the error on the first error page in the replay suggests that the cause of the error was not user entered data, but a hidden variable normally handled internally by the user's web browser, then you may use the Fields View to track down any variables on that page that do not have modifiers to update them automatically (if applicable). Once you have located a variable that is not being handled automatically, and confirmed how the application automatically updates that variable, you may consult the Advanced Application State section of the manual to give the Application State Management Wizard enough knowledge to correctly update your scheme.
To disable automatic handling for certain fields when ASM is run, the Ignored Fields preference page may be used.