Intro to Monitoring Synthetic Web Transactions

Posted by on December 16th, 2015
January 9th, 2017

In essence, a Web Transaction test is a series of Page Load tests interspersed with synthetic user interactions like typing in fields and clicking buttons. These interactions are executed on Cloud or Enterprise Agents and are controlled through a Selenium script that must be provided during test creation. Transaction tests allow you to see how individual objects load across multiple pages or interactions, and can ultimately help you reproduce and better understand actual user experiences. In this post, we’ll talk about common uses of Transaction tests, general tips for working with scripts and some examples specific to running Transaction tests in the ThousandEyes app.

Why Use Transaction Tests?

There are many ways in which Transaction tests can help you understand website performance. Common use cases include:

  • Measure load scenarios: For example, measure how long it takes to return the results of a particular search, or observe site performance for a site behind form-based authentication.
  • Test specific functionality: Make sure that site functionalities, like search or a shopping cart, work as expected.
  • Before and after events: See how changes in your site’s code or other events affect user experience.
  • Benchmark competitors: Compare how much time a transaction takes on your site and comparable sites.
  • Optimize site performance: See all objects in the order they’re loaded and each of their load times to optimize how your site executes transactions.

Most commonly, Transaction tests are used to simulate transactions that users frequently execute, like logging in to an account or performing a search. These tests give visibility into how users experience your site and can provide web developers information critical to optimizing web performance. Monitoring web transactions can be helpful for a variety of enterprises, including customers who want to monitor internal applications like customer support apps, and SaaS and e-commerce companies—and their customers—who need to ensure that their often complex web pages are loading as expected.

In this post, we’ll walk through how to get the ThousandEyes Recorder Chrome extension and Web Transaction tests running with an example from Salesforce.

Using the ThousandEyes Recorder

To obtain the transaction script needed to set up a test, you can either write your own Selenium script or use the ThousandEyes Recorder to record the transaction you want to measure. To use the Recorder, first install the ThousandEyes Recorder extension in your Chrome browser.

Now you can start recording transactions. First open the ThousandEyes Recorder by clicking the ThousandEyes icon in the top right corner of your Chrome browser. Simply click the “Record” button and perform the transaction you’d like to measure. As you perform the actions in the browser, you’ll see the Recorder window populate with the Selenium scripts that will replicate your actions on the agent.

Figure-1
Figure 1: As you perform actions, you’ll see the Recorder window populate with the corresponding Selenium scripts.

Click the wrench icon and select ‘Export to TE…’, which will automatically open an ‘Add New Test’ page in the ThousandEyes application with your transaction script imported. Transaction scripts imported from the Recorder will often need to be revised. Because your Transaction test will ultimately need to run within the ThousandEyes app, we recommend testing and troubleshooting your script in the app rather than the Recorder. Consult our related Knowledge Base article to see the list of all supported Selenium commands.

Working with Transaction Scripts

Let’s jump into our transaction script. It performs the following actions in our Salesforce account:

  1. Log in
  2. Access the dashboard, ‘Trials Created Daily’
  3. Go to the reports view and access the report, ‘ACV Total Opportunities’
  4. Log out

Below, we’ll go into general tips and specific examples for cleaning up transaction scripts. To put these examples in context, view the entire transaction script generated by the ThousandEyes Recorder, side by side with our revisions.

1. Check that an element is present before performing an action on it. For example, during the login process, the Recorder may not return a waitForCondition script before clicking on the Login button. You’ll need to insert a wait condition to make sure that the agent does not click the button before it’s even present on the page.

Command Target Value
Recorder
click //*[@id=”Login”]
Revised waitForCondition selenium.isElementPresent(‘//*[@id=”Login”]’) 30000
click //*[@id=”Login”]

2. Use XPath syntax where possible to statically locate and define the element. This will reduce the likelihood of your transactions breaking when the page changes. There are a few ways to get the XPath syntax, including the following two:

  • In Chrome, right click on the element and select ‘Inspect.’ This will open a console with the element on the HTML page highlighted. Right click on that element and select ‘Copy Xpath.’
    Figure-2
    Figure 2: Use the Console in Google Chrome to find the XPath syntax for an element.
  • Alternatively, in the ThousandEyes Recorder, click on the target in question. A dropdown will appear showing alternative ways to identify the element.
    Figure-3
    Figure 3: Click on the target in the ThousandEyes Recorder to choose an alternative identifier.

Below, see an example from our transaction script where we revised it to use XPath syntax that searches for the element, a Logout button, based on title.

Command Target Value
Recorder click link=Logout
Revised click //*[@title=”Logout”]

3. Remove unnecessary conditions. Sometimes recorder extensions will give you more conditions than necessary; for example, you may get a script that says to wait for a certain element to be present even though you don’t perform any action on it. Make sure to delete any of these extraneous scripts. Below, 16 wait conditions were replaced by just the one condition that was necessary to check for the element acted upon in the next step.

Command Target Value
Recorder waitForCondition selenium.isElementPresent(‘id=ext-comp-1011’) 30000
waitForCondition selenium.isElementPresent(‘id=ext-comp-1012’) 30000
waitForCondition selenium.isElementPresent(‘id=ext-gen63’) 30000
Revised waitForCondition selenium.isElementPresent(‘//span[text()=”ACV Total Opportunities”]’) 30000

4. Use readable text identifiers rather than numerical IDs where possible in order to make scripts more intelligible for future debugs. If using a readable ID is not possible, make a note in the name of the step as a reminder of what the target is. Below, we changed an unreadable numerical ID to one that identified the element based on its textual name, “ACV Total Opportunities.”

Command Target Value
Recorder click css=#00OE00000022Ms2_NAME > div.nameFieldContainer.descrContainer > a > span
Revised click //span[text()=”ACV Total Opportunities”]

5. Beware of changing IDs. Depending on the page, element IDs may change if their order on the page changes, if the page is refreshed, or for a variety of other reasons. If possible, get an understanding of whether and how IDs behave by making changes on the page such as adding elements. Avoid breaking tests as much as possible by identifying the element using a unique attribute that is unlikely to change.

6. Change timeout values if needed. For each wait condition, you must choose a timeout value, which is the maximum time for the condition to be evaluated as true. If the condition is true before this maximum has been reached, the agent will move on to the next step immediately. The Recorder sets a default timeout value of 30,000 ms, or 30 seconds. If this is inappropriate for what you’re measuring—for example, if you’re testing to a remote location that generally has long load times—make sure to adjust the timeout value so you don’t get false failures in your test results.

When defining your script in the test configuration settings, you can set the start and end options of the test based on the period you want to record. For example, if you’re only interested in measuring how long it takes for the site to return a value after submitting a request, set the start at the time when the submit button is clicked, and set the end when the presence of a known element on the page has been validated. If you want to compare cached and uncached results, simply repeat those steps in the script.

Some services also require authentication of your device before allowing access. In this case, you’ll need to whitelist the IP addresses of the Cloud and Enterprise Agents you choose to test with. For instructions on how to do this with Salesforce, see the following Knowledge Base article, Web Transaction Tests for Salesforce.com.

Viewing Test Results

Once your test has been set up, navigate to your test results under Views. A web transaction test returns two metrics: completion percentage and transaction time.

Figure-4
Figure 4: Web Transaction test view showing observed transaction time.

In addition, detailed waterfall information is returned for each page visited during the transaction.

Figure-5
Figure 5: In the waterfall view, see total load times and their breakdowns for each object.

When monitoring transaction tests, you’ll want to watch for dips in completion percentage, spikes in transaction time, or results that show one or more agents out of sync with the rest of the agents. When Transaction tests fail, there is an option to view the screenshot at the time of failure under the ‘Map’ tab. If you also want to review both the request and response headers for each request found in the waterfall, check ‘Show HTTP headers in waterfalls’ under Advanced Settings.

Figure-6
Figure 6: View the screenshot taken at the time of failure to understand why the Transaction test failed.

Due to the dynamic nature of page load tests and because each attempt to access the site may result in accessing a different set of pages or sites, ThousandEyes does not currently support including network data for transaction tests. If you’re interested in measuring network performance, we recommend setting up an additional HTTP Server test to the same target.

Additional Resources

For more on running Web Transaction tests, see the resources below.

Writing transaction scripts can be tricky. In general, try to get started using the script provided by a recorder as a base; from there, use the above tips and trial and error to resolve any failures. If possible, contact the relevant web development team to see if there will be any web page changes that may affect your tests. If at any point you get stuck, feel free to contact Customer Success by clicking the help menu in the upper right corner.

Processing...
  • Jim

    Great article!!