Web Performance Management FAQs

Vercara WPM uses native JavaScript to drive Selenium and WebDriver scripts. This means a full JavaScript environment is available to both of your scripts, giving you full control over what the browser executes on your website, web service, or API.

Vercara can provide professional services to get your monitor or load testing service up and running. Contact us for more information.

What do I need to get started with Selenium scripting?

Some very useful (but not necessary) tools for scripting include:

• Firebug (http://getfirebug.com/)
• Xpath Finder (https://addons.mozilla.org/en-us/firefox/addon/xpath-finder/)
• Web Performance Management Local Validation Service
• An IDE or text editor

Every time you attempt to validate a Real browser user script, a screenshot is captured (BASIC scripts do not generate screenshots) and the validation results are updated. To see the results, simply click the “View Validation Results” link from the script editor page. If there was a problem executing the script, or validation failed, a message will appear at the top of the results dialog along with the line number on which the error occurred. Use this information to debug your script and then retry validation.

You can add additional logging anywhere in your script using “log (‘message’)” These messages will show up at the bottom of the validation results dialog. Tip: log messages are useful for tracking variables and unique values as well as key execution points.

In order to convert a script from RBU to BASIC, the RBU script must first be validated using either the online or local validator tool. Once validated, open the script in the Webmetrics-WPM online script editor and click “Generate Basic Script.” This will create a script that makes all the same requests as the validated RBU but replays as simple HTTP GET/POST requests instead of using a real browser. Converted scripts can be used for both website monitoring and load testing.

The validation process allows a maximum execution time of two minutes. However, there is no time limit on script execution in load tests. If you are attempting to validate a long-running script that is intended for load tests only, there are a couple of options available. The first is to look at the amount of pause time in the script. If the script is using long pause times, the “isValdation()” method can be used to reduce the amount of time spent paused during validation. Here is an example:

if(test.isValidation()){
//Pause for 2 seconds in validation
test.pause(2000); } 
else{ 
//Pause for 20 seconds during load test 
test.pause(20000); 
}

If, even after using “isValidation()” to reduce pause time, you’re still running past the two-minute limit, you will need to use the local-validation service. As with a load test, there is no time limit for script execution when using the local validator. Once you have verified the script works as expected on your local machine, upload the script and check the “Bypass Validation” option in the script editor. Finally, it’s advisable that you run a small load test to ensure the script behaves as expected.

BASIC scripts are built from the recorded HTTP traffic generated during the validation of the original RBU script. But as is often the case, the HTTP traffic might be different on every run of an RBU script (e.g. ads, ajax, etc.). BASIC scripts replay the same requests every time and expect the same response codes.

The most common error is the converted script expecting 3xx response codes, but seeing 200 instead. This is usually caused by ads, which were originally redirected to register a unique impression. When the converted script attempts to replay the same request, it is caught by the ad server as a duplicate, and the response is altered to prevent additional (false) ad impressions. The fix is as simple as removing the faulty requests or changing the expected response code to what was actually returned. For example:

c.get("http://example.com/ad?req=12345", 301);

Change to:

c.get("http://example.com/ad?req=12345", 200);

The second most common issue is content from third-party domains. The blacklist requests directive from the original RBU script will not be maintained in the Basic script. Our recommendation is to remove any third-party requests from the script. Here is an example of requests that would be removed:

c.get("https://connect.facebook.net/en_US/all.js", 200); 

c.get(https://ssl.google-analytics.com/ga.js", 200);