Selenium helps you test web applications by simulating how a real user would interact with your application using real browsers. The WebDriver API has language bindings and implementations to help drive different browsers.

Combine Selenium with WebDriver on Tricentis Flood and you get distributed load testing across the globe.

On Flood, you can launch browsers using ChromeDriver or FirefoxDriver that run in isolated Docker containers.

Since these containers run full browsers, CPU overheads are naturally higher so we recommend a maximum of 5 browsers per node for on demand customers. For hosted customers who have the ability to launch larger grid nodes, the maximum recommended is 50 browsers per node.

The benefit of running full browser automation for load testing comes from driving the browser itself. Being able to run existing browser based automation suites as a control sample in conjunction with more traditional load testing tools and techniques is valuable for the increased fidelity of the simulation. However there's nothing stopping you from running larger grids with multiple nodes to increase the level of concurrency if you want to run Selenium only load tests.


For your tests to work on Flood, you'll need to import our FloodAgent. This is a custom plugin that lets us pull together reporting information for your flood tests. The critical functions your script needs to call are .started() and .finished() for test boundaries. Inside that you can make calls to .passed_transaction(WebDriver driver, String label, Integer responseCode) or .failed_transaction(WebDriver driver, String label, Integer responseCode).

When your test is running we'll pass in the relevant WEBDRIVER_HOST and WEBDRIVER_PORT environment variables for your test to connect to.

Have a look at the following example test plan.

import java.util.concurrent.TimeUnit;

import org.openqa.selenium.By;
import org.openqa.selenium.WebDriver;
import org.openqa.selenium.WebElement;
import org.openqa.selenium.WebDriverException;

import org.openqa.selenium.JavascriptExecutor;

import org.openqa.selenium.remote.Augmenter;
import org.openqa.selenium.remote.DesiredCapabilities;
import org.openqa.selenium.remote.RemoteWebDriver;


import io.flood.selenium.FloodSump;

public class SeleniumExample  {
  public static void main(String[] args) throws Exception {
    int iterations = 0;

    // Create a new instance of the html unit driver
    // Notice that the remainder of the code relies on the interface,
    // not the implementation.
    WebDriver driver = new RemoteWebDriver(new URL("http://" + System.getenv("WEBDRIVER_HOST") + ":" + System.getenv("WEBDRIVER_PORT") + "/wd/hub"),;
    JavascriptExecutor js = (JavascriptExecutor)driver;

    // Create a new instance of the Flood agent
    FloodSump flood = new FloodSump();

    // Inform Flood the test has started

    // It's up to you to control test duration / iterations programatically.
    while( iterations < 5 ) {
      try {
        System.out.println("Starting iteration " +  String.valueOf(iterations));

        driver.manage().timeouts().implicitlyWait(5, TimeUnit.SECONDS);

        // And now use this to visit the target site

        // Log a passed transaction in Flood


        // Log a passed transaction with custom label
        Select ageDropDown = new Select(driver.findElement("challenger_age")));

        flood.passed_transaction(driver, "Challenge Step 2");

        // Log a failed transaction


        // Good idea to introduce some form of pacing / think time into your scripts
      } catch (WebDriverException e) {
        String[] lines = e.getMessage().split("\\r?\\n");
        System.err.println("Webdriver exception: " + lines[0]);
      } catch(InterruptedException e) {
        String[] lines = e.getMessage().split("\\r?\\n");
        System.err.println("Browser terminated early: " + lines[0]);
      } catch(Exception e) {
        String[] lines = e.getMessage().split("\\r?\\n");
        System.err.println("Other exception: " + lines[0]);
      } finally {


    // Inform Flood that the test has finished


We use Docker containers that run standalone Selenium Node images provided by the Selenium project for Chrome and Firefox. Inside those our Java plugin makes calls to the same internal reporting API using Elastic that all of our load test runners use. The plugin itself is using the JavascriptExecutor within WebDriver to parse the Navigation Timing API, something along the lines of:

JavascriptExecutor js = (JavascriptExecutor)driver;

long loadEventEnd = (Long)js.executeScript("return window.performance.timing.loadEventEnd;");  
long navigationStart = (Long)js.executeScript("return window.performance.timing.navigationStart;");  
long responseStart = (Long)js.executeScript("return window.performance.timing.responseStart;");  
long connectStart = (Long)js.executeScript("return window.performance.timing.connectStart;");  

Beyond that, results are formatted in the same fashion as all of our load test reports. Importantly we're not relying on any proxies in between your browser and the target site so as to minimise impact on your test results as much as possible.


You can find more examples including how to get set up for testing and development locally prior to pushing to Flood here.

Did this answer your question?