How-To: GUI Testing Remote Embedded Devices

How-To: GUI Testing Remote Embedded Devices

New to Squish 6.6 is a fully-integrated remote control solution for improved testing of remote systems. With it, you can display the screen of the remote device in real-time as a test is executed, and even record new tests, including picking objects for inspection, even if the application under test is running on a computer in a remote location. This functionality removes the need for any additional remote desktop solution, and works for virtually any target, including embedded systems.

The best part? It’s a one-click solution. The data required for its operation is embedded within regular Squish communication. No longer will you have to worry about external remote control tooling problems of interoperability, compatibility, network setup, or multi-platform AUT requirements. In Squish 6.6, a click of a button displays your remote system’s GUI locally on your machine, with no special configuration or setup.

Remote Testing of an Embedded Device

We will demo this new feature using a mock-up of an In-Vehicle Infotainment (IVI) system running on a remote Raspberry Pi embedded board. The UI itself — Neptune UI — was developed in the Qt Automotive Suite and is implemented with QML.

Qt's Neptune UI Developed in Qt Automotive Suite
Neptune UI Touchscreen Display.

The vehicle’s passengers would increase or decrease the temperature to their comfort using the IVI touchscreen:

Neptune UI Screen for Changing Passenger Air Temperature
Passenger Heating and Cooling Settings.

You’ll notice the „+“ and „-“ buttons to set the desired temperature. Each press of the button increases or decreases the air temperature by 0.5 deg C.

We will utilize Squish to write an automated test which increases the driver’s side air temperature and then verifies that the display reading updates correctly. We will walk through using the Remote Control feature step-by-step:

Step 1. Set the remote AUT’s Hostname and Port

Within the Squish IDE, we navigate to Edit > Server Settings, and click Add... to define an Attachable AUT.

We set a representative name, and give the Host and Port number, as in the below screenshot:

Squish Server Settings for Defining Attachable AUT
Add Attachable AUT Server Settings.

Step 2. Verify the AUT launches

Squish allows you to display the screen of the remote AUT, even outside of record and replay. To verify our connection to the remote system, we’ll launch the AUT, using Run > Launch AUT.

In the icon bar, click on the Remote Control icon.

The ‚Squish Remote Control‘ window should appear, displaying the GUI of our AUT. We’ll go ahead and quit the AUT, and begin recording.

Step 3. Record test case

The remote control functionality is not simply to display your AUT. You can actually pick and inspect objects as if your application is running locally. In a new test case, we click the Record button. The familiar Control Bar will appear. We’ll click on the Remote Control button to display our AUT.

Squish Control Bar: Remote Control
Squish Control Bar: Remote Control.

We can now record as usual. According to our test requirements, we need to click the „+“ button on the touchscreen to increase the air temperature. We will increase temperature by 2 deg C, which requires four clicks.

Next, we want to verify the display reading updated correctly. We’ll insert a Property Verification Point using the Control Bar.

Squish’s Picker tool can be used for picking UI controls on the remote target. We’ll click the display reading (23 deg C) and set the VP. Our recorded script now looks as in the following code block:

# -*- coding: utf-8 -*-

import names

def main():
    attachToApplication("NeptuneUI_AUT")
    mouseClick(waitForObject(names.o_Label, 27015292))
    mouseClick(waitForObject(names.o_Label))
    mouseClick(waitForObject(names.o_Label))
    mouseClick(waitForObject(names.o_Label))
    test.compare(str(waitForObjectExists(names.o23_Text).text), "23")

To improve readability, portability and maintenance, we’ll refactor our script to give more meaningful object names, covered next.

Step 4. Refactoring

To make our test more concise, let’s re-work our touchscreen presses. We’ve written a helper function which simulates the passengers‘ touchscreen presses by consuming the degrees to which the driver wishes to increase the temperature:

def tempIncrease(deg):
    presses = deg * 2;
    for i in range(presses):
        mouseClick(waitForObject(names.tempIncreasePress));

We’ve also renamed the vague o_Label object using the IDE’s built-in refactoring capabilities. Finally, we’ve refactored our VP for concision:

def isTempDisplayed(num):
    try:
        obj = waitForObjectExists( {"container": names.o_QQuickView, "text": num, "type": "Text", "unnamed": 1, "visible": True}, 5000)
        return True
    except LookupError:
        return False

Our refactored test case reads as follows:

# -*- coding: utf-8 -*-
source(findFile("scripts", "script_func.py"))

import names

def main():

    attachToApplication("NeptuneUI_AUT")
    #increase the temperature by 2 deg C
    tempIncrease(2)
    # verify the temperature reading
    test.verify(isTempDisplayed(23), "Expected Display Temperature Should Be 23")

We can then playback our refactored script and view the execution through the remote control video stream, as if the AUT were running locally on our machine. You’ll note the minimal effort required to test our embedded device: we simply set the AUT in Squish’s server settings, and the rest was a click away.

Additional Remote Control Settings

There are additional settings to remote control to aid in testing, a few of which are described below. These are available in the ‚Squish Remote Control‘ window.

  • Disable Inputs. This button disables the user inputs forwarding. When enabled, the Remote Control dialog functions in view-only mode. This is useful to avoid interference with remote test case execution which is sensitive to the position of the cursor.
  • Remote Keymap. This button switches the key-press handling mode from local-keymap to remote-keymap. In the remote-keymap mode, the keys are forwarded as key codes and interpreted on the target OS using its current keyboard map. In the local-keymap mode, the keys are interpreted as symbols by the IDE using the local keyboard map and forwarded as symbols.
  • Extra Keys. This button activates buttons on the remote device which do not map to a regular PC keyboard, for example, volume buttons on the side of a smartphone or other controls on embedded devices.

Wrap-Up

Squish 6.6’s click-and-play remote control functionality greatly improves working with remote systems, whether they are desktop, mobile or embedded targets. The added convenience will allow you to record, replay, write, debug and execute tests on your remote device with improved speed and efficiency, without the sometimes complicated setup of external remote desktop software.

Nick joined froglogic Marketing in 2018, following graduate study in computational mechanics and various Application Engineering roles within the software sector. When he’s not blogging for froglogic, he enjoys testing vegan recipes, reading poetry and modding his Subaru.

0 Kommentare

Eine Antwort hinterlassen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*