Skip to content

Load Testing Blog

How do I define my user profiles?

One of the questions I hear the most from newcomers preparing load tests is about defining proper virtual user profiles.

If you are familiar with testing, you probably heard about the 80/20 rule, also know as the Pareto principle. Apart from impressing the ladies at parties (you know, probably), this principle states that roughly 80% of the effect (performance) comes from 20% of the cause (functionalities in our case). This principle is widely used when selecting the functionalities to test and avoid too much and/or too long user profiles.

Performance testing is not functional testing

Ok, I know, thanks captain obvious.

ThankYouForNoticingThisNotice

But still I see a lot of testers creating more than 10 user profiles to test the performance of simple applications. You must keep in mind that these two types of tests differ in terms of objectives, but also in terms of preparation cost.

Yes, a performance test first objective is usually to improve performance. Well this is not always true, but that's another debate.

How do I survive the stampede?

As a performance tester, I am always surprised to see how unprepared most retail websites are. Even when load testing has been done (to prepare for sales or marketing campaigns), most of the time it is nowhere close to the real users behavior. We've already seen the importance of response times in a previous article, but there are other aspects we should consider.

For instance, unless you spent the past years on a different planet, you have probably seen these videos where thousands of people rush into stores during sales. There is no reason why thing would happen differently on a retail website. So the question is how do I survive the stampede?

Stampede

Focus on what you already know

As obvious as it may seem, you should start by analyzing your users behavior. If this is not your first rodeo, you probably know what to expect. Also, websites like google analytics will give you an idea of what should happen. But never underestimate the importance of analyzing this data.

REST API using Node.js

I want to setup a simple REST server that allows to Create, Read, Update and Delete data (Users in this case) using Node.js, Express, and TypeScript:

  • I could do it using Java/Spring in a couple of minutes, but I want to learn more about Node.js.
  • Express seems to be a good choice to create REST APIs.
  • And as I think that TypeScript may be the good compromise between Java and Javascript I will keep on giving it a try.

Also, I would like to feel as comfortable as using Java. First I need a debugger. No need to spam console.log() using node-inspector. Then unit tests are mandatory and cannot go without a code coverage tool. Finally, I make use of various tools to build, test, debug and run the TypeScript code. Grunt is convenient simplify these processes (plus it's a gain for productivity).
The only thing I bypassed is a code quality tool. We use SonarQube on a daily basis for OctoPerf, and I might do the same for this sample someday.

Before reading this article further, you may check the result on GitHub Rest-Crud.

AngularJs domain name filter

Until now, we used default names such as 'Untitled VU' for virtual users created in octoperf, our load testing tool. That's not very relevant. So we changed it to the domain name of the tested website.

The load tester selects a URL to test, and we need to extract the domain name from it.

A nice trick is to create an hyperlink element <a href="..."/>. Then we can retrieve the hostname, parsed by the browser. So instead of relying on a regex we use the browser built-in URI parsing capabilities. It's easier and safer.

TypeScript using WebStorm

We use AngularJs at OctoPerf.com, for the frontend of our load testing tool. As AngularJs V2 quick start guide uses TypeScript, I think it's a good motivation to give it a try.

Prerequisite

Node.js and npm must be installed to run this sample. WebStorm is used to automatically transpile our .ts files (compile them to .js ones).

We can also use the command line transpiler:

  • npm install -g typescript to install it.
  • tsc --watch -m commonjs greeter.ts to transpile it.