One of the most underused techniques when it comes to scripting with ZebraTester is how you make use of your test data to enhance your input files and vice versa. Instead of just collecting the most necessary data for your test you should think of what further data can enhance your test; if you need data for logins you might want to get a firstName and lastName column as well to make use for dynamic verification while running the test. This is necessarily not an advanced technique but something that should be adapted more to verify integrity of responses better.
Another technique with input files is that we can define different user behaviors like how fast – or slow – a user should pass through the test. The example below describes how this can be achieved both in the input file and then how to tie it together in ZebraTester.
With the above data we can connect each column in our user_behaviour.csv to the think time of the page breaks and that way enforce particular behaviors so that we in the above case have 1/3 slow users (20;20;30), 1/3 normal users (10;10;30) and 1/3 quick users that only spend 5 seconds per page until they reach the page they were looking for which they stay a minimum of 30 seconds on.
But we can still make enhancements to this file by changing it so that the hit ratio on the user behaviors gets used depending on a percentage.
By ensuring that we have 10 lines of user behavior in the input file we now weight how often a user behavior is used by configuring how we select a row in ZebraTester and that is achievable by simply making sure it picks the data sequentially and we can then represent user behaviors in percentages, 40% of the users will act as a slow user, 50% will act as a normal user and 10% will act as a quick user.
If we then change the behavior of the “Line order” function randomized those hard 40% slow visitors we defined earlier will now mean that there’s is a 40% CHANCE that a slow user will be started.
When the input files have been populated you need to configure your ZebraTester scenario to make use of the input file, to do this just click on any URL in your scenario recording to open the URL Details/Var Handler and proceed to add the input file and create a variable for each column that represents a page break in your input file.
When all variables have created – for a 3 page break scenario you should have 3 variables configured – we need to map these to the think times in the test, to do this we just need to open and configure the think time values for each page break in your scenario as shown below.
When these two steps have been performed for your scenario it is now configured with different user behaviors that can be changed or expanded at any time to reflect new data.
By setting up an input file according to the example below we can also define what is called a user flow which is a way of setting up the test to execute different user flows in the same scenario. For our example we are using a WordPress test consisting of 3 steps or page break’s as they are called; test can be viewed below.
In the above example we have identified 3 different user paths we want to define,
- The user loads the start page
- The user loads the start page and performs a search
- The user loads the start page, performs a search and opens the first article in the list
Important to note is that if a step needs to extract a value to be able to build the request or get the correct data you need to include the steps where you extract that data from, in our example we cannot extract the top search result hit if we haven’t performed the search that gives us that post id.
To achieve this with a input file we will set it up it according to the example below,
1;1;1#execute all steps
1;1;0#execute start and search
The 3 columns represent if we should execute the step or not, in this example 100% of all users will execute pattern 1, 66% will execute pattern 2 and 33% will execute pattern 3. When the file is created and seeded with your user flow’s you can tie each column to a variable – We recommend that you name the variables step 1 to 3 to make it easy to track – and then create the inner loops and tie them to the variables for how many executions they should do, to do this in ZebraTester you just map the columns in the same manner we did when configuring User Behaviors previously in this post, when that is done all you need to do is create inner loops and assign the variables as shown below.
This process needs to be repeated for each step and also supports nested inner loops for more complex user paths designs, for this example we just want to span each inner loop across one step and not overlap any other inner loops for simplicity.
So with fairly simple scripts we can achieve fairly advanced load patterns by just having the right test data and information on user patterns from analytics services like Google Analytics where you can define certain patterns in beforehand to make the analysis before the test easier, we hope this helps you in your current or future projects.
Written by Daniel Freij, Senior Performance Engineer and Community Manager, Apica