Typically in when performance testing complex applications the script development phase is by far the longest and most complex part. The reason is due to the way that performance tools capture user activity, at the HTTP layer. This means that session state and other parameters have to be handled correctly for the script to work correctly and be usable to generate accurate and correct load as part of a load scenario. This data is not seen by the user as it is handled by the browser, however performance tools work by emulating browser traffic and therefore must be able to emulate it correctly.
Agileload script Modelling
AgileLoad has the capability to automate the parameterisation of scripts for complex applications using ‘Script Modelling’. The benefit of this is that most of the work is taken out of the scripting phase and scripting time can be reduced from days to hours or minutes, it also avoids mistakes that can be made with a manual approach. AgileLoad comes with models for some applications as part of the install, however for applications that are not already in the list and bespoke applications, models can be built or existing models can be copied and adjusted, effectively enabling the AgileLoad user to ‘teach’ AgileLoad how to deal with these complex transactions.
In the example we are going to discuss in this section we will look at a Microsoft SharePoint applications, mainly because they can be very complex to deal with for performance testing and because they are incredibly common in the field. In fact AgileLoad comes with a model to manage SharePoint applications and we will look at the way that the model was built in order to understand the modelling feature of AgileLoad, the point being to enable you to build a model from scratch and to enable you to customise this model should you need to (many SharePoint implementations are heavily bespoked and can be significantly different from a vanilla implementation).
Firstly let’s take a look at the model working, how it is implemented and the effect it has on the script it is working on. After the script is recorded AgileLoad will attempt to detect the type of conversation that it has recorded – in this case it has detected that it has been a .Net or SharePoint conversation (see Session identifiers management screenshot). Using the drop down box you can correct AgileLoad if it has guessed wrongly. AgileLoad will attempt to use the model that it calculates will do the best job of parameterising the script. Clicking OK will start the automatic parameterisation process. Don’t worry if you are not happy with the parameterisation – the script can be brought back to its original state by choosing the Regenerate Script option from the Tools menu in the AgileLoad Script Editor.
To understand what AgileLoad has done in this process we will look at a before and after screenshot, first the before screenshot shows a script with hard coded parameters, notice the <projectGUIDs> section and dates :
After the model has done its work then those hard coded parameters are parameterised, see red circled areas:
So how did AgileLoad know what needed to be parameterised? The answer is that it used a model, this model was created using the automatic modelling tool which can be configured using the Manage Session Configuration window. This section deals with that part of AgileLoad – please see the Manual Parameterisation section to understand how to parameterise a script manually.
You will need to understand this before you can teach AgileLoad how to parameterise the script.
Next Parameterising dynamic data