Hardware Abstraction Layer (HAL)

The purpose of the HAL is to provide abstraction from platform-specific hardware composition, including device drivers, and serve as a framework engine.

Target abstraction

2.4.3.1 Target abstraction

By ensuring abstraction from the specific target, changes to hardware configuration and device driver implementations will not affect the application code, improving robustness against hetero- geneous platforms as additional platform support only requires a new HAL implementation. Figure 2.12 shows how the HAL interface enables easy extension of platform support by intro- ducing a new concrete HAL implementation.

Figure 2.12: TouchGFX target abstraction through HAL.

When creating a concrete HAL implementation for TouchGFX, the most important aspects are the operating system (OS) and the device drivers.

• The target OS used in embedded development may vary significantly in size and features. As additional features introduce overhead and greater hardware requirements, low-resource embedded development tends to focus on the minimal OS such as FreeRTOS and TinyOS. The recommended approach to TouchGFX is to utilize the FreeRTOS distribution in order to enable low-resource, real-time execution of the GUI application. In essence the FreeRTOS distribution supplies threading facilities and resource management for a multitude of target platforms [3]. However, as there is no concept of multiple processes in FreeRTOS, but rather a scheduled and prioritized execution of multiple tasks, running parallel processes is not an option. This means that a test framework can not be completely separated from the AUT as they must be compiled together and will compete for the processor.

• Target device drivers are software interfaces enabling the use of physical peripheral devices, e.g., Universal Asynchronous Receiver/Transmitter (UART) and Analogue-to-Digital Con- verter (ADC) components.

The TouchGFX distribution provides graphical device drivers for several platforms, but no implementations are included for other peripheral components. Utilization of such compo- nents and device drivers are thus subject to application-specific implementation, which may be placed in the back-end.

Provided with the TouchGFX distribution are a Windows and a Linux simulator. The simulators are based on SDL1, which is a cross-platform library providing access to keyboard and mouse in- put as well as graphical output. By using SDL in the concrete HAL implementation, a TouchGFX application may run on a computer in Windows or Linux.

2.4.3.2 Framework engine

The HAL is responsible for forwarding events to the TouchGFX core. In this respect the HAL can be said to constitute the engine that drives the TouchGFX framework. Apart from forwarding

Chapter 2. GUI Testing of Embedded Systems

touch events, the HAL forwards lower-level tick and vsync events to the application. A tick event is a simple abstraction of the target clock, while a vsync event indicates that the framework has finished processing GUI instructions and rendering the graphics. Knowing when the framework has finished rendering allows the core to postpone further instructions to the HAL until the GUI has reached a stable state. Related to the temporal synchronization problem, described in Sec- tion 2.2.3, this is an important feature in a test automation framework as it enables the framework to discern when the AUT is idle and ready for new instructions.

The vsync event is utilized by our GUI testing framework in order to synchronize with the AUT. This process is described in Section 4.4.

CHAPTER

3

An Automated GUI Testing Framework

This chapter describes the conceptual design of an automated GUI testing framework. The design enables automated GUI testing of embedded applications on low-resource devices. Besides the overall design of the framework, this chapter presents the detailed design of the host framework in a partitioned architecture. An extended design including the Application Under Test is presented in Chapter 4.

3.1.

Overview

The framework presented throughout this chapter enables automated GUI testing of embedded applications on low-resource devices. This ability is at the core of the thesis goals presented in Chapter 1, and it is achieved using methods and technologies presented in Chapter 2 along with methods from related work presented in this chapter. The design is validated in Chapter 5. Assumptions made for the design are described in Section 3.2 and related work is described in Section 3.3. The design itself is described in Section 3.4 and is discussed in Section 3.5.

3.2.

Assumptions

When using the GUI testing framework, testers without any programming experience may write test specifications, but it is assumed that test libraries, as described in Section 3.4 below, are pro- vided by developers. Test libraries may specify application- and platform-specific configurations, such as using serial communication as the concrete method of communication between the frame- work and the SUT, which requires knowledge of the setup of test equipment.

Test libraries rely on a structured model of the GUI of the AUT, as described in Section 3.4.4.3 below. The test specification may refer to GUI objects such as buttons and textboxes by a logical name which maps to a GUI object in the model. This abstraction of the AUT is used by scriptless GUI testing frameworks, as described in Section 2.2.2, in order to enable test-driven development. Throughout this thesis it is assumed that this model is generated by a tester or developer using a GUI survey tool. In compliance with Section 1.3.3 the survey tool is out of scope for this thesis, but it is expected that the tool will extract and interpret a structure of GUI elements from the AUT similar to how the current state of the GUI is retrieved for validation, as described in Section 3.4.5. The tool can then enable the tester to label each GUI object by a logical name used in the test specification and, upon completion, persist the model in a file or database similar to the use of test databases in scriptless frameworks.