cuTeDriver Wiki

cuTeDriver is a TDriver fork. This Wiki page contains minimal information on the different cuTeDriver components, as well as their usage and installation.

Overview

cuTeDriver is a TDriver fork.

TDriver is a framework for remote execution, automatic testing, regression testing and even automated performance measurement for any Qt-based application.

A full cuTeDriver/TDriver setup consists of the following:

• SUT, or system-under-testing. This can be a device or Virtual Machine, and is not limited to only Linux-based platforms, anything that runs Qt-based applications can be used.
• A Host, which can be used to run automated testing runs or remote execution on the SUT.
• TCP/IP Connection between Host and SUT, through which the two platforms communicate with each other.

Applications can be remotely controlled either via Ruby-based scripts, or by using the Visualizer application.

The cuTeDriver components

agent_qt

• Device: SUT (optional on Host)
• Requirements: Qt 5.x (+ some additional packages on Linux depending on distro and Wayland/X11, see .spec files for hints)
• Tested Platforms: Linux (Wayland & X11), Windows (7/8), OS X (10.10 "Yosemite")
• Tested Qt versions: Qt 5.2-5.4
• Description:

agent_qt is the only SUT-side component required for cuTeDriver, and if you are working with a mobile device, the only component that needs to be set up on the actual target. Once agent_qt has been successfully setup, it can be used to start the qttasserver, either via the UI application (qttas_ui) or directly from command-line.

After the server is started, tested Qt/QML applications (started with the -testability flag) will then register with it. The qttasserver then handles communication between SUT and Host (via TCP/IP connection which needs to exist between the two), as well as controlling the application. A running qttasserver can also be used to start up applications from the Host-end on SUT.

Setting up and running agent_qt.

driver

• Device: Host
• Requirements: Qt 5.x, Ruby 1.9.X->
• Tested Platforms: Linux (gem compiles and installs fine on Windows, not tested due to visualizer issues)
• Tested Qt versions: Qt 5.2-5.4
• Tested Ruby versions: 1.9.1, 2.1.6
• Description:

cutedriver-driver is the portion of cutedriver, which does the actual remote control and running of scripts, and communicates via TCP/IP with qttasserver on the target device. For running automated tests via scripts, your host needs both the driver and sut_qt ruby gems.

Setting up and running driver and sut_qt.

sut_qt

• Device: Host
• Requirements: Qt 5.x, Ruby 1.9.X->, driver
• Tested Platforms: Linux (gem compiles and installs fine on Windows, not tested due to visualizer issues)
• Tested Qt versions: Qt 5.2-5.4
• Tested Ruby versions: 1.9.1, 2.1.6
• Description:

sut_qt is the second ruby gem required for remote execution of testing scripts, and contains the SUT related info, as well as a default SUT implementation on the host device itself.

Setting up and running driver and sut_qt.

visualizer

• Device: Host
• Requirements: Qt 5.x, Ruby 1.9.X->, driver, sut_qt
• Tested Platforms: Linux (interface issues on Windows)
• Tested Qt versions: Qt 5.2-5.4
• Tested Ruby versions: 1.9.1, 2.1.6
• Description:

Visualizer is the graphical Qt frontend for cuTeDriver, which allows remote testing of the UI directly throuh a screenshot preview, viewing of the UI element structure as well as running of Ruby scripts and commands.

Setting up and running visualizer.

Scripting

See pages:
Basic Scripting Info
Basic Scripting Info

Using Docker to run scripts

Docker example file can be found from https://github.com/rferrazz/docker-cutedriver

Lets suppose you have a functional test file called test.rb that you want to execute into your target device with IP 10.4.4.224 which is running qttasserver.

In order to run the test you need to create your parameters.xml file indicating the ip address of the remote device.

<parameters>
	<sut id="sut_qt" template="qt">
		<!-- ip address of the device to test -->
		<parameter name="qttas_server_ip" value="10.4.4.224" />
	</sut>

	<parameter name="behaviours" value="behaviours.xml"/>
</parameters>

Then you can run your test script with:

docker run -t -i --rm -p 55535:55535 -v $(pwd)/parameters.xml:/etc/tdriver/tdriver_parameters.xml -v $(pwd)/test.rb:/root/test.rb rferrazz/cutedriver test.rb

This section is by courtesy of rferrazz

Current Known Issues

• Host-setup on Windows suffers from issues (contact for details).
• If your application uses QCommandLineParser, you will need to add an option for the -testability flag, with a suitable comment.