HTML Services Recorder User Guide Follow

Installation

Download Stand alone FireFox with AuraPlayer IDE - link

Unzip the above file, and open FirefoxPortable.exe.

Opening the IDE

To run the AuraPlayer IDE, simply select it from the Firefox Tools menu. It opens as follows with an empty script-editing window and a menu for loading, or creating new workflows.

IDE Features

 

Toolbar

The toolbar contains buttons for controlling the execution of your Workflows, including a step feature for debugging your Workflows. The right-most button, the one with the red-dot, is the record button.

Speed Control: controls how fast your Workflow runs.

Run All: Runs the entire test suite when a test suite with multiple Workflows is loaded.

Run: Runs the currently selected test. When only a single test is loaded this button and the Run All

button have the same effect.

Pause/Resume: Allows stopping and re-starting of a running Workflow.

Step: Allows you to “step” through a Workflow by running it one command at a time. Use for debugging Workflows.

TestRunner Mode: Allows you to run the Workflow in a browser. The TestRunner is not commonly used now and is likely to be deprecated. This button is for evaluating Workflows for backwards compatibility with the TestRunner. Most users will probably not need this button.

Insert Input command: Allows you to store a value as an input

Insert Output command: Gets the text of an element. This works for any element that contains text.

Record: Records the user’s browser actions.

Workflow Pane

Your script is displayed in the Workflow pane. It has two tabs, one for displaying the command and their parameters in a readable “table” format.

The other tab - Source displays the Workflow in the native format in which the file will be stored. By default, this is HTML although it can be changed to a programming language such as Java or C#, or a scripting language like Python. See the Options menu for details. The Source view also allows one to edit the Workflow in its raw form, including copy, cut and paste operations.

The Command, Target, and Value entry fields display the currently selected command along with its parameters. These are entry fields where you can modify the currently selected command. The first parameter specified for a command in the Reference tab of the bottom pane always goes in the Target field. If a second parameter is specified by the Reference tab, it always goes in the Value field.

If you start typing in the Command field, a drop-down list will be populated based on the first characters you type; you can then select your desired command from the drop-down.

Log/Reference/UI-Element/Rollup Pane

The bottom pane is used for four different functions–Log, Reference, UI-Element, and Rollup–depending on which tab is selected.

Log

When you run your Workflow, error messages and information messages showing the progress are displayed in this pane automatically, even if you do not first select the Log tab. These messages are often useful for Workflow debugging. Notice the Clear button for clearing the Log. Also notice the Info button is a drop-down allowing selection of different levels of information to log.

Reference

The Reference tab is the default selection whenever you are entering or modifying commands and parameters in Table mode. In Table mode, the Reference pane will display documentation on the current command. When entering or modifying commands, whether from Table or Source mode, it is critically important to ensure that the parameters specified in the Target and Value fields match those specified in the parameter list in the Reference pane. The number of parameters provided must match the number specified, the order of parameters provided must match the order specified, and the type of parameters provided must match the type specified. If there is a mismatch in any of these three areas, the command will not run correctly.

UI-Element and Rollup

Detailed information on these two panes (which cover advanced features) can be found in the UI-Element Documentation on the Help menu of AuraPlayer IDE.

Building Workflows

There are three primary methods for developing Workflows. Frequently, a test developer will require all three techniques.

Running Workflows

The IDE allows many options for running your Workflow. You can run a Workflow all at once, stop and start it, run it one line at a time, run a single command you are currently developing, and you can do a batch run of an entire test suite. Execution of Workflows is very flexible in the IDE.

Run a Workflow

Click the Run button to run the currently displayed Workflow.

Run a Test Suite

Click the Run All button to run all the Workflows in the currently loaded test suite.

Stop and Start

The Pause button can be used to stop the Workflow while it is running. The icon of this button then changes to indicate the Resume button. To continue click Resume.

Stop in the Middle

You can set a breakpoint in the Workflow to cause it to stop on a particular command. This is useful for debugging your Workflow. To set a breakpoint, select a command, right-click, and from the context menu select Toggle Breakpoint.

Start from the Middle

You can tell the IDE to begin running from a specific command in the middle of the Workflow. This also is used for debugging. To set a startpoint, select a command, right-click, and from the context menu select Set/Clear Start Point.

Run Any Single Command

Double-click any single command to run it by itself. This is useful when writing a single command. It lets you immediately test a command you are constructing, when you are not sure if it is correct. You can double-click it to see if it runs correctly. This is also available from the context menu.

Using Base URL to Run Workflows in Different Domains

The Base URL field at the top of the AuraPlayer IDE window is very useful for allowing Workflows to be run across different domains. Suppose that a site named http://news.portal.com had an in-house beta site named http://beta.news.portal.com. Any Workflows for these sites that begin with an open statement should specify a relative URL as the argument to open rather than an absolute URL (one starting with a protocol such as http: or https:).AuraPlayer IDE will then create an absolute URL by appending the open command’s argument onto the end of the value of Base URL. For example, the Workflow below would be run against http://news.portal.com/about.html:

This same Workflow with a modified Base URL setting would be run against http://beta.news.portal.com/about.html:

Commands

Commands, are the set of commands that run your tests. A sequence of these commands is a test script. Here we explain those commands in detail, and we present the many choices you have in testing your web application.

One can test the existence of UI elements based on their HTML tags, test for specific content, test for broken links, input fields, selection list options, submitting forms, and table data among other things. In addition commands support testing of window size, mouse position, alerts, Ajax functionality, pop up windows, event handling, and many other web-application features.

A command tells AP what to do. commands come in three “flavors”: Actions, Accessors, and Assertions.

• Actions are commands that generally manipulate the state of the application. They do things like “click this link” and “select that option”. If an Action fails, or has an error, the execution of the current test is stopped.

  Many Actions can be called with the “AndWait” suffix, e.g. “clickAndWait”. This suffix tells that the action will cause the browser to make a call to the server, and that should wait for a new page to load.

• Accessors examine the state of the application and store the results in variables, e.g. “storeTitle”. They are also used to automatically generate Assertions.

• Assertions are like Accessors, but they verify that the state of the application conforms to what is expected. Examples include “make sure the page title is X” and “verify that this checkbox is checked”.

  All Assertions can be used in 3 modes: “assert”, “verify”, and ” waitFor”. For example, you can “assertText”, “verifyText” and “waitForText”. When an “assert” fails, the test is aborted. When a “verify” fails, the test will continue execution, logging the failure. This allows a single “assert” to ensure that the application is on the correct page, followed by a bunch of “verify” assertions to test form field values, labels, etc.

  “waitFor” commands wait for some condition to become true (which can be useful for testing Ajax applications). They will succeed immediately if the condition is already true. However, they will fail and halt the test if the condition does not become true within the current timeout setting (see the setTimeout action below).

Script Syntax

Commands are simple, they consist of the command and two parameters. For example:

The parameters are not always required; it depends on the command. In some cases both are required, in others one parameter is required, and in still others the command may take no parameters at all. Here are a couple more examples:

The command reference describes the parameter requirements for each command.

Parameters vary, however they are typically:

• a locator for identifying a UI element within a page.
• a text pattern for verifying or asserting expected page content
• a text pattern or a variable for entering text in an input field or for selecting an option from an option list.

Locators, text patterns, variables, and the commands themselves are described in considerable detail in the section on Commands.

Scripts that will be run from AuraPlayer IDE will be stored in an HTML text file format. This consists of an HTML table with three columns. The first column identifies the command, the second is a target, and the final column contains a value. The second and third columns may not require values depending on the chosen command, but they should be present. Each table row represents a new command. Here is an example of a test that opens a page, asserts the page title and then verifies some content on the page:

<table>
    <tr><td>open</td><td>/download/</td><td></td></tr>
    <tr><td>assertTitle</td><td></td><td>Downloads</td></tr>
    <tr><td>verifyText</td><td>//h2</td><td>Downloads</td></tr>
</table>

Rendered as a table in a browser this would look like the following:

The HTML syntax can be used to write and run tests without requiring knowledge of a programming language. With a basic knowledge of HTML and AuraPlayer IDE you can quickly produce and run Workflows.

Commonly Used Commands

To conclude our introduction of AuraPlayer IDE, we’ll show you a few typical commands. These are probably the most commonly used commands for building tests.

open

opens a page using a URL.

click/clickAndWait

performs a click operation, and optionally waits for a new page to load.

verifyTitle/assertTitle

verifies an expected page title.

verifyTextPresent

verifies expected text is somewhere on the page.

verifyElementPresent

verifies an expected UI element, as defined by its HTML tag, is present on the page.

verifyText

verifies expected text and its corresponding HTML tag are present on the page.

verifyTable

verifies a table’s expected contents.

waitForPageToLoad

pauses execution until an expected new page loads. Called automatically when clickAndWait is used.

waitForElementPresent

pauses execution until an expected UI element, as defined by its HTML tag, is present on the page.

Verifying Page Elements

Verifying UI elements on a web page is probably the most common feature of your automated tests. Commands allows multiple ways of checking for UI elements. It is important that you understand these different methods because these methods define what you are actually testing.

For example, will you test that…

1. an element is present somewhere on the page?
2. specific text is somewhere on the page?
3. specific text is at a specific location on the page?

For example, if you are testing a text heading, the text and its position at the top of the page are probably relevant for your test. If, however, you are testing for the existence of an image on the home page, and the web designers frequently change the specific image file along with its position on the page, then you only want to test that an image (as opposed to the specific image file) exists somewhere on the page.

Assertion or Verification?

Choosing between “assert” and “verify” comes down to convenience and management of failures. There’s very little point checking that the first paragraph on the page is the correct one if your test has already failed when checking that the browser is displaying the expected page. If you’re not on the correct page, you’ll probably want to abort your Workflow so that you can investigate the cause and fix the issue(s) promptly. On the other hand, you may want to check many attributes of a page without aborting the Workflow on the first failure as this will allow you to review all failures on the page and take the appropriate action. Effectively an “assert” will fail the test and abort the current Workflow, whereas a “verify” will fail the test and continue to run the Workflow.

The best use of this feature is to logically group your test commands, and start each group with an “assert” followed by one or more “verify” test commands. An example follows:

The above example first opens a page and then “asserts” that the correct page is loaded by comparing the title with the expected value. Only if this passes will the following command run and “verify” that the text is present in the expected location. The Workflow then “asserts” the first column in the second row of the first table contains the expected value, and only if this passed will the remaining cells in that row be “verified”.

Locating Elements

For many AP commands, a target is required. This target identifies an element in the content of the web application, and consists of the location strategy followed by the location in the format locatorType=location. The locator type can be omitted in many cases. The various locator types are explained below with examples for each.

1
2
3
4
5
6
7
8
9

<html>
 <body>
  <form id="loginForm">
   <input name="username" type="text" />
   <input name="password" type="password" />
   <input name="continue" type="submit" value="Login" />
  </form>
 </body>
<html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 <html>
  <body>
   <form id="loginForm">
    <input name="username" type="text" />
    <input name="password" type="password" />
    <input name="continue" type="submit" value="Login" />
    <input name="continue" type="button" value="Clear" />
   </form>
  </body>
 <html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 <html>
  <body>
   <form id="loginForm">
    <input name="username" type="text" />
    <input name="password" type="password" />
    <input name="continue" type="submit" value="Login" />
    <input name="continue" type="button" value="Clear" />
   </form>
 </body>
 <html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 <html>
  <body>
   <form id="loginForm">
    <input name="username" type="text" />
    <input name="password" type="password" />
    <input name="continue" type="submit" value="Login" />
    <input name="continue" type="button" value="Clear" />
   </form>
 </body>
 <html>

1
2
3
4
5
6
7

<html>
 <body>
  <p>Are you sure you want to do this?</p>
  <a href="continue.html">Continue</a>
  <a href="cancel.html">Cancel</a>
</body>
<html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 <html>
  <body>
   <form id="loginForm">
    <input name="username" type="text" />
    <input name="password" type="password" />
    <input name="continue" type="submit" value="Login" />
    <input name="continue" type="button" value="Clear" />
   </form>
 </body>
 <html>

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

 <html>
  <body>
   <form id="loginForm">
    <input class="required" name="username" type="text" />
    <input class="required passfield" name="password" type="password" />
    <input name="continue" type="submit" value="Login" />
    <input name="continue" type="button" value="Clear" />
   </form>
 </body>
 <html>

Matching Text Patterns

Like locators, patterns are a type of parameter frequently required by commands. Examples of commands which require patterns are verifyTextPresent, verifyTitle, verifyAlert, assertConfirmation, verifyText, and verifyPrompt. And as has been mentioned above, link locators can utilize a pattern. Patterns allow you to describe, via the use of special characters, what text is expected rather than having to specify that text exactly.

There are three types of patterns: globbing, regular expressions, and exact.

The “AndWait” Commands

The difference between a command and its AndWait alternative is that the regular command (e.g. click) will do the action and continue with the following command as fast as it can, while the AndWait alternative (e.g. clickAndWait) tells AP to wait for the page to load after the action has been done.

The AndWait alternative is always used when the action causes the browser to navigate to another page or reload the present one.

Be aware, if you use an AndWait command for an action that does not trigger a navigation/refresh, your test will fail. This happens because AP will reach the AndWait’s timeout without seeing any navigation or refresh being made, causing AP to raise a timeout exception.

The waitFor Commands in AJAX applications

In AJAX driven web applications, data is retrieved from server without refreshing the page. Using andWait commands will not work as the page is not actually refreshed. Pausing the test execution for a certain period of time is also not a good approach as web element might appear later or earlier than the stipulated period depending on the system’s responsiveness, load or other uncontrolled factors of the moment, leading to test failures. The best approach would be to wait for the needed element in a dynamic period and then continue the execution as soon as the element is found.

This is done using waitFor commands, as waitForElementPresent or waitForVisible, which wait dynamically, checking for the desired condition every second and continuing to the next command in the script as soon as the condition is met.

Store Commands and Variables

You can use variables to store constants at the beginning of a script. Also, when combined with a data-driven test design (discussed in a later section), variables can be used to store values passed to your test program from the command-line, from another program, or from a file.

The plain store command is the most basic of the many store commands and can be used to simply store a constant value in a variable. It takes two parameters, the text value to be stored and a variable. Use the standard variable naming conventions of only alphanumeric characters when choosing a name for your variable.

Later in your script, you’ll want to use the stored value of your variable. To access the value of a variable, enclose the variable in curly brackets ({}) and precede it with a dollar sign like this.

A common use of variables is for storing input for an input field.

Variables can be used in either the first or second parameter and are interpreted by prior to any other operations performed by the command. A variable may also be used within a locator expression.

An equivalent store command exists for each verify and assert command. Here are a couple more commonly used store commands.

JavaScript and Parameters

JavaScript can be used with two types of parameters: script and non-script (usually expressions). In most cases, you’ll want to access and/or manipulate a Workflow variable inside the JavaScript snippet used as a parameter. All variables created in your Workflow are stored in a JavaScript associative array. An associative array has string indexes rather than sequential numeric indexes. The associative array containing your Workflow’s variables is named storedVars. Whenever you wish to access or manipulate a variable within a JavaScript snippet, you must refer to it as storedVars[‘yourVariableName’].

echo - The AP Print Command

Commands has a simple command that allows you to print text to your test’s output. This is useful for providing informational progress notes in your test which display on the console as your test is running. These notes also can be used to provide context within your test result reports, which can be useful for finding where a defect exists on a page in the event your test finds a problem. Finally, echo statements can be used to print the contents of variables.

If you have more questions please refer to FAQ/How To page.