In this short tutorial, we show how to quickly implement a simple browser-based load test based on Cypress scripts in step.
This is a technical tutorial for people who are already familiar with Cypress and load testing in general.
To follow this tutorial you’ll need a step instance with the Cypress plugin enabled. You can either install an Enterprise Edition of step while following the Quick setup or get a SaaS instance up and running in minutes. For most users the SaaS option is recommended.
This tutorial also assumes that you’ve installed Cypress on your local machine. If not, please follow the installation guide of Cypress to install it.
To showcase the advantages of browser-based load-testing, and especially with Cypress, we will load-test a complete test case with many screens interactions. This is typically complex and error-prone to implement with a classical protocol-based load-testing approach.
Our first test case models a typical user visit in our online shop. We call it “TC01 Place order”:
an unregistered user navigates to the homepage
searches for an article
adds the article to the cart
checks out the cart
enter all the required information and place the order
For the sake of this tutorial we define the goal of our load test as follow: Simulate 10 concurrent visits.
Assuming that our test case represents a typical user visit, we can simulate this while running our test case with 20 virtual users in parallel.
As per target of this tutorial we use Cypress to automate our test case.
We have implemented a Cypress test and pushed its code to our step sample project on github. This tutorial assume that you’re already familiar with Cypress. We’re therefore not going into scripting details of Cypress. If you’re not familiar with Cypress we recommend to follow the good getting started guide of Cypress.
To clone our sample repo containing our Cypress project using git:
cypress run --headed
This should open a browser window and run the test case
Plan creation in step
Now that we have a running implementation of our test case we can define our load test plan.
In the simplest terms a Load Test Plan defines the test scenario to be executed and at which level of concurrency.
The Load Test Plan definition takes place in step.
Switch to your step instance
If you have access to an existing step instance (on-premise or SaaS) as described in the prerequisite, access it and log in.
Otherwise, you can get a SaaS instance up and running in minutes on stepcloud.ch !
Create the Keyword
In step a Plan consists of logical Controls and so-called Keywords that encapsulate the automation scripts. In its simplest form a Keyword can encapsulate an whole test case or workflow. For modular compositions of Plans, the use of more granular Keywords is however prefered in practice. For the sake of this tutorial we’ll define one single Keyword for our test case.
To create the Keyword for our test case:
Login to step
Navigate to Menu > Keywords.
Click on the New keyword button.
Enter a Name for your keyword. For instance: “Place an order in Opencart”
Select “Cypress” as “Type”
Enter your complete Cypress script as command. In this tutorial we’ll take the content of the test case “Opencart_TC01_PlaceOrder” defined in “step-samples/keywords/cypress/opencart/cypress/integration/opencart.spec.js” that we’ve previously executed locally:
cy.contains('Add to Cart').click()
cy.get('.pull-right > [type="checkbox"]').click()
cy.contains('Your order has been placed!')
Enter “https://opencart-prf.exense.ch" as “Base URL” of your Keyword. This is important. It wil be set by step as global cypress option before for the runner.
Create the Plan
Now that we have our Keyword defined, we can define our 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 one ThreadGroup children to the plan:
Thread Groups Content
In each thread group, we first add a “Session” control. This forces the creation of a new browser session (and thus a clear cache) at each ThreadGroup iteration. Without Session each ThreadGroup iteration would reuse the same Browser session which is not what we want to simulate.
Within the Session we add our unique Keyword “Place an order in Opencart”. Please not that we’ve decided to define on Keyword for the whole test case. In practice it often makes sense to split the test case in more granular Keywords. In that case we would simply add them in sequence within our Session:
Thread Groups Parameters
Once the structure ot the test scenario is established, we return to the ThreadGroup nodes to configure their parameters:
We want the ThreadGroup to run 10 threads in parallel.
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).
Run the load test
At this point your test is ready to be started. Before starting it you should however ensure that your step instance has enough Agents. In the SaaS you will need 1 Agent per Thread and thus 10 Agents in total.
To run the load test, simply click the “run” button:
Analyze the results
Once the execution started you will be redirected to the execution page.
By selecting the “Performance” or “Performance (Beta)” tabs, you can explore detailed performance
metrics of the execution:
There you’ll find all metrics relative to the transactions of your cypress scripts:
The total execution time of your Keyword: “Place an order in Opencart”
The series related to the different Cypress commands: “visit”, “contains”, etc. Please pay attention that the current version of the Cypress plugin also reports the command “request” and “then”. These 2 are generated by the plugin itself and can be ignored.