Published by Rob Lambert,
Unless you are creating a website with a very limited audience then you will probably be expecting a reasonable number of visitors to your site. As such, it would be prudent to check that it works for X number (where X is a number relevant for your context) of users.
One of the trickiest elements of testing for multi-user or load testing your application is defining the end usage patterns and expected load. It's not just about the maximum number of users, it's about how long they spend on your site and ultimately what they are doing.
For example, some sites may be used everyday by only a handful of people, but at the weekends visited by many thousand. There is also the added complexity of mapping out the end user behaviour patterns. Are all end users going to perform the same actions each and every time they visit your site?
One of the simplest methods for starting your journey to multi-user testing and then load/performance testing is to use the simple concept of One, Two and Many (or other variants of these numbers)
I personally like the One, Two and Many because it's easy to explain and it's also provided me with exceptional value when used.
The theory goes like this:
You test with one user to make sure the basics work at a functional level.
You then test with two concurrent users to check that there are no basic deadlock and concurrency issues and that the application/site allows multi-user activity at a basic level. You'd be surprised at how many issues I've found by this simple approach. The amazing thing about this sort of test is that it's quite simple.
After proving basic concurrency you can then test with many more users. The "many" being whatever value you deem to be right for your goal. That could be ten, twenty or maybe even two million. The choice is yours.
The reason for starting low and then jumping to big numbers is that in my experience most performance issues happen with relatively low numbers. I’ve also seen many teams ramp up very expensive infrastructure and load test tools only to find the product wouldn’t even allow two users to log in at the same time.
How to test for basic performance
I would suggest you perform the “One" and “Two" manually, maybe with some support by simple automation like Selenium or even ignoring the UI and diving in at the API (application program interface).
For the bigger loads there are countless options, of which I'm not going to explore in this book.
My personal favourite at the time of writing this book is jMeter (http://jmeter.apache.org/), simply because it's free, easy to get started with and easy to extend.
Saying that, you could opt for any number of solutions, free to very expensive, locally installed or hosted; maybe even a complete managed service.
Whatever your decision never lose site of what your goals are. Performance and Load testing can become complicated, unwieldy and expensive as you explore any number of variables unless you keep focused of what you’re goals are.
Do a proof of concept or trial run with free or “free to try" tools before opting to buy any product.
Tool quality and suitability can vary greatly.
A general rule of thumb in my experience is that as the cost of the tool goes up the suitability for purpose goes down.
A list of testing tools on Wikipedia
If you’re interested in a career in Software Testing then check out my book Remaining Relevant And Employable (Tester’s Edition) - it’s packed full of ideas about writing good CVs, communicating your value to employers and doing well in an interview.