|Determining specifics of your web page|
Note This section provides a first theoretical overview, the next section shows a realistic example.
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. That's why nearly every toolkit implemented its own way for drawing such components. This fact means that the HTML structure (the so-called DOM tree) looks different for every toolkit or framework. In order to allow QF-Test to identify the components as buttons or data-tables we need some kind of dictionary. The dictionary should contain a translation for the properties of the created HTML components to the QF-Test vocabulary.
Due to that flexibility of HTML your first step should be to get a good understanding of how the toolkit used creates its components and of the specific attributes and properties of the HTML components generated. The next paragraphs and especially the next section show some steps how to get this understanding of your web-page.
Once you identified a certain property determining a specific business component
you then should configure QF-Test to map it accordingly, using the
At the end
of the day you will have taught QF-Test which HTML tag or attribute represents a button,
which HTML property represents a data-table showing data and so on. From a
QF-Test perspective you assign generic classes to HTML
tags. The generic classes will then trigger the default
mechanism of the component recognition and item resolution of QF-Test.
The mechanism is the same as you are used to from any other engine.
You can find more details
about generic classes at chapter 53.
Inspecting the HTML code of a web page can be achieved by using the built-in development tools of your browser or extensions like FireBug.
||Figure 45.1: HTML code inspection in Firefox|
In most cases the HTML attribute
significant for component recognition and provides information about
the business type of that component, e.g. whether
the component acts as button or data-table. Other toolkits might set the
id or any other attribute. Of course there are
For adapting QF-Test to those toolkits you need to implement
many more resolver. However, we set the focus on the simple use-case here.
please get in touch with our support.
We start with calling the procedure
from the standard
qfs.qft and fill in the required parameters.
As already mentioned, the
class attribute provides
the class information in most cases, so we take a look at this attribute first.
Our goal now is to create a dictionary for QF-Test of the technical properties
of your HTML web-page. The next section will show this in detail.
The second step therefore is to map those determinative values to generic
classes of QF-Test via the parameter
genericClasses, which is
described in the next section.
Once we created such a dictionary, QF-Test will then record the business related components only. This will simplify the component tree recorded by QF-Test. In the figure below you can see such a simplification for the provided WebCarConfigurator demo.
A call to the procedure
qfs.web.ajax.installCustomWebResolver will be added to your
setup sequence by the Quickstart Wizard. You can find that call in the sequence
Install CustomWebResolver. You can adapt or replace that call accordingly.
||Figure 45.2: Reduction of complexity for WebCarConfigurator demo|
|Last update: 10/11/2018
Copyright © 1999-2019 Quality First Software GmbH