Qf test

Author: s | 2025-04-25

All QF-Test licenses are floating, e.g. not tied to individual computers or users (unlike node locked licenses which are tied to a single user). UI technologies: QF‑Test/web, QF‑Test/swing, QF‑Test/swt, QF-Test/fx, QF-Test/win, QF-Test/android, QF-Test/ios and all

Manual - QF-Test - QF-Test

QF-Test maintenance release 7.0.6 & 7.0.7 | NEW: Expert Day via Webinar in November Hello dear QF-Test users!The critical vulnerability in the WebP graphics library, which affects many kinds of software products, including all browsers, has made high waves in the IT world over the last two weeks. Since QF-Test also uses this library, we first replaced it in version 7.0.6 and updated the embedded Chrome browser for QF-Driver on Windows in today`s release QF-Test 7.0.7.In addition, we have a new training format for you: On November 20, 2023, we offer an expert day on the topic "Toolbox for stable component detection of web applications". In this online training, we will dive deeply into QF-Test and show you how to optimize the interaction with your web application. There will be time for exercises on special topics and your personal questions.Best regards, your QFS team QF-Test maintenance release 7.0.6 & 7.0.7 QF-Test versions 7.0.6 and 7.0.7 are our timely response to the critical security vulnerability in the widely used graphics library WebP. To that end we first updated the library itself (7.0.6) and now upgrade the embedded Chrome browser for QF Driver on Windows to CEF version 117 (7.0.7).Download QF-Test version 7.0.7To the Release NotesFor more information about the WebP vulnerability, as well as measures for securing older QF-Test versions please see our blog postMitigation of the WebP 0-day vulnerability CVE-2023-4863 in QF-Test. Save the date: Events in 2023 QF-Test Basics: Training via WebinarNovember 6–9, 2023 4 days, 2 × 2,5 hours each Effective and rapid knowledge transfer in small groups up to a maximum of 8 participants.Interaction with the trainers and asking questions are possible at any time.➜ Sign up nowWould you like a training course which is individually tailored to your company? Just send us an email to [email protected]: Online Expert DayToolbox for stable component detection of web applicationsNovember 20, 2023, 2 × 2,5 h "Yesterday my test was still working. What is going on now?" In this online training, we will dive deeply into QF-Test and show you how to optimize the interaction with your web application. There will be time for exercises on special topics and your personal questions.➜ Details, pricing and registrationFree special webinarTest the smart way with SmartIDFebruary 5, 2024, 15:30 CET "SmartID" is a completely new way to address the UI components of your application which we continue to tweak and improve. In this

QFS Newsletter QF-Test 4.1.2 Released - QF-Test

The call syntax for interactive and batch mode varies widely since some command line arguments are specific to interactive mode or batch mode or even sub-modes of batch mode. Note that all of the arguments have sensible default values which you only need to override for special cases. In most cases you'll only need to execute either qftest [ | ]* to run QF-Test in interactive mode, or qftest -batch [-runlog []] [-report ] to execute a test in batch mode. 5.2+ For maximum flexibility the names of all QF-Test arguments are case-insensitive and embedded '-', '_', '.' and ':' characters are ignored, so -report.html is equivalent to --reportHtml or -report-html. The latter is the officially documented form because it avoids conflicts with Windows PowerShell. WindowsThe program qftest.exe is a Windows GUI application. When started from a command shell, it will not wait for QF-Test to terminate but return immediately. Thus, when executing a test in batch mode, you cannot see whether QF-Test has finished or not (you may put the command into a .bat file to deal with this behaviour). Furthermore you won't see any output from QF-Test in the console window when using qftest.exe. For both reasons you may prefer to utilize the qftestc.exe Console application when launching QF-Test from a command shell: It waits for QF-Test to terminate and print output from Server scripts will be displayed in the console window. Apart from that, everything said about qftest.exe in this chapter holds true for qftestc.exe too. Mac In case the macOS App is used those parameters can be defined directly in QF-Test via »Edit«-»Options« under General->Startup (please also see the macOS specific note under Starting QF-Test). Interactive mode The full call syntax for interactive mode is: qftest [-dbg] [-java (deprecated)] [-noconsole] [-J]* [-allow-shutdown []] [-daemon] [-daemonhost ] [-daemonport ] [-daemonrmiport ] [-dontkillprocesses] [-engine ] [-groovydir ] [-help] [-ipv6] [-javascriptdir ] [-jythondir ] [-jythonport ] [-keybindings ] [-keystore ] [-keypass ] [-libpath ] [-license ] [-license-waitfor ] [-logdir ] [-noplugins] [-noupdatecheck] [-option =] [-options ] [-plugindir ] [-port ] [-reuse] [-run] [-runlogdir ] [-runtime] [-serverhost ] [-shell ] [-shellarg ] [-suitesfile ] [-systemcfg ] [-systemdir ] [-tempdir ] [-test |]* [-usercfg ] [-userdir ] [-variable =]* [-version] [ | ]* There are several sub-modes for running QF-Test in batch mode. The default is to execute one or more test suites. Alternatively QF-Test can be invoked to create test documentation from test suites or reports from run logs. QF-Test can also be run in daemon mode where it sits in the background waiting for calls from the outside telling it what to do (see chapter 55 for further information about the daemon mode). Finally, showing help or version information can also be seen as separate sub-modes. Test execution To execute one or more test suites and create a run log and/or report as a result, use: qftest -batch [-run] [-dbg] [-java (deprecated)] [-noconsole] [-J]* [-allow-shutdown []] [-clearglobals] [-compact] [-engine ] [-exitcode-ignore-exception] [-exitcode-ignore-error] [-exitcode-ignore-warning] [-groovydir ] [-ipv6] [-javascriptdir ] [-jythondir

The Tutorial for the Test Tool - QF-Test - QF-Test

Generic components. The tester is able to concentrate on elements that are visible and relevant for testing without special knowledge of the technical architecture of the website. This results in an efficient test creation with a fast ROI."Extending the CustomWebResolver is easy and uncomplicated - even with toolkit specific classes. Thanks to the Quickstart Wizard creating the project was fast and unproblematic and we could use it immediately. This is the reason why QF-Test will stay a top tool in the test automation field for TAC."Bernhard Rappold, Director Software DevelopmentTAC | The Assistant Company, Hartberg, Austria"After two major versions we abandoned Selenium due to this high maintenance effort."Read moreAttila Enez, TesterHamburger Pensionsverwaltung, Hamburg, Germany UI Testing of Electron applications Electron is a framework for executing cross-platform desktop applications using the web browser Chromium and the Node.js framework. With Electron Web applications can can be delivered as desktop standalone applications. QF-Test can test these applictions. Both the web application as well as the native dialogs can be tested.How to test Electron apps with QF-Test? Testing Webswing applications Java Swing, JavaFX, Applet and Netbeans applications can be displayed in a browser with the technology Webswing. QF-Test can test such applications, both the Java and the Web part can be accessed. Your existing Java tests with QF-Test can be reused in a Webswing system.More about Webswing Testing with QF-TestCross-browser testing with QF-Driver, Selenium-WebDriver & Chrome DevTools Protocol (CDP)Cross-browser testing Google Chrome, Microsoft Edge (Chromium based), Mozilla Firefox, Opera and Safari; Headless Browser versions of Chrome, Firefox and Edge (Chromium based)Chrome DevTools Protocol (CDP): faster and more stable alternative to WebDriverIntegration of Selenium tests via Unit test steps or via Selenium API Automated testing of your web framework The high-level API provided by the frameworks and toolkits enables developers to create applications with a. All QF-Test licenses are floating, e.g. not tied to individual computers or users (unlike node locked licenses which are tied to a single user). UI technologies: QF‑Test/web, QF‑Test/swing, QF‑Test/swt, QF-Test/fx, QF-Test/win, QF-Test/android, QF-Test/ios and all

Mobile Apps testing with QF-Test - QF-Test

Web UI Testing Features Real user simulation, directly in the browserCross-browser testing: Google Chrome, Mozilla Firefox, Microsoft Edge (Chromium based), Opera and Safari Headless Browser versions of Chrome, Firefox and Edge (Chromium based)Chrome DevTools Protocol (CDP) and Selenium WebDriverMobile Web applications via Mobile Browser EmulationTesting of Electron applications, Webswing, JProAll QF-Test FeaturesPressing the play button will load a video from our external provider YouTube.Privacy PolicyWatch our video overview "Testing web applications with QF-Test" QF-Test makes the test automation of your web application robust and less complex QF-Test simplifies deeply nested DIV hierarchies back to logical UI elements Web application testers face particular challenges: In HTML, there are few concepts for logical GUI elements such as trees, so developers often come up with something themselves. A simple tree component is then represented by dozens of individual DIV nodes. This explosion of complexity has to be compensated for later by test developers.QF-Test offers an innovative solution to this problem:To “teach” your specific application to QF-Test, use our intuitive CustomWebResolver. With the help of simple assignments, without programming code, you translate HTML structures into easily understandable, logical components. This already works out-of-the-box for many common UI frameworks, so you benefit directly from the advantages of the QF-Test component concept.Testers can then work independently with QF-Test and your web application without having to know the underlying HTML structure. Challenges of web pages Varied presentation of particular components in different browsers.Increasingly dynamic interface design via JavaScript.The UI-components (Widgets) have a very different structure to conventional 'fat clients' with diverse design characteristics.Reusability of test only, if the components can be found again in the modified UI. QF-Test's solution QF-Test meets this challenge with a component concept that provides a specific component recognition for every toolkit. It works like this: The special components are transferred in familiar

Web UI testing with QF-Test - QF-Test

I User manual20 Testing Java desktop applications in a browser with Webswing and JPro 5.2+ Webswing and JPro are two fascinating solutions that bring Swing and JavaFX desktop applications into a browser. The underlying technologies, concepts and goals differ significantly, but the challenge for QF-Test mainly boils down to the same thing: There are two SUT clients that need to be tested together in a coordinated way. Migrating existing applications is one of the most common scenarios, so the ability to reuse existing QF-Test tests for the Swing or Java desktop application is crucial. This is one reason why testing through the browser alone is not sufficient. The other reason is that in the browser QF-Test only sees either a CANVAS node with colored pixels (Webswing) or a hierarchy of very similar DIV nodes (JPro). Though the latter is at least moderately useful for testing and may become interesting for special cases like load testing, it is still very limited compared to the deep access QF-Test has to Java applications. Enter "JiB" - QF-Test's solution for "Java in Browsers". Note In addition to QF-Test engine licenses for Swing and/or JavaFX, JiB support requires QF-Test licenses for the web engine. A demo test suite for Webswing is provided for a better understanding of the concepts described in the section below. You can open it via the menu »Help«-»Explore example test suites...«, entry "Webswing SwingSet Suite". There is a short introductory video about Webswing testing available on our QF-Test YouTube channel. In

Java UI testing with QF-Test - QF-Test

System qftest -batch -interrupt-running-instances [-timeout ] Compress images in an existing test suite qftest -batch -compress + Get help qftest -batch -help Command line arguments for QF-Test fall in three categories. They can be mixed freely. These arguments are evaluated directly by the qftest shell script or executable and override settings determined during installation. On Linux these settings are stored in the file launcher.cfg in QF-Test's system directory, on Windows the file is called launcherwin.cfg. -batch Run QF-Test in batch mode. This causes QF-Test to load and execute a test suite directly and finish with an exit code that represents the result of the test run. -dbg Turn on debugging output for the starter script. The same effect is achieved by setting the environment variable QFTEST_DEBUG to a non-empty value. On Windows this causes QF-Test to open a console window to display the output that would otherwise be invisible unless the argument -noconsole is also given. This also turns on debugging output for the qfclient and java helper programs when using the old connection mechanism (see chapter 46). -java (deprecated) The Java executable used to run QF-Test. The default is java on Linux and javaw.exe on Windows, unless a different value was set during installation. This argument will be removed in a future version of QF-Test. -noconsole (Windows only) On Windows this argument suppresses the console window that would otherwise be opened in case -dbg is specified. You can pass arguments to the Java VM through the starter script by prepending them with -J, e.g. -J-Duser.language=en to set a system property. To set the classpath, prepend -J only to the -cp or -classpath argument, not to the actual value, e.g. -J-classpath myclasses.jar. When setting the classpath this way, QF-Test's own jar archives need not to be taken into account. The rest of the arguments are handled by QF-Test itself when it is executed by the Java virtual machine. These arguments can also be placed in a file using the syntax = for arguments with parameters or =true or =false to turn a simple argument on or off. By default this file is called qftest.options, located in the bin directory of QF-Test and used only for internal logging purposes. If you change anything in this file, you can move it to QF-Test's system directory so your changes will still apply after upgrading. Alternatively you can use the -options argument to specify a different file. Arguments given on the command line override arguments from an option file except for those which can be given multiple times. In the latter case the arguments are merged. -allowkilling Deprecated, use -allow-shutdown without shutdown ID instead. -allow-shutdown [] Explicitly specifies that this QF-Test instance can be cleanly terminated via a batch call with the -shutdown argument. An optional string argument can be provided as shutdown ID which allows selective process termination without knowing the process ID. The shutdown ID must contain at least one non-numeric character to be distinguishable from the numerical process ID. If -allow-shutdown

QF-Test News 2025 - QF-Test

QF-Test that this batch run serves to create test documentation from test suites. -genreport (batch mode only) Tell QF-Test that this batch run serves to create a report from run logs. -groovydir This argument overrides the default location of the directory for additional Groovy modules. The default directory called groovy is located under QF-Test's system directory. -help Show help about available command line arguments. -import (batch mode only) Import a given test suite into another one. This mode can be used to merge two test suites. -import-from (batch mode only) The source test suite, which should be imported into another one. -import-into (batch mode only) The target tests-suite for importing. -import-components (batch mode only) Switch for merging components of two given test suites. -import-procedures (batch mode only) Switch for merging packages and procedures of two given test suites. -import-tests (batch mode only) Switch for merging test cases and test sets of two given test suites. -interrupt-running-instances (batch mode only) Interrupt a test run on the current system and brings up a dialog which allows to pause or to interrupt the current test run. -ipv6 QF-Test uses only IPv4 communication, so by default IPv6 support is disabled at Java level which can reduce startup time significantly. In case you need to enable IPv6 support in QF-Test, for example for use within a plugin, you can use this argument. -javascriptdir This argument overrides the default location of the directory for additional JavaScript modules. The default directory called javascript is located under QF-Test's system directory. -jythondir This argument overrides the default location of the directory for additional Jython modules. The default directory called jython is located under QF-Test's system directory. -jythonport Tell the embedded Jython interpreter to listen for TCP connections at the specified port. You can then use telnet to connect to that port and get an interactive Jython command line. -keybindings (interactive mode only) Currently used only for macOS to switch between the new default Mac bindings (value system) or the old, Windows oriented QF-Test bindings (value classic). -keystore An alternative keystore file to use for securing daemon communication with SSL. See section 55.3 for details. To disable SSL by specifying no keystore, use this argument in the form -keystore=. -keypass The password for the keystore file used for securing daemon communication with SSL. See section 55.3 for details. -kill-kunning-instances Deprecated, use -shutdown all instead. -libpath Override the library path option (Directories holding test suite libraries). The directories of the library path should be separated by the standard path separator character for the system, i.e. ';' for Windows and ':' for Linux. QF-Test's include directory will automatically be appended to the path. -license Set the location of the license file (see section 1.5). -license-waitfor ; Specify an interval in seconds to wait during QF-Test startup in case a license is not immediately available. This timeout is also in effect when renewing a lease from the QF-Test license server and the server is temporarily unavailable. -logdir This argument overrides the default location. All QF-Test licenses are floating, e.g. not tied to individual computers or users (unlike node locked licenses which are tied to a single user). UI technologies: QF‑Test/web, QF‑Test/swing, QF‑Test/swt, QF-Test/fx, QF-Test/win, QF-Test/android, QF-Test/ios and all All QF-Test licenses are floating, e.g. not tied to individual computers or users (unlike node locked licenses which are tied to a single user). UI technologies: QF‑Test/web, QF‑Test/swing, QF‑Test/swt, QF-Test/fx, QF-Test/win, QF-Test/android, QF-Test/ios and all combinations out of them.

QFS - The GUI-Testing-Experts - QF-Test

Line length for saving test suites is used. -convertxml-utf8 (convertxml mode only) Whether to save the converted suites with UTF-8 (value true) or ISO-8859-1 encoding (value false). If not specified the value of the option Use UTF-8 encoding for saving test suites is used. -daemon Run QF-Test in daemon mode. Further information is provided in chapter 55. -daemonhost (daemon or calldaemon mode only) In calldaemon mode, specify the host where to locate the QF-Test daemon. The default is localhost. When starting a daemon, either in interactive or in batch mode, this parameter defines the hostname or IP address that daemon objects use at RMI level. The default in this case is chosen by Java, typically the IP address of the primary local network interface. -daemonport Specify the registry port for the QF-Test daemon to listen on and to connect to respectively. The default is 3543 or the port defined with -port . -daemonrmiport Specify the port that the QF-Test daemon should use for RMI communication. Useful only when running the daemon behind a firewall. When running unprotected without SSL (see section 55.3) this can be identical to the daemon port specified with -daemonport . If using SSL, two different ports are required. -dontkillprocesses (batch mode only) When finishing batch execution, don't explicitly kill processes started by QF-Test as part of the tests. However, whether or not a sub-process of QF-Test survives QF-Test's exit is system-dependent. -engine Specify which engine license(s) to use. This option is only useful in case the QF-Test license contains a mix of GUI engine(s) with different numbers of engine licenses. In that case it may be necessary to specify the engine license(s) to use in order to prevent license conflicts with colleagues using the same license. Possible values are "all" to use all supported licenses, "ask" to bring up a dialog for engine selection or any combination of "awt" for AWT/Swing, "fx" for JavaFX, "swt" for SWT or "web" for Web, e.g. "awt,web". This is explained in more detail in subsection 41.1.9. -exitcode-ignore-exception (batch and calldaemon mode) For exit code calculation exceptions, errors and warnings are ignored. This means if exceptions, errors or warnings occurred during a test run the exit code will be 0. This option is helpful when integrating QF-Test with build tools that rate a build as failed dependent on the the exit code. -exitcode-ignore-error (batch and calldaemon mode) For exit code calculation errors and warnings are ignored. This means if just errors and warnings occurred during a test run the exit code will be 0. This option is helpful when integrating QF-Test with build tools that rate a build as failed dependent on the the exit code. -exitcode-ignore-warning (batch and calldaemon mode) For exit code calculation warnings are ignored. This means if just warnings occurred during a test run the exit code will be 0. This option is helpful when integrating QF-Test with build tools that rate a build as failed dependent on the the exit code. -gendoc (batch mode only) Tell

QF-Test 4.1.4 Released - QF-Test

IV Technical reference51 Web51.1 Improving component recognition with a CustomWebResolver Video: 'CustomWebResolver in QF-Test'. 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 text field 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), for the depth of the component hierarchy, whether complex components such as tables, lists, trees etc. have been mapped as such and the sub-items were addressed via index. You will find detailed information on the standard recording of HTML elements and criteria for deciding whether it is sufficient 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. All QF-Test licenses are floating, e.g. not tied to individual computers or users (unlike node locked licenses which are tied to a single user). UI technologies: QF‑Test/web, QF‑Test/swing, QF‑Test/swt, QF-Test/fx, QF-Test/win, QF-Test/android, QF-Test/ios and all

QF-Test 4.1.6 Released - QF-Test

November 2020, a special webinar took place about Webswing testing with QF-Test. Here you can find the special webinar video recording available on our QF-Test YouTube channel. With the JiB concept QF-Test treats the Swing or JavaFX application as the primary SUT. Nearly all interaction is triggered through the respective Swing or JavaFX SUT engine. QF-Test also opens a browser window and uses its web engine to interact with this frontend through which the application is displayed and through which the user interacts with it. There are two modes of interaction between QF-Test and the application: Java mode QF-Test can keep the event handling entirely within the Swing or JavaFX application. In that mode the browser serves only as a trigger to launch the application, as a reference for the user and for handling special cases where the workflow in the application had to be adapted to use web interfaces, most notably for file upload and download. This mode is very similar to testing a plain Swing or JavaFX application, event simulation happens in an identical way. Images for image checks are taken via Swing or JavaFX off-screen-rendering to a memory buffer, also identical to the desktop version. Web mode What the above doesn't cover is the verification that the Webswing or JPro integration actually works end-to-end as expected, i.e. that the user really sees the interface as expected and that the user can interact with the application via mouse and keyboard through the browser. Though it is debatable to