Planning a script
Before you record a script, identify the goals you want to accomplish. Here are some considerations:
What functionality needs to be tested?
- Define your requirements. Understand the goals and navigation patterns of your customers so you can design a script that matches their behavior. Or you might want to focus on common transactions where you believe your users are abandoning your site due to performance problems.
- Gather all information required for recording, e.g., user IDs and passwords.
What should the script flow look like?
A script needs to contain your end-to-end transaction and should ideally be less than 10 pages. Click the link below for tips on script flow.
- Familiarize yourself with the site and its menus and navigation. A list of pages and links to visit might work, or, if necessary, draw a flowchart of the steps the script will take.
- The entire business transaction you wish to monitor must be contained within a single script. You cannot concatenate several scripts to run end-to-end during provisioning. For example, if your transaction involves logging in to a site, adding items to a cart, entering payment details, and logging out, all these procedures must be part of a single script; you cannot create and run a separate script for each procedure.
- Use the simplest method to achieve your business goal. Remember that longer scripts mean more dependencies for actions down the line and higher performance times.
- We recommend scripts of 10 pages or less.
- If your website contains dynamic or synchronous content, plan where you want interactions to be recorded as new pages/actions (see also Initial Settings below).
How do you make sure the script is going to function properly?
- Before beginning the recording, walk through the business process in a browser to make sure there are no performance problems that would prevent the recorder (KITE/MITE/Keynote web recorder) from successfully recording and playing the script.
- Walking through the script flow before recording also helps you plan for completion events and validation in the post-recording phase.
Can this functionality be tested in the browser versions and device profiles supported in the recorders and agents?
In KITE, you record in Internet Explorer, with playback options in Firefox and Chrome for TxP, and any available user agent for ApP (select Settings in the Script Viewer pane > choose a user agent from the Browser drop-down list in the Script Properties Editor).
During a release, agents are updated on a rolling basis until all agents have the same versions of IE, Firefox, and Chrome. Current versions are:
- Internet Explorer 11
- Chrome 36
- Firefox 31
In MITE you can record on one device profile and play back on any other. However, playback works best when the recording and playback profiles have compatible browsers. So if you record on an Apple device profile, your script will work more accurately on another Apple device profile. Likewise, scripts recorded on a tablet profile play best on other tablet profiles. Plan also for platform (iOS, Android) compatibility, e.g., scripts captured on an Android profile are best played back on Android profiles.
Here are some recommended global settings before beginning recording:
For MWP scripts in MITE
Check Preferences > Settings :
- You might want to change your default Geolocation emulation for recording and Playback location of agent.
- You must also Enable virtual pages here if you want to create one in a script.
For TxP scripts in KITE
Make the following settings in Options > Settings >** Recording** >** Transaction Perspective** :
Set the default network inactivity timeout to 3000 milliseconds for use as a completion condition: Default Event Network Inactivity = 3000.
Set the default delay between consecutive steps of an action to 500 milliseconds; the timer begins immediately after execution: Default Step Delay = 500.
Set the default completion event timer to 5 seconds: Default Event Timeout = 5.
For ease of scripting, do not opt to create a new action each time dynamic content is loaded: Dynamic New Page = No . If part of a page reloads, you might not want it to be recorded as a new page—refer to your script plan for how you want your transaction to be structured logically for best results analysis.
We do not recommend setting KITE > IE Browser Mode (Internet Explorer compatibility for recording scripts) globally as this might be something you wish to adjust based on the test website. Without a global setting, KITE defaults to the version of Internet Explorer installed on your machine for recording scripts.
**For ApP scripts in KITE
Leave default settings as is; there are no completion conditions in ApP as scripts are run on emulated browsers.
Recording a script
- In KITE, a new action is created for every page you visit. Actions are composed of script steps for functions performed on the same page, e.g., entering credentials and clicking a link.
- In MITE, scripts are composed of pages, which are further divided into actions for functions performed on the same page.
Your script encapsulates an entire business transaction end-to-end, so try to use the shortest, most efficient path possible (see also tips on script flow above). Try to limit scripts to 10 pages or less in KITE. For MWP scripts, we collect heavy amounts of information per data point, so the shorter your transaction, the lower the risk of losing data points.
Record your script as a new visitor. After you click the Record button:
- In KITE, check Record as new visitor.
- In MITE, select Advanced Options > Clear local storage and database on this device. You can also edit a script after recording to clear local storage (see Other Settings below).
In MITE, select Advanced options to select a web server emulation location (Select a location ) for a particular script. You can also set this option globally (see Initial Settings).
Right after you begin recording, insert any steps to ensure that consecutive runs of the script start from a clean state in case of failure. For example, if your script involves adding items to a shopping cart, and your script fails before clearing the cart, the next run will not start from a clean state. So add a step to clear the cart immediately after logging in.
Wait for the content that you want to interact with to load fully before interacting with it.
Pay attention to how pages are loading as you navigate through them, as this could help determine which completion event(s) use. (If monitoring asynchronous third-party content is important, you will want to use network inactivity. If focused on primary content, use download cycles combined with a timer completion event.)
Try to click text links instead of images where possible, as images can change quickly on a website.
Watch the placement of clicks in your recorder (Block view in MITE and Script Viewer in KITE), as it may not always create a new page (MITE) or action (KITE) when the website loads a new page. (See Initial Settings above for TxP scripts in KITE—based on your settings, new actions are not necessarily created for dynamic content.)
When interacting with Flash sites in KITE (see also Recording Flash and Silverlight in Transaction Perspective):
Try to click the center of the objects you are interacting with, as there can occasionally be a difference of a few pixels between KITE and the agents.
Select Reset Window Size in the recording window to match window size on agents. Because KITE records coordinates for the location of each interaction, the size of the KITE recording window must be the same as on the agent.
On sites that include Flash, Silverlight, or other rich Internet applications, interactions do not automatically generate KITE navigations; you need to specify when a new action should be recorded. You can specify Yes in the Dynamic New Page field of the recording window if you want each interaction to be considered a new action. Select No if you want all the interactions with the Flash or Silverlight application to be contained in a single action. The Prompt option is not recommended when recording Flash.
You can also specify a default treatment for dynamic content in global settings.
After you have stepped through your business transaction in the recorder, play your script back several times to ensure that there were no errors in capturing your transaction. Thereafter, you might need to adjust completion conditions, add validation, change the structure of the script into actions/pages, adjust script timeout, name script steps for easy identification, and adjust other settings as necessary.
Advanced scripting in KITE and MITE requires the following skills:
- Remove unnecessary steps, e.g., anything you have captured by mistake like clicking in a non-clickable area.
- While the recorders automatically create pages (MITE) or actions (KITE) per page you visit, check that your script is organized into pages as per your script plan, in a way that allows you to analyze performance easily. If you have a page/action that makes multiple AJAX calls or visits more than one page, it will be hard to distinguish response times for each.
MITE sometimes creates two separate pages for web pages where you need to enter a user ID and password; you should combine these into a single MITE page.
For TxP scripts in KITE, you might have opted not to create a new action each time dynamic content is loaded (see Initial Settings above). After recording, refer to your script plan for how you want break script steps down for dynamic content into logical actions.
While KITE and MITE insert default completion conditions (taking your global settings into account in KITE), we strongly recommend reviewing and adjusting these to suit your monitoring purpose:
Play your script back after recording. If it does not work as expected, adjust the completion events using the guidelines below.
If you are focused on monitoring a lot of third-party, asynchronous content, use network inactivity as a completion condition. If focused on primary content, use download cycles combined with a timer completion condition.
We do not recommend using just a hard wait time as a completion event.
There are no completion events for ApP scripting.
- In MITE, every action that generates network activity has a completion event. (You can add multiple Navigate actions to a single script page—each one of these will have a completion event.)
- The default completion event created for every action in MITE is a combination of network inactivity of 2 seconds and End on load event = True (download cycles). We recommend using these settings.
See Editing a MITE Script for details.
For TxP scripts, these standard completions can work for most actions:
1 download cycle with a 5 second timer
HTTP inactivity set to 3000 milliseconds
You cannot combine network inactivity with a timer or download cycles as a completion condition in KITE.
HTTP inactivity is preferred over download cycles:
- As it works better with Internet Explorer 11; Chrome and FireFox do not support download cycles.
- HTTP inactivity is also preferable when a site generates an overlay instead of a new page, as that rarely triggers a download cycle.
However, network inactivity can also be reset by a late call such as a chat pop up or third-party rotating banners. You will need to adjust the inactivity timer to make sure that network time for the late call is not added to the performance time of the page (also check MyKeynote).
If you have a step delay (between consecutive steps of an action) that is greater than the completion condition at the end of the action such as a hard timer or HTTP inactivity timer, the completion condition might be triggered first. Make sure that your step delay is not greater than your completion condition timer.
####### Web recorder
- In the Keynote Web Recorder, you have a choice of a hard wait time in milliseconds, download cycles, or network inactivity as a completion condition for desktop scripts. Mobile scripts have a hard-coded completion condition of one download cycle and 2000 ms of HTTP inactivity, which cannot be edited. See the Wait option in Web Recorder Actions.
Use validation on every action (KITE) and page (MITE) to verify that your your transaction flow is exactly where it is supposed to be. Sometimes, the script will return a success even if it loads an unexpected page; validation verifies that the script has loaded the correct page.
Make sure the content you want matched does not change or is not removed from the page.
Validation text should be specific to the page you are verifying and not on the previous page as well.
Try to avoid using validation text that is not visible but hidden in the page HTML (e.g., JSON and XML responses), as it can make it confusing to determine if it appeared or not in screenshots. Sometimes, however, it might be unavoidable to use hidden text when there is no good unique text on the page to use for validation.
Time spent performing validation has no effect on performance value because validation occurs after the completion condition.
- MITE supports text validation, i.e., searching for a string of text from page code to verify that it has loaded.
- You can create a validation at the page or action level (right-click > Validation > opt to search for validation text in title, page, or link).
- You can have more than one validation rule per MITE page.
- KITE supports text, element, and cookie validation—right-click a page name in the Script Viewer > Add Validation. Then right-click the Validation step added to specify required text, error text, a cookie, or element.
- You can have more than one validation rule. The order of validation rules is respected in KITE, so add rules in the order you want them observed. Add error text before required text for validation.
- Avoid using multibyte characters (e.g., Asian language characters) in validation text if possible. If necessary, use DOM scripts (right-click > Add DOM Script) to validate these characters instead.
Timeout Settings for KITE
- In the Script Viewer, the script Timeout is set by default to 60 seconds for all scripts up to 5 pages in length, allowing 12 seconds for completion per page. After this timeout, the agent reports script failure.
Changing the default timeout can cause you to incur additional charges. For example, if you have a 5-page script and change the timeout to 72 seconds, you are charged for 6 pages.
- Under the Script Properties Editor for each action, leave the Page Timeout value at 0.
- If your script actions have multiple steps that require additional delay between them (such as clicking a menu and waiting for it to drop down), select the step and add the delay in the Script Properties Editor. The default step delay should already have been set to 500 ms in global settings. For slower responses, change this to 1000-2000 ms.
- If you have a step delay (between consecutive steps of an action) that is greater than the completion condition at the end of the action such as a hard timer or HTTP inactivity timer, the completion condition might be triggered first. Make sure that your step delay is not greater than your completion condition timer.
- Be sure that locators to identify an element have unique values on an HTML page so you can interact with it correctly, e.g., click a specific button. If your page has multiple buttons with no IDs and the same name, do not use the name to locate the button you want. You might need to enhance locators with some other properties such as Xpath or CSS selectors, which you can get from the DOM tree view. (The DOM view is available in KITE for playback and browse modes.)
- To run your script as a new visitor, add an action at the start of the script to clear local storage: Advanced > Clear local storage.
Select Settingsin the Script Viewer to edit specific properties in the Script Properties Editor:
- Check Auto-close windows dialogs (select Settings in the Script Viewer > Auto-close windows dialogs in the Script Properties Editor) to prevent any browser dialog boxes from causing the measurement to timeout.
- Uncheck Report error if no network activity only if the script demands it, such as a script action that interacts with a feature but does not generate network activity. In such a case, uncheck this option because a network inactivity error (70042) can mask other errors at the page level. Generally, this option is checked to catch network inactivity errors; no network activity at the end of a page means that the page or script are not functioning as expected.
- Leave IE Browser Mode at Default, unless the site requires a specific setting. This defaults to the Internet Explorer version on the machine where KITE is installed.
In step settings for clicks:
- Mouse clicks are not recommended because they can sometimes misfire and cause timeouts. (DOM clicks act on the entire element from the DOM; mouse clicks act on an (x, y) coordinate, defaulting to (0, 0) for the top-left corner of the DOM object).
- If using a mouse click, change the positional coordinates so that the step clicks something closer to the center of the object.
Any DOM scripts used should have sufficient commenting to explain what they are doing.
Edit the default action and constituent step names in KITE and page and action names in MITE to provide unique and meaningful names. Default action (or page) names are scraped from title of HTML page and are not necessarily unique or easy to identify.
Name your pages in KITE or actions in MITE based on the page you interact with. For example, a page that adds an item to a cart would be called “Cart," not “Add to Cart.”
- Describe the interaction, e.g., "Add to Cart," in the Description field of script properties. This helps other scripters/users in your account with script maintenance.
Ensure that page (in KITE) or action (in MITE) names are unique.
If you visit the same page in multiple scripts, try to use the same name across different scripts to avoid confusion.
If your script returns to a page already visited (such as returning to the cart from checkout in order to clear it), add an identifier such as "Cached" to the second instance of the page name to signify that you've already visited it and most of the elements are cached in the browser.
Rename each constituent step (or action) in a script to make it easy to identify in MyKeynote.
Name your script using identifiers for the website and description of the transaction.
Use the script name as the basis for the slot/measure name in KSC.
- Once a script is complete, run it several times over without any script errors before deployment.
- Run your script against real agents using the 5-city test in MyKeynote (Diagnostics > Five City Test). Upload your script directly to MyKeynote to run this instant test and view results.