47.1

Weighting of recognition features for recorded components

When searching for a component, QF-Test calculates the probability with which each component in the SUT corresponds to the searched component. The component with the highest probability is then used, as long as that this probability is above a freely configurable threshold. First, the probabilities of the windows in the SUT are examined. Then, the search is continued in the window with sufficiently high probability.

The same procedure is followed level by level, i.e. for each direct and indirect parent node of the searched 'Component' node, but from top to bottom. At each level, the components matching the attribute 'Class name' are determined and their probability is calculated. Invisible components are not considered.

At each level, the probability of a component is calculated in several stages:

• Every calculation starts with a value of 99 percent, which is first reduced by deviations from geometry specifications. This serves as the base probability for the next stages.
• The following three stages can either result in a "match", "no match", or be skipped. If no value is specified for a stage, it is skipped; the probability remains unchanged. Each of the three steps has a freely configurable bonus in case of a match or a penalty in case of a deviation. A bonus in effect increases the probability score to more than its value, a penalty reduces it to below its value.
• First, the structure of the 'Components' is checked, (not of 'Windows', which do not have this information). All components of the currently evaluated container component whose class matches the given 'Class name' or a derived class are collected in a list (including invisible components). For a match, the amount of previously identified components with the matching class as well as the index of the component in this list must match.
• Then, the 'Feature' and possible 'Extra features' are checked. If the test of an 'Extra feature' with status "must match" fails, the component is discarded.
• Finally, the 'Name' of the component is checked. If a 'Name' exists, this is the deciding check since bonus and penalty have the highest values here.

For dialogs, there is another step that checks the modality of the dialog. Normally, a dialog is either modal or non-modal, so a mismatch would prevent detection. However, one and the same dialog could be presented modally or non-modally depending on context. If your SUT contains such a dialog, you must set "Modal penalty" to a value above the minimum probability.

If the calculated probability does not reach a minimum value, the component is discarded. The component with the highest probability is used. If there is a discrepancy in the component's structure, feature, or name, a message is written to the log, as this may indicate that it is not the correct component after all. Most of the time, however, this just indicates that the SUT has changed slightly. The component should then be updated before the changes accumulate and the component is no longer recognized.

Even though the search for the name already dominates this process, you can increase its importance even more by setting the options Name override mode (replay) and Name override mode (record) to "Override everything". Then QF-Test will simplify the search for a component if it has a name. Instead of, as explained above, working through all parent containers from the outside in, they are skipped and the window is directly searched for a component matching the name and class. This increases the independence from the GUI structure; The component will even be recognized if a new hierarchy level between window and component is introduced or removed. This method requires that, if a name is given, it is unique at least among the visible components of the same class in one window.

If such uniqueness is not given, "Hierarchical resolution" is the next best setting for the two options. It requires that two components with the same name have at least differently named parent containers. This setting preserves most of the benefits and flexibility of names. However, it will fail recognition if a named component is moved from its parent container.

Last update: 9/10/2024 Copyright © 1999-2024 Quality First Software GmbH