Articles Tagged 'recording'

When using Rapise for analog testing you need to use the key sequence CTRL+BREAK to start and stop the analog recorder. However some machines (particularly smaller laptops) do not have a BREAK or PAUSE (often the same function as BREAK) key. This article describes some solutions

The context menu control is not natively supported by Rapise, but one can use a simple workaround.

When you do recording of test steps for a Web application - Rapise by default captures page URLs and stores them in the object repository. Learn how to  disable URL recording from this article.

Requires Rapise 6.4+

Every test has a User.js file and it is a place to put custom code and functions. This code must follow a few rules.

By design Rapise tries to record user activity on the highest possible level. This makes recorded actions more readable and universal. However that sometimes means that certain actions that a user performs won't be automatically picked up. This guide explains ways to handle situations when a specific user activity is not recorded.

In most cases "Auto" is the best choice. Manual selection of libraries may be needed in more advanced scenarios and is intended for experienced users.                

Sometimes the application under test doesn't contain any learnable objects. In that case you may need to use the fallback of Analog Recording. This guide describes how you perform analog recording.

This guide describes what simulated objects are and when they should be used.

By default Rapise records user actions with a line commented out for each action. This articles describes how you can disable this behavior if you just want the script lines recorded on their own.

By design Rapise tries to record user activity on the highest possible level. This makes recorded actions more readable and universal (often several lower-level user actions are combined)

Rapise uses a heuristics to distinguish meaningful activity from low level actions. In some cases this leads to a result that some user activity is not automatically recorded (for example, a mouse click before entering  text in a box). There is a broad range of available UI platforms and libraries. The variety of graphical widgets makes user interface robust and beautiful. Rapise tries to recognize as much objects as possible. However this range is growing and there are always widgets that are not being recorded.

There are several ways to find if something is already on the screen, this article explains some of the options.

A Flex application requires some instrumentation to be ready for testing. By default Flash player has security restrictions preventing Rapise from accessing the application contents. Please, check the this help topic to learn more about Adobe Flex testing.                

Sometimes Rapise will incorrectly recognize a GUI component. This guide outlines how you can manually change the object type captured during recording.

Many web sites have dynamic site menus. This guide outlines the best practices for recording events associated with such dynamic site menus.

This guide describes the different types of mouse events and how they are recorded in Rapise.

Simulated objects are found by looking at the parameters of the object (x number of pixels from the top of the window, y number of pixels from the left of the window, etc).  One common question that has arisen is - during playback, does Rapise take into account screen resolution?  If the resolution on the computer you run it on is different from the one it records on the location of the object will change relative to the number of pixels.  So on the computer you record it on the top parameter might be 200 but on a different resolution it might be 180.  Would Rapise recognize that the resolution is different and adjust for that?