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.
This is a technical tutorial for people who are already familiar with development in general,
and Selenium automation in particular.
We therefore assume existing knowledge about the following topics and technologies:
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.
The following software is recommended to follow this tutorial, but not absolutely required.
You may need to skip some steps if you do not have the corresponding software installed.
To see the interactions that are performed, run the JUnit tests:
# 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
Note: Running the tests requires a local installation of Chrome and ChromeDriver,
and you may need to provide the correct ChromeDriver executable path if is not installed system-wide.
You can skip this step if you want; here’s a 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.
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.
The scenario is created by selecting the Plans tab, then clicking on New Plan, and providing the required information:
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:
We want each ThreadGroup to run 5 threads in parallel.
The interactions within each thread should be spaced out by 20 seconds.
We do not want a limit on the number of iterations per thread: the corresponding input box must be empty.
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.
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: