RealBrowser testing

First RealBrowser project

Design

To get started with your first RealBrowser project, launch a browser process through an OpenBrowser action. Then, use a Navigate action to go to a specified URL.

Next, depending on your business use case, you can use a mix of the following:

  • Browser actions (clicks, types, presses, scrolls, etc...)

  • Browser assertions (waits, reads, etc...)

  • Utilities (loops, branches, think times, etc...)

At the end of your user path, put a CloseBrowser action to close the browser instance.

For OpenBrowser and CloseBrowser actions, you have two general options :

  • Put OpenBrowser in the Init folder and CloseBrowser in the End folder of your user path.

    For each Virtual User started, the same browser instance is reused for each iteration of that VU. This means that eventual cookies and localStorage will be persisted and might impact following iterations.

  • Put OpenBrowser at the beginning of the Actions folder, and CloseBrowser at the end of the Actions folder.

    Each iteration closes the browser and reopens a new instance. This allows the VU to run in a cleaner and more stable context.

Choose the option you prefer based on your use cases. However, the second option needs to be privileged.

Note: When recording a browser session, the OpenBrowser and CloseBrowser placement are automatically managed.

Scenario

A good RealBrowser scenario will be a RampUP scenario.

Indeed the OpenBrowser action takes a lot of resources, it is important to let time between the execution these actions, it is why the RampUP scenario is the most effective type of scenario for RealBrowser.

We recommend to let at least 20 seconds between each Virtual User start.

Selector engines

Most RealBrowser actions have a selector parameter that targets a specific dom element.

Different selector engines are supported:

CSS

  • Without prefix, or with the prefix css=
XPath

  • With the prefix xpath=

  • Does not pierce shadow dom
Text

  • With the prefix text=
React

  • With the prefix _react=

  • This selector engine is experimental
Vue

  • With the prefix _vue=

  • This selector engine is experimental

  • Works with Vue2 and above

  • Only works against unminified application builds

Note: CSS and Text engines pierce the Shadow DOM by default.

Infrastructure sizing

Infrastructure sizing varies and depends on the scenario design, targeted application consumption, and the amount of hardware resources available.

The Load Generators need to manipulate one browser instance for each VU, which consumes many additional resources. This results in a large gap between the number of VUs you can run in classic protocol mode and in browser mode.

The sizing process is about finding the right balance between RAM and CPU. CPU is the resource that can cause throttling in iterations, and it needs increased think times to mitigate. This increased think time causes a few seconds of reading the page between each action when you mimic the behavior of a real user.

The general estimate for low to medium resource-consuming target app is the following:

  • 8 VUs per 1GB of RAM

  • 2 Actions per Second per CPU

Caution: The following estimations can greatly vary depending on your target application and/or environment. It is up to you to perform a few "sizing" tests and find the ideal ratio of VUs per CPU for your situation.

Example

You have 1 Load Generator with 32 GB of RAM and 8 CPU and you have measured that your typical VU executes 3 Actions per Second.

  • Maximum VUs allowed respective to the RAM (before out of memory errors)

    • 8 VUs per 1GB of RAM * 32GB = 256 VUs

  • Maximum VUs allowed respective to the CPU (before throttling and slowing down of your user path)

    • 2 Actions per Second per CPU * 8 CPU = 16 Actions per Second

    • 16 Actions per Second (max) / 3 Actions per Second (per VU) = 5.3 VUs

The CPU is a limiting factor. But this is where think time comes into play. If think times are inserted into your user path so that each VU executes 0.2 Actions per Second instead of 3, the result becomes:

  • Maximum VUs allowed respective to the CPU (before throttling and slowing down of your user path)

    • 2 Actions per Second per CPU * 8 CPU = 16 Actions per Second

    • 16 Actions per Second (max) / 0.2 Actions per Second (per VU) = 80VUs

This means you can expect around 80VUs for each Load Generator of this size available to you.

These are theoretical values and should only help you estimate a first sizing of your infrastructure.

Note: It is assumed you have no other processes running on your LG that might take up resources on the side.

Authentication in RealBrowser

RealBrowser works with two authentication methods:

  • In-page authentications with a username and password, or another type of a login form embedded directly in the page. This includes technologies such as SAML. In this case you don't need further configurations as the user interaction at the page level allows the recorder to pick up the authentication steps.

  • HTTP authentications with prompts for a username and password at the browser level. This includes technologies such as BasicAuth, NTLM, and Kerberos. To enable this type of authentication, check out Authentication in RealBrowser.

  • Client certificate authentication asks for certificate selection at the browser level. To enable this type of authentication, check out how to use client certificates with RealBrowser.

Note: If you want to avoid the authentication step, inject a cookie or modify the localStorage property by using the EvaluateJavaScript action.

Use the Read action

The Read action is useful for extracting values from the page into variables and use them as conditional logic in your user path.

A good example of that is when targeting an application that contains "A/B testing", in other words some elements are displayed on the page in a certain way, and in another way the other half of the time.

Here is a sample user path that can address this kind of use case.

  • We have a Read action that verifies the presence of an element based on its selector, and store its text (or attribute) value into a variable, here we check the presence of some button in a popup.

  • Then we have an Condition that checks the variable has correctly been initialized.

  • If that variable exists, we enter the Then container, which will let us click on a "Dismiss popup" button.

  • Then we resume with the following actions.

Note: If the Read action is not enough, you can use the EvaluateJavaScript to retrieve more advanced page data from the page into variables.

Add MouseOver actions in a user path

A MouseOver action is needed every time some element display state depends on hovering that element or another element.

One example is a menu that displays his options in a div element on hover the mouse over the parent element. In this case, if we want to click in a menu option, a MouseOver action will be needed.

The MouseOver action positions the mouse over the specified coordinates or element location. It also scrolls the window when that position is out of the current viewport.

The MouseOver action has two main parameters :

  • Coordinates: Coordinates of the mouse, relative to the selector if specified, absolute otherwise. If no coordinates are specified with selector, the mouse will be placed at the middle of the element.

  • Selector: The selector is a string that point to the elements in the page.

Both are optional but at least one of the two must be specified.

There are three possible use cases:

  • Absolute positioning: Only coordinates parameter is specified.

  • Selector positioning: Only selector parameter is specified.

  • Relative to selector positioning: Both coordinates and selector parameters are specified. Then coordinates are relative to element identified by selector.

Blocking specific resources

Sometimes it can be useful to block some resources: if the target app uses an API with quotas, you don't want to consume all the quota doing a load test.

To do so, you can add a parameter blockRoute in the OpenBrowser action:

Advanced: EvaluateJS

The EvaluateJS action allows you to execute JavaScript code on the current page and retrieve the corresponding result.

It can be useful in different cases. For example, you can retrieve information that are not displayed (or not even in the dom).

Let's imagine that on a web page of a shopping site, a purchasedItems variable (instead a "basket" object) contains the list of purchased items. If the number of purchased items is not visible on the page, you can retrieve it as follows:

The result will be stored in the variable NumberOfPurchasedItem, therefore, you can use it on next actions:

Simulate returning users

By default, most recordings and user paths that you set up follow a brand-new user's path during each run. . This keeps the browser state the same during each test, which works great for most user scenarios.

However, if you’re working on a more advanced user path, you might want to mimic a returning user with browser storage or cookies from a previous run. For example, you can test login steps on the first iteration and then use cookies to skip logging in during future test runs.

To simulate returning users, you’ll need to build in conditional actions and behaviors based on the application's state. To do this, wrap your login step in an IF...ELSE NeoLoad action block. The IF part should check if the user is already logged in or not.