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:
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: 4/26/2023|
Copyright © 1999-2023 Quality First Software GmbH