HOW SELENIUM WEBDRIVER CAN BE USED FOR PERFORMANCE TESTING

To save time and make use of existing assets, there is a desire to re-use functional test scripts to execute performance testing. Selenium WebDriver is widely used by test analysts, so why is it not standard practice to re-use Selenium WebDriver scripts for performance testing ?

When researching the subject on the Selenium website, the consensus is that is it not generally advised, not because it is incapable but because it is not optimised for the job and you are unlikely to get good results.

We've taken a look at this and broken down the positives and negatives:

POSITIVES:

a). Selenium is freeware and extremely capable.

b). We can use existing functional automation scripts (though functional test scripts do not make good performance test scripts).

NEGATIVES:

a). Has a large footprint and requires significant hardware to run a performance test.

b). Has to be plugged into another tool to run a performance test.

c). Can be awkward gathering and reporting performance test metrics.

HOW DO WE ADDRESS THE NEGATIVES ?

Rather than using an existing functional test script, we lift out the assets required. If someone else has spent time creating a POM (Page Object Model) then creating a new performance test simply becomes plug and play. Unfortunately, the footprint it is what it is and there are no hard and fast rules to calculate the footprint and the hardware required to support your test.

There are many factors that can be taken into consideration, with the main one being how hard your site works the browser. If you consider video conferencing; with video & audio up & down sockets, chat and handshakes, the WebDriver footprint fades in significance.

The pragmatic approach is to monitor your machine running your test with first one, then five users and extrapolate from there.

There are some steps that we take to minimise the WebDriver footprint:

• Run the browser in headless mode.
• If the browser type is not critical, use the one that is the most efficient for the site.
• Keep your scripts simple. There is no need to have an elaborate framework.

Tooling is, as always, a matter of budgets and personal choice with budget normally being the dominant factor. The tool should allow you to utilise your Selenium scripts and still give you the transaction detail that is required (e.g. time script started – time script ended is not good enough).

The tool must be capable of providing transaction response times correlated to the server and network monitored statistics collated during test executions to provide clear and informative reporting. Correlating such statistics manually is laborious and error prone.

We have experience of all major test tools and can quickly evaluate which is best for your budget whilst being capable of providing the level of transaction detail required. All enquiries are welcome.