On this page:
On this page:
Browser Synthetic allows you to use scripts, written in Python using the Python bindings for Selenium, to create scheduled tests that can mimic end-user actions in remote browsers in supported locations. You can use synthetic scripts to test performance, features, end-user flows, and the end-user experience.
For example, your synthetic script might do the following:
- Visit your website.
- Search for products.
- Add items to a shopping cart.
- Check out the shopping cart.
- Enter payment details.
- Complete the purchase.
Benefits of Using Synthetic Scripts
Using synthetic scripts, you can:
- find broken user flows
- develop and improve user flows
- improve the performance of your site by finding where response times in your web applications are slow
- test new features
How Scripts Are Run
Understanding how scripts are added, run, and results are returned will deepen your understanding of the end-to-end flow and also help you visualize how scripts are run in isolation from agents.
The entire process can be simplified into the following steps:
- You add your script to a synthetic job in the Controller UI.
- The synthetic job is transmitted to the Synthetic servers, where it is scheduled to be run.
- When the synthetic job is next in the queue:
- A Docker container is created.
- The Docker container communicates with agents in selected regions.
- The script is run within the container.
- The script commands are run on a browser within the agent.
- After the script finishes running, the agent collects browser metrics and sends them to the Controller UI.
- The Controller UI receives and displays the metrics from your synthetic job.
Where Scripts Run
Browser Synthetic provides agents in locations around the world. This allows you to run scripts simulating real user workflows in the same network conditions as a user in the same region. For security reasons, scripts are not run within the agent, but within a separate Docker container located in the cloud. Isolating the agents and scripts guarantees the safety of the data handled by the scripts and has no effect on the performance of the agent.
Before Writing Your Synthetic Script
Your synthetic script simulates end-user interactions, so you'll need to understand your web application.
We recommend that you know the following about your application. Think of it as a checklist.
Locations in your application where users interact with the page, such as clicking on buttons, links, or entering text in text fields.
CSS selectors and XPath statements to select the HTML elements that users interact with.
The structure of your application. For example, if it’s a web application, you should know the DOM structure.
What pages are dynamically and statically loaded.
- Which elements of a page are loaded and visible.
Get Started Scripting
For a good introduction to scripting, we recommend reading Getting Started in the Selenium Python Bindings documentation. When you are ready to write synthetic scripts, you should be aware that although Browser Synthetic can run unmodified Python scripts, there are few differences:
The driver initialization code can be removed because the variable
driveris automatically created and initialized with the browser selected in the Script creation UI. Thus, the example code below that initializes a driver would be replaced by our logic that then returns the variable
driveras a singleton.
If your script initializes a driver, it is okay to keep it: Synthetic will just ignore your initialized driver and instead return the driver it automatically created.
Only one driver can be run within a Synthetic session. Any attempt at creating new drivers will return the automatically instantiated driver (a singleton).
- Scripts interacting with multiple windows will work; however, the session results will merge the results for all windows into one waterfall.
Add Synthetic Scripts to Jobs
You add your scripts to synthetic jobs. When you create a new synthetic job, the New Job dialog will open. Select Run a script and cut and paste your script into the text field as shown below.
Understand Script Results
You can determine whether your script executed successful or unsuccessful by referring to Session State.
Observing the following will prevent issues and improve your scripts:
- Use implicit wait with caution:
- When looking up elements, if the element is not yet in the DOM, implicit wait retries until the set timeout expires. This can be quite useful, but in certain cases can produce misleading or incorrect results. For example, an element might be present in the DOM, but not visible, or not clickable. Implicit wait only detects whether the element is present.
- If you are searching just as the DOM changes, your selector might match an element which is in the process of being replaced. So use it, but with care.
- User actions on the wrong elements can fail silently. For example, clicking on the wrong DOM element might simply do nothing at the moment, but could lead the script to fail at a later step.
- Selectors break all the time. Long hierarchical selectors break more easily than shorter ones. Whenever possible use unique IDs instead, and if you are using selectors, use ones that are as short as possible. This reduces script maintenance over time.
- Don't submit forms using
.submit(). Click on the user-visible element instead, or send a Return key—whatever your user actually does. You want to test the form in a way that mirrors as closely as possible what your users do. If you don't, your page may be broken in a way that significantly impacts the user but that your test will not detect.
IEDriveris slow: use long timeouts with Internet Explorer.
- Pay attention to element visibility. The specification is complex and the results are not always what users expect. See the WebDriver specification for more information.
window.prompt are fully supported.
Multiple windows, as in, multiple HTML documents loading either in different tabs or windows, are not fully supported because although you can write a script to handle multiple windows, you will not be able to view the waterfall or the resources for each browser window. This is because the waterfall view of the session only assumes there is one page that combines the resources and the waterfall timing metrics for the multiple browser windows.
Useful Scripting Tools
Selenium Builder is a Firefox add-on that helps you create Selenium scripts by recording your actions. The resulting script will work with Browser Synthetic, but as with most auto-generated code, expect to make manual changes to improve it.
We also recommend the Chrome application WebDriver Scripting Assistant, which will help identify an element’s CSS selector to drive your scripts.