NOTICE: Our Community is moving. Get more information. Updated information on a New Login Process
Session-handling customization is the process of manipulating server responses in such a way that application state information is preserved during load testing. In their responses to clients, servers often generate information at runtime that is used to identify future client requests as coming from the same computer during the same user session. Servers may send out unique strings, commonly known as session IDs. If not updated in test scripts, such session information can create problems in subsequent test runs.
When replayed test runs are compared to originally recorded test runs and outdated session information is discovered, that information must be replaced with dynamic variables in future test runs. Otherwise test scripts pass along invalid session IDs or other session information.
The following video demonstrates how this can be done using the TrueLog Explorer’s Customize Session Handling Wizard.
First record a script remembering to clear the recording browsers cache and cookies.
Next continue to model a script in this case against the ShopIt sample application. The purpose of this application is to represent a normal ecommerce website. We purchase an item and check out of the store.
Then we save the script, remembering to always close the browser before closing the recorder. Run a TryScript.
You will notice that the first pages seem to have loaded successfully and are shown in the rendered tab giving visual confirmation that the correct page has been returned during replay. However below it is obvious that some errors have occurred.
This is obvious within the application because the wrong page has appeared. The info tab below shows the http error.
Moving to the next error shows http 1062 error – form not found. This is the most common session related http error because the reason the form can’t be found is because the application is not on the correct page because the state has been lost due to an invalid session. The cause of this issue is that the recorder has recorded a session id and hard coded it in the script. When we replayed we tried to use the same session id which was hard coded but this will not work because it has expired.
To use the customize session handling wizard:
When a session id is found the id is displayed with a message in orange highlighting that a difference has been found between record and replay. It also highlights if the difference appeared in the source code and if it occurs in the bdl script – for example if the session id is found to be hard coded in the script.
To recap what is happening at this point – we are comparing the server response between record and replay to see if any differences occurred. If a difference did occur then this will need to be parsed and variablized so that the correct session id can be picked up and used in future replays.
Looking at the script we can see an addition of the sFormid variable which will be placed in the dclform section where the id appeared hard coded. You can also see the parsing statement which the wizard has added.
Now when replaying the script the replay should be successful.
I think Auto correlation doesnt work all the time, it would be great if you can make a video for manual correlation.