Creating a Test Script

Before you can schedule a load test, you must first create a test script. These scripts are what gets played back during a load test and generally simulate the interactions done by a real user on your website. There are two types of scripts you can create inside of BrowserMob:

• Real Browser User scripts – these scripts use Selenium to automate a real web browsers
• Virtual User scripts – these scripts simulate just the HTTP traffic seen by a browser, but don’t run real browsers themselves

Both Real Browser Users (RBUs) and Virtual Users (VUs) have there place and allow you to trade-off between realism/fidelity and price. Over time you will likely find that both have their places in your testing strategy.

When at the “Manage Scripts” page, you are given four options:

• Create a basic browser script (RBU)
• Convert an RBU script to a virtual user script (VU)
• Upload an advanced Selenium browser script (RBU)
• Create a script by hand (RBU or VU)

Each of these provides a slightly different way to create a BrowserMob script, ranging from easiest (basic browser script) to most difficult (create a script by hand). All scripts are composed of a flexible JavaScript programming language and API, but you don’t have to know JavaScript or the BrowserMob API to get started.

Create a Basic Browser Script

This is the recommended starting place for beginners. It requires no scripting knowledge and makes it very easy to create browser-based scripts (RBUs). Simply provide one or more URLs you wish the browsers to visit and an optional “validation text”. The validation text is used to check if the resulting page contains that text.

The script will automatically fail if the validation text for any URL is not found. It will also be configured to automatically fail if any of the pages take more than 30 seconds to load. Why 30 seconds? That’s the default timeout we’ve chosen because just about any normal user will have given up on your site by then!

Validating Scripts

Before the script can be used in a load test, BrowserMob must first validate it. We do this by playing back the script one time outside of any load test. If the script passes, then we assume it’s “valid”. If the script fails, it’ll be marked as “invalid” and you’ll need to fix the problem before you can schedule a test with that script.

Regardless of the validation status, you can check out the validation log, which contains important information, such as a list of all the objects downloaded by the script, a screenshot of the browser (if it’s an RBU script), and any additionall logging information embedded in the script itself (see the BrowserMob API  documentation for more information).

It is important to look through this validation log even if your test passes. For example, you’ll want to ensure that the script is not making any HTTP requests from sites or 3rd-party providers that you weren’t expecting, such as images hosted on another site you don’t wish to load test or Google Analytics calls that will artificially inflate your site’s traffic during a load test.

If the script is invalid, click the script name to see the underlying source. From there, you can edit the script and save the changes. The script will automatically be re-validated and you’ll see the results within seconds.

Convert an RBU Script to a VU Script

If you wish to create a Virtual User (VU) script, the easiest way to do this is to convert an existing RBU script to a VU script. What this will do is play back the RBU script and, in real time, capture all the HTTP traffic it generates. Once that traffic has been identified, a new VU script is automatically created that makes all the same HTTP GET and POST calls.

This conversion process will not copy over any of the logic in the original RBU script, such as text validations, waitFor conditions, pauses, etc. It simply records the HTTP traffic and builds a new script VU script for you.

For simple scripts (such as those created from the “basic browser” interface, documented previously), this is perfectly fine. However, if you need more advanced logic and error checking, you may need to edit the script by hand after you’ve made the initial conversion.

Also keep in mind that the HTTP traffic generated in the VU script is based on the content seen at the time the original RBU script was converted to the new VU script. If the underlying pages have changed and, for example, now reference new images and stylesheets, you may wish to recovert the script before scheduling a load test. That is because the original VU script probably doesn’t reference the new files.

Upload a Selenium Browser Script

For more advanced browser-based load tests, you may wish to record a script using the Selenium IDE tool. See our documentation on how to get started with recording scripts in Selenium IDE here.

Once you’ve saved a Selenium script to your desktop, you can upload it to BrowserMob. BrowserMob will automatically convert the Selenium script to an RBU script that uses our special API that is designed for performance and load testing.

When uploading a Selenium script, we strongly recommend that the first command be an “open” command and that the URL be an absolute URL (ie: starts with http:// or https://). This will ensure that BrowserMob knows exactly where to begin playing back the script.

Create a Script by Hand

For advanced users who are comfortable with the BrowserMob API, we allow you to create scripts by hand. This allows you to write JavaScript that directly controls a real browser or simulated HTTP requests. Note that if your script calls browserMob.openBrowser() it is assumed to be an RBU script, otherwise it is assumed to be a VU script.

The BrowserMob Scripting Language and API

Regardless of how you create your script, all BrowserMob test scripts are ultimately written in the BrowserMob scripting language and use a special API designed for performance and load testing. The programming language itself is standard JavaScript and the full documented API can be found at:

http://static.browsermob.com/api

Note that scripts initially only have access to a “browserMob” object, which maps to the BrowserMob class in the API documentation. The script must make calls to beginTransaction(), beginStep(), and other critical functions before it is considered a fully working script.

The easiest way to get up to speed on this scripting language is to build a few scripts using Selenium and/or by converting an RBU script to a VU script. From there, view the script and make small changes to it. Alternatively, when you create a script by hand, a script template is provided that shows the common components of a BrowserMob script, making it easy to get started.

Error Reporting

BrowserMob scripts may have errors. In fact, when there is a large volume of RBUs or VUs hitting your site, your goal may to explicitely cause errors to happen. As such, it’s important to know how error reporting works.

In general, if your script throws an exception at any point during execution, it’s considered an error. When an error occurrs, the exception message is saved, the test is marked as a failure, and any “additional content” is saved and associated with the transaction results.

This “additional content” can be, if the script is an RBU script, a screenshot of the browser at the time of the failure. Or, if the script is a VU script, the response content of the last requested HTTP object (if there is content that was captured).

Some functions in the BrowserMob API automatically throw exceptions. For example, most of the Selenium commands will automatically throw an exception if a verification/assertion is false or if a particular command “times out” (ie: takes more than 30 seconds to complete).

But some functions will not throw exceptions and will require you to include error checking/validation in your script. For example, the HttpClient’s get() and post() methods will not throw any exceptions, regardless of any connection errors or HTTP return codes (ie: 500, 404, etc). Instead, your code must look at the returned object and then decide whether it should “throw” an exception.

Logging

Sometimes during development of a script it’s helpful to log information. This is usually expecially helpful while developing VU scripts. You can log any content that you think is relevant by calling the browserMob.log() function. Content logged here will be saved in the script’s validation log and can be reviewed there. However, during an actual load test, log calls will be ignored.

Tweet This Post 

No comments yet.