Planning the script
Before you record a script, identify the goals you want to accomplish. Here are some considerations:
- What functionality needs to be tested?
- Is this functionality supported in the browser versions supported by the browser agents?
- What should the script flow look like?
- How do you make sure the script is going to function properly?
Before beginning the recording, walk through the business process in a native browser (for browser scripts) or in the app (for native application scripts) to make sure there are no performance problems that would prevent the Recorder from successfully recording and playing the script.
A walkthrough also helps you determine whether the default timeouts, e.g. for Wait actions, need to be adjusted after you record the script.
- You should familiarize yourself with the backtick syntax that the Recorder uses to handle dynamic values.
- It will also be helpful to familiarize yourself with the GSL concepts for the Recorder and scripts.
- Most script actions can be edited. Review the help topics for script actions so you know how to supply necessary information and refine their behavior.
Configuring a script
You can save time by configuring default settings before recording the scripts. You can specify such details as the recording mode (desktop browser or mobile device), the device to emulate in mobile scripts, a default header, the default playback agent, the IP mode, and the file format for saving the script.
When you record a script, you can save its settings as a custom profile that you can use to apply the same settings to other scripts.
Use FormFill rather than Keystroke actions when you record a script, unless you have a specific need to capture each keystroke (for example, to test the autofill function for a form field).
Setting up a script
When you create a script, don't try to squeeze in as many functionalities as possible. You can create multiple scripts, so that each script tests only one application function at a time, to keep each script as short and simple as possible. For example, for a shopping website, create separate scripts to log in, search for an item, add the item to the cart, provide shipping information, and pay for the item. Limiting the script to a single application function helps to isolate problem areas for troubleshooting.
Using actions effectively
Wait actions should be placed before the end of the step, after the action for which the wait is needed: for example, a Wait for Page Complete after a Click action that results in going to a new page.
Best practice is to end each step with a Validate action to ensure that the step executed properly. Note that this Validate is a separate action, not the Wait for Validate criterion in a Wait action. The Wait action and Validate action should not be the only actions in a step.s
Cleaning up a script
After creating a script, go through the steps to make sure it is clean and doesn’t have any unnecessary actions. Here are a few tips:
- Remove unnecessary actions. For example, if you corrected a typo while entering text in a form field, delete the Type actions that recorded the backspace and (if you recorded keystrokes) the incorrect character(s).
- If you commented out any actions while troubleshooting the script, either delete the actions if you determined they aren't necessary, or uncomment the actions. Comments are not supported in active tests, because they create unneeded communication within the browser agent and they may affect the test results.
- Delete any actions that have
.htmlas the locator. The Recorder creates these actions when you click the scroll bar or anywhere in the web page where there isn’t an element. If you need to scroll down the page and have a scroll wheel on your mouse, use the wheel instead of clicking the scroll bar.
- As needed, organize actions into steps that allow you to easily analyze the data. Each step should represent a single page load. If you have a step that makes multiple AJAX calls or visits more than one page, it will be hard to distinguish the total response time. Insert step barriers to split up the calls that are made and give you a more accurate representation of how long it took for each AJAX call or page load to occur.
- Make sure that each step ends with a Wait or Validate action. A step should never end with any other action. When an action is made on the page that either results in an AJAX call or loads a new page, the Wait action allows the script to display the results for that specific step. The Validate action verifies that the step performed as expected.
- Include a content match in each step. Sometimes the script will load a different page than expected but will return a success. A simple text validation verifies that the script loads the correct page. Make sure the string you specify for the content match is content that will not change or be removed from the page.
- Edit the default script and step names to provide unique and meaningful names. Using names that clearly identify the purpose of the script and each step makes maintaining the script easier.
When you have cleaned up the script, run the script on your local machine. Make sure that the script plays back successfully before uploading it to the Synthetic Classic Portal.