|'Windows and components' Section|
The topic 'components' is covered by several videos:
The video 'Component recognition' first explains the criteria for component recognition, then (starting at min 13:07) the use of generic components using regular expressions, followed by generic components using variables in component recognition attributes.
There are two videos available explaining in detail how to deal with a
The video 'ComponentNotFoundException - simple case' shows a simple case.
A more complex case is discussed in the video 'ComponentNotFoundException - complex case'.
The video 'Dealing with the explosion of complexity in web test automation' gives you a good idea of how QF-Test handles a deeply nested DOM structure.
QF-Test stores the information about how to find a component in the UI of the SUT in the 'Windows and components' section. It analyzes the component information during the recording of actions to the SUT and saves the information for the components the user interacted with in the details of the 'Component' nodes.
This section is meant to give you an idea about which kind of information is stored in the 'Component' nodes and how QF-Test uses it to recognize a component in the UI. There are two cases where you will want to have a look at components and where it will be useful to have a basic idea of the concepts of component recognition.
The first one is when the UI of your application changed significantly between when you first recorded the component to when you want to replay the test, e.g. because of a new release of the application. QF-Test uses several algorithms to evaluate whether a certain UI element currently displayed matches the criteria of the UI element that was once recorded. However, when too many of the criteria no longer fit then you will have to have a look at the components. For a detailed instruction about what to do then, please refer to the manual chapter Troubleshooting component recognition problems. There are also links to videos showing respective samples.
The second one is when you want to improve component recognition. As you already know from the chapter Improved Web Component Recognition a certain functional component like a checkbox or table, even an input field, can be implemented in quite a number of different ways from the basic HTML components available. Even though QF-Test provides component recognition for a number of AJAX toolkits there may always be some components that are not recognized for what they really are. For details about how to implemtent additional component recognition please have a look at the chapter 'CustomWebResolver' in the technical reference part of the manual.
Let's have a look at a 'TextField' component node and see which criteria were recorded and saved in the details of the 'Component' node.
||Figure 13.2: Locating a component|
This is going to take you directly to the 'TextField CalculatedPrice' node in the 'Windows and components' section.
||Figure 13.3: Component tree|
Above component tree has only a few levels. This is because of the custom web resolver registered after the start of the application as explained in Improved Web Component Recognition. When you have a look at the component tree recorded for the test-suite you set up in chapter 11 you will notice that there are a lot more DIV levels. These have been defined on the HTML page. They are not relevant for component recognition and make the tree rather big and confusing. Therefore, in the demo test-suite, we suppress their recording with the custom web resolver.
Let's have a look at the properties of this component node used to identify the UI element.
||Figure 13.4: Details of the 'Component' node|
The topmost attribute is 'QF-Test ID', which provides the 'handle' to the component to be used in the test-cases and procedures. All other attributes refer to the component in the UI.
The next attribute is 'Class name'. In our case it is 'TextField'. For component recognition it is essential to know the class of a component. In fact this class is a generalized value of the class used by the developer. This is helpful to achieve component recognition independent of the specific implementation and allows easy porting of tests. However, QF-Test saves the specific values in the 'Extra features' table. By default, they are not used for component recognition.
Other examples for generic classes would be 'Panel', 'Dialog' or 'Button'.
The 'Name' attribute is the name or id given to the UI component by the programmer. If there is a Name then this, together with the class, is all QF-Test needs to identify a component in the UI.
If the programmer did not set a name or id for the UI component and the 'Name' attribute therefore remained empty QF-Test needs other criteria like a certain text associated with the component, index information and geometry.
A feature associated with a button for example would be the text shown on the button.
QF-Test saves a text directly belonging to the UI component in the
'Feature' attribute. If the web UI element has not text but an
id QF-Test saves the id in the 'Feature' attribute. If none of the two exists and
there is a text in the vicinity of the component
that could be the label then this will be saved in the 'Feature'.
In any case the label will be saved in the 'Extra features' table with the
'Extra features' Name
The Structure information refers to all UI components of the respective class. The total number of UI components of that class is saved in the 'Class count' attribute, the index of the component itself in the 'Class index' attribute.
Last there is the Geometry information. It is the one having the lowest weight within the recognition algorithm. It can be of value if no other helpful information is available for a component.
In case you are interested in further details of the component recognition you will find such in the Component recognition chapter of the technical reference of the manual.
If you want to get a feeling for the component recognition you could play around with the attribute values and see what you need to change to make QF-Test not recognize it anymore or even recognize a wrong component in the UI. You will find that you need to change quite a few attributes before QF-Test recognizes a different component. This means that component recognition with QF-Test is very robust. With regression tests a significant part of the UI component criteria need to change before QF-Test will not recognize the component anymore even if the component has no name or id.
When you click the 'Component' node QF-Test will highlight the recognized component in the UI by outlining it with a dark blue border.
CalculatedPricefrom the 'Name' attribute. Because as long as there is an entry in the 'Name' attribute QF-Test will not consider the attributes below.
TextFieldnode and check QF-Test still highlights the Final Price field in the UI.
CalculatedPrice, either via the respective toolbar button or by typing [Ctrl-Z].
qfs:labelvalue in the 'Extra features' table from
qfs:labelvalue in the 'Extra features' table back to
qfs:labelvalue in the 'Extra features' table from
This is just to give you a bit of a feeling for component recognition. In the above mentioned chapters (and some more) of the manual you will find detailed information about what to do when you have trouble with component recognition.
|Last update: 12/3/2020
Copyright © 2002-2020 Quality First Software GmbH