Categories: TUTORIALS LOAD TESTING SELENIUM HIGHLIGHTS

Load testing with Selenium

In this short tutorial, we show how existing Selenium automation tests can be turned into full-fledged load tests in just a few minutes, by leveraging the STEP platform.

Prerequisite

Install step

To follow this tutorial you’ll need a step instance. You can either setup an on-premise instance while following the Quick setup or get a SaaS instance up and running in minutes. For most users the SaaS option is recommended.

Install basics if needed

Install ChromeDriver (optional)

The following software is recommended to follow the local and on-premise parts of this tutorial. You can skip all steps requiring ChromeDriver and still finish the tutorial if you focus on the SaaS solution only.

The sample project

We prepared a small project that will be used throughout this tutorial. The project uses Selenium to automate interactions with a (demo) online shop: OpenCart is an Open-Source Shopping solution, and exense hosts a demo instance specifically to be used as a System-Under-Test (SUT) for load test scenarios.

Get the code

The project is available on github; to clone it using git:

git clone https://github.com/exense/demo-opencart-selenium.git

Run tests locally (optional: requires ChromeDriver)

To see the interactions that are performed, run the JUnit tests:

cd demo-opencart-selenium

# If ChromeDriver is installed system-wide and added to the path:
mvn clean compile test

# Otherwise, explicitly specify the ChromeDriver path:
mvn clean compile test -Dwebdriver.chrome.driver=c:/tools/chromedriver/chromedriver.exe

If you want to skip this step feel free to watch this video of what running the tests should look like:

The test cases navigate through the “Desktop” and “Components” categories of the website, as defined in the unit tests.

Check the source code

Take a moment to look at the sample project code – we tried to keep it as simple and straightforward as possible.

You’ll notice that the test class (SiteTest.java) is really just a standard JUnit class, with only two changes:

  • First, the individual test methods carry an additional @step.handlers.javahandler.Keyword annotation. These annotations make the respective methods available as Keywords within step.
  • Second, the test class itself extends the class step.handlers.javahandler.AbstractKeyword. This is a technical requirement which ensures that step can actually use the Keyword methods.

These modifications are sufficient for the provided functionality to be used for load tests in the step framework.

Create a Keyword Package

To package the functionality in a jar file, run:

mvn clean package -DskipTests

This command creates a jar file, normally named demo-opencart-selenium-0.0.0.jar, in the target folder of the project directory. This is the file that we will use in the subsequent steps.

Switch to your STEP instance

If you have access to an existing STEP instance (on-premise or cloud), access it and log in. Remember that for on-premise setup chrome and chromedriver must be available on the step’s agents.

Otherwise, you can get a cloud instance up and running in minutes on stepcloud.ch!

Import the keyword package

In the step controller, navigate to Menu > Keyword Packages:

Click on the New Keyword Package button, then proceed to select the jar file:

Verify that the jar file contains the expected keywords, then import it:

Define the load test

Now that all the basics are established, we can define an actual load test.

This is done by creating a new plan in step. In this case, we’ll use the TestScenario template.

Test Scenario

The scenario is created by selecting the Plans tab, then clicking on New Plan, and providing the required information:

Thread Groups

Once the plan for the scenario is established, the visual editor can be used to add two ThreadGroup children to the plan:

Thread Groups Content

In each thread group, the action to be performed is added by selecting it from the list of Keywords:

Thread Groups Parameters

Once the structure ot the test scenario is established, we return to the ThreadGroup nodes to configure their parameters:

  1. We want each ThreadGroup to run 5 threads in parallel.
  2. The interactions within each thread should be spaced out by 20 seconds.
  3. We do not want a limit on the number of iterations per thread: the corresponding input box must be empty.
  4. The ThreadGroup should terminate after a maximum of 10 minutes (600000 ms).

We only show the configuration of one ThreadGroup above; please make sure that the other one is configured with the same parameters.

Run the load test

To actually run the load test, simply click the “run” button:

NOTE: As each ThreadGroup was configured to use 5 threads, and there are two ThreadGroups running in parallel, the total number of parallel threads is 10. This, in turn, means that 10 agents must be available concurrently for this scenario to run successfully.

If you have less than 10 agents in your cluster, the execution will make use of the available agents, but parts of the plan will fail because the required resources cannot be allocated.

To set the needed number of agents follow the installation guide for step on-premise Installing agents or go to the cluster details in the step Portal and set the browser-java agents to 10 for step SaaS.

Evaluate the results

You can check the status of your executions on the Executions tab:

… and you can click on individual executions to get a detailed view. This functionality is available at any time (i.e., also for executions which are currently running).

The screenshot below shows the status for a (successfully) finished execution:

By selecting the “Performance” or “Performance (Beta)” tabs, you can explore detailed performance metrics of the execution: