Tests created with Selenium WebDriver replicate the user experience from the perspective of the UI. It can be thought of as a top-down approach whereby it accurately replicates the behavior of an end user. Running through a browser instance such as Chrome or Firefox, the test process itself interacts with the actual user interface elements of a target test application.
This is in contrast to many other testing frameworks. One of the most popular is JMeter, and differs from Selenium in that it takes a bottom-up approach. JMeter tests simulate the user interaction by precisely defining each individual web request in an attempt to re-create the overall user experience.
Advantage of Selenium for Load Testing
With Selenium the entire user interaction can be recorded and replayed using a real browser window. It is therefore easy to appreciate how a Selenium test can be a superior tool for more closely simulating real user interactions with a web application. However, it does have one drawback that must be considered in the context of load testing.
Disadvantage of Selenium for Load Testing
Selenium tests require an entire browser instance to be loaded for each virtual user simulated. This creates a very high relative resource demand when compared to each virtual user simulated with a JMeter test. While this in itself is not an absolute deal-breaker for using Selenium WebDriver for load testing, it does make it expensive. It is not uncommon for a Selenium based test to consume ten or or even one hundred times the resources per simulated virtual user as compared to a JMeter test.
As the above pictogram illustrates, two similar tests using a scripted JMeter architecture versus one using Selenium WebDriver may achieve the same task, however the scripted test is much more efficient. Given unlimited resources this wouldn’t pose a problem, but most real-world scenarios involve budgetary constraints. With all else being equal, running Selenium WebDriver tests are much more expensive.
Choosing the Best Architecture for Your Test
When it comes to deciding on the best architecture for your load test, it is important to determine what your ultimate testing goals are. If you are intending to stress your target test application and probe for breaking points, most often a scripted test is the best option for this. There are some exceptions however. One might be a scenario where you are performing functional testing with some load requirement. In this case the Selenium test might be advantageous in that it will capture how the user interface responds.
Another scenario where you might utilize a Selenium WebDriver test is for a web application that is too complex to simulate using scripted requests. Examples of such are those which rely heavily on Ajax requests and complex responses that are best simulated using a full web browser instance.
Regardless of your specific testing needs, the selection between scripted tests using something like JMeter versus Selenium WebDriver will likely be under some budgetary constraint. Selenium tests are always more resource intensive, and that must be factored in when choosing your test plan architecture.
JMeter as an Alternative to Selenium
Even though Selenium WebDriver most closely simulates the end user experience recreating it with high accuracy, it is resource intensive. If we are more concerned with stress testing our target test application we can do this more efficiently with a scripted framework such as JMeter. This is especially true when massively scaled load testing is indicated into the thousands or millions of virtual users and beyond. In these cases, JMeter will almost always be the superior choice.
Did you know that RedLine13 offers a full-featured free trial? Sign up now and move your Selenium WebDriver load testing to the cloud today!