Your first step is to host the app on as close to a production environment as possible to eliminate "noise" from your load/performance testing. In the case of a test server, you'd want to keep everything else off it, have any database hosted on a separate system if that's your likely production configuration, and then start exploring the application behavior under load.
Some things to consider:
- You can't actually estimate how many servers you need. What you can do is estimate how many concurrent users and users per hour a given host configuration will be able to handle. If the estimate falls below what you're expecting in traffic, then you'll need to look at load-balanced servers.
- If you can test to failure, do it (you may find that other elements of your system make this impossible. I know someone who brought down the company intranet with a load test - but the application he was testing didn't blink).
- Be aware of any other limitations within the application ecosystem: communications with COM objects are subject to a hard limit in queued requests, for instance, and some kinds of interactions can't be multithreaded (I work with a web application that communicates with a mainframe - the mainframe communications are single thread, first in first out). If you have any of these in your application, make sure you explicitly test their limits since they're a likely candidate for bottlenecks.
- If you're working within your company network, schedule the tests for a time when the intranet isn't heavily loaded. You don't want the company network to be your testing bottleneck (Ideally, you should have the server accessible from outside your company network and use a cloud-based load tool to do the testing - this isn't always possible)
- Make sure you cover concurrent users (everyone hitting the same thing at the same time) and a user access profile that seems likely for your app. I don't recall the scaling rule of thumb for concurrent users (it's something like 10 concurrent in a 10 minute test = 100 per 10 minutes) but you can probably expect that there will be special events that get you a swarm of concurrent or near-concurrent users. You want to know how well your app handles the different scenarios.
The key thing to remember here (and as an interview question) is that the purpose of load and performance testing isn't to determine what kind of equipment the application needs. It's to locate and eliminate as many bottlenecks as possible. You should never be afraid to tell an interviewer this: if an organization uses load and performance tests for this purpose they run a high risk of over or under-committing resources.
