How to write a load test script – Part 2 | FriendRunner Development Zone

How to write a load test script – Part 2

In the last post, we discussed some strategies for deciding which user actions should go into your load test. It’s all pretty simple, include those actions that a typical user will take when using your app. But how easy is this to do in a very realistic manner. Let’s say users will visit one page twice as often as another, or the application is a game and the user will take different actions based on whether he won or lost. How can we do this in FriendRunner?

To get to the answer to these questions, you first need to understand a small secret about FriendRunner. Load test scripts are created in Selenium. However, that isn’t where the process of test script generation ends. The Selenium script is simply an easy way to communicate intentions about what the test should do, but there is no way to define all of the richness that a test should be able to hold. But that’s okay, the Selenium script isn’t even the thing that’s executed during a Friendrunner test. When you submit your Selenium script, FriendRunner will load it back into Selenium, and convert it into Java code. When you run your test through FriendRunner, it is this code that is actually controlling what your virtual users are doing.

This is great because it means that the virtual users are being controlled programmatically. If we need them to do some fancy things, all we’ll need to do is hand tweak the program. Let’s look at different things we can do:

Going to a page only some of the time

If there’s a page that should be a part of a load test, but users will only go to it on occasion, then we’ll need to take advantage of FriendRunner’s ability to use randomness in load test scripts. At any point in the script, instead of saying that the virtual user should go to some page, we can say that the user goes to some page X% of the time. Then, when we get to that point in the script we generate a random number between 1 and 100. If this number is less than X, then we’ll go to that page. This behavior can be used in any situation when some amount of randomness will help to make the test script more realistic.

User action determined by what’s on the page

Often, it’s a bit tricky to write a static serial test script because the application may respond to user requests in an unpredictable way. For instance, if the application is a game, the response to a user’s move may depend on whether that user has won or lost the game. The action that the user takes next on a winning page may not even make sense if the page is a losing page. This means that the page must be “read” in order to determine the next action to take. FriendRunner is able to search a page for a piece of text, and control the next user action beased on whether that text is or isn’t there.

Two users who perform different actions

Each virtual user in FriendRunner has a user id, just like in Facebook. If we’d like 1% of the users to perform advanced functionality, and the rest of the users to perform normal functions, we can do that easily be taking advantage of the user ids.

Warning - Don’t get carried away

When writing your load test script, it’s often useful to take a break every half hour , take a deep breath, and say to yourself “I’m writing a load test script.” It’s often very easy to fall into the trap of trying to throw every user action and function into your test script, but this must be avoided. You aren’t writing a functional test, it’s a load test, and you should treat it that way. In our experience, even very large Facebook applications can be load tested with a handful of user actions.

The reason that you want to keep your load tests simple is because timing is so important to interpreting the results of the test. If you’d like to know the point at which your test, and your application began to go south, the best place to look is the transaction response graph. This graph shows you the average time it took to run through one cycle of the test script. If the test script is very long or complex, this graph will be less predictable and harder to interpret.