The following options are used specifically for web testing.
||Figure 35.27: Web options|
Use the ID of a DOM node as the component name, provided the ID is sufficiently unique. Uniqueness is determined per node type and depending on the setting of the options Name override mode (replay) and Name override mode (record).
Note Of course this option only changes the way QF-Test treats ID attributes. The attributes themselves are left unchanged or the application would most likely no longer work.
With this option activated QF-Test removes all numerals from 'ID' attributes to prevent problems caused by automatically generated IDs often found in Ajax frameworks like GWT. Such dynamic IDs can change after the slightest modification to a web application which causes tests to break, especially if names are based on IDs. By removing the dynamic part from such IDs they become less useful, because they are no longer unique, but also less harmful. Uniqueness of names is taken care of by QF-Test. Since IDs also serve as a basis for 'Feature' and 'Extra features' attributes, this option is helpful even if IDs are not used as names.
If this option is active, all pages coming from the same host are recorded as the same page by reducing the URL feature to the host part of the URL. This is often useful when pages share a common look and navigation structure.
For file URLs, the URL is reduced to the filename, with intermediate directories removed.
When recording mouse events on DOM nodes in a web page it is often useful to ignore "trivial" nodes and concentrate on the important ones. For example, when clicking on a text hyperlink it is typically not of interest whether part of the link is formatted with a bold font. It is the link that is important.
If this option is active QF-Test does not simply record the event for the deepest DOM node under the mouse cursor. Instead it moves up the hierarchy until it finds an "interesting" node. In the example above, QF-Test would record the event on the <A> node with the option active and on the contained <B> node otherwise.
Normally QF-Test's component recognition is tolerant to changes in the component hierarchy. For web pages with deeply nested tables this can lead to performance problems because the potential variants of determining the target component grow exponentially with the nesting depth. If you experience such problems, try to deactivate this option. It will reduce adaptability but should help with performance.
Note The by far preferable solution is to set unique ID attributes for the different tables and other components so that QF-Test's name override mechanism can apply. This not only speeds up recognition drastically, it is also much more reliable and tolerant to change.
Similar to AWT/Swing or SWT, QF-Test normally only recognizes visible DOM nodes as target components. However, visibility of DOM nodes is not as well defined as that of components in a Java GUI. For example it is possible that an invisible DOM node has visible child nodes. Also, if a web page contains illegal HTML constructs it is possible that a DOM node is considered invisible, even though it is displayed in the browser window. If you come across such a problem you can turn off this option.
When recording checks, components or procedures QF-Test needs to determine the target element under the mouse cursor. In case of overlapping nodes there are two different ways for calculating which one should be used. By default QF-Test lets the browser decide, which is usually the best choice. Since the different browsers don't always behave in the same reliable way, this option can be turned off in case of problems to use the older mechanism based on the z-order of elements instead. This option has no effect on check replay.
The possible choices for the option "Error level" are "Error" and "Warning". We advise that you set it to "Error" and make sure that such problems are reported to development and fixed sooner rather than later because they can represent a bug in the application you are testing. Known messages that are not going to be fixed by development can be excluded and ignored via the option Errors that should be ignored.
In case a web page contains erroneous code it is possible that a lot of errors are triggered. Logging all those errors can significantly impact test performance, yet logging more than the first few errors does not really contribute much. The option "Maximum number of errors to log per SUT client" limits the possible number of error messages for this case.
These options influence the behavior of HTTP requests.
||Figure 35.28: Options for HTTP Requests|
Note HTTP request tracking is supported for browsers in QF-Driver mode only. It does not apply to WebDriver based tests or to browsers embedded in Java like WebView.
Because most things in AJAX based web applications run asynchronously, one of the main challenges in testing such applications is timing. QF-Test uses various means to synchronize with the SUT and this option controls one of them. If turned on, QF-Test will keep track of all HTTP requests the browser sends to the server. Before and after replaying an event, QF-Test will wait until no requests are outstanding. The following two options Timeout for HTTP request synchronization (ms) and Extended HTTP request timeout for new documents (ms) are used for fine-tuning this feature.
When synchronizing with the SUT by tracking HTTP requests as explained for the option Synchronize with HTTP requests, QF-Test cannot wait indefinitely for outstanding requests as this would impact test performance too much. This option defines the maximum time to wait for outstanding requests in normal situations and the following option Extended HTTP request timeout for new documents (ms) is used right after a page has finished loading.
When recording HTTP Requests a 'Browser HTTP request' is created. This request will be submitted directly via the browser so that the response is shown afterwards and test execution can be continued directly in the browser. By deactivating this option a 'Server HTTP request' will be recorded. This request will be submitted by QF-Test and doesn't have any effect on the browser. The response is only accessible in QF-Test.
These options can re-set QF-Test to older behavior. Those settings have changed that much that QF-Test cannot keep backward compatibility over all versions.
||Figure 35.29: Options for web backward compatibility|
In versions older than 4.2.0 'Check text' and 'Fetch text' nodes provided too much or too less text for components of generic classes in some cases. Especially
TableCell components containing text-fields returned wrong text. Now the any child component with a generic class will be taken into account.
Older QF-Test versions than 4.2.0 turned all underscores into blanks once 'Extra features' were compared. This behavior could cause troubles in case you were really searching for underscores.
|Last update: 07/26/2018
Copyright © 1999-2019 Quality First Software GmbH