User modeling is a very important step when planning out load tests. There are many ways to go about creating a model, but the UCML (User Community Modeling Language) Diagram stands out as an excellent way to quickly and visually communicate the various business processes virtual users will perform during the load test. A UCML diagram is formatted as a state machine that shows what percentage of users will take a given path at each decision point. Another way to imagine a load test is for hundreds of users flow through this model at a time and they take each path based on probability. In essence a well designed UCML is a Markov Chain.
Fig. 1 – Sample UCML Model
In the LoadRunner Airlines example in Fig. 1, we see that 85% of the total users will proceed to the screen to enter customer information into the system and the other 15% will look up a flight upon logging in. Moving down the model, again users will reach a decision point as to whether they are performing a book versus shop or change flight versus cancel flight. Each percentage indicates the percentage of total users that make a certain decision. At the end of each user’s business process, that user will then log out of the system as indicated by the 100% logoff bubble.
So how do we go about making such a model? First, we need to begin with the actual usage data needed to plan out the business process mix and the UI steps needed to perform the business process. Once the data is in hand, it is just a matter of using math to figure out the percentages and placing the steps in the correct order. Let’s say there are 100 business processes performed in a given hour of application use. Determine the first steps of each business process, and then find out how many times that step is performed. If 85 of the 100 transactions are enter customer information, and the other 15 are flight lookup, that leaves us with 85% and 15% respectively. After that it is just a matter of determining the next set of decisions and performing the same math to figure out the breakdown of future decision sets.
Now that we have our percentages determined it is only a matter of transforming the data into a beautiful UCML Diagram. There are many tools out there to build a UCML. Fig. 1 was created using Microsoft Vizio, but there are other free tools that can be found on the web to accomplish the same goal.
Once the user model has been completed for the load test, it is time to create a script to match the workflows. An excellent method to avoid having to keep track of multiple scripts is to create a single modularized script. Using Fig. 1 as an example, there are a total of four workflows for the LoadRunner Airlines application. Instead of having four separate scripts to run, it would be easier to have a single master script containing the four workflows. The script can then delineate which workflow a user will perform.
To create a modularized script, a quick and easy way to start is using LoadRunner’s run blocks in the Run Time Settings menu on the Run Logic node. Note that the percentages must add to 100 for LoadRunner, since it is based on the number of users at the current fork and not overall users. Some quick conversion is in order, but luckily it is easy enough. Using the Book workflow as an example, we can easily scale the percentages by dividing the fork percentages into the previous decision’s percentage. To convert the Book workflow, just divide 15 into 85 and we end up with roughly 18% of the customer info users deciding to book a flight. After applying the same scaling math to the other decision points we get the following percentages.
Fig. 2 – LoadRunner Run Time Settings Modularized
The setup in Fig. 2 was created by using run blocks that were set to randomly choose actions. To do this, just insert the necessary actions and insert blocks to act as the decision points. Highlight an element, click properties, and set blocks to random any time there are multiple actions to choose from. Refer to Block1 or Block3 in Fig.2 as an example.
The LoadRunner Run Time Settings menu is a great entry point for modularization, but the true power from this concept emerges when it is implemented as code. Some major differences arise when doing this method compared to the Run Logic method, beyond the fact that we are using code and not menus. First, we can go back to using the same percentages as the UCML since the code can be based off of total users again. Second, the Run Logic must change to remove all actions except vuser_init, vuser_end, and the action file you will use to create the decision tree. Third, it is much quicker to change the percentages in code as opposed to the menu.
Fig. 3 – Sample Code Driven Decision Tree
The tree in Fig. 3 allocates percentage ranges that match the percentages of the UCML. If iRand is chosen to be 96 in this tree, then the user will execute a Cancel Flight workflow. It is recommended to use action files that house the actions required to perform each workflow to keep from cluttering the driver. For example, a “BookDriver” action would contain the “CustomerInfo” and “Book” actions necessary to complete the workflow. To really unleash the power of code driven modularization, the percentages can be parameterized and controlled via a parameter file. This allows the percentages to be changed with only a few mouse clicks or even the command line. Past profiles can be saved in case they are needed again for future testing.
Billy Garrity, Consultant of Managed Performance Testing at Orasi Software