Have you ever thought of running a performance test with 100,000 real browsers? If you would have done that, you must have experienced at least one of the following things.
- You would have actually done it with 1 Lac live concurrent users on your application.
- You would have used a performance testing tool like JMeter to simulate real browsers.
- You would have setup an advanced testing lab with numerous text boxes running real browsers.
If you are not able to answer the question, the point here is that testing large number of users won’t be economical if you run performance testing using real browsers. This is the most common mistake for those who are new to performance testing. However, otherwise it’s quite obvious.
You have to see when is the right time to run tests with real browsers? Some of the instances when you can use real browsers are mentioned below.
- Single user tests for bug detection in early stage code development.
- While evaluating functionality, irrespective of the response time, load times, and performance.
- Tests that do not depend upon the browser’s behavior on apps functionality.
- Performance tests with less than 10,000 concurrent users
Limitations of Using Real Browsers
Cost and complexity are two known limitations. In addition, they are also resource incentive. This is because they consume more CPU and memory for JavaScript. To represent a user, each browser requires its own power. So, for thousands of concurrent users, you need to have thousands of testing boxes to use real browsers. However, this is not easy in the majority of the organizations, especially when the budget is limited.
So, it’s better to go for a solution where there is a large scale testing of million concurrent users at the HTTP level and using real browsers when the required load is not too much. For hardware deployment, you can either prefer staying on-site using your own system for more security or use public clouds for testing.
You may also like: Performance Testing Bottlenecks and Challenges
