URLs are the key to scripting web applications correctly with a load testing tool. That is, you can either manually enter the URLs directly into the script and see if it will play back, or you can use the interactive recording capabilities and let the product record what you do within the site. The latter is usually the preferred method since it's easier to "walk" through the site by navigating as a real user would, recording the script along the way.
Though Quest doesn't offer load testing tools for web apps, there may be times when it would save time to take a real-user’s session from Foglight running in production and turn it into a script for playback during a QA process. This could more accurately simulate what real users are doing on the site, rather than taking an educated guess as to what you “think” they will be doing on the site. Of course, you would still need to strip out the user’s personal information before making a script from it, and perhaps even some of the extra navigation the user does that would be unnecessary to replicate in the script.
There is no magic mechanism in Foglight to create such a script since any recording would need to be cleaned up, with personal data and sensitive fields removed. So, I've put together some high-level steps within Foglight to build a script from an actual end-user session, first from within FxV:
- In FxV, do a sessions search and pick a session that you believe will be a good representation of the script you wish to build
- In the Content Replay Tab view, select “Export to ZIP” so you can share this with the QA team
- Open the .ZIPped file from your desktop, or the desktop of the machine running your load testing recorder, where you will be presented with the session replay in off-line form
- Using the URL button at the top of the browser will show the actual URL the user touched during his/her session
- Open up the recording tool and begin scripting of a virtual user following these URLs. In the case where there is data entered, a decision has to be made whether to parameterize this or not. Most script recorders let you use parameter files/randomize/etc. the data so that the app servers and databases are not cached for each subsequent run, resulting in unrealistic response times.
- Follow as much of the script as makes sense until a complete script is created.
- Replay the script to ensure playback works.
- Open up the User Session Log from Analysis->User Sessions Log
- Find a representative session to use for scripting
- Scroll down past the performance summary information until you get to the URL-level listing of each URL within the session
- Follow as much of the script as makes sense until a complete script is created within the scripting tool, taking into account the randomization/parameterization mentioned above
- Replay and test!
Because Foglight captures the data entered during a session, you can get a reference for what fields will need to be entered for the script creation, but obviously you may not want to use the exact same data from a production user to avoid real-user impact.
--Jason
is an end-user performance expert with Quest Software and can be reached on Twitter @QuestExperts