HTML is a very flexible language for describing the content of web
pages. But unfortunately there are no real standards with regard
to components which should be used to draw a button, a textfield
or a table showing data. As a result nearly every framework implements its own
way of drawing such components. This means the HTML structure
(the so-called DOM tree) looks different for every web framework. In order to
allow QF-Test to identify the components as buttons or data-tables etc we need some kind of
dictionary. The dictionary should work as a translator for the properties
of the HTML components to the QF-Test vocabulary.
QF-Test offers a generic component resolver to be configured freely, the
CustomWebResolver, allowing you to adapt the component recognition
of QF-Test without too great an effort to the specific needs of your web page.
Before starting to set up test-cases you should check the component recognition
and maybe improve it. We recommend the following approach:
-
Record GUI objects you want to interact with in the test on different
web pages of the application.
-
Check the recorded QF-Test components
-
whether they were mapped to Generic classes,
-
if they have sufficient recognition criteria ('Name' and 'Feature'
attributes,
qfs:label in 'Extra features'),
-
regarding the depth of the component hierarchy,
wie tief die Komponentenhierarchie ist
-
whether complex components such as tables, lists, trees etc have been
mapped as such and the subitems were addressed via index.
You will find detailed information on the standard recording of web objects and
criteria for deciding whether it is sufficent in Recognition of web components and toolkits.
-
In case you identified weak points, check the respective GUI objects of
different web pages trying to identify their characteristic attributes
to be mapped to generic QF-Test classes, as well as 'good' attributes for
the 'Name' and 'Feature' of the QF-Test component.
-
Configure the component mapping as described in The procedure
installCustomWebResolver.
