QF-Test allows intuitive testing of web pages in a browser from the point of view of the user. Just as with the other supported GUI technologies you can record actions and checks directly, and then rework, structure and replay them.
QF-Test supports test automation for the following browsers:
Please refer to subsection 1.1.2 for details on the supported browser versions.
In the tutorial, part II, you will find a step-by-step instruction for starting with test automation for web applications.
The approach towards test automation and execution regarding web applications does not really differ from that for other GUI technologies, as described in the general part of the manual, starting from chapter 2. However, you should pay special attention to component recognition, which highly depends on the precise implementation of the web application. In order to find out how well the direct recognition will work we recommend you do a test recording of different components in several dialogs of the web application and check the replay is correct. Please refer to section 14.4 for more information on component recognition and configuration.
First, you need to start and connect to the desired browser via QF-Test. As soon as the web application, defined by its URL, has been loaded you can start with recording and test automation.
QF-Test uses two different methods, so-called drivers, to get access to the browser and to set up the connection: the QF-Driver and the WebDriver.
NoteMost browsers can be accessed only via one of the two, the only exceptions being Chrome on Windows and Firefox up to version 43 on Windows and Linux. QF-Test automatically tries to set the correct mode for accessing the browser in the attribute 'Browser connection mode' of the 'Start web engine' node. If required, you can change it as needed. For details please refer to section 45.3.
QF-Driver embeds the browser installed on the testing machine into a wrapper window, and the wrapper window into the locally installed web browser, thus gaining access to the automation interfaces of the browser and being able to listen to the events in the browser and on the other hand to inject events into the browser.
The embedding of the browser into a separate window unfortunately does not work with all browsers anymore, requiring an alternative mechanism to be implemented.
4.1+ The WebDriver mechanism uses the Selenium WebDriver as link between the browser and QF-Test, the WebDriver having become a W3C standard for controlling of web browsers (http://www.w3.org/TR/webdriver/).
Note For reasons inherent to WebDriver, unfortunately, the WebDriver connection mode is not yet on par with QF-Driver mode in terms of performance and feature completeness (see subsection 45.3.3). For the time being we recommend to primarily use QF-Driver mode for recording.
Note QF-Test needs to deep inspect the browser content in order to enable the familiar testing features (e.g. event and check recording, feature based component recognition, web and custom resolvers) in WebDriver mode. With some browsers this might trigger in a warning related to mixed content display or an untrusted certificate. If this warning or error message only appears while running the web site in testing mode, you can safely ignore it.
|Recognition of web components and toolkits|
With web applications developers are quite free as to how to implement graphical objects with HTML, leading to a multitude of different implementations for functional GUI components like buttons, text fields, data tables etc. Some samples for an OK Button:
<span class="btn" name="ok2">OK</span>
By default, QF-Test records the GUI elements with the HTML tag as class plus basic features for recognition.
For the first sample QF-Test would record a component of the class
ok1 and the structure and geometry as resulting from the
GUI. When replaying the tests, the component recognition should work all right.
Moreover, QF-Test checks whether the HTML implementation is a quasi-standard, and if so,
maps the object to a generic QF-Test class. In the first sample this would be the case
and the component would be recorded as
One benefit of generic classes is that QF-Test additionally records class specific features for component recognition, e.g. the text of a button would be saved in the 'Feature' attribute. Another advantage are the class specific checks, like a check for a whole row or column with tables. For more benefits of generic classes please read the introduction of Generic classes. For detailed information on class specific features please have a look at Properties of generic classes.
There is a variety of web frameworks on the market, such as Angular, React and Vue.js, which are very helpful when creating web pages. Each of the frameworks has its own implementation of GUI objects.
The second sample could be from a framework using the css class
For some web frameworks the mapping of the GUI elements to generic classes has already been implemented with QF-Test. For such frameworks you can work with the stable component recognition you are used to with QF-Test. For more information please refer to Special support for various web frameworks. By default, QF-Test should automatically recognize the web framework used to implement the application. Else you can choose the correct framework manually.
The third and the fourth sample do not follow any standard. For sample three the
standard component recognition would probably be sufficient regarding stability
because of the
name attribute. The fourth sample would not
have a good standard component recognition. However, it has an HTML attribute defining
the functionality of the node. In both cases you could map the defining attribute
to the generic class
Button. For detailed instructions please refer to
Improving component recognition with a
Note We recommend checking which category the GUI objects of the application to be tested belong to before starting test automation. In case standard recognition should not be sufficient we recommend to improve it by mapping the GUI objects to generic QF-Test classes as described in section 45.1.
Note Working with several browser windows is explained in FAQ 25.
|Cross browser tests|
Cross browser tests are easy to implement. You can implement test cases working on
one browser and then replay them on other browsers. You just need to
implement a Data driver defining adequately the variable
If you want to try it out just open the web demo test-suite and add a 'Data driver' node in the
(To open the demo test-suite select the menu item »Help«-»Explore sample test-suites...« and click the
'open' link behind 'Web CarConfig Suite'.)
||Figure 14.1: Cross-Browser Tests|
Then the four test sets which are in the same test set as the data driver will be run once for each of the browsers.
|Emulation of mobile browsers|
4.2.1+ An important aspect of web page testing is the user experience on mobile devices like smartphones or tablets, since due to varying browser identifiers ("user agent") and device-specific screen sizes rendering of web pages differs between mobile and desktop browsers ("responsive design").
QF-Test supports such scenarios by emulating mobile browsers: A desktop browser (e.g. Google Chrome) is started in a special mode, where the page size and the browser identifier mimics those of browsers on mobile devices.
Google Chrome in particular is able to simulate specific characteristics of mobile browsers like adjusted pixel ratios and automatic scaling of non-responsive web pages.
To use mobile emulation in QF-Test, select the corresponding entry in the Quickstart wizard (see chapter 3) and specify the required device parameters, together with the URL of the web page and additional test requirements. QF-Test ships with a great number of predefined definitions of well-known mobile devices, which can be freely adapted as needed.
For a demo please open the test-suite 'carconfigWeb_advanced_en.qft' and run the test-set 'Emulation of Mobile Devices'. An easy way to open it is via the menu »Help«-»Explore sample test-suites...« and then selecting the 'open' link behind 'Web CarConfig Suite' (at the very bottom).
|Web-Tests in headless mode|
4.2+ Using the WebDriver connection mode it is possible to run Firefox, Chrome and the modern Edge in a so called "headless" mode. In this mode, the browser is started in the background, without any visible window on the screen. All interactions with the web page are executed inside this "invisible" window.
A use-case for headless browsers might be load testing (section 27.5). Or you could use it for tests you want to run in the background on the same machine as you are developing tests on.
To execute an existing web test using the "headless"-mode, simply change the type of browser in
the 'Start web engine' step from
headless-firefox, or from
headless-edge. Please note that the "headless"-mode
is only supported since Chrome 60 and Firefox 57, and only for the Chromium based Edge on Windows.
|Integrating existing Selenium web tests|
You can run existing Selenium Scripts with QF-Test when using the WebDriver mode.
Another option is embedding Selenium Scripts as Unit tests, as described in chapter 13. As a nice side effect, you get an integrated report including the executed Unit tests.
For a demo please open the test-suite 'carconfigWeb_advanced_en.qft' and run the test-set 'Integrating Selenium tests'. An easy way to open it is via the menu »Help«-»Explore sample test-suites...« and then selecting the 'open' link behind 'Web CarConfig Suite' (at the very bottom).
|Selecting the browser installation|
If you use the WebDriver mode, you are no longer limited to Firefox if you want to specify a browser installation folder using the attribute 'Directory of browser installation' of the 'Start web engine' node. If no matching browser can be localized in the specified directory, an exception will be thrown. If no directory is specified, QF-Test will try to start a default browser of the given browser type.
|Last update: 9/13/2020
Copyright © 1999-2020 Quality First Software GmbH