qtestctl (also known as the qTest Controller) was officially introduced in qTest OnPremise 8.7.3 (Fall 2017). This component's main purpose is to provide provisioning capability for native Windows and Linux deployments and serves these functions:
- Coordinate the execution of all qTest applications
- Download dependencies from the internet (for the web installer)
- Initialize or upgrade database schema
- Manipulate application properties files
Behind the scenes, qtestctl is a renamed Gradle Wrapper, so any general configurations that are applicable for Gradle Wrappers should be applicable for qtestctl. You can see all available configurations using "--help" For example: ./qtestctl --help
Due to its custom nature, users should not experiment on their own without QASymphony's help. However, here are some basic configuration options that can be used safely with qtestctl.
- --help: display all available options of qtestctl
- --info & --debug: outputting a more detailed log into the standard output of qtestctl
- --offline: do not download from the internet and use the application version in the package
By design, a single qtestctl process can provision and control all qTest applications processes under it. This is configured by listing the product names in the "apps" properties of the configuration file, qtest.config.
By listing the product name(s) here, each server can process one or all qTest applications. In other words, for each server in your deployment model, you only need to have 1 single qtestctl (both folder and process).
Upgrading from an Older Version
If you already have qTest applications installed and want to upgrade to a newer software version, you should store the new qtestctl versions into a separate renamed folder. Do NOT override an existing qtestctl version with the content of a newer one.
- NOTE: Only use this mode for testing and troubleshooting a deployment. For production usage, we should run qtestctl as a system service
qtestctl is a foreground console application (which has no GUI), which can be started by entering qtestctl start in the console. When running, the qtestctl will block the standard input and will output its log to the standard output and its error (or debug information) to the standard error. This can be found as output on the console:
At this point, the process will listen for a break command (Ctrl + C) from the standard input or SIGINT from the system to terminate all its child processes (qTest Applications) and stop.
To allow qtestctl to run as a system service (or daemon) process in the background, which can be started up after a system reboot, we either use NSSM for Windows or systemd for Linux as a thin bootstrapper for qtestctl. This doesn't limit the capability of using other technologies to do something similar. For example, using Upstart to daemonize qtestctl on Ubuntu 14.04 or even SystemV in other environments.
The provided "install" script inside the qtestctl package is to only setup qtestctl as a service (it does not handle the configuration of qTest applications) on the current system either by NSSM or systemd, and you only need to do it once for each server.
- Make sure you execute these commands under "root" on Linux or "Administrator" on Windows.
- You only need to "install" once for each server/VM. Attempting to install multiple times on the same server will result in errors, which indicates that the system service already exists.
- Installation/uninstallation of the qtestctl as a system service is an entirely separate procedure from configuring qTest applications (which is handled by qtestctl). If necessary, you can retry the service installation/uninstallation multiple times without affecting the data or the configuration of qTest applications.
[root@localhost qtestctl]# ./install
[root@localhost qtestctl]# ./uninstall