Understanding Session Session within the context of web applications is a simple way of explaining how a web server identifies its client when in it is dealing with many clients, sometimes thousands at the same time. When a real user is interacting with a web application such as Ebay or Amazon the server keeps track of the user regardless of whether they are logged in or not. You might have noticed Amazon keeping a list of recently viewed items – this is an example of session, albeit in a very simple format. A login is a more formalized example of session where the user accesses their own customized version of the web application by identifying himself to the server which then responds with user specific content. In any event, how does the server know who it’s talking to? Session information is the broad term for information sent between client and server which serves the purpose of maintaining a one to one relationship where all communication between client and server exists only within that relationship. There are various methods servers use to maintain session with a client but the main one is session IDs. Session ID’s are usually numeric or alphanumeric values generated at random and used to maintain a session with the server for the duration of the users visit. Once one session ends and a new one is created a new session ID is generated and a new session begins. It is a common support query of Silk Performer customers to ask why their script did replay successfully for a while, but now generate errors. It is also common for business logic not to be implemented where session problems exist. The problem with session information is twofold: It is supposed to be unique to a single user It is usually time limited (expires) Each of these scenarios presents its own problem. When recording application traffic at web protocol level Silk Performer records application requests directly in the script and where requests contain session information the same session information will be hard coded in the script. This means that on replay of the script the same session IDs used during record are now being used for replay. This is a problem if they expire. The behaviour most often reported is that the script might work for a while (30 minutes for example), for one user, until the session expires and the server no longer accepts the value. This same script would fail if run for two users immediately. The solution is to customize the script to enable the use of fresh session values. How this is achieved is dependent on how the values are generated. A simple and quite common method is using the JavaScript date functions getTime method. If your application uses this you can substitute the hard coded session id with the GetTimeStamp function available in Silk Performer. It is common for session values to originate on the server in which case you will need to identify the session id in the in-data in TrueLog Explorer where it appears first and parse it from there using the customize session handling wizard. One very useful feature Silk Performer has is the customize session handling wizard which looks for certain types of session data even when you don’t know how your application manages session or what you should look for. A short video on this feature is available here . In any event, the most common cause of scripting errors and business logic not being implemented is a lack of customizations in the script to combat invalid sessions. If you are completely lost as to where to start with session handling the simplest method to determine if session values are hard coded is to run through the customize session handling wizard which will highlight certain types of differences. It is sometimes useful to perform two identical recordings or your application, clearing cache and cookies before each, and then use a text comparison tool to analyse the scripts side by side, thus highlighting the differences. Not all differences will be session related, but if there is session data hard coded it will show as a difference. This method also highlights other differences which are not related to session but which you might want to parameterize like search criteria, login information or user input data. Missing Header Information Missing header information is another reason why scripts may not perform the actions you expect them too. In particular, JavaScript heavy applications generate headers which Silk Performer might not capture automatically. Applications often need to see what page is making the current request and this information is usually contained in a referrer header contained in the request header information. This helps the server understand the context of the request, and the Silk Performer page based API handles this context automatically (functions like WebPageLink or WebPageSubmit). However JavaScript offers Web developers many options for doing things that cannot be achieved through HTML techniques, and therefore cannot be simulated using the Silk Performer replay engine by simply parsing HTML. This makes JavaScript a leading cause of context loss and Silk Performer handles this by scripting a context-less function (WebURL). It is within these context-less functions where referrer headers might be missing and would need to be added manually. In the same way, ajax enabled applications make their ajax requests using the XmlHttpRequest JavaScript object. The client specifies a request being made by ajax by sending an X-Requested-With: XmlHTTPRequest header. This header would also not be picked up by Silk Performer automatically although you can configure the recorder to do so. To check header information is correct you should compare the header information of each request between the record and replay TrueLogs within TrueLog Explorer. Not all missing headers need to be added, but where header information is very different between record and replay its possible you might need to add some additional headers in your script. Post Data One other type of data which can be hard coded in the script is post data. This is usually contained in the dclform section or sometimes in WebPageSubmitBin functions. In a nutshell, this is data sent to the server from the client during record. It can include user submitted form data, hidden form data, file data, login information and search query parameters amongst other things. In many cases this information will not be accepted by the server a second time and would therefore become a candidate for customization/parameterization. A classic example of script failure is trying to run a script multiple times with hard coded login credentials for only one user. If the application only allows a user to be logged in once then trying to run a script with this data for two users will generate errors. In this circumstance the solution would be to parameterize the username and password and read them in from a csv file at runtime so every user gets a unique login. A video on this process can be found here . Even if your application does allow one user to log in multiple times it is best practice to keep your test scenarios close to real world usage and have separate credentials for each user. In the last section we will look at logic and application stability.
↧