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.
The vehicle’s passengers would increase or decrease the temperature to their comfort using the IVI touchscreen:
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:
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.
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.
The post How-To: GUI Testing Remote Embedded Devices appeared first on froglogic.