Mauvaises pratiques de développement d'interfaces utilisateur. Dans cette thèse nous avons identifié et décrit une mauvaise pratique, le Blob listener . Nous pensons que d'autres mauvaises pratiques de développement d'interfaces utilisateur existent. À l'instar du travail réalisé dans cette thèse, cela demanderait d'analyser empiriquement du code d'interfaces utilisateur existant pour mesurer diverses métriques (cohésion, couplage, etc.) qui pourraient donner des indications sur la qualité du code. Des analyses statiques ou dynamiques devront être développées pour identifier ces mauvaises pratiques.

2 AG U It oo l k i ti sal i b r a r y( o rac o l l e c t i o no fl i b r a r i e s )t h a tc o n t a i n sas e to fw i d g e t st os u p po r tt h e development of GUIs for instance Java Swing, or JavaFX toolkits.

3 WIMP stands for Windows, Icons, Menus, and Pointing device.

Abstract

Graphical user interfaces (GUIs) are integral parts of interactive systems that require interactions from their users to produce actions that modify the state of the system. While GUI design and qualitative assessment is handled by GUI designers, integrating GUIs into software systems remains a software engineering task. The software engineering community takes special attention to the quality and the reliability of software systems. Software testing techniques have been developed to find errors in code. Software quality criteria and measurement techniques have also been assessed to detect error-prone code.

In this thesis, we argue that the same attention has to be investigated on the quality and reliability of GUIs, from a software engineering point of view. We specifically make two contributions on this topic. First, GUIs can be affected by errors stemming from development mistakes. While the current GUI testing tools have demonstrated their ability in finding several kinds of failures (e.g., crashes, regressions) on simple GUIs, various kinds of faults specific to GUIs have to be identified and studied. The first contribution of this thesis is a fault model that identifies and classifies GUI faults. This fault model has been designed empirically by performing a round trip process between the analysis of the state-of-the-art of GUI design and bug reports. For each fault we illustrate which part of a GUI is affected and how that fault occurs as GUI failure. We show that GUI faults are diverse and imply different testing techniques to be detected. We then develop GUI mutants derived from our fault model. These mutants are freely available for developers of GUI testing tools to evaluate the ability of their tool in finding GUI failures.

Second, like any code artifact, GUI code must be maintained and is prone to evolution. Design smells are bad designs in the code that may affect its quality. Maintenance operations can be performed to correct design smells. As for the first contribution, we focus on design smells that can affect GUIs specifically. We identify and characterize a new type of design smell, called Blob listener , which is a GUI specific instance of a more general design smell: God method, that characterizes methods that "know too much or do too much". It occurs when a GUI listener, that gathers events to treat and transform as commands, can produce more than one command. We propose a systematic static code analysis procedure that searches for Blob listener that we implement in a tool called InspectorGuidget. Experiments we conducted exhibits positive results regarding the ability of InspectorGuidget in detecting Blob listeners. To counteract the 8 Abstract use of Blob listeners, we propose good coding practices regarding the development of GUI listeners.

Résumé en Français

Contexte

Les logiciels reposent généralement sur des interfaces utilisateur pour être contrôlés par les utilisateurs. De tels logiciels sont alors appelés des systèmes interactifs. Les interfaces utilisateurs peuvent prendre différentes formes telles que les interfaces en ligne de commande, les interfaces vocales ou -et ce sera le centre d'intérêt de cette thèse -les interfaces graphiques. Les interfaces graphiques se composent de composants graphiques dont les plus connus sont les boutons, les menus ou encore les champs de saisie de texte. Les utilisateurs interagissent avec ces composants (par exemple, en pressant un bouton à l'aide d'un dispositif de pointage comme la souris) pour produire une action1 visant, par exemple, à modifier ou à consulter les données que le logiciel permet de manipuler.

La conception et le développement d'interfaces utilisateur, en particulier les interfaces graphiques, impliquent différents rôles. Le designer conçoit, choisit comment l'utilisateur va interagir avec le système via une interface utilisateur et valide ses choix. Le développeur logiciel implémente cette interface utilisateur pour l'intégrer au système et la valider. Le développement logiciel d'interfaces utilisateur est un travail conséquent puisque le code produit peut atteindre 60% du code total du logiciel [START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF]. De plus, la multiplication des périphériques d'entrée (clavier tactile, GPS, accéléromètre, etc..) et des plates-formes (tablettes, smartphones, cockpits, etc.) complexifie le développement logiciel de ces interfaces utilisateur.

La communauté du génie logiciel porte depuis ses débuts une attention spéciale à la qualité et la fiabilité des logiciels. De nombreuses techniques de test logiciel ont été développées pour caractériser et détecter des erreurs dans les logiciels. Les modèles de fautes identifient et caractérisent les erreurs pouvant affecter les différentes parties d'un logiciel. D'autre part, les critères de qualité logiciel et leurs mesures permettent d'évaluer la qualité du code logiciel et de détecter en amont du code potentiellement sujet à erreur. Les techniques d'analyses statiques et dynamiques scrutent, respectivement, le logiciel à l'arrêt et à l'exécution pour trouver des erreurs ou réaliser des mesures de qualité. Dans cette thèse, nous prônons le fait que la même attention doit être portée sur la qualité et la fiabilité des interfaces utilisateurs, au sens génie logiciel du terme. Nous pensons que le code, ou plus généralement les artefacts logiciels composant des 10 Résumé interfaces utilisateurs impliquent des erreurs spécifiques nécessitant donc des techniques de détection tout aussi spécifiques.

Le test d'interfaces utilisateur

Des techniques spécifiques au test d'interfaces graphiques ont été proposées durant la dernière décennie. Ces techniques reposent sur des approches fondées sur les modèles et des analyses statiques ou dynamiques du code. Les approches fondées sur les modèles modélisent certaines informations de l'interface utilisateur à tester dans le but de produire ensuite des tests exécutables. Ces modèles peuvent être construits manuellement à partir des spécifications du logiciel [START_REF] Ana | Specificationbased testing of user interfaces[END_REF]. Dans le contexte des interfaces utilisateurs, ces modèles décrivent par exemple les interactions utilisateurs et les composants graphiques composant l'interface utilisateur. Cette étape est utilisée dés qu'une indépendance entre le logiciel développé et les modèles servant au test est requise, comme c'est le cas dans les normes IEC 60964 et 61771 dédiées au design et à la validation des centrales nucléaires [START_REF] Iec | Nuclear power plants -main control-room -verification and validation of design[END_REF][START_REF]Nuclear power plants -control rooms -design[END_REF]. Lorsqu'une telle indépendance n'est pas nécessaire, certaines techniques synthétisent ces modèles à partir d'une version étalon du logiciel par son analyse dynamique ou statique [START_REF] Nguyen | GUI-TAR: an innovative tool for automated testing of gui-driven software[END_REF]. Une autre technique pour produire de tels modèles est le capture and replay, où le testeur exécute des scénarios manuellement sur le logiciel, scénarios qui seront enregistrés pour produire des tests rejouables. L'avantage est le gain de temps relatif à la création du modèle. L'inconvénient, cependant, est que ce principe considère la version étalon comme valide en dépit d'éventuelles erreurs présentes dans cette version. Le processus classique de test d'interface utilisateur fondé sur les modèles est décrit dans la figure 1. Des tests abstraits, i.e., non exécutables car ne contient pas les informations concrètes sur l'interface utilisateur telles que la position des composants graphiques, sont produits à partir des modèles. Ces tests abstraits sont alors concrétisés en faisant le lien avec l'interface utilisateur à tester. Ces tests concrets sont exécutables sur le logiciel à tester produisant des données de sortie analysées par des oracles graphiques statuant si un test passe ou non. Parallèlement au test logiciel, la qualité logiciel prône la définition, la caractérisation, la détection et la correction la plus automatique possible de mauvaises pratiques de développement [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]. En effet, la présence d'erreurs dans le code peut être accentuée par la présence de mauvaises pratiques [START_REF] Li | An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution[END_REF][START_REF] Hall | Some code smells have a significant but small effect on faults[END_REF]. L'étude des mauvaises pratiques concernent principalement le code orienté-objet[BMMM98, Fow99, Mar04, PBDP + 14, ZFS15]. Peu de travaux existent sur les mauvaises pratiques de développement d'interfaces utilisateur. La notion de "spaghetti de call-backs" est une des premières mauvaises pratiques relatives aux interfaces utilisateur mettant en exergue la mauvaise structure du code lié à ces interfaces [START_REF] Myers | Separating application code from toolkits: Eliminating the spaghetti of call-backs[END_REF]. Les patron d'architecture du type MVC (Modèle-Vue-Contrôleur) [START_REF] Krasner | A description of the model-view-controller user interface paradigm in smalltalk80 system[END_REF] ou MVP (Modèle-Vue-Présentateur) [START_REF] Potel | MVP: Model-view-presenter the taligent programming model for c++ and java[END_REF] permettent de limiter ce problème en structurant le code lié aux interfaces utilisateur dans différents modules. L'utilisation de ces patrons d'architecture n'assure cependant pas l'absence de problèmes de développement, en particulier avec de larges et complexes interfaces utilisateur [START_REF] Karagkasidis | Developing GUI applications: Architectural patterns revisited[END_REF].

Challenges

Des techniques de test d'interfaces utilisateur ont donc été proposées pour améliorer la qualité et la fiabilité des interfaces. Nous pensons cependant que ces techniques ne vont pas assez loin et que le domaine du test d'interfaces utilisateur devrait plus largement adapter des concepts provenant du génie logiciel. De plus, ces techniques visent les interfaces utilisateurs simples, appelées WIMP (Window-Icon-Menu-Pointer) caractérisant des interfaces fondées uniquement sur des interactions clavier-souris et des composants graphiques standards qui en découle (bouton, case-à-cocher, etc.). En effet, la diversification des périphériques d'entrée (écran tactile, accéléromètre, etc..) limite l'utilisation des interfaces WIMP fondées sur l'utilisation du clavier et de la souris pour aller vers des interfaces dites post-WIMP fondées sur une plus large palette de périphériques et donc d'interactions homme-machine et de composants graphiques, découlant sur les conséquences suivantes :

1. Les données sont dynamiquement affichées par des composants graphiques spécifiquement développés (que l'on appellera composants ad hoc) pour l'occasion.

2. Les données sont manipulées de manière directe. Les principes de la manipulation direct [START_REF] Hutchins | Direct manipulation interfaces[END_REF][START_REF] Shneiderman | Direct manipulation: a step beyond programming languages[END_REF] sont de plus en plus adaptées aux interfaces post-WIMP [BL00, BL04, BB10] pour permettre une interaction direct et continue entre l'utilisateur et les données du système représentées le plus proche possible du modèle mental de l'utilisateur.

Résumé

3. Des interactions ad hoc sont conçues pour interagir avec ces données et leurs composants associés. D'un point de vue génie logiciel, de telles interactions sont plus complexes que les interactions WIMP : elles visent à se rapprocher des interactions naturelles que les utilisateurs font dans leur vie de tous les jours (interactions gestuelles, vocales, etc..). Cela implique généralement des interactions plus longues qu'un simple clic sur un bouton où plusieurs modalités d'interaction peuvent être utilisées en même temps (voix, geste, etc..). La figure 3.7 illustre ce principe avec une interaction bi-manuelle représentée sous la forme d'une machine à nombre fini d'états où chaque transition correspond à un évènement produit par un périphérique d'entrée. Un des problèmes majeurs de cette évolution est que les développeurs d'interfaces utilisateur font désormais face à de nouveaux types d'erreur que les outils classique de test d'interfaces ne peuvent trouver. De plus, ces outils se focalisent sur les crashs et les régressions des interfaces [START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF] alors même que des erreurs spécifiques aux interfaces existent requérant des techniques de test spécifiques pour être identifiées.

Challenge #1 : modèle de faute d'IHM. Un prérequis essentiel pour développer des techniques spécifiques de test d'interfaces utilisateur WIMP et post-WIMP est un modèle de fautes dédié, ce qui n'a jamais été fait. Un modèle de fautes fournit une classification et une description exhaustive des fautes affectant un domaine particulier, en l'occurrence les interfaces utilisateur. Un tel modèle permet aux développeurs d'outils de test de développer pour chaque faute, une technique de test.

Challenge #2 : étude de mauvaises pratiques de développement d'IHM. Parallèlement, le développement d'interfaces WIMP et post-WIMP implique du code liant l'interface utilisateur au logiciel. Comme tout artefact logiciel, ce code doit être maintenu et est susceptible d'évoluer et d'être affecté par des mauvaises pratiques de codage. Par exemple, la mauvaise pratique appelée Méthode Dieu (aka. Large méthode Résumé 13 ou méthode blob) identifie les méthodes trop longue [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]. Peu de travaux ont cependant été menés pour étudier des mauvaises pratiques spécifiques au code des interfaces utilisateurs.

Contributions

Cette thèse propose deux contributions dans le domaine du test et de la maintenance d'interfaces utilisateur, comme l'illustre la figure 4.2 (en vert) et détaillé ci-dessous. Le modèle de fautes proposé est synthétisé dans les tables 1-2.Chaque faute y est décrite et illustrée.

Résumé Table 1 -Fautes d'interactions utilisateur

Catégories Fautes Défaillances possibles

Comportement de l'interaction

Mauvais comportement de l'interaction AL as y n c h r o n i s a t i o ne n t r el av o i xe t les gestes ne fonctionne pas.

Action

Résultats de l'exécution d'une action incorrect Déplacer une forme dans un dessin selon un vecteur de translation (x, y) déplace cette forme selon le vecteur inverse (-x, -y).

Pas d'action exécutée

Cliquer sur un bouton n'a pas d'effet.

Mauvaise action exécutée

Cliquer sur un bouton de sauvegarde, lance une action de chargement.

Réversibilité

Résultats incorrects du undo / redo.

Cliquer sur le bouton undo n'annule pas la dernière action effectuée.

L'arrêt de l'interaction en cours ne fonctionner pas.

Presser la touche "échap" lors d'un glisser-déposer ne stoppe pas l'interaction.

L'arrêt d'une action en cours ne fonctionner pas.

Cliquer sur le bouton "Annuler" d'une barre de progression ne stoppe pas le chargement en cours.

Structure et esthétisme

Disposition incorrecte des widgets

Les positions de deux widgets sont inversées. Du texte n'est pas entièrement visible du fait d'un widget aux dimensions trop petites.

État des widgets incorrect

Impossible de cliquer sur un bouton car ce dernier n'est pas activé.

Apparence incorrecte des widgets

L'icône d'un bouton n'est pas visible.

Présentation des données

Rendu incorrect des données La taille d'un texte n'est pas correcte. Dans un dessin, une ligne n'est pas peinte de la bonne couleur ou un rectangle est représenté par une ellipse.

Propriétés incorrectes des données

Une adresse Web dans du texte n'est pas cliquable.

Format ou type des données incorrect

Une date est affichée à l'aide de cinq nombres au lieu de six. Une valeur en radian est affichée en degré.

L'évaluation du modèle de fautes proposé se compose de trois études empiriques. La première étude valide la pertinence du modèle de fautes en le corrélant avec des fautes réelles observées sur ces logiciels open-source. Cette validation a permis d'améliorer le modèle de fautes en le complétant et le précisant. La deuxième évaluation consiste à mesurer la capacité de deux outils connus de test d'interfaces utilisateur (GUITAR et Jubula) à détecter des fautes réelles classées lors de l'évaluation précédente dans notre modèle de fautes. La dernière évaluation consiste à exécuter ces deux outils sur les mutants produits en corrélation avec le modèle de fautes proposés. Le but de cette évaluation est d'évaluer quelles fautes ces outils couvrent. Nous avons validé l'analyse statique proposée en exécutant InspectorGuidget sur six systèmes interactifs open-source. InspectorGuidget a permis la détection de 67 Blob listeners sur les 68 identifiés manuellement. Les résultats présentent une précision de 69,07 % et un rappel de 98,81 % démontrant ainsi la capacité de notre approche à détecter des Blob listeners. La table 3 résume les résultats obtenus.

Structure du document

Le document décrivant la thèse réalisée se structure de la manière suivante. Chapter 1

Introduction

Context

Software systems usually rely on user interfaces for being controlled by their users. Such systems are then called interactive systems. User interfaces can take various forms such as command line interfaces, vocal interfaces, or graphical user interfaces (GUI). GUIs are composed of graphical interactive objects called widgets, such as buttons, menus, and text fields. Users interact with these widgets (e.g., by pressing a button) to produce an action1 that modifies the state of the system. The development of GUIs involves multiple roles. The GUI design and qualitative assessment is handled by GUI designers. Software engineers then integrate GUIs into interactive systems and validate this integration using software testing techniques. GUI development and validation is a major task in the development of an interactive system since GUIs may achieve up to 60% of the total software [START_REF] Myers | User interface software tools[END_REF][START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF]. Besides, a multiplication of human interface devices (HID, e.g., tactile screen, gyroscope) and a diversification of the platforms (tablet, mobile, etc.) has been experienced over the last decade. As a result, software testers face user interfaces that have to be tested on multiple platforms with various HIDs, which increases the testing cost. Validating, from a software engineering point of view, user interfaces and in particular GUIs is now a crucial challenge. Similarly to the attention that has been paid to the validation of software systems since the last decades, we argue in this thesis that software testing must be tailored to consider GUI specific defects. Indeed, GUIs have to be considered as special software artifacts that require dedicated software testing techniques. Such techniques can rely on mainstream software testing techniques, as we detail in this document.

Challenges and Objectives for Testing GUIs

GUIs rely on event-driven programming: input events produce by users while interacting with a GUI are captured to be then treated by the system. Most of standard widgets Introduction enable user interactions composed of a single input event (e.g., press). Such widgets work similarly across mainstream GUI toolkits 2 and mainly rely on the use of a mouse and a keyboard. Current GUI testing approaches have targeted GUIs composed of standard widgets (aka. standard GUIs [START_REF] Lelli | On model-based testing advanced GUIs[END_REF] or WIMP GUIs [vD00]) 3 . However, the evolution of GUIs and how they are developed and maintained require increasing efforts in the GUI testing domain as discussed below.

First, an ongoing trend in GUI design is the shift from designing "[user] interfaces to designing [user] interaction" [START_REF] Beaudouin-Lafon | Designing interaction, not interfaces[END_REF]. The underlying goal is to embrace the diversity of HIDs and platforms to design user interfaces more adapted and natural to users, called post-WIMP interfaces. Post-WIMP GUIs require specific, ad hoc widgets [BL00, BL04, BB10] developed to fulfil a need that standard widgets cannot meet. Post-WIMP GUIs exploit the following mechanisms to be more adapted to users:

1. Data are dynamically presented in the widget to be directly manipulated.P o s t -WIMP GUIs use direct manipulation through continuous and direct interaction with objects, for instance, users interact directly with underlying data (e.g.,2 D or 3D objects) to produce the target action.

2.

Ad hoc interactions are provided to interact with the data and their associated widgets. Developing and testing these interactions is more complex than interactions from standard widgets. They involve multiple events triggered (e.g., voice and gesture events) by one or more modern HIDs such as tactile screen, gyroscope, or eye tracking. An example is the bimanual interaction that can be performed in a multi-touch screen for zooming shapes using two fingers as it is typically more and more the case with mobile phones and tablets.

The aforementioned specificities in GUI design demand different ways in testing a GUI. For example, testing a GUI consists of verifying whether a user interaction produces the expected action. In WIMP GUIs, the interactions are not tested since they are composed of a single event, which is embedded in a GUI toolkit. For example, the interaction "pressing" the left mouse button has the same behavior on all GUI platforms and thus the target is to test the action resulting after the execution of such an interaction. In post-WIMP GUIs, however, the ad hoc interactions involve multiple events, they have some special properties (e.g., feedback) that should be tested while they are performed. Thus, we argue that a transition must occur in the GUI testing domain: move from testing WIMP GUIs to testing post-WIMP GUIs.

One major challenge with this transition is that the GUI developers and testers must handle new types of GUI faults that current GUI standard testing tools cannot detect. While GUI testing approaches have demonstrated their ability in finding several kinds of failures (e.g., regressions, crashes) on standard GUIs [NRBM14, CHM12, APB + 12, MPRS12, NSS10], various kinds of faults, which are specific to the characteristics of recent developments of GUIs, have still need to be identified and studied.

Challenges and Objectives for Testing GUIs

21

These faults are mostly stemming from post-WIMP GUIs, which have more embedded HCI (Human-computer interaction) features such as direct manipulation,a n d feedback [HHN85, Nor02, BL00, BB10]. In WIMP GUIs, checking whether a standard widget is correctly activated can be done easily using regression testing techniques [START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF]. In post-WIMP GUIs, however, errors show up in ad hoc widgets and their interactions, and the graphical nature of these GUIs (e.g., data rendering). Thus, testing such GUIs requires new testing techniques.

Second, like any code artifact, GUI code should be analyzed statically to detect implementation defects and design smells. Several bad design decisions can introduce design smells such as design principle violations (e.g., OO principle: encapsulation), ad hoc software evolution, and non-use of well-known best practices (e.g., patterns [START_REF] Gamma | Design patterns: elements of reusable object-oriented software[END_REF], guidelines [START_REF]Java Look and Feel Design Guidelines[END_REF]). Indeed, the presence of design smells may indicate a fault-prone code [START_REF] Li | An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution[END_REF][START_REF] Hall | Some code smells have a significant but small effect on faults[END_REF]. For example, the design smell "God method "4 has been associated with the class error-probability [START_REF] Li | An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution[END_REF].

Few efforts, however, have been done to investigate specific problems that arise from the development of GUI systems. To develop GUIs, software engineers have reused architectural design patterns, such as MVC [START_REF] Krasner | A description of the model-view-controller user interface paradigm in smalltalk80 system[END_REF] or MVP [START_REF] Potel | MVP: Model-view-presenter the taligent programming model for c++ and java[END_REF] (Model-View-Controller/Presenter), that consider GUIs as first-class concerns (e.g., the View in these two patterns). These patterns clarify the implementations of GUIs by clearly separating concerns, and thus minimizing the "spaghetti of call-backs" [START_REF] Myers | Separating application code from toolkits: Eliminating the spaghetti of call-backs[END_REF]. Yet, the use of these patterns does not ensure that a GUI code will not be affected by development problems, which become more apparent in large and complex GUIs [START_REF] Karagkasidis | Developing GUI applications: Architectural patterns revisited[END_REF]. GUI development thus poses a challenge to the GUI quality: identifying design smells that degrade GUI code quality. We call GUI design smells that decisions affect negatively the code responsible for GUI behavior. These smells are particular recurrent issues that limit the maintenance and evolution of GUI systems. Furthermore, deciding whether a GUI code contains design smells is not a trivial task due to the absence of GUI metrics to smell them. Software engineers have adapted well-known metrics such as cyclomatic complexity or code duplication to measure the GUI complexity. Also, cyclomatic complexity has been correlated to the number of faults found in the source code [START_REF] Maji | Characterizing failures in mobile oses: A case study with android and symbian[END_REF]. So, we need to study which kinds of development practices affect the quality of GUI systems and which kinds of maintenance operations are required to correct them.

In this thesis, we address these two challenges by first providing a conceptual framework for GUI testing, i.e., a GUI fault model, that covers the specificities of recent GUI developments. A GUI fault model must provide clear definitions of the different kinds of faults a GUI testing technique should look for. It then serves both as an objective to develop testing techniques and as a baseline to evaluate testing techniques. We address the second challenge through the development and empirical assessment of a novel static analysis technique, which specifically targets GUI code and focuses on one bad design practice that we call Blob listener . The objectives to improve the testing and maintenance of GUIs are listed as follows.

Introduction

GUI testing:

• Provide a conceptual framework for GUI testing, which integrates the characteristics of GUI development paradigms;

GUI maintenance:

• Investigate development practices that characterize new GUI design smells, and develop a static analysis to automatically detect the presence of the critical ones.

Contributions

This thesis establishes two core contributions in the research of testing and maintenance of GUIs. We detail these contributions below.

1. GUI fault model and its empirical assessment: We have proposed a GUI fault model based on HCI concepts to identify and classify GUI faults. These faults concern WIMP and post-WIMP GUIs and they are described at two levels: user interface and user interaction. Our fault model tackles dual objectives: 1) provide a conceptual GUI testing framework against which GUI testers can evaluate their tool or technique; and 2) build a set of benchmark mutations, i.e., GUI mutants5 , to evaluate the ability of GUI testing tools to detect failures for both WIMP and post-WIMP GUIs.

To evaluate our fault model, we have conducted three empirical studies. In the first study, we assess the relevance of our fault model w.r.t. faults currently observed in existing GUIs. The goal is to state whether our GUI fault model is relevant against failures found in real GUIs. We have successfully classified 279 GUIrelated bug reports of five highly interactive open-source GUIs in our GUI fault model. In the second one, we have evaluated the coverage of two well-known GUI testing tools to detect real GUI failures previously classified into our GUI fault model. These tools differ in how they build the GUI model, from specification of the SUT or from own SUT by reverse engineering. We have observed some faults related to standard widgets that GUI testing tools cannot detect such as GUI failures regarding the auto-completion feature or the data model. In the last study, we have executed these GUI tools against 65 GUI mutants derived from our fault model. These mutants are planted into a highly interactive opensource system, and they concern both standard widgets and ad hoc widgets. This evaluation have demonstrated that GUI testing frameworks failed at detecting 43 out of 65 mutants, and most of them are related to ad hoc widgets and their user interactions.

The above experiments allowed us to study the current limitations of standard GUI testing frameworks. Thus, we have demonstrated why GUI failures that come from recent developments of GUIs were not detected by these frameworks. As a secondary contribution, we have introduced a richer User Interface Description Languages (UIDL), which is based on the concept of interaction-action flow graph (IFG), to tackle these limitations. We have presented the initial feedback from the use of this approach in two case studies: an industrial project and on an opensource interactive system. The preliminary results highlighted the capability of the IFG produces test cases able to detect some defects in advanced GUIs.

GUI code assurance quality:

We propose a novel static analysis technique to automatically detect one specific GUI design smell, called Blob listener .W e identified and characterized Blob listeners as a new type of GUI design smell. It occurs when a GUI listener can produce more than one GUI command. A GUI command is a set of statements executed in reaction to a GUI event triggered by each widget. This tool currently focuses on detecting Blob listeners in Java Swing software systems. We focus on the Java Swing toolkit because of its popularity and the large quantity of Java Swing legacy code. Also, InspectorGuidget leverages the Eclipse development environment to raise warnings in the Eclipse Java editor when it suspects the presence of Blob listeners.

To design this tool, we first have conducted an empirical study to identify the good and bad practices in GUI programming. We examine in detail the GUI controllers code of open-source interactive systems stored on 511 Web code hosting services. [START_REF] Lelli | Challenges of testing for critical interactive systems[END_REF]. The work on fault model is published in [START_REF] Lelli | Classifying and qualifying GUI defects[END_REF]. The kinds of GUI faults have been identified by performing a complete research study based on the HCI concepts and real bug reports. We also demonstrate the weakness of standard GUI testing tools at detecting several GUI failures by building a set of benchmark mutations derived from our fault model. The current limitations of GUI testing frameworks is published in [START_REF] Lelli | On model-based testing advanced GUIs[END_REF]. In this work, we explain why standard GUI testing tools fail in testing advanced GUIs. We also present how a user interface description language, dedicated to advanced GUIs, can be applied on GUI testing to overcome that limitations.

The work on code assurance has been submitted [LBB + 16]. In this work, we present the empirical study to investigate coding practices that affect Java Swing GUIs. We also present and evaluate the static analysis approach to automatically detect the presence of Blob listeners.

Overview of this thesis

The remainder of this thesis is structured as follows.

Chapter 2 gives an introduction of GUI design by two generation of GUIs: WIMP vs. post-WIMP. This chapter also details the main concepts of human-computer interactions that must be considered in GUI testing. We then present the GUI V&V techniques (e.g., defect classification schemes, dynamic and static analysis) and how the current approaches leverage them to provide a fully GUI testing.

Chapter 3 presents an original, complete fault model for GUIs. The GUI faults are explained in detail through two levels: user interface and user interaction. This chapter also gives several examples of GUI failures originated by that faults. The empirical studies performed to assess the fault model are described in detail. We also present the limitations of standard GUIs testing frameworks in testing more advanced GUIs. We end this chapter by presenting the concept of interaction-action-flow graph to tackle these limitations.

Chapter 4 starts showing the coding practices that may affect the GUI code quality. These practices are analyzed through an empirical study of GUI controllers through 511 code repositories. We then introduce the critical bad coding practice that we identified and characterized as a new GUI design smell. Next, we present an automated static analysis approach to detect this smell in GUI controllers called Blob listener . The empirical assessment of our approach's ability at detecting Blob listeners in six large, popular Java applications is presented in detail. We also propose the good coding practices to avoid the Blob listeners. This chapter ends with ongoing work towards refactoring Blob listeners.

State of the Art and Related Work

This chapter introduces the main concepts of GUI design to illustrate the new challenges for GUI testing, and presents the limitations of current state of the art technique. First, we present the characteristics that compose a GUI and explain them by the two generations of GUIs (Section 2.1). Then, we detail the interactive features that complexify how to develop and test GUIs. Second, we present the existing archictectural design patterns used to develop GUIs (Section 2.2). Last, we present the seminal GUI V&V techniques applied to support GUI testing (Section 2.3). We also explain how the current solutions leverage these techniques to provide an automated GUI testing process and point out their drawbacks.

GUI Design

GUIs are the essential part of an interactive system. They are composed of graphical interactive objects, called widgets, such as buttons, menus, drawing areas of graphical editors. These widgets are laid out following a specific order in their hierarchy. Users interact with widgets by performing a user interaction on a GUI. A user interaction is composed of a sequence of events (mouse move, mouse release etc.) produced by input devices (mouse, keyboard etc.) handled by users. Such an interaction produces as output an action that modifies the state of the system1 . For example, the user interaction that consists of pressing the button "Delete" of a drawing editor produces an action that deletes the selected shapes from the drawing.

The graphical elements displayed by a widget are either purely aesthetics (fonts, etc.) or presentations of data. The state of a widget can evolve in time having effects on its graphical representation. For example, the widget properties (e.g.,v i s i b i l i t y , position) have discrete values that may be modified during the execution of a GUI. Thus, a GUI state is a set of information collected from the states of all widgets while a user interaction is performed.

Context

In the next subsection, we present the two generations of graphical user interface styles: WIMP and post-WIMP GUIs.

Types of GUIs

GUIs become more adapted to incorporate new interactions styles. This trend is reified by the two generations of graphical user interfaces styles: WIMP and post-WIMP GUIs.

WIMP (Windows, Icons, Menus, Pointer) GUIs [vD00, RPV12] emerged in the 70's aiming at being more user-friendly and easy to use 2 compared to the command lines interfaces. However, they only gained popularity with Macintosh in the 80's, and remained dominant for more than two decades [vD97]. WIMP GUIs are composed of standard widgets (e.g., buttons, menus, text fields). Such widgets enable interactions composed of a single input event, we call mono-event interactions, based on the mouse and keyboard devices. The standard widgets work identically on many GUI platforms. For instance, interacting with a button has the same behavior on various platforms: pressing the left mouse button on it while a mouse is positioned. Also, the standard widgets have a pre-established set of properties (e.g., position, size), which have predefined values (number, text).

Figure 2.1 shows a basic WIMP GUI. In this example, the standard widgets are represented by the pull-down menus "File"a n d" Edit", where interactions are performed through their menu items; the buttons undo and redo represented by the two icons grouped in the toolbar along the top; and the main text area. The interactions can be performed using a mouse. An example of a WIMP interaction is pressing the button "undo" in the toolbar, which undoes the text typed in that text area. Post-WIMP GUIs go beyond the mere use of mice and keyboards to fit to new input devices such as tactile screens, gyroscopes, finger/eye trackers. They are presented in several domains such as ubiquitous and mobile computing, and virtual reality. These domains leverage the novel human-computer interaction techniques to develop highly interactive GUIs with more "real world " interactions [JGH + 08]. van Dam proposed that a post-WIMP GUI is one "containing at least one interaction technique not dependent on classical 2D widgets such as menus and icons" [vD97]. Thus, post-WIMP GUIs rely more and more on ad hoc widgets and their complex3 interactions.

Ad hoc widgets are mainly developed for a specific purpose such as GUIs in avionics systems [FFP + 13]. These widgets are dynamic and their underlying data are not "predefined" like WIMP GUIs. Notably, objects in post-WIMP GUIs have more complex data structure such as geometric objects in 2D (e.g., vector-based graphics systems) or 3D systems. These objects are more dynamic since they evolve as interactions are performed. For example, 3D objects change their state of appearance as the user interacts with them. Besides, ad hoc widgets allow users to interact more directly with objects (e.g., data). We call such interactions multi-event interactions. They are composed of multiple events (in opposition to mono-event interactions) produced by one or more input devices. So, post-WIMP interactions are either sequential (i.e., multiple events) and simultaneous (i.e., multiple interactions). For example, a multimodal interaction4 can be represented by a finite state machine, where each transition is an event produced by an input device [START_REF] Blouin | Improving modularity and usability of interactive systems with Malai[END_REF].

Figure 2.2 illustrates a graphical post-WIMP editor called CNP2000 [START_REF] Beaudouin-Lafon | The architecture and implementation of cpn2000, a post-wimp graphical application[END_REF][START_REF] Beaudouin-Lafon | Designing interaction, not interfaces[END_REF]. This editor was redesigned for manipulating colored Petri nets through complex interactions techniques. The GUI of CNP2000 is based on toolglasses, marking menus, a floating palette5 and bi-manual interaction to manipulate objects. A bi-manual interaction is a variant of direct manipulation that requires both hands to perform an action over a GUI (e.g., zooming or resize a GUI object).

Seminal HCI Concepts

Identifying GUI faults requires an examination in detail of the major HCI concepts. In this subsection we detail these concepts to highlight and explain in Chapter 3 the resulting GUI faults.

Direct manipulation aims at providing users the feeling of visualizing and manipulating directly data objects of the system, as they could do in the real world [START_REF] Shneiderman | Direct manipulation: a step beyond programming languages[END_REF][START_REF] Hutchins | Direct manipulation interfaces[END_REF]. Such a manipulation also recommends that user interactions that can be used to handle data objects can be inspired by the physical world, for permitting: • beginners to quickly learn the basic features of the system;

Context

• experts to quickly perform multiple actions;

• all users to perceive in real-time the results of their ongoing interaction within the system.

Using direct manipulation also prones the following properties:

• data objects have to be continuously represented;

• physical interactions have to replace WIMP ones;

• actions, that modify the state of the system, have to be incremental and reversible, and have to provide users with feedback to let him monitor the progress of the ongoing action.

An example of direct manipulation is the drawing area of drawing editors (for instance the one depicted in Figure 2.2). Such a drawing area represents shapes as 2D/3D graphical objects as most of the people define the concept of shapes. Users can handle these shapes by interacting directly within the drawing area to move or scale shapes using advanced interactions such as bi-manual interactions. Direct manipulation is in opposition to the use of standard widgets that bring indirection between users and their objects of interest. For instance, scaling a shape using a bi-manual interaction on its graphical representation is more direct than using a text field. So, developing direct manipulation GUIs usually implies the development of ad hoc widgets, such as the drawing area. These ad hoc widgets are usually more complex than standard ones since they rely on: advanced interactions (e.g., bi-manual, speech+pointing interactions); a dedicated data representation (e.g., shapes painted in the drawing area). Testing such heterogeneous and ad hoc widgets is thus a major challenge.

Another seminal HCI concept is feedback [HHN85, Nor02, BL00, BB10]. Feedback is provided to users while they interact with GUIs. It allows users to evaluate continuously the outcome of their interactions with the system. Direct manipulation relies on feedback to provide users with continuous representations of the data objects of the system. Feedback is computed and provided by the system through the user interface and can take many forms. A first WIMP example is when users move the cursor over a button. To notify that the cursor is correctly positioned to interact with the button this changes its shape. A more sophisticated example is the selection process of most of drawing editors that can be done using a Drag-And-Drop (DnD) interaction. While the DnD is performed on the drawing area, a temporary rectangle is painted to notify users about current selection area.

Another HCI concept is the notion of reversible actions [Shn83, HHN85, BB10]. The goal of reversible actions is to reduce user anxiety by about making mistakes [START_REF] Shneiderman | Direct manipulation: a step beyond programming languages[END_REF]. In WIMP GUIs, reverting actions is reified under the undo/redo features usually performed using buttons or shortcuts that revert the latest executed actions. In post-WIMP GUIs, recent outcomes promote the ability to cancel actions in progress [START_REF] Appert | Dwell-andspring: undo for direct manipulation[END_REF]. In such a case, users may cancel an interaction while it is executed, when it only changes the state of the view. For instance, moving a graphical object (e.g., a shape) to a new position can be reverted before the object reaches that position. Thus, this feature also allows widgets to be more susceptible to direct manipulation.

All these HCI concepts introduced in this subsection are interactive features that require significant efforts to develop and test GUIs. Software engineers have paid special attention to integrate these features in GUIs. Such an integration has been done through complex pieces of code, which must be thoroughly analyzed and tested to detect faults. While GUI implementations rely on existing GUI architectural design patterns to minimize recurrent development problems and thus provide a higher quality code, GUI testing techniques have adapted existing testing techniques to provide GUI solutions that ensure the reliability of GUIs.

We thus present in the next sections the GUI architectural design patterns used to develop GUIs and the GUI V&V techniques applied to GUI testing.

GUI architectural design patterns

The software development of GUIs relies, as any software intensive-system [START_REF] Mark W Maier | Software architecture: introducing ieee standard 1471[END_REF], on specific architectural design patterns that organize the GUI components and describe Context how they interact with each other. This section gives a brief overview of the mainstream architectural design patterns used to develop GUIs.

The core decomposition that follows all the GUI architectural design patterns is the separation between the data model of the system (aka. the functional core) and their representations (the views or user interfaces). This explicit separation permits the model to be independent of any view. So, multiple views can be developed for a single data model. Views can be added, removed, or modified without having an impact on the model.

Based on this model-view separation, multiple GUI architectural design patterns have been proposed to complete this separation with details. The most well-known architectural design pattern is certainly the Model-View-Controller design pattern (MVC) [START_REF] Krasner | A description of the model-view-controller user interface paradigm in smalltalk80 system[END_REF]. MVC organizes an interactive system in three main components supplemented with communications between them, as depicted by Figure 2.3. The model corresponds to the data model of the system. The view is the representation of this data model. The controller is the component that receives events produced by users while interacting with the view, treats them to then modify the model or the view. On changes, the model can notify its observers (in our case the views) about the changes to be updated. The transmission of events from a view to its controller usually relies on an eventdriven programming pattern: an interaction produced through the view by a user using an input device (e.g., pressing a button using a mouse) produces an GUI event (e.g., a mouse event). This GUI event is then transmitted to the controller of the view that receive it through a listener method (aka. a handler method). For instance, Listing 2.1 illustrates a Java Swing listener method actionP erf ormed implemented in a mere controller AController. This listener receives events (ActionEvent) produced while interacting with buttons or menus. This event can be then treated by the controller in this method to perform some action.

class AController implements ActionListener { @Override public void actionPerformed(ActionEvent e) { //... } }

Listing 2.1: Example of a GUI controller in Java Swing

A second GUI architectural design patterns is the Model-View-Presenter pattern (MVP) [START_REF] Potel | MVP: Model-view-presenter the taligent programming model for c++ and java[END_REF]. MVP shares many similarities with MVC. The main differences are the renaming of the controller as a presenter and the communications between the three components, as depicted by Figure 2.4. The presenter is the core of the MVP pattern since the model does not notify its views anymore. The presenter manages the process of the events produced by the views and updates these last. This change permits the model to be fully independent of observers (views). MVP is mainly used to develop Web applications where the model remains on the server, the view on the client, and the presenter cut in two parts: one part on the client and another one on the server). In this case the presenter manages the communications between the client and the server. Implementations of MVP mainly rely on the use of listeners/handlers to treat GUI events. The differences between MVC and MVP are, however, not so clear in practice since these patterns provide few details about how to implement them. Many variations and interpretations on MVC exist so that one may already be using MVP under the guise of MVC. Besides, a second version of MVC, called MVC2, has been proposed and matches the MVP definition6 . Beaudoux et al. discuss the distinctions between MVC and MVC2 [START_REF] Beaudoux | Binding orthogonal views for user interface design[END_REF]. MVC2 evolves MVC to allow the definitions of complex relationships between models and views such as data binding mechanisms. Both patterns, however, do not provide mechanisms for separating the interactions (e.g., DnD) on presentations from actions (e.g., Create) on the domain objects. In such a case, a mechanism should be provided for transforming a user interaction into an action that has effect on the presentation and/or on the domain objects.

Other industrial and academic GUI architectural design patterns have been proposed. We focus on two of them related to MVC and MVP that rely on event-driven programming. The Model-View-ViewModel pattern (MVVM) is the core component of the WPF (Windows Presentation Foundation) toolkit developed by Microsoft [START_REF] Smith | WPF apps with the model-view-viewmodel design pattern[END_REF]. MVVM can be summarized as the MVP pattern supplemented with WFP features, such as data binding. Regarding academic patterns, Malai [Blo09, BB10] can be viewed as an MVC or MVP pattern supplemented with two other components: interaction and action. These components respectively permit developers to explicitly define user interactions as finite-state machines and actions as reversible GUI commands.

The use of GUI architectural design patterns clarifies the implementations of GUIs by clearly separating concerns, and thus helps developers to avoid some problems such as the "spaghetti of call-backs" [START_REF] Myers | Separating application code from toolkits: Eliminating the spaghetti of call-backs[END_REF]. The GUI implementations, however, still Context are affected by development issues which may be accentuated by the multiplication of input devices (tactile screen, gyroscope, etc.), the diversification of the platforms (tablet, mobile, etc.), and the interactive features (recall Section 2.1.2). We investigate the development practices that affect the controllers of a GUI in Chapter 4.

GUI V&V techniques

GUI verification and validation (V&V) is the process of evaluating GUI software artifacts to verify whether they satisfy the requirements, or ensure that they are bug-free. One may note that GUIs have several specificities that complexify how to test them (recall Section 2.1). For example, testing WIMP GUIs focuses basically on testing standard widgets. Testing post-WIMP GUIs, however, focuses on both ad hoc widgets and their multi-event interactions. Besides, testing a GUI is able to find problems that arise through GUIs but may not be GUI failures. As Memon wrote GUI testing is "not only how much of the code is tested, but whether the tested code corresponds to potentially problematic user interactions" [START_REF] Atif | Advances in GUI testing[END_REF].

There are several GUI V&V techniques (e.g., model-based testing, static analysis) to ensure the quality and reliability of GUIs. They have been developed to find failures that affect GUIs or to measure the GUI code quality. Table 2.5 illustrates some V&V techniques and their solutions for graphical user interfaces. The most used technique to measure the quality and reliability of GUIs is testing. Testing GUIs aims at validating whether a GUI has the expected behavior: Does the GUI conform to its requirements specification? Indeed, GUI testing exercises each possible state of a GUI through its components looking for failures. Most of GUI testing approaches focus on automated GUI testing to provide an effective bugs detection [START_REF] Cristina | Automated Specification-Based Testing of Graphical User Interfaces[END_REF][START_REF] Mariani | AutoBlackTest: A tool for automatic black-box testing[END_REF][START_REF] Nguyen | GUI-TAR: an innovative tool for automated testing of gui-driven software[END_REF]. For example, model-based GUI testing solutions rely on models to drive the test case generation. In such a case, the reliability of the GUI depends on the reliability of the models used for modeling and testing GUIs [START_REF] Belli | Event-based GUI testing and reliability assessment techniques -an experimental insight and preliminary results[END_REF].

The reliability of GUIs, however, is still affected by the low quality code. Static analyses have been thus proposed to measure the quality of a GUI code. They aim at detecting problems in the source code that may have effect on faults. Furthermore, V&V techniques are complementary, and similar GUI V&V techniques can be combined to achieve a fully GUI testing. For example, a model-based testing may use a dynamic analysis to build a GUI test model. GUI V&V techniques can be supported by defect classification schemes. An example is fault models (Section 2.3.1.3) that are largely used as a start point in fault-based testing such as mutation testing. Mutation testing leverages fault models to implement a set of mutations that should be detected by their test suites. Thus, a complete test suite must detect all mutations derived from the fault model.

In the next subsections, we present seminal V&V techniques. This section is organized as follows. We first introduce the defect classifications schemes adapted for GUIs (Section 2.3.1). Then, we present the current GUI approaches to automate GUI testing such as model-based testing (Section 2.3.2) and dynamic analysis (Section 2.3.3). Last, we present the GUI solutions that leverage static analysis (Section 2.3.4).

Defect classification schemes

Testing techniques look for the presence of bugs7 in a software system. One way to determine which defects should be overcome by such techniques is to introduce defect classifications. A defect classification scheme defines a set of defect categories, where each one covers a specific defect. Software defect classification schemes concern problems that affect software systems. They can be generic, describing problems related to the entire software development process, or software specific focusing on the product (e.g.,a mobile system) or a specific part of software (e.g., GUIs). Most of the existing schemes have been proposed through two classifications: defects taxonomies or fault models. Both classifications have been used to support GUI V&V techniques.

In this subsection, we introduce the defect classifications schemes used for GUIs. We also present the limitations of theses schemes in covering GUI faults. The purpose is to clarify which kinds of faults the GUI V&V solutions should look for.

The basic concepts

In this subsection, we present the definitions of fault, error, and failure that will be used throughout the next sections. A static defect is any incorrect behavior in a system component such as an incorrect instruction into a source code. IEEE Std. defines a defect as an imperfection in a product when this does not meet its specifications [START_REF]Standard classification for software anomalies[END_REF]. We use the terms defect and fault as synonyms. A fault may exist into a system with no effect on its behavior, in this case a fault is said dormant, otherwise it is active. When a fault is activated, i.e., that instruction is executed, it leads to a wrong internal state of a system (e.g., erroneous program counter). If this wrong state is propagated outside a SUT, e.g.,i ti s observable by a user or an oracle, it is characterized as a failure. Thus, a fault can lead to one or more failures. Yet, a failure may be caused by user mistakes such as wrong input data.

When the aforementioned problems concern a GUI, the terms GUI fault, GUI error, and GUI failure are analogously defined. We present these definitions in Chapter 3.

Defect taxonomies

Defect taxonomies are generic classification schemes since they focus on high-level problems that affect the software development process. Several defect taxonomies have been proposed in the literature [Bei90, CBC + 92, Gra92, IEE10]. A comparison study of defect classifications taxonomies [ML09, VGH09] reveals that they share several commonalities such as some defect categories. A defect taxonomy is composed of categories, where each category is represented by a set of values that characterizes a defect. The relationships between such categories define the structure of a defect taxonomy (e.g., orthogonal [CBC + 92] when defect categories are independent).

The three defect taxonomies that have been adapted to cover GUIs are Beizer's taxonomy [START_REF] Beizer | Software Testing Techniques[END_REF], Orthogonal Defect Classification (ODC) [CBC + 92], and IEEE standard 1044 [START_REF]Standard classification for software anomalies[END_REF]. We first introduce the general structure of these taxonomies and then we present the research studies based on them to cover GUIs.

Bezier's taxonomy is one of the first taxonomies to classify defects that was proposed by Boris Beizer. The defects are presented into eight categories as follows:

1. "Functional Bugs: Requirements and Features " concern defects caused by ambiguous, incomplete, duplicate, or overly specified requirements.

2. "Functionality as Implemented " categorizes defects through the incorrect implementation of requirements.

"Structural

Bugs" focus on problems into the code structure such as unreachable code or wrong arithmetic expressions.

4. "Data" defects are related to the incorrect structure or manipulation of data.

5. "Implementation and coding" concern defects into the implementation (e.g.,t ypographical defects) and also defects that impact on the software maintenance such as standards violation in control-flow structure (e.g., excessive if-then-else nesting).

6. "Integration" categorizes problems regarding the components integration such as an incorrect communication between internal and external interfaces.

7. "System and Software Architecture" focus on defects that affect the entire software system such as architectural errors.

8. "Test Definition or Execution Bugs" gather defects found in the definition, design, and execution of tests, and the data used to validate the system (e.g., wrong test initialization, incomplete test cases).

Moreover, each above category is further break down into subcategories. This hierarchy structure specializes the defect categories to classify more precisely a defect. So, a defect is represented by a four digit number, where the first two digits concern the category and a subcategory, respectively. For example, the number 61xx classifies a defect within the category "Integration" and the subcategory "Internal interfaces" (see Table 5.1 in Appendix).

ODC taxonomy defines eight defect types: function, interface, checking, assignment, timing/serialization, build/package/merge, documentation,a n dalgorithm.A l s o , the defect types can be associated with the software development phases (e.g., design, code). The interface type concerns defects into the communication between software components (e.g., modules, subsystems) or hardware (e.g., device drivers). An example of Interface defect is aw r o n gt y p eo fv a r i a b l eu s e di nt h ep a r a m e t e ro faf u n c t i o nc a l l .

IEEE standard 1044 aims at classifying software anomalies. The term anomalies is used to describe any problem detected within the project, product, or a software life cycle. Also, IEEE Std. distinguish the terms problem, defect, fault, error,a n dfailure. The terms fault and defect are not used interchangeably. For example, a defect is not considered as a fault if it is found by inspection or static analysis activities. Thus, IEEE Std. proposes a scheme that allows software engineers to categorize defect, faults, and failures, and their relationships. The defect categories are represented by a set of attributes such as interface, logic, and data.S i m i l a r l yt oODC taxonomy, the root cause of the defect can be correlated with the phase of software cycle life (e.g., requirements, designing, code, configuration). Also, defects into the interface type concern the same problem: communication between components. Table 2.1 illustrates the defects into this category.

Context

Although the aforementioned taxonomies aim at providing an extensive defect classification scheme, they present several shortcomings. One of this is the lack of low-level defect classifications, for instance, defect categories for covering specific concerns such as GUIs. Thus, several approaches have adapted existing defect taxonomies (e.g., Beizer's taxonomy or ODC) or proposed new ones to cover GUIs. Besides, several GUI classifications focus on classifying GUI failures instead of GUI faults. We discuss these approaches below.

GUI Defect classifications

The ODC extension to cover GUI defects was proposed by IBM Research [START_REF]Extensions for defects in GUI, user documentation, build and national language support[END_REF]. This extension defines 6 ODC triggers8 that concern the visual aspects of GUIs. Table 2.2 shows the triggers (highlighted in blue color and italic) and the corresponding defect types. These types remain the same as described in ODC version 5.2 for Software Design and Code classification [START_REF]Orthogonal defect classification v 5.2 for software design and code[END_REF]. [START_REF] Li | Classification of software defect detected by black-box testing: An empirical study[END_REF]. This classification defines five high-level defect categories: Function, System, Data, Interface, Specific. The category Interface is divided into subcategories to cover several GUI defects. These subcategories are named according to specific GUI elements (e.g., window, title bar, menu,ortool bar ), or input devices (i.e., mouse and keyboard).

An adaptation of Beizer's taxonomy (recall the beginning of Section 2.3.1.2) to include GUI-related defect categories is proposed by Brooks et al. [START_REF] Brooks | An initial characterization of industrial graphical user interface systems[END_REF]. The extension creates new five subcategories that are related to GUIs: GUI Defects, Software Documentation, User Documentation, Configuration Interfaces,a n dSystem Setup.T able 5.1 (see Appendix) shows these subcategories (highlighted in blue color and italic) into Beizer's taxonomy. The subcategory "GUI defects" is included in the category "Implementation Defect" to classify defects concern both the graphical components of GUIs and the user interactions. Thus, the type of GUI defects, however, are not described and no GUI defect classification is proposed. Other approaches combine two or more defect taxonomies to identify faults. For example, Børretzen et al. [START_REF] Arvid | Results and experiences from an empirical study of fault reports in industrial projects[END_REF] present a fault classification by combining IEEE Std. 1044 and ODC taxonomy. Similarly to Brooks' work [START_REF] Brooks | An initial characterization of industrial graphical user interface systems[END_REF], one category that focuses on GUI faults is added (GUI faults) but no GUI fault classification is proposed.

Other defect classifications focus on supporting the GUI testing automation. For instance, Xuebing has defined a small defect classification to drive a particular test case generation [START_REF] Yang | Graphic User Interface Modelling and Testing Automation[END_REF]. This classification covers few types of GUI defects which are grouped in the three following categories:

1. Functional defects are defects found when events from functional objects (e.g., buttons, menus) are invoked;

2. Interactive defects are defects that concern the interaction between a user and the SUT to exchange some information (e.g., data editing);

3. GUI adjustment defects are defects regard the GUI adjustments objects, which are used to resize the GUI such as resizing, or scrolling adjustements.

The above categories are based on the most common standard widgets. Table 2.3 illustrates these categories according to their related widgets. A set of widgets is linked to a defect category (called "defect class" by the author). For instance, the category "Functional defects " is linked to widgets that have their results reflected in GUI properties (e.g., buttons), whereas the category "Interactive defects" is related to widgets that receive inputs from the users (e.g., combo boxes).

GUI failure classifications

In contrast to the defect-based classifications, several research studies focus on failure-based taxonomy [START_REF] Black | Guide to the ISTQB Advanced Certification As an Advanced Technical Test Analyst[END_REF]. This taxonomy is based on classifying failures instead of faults. Most of these studies focus on specific domains such as mobile [START_REF] Maji | Characterizing failures in mobile oses: A case study with android and symbian[END_REF] or safety-critical [START_REF] Lutz | Empirical analysis of safety-critical anomalies during operations[END_REF] or specific GUIs (e.g., automotive GUIs [START_REF] Mauser | GUI failure analysis and classification for the development of in-vehicle infotainment[END_REF]). For example, Maji et al. characterize failures for mobile operating systems [START_REF] Maji | Characterizing failures in mobile oses: A case study with android and symbian[END_REF]. The failure categories are defined as segments. A segment is the localization (e.g., a device component, a software system) where a failure occurred. For instance, a failure manifested in a camera is categorized in the Camera segment. Similarly, failures for other segments such as Web, Multimedia,o rUI softwares (user interface) are categorized. Also, Zaeem et al. [START_REF] Nokhbeh Zaeem | Automated generation of oracles for testing user-interaction features of mobile apps[END_REF] have conducted a bug study for Android applications to automate oracles. They designed 20 bug categories and classified several failures into them. These categories have included some GUI issues such as Rotation (device's rotation), Gestures Context (zooming and out), and Widget. Although, both research studies have investigated failures in a context that brings many advances in terms of interactive features, no GUI defect classification or discussion about these kinds of failures is presented.

Mauser et al. propose a GUI failure classification for automotive systems [START_REF] Mauser | GUI failure analysis and classification for the development of in-vehicle infotainment[END_REF]. This classification is based on the three categories: design, content, and behavior. In the Design category, the failures refer to GUI layouts (e.g., color, font, position). In the Content category, the failures are associated to data displayed such as text, animation, and symbols/icons. The failures in the Behavior category are caused by a wrong behavior of windows (e.g., wrong pop-up) or widgets (e.g., wrong focus). The authors focus on characterizing GUI failures based only on a small set of specific widgets designed for these kinds of GUIs. Furthermore, they do not consider failures that come from user interactions.

Limitations of GUI defect classifications

We identified several limitations of GUI defect classifications. The main shortcoming is that they are not properly defined to describe real GUI defects. The reasons are twofold. First, some classifications propose GUI defect categories that do not describe their types of GUI defects. For example, Børretzen et al. [START_REF] Arvid | Results and experiences from an empirical study of fault reports in industrial projects[END_REF] and Brooks et al. [START_REF] Brooks | An initial characterization of industrial graphical user interface systems[END_REF] have extended defect taxonomies to cover GUIs by including a single category called "GUI defects/faults", where the kinds of GUI defects are not described. Second, other classifications describe the GUI defects based on a set of standard widgets or input devices [START_REF] Li | Classification of software defect detected by black-box testing: An empirical study[END_REF][START_REF] Yang | Graphic User Interface Modelling and Testing Automation[END_REF]. For example, ODC-BD [START_REF] Li | Classification of software defect detected by black-box testing: An empirical study[END_REF] proposes a defect category called Mouse.S o ,does a fault classified into this category refer to an interaction, an action or an input device? Also, these kinds of categories are more the case of GUI failure-based classifications, which identify the failures categories according to their localization. For example, the GUI failure that occurs when a user interacts with a widget is classified in the category Widget as proposed by Zaeem et al. [START_REF] Nokhbeh Zaeem | Automated generation of oracles for testing user-interaction features of mobile apps[END_REF].

The limitations of the GUI defect classifications are summarized below.

1. The defect categories are named according to a small and specific GUI components such as widgets (e.g., button), or common input devices (e.g., mouse);

2. The defect categories focus on standard GUIs, and thus faults that concern ad hoc widgets and their interactions are not covered;

3. The defect categories do not clearly separate defects that show up from different elements of a GUI system such as widgets, interactions, actions;

4. The defect categories do no cover interactive features (recall Section 2.1.2); and 5. The relationship between GUI defects and their GUI failures are not presented.

Fault models

Fault models aims at being more accurate than a defect taxonomy. They describe how faults come to be and how and why they occur as failure [START_REF] Black | Guide to the ISTQB Advanced Certification As an Advanced Technical Test Analyst[END_REF]. Bochmann et al.

[vBDD + 91] define a fault model as: This definition highlights two key points of fault models: 1. they provide different levels of abstraction; and 2. they qualify the effectiveness of testing techniques in terms of fault-detection. A higher level fault model describes faults covering both physical faults and software faults [vBDD + 91]. The physical faults concern faults that affect the hardware components. One example is the well-known fault model stuck-at model that concerns physical faults within circuits in Digital Systems [START_REF] Mccluskey | Fault equivalence in combinational logic networks[END_REF]. The software fault models provide a collection of faults that occurs in software systems. These faults can be structured according to the software assets (e.g., specification, design, implementation). This allows software engineers to provide more detailed fault models and thus captures "what is going wrong" in a specific part of a system. Because of this specificity, faults models are widely applied to measure the fault-detection effectiveness of automated testing techniques. Binder wrote "af a u l tm o d e la n s w e r sas i m p l eq u e s t i o na b o u tt e s t i n g techniques: why do the features called out by the technique warrant our effort? " [START_REF] Binder | Testing Object-oriented Systems: Models, Patterns, and Tools[END_REF].

One way to measure the fault coverage of test suites is to use a fault-based testing technique such as mutation testing (aka. mutation analysis). Mutation testing creates several mutants of a software system [START_REF] Jia | An analysis and survey of the development of mutation testing[END_REF]. Each mutant contains a fault derived from a fault model, which is called a system's faulty version. A fault is seeded in the system's code as a mutant operator9 , which produces specific incorrect statements. The most common examples of mutants operators are: deletion/insertion/duplication of an statement, replacement of relational (e.g., >, >=) or conditional (e.g.,& & ,| | ) operators. Once the mutants are planted, they are executed over a test suite. A mutant is killed when a test suite detects its corresponding failure.

Type of fault models

Faults models have been largely used for supporting software testing techniques. They have been applied to describe software faults that concern the behavior of a system (e.g., state transition models) or application domains such as object-oriented (OO) or concurrent systems. We present some examples of fault models below to:

• show that although GUIs are presented in several domains (e.g., OO systems or critical interactive systems), the current fault models do not describe GUI faults; and

• illustrate how fault models should be structured to support for instance the faultdetection testing techniques.

State transition fault models. The GUI of a system is specified using User Interface Description Languages (UIDL). Such languages may leverage state transistion models to describe the GUI behavior. A state transition model is composed of states Context and transitions between these states. Bochmann et al. presented several faults that affect FSMs and Petri nets [vBDD + 91]. For example, an FSM is composed of states (initial, end, intermediate), events (input, output), and transitions. FSM faults refer to problems found in such a structure as detailed as follows.

• output faults when an output is not correctly provided;

• transfer faults when a transition goes to an incorrect state;

• transfer faults with additional states when a transfer fault leads to a non-specified state (i.e.,a d d i t i o n a l ) ;a n dadditional or missing transitions from one state to another.

Likewise, Petri nets faults refer to problems into Petri nets components (e.g., arc, places, transitions). Some examples of such faults are: missing/additional input and output arcs, incorrect transition between the places.

FSMs and Petri nets have been used to describe GUI models [START_REF] Navarre | ICOs: A model-based user interface description technique dedicated to interactive systems addressing usability, reliability and scalability[END_REF][START_REF] Blouin | Improving modularity and usability of interactive systems with Malai[END_REF]. GUI models can serve as a basis to build GUI test models. One example of an FSM model used to build GUI test models is presented in Chapter 3. If a GUI model describes correctly a GUI, the test model will produce the test cases correctly. So, the accuracy of a test model also depends on the accuracy of building correctly its representation.

Object-oriented fault models describe faults specific to object-oriented features. An example of OO faults is when OO principles are violated. Offutt et al. have proposed a fault model regards the misuse of inheritance and polymorphic principles [OAW + 01]. Such faults are described independently of a programming language, but the manifestation of their failures is more prone to a specific language. Some examples of OO faults are listed below:

• Inconsistent Type Use (context swapping);

• State Definition Anomaly (possible post-condition violation);

• Indirect Inconsistent State Definition;

• Incomplete Construction;

• State Visibility Anomaly; etc.

Several research studies have used OO faults models to provide more specific mutant operators [START_REF] Binder | Testing object-oriented software: a survey[END_REF][START_REF] Kim | Class mutation: Mutation testing for object-oriented programs[END_REF][START_REF] Ma | Inter-class mutation operators for java[END_REF]. The set of these operators is also referenced in the literature as mutation fault models. These models provide a collection of mutants operators to plant a specific fault. Ma et al. have presented six categories of mutation operators based on OO programming faults [START_REF] Ma | Inter-class mutation operators for java[END_REF]. One example is the incorrect use of Inheritance introduced by the operator hiding variable deletion. This operator removes a declaration of an overriding method, for instance, commenting the line, where av a r i a b l ei sd e c l a r e d . Thus, the related fault consists of the "incorrect variable access" since any reference to that variable will be accessed from the variable defined in the parent (or ancestor) instead of its child. Also, the authors have proposed Java mutant operators. For example, the Java mutant operator "this keyword deletion" introduces the fault "this keyword misuse".

Likewise, Strecker et al. [START_REF] Strecker | Relationships between test suites, faults, and fault detection in GUI testing[END_REF] have presented 12 mutant operators (called as fault classes by the authors) in Java code that affect GUI test suites. These mutants, however, do not characterize GUI faults but Java mutant operators (e.g., class or method faults) that may affect a GUI. Table 2.4 illustrates some of them. Aspect-oriented fault models refer to faults that arise from aspect-oriented programming. AOP fault models describe faults that are distinct from OO and procedureoriented programming [START_REF] Alexander | Towards the systematic testing of aspect-oriented programs[END_REF]. Thus, AOP faults are most likely to appear during the implementation of the cross-cutting concerns such as pointcuts, join points,a n dadvice in AspectJ10 language. Several AspectJ fault models have been proposed in the literature [ABA04, BA06, CTR05, DMM05]. Baekken et al. [START_REF] Bsekken | A candidate fault model for aspectj pointcuts[END_REF] describe several specific faults regarding the AspectJ pointcuts. One example is the incorrect choice of primitive pointcut, where one pointcut should be selected in place of another.

Concurrency fault models define several faults related to concurrent systems. The essential property of these systems is concurrency, which enables several computations executing simultaneously. Developers have faced several problems to implement such a property. One key issue is when the synchronization of concurrent systems is violated. Lu et al. [START_REF] Lu | Learning from mistakes --a comprehensive study on real world concurrency bug characteristics[END_REF] have studied several bugs related to this problem. Each bug was analysed to identify the root cause and thus identify a bug pattern. The results of this analysis are presented into a fault model. This model is structured in three dimensions: bug pattern, bug manifestation,andbug fix strategy, which describe, respectively, the identified faults, their manifestation, and the strategy to fix them. Table 2.5 illustrates the kind of faults presented in the bug pattern.

System-specific fault models describe faults collected from empirical observations of an application domain. Such fault models differ from the aforementioned models since they do not focus on characterizing faults from programming features and languages. Instead, they are based on a system domain. One example is a preliminary

Context

Order

The desired order between two (groups of) memory accesses is flipped Violation (i.e., A should always be executed before B, but the order is not enforced during execution).

Other Concurrency bugs other than the atomicity violation and order violation.

Web-specific fault model proposed by Ricca and Tonella [START_REF] Ricca | Web testing: a roadmap for the empirical research[END_REF]. This model is obtained by analysing the open-source bug repositories of Web applications written in different languages (e.g., PHP, Javascript). The fault categories concern the authentication problems, hyperlink problems, incorrect session management, incorrect generation of error page, etc.

Other system domain that fault models have been used is critical interactive systems. In such a domain, the interface contains an amount of information which is shown in different displays by using a range of technologies (e.g., LCD and CRT screens). This information must to be coherent in all displays to avoid failures provoked by the operator. One example is the interface of instrumentation and control (I&C) systems for nuclear power plants. Fayollas et al. have used fault models to increase the reliability of safety critical systems such as interactive cokpits in avionics systems [FFP + 13]. The interactive cockpit user interfaces are composed events, display managers, and widgets (e.g., push-buttons, radio buttons, edit boxes). These interfaces manage information from a human operator (e.g., crew members) and from user applications (e.g., aircraft systems). One way to validate such interfaces is to ensure that the information received from the operator (e.g., input events) and the data received from the applications are processed correctly to be then visualized on GUIs. So, the three following failures must be avoided:

1. Erroneous display concern the transmission of wrong values to the display; 2. Erroneous control refer to the transmission of actions that differ from the events triggered by the operators;

3. Inadvertent control are related to the transmission of actions that are not performed by the operators.

To prevent these failures, the authors have considered a fault model that cover software faults (e.g., design faults) and physical faults such as crash and transient faults.

By contrast, Pretschner et al. have proposed a generic fault model for quality assurance [START_REF] Pretschner | A generic fault model for quality assurance[END_REF]. The authors qualified this model as generic since it aims at char-acterizing fault models instead of their faults. They demonstrated how some existing fault models (e.g., finite state machine models) can be instantiated from it.

What is the important about the aforementioned fault models is they are presented in several domains, which some of them (e.g., critical interactive systems) are driven by GUIs. Although they describe specific faults that may result in failures (e.g., crashes) observed by a GUI, none of them have presented or discussed GUI faults that may be the root cause for such failures.

In this subsection, we presented the defect classification schemes for GUIs and pointed out their drawbacks. We observed that the current GUI schemes bring several limitations to cover properly GUI faults. Such limitations help us to understand which kinds of faults existing GUI V&V techniques must be overcome. We thus present in the next three subsections the seminal GUI V&V techniques and how they are designed to support GUI testing. The purpose is to show the main drawbacks of GUI testing approaches.

Model-based GUI testing

Model-based testing (MBT) is a software testing technique that relies on models to describe the SUT behavior. MBT is widely applied to automate GUI testing. This subsection gives an overview of the basic MBT process applied for automated GUIs.

The GUI standard MBT process is illustrated in Figure 2.6. This process consists of obtaining GUI test models that are built from the specifications or directly from the SUT. Based on these models, abstract test cases are generated and then concretized to be executed against the SUT. The four MBT artifacts are detailed below.

• GUI test models are test models that describe the structure and behavior of a GUI of the SUT. They contain all possible sequence of user interactions. A GUI model, however, can be designed at different levels of abstractions: modelling standard GUIs based on single input events such as event-flow graphs (EFG) [START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF]; modelling advanced GUIs based on multi-event interactions such as interaction-action flow graph (IFG) [START_REF] Lelli | On model-based testing advanced GUIs[END_REF]; or modelling user scenarios to achieve a particular goal such as task models [START_REF] José | Model-based user interface testing with spec explorer and ConcurTaskTrees[END_REF]. • GUI Oracles yield test verdicts by comparing the actual results of test scripts with the expected ones. A GUI oracle model can be obtained from the requirements specifications or from a stable version11 of a GUI software.

GUI test models can be automatically extracted by reverse engineering from the SUT binaries [START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF] (i.e., using dynamic analysis). Such models of existing GUIs is effective for detecting crashes and regressions: the analysed GUI is then considered as a benchmark. In some cases, however, reverse engineering is not possible. For instance, the norms IEC 60964 and 61771, dedicated to the validation and design of nuclear power plants, require that: developed systems must conform to the legal requirements; models must be created from requirements in that purpose [START_REF] Iec | Nuclear power plants -main control-room -verification and validation of design[END_REF][START_REF]Nuclear power plants -control rooms -design[END_REF]. In this case, GUI models are designed manually from the requirements. The testing process then targets mismatches between a system and its specifications. Paiva proposed an automated MBT approach for GUIs based on the requirements specification [START_REF] Cristina | Automated Specification-Based Testing of Graphical User Interfaces[END_REF]. This specification is written in Spec#12 language and then converted into a FSM to generate automatically GUI test cases.

Furthemore, GUI test models can be refined into GUI models, which are specified using a User Interface Description Language (UIDL). UIDLs are used to model GUIs in different domains (e.g., critical interactive systems, rich interactive GUI systems). For example, Malai [START_REF] Blouin | Improving modularity and usability of interactive systems with Malai[END_REF] and ICOs [START_REF] Navarre | ICOs: A model-based user interface description technique dedicated to interactive systems addressing usability, reliability and scalability[END_REF] architectures have been used to model rich GUIs, i.e., post-WIMP GUIs, whereas GUITAR testing framework [START_REF] Nguyen | GUI-TAR: an innovative tool for automated testing of gui-driven software[END_REF] uses its own UIDL that captures GUI structures (the widgets that compose a GUI and their layout). Examples of GUI test models are: state transition models (e.g.,F S M s or extended FSM such as Markov chain, or Petri nets), graphs (e.g., EFG) or formal languages (e.g., Z language). While Malai uses FSMs to represent GUIs, ICOs leverages Petri nets. Similarly, UML can also be applied to model user interactions using its state machine diagrams [OMG07].

In the current GUI testing approaches, test models are mainly event-flow graphs (EFG) [Mem07, APB + 12]. EFGs contain all the possible sequences of user interactions that can be performed within a GUI. One example is GUITAR that leverages EFGs to support an automated test cases generation. Figure 2.7 gives an general overview of GUITAR process. The first step consists of extracting the GUI structure (e.g., widgets that compose a GUI and their properties such as visibility) by a GUI Ripper tool. Then, this structure is converted into a GUI model, i.e., EFG. Next, the EFG is inferred to generate test cases by using GUI tcgenerator tool. So, GUI Replayer executes those test cases against the SUT. One example of a GUI test sequence to "Draw a black square" on the radio button demo shown in that The main shortcoming of the MBT approaches for GUIs is that they are based on models concerning standard GUIs. Such models will produce test cases that are limited to testing standard widgets and their mono-event interactions. An adaptation of these models is required to test advanced GUIs and thus to detect the new kind of GUI faults. The current limitations of the GUI testing frameworks dedicated to test standard GUIs (e.g., GUITAR) and a promising GUI test model to test advanced GUIs will be discussed in Chapter 3. Furthermore, standard GUI test models (e.g., EFGs) can be built from the SUT by using dynamic analysis. This brings other drawbacks that we discuss in the next subsection.

Dynamic Analysis

Dynamic analysis leverages the SUT execution to observe its external behavior. So, the only software artifact that can be used is the proper SUT (or its binaries). Due to the nature of GUIs, which require user interactions to produce actions, several approaches leverage dynamic analysis to exercise a GUI and thus test its external behavior to look for failures.

A GUI dynamic analysis technique explores the GUI of a SUT to extract all the Context possible sequence of events 13 . The goal is to interact with a GUI through all the possible GUI states. To do this, each widget (e.g., windows or buttons) is traversed and its events are triggered through the GUI. One example is the GUI Ripper step of GUITAR (see Figure 2.7) that dynamically explores a GUI. The information obtained from the GUI will be the basis to build a GUI test model. Three factors, however, should be considered to dynamically traverse a GUI [AFT + 12]:

• the way and the order the events are triggered ;

• precondition of the SUT and its running environment;a n d

• ac r i t e r i o nt os t o pt h eG U Ie x p l o r a t i o n .

One problem that arises when the order of events is not correctly triggered is that: a GUI test model can produce infeasible test cases sequences. For example, a widget is disabled during the test execution when it should be enabled. In this case, the test may fail. Memon proposed an automated approach to repair the infeasible sequences [START_REF] Atif | Automatically repairing event sequence-based GUI test suites for regression testing[END_REF] generated by GUITAR.

Figure 2.8 illustrates the two artifacts generated by GUI Ripper tool: GUI tree on the top and its EFG model on the bottom. The GUI Ripper tool [START_REF] Atif | GUI ripping: Reverse engineering of graphical user interfaces for testing[END_REF] executes dynamically a SUT and extracts its GUI tree. This GUI tree represents the hierarchical GUI structure such as widgets (e.g., w 0 ,. . . , w 8 , where w 0 represents the button "Exit") and their properties. These properties have discrete values (e.g., integer or text) that compose a GUI state. The EFG represents the possible sequences of events behind the GUI structure. Each node of EFG is an event triggered by a widget. For example, the nodes named create and exit in the EFG represent the events triggered by the buttons "Create" and "Exit" in the GUI tree, respectively.

An extension of GUI Ripper to support Android platform, called AndroidRipper,i s presented by Domenico et al. [AFT + 12]. The process is similar to GUI Ripping but the GUI structure is represented by a state machine model. This model contains the set of GUI states and state transitions. The main goal is to find GUI crashes. Also, Takala et al. proposed a dynamic solution to build models of Android applications and generate online GUI test cases [START_REF] Takala | Experiences of systemlevel model-based GUI testing of an android application[END_REF]. The solution uses two separate state machines to build the model to facilitate its reuse on other device models. The first machine represents the state of the SUT and verifies it against the model. The second state machine uses the keyword method to capture the user interactions, for instance, tapping and dragging objects on the screen.

Mariani et al. proposed the AutoBlackTest technique to build a model generating test cases incrementally and automatically while interacting with a GUI of SUTs [START_REF] Mariani | AutoBlackTest: A tool for automatic black-box testing[END_REF][START_REF] Mariani | AutoBlackTest: Automatic black-box testing of interactive applications[END_REF]. While interacting with the SUT, the GUI is analyzed to extract its current state. Then, the behavioral model is updated to select and execute the next action. Thus, the model is built incrementally and the test cases are identified. These test cases are refined and a test suite is then generated automatically. Although most of GUI dynamic approaches build test models to automate steps of a model-based GUI testing. Other solutions may generate sequences of events without creating a GUI test model. A typical example is the Monkey tools such as UI/Application Exerciser Monkey for Android systems. These tools interact with a GUI by randomly sending events to a device (or emulator) such as key pressures, touches pressures, or gestures. They are useful to find failures that result in crashes. Some model-based testing tools (e.g., TEMA tools14 ) have reused Monkey tools to interact with a specific GUI (e.g., Android GUIs) and thus extract the GUI structure.

The main drawback of GUI dynamic analysis techniques is that they require a correct SUT to extract GUI models. If a faulty SUT is used, its corresponding GUI model will be built incorrectly. So, the test cases generated from this model will consider GUI failures as a correct behavior. For this reason, GUI testing techniques that use dynamic analysis to support test cases generation have demonstrated their effectiveness during regression testing. 52 Context

Static Analysis

While dynamic testing techniques exercise a SUT looking for the presence of failures, static analyses check whether a software artifact (which does not require the SUT execution) is fault or error-free. Thus, static analysis techniques are performed on several software artifacts such as the specifications (e.g., model checking) or the source code (aka. static code analysis).

A static code analysis is a technique that examines the source code of a SUT without executing it. This technique can be applied for different purposes. One purpose is to infer the source code to detect bad coding practices such as design smells. GUI bad coding practices may be error-prone as standard bad coding practices. Another goal is to apply the static code analysis to locate faults directly in a source code, whether or not such faults may provoke a failure. Because of this, static analysis is aka. variant of testing.

In this subsection, we first give a brief introduction on the purpose of static code analysis tools. Then, we present the GUI static analysis approaches and how they target the quality of GUIs.

Static Analysis tools

Static code analysis is usually supported by automated tools. There are several static code analysis solutions that vary in their scope from design smell detection [BMMM98, Fow99, MPN + 12, SKBD14] to maintenance and evolution of systems [Sta07, APB + 12, ZLE13]. Such solutions aim at solving several problems when the aspects of code quality (e.g., understandability and changeability) are affected. The main solutions of static analysis tools are presented below.

Style checkers aim at assisting developers to write code that adheres to quality checkers. Quality checkers are a set of coding standards such as programming rules, naming conventions, and layout specifications. One example of a quality checker tool is Checkstyle 15 . This tool analyses the coding style and conventions of a Java code checking for whitespace, method and line length, empty blocks, etc.

Bug finders look for potential defects in the source code of a particular programming language. The goal is to raise warnings into a code where the system will behave incorrectly. Such tools are based on several rules (or patterns or idioms) to indicate often real defects. A well-known tool is Find bugs16 that detects several errors in Java systems such as infinite recursive loops, deadlocks,a n dcatch exceptions. Another tool to identify potential bugs and bad programing practices in Java code is PMD17 .

Design smells detectors look for bad design problems that degrade the code quality. A design smell (aka. code smells or bad smells) is any symptom in the source code that may indicate a design problem or a poor design choice. The characterization and detection of object-oriented design smells have been widely studied [BMMM98, Fow99, GPEM09, MGDLM10, KVGS11, MPN + 12, PBDP + 14, ZFS15]. The most relevant work about design smells is proposed by Fowler et al. [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]. In this work, the authors describe 22 design smells and the refactoring strategies to correct them.

Note that some tools have more than one purpose, i.e., they combine two or more solutions. For example, PMD looks for both bugs and bad programing practices.S i m ilarly, Style checkers detect design violations that may be characterized as design smells [START_REF] Samarthyam | Refactoring for Software Design Smells[END_REF]. Several tools leverage that combination to cover a domain-specific. This is the case of static analysis tools for GUIs. These tools can leverage the code metrics (e.g., CC) or code structures (e.g., data flow structure) to formulate heuristics or to build/improve test models, that may also be used by detection strategies such as design smell detections.

GUI Static Analysis tools

Table 2.6 gives an overview of several GUI approaches that use static analyses to achieve a specific purpose. They can be applied for supporting GUI testing by improving a GUI test model [SSG + 10], or this obtained model can be used to detect bad smel ls [START_REF] Silva | An approach for graphical user interface external bad smells detection[END_REF]. We categorize those approaches according to the main purpose they serve.

Several approaches have extended GUITAR by using static analyses to extract information from the source code. The purpose is to improve GUI testing techniques by building a richer GUI test model, which will support the test case generation. For example, Arlt et al. use static analyses to identify and removes redundant test sequences in GUI test suites [APB + 12]. They have extended GUI Ripper to infer dependencies between GUI event handlers18 in the source code. These dependencies are included in a model called Event Dependency Graph (EDG). Similarly, Yang et al. implement a static analysis in a tool called ORBIT to extract a set of events from the source code of Android applications [START_REF] Yang | A grey-box approach for automated GUI-model generation of mobile applications[END_REF]. Both static analysis approaches aim at building more complete GUI test models. Such models will produce more feasible test cases that will be able to find failures across different GUI domains. The GUISurfer process is illustrated in Figure 2.9. First, a language-dependent parser is used to obtain the abstract syntax tree (AST) from the source code. A code slicing technique is used to interact with this AST and extract only GUI related data, which represent a GUI model. Then, a language independent tool receives this model and generates the GUI outputs files (e.g., events, conditions, actions, and states). These files are transformed in behavior models such as FSMs to support GUI testing.

Context

Other static analysis approaches focus on GUI maintenance and evolution. Grechanik et al. propose a tool called REST to identify test scripts that are affected when a GUI of a system evolve [START_REF] Grechanik | Maintaining and evolving guidirected test scripts[END_REF]. Zhang et al. have extended REST to automatically repair broken workflows in Swing GUIs [START_REF] Zhang | Automatically repairing broken workflows for evolving GUI applications[END_REF]. A workflow is broken when GUI widgets are replaced or shifted in a new version of the GUI. The authors combine random testing and static analysis to infer workflows from a user's point of view. The static analysis is limited to find methods related to a GUI action. Although a GUI listener can handle several actions 19 , GUI actions presented in a same listener are not tackled. So, the static analysis approach was less effective. This work highlights the difficulty "for a static analysis to distinguish UI actions [GUI commands] that share the same event handler [GUI listener] ". In this thesis, we tackle this problem by developing an approach to accurately detect GUI commands that compose GUI listeners.

Staiger also proposes a static analysis to extract GUI code, widgets, and their hierarchies in C/C++ software systems [START_REF] Staiger | Static analysis of programs with graphical user interface[END_REF]. This approach, however, is limited to find relationships between GUI elements and thus does not analyze GUI event handlers. Zhang et al. propose a static analysis to find violations in GUIs [START_REF] Zhang | Finding errors in multithreaded GUI applications[END_REF]. These violations occur when GUI operations are invoked by non-UI threads leading a GUI error. The static analysis is applied to infer a static call graph and check the violations. This technique is implemented on the top of WA L A framework. An interesting finding reported by the authors is that "GUI developers have already used design patterns, run- time checks, and testing to avoid violating the single-GUI-thread rule. However, due to the huge space of possible UI interactions, hard-to-find invalid thread access errors still exist". In our work, we tackle a GUI design smell that affects GUI controllers, which are based on GUI architectural patterns.

Frolin et al. propose an approach to automatically find inconsistencies in MVC JavaScript applications [START_REF] Ocariza | Detecting inconsistencies in JavaScript MVC applications[END_REF]. GUI controllers are statically analyzed to identify consistency issues (e.g., inconsistencies between variables and controller functions). This work is highly motivated by the weakly-typed nature of Javascript. The main issue is the erroneous understanding of the relationship between the JavaScript code and the API "Document Object Model ", which is responsible to represent the hierarchy of HTML elements and their properties. The authors analyzed 300 bug reports to understand the issues specific for JavaScript applications (e.g., their root cause and propagation). The static analysis is implemented in a tool called AUREBESH. This tool detected 15 bugs in 22 real-world MVC applications. They established four patterns to explain the root cause of these bugs. For example, one pattern, called boolean assigned a string, occurs when a developer assigning a string to a variable that expects a boolean value.

Regarding the GUI design smells, we first recall the characterization and detection Context of object-oriented design smells to illustrate how they cannot be used in our work presented in Chapter 4. For instance, Fowler [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF] and Brown et al. [START_REF] Brown | AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[END_REF] characterized multiple design smells, resp. anti-patterns, associated with refactoring operations. The detection of design smells mainly relies on the association of code metrics (e.g., LOC or CC) to form heuristics. Closely related, Moha et al. propose Decor, a method to specify and then detect design smells [START_REF] Moha | DECOR: A method for the specification and detection of code and design smells[END_REF]. In this thesis, we characterized a new type of GUI design smell, called Blob listener , as a GUI listener that contain more than one GUI command (Section 4.3). From this definition, the aforementioned approach can be hardly used to detect Blob listeners. It would require considering the number of GUI commands per GUI listener as a code metric, and specify a rule based on this new metric to detect Blob listeners. If considering such a metric as a standard metrics is relevant given the increasingly interactivity of software systems, it is not possible yet. Moreover, our detection strategy aims at precisely locating each GUI commands that compose Blob listeners, not just detecting Blob listeners.

Sahin et al.

propose an approach to generate design smell detection rules using a dedicated optimization technique [START_REF] Sahin | Code-smell detection as a bilevel problem[END_REF]. The goal is to ease the definition of detection rules by automatically analyzing code instead of relying on a manual process. Closely related, Zanoni et al. propose an approach based on machine learning to detect design smells [START_REF] Zanoni | On applying machine learning techniques for design pattern detection[END_REF]. Khomh et al. propose goal question metric-based approach to detect anti-patterns [START_REF] Khomh | BDTEX: A GQM-based bayesian approach for the detection of antipatterns[END_REF]. Because of GUI specificities, the Blob listener detection rule we propose does not rely on standard code metrics. These approaches, however, may be applied on detected Blob listeners to see whether interesting detection rules or results are produced and to what extent they can be used to precise our approach. Several research work on design smell characterization and detection are domain-specific. For instance, Moha et al. propose a characterization and a detection process of serviceoriented architecture anti-patterns [MPN + 12]. Garcia et al. propose an approach for identifying architectural design smells [START_REF] Garcia | Identifying architectural bad smells. In Software Maintenance and Reengineering[END_REF]. Similarly, this thesis aims at motivating that GUIs form another domain concerned by specific design smells that have to be characterized.

Unlike the aforementioned object-oriented design smells, less research work focuses on GUI design smells. We identified two research studies focus on design smells for GUIs. These studies, however, leverage static analysis to detect the presence of design smells in another type of GUI artifacts such as GUI dialog models [START_REF] Silva | An approach for graphical user interface external bad smells detection[END_REF] and GUI test scripts [START_REF] Chen | Bad smells and refactoring methods for GUI test scripts[END_REF]. Also, the strategies of design smell detections may be based on metrics or existing OO design smells. Silva et al. propose an external bad smells detection in dialog models [START_REF] Silva | An approach for graphical user interface external bad smells detection[END_REF]. External by the authors means looking for bad smells from the running system instead of from source code analysis. Dialogue models describe the behaviour of a user interface such as GUI components and their relationship. The authors use the static analysis approach, tooled by GUISurfer [SSG + 10], to build such models. To detect the bad smells in the dialog models, the approach calculates two metrics: Pagerank and Betweenness. These two metrics are used to measure the user interface complexity. This complexity can reveal some bad smells such as erroneous distributed complexity along the application behavior or misplaced central axes in the interaction between users and the system. The authors show how these metrics can be applied but no detail about the bad smells is provided.

Chen and Wang [START_REF] Chen | Bad smells and refactoring methods for GUI test scripts[END_REF] identify 11 bad smel ls in GUI test scripts illustrated in Table 2.7. This choice is motivated by the fact that the structure of a GUI test script is similar to the source code (e.g., statements) in some aspects. First, a GUI test script is a sequence of actions that will be executed over the GUI of a SUT. These actions are represented by GUI events or assertions, this concern the correctness of the SUT. Second, a method also contains a sequence of statements that will be executed when it is invoked. For example, the bad smell long method (aka. God Method [START_REF] Fowler | Refactoring: Improving the Design of Existing Code[END_REF]), which is too large since it contains several statements, is analogous to the bad smell long keyword. This bad smell shows up in a keyword-driven test (KDT) script when one keyword contains several actions. These two bad smells are similar since they tackle the same problem but in different contexts: several statements in a method and several actions in a test script. Also, the authors propose 16 refactoring methods to remove automatically such bad smells. The bad smell long keyword can be removed by applying the method "extract macro event". This method removes several actions found into a keyword (or macro event) to create a new reduced one. In this thesis, we identify a new type of GUI design smell, Blob listener , that are also related to the design smell long (God) Method. Blob listener is a GUI particular instance of the God Method. However, we do not investigate the correlation between the Blob listeners and others GUI artifacts.

Bad Smell Description

Unsuitable Naming A keyword, macro component, macro event, or primitive component is not properly named.

Duplicated Actions

Some duplicated actions appear in multiple places.

Long Keyword or Long Macro Event

A keyword (or macro event) contains too many actions.

Long Parameter List

The parameter list of a keyword or macro event is too long.

Shotgun Surgery

Multiple places need to be modified with a single change.

Large Macro Component

A single macro component contains too many primitive components, macro events, and macro components.

Feature Envy

A macro event uses another macro component's macro events or components excessively.

Middle Man

A macro component delegates all its tasks to another macro component.

Lack of Macro Events

A macro component does not have any macro events.

Lack of Encapsulation

Using primitive events directly instead of encapsulating actions into macro events.

Inconsistent Hierarchy

The macro component hierarchy is inconsistent with the structure of the GUI.

One may note that metrics play a special role to the detection strategies of design smells. However, few studies focus on establishing metrics that are specific for GUIs.

Context

Magel et al. [START_REF] Magel | GUI structural metrics and testability testing[END_REF] introduce five GUI structural metrics. We detail below three of them that deal with the complexity of GUIs.

• Controls' Count (CC)/LOC measures how much the code of a system is dedicated to implement a GUI. This metric is an adaptation of CC metric, which is based on the total number of controls' count that has an interface. A high CC value may indicate the system's complexity. However, this metric alone does not reflect the GUI complexity since some controls are easier to test than others.

• The GUI tree depth measures the depth of a GUI. A GUI structure is mapped to a tree model and then the depth of the tree is calculated based on its leaf deepest node. The authors believe that this metric can be useful to select more representative GUI test scenarios. For instance, the controls that have the same parent of the selected control may be excluded from a test scenario when it starts from the lowest level control. Such a reduction is based on heuristics that are not provided by the authors.

• The structure of the tree measures how much a GUI is complex. The complexity is based on the fact that if a tree has the most of GUI controls on the top, this tree is more complex. From a testing point of view, this kind of tree reflects more user choices or selections.

These metrics aim at measuring how much effort is needed to test a particular GUI.

They do not indicate a problem for instance in the source code of a GUI. Most of GUI research studies have used mature metrics such as CC to measure the complexity of a GUI code. Other metrics, however, may also be adapted to detect specific problems in the GUI code such as number of changes (per commit, class, or method) and cohesion metrics. For instance, the cohesion metric has been applied to indicate fat interfaces [START_REF] Romano | Refactoring fat interfaces using a genetic algorithm[END_REF], which are classes that handle several methods from different clients. In our work, this metric may be adapted to measure the cohesion of GUI controllers that are Blob listeners. We believe that several metrics can be used or adapted to help software engineers to identify problems in GUI code. In this thesis, we have used cyclomatic complexity as an initial step to investigate the code of GUI controllers to then establish a more elaborate and precise rule, i.e., the number of GUI commands per GUI listener, to automatically detect Blob listeners.

In this section, we presented the GUI V&V techniques and the GUI defect classifications schemes to support them. The limitations of GUI schemes allowed us to explain the main drawbacks of current GUI testing techniques. On the one hand, GUI testing techniques aim at the reliability of standard GUIs. So, they fail in providing solutions to test advanced GUIs and their interactive features. By the other hand, GUI analysis approaches aim at the quality of GUIs. None of them have targeted design smells that may degrade the GUI code.

Conclusions

59

Conclusions

This chapter presented the state-of-the-art of testing GUI systems. GUIs play a vital role in designing interactive systems. The new trend in GUI design brings several specificities that impact on how to test GUIs. GUI testing has been applied to find GUI failures provoked by GUI defects. Several defect classification schemes have been proposed but few of them focus on GUIs. The gap is twofold. First, the proposed GUI defect classifications are not properly defined since they are based on a small set of standard widgets. Second, GUI schemes do not consider defects that arise from richer GUIs. For example, GUI errors that show up from the graphical nature of post-WIMP GUIs, their ad hoc widgets and complex interactions are not covered. Several kinds of faults specific to GUIs have been identified and described into a new GUI fault model, which will be presented in Chapter 3.

Different GUI V&V techniques are detailed. They vary in their purpose w.r.t. the GUI artifact used to provide automated solutions. Most of GUI approaches focus on automated GUI testing for standard GUIs. Also, MBT approaches that leverage dynamic analysis to build GUI test models have demonstrated their ability to detect crashes and regressions. Such approaches, however, require expressive GUI models to produce more effective test cases. Different kinds of UIDLs have thus been proposed to describe intrinsic components of GUI design, which are represented as GUI models. Such models have been used to derive GUI test models and thus support test case generation. Also, GUI V&V techniques inspect the source code to measure the code quality for instance detecting error-prone code that may result in GUI failures. Static analysis approaches have been applied for different purposes such as GUI testing, GUI maintenance and evolution. We identified few studies focus on GUI design smells.A new type of design smell specific for GUIs is identified and automatically detected by a novel GUI static analysis proposed in this thesis. We will present the details in Chapter 4.

Chapter 3

GUI fault model

This chapter presents an original fault model for graphical user interfaces. This fault model is a GUI fault classification scheme structured at two levels: user interface faults and user interaction faults. For each fault we illustrate which GUI is affected and how it occurs as GUI failure (Section 3.1). We evaluate the coverage of our fault model through an empirical analysis: identifying and classifying several GUI failures from open-source bug repositories (Section 3.2). We also assess the ability of two GUI testing tools (GUITAR and Jubula) to find real GUI failures previously classified (Section 3.3).

The practical use of the GUI fault model is demonstrated by forging several mutants of a highly interactive open-source system (LaTeXDraw). These mutants implement the faults described in our fault model. We then conduct a third experiment to evaluate the ability of those GUI testing tools to detect these mutants (Section 3.4). We also discuss the reasons why several mutants are not killed. A precise analysis of the limits of GUI testing frameworks for testing advanced GUIs is presented in Section 3.6. We selected GUITAR, a standard GUI model-based testing framework, to study and explain the limitations of the current standard GUI testing approaches. We also present the concept of interaction-action-flow graph to tackle these limitations (Section 3.7). The benefits of this approach are demonstrated through two different use cases.

The contributions of this chapter have been published in [LBB15, LBBC15].

Fault Model

In this section we present an exhaustive GUI fault model. To build the fault model we first analyzed the state-of-the-art of HCI concepts (recall Chapter 2). We then analyzed real GUI bug reports (different than those used in Section 3.2) to assess and precise the fault model. We performed a round trip process between the analysis of HCI concepts and GUI bug reports until a stable fault model was obtained.

In Chapter 2, we present the definitions of fault, error, failure. Based on these definitions, we propose the following definitions of a GUI fault, error, and failure: Definition 3.1 (GUI Fault) GUI faults are differences between an incorrect and a correct behavior description of a GUI. A GUI fault can be introduced at different levels of a GUI software (e.g., GUI code, GUI models). An illustration of a GUI fault is: a correct line of GUI code vs an incorrect line of GUI code. For example, a GUI fault can be activated when an entry,s u c ha sa value into an input widget, is not handled correctly by its GUI code. So, an unexpected GUI state is manifested (e.g., a crash as a GUI failure) when a user clicks on a button after typing this entry.

Our fault model is divided into the following groups:

• User interface faults refer to faults that affect the structure and the behavior of graphical components of GUIs.

• User interaction faults refer to faults that affect the interaction process, i.e., when a user interacts with a GUI.

User Interface Faults

GUIs are composed of widgets that can act as mediators to interact indirectly (e.g., buttons in WIMP GUIs) or directly (direct manipulation principle in post-WIMP GUIs) with objects of the data model. In this section, we categorize the user interface faults, i.e., faults related to the structure, the behavior, and the appearance of GUIs. We further break down user interface faults into two categories: the GUI structure and aesthetics,a n dt h edata presentation faults, as introduced below. Table 3.1 presents an overview of these faults and their potential failures.

GUI Structure and Aesthetics Fault

This fault category corresponds to unexpected GUI designs. Since GUIs are composed of widgets laid out following a given order, the first fault is the incorrect layout of widgets (GSA1). Possible failures corresponding to this fault occur when GUI widgets follow an unexpected layout (e.g., wrong size or position). The next fault concerns the incorrect state of widgets (GSA2). Widgets' behavior is dynamic and can be in different states such as visible, enabled, or selected. This fault occurs when the current state of a widget differs from the expected one. For example, a widget is unexpectedly visible.

The following fault treats the unexpected appearance of widgets (GSA3). That concerns aesthetic aspects of widgets not bound to the data model, such as look-and-feels, fonts, icons, or misspellings. Not possible to click on a button since it is not activated. Awindo wisnotvisiblesothatitswidgets cannot be used. Not possible to draw in the drawing area of a drawing editor since it is not activated.

Fault Model

GSA3 Incorrect appearance of widgets (e.g., font, color, icon, label)

The icon of a button is not visible.

In a GUI of a power plant, the color reflecting the critical status of a pump is green instead of red.

Data Presentation DT1 Incorrect data rendering (e.g., scaling factors, rotating, converting)

The size of a text is not scaled properly. In a drawing editor, a dotted line is painted as a dashed one. Ar e c t a n g l ei sp a i n t e da sa ne l l i p s e .

DT2 Incorrect data properties (e.g., selectable, focused) Awebaddressinatextisnotdisplayed as hyperlink.

DT3 Incorrect data type or format (e.g.,d e g r e evs radian, float vs double)

The date is displayed with 5 digits (e.g., dd/mm/y) instead of 6 digits (e.g., dd/mm/yy). At e x tfi e l dd i s p l a y sa na n g l ei nr a d i a n instead of in degree.

Data presentation

In many cases, widgets aim at editing and visualizing data. For example with WIMP GUIs, text fields or lists can display simple data to be edited by users. Post-WIMP GUIs share this same principle with the difference that the data representation is usually ad hoc and more complex. For example, the drawing area of a drawing editor paints shapes of the data model. Such a drawing area has been developed for the specific case of this editor. That permits to represent graphically in a single widget complex data (e.g., shapes). In other cases, widgets aim at monitoring data only. This is notably the case for some GUIs in control commands of power plants where data are not edited but monitored by users. The definition of data representations is complex and error-prone. It thus requires adequate data presentation faults.

The first fault of this category is the incorrect data rendering (DT1). DT1 is pro-voked when data is converted or scaled wrongly. Possible failures for this fault are manifested by unexpected data appearance (e.g., wrong color, texture, opacity, shadow) or data layout (e.g., wrong position, geometry). The second fault concerns incorrect data properties (DT2). Properties define specific visualization of data such as selectable or focused. A possible failure is a web address that is not displayed as a hyperlink. The last fault (DT3) occurs when an incorrect data type or format is displayed. For instance, an angle value is displayed in radian instead of in degree.

User Interaction Faults

In this section, we introduce the faults that treat user interactions. The proposed faults are based on the characteristics of WIMP and post-WIMP GUIs detailed in the previous section. For each fault we separated our analysis into two parts. One dedicated to WIMP interactions and another one to post-WIMP interactions. WIMP interactions refer to interactions performed on WIMP widgets. They are simple and composed of few events (click1 , key pressed, etc.).

Post-WIMP interactions refer to interactions performed on post-WIMP widgets. Such interactions are more complex since they can be multimodal, i.e.,i n v o l v em u l t i p l e input devices (gesture, gyroscope, multi-touch screen); be concurrent (e.g.,inbi-manual interactions the two hands evolve in parallel); be composed of numerous events (e.g., multimodal interactions may be composed of sequences of pressure, move, and voice events). Subsequently the direct manipulation principles, other particularities of post-WIMP interactions are that they aim at: being as natural as possible; providing users with the feeling of handling data directly (e.g., shapes in drawing editors). Table 3.2 summarizes the user interaction faults and some of their potential failures for both WIMP and post-WIMP interactions. These faults are detailed as follows.

Interaction Behavior

Developing post-WIMP interactions is complex and error-prone. Indeed, as explained in Chapter 2, it may involve many sequences of events or require the fusion of several modalities such as voice and gesture. So, the first fault (IB1) occurs when the behavior of the developed interactions does not work properly. This fault mainly concerns post-WIMP widgets since WIMP widgets embed simple and hard-coded interactions. For instance, an event such as pressure can be missing in a bi-manual interaction. Another example is the incorrect synchronization between the voice and the gesture in a voice+gesture interaction. GUI toolkits, however, are progressively providing developers with predefined basic post-WIMP interactions. For instance, JavaFX introduced the swipe, zoom, and rotate gesture interactions2 .

RV S B 2 R e ve r t i n g t h e current interaction in progress works incorrectly

Pressing the key "Escape"d u r i n ga DnD does not abort this last. Saying the word "Stop"d o e sn o t stop the interaction in progress.

RV S B 3 R e ve r t i n g t h e current action in progress works incorrectly

Clicking on the button "Cancel "t o stop the loading of the file previously selected does not work properly.

Feedback

FDBK1 Feedback provided by widgets to reflect the current state of an action in progress works incorrectly

The progress bar that shows the loading progress of a file works incorrectly.

FDBK2 The temporary feedback provided all along the execution of long interactions is incorrect

Given a drawing editor, drawing a rectangle using a DnD interaction does not show the created rectangle during the DnD as expected.

GUI fault model

Action

This category of faults groups faults that concern actions produced while interacting with the system. The first fault (ACT1) focuses on the incorrect results of actions.I n this case the expected action is executed but its results are not correct. For instance with a drawing editor, a failure can be the translation of one shape to the given position (-x, -y) while the position (x, y) was expected. The root cause of this failure can be located in the action itself or in its settings. For instance, a first root cause of the previous failure can be the incorrect coding of the translation operation. A second root cause can be located in the settings of the translation action.

The second fault (ACT2) concerns the absence of action when interacting with the system. For instance, this fault can occur when an interaction, such as a keyboard shortcut, is not correctly bound to its widget.

The third fault (ACT3) consists of the execution of wrong actions. The root cause of this fault can be that the wrong action is bound to a widget at a given instant. For instance: clicking on the button Save shows the dialogue box used for loading; doing a DnD interaction on a drawing area selects shapes instead of translating them.

Reversibility

This fault category groups three faults. The fault (RVSB1) concerns the incorrect behavior of the undo/redo operations. Undo and redo operations usually rely on WIMP widgets such as buttons and key shortcuts. These operations revert or re-execute actions already terminated and stored by the system. A possible failure is the incorrect reversion of the latest executed action when the key shortcut ctrl+z is used.

Contrary to WIMP interactions, that are mainly one-shot, many interactions last some time such as the DnD interaction. In such a case, users may be able to stop an interaction in progress. The second fault (RVSB2) thus consists of the incorrect interruption of the current interaction in progress. For instance, pressing the key "Escape" during a DnD does not stop this last as expected. This fault could have been classified as an interaction behavior fault. We decided to consider it as a reversibility fault since it concerns the ability to revert an ongoing interaction.

Once launched, actions may take time to be executed entirely. In this case such actions can be interrupted. The third fault (RVSB3) concerns the incorrect interruption of an action in progress. A possible failure concerns the file loading operation: clicking on the button "Cancel " to stop the loading of a file does not work properly.

Feedback

Widgets are designed to provide immediate and continuous feedback to users while they interact with them. For instance, progress bars that show the loading progress of a file is a kind of feedback provided to users. The first fault of this category (FDBK1) concerns the incorrect feedback provided by widgets, where feedback reflects the current state of an action in progress. This fault focuses on actions that last in time and which progress should be monitored by users.

The second fault (FDBK2) focuses on potential ly long interactions (i.e., interactions that take a certain amount of time to be completed) which progress should be discernible by users. For instance with a drawing editor, when drawing a shape on the drawing area, the shape in creation should be visible so that the user knows the progression of her work. So, a possible failure is drawing a rectangle using a DnD interaction, that works correctly, does not show the created rectangle during the DnD as expected.

Discussion

The definition and the use of a fault model raise several questions we discuss about in this subsection.

What are the benefits of the proposed GUI fault model?

The benefits of our GUI fault model are twofold. First, a fault model is an exhaustive classification of faults for a specific concern [vBDD + 91]. Providing a GUI fault model permits GUI developers and testers to have a precise idea of the different faults they must consider. As an illustration, Section 3.2 describes an empirical analysis we conducted to classify and discuss about GUI failures of open-source GUIs. Second, our GUI fault model allows developers of GUI testing tools to evaluate the efficiency of their tool in terms of bug detection power w.r.t. a GUI specific fault model. As detailed in Section 3.4, we created mutants of an existing GUI. Each mutant contains one GUI failure that corresponds to one GUI fault of our fault model. Developers of GUI testing tools can run their tools against these mutants for benchmarking purposes.

Should usability have been a GUI fault?

Answering this question requires the definition of a fault to be re-explained: a fault is ad i fference between the observed behavior description and the expected one. Usability issues consist of reporting that the current observed behavior of a specific part of a GUI lacks at being somehow usable. That does not mean the observed behavior differs from the behavior expected by test oracles. Instead, it usually means that the expected behavior has not been defined correctly regarding some usability criteria. That is why we do not consider usability as a GUI fault. This reasoning can be extended to other concerns such as performance.

How to classify GUI failures into a fault model?

A GUI failure is a perceivable manifestation of a GUI error. Classifying GUI failures thus requires to have identified the root cause (i.e., GUI fault) of the failure. So, classifying GUI failures can be done by experts of the GUI under test. These experts need sufficient information, such as patches, logs, or stack traces, to identify whether the root cause of a failure is a GUI fault to then classify it. For example, given a failure manifested through the GUI and caused by a precondition violation. In this case, such a failure is not classified into the GUI fault model. Similarly, classifying correctly a GUI failure also requires to qualify the involved widgets (e.g.,s t a n d a r do rad hoc) as well as the interaction (e.g., mono-event or multiple-event interaction).

GUI fault model

How to classify failures stemming from other failures?

For instance, the incorrect results of the execution of an action (action fault) let a widget not visible as expected (GUI structure fault). In such cases, only the first failure must be considered since it puts the GUI in an unexpected and possibly unstable state. Besides, the appearance of a GUI error depends on the previous actions and interactions successfully executed. Typical examples are the undo and redo actions. A redo action can be executed only if an action has been previously performed. Furthermore, the success of a redo action may depend on the previous executed actions. We considered this point during the creation of mutants (as detailed in Section 3.4) to provide failures that appear both with and without previous actions.

In the next three sections, we present empirical studies that assess the relevance of our GUI fault model when applied to real situations.

Relevance of the Fault Model: an empirical analysis

In this section the proposed GUI fault model is evaluated. Our evaluation has been conducted by an empirical analysis to assess the relevance of the model w.r.t. faults currently observed in existing GUIs. The goal is to state whether our GUI fault model is relevant against failures found in real GUIs.

Introduction

To assess the proposed fault model, we analyzed bug reports of five popular open-source software systems: Sweet Home 3D, File-roller, JabRef, Inkscape, and Firefox Android. These systems implement various kinds of widgets, interactions, and encompass different platforms (desktop and mobile). Their GUIs cover the main following features: indirect and direct manipulation; several input devices (e.g., mouse, keyboard, touch); ad hoc widgets such as canvas; discrete data manipulation (e.g., vector-based graphics); and undo/redo actions.

Experimental Protocol

Bug reports have been analyzed manually from the researcher/tester perspective by looking only at data available in the failures report (i.e., black box analysis). To focus on detailed and commented bug reports that concern GUI failures, the selection has been driven by the following rules. Only closed, fixed, and in progress bug reports were selected. The following search string has been also used to reduce the resulting sample:

(interface OR "user interface" OR "graphical user interface" OR "graphical interface" OR GUI OR UI OR layout OR design OR graphic OR interaction OR "user interaction" OR interact OR action OR feedback OR revert OR reversible OR undo OR redo OR abort OR stop OR cancel ).

Relevance of the Fault Model: an empirical analysis 71 Each report has been then manually analyzed to state whether it is a GUI failure. Also, selected bug reports have to provide explanations about the root cause of the failure such as a patch or comments. This step is crucial to be able to categorize the failures using our GUI fault model considering their root cause. We also discarded failures identified as non-reproducible, duplicated, usability, or user misunderstanding. From this selection we kept 279 bug reports (in total for the five systems) that describe one GUI failure each. The following sub-sections discuss about these failures and the classification process.

Classification and Analysis

All the 279 failures have been successfully classified into our fault model. 3.3 shows the distribution of the 279 analyzed GUI failures per software and category (user interface or user interaction). These results point out that the systems Sweet Home 3D and Firefox Android seem to be more affected by user interface failures. Most of these failures concern the GUI structure and aesthetics fault. That can be explained by the complex and ad hoc GUI structure of these systems. File Roller and JabRef GUIs include widgets with coarse-grained properties (i.e.,s i m p l ei n p u tv a l u e such as number or text). Most of their failures concern WIMP interactions classified into the action category. In contrast, Inkscape presented more failures classified as post-WIMP. Indeed, Inkscape, a vector graphics software, mainly relies on its drawing GUI fault model area that provides users with different post-WIMP interactions. These failures have been categorized mainly into interaction behavior, action,a n dreversibility. As depicted by Figure 3.2, 41% of these 279 GUI failures are originated by faults classified into the user interface category and 59% into the user interaction category. Most of user interaction failures have been classified into the incorrect action results (54%). This plot also highlights that only 25% of the analyzed user interface failures and 18% of the user interaction ones have been classified as post-WIMP. We comment these results in the following subsection.

Discussion

The empirical results must be balanced with the fact that user interactions are less tangible than user interfaces. So, users may report more GUI failures when they can perceive failures graphically (an issue in the layout of a GUI or in the result of an action visible through a GUI). Users, however, may have difficulties to detect a failure in an interaction itself while interacting with the GUI. That may explain the low number of failures (4%) classified into Interaction Behavior. Another explanation may be the primary use of WIMP widgets, relying on simple interactions.

In our analysis, many failures that could be related to Feedback were discarded since they concerned enhancements or usability issues, which are out of the scope of a GUI fault model as discussed previously. For instance, GUI failures that concern the lack of haptic feedback in Firefox Android were discarded. So, few faults (1%) were classified into this category. Another explanation may be the difficulty for users to identify feedback issues as real failures that should be reported.

We observed that some reported GUI failures are false positives regarding the fault localization: if the report does not have enough information about the root cause of a failure (e.g., patch or exception log), a GUI failure can be classified in a wrong fault category. For example, when moving a shape using a DnD does not move it. At a first glance, the root cause of this failure can be associated to an incorrect behavior of the DnD. So, this failure can be categorized into the interaction behavior. However, after analyzing the root cause this failure refers to an action failure since the DnD works properly, but no action is linked to this interaction.

Likewise, the failures related to Reversibility and Feedback were easily identified through the steps to reproduce them. For example in JabRef, "pressing the button "Undo" will clear all the text in the field, but then pressing the button "Redo" will not recover the text ". Furthermore, some systems do not revert interactions step by step but entirely. This can imply a failure from a user's point view, but sometimes it is considered as an invalid failure (e.g., requirements vs. usability issues) by developers. In JabRef, the undo/redo actions did not revert discrete operations. For example, pressing the button "Undo" clears all texts typed into different text fields instead of clearing only one field each time the button "undo" is pressed.

Another important point concerns the WIMP vs. post-WIMP GUIs faults. We classified more failures involving WIMP than post-WIMP widgets. A possible explanation is that, despite the increasing interactivity of GUIs, the analyzed GUIs still rely more on WIMP widgets and interactions. Moreover, users now master the behavior of WIMP widgets so that they can easily identify when they provoke failures. It may not be the case with ad hoc and post-WIMP widgets.

Are GUI Testing Tools Able to Detect Classified Failures? An Empirical Study

This section provides an empirical study of two GUI testing tools: GUITAR and Jubula3 . To demonstrate the current limitations of GUI testing tools in testing real GUIs, we applied those tools to detect the failures previously classified into our GUI fault model.

GUITAR and Jubula

GUITAR is one of the most widespread academic GUI testing tools. It extracts the GUI structure by reverse engineering. This structure is transformed into a GUI Event Flow Graph (EFG), where each node represents a widget event. Based on this EFG, test cases are generated and executed automatically over the SUT. We used the plugin for Java Swing (i.e., JFC GUITAR version 1.1.1) 4 . In GUITAR, each test case is composed by a sequence of widget events. The generation of test cases can be parameterized with the size of that sequence (i.e., test case length). Jubula is a semi-automated GUI testing tool that leverages pre-defined libraries to create test cases. These libraries contain modules that can be reused to generate manually test sequences. The modules encompass actions (e.g., check, select) and interactions (e.g., click, drag and drop) over different GUI toolkits (e.g., swing, SWT, RCP, mobile). We have reused the library dedicated to Java Swing (Jubula version 7.2) to write the test cases presented in the next experiments. This library contains actions to test only standard widgets such as dragging a column/row of a table by passing an index. To test ad hoc widgets (e.g., canvas), we made a workaround by mapping actions directly to these widgets. For example, to draw a shape on canvas we need to specify the exact position (e.g., drag and drop coordinates) where the interaction should be executed.

Experiment

We selected JabRef5 , a software to manage bibliographic references. JabRef is written in Java which allows us to apply both GUITAR and Jubula. For each fault described in our GUI fault model, we selected one reported failure. To reproduce each failure, we downloaded the corresponding faulty version of JabRef. We used the exact test sequence (i.e., number of actions) to reproduce a failure. In GUITAR, all test cases were generated automatically over a faulty version. In Jubula, each test case was created manually to detect one failure. Also, their test sequences are extracted by analyzing failure reports (e.g., steps to reproduce a failure) and reusing Jubula's libraries. Then, GUITAR and Jubula run all their test cases automatically for checking whether the selected failure is found.

Results and Discussion

Table 3.4 summarizes the detection of the JabRef GUI failures by GUITAR and Jubula. These failures cover 11 out of the 15 faults described in our fault model. The remaining four faults were not covered for two reasons:

1. No failure was classified for that fault; or 2. A failure was classified, but we could not reproduce it -only occurred in a specific environment (e.g., Operating System) or given a certain input (e.g., a particular database in JabRef).

The reported failures in JabRef are mostly related to WIMP widgets, so we would expect GUITAR and Jubula to detect them, but it was not the case. For instance, failure #1 reports an incorrect display of buttons' label; its root cause is the incorrect size of a widget positioned to the left of them. Thus, this failure does not affect the values of internal properties (e.g., text, event handlers) of those buttons. In GUITAR, checking the properties of that widget did not reveal this failure since the expected and actual values of its size property (e.g., width) remained the same. In Jubula, the concerned widget cannot be mapped to test cases execution and thus cannot be tested. Failures #2 and #3 refer to an incorrect menu path and a misspelling, respectively. Both failures were detected by Jubula. However, these failures were not found by GUITAR. Indeed, GUITAR does reverse engineering of an existing GUI to produce tests. If this GUI is faulty, GUITAR will produce tests that will consider these failures as the correct behavior.

Failures #8 and #13 that lead to a crash of the GUI were found by both GUITAR and Jubula. However, failures #4, #6, #10, and #11 that affect the data model were not detected by GUITAR for two reasons. First, GUITAR does not test the table entries in JabRef since they represent the data model. To do this, we need to extend GUITAR to interact with them. Second, the test cases successfully passed, but a failure has been revealed. That means, the events are fired properly (e.g., no exception) and GUI properties are the "expected" ones. For example, a text property of a status bar contains the value: "Redo: change field", when this action was actually not redone. Similarly, failure #10 was not detected by Jubula. This failure reports an unexpected auto-completion when the action "save" is triggered by shortcuts. We reproduced this failure manually but the test case was successfully replayed by Jubula. The input text via keyboard was typed and saved automatically without any interference of the autocompletion feature.

Another point is the accuracy of test cases generated manually in Jubula. Detecting failure #6 depends on how the test case is written. For example, adding a field that contains LaTeX commands (e.g.,1 0 0 \%), and then checking its output in a preview window should not contain any command (e.g., 100%). So, we can write a test case to test the outputs in the preview window only looking for commands (e.g., SelectPattern[%, equals] in ComponentText[preview] ). Or, write a test case to check whether an entire text matches to the expected one (e.g., CheckText[100%, equals] in Component-Text [preview] ). However, the last test case will fail since a text from preview window in JabRef is shown internally as HTML and, in Jubula, the action's parameters cannot be specified in that format.

Our experiment does not aim at comparing both tools since GUITAR is a fully automated tool contrary to Jubula. However, the results of this study highlight the current limitations of GUI testing tools. GUITAR and Jubula currently mainly work for detecting failures that affect properties of standard widgets. Moreover, GUITAR does GUI regression testing: it considers a given GUI as the reference one from which tests will be produced. If this GUI is faulty, GUITAR will produce tests that will consider these failures as the correct behavior. A possible solution to overcome this issue is to base the test process on the specifications (requirements, etc.) of the GUI.

Forging faulty GUIs for benchmarking

In this section, we evaluate the usefulness of our fault model by applying it on a highly interactive open-source software system: LaTeXDraw6 . We created mutants of this system corresponding to the different faults of the model. The main goal of these mutants is to provide GUI testers with benchmark tools to evaluate the ability of GUI testing tools to detect GUI failures. As an illustration of the practical use of these mutants, we executed two GUI testing tools against the mutants of the system. Thanks to that we caught a glimpse of their ability to cover our proposed fault model. The goal of this experiment is to answer the research question: what are the benefits of this fault model for GUI testing?

Presentation of LaTeXDraw

LaTeXDraw is an open-source drawing editor for L A T E X that we selected as an illustration of interactive systems relying on more natural but complex interactions and widgets. We have selected LaTeXDraw to perform our experiments since it is a highly interactive system written in Java and Scala (dedicated to the creation of drawings for L A T E X), and its GUI mixes both standard and ad hoc widgets. Also, LaTeXDraw is released under an open-source license (GPL2) so that it can be freely used by the testing community. Figure 3.3 shows LaTeXDraw's GUI composed of both standard widgets grouped in two toolbars, and an ad hoc widget corresponding to the drawing area of the editor. This drawing area is special compared to standard widgets and is representative of other ad hoc widgets because of the three following points:

1. Data are dynamically presented in the widget in an ad hoc way. In our case, data is graphically represented in 2D.

2. Data presentations can be supplemented with widgets to interact directly with the underlying data. For example with Figure 3.3, the shape "Circle" is surrounded by eight scaling handlers and one rotation handler.

3. Ad hoc interactions are provided to interact with the data representations and their associated widgets. These interactions are usually more complex than standard widget's interactions. For instance, the scaling and rotation handlers in LaTeXDraw can be used with a drag-and-drop (DnD) interaction. With a multitouch screen, one can zoom on shapes using two fingers (a bi-manual interaction) as it is typically more and more the case with mobile phones and tablets.

Failures to find in LaTeXDraw

LaTeXDraw's GUI is composed of several standard widgets that can be tested with current GUI testing frameworks to find crashes. However, one may want to detect that executing one interaction on a GUI has the expected results. For instance, if a user performs a bi-manual interaction on the drawing area, the expected results are either a zoom action if no shape are targeted by the interaction; or a scale action applied on the targeted shape. The zoom and the scale levels are both computed from information provided by the interaction. One may want to validate that the correct action has been performed and that the execution of the action had the expected results (e.g.,n o crash or the zoom level is correct). This kind of faults consists in validating that the specifications have been implemented correctly.

Mutants Generation

As highlighted by Zhu et al., "software testing is often aimed at detecting faults in software. A way to measure how well this objective has been achieved is to plant some artificial faults into the program and check if they are detected by the test. A program with a planted fault is called a mutant of the original program" [START_REF] Zhu | Software unit test coverage and adequacy[END_REF]. Following this principle, we planted 65 faults in LaTeXDraw, a highly interactive open-source software system.

We created 65 mutants corresponding to the different faults of our proposed fault model. All these mutants and the original version are freely available7 .E a c hm u t a n ti s documented to detail its planted fault and the oracle permitting to find it 7 .M u l t i p l e mutants have been created from each fault by: using WIMP (22 mutants) or post-WIMP (43 mutants) widgets to kill the mutants; varying the test case length (i.e.,t h e number of actions required to provoke the failure). Each action (e.g., select a shape) requires a minimal number of events (e.g., in LaTeXDraw a DnD requires at least three events: press/move/release) to be executed. Table 3.5 illustrates the attributes and their values for a GUI mutant8 planted in LaTeXDraw concerning the Action category.

Mutated files

The mutated file is package net.sf.latexdraw.ui.UIBuilder The mutated code is the setEventableToInstruments()

Steps to produce the failure 1. Select any shape style in the tool bar; 2. Drag and drop to draw a shape on canvas. ORACLE -> The shape is not drawn.

Tables 3.6 and 3.7 summarize the number of forged mutants and the minimal and maximal test case length for user interface and user interaction faults, respectively. For example, a length 0..2 means there exists at least one mutant requiring a minimum of 0 action or a maximum of 2 actions. However, the fault RVSB3 is currently not covered by the LaTeXDraw mutants. Similarly, some planted mutants only rely on post-WIMP interactions or widgets (e.g., IB1, DT1).

Forging faulty

How GUI testing tools kill our GUI mutants: a first experiment

We applied the GUI testing tools GUITAR and Jubula on the mutants to evaluate their ability to kill them. Our goal is not to provide benchmarks against these tools but rather highlight the current challenges in testing interactive systems not considered yet (e.g., post-WIMP interactions). GUITAR test cases have been generated automatically while Jubula ones have been written manually.

Considering the mutants planted at the user interface level, Jubula and GUITAR tests killed the mutants that involve checking standard widget properties, such as layout (e.g., width, height) and state (e.g., enable, focusable). Also, it is possible to test simple data (e.g., string values on text fields) on those widgets. However, most of the mutants that concern the ad hoc widgets were alive. Notably, when test cases involve testing complex data from the data model. For example, it is not possible to compare the results of the actual shape on canvas against the expected one. Even if some shape properties (e.g., rotation angle) are presented on standard widgets (e.g., spinner), GUITAR and Jubula cannot state whether the current values in these widgets match the expected shape rotation on the canvas.

Likewise, our GUITAR and Jubula tests cannot kill most of the user interaction mutants that result on a wrong presentation of shapes. In particular, when we tested mutants planted into the Reversibility or Feedback categories. For example, testing undo/redo operations in LaTeXDraw should compare all states to manipulate a shape on canvas. Moreover, the tests verdict on Jubula passed even though interactions are defined incorrectly (e.g., mouse cursor does not follow a DnD) or actions cannot be executed (e.g., a button is disabled). In GUITAR, the generated test cases do not cover properly actions having dependencies. For example, the action "Delete" in LaTeXDraw requires first selecting a shape on canvas. However, no test sequence that contains "Select Shape" before "Delete Shape" was generated. Thus, some mutants could not be killed.

Table 3.8 gives an overview of the number of mutants killed by GUITAR and Jubula. The results show that both tools are not able to kill all mutants because of the four following reasons:

1. Testing LaTeXDraw with GUITAR and Jubula is limited to the test of the standard Swing widgets. In Jubula, the test cases are only written according to libraries available in the Swing toolkit. In GUITAR, the basic package for Java Swing GUIs only covers standard widgets and mono-events (e.g., a click on a button).

2. Configure or customize a GUI testing tool to test post-WIMP widgets is not a trivial task. For example, each sequence of a test case in Jubula needs to be mapped for the corresponding GUI widget manually. Also, GUITAR needs to be extended to generate test cases for ad hoc widgets (e.g., canvas) as well their interactions (e.g., multi-modal interactions).

3. Testing post-WIMP widgets requires a long test case sequence. In LaTeXDraw, a sequence to test interactions over these widgets is composed of at least two actions. That sequence is longer when we have to detect failures into undo/redo operations.

4.

It is not possible to give a test verdict for complex data. The oracle provided by the 2 GUI testing tools do not know the internal behavior of ad hoc widgets, their interaction features and data presentation.

These results answer the research question by highlighting the benefits of our fault model for measuring the ability of GUI testing tools in finding GUI failures.

Table 3.8: Mutants killed by GUITAR and Jubula

GUITAR JUBULA ID WIMP post-WIMP WIMP post-WIMP GSA1 2 0 2 0 GSA2 5 0 6 1 GSA3 3 0 3 0 DT1 - 0 - 0 DT2 - 0 - 0 DT3 - 0 - 1 IB1 - 0 - 0 ACT1 0 0 0 1 ACT2 3 0 3 0 ACT3 2 0 2 0 RV S B 1 2 0 2 0 RV S B 2 - 0 - 0 RV S B 3 - - - - FDBK1 1 0 1 0 FDBK2 - 0 - 0

Threats to Validity

Regarding the conducted empirical studies, we identified the two following threats to validity. The first one concerns the scope of the proposed fault model since we evaluated it empirically on a small number (5) of interactive systems. To limit this threat, we selected interactive systems that cover different aspects of the HCI concepts we detailed in Chapter 2. The second threat we identified concerns the subjectivity observed in bug reports to describe failures. To deal with this, we based the classification on the bug report artifacts (patches, logs, etc.) to identify the root cause of the reported failures.

Current limitations in testing advanced GUIs

Using LaTeXDraw as an illustrative example, we explain in this section the limitations of the current approaches for testing advanced GUIs (i.e., post-WIMP GUIs) and thus for detecting failures such like those detailed in Section 3.4.1.

Studying failures found by current GUI testing frameworks

GUITAR has demonstrated its ability to find failures in standard GUIs [START_REF] Nguyen | GUI-TAR: an innovative tool for automated testing of gui-driven software[END_REF] (i.e., WIMP GUIs). It follows the standard GUI testing process depicted by Figure 2.6 in Chapter 2 and can be thus studied to highlight and explain the limitations of the current GUI testing approaches for testing advanced GUIs. GUITAR developers provide information on 95 major failures detected by this tool during the last years in open-source interactive systems9 . An analysis of these failures shows that:

1. All of them have been provoked by the use of standard widgets with mono-event interactions, mainly buttons and text fields;

2. All of them are crashes.

While several of the tested interactive systems provide advanced interactive features, all the reported failures are related to standard widgets. For instance, ArgoUML10 is a modeling tool having a drawing area for sketching diagrams similarly to LaTeX-Draw. None of the nine failures found by GUITAR on ArgoUML has been detected by interacting with this drawing area.

We applied GUITAR on LaTeXDraw to evaluate how it manages the mix of both standard widgets and ad hoc ones, i.e., the drawing area and its content. If standard widgets were successfully tested, no test script interacted with the drawing area. In the next section, we identify the reasons of this limit and explain what is mandatory for resolving it.

Limits of the current GUI testing frameworks

The main differences between standard widgets and ad hoc ones are: one can interact with standard widgets using a single mono-event interaction while ad hoc ones provide multiple and multi-event interactions; ad hoc widgets can contain other widgets and data representations (e.g., shapes or the handlers to scale shapes in the drawing area). As previously explained, four elements are involved in the typical GUI testing process: the GUI oracle; the test model; the language used to build GUI models; the model 82 GUI fault model creation process. In this subsection we explain how current GUI and test models hinder the ability to test advanced GUIs.

Current GUI models are not expressive enough. Languages used to build GUI models, called UIDLs, are a corner-stone in the testing process. Their expressiveness has a direct impact on the concepts that can compose a GUI test model (e.g., an EFG). That has, therefore, an impact on the ability of generated GUI test cases to detect various GUI failures. For instance, GUITAR uses its own UIDL that captures GUI structures (the widgets that compose a GUI and their layout). However, in the current trend of developing highly interactive GUIs that use ad hoc widgets, current UIDLs used to test GUIs are no longer expressive enough as pointed out below.

1. UIDLs currently used for GUIs testing describe the widgets but not how to interact with them. The reason behind this choice is that current GUI testing frameworks test standard widgets, which behavior is the same in many GUI platforms. For instance, buttons work by pressing on it using a pointing device on all GUI platforms. This choice is no more adapted for advanced GUIs that rely more and more on ad hoc widgets and interactions. Indeed, the behavior of these tests has been developed specially for a GUI and is thus not standard. As depicted in Figure 3.4, GUITAR embedds the definition of how to interact with widgets directly in the Java code of the framework. Test scripts notify the framework of the widgets to use on the SUT. The framework uses its widgets definitions to interact with them. So, supporting a new widget implies extending the framework. Even in this case, if users can interact with a widget using different interactions the framework randomly selects one of the possible interactions. Thus, the choice of the interaction to use must be clearly specified in GUI models. That will permit to generate a test model (e.g., an EFG) that can explore all the possible interactions instead of a single one. UIDLs must be expressive enough for expressing such interactions in GUI models. 2. Current UIDLs do not support multi-event interactions. The current trend in GUI design is to rely more on natural but complex interactions (i.e., multi-event interactions such as the DnD and the bi-manual interactions) rather than on mono-event ones (e.g., button pressure). Moreover, such interactions can be ad hoc. Testing such interactions implies that UIDLs must be able to specify them. Following the previous point on describing interactions in GUI models, the main benefit here would be the ability to generate from GUI models test models leveraging the definition of these interactions.

3. Current UIDLs do not describe the result of the use of one widget on the system. Users interact with a GUI in a given purpose. The action resulting from the interaction of a user with a GUI should be described in GUI models. Similarly, the dependencies between actions and the fact that some actions can be undone and redone should be specified as well. For instance, an action paste can be performed only if an action copy or cut has been already performed. That would help the creation of GUI oracles able to state whether the result of one interaction had the expected results. For instance with LaTeXDraw, a GUI model could specify that executing a DnD on the drawing area can move a shape at a specific position if a shape is targeted by the DnD. From this definition, a GUI oracle could check that on a DnD the shape has been moved at the expected position. Another benefit would be the ability to reduce the number of the generated test cases by leveraging the dependencies between actions. Such work has been already proposed by Cohen et al. [START_REF] Cohen | AutoInSpec: Using missing test coverage to improve specifications in GUIs[END_REF] and must be capitalized in GUI models.

Current EFGs mix both interaction, widget, and action under the term event. Test models, i.e., EFGs in our case, are graphs of all the possible events that can be produced by interacting with a GUI. An event is both the widget used and its underlying interaction. The name of the event usually gives an indication regarding the action produced when interacting with the widget. For instance, Cohen et al. describe a test model example is composed of the events Draw, Paste, Copy, Cut, etc. corresponding to both the menu items that produce these events and their interaction, here Menu Pressed [START_REF] Cohen | AutoInSpec: Using missing test coverage to improve specifications in GUIs[END_REF]. The name of each event describes the action resulting from the use of the widget. However, this mix of concepts may hamper the testing process of advanced GUIs as explained as follows.

1. Actions must be reified in EFGs. Currently, GUI oracles detect crashes or regressions and are not supplemented with information coming from EFGs. However, testing advanced GUIs requires the detection of other kinds of failures as explained in Section 3.4.1. In this chapter, we empirically identified and classified various kinds of GUI failures that can affect both WIMP and post-WIMP GUIs (see Section 3.1). For instance with LaTeXDraw, a GUI oracle must be able to state whether a shape has been correctly moved. EFGs should contain information about the actions defined in GUI models in order to provide GUI oracles with information mandatory for stating on test verdicts.

2.

Interactions and widgets must be clearly separated in EFGs. As depicted by the left part of Figure 3.5, mixing interaction and widget works for standard widgets that use a mono-event interaction. For testing ad hoc widgets using several multi-event GUI fault model interactions, EFGs should explicitly describe how user interactions work. For instance, the right part of Figure 3.5 precisely specifies the events that compose the interaction performed by a user (here a multi-touch interaction) to rotate shapes or to cancel the interaction: two touch pressures followed by a move and a touch release to rotate shapes; canceling the interaction in progress consists of pronouncing the word "cancel". In this case, EFGs would be able to support ad hoc interactions. We explained in this section the precise limits of the current GUI model-based testing approaches for testing advanced GUIs. We claim that these limitations stem from two facts: first, there is a lack of proper abstractions to build test model for testing advanced GUIs; second, only few GUI oracles are currently considered while we demonstrated in Section 3.1 the diversity of faults that can affect GUIs.

GUI testing with richer UIDLs

This section details how we leveraged a rich User Interface Description Language (UIDL), called Malai [Blo09, BB10, BMN + 11], to test advanced GUIs. Our goal is to propose the concept of interaction-action-flow graph (IFG) for going beyond the current limits of EFGs (Section 3.6). First, we introduce the Malai UIDL. Then, the concept of the IFG is explained. Finally, we present the initial feedback from the use of the proposed IFG in two use cases.

Modeling GUIs with Malai UIDL

This section illustrates the expressiveness required to build test models of advanced GUIs using Malai. We notably show how to model both standard and advanced interactions, and how to differentiate an interaction from the resulting action of its execution. Malai is an architectural design pattern that extends MVC/MVP by refining the controller to consider the notion of interactions, actions, and instruments as first-class objects [START_REF] Blouin | Un modèle pour l'ingénierie des systèmes interactifs dédiés à la manipulation de données[END_REF][START_REF] Blouin | Improving modularity and usability of interactive systems with Malai[END_REF]. Malai gathers principles of several major interaction models and design patterns, notably the instrumental interaction [BL00], the direct manipulation [START_REF] Shneiderman | Direct manipulation: a step beyond programming languages[END_REF], and the Command and Memento design patterns [START_REF] Gamma | Design patterns: elements of reusable object-oriented software[END_REF]. The Malai implementation11 provides a model-based UIDL.

Malai decomposes an interactive system as a set of presentations and instruments (see Figure 3.6). A presentation is composed of an abstract presentation and a concrete presentation. An abstract presentation is the data model of the system (the model in MVC). A concrete presentation is a graphical representation of an abstract presentation (the view in MVC). An action encapsulates what users can modify in the system. For instance, LaTeX-Draw (recall Section 3.4.1), has numerous actions such as rotating shapes. An action does not specify how users have to interact with the system to perform it. An action just specifies the results of a user interaction on the system. An action can also depend on other actions for being executed. For example, the action paste can be executed only if an action copy or cut has been executed before. An action is executed on a presentation (link AE).

An interaction is represented by a finite-state machine where each transition corresponds to an event produced by an input device (Figure 3.6, link ¨). Using FSMs for defining interactions permits the conception of structured multi-event interactions, such as DnD, multi-touch, or multi-modal interactions. An interaction is independent of any interactive system that may use it. For instance, a bi-manual interaction, as depicted by Figure 3.7, is defined as an FSM using events produced by pointing devices or speech recognizers (e.g., pressure, voice). This interaction does not specify the actions to perform on a system when executed (e.g., rotate shapes). The interaction depicted by Figure 3.7 starts at the initial state (black circle) and ends when entering a terminal (double-lined circle) or an aborting (crossed out circle) state. Aborting states permit users to abort the interaction they are performing. Transitions (e.g., press and move) can be supplemented with a condition constraining the trigger of the transition. For instance, the interaction goes into the aborting state thanks to the transition voice only if the pronounced word is "abort". Because actions and interactions are independently defined, the role of instruments is to transform input interactions into output actions (link ≠). Instruments reify the concept of tool one uses in her every day life to manipulate objects [START_REF] Beaudouin-Lafon | Instrumental interaction: An interaction model for designing post-wimp user interfaces[END_REF]. For instance, Figure 3.8 describes the instrument Hand as it could have been defined in Latexdraw. The goal of this instrument is to move and rotate shapes. Performing these actions requires different interactions: rotating shapes can be done using the bimanual interaction previously depicted; moving shapes can be done using a DnD interaction. In Malai such tuples interaction-action are called interactors and one instrument can have several interactors, i.e., one can handle an instrument with different interactions to execute different actions. In an interactor, the execution of the action is constrained by a condition. For example, the interactor Bimanual2Rotate (Figure 3.8) permits the execution of the action RotateShapes only if the source and target objects of the bimanual interaction are the same shape: src == tgt ∧ src is Shape (using a bi-manual interaction to rotate a shape may imply that the two pressures are done on the targeted shape).

In Malai, the GUIs of a system are composed of the widgets provided by all the instruments: an interaction can be based on a widget (e.g., a click on a button) and in this case, instruments using such interactions create and provide these widgets.

Malai supports mono-event as well as multi-event interactions; interactions work as FSM that may help the test model generation process; actions can be defined and dependencies between them can be specified; instruments and their interactors can be viewed as FSMs as well. Because in Malai interactions, interactors, and instruments are FSMs, the creation of test models is eased as detailed in the next subsection. Such FSM models capture all the possible scenarios that users can do while interacting with the system. A path in such FSMs corresponds to one scenario.

Interaction-action-flow graph

This section introduces the concept of interaction-action-flow graph (IFG) that can be automatically inferred from Malai models. As depicted in Figure 3.9, an IFG follows the same idea than an EFG by sequencing all the possible user interactions. The difference is that the concepts of interaction, action, and widget are clearly separated, and interactions and actions are included in IFGs. The goal of such separation is to be able to test a widget using its different interaction, and to test that the effective result of one execution of an interaction is the result expected ass defined in the action. So, an IFG is a sequence of interaction-to-action tuples. Each tuple is in fact an FSM composed of two states (the interaction and the action) and one transition (the condition that permit to execute the action). For instance, Figure 3.9 describes an IFG composed of the three instruments: the Pencil (¨) that permits to draw shapes; the EditingSelector (≠) that permits to select the kind of shapes to draw; the Hand (AE) that permits to move or scale shapes. At start-up, only the instruments Pencil and EditingSelector are activated and can be used. So, the interaction-action tuples ¨and ≠ are available. The instrument EditingSelector permits to use either the Pencil or the Hand instrument. So, using this instrument can lead to all the tuples ¨, ≠,a n dAE. Figure 3.9 does not represent the widgets associated to each tuple but the tuples ¨and AE deal with the drawing area while the tuple ≠ deals with a set of buttons.

To create such sequences from Malai models, we need to define which instruments can be used at a given instant. Malai models do not explicitly specify the relations between instruments, i.e., they do not specify which instruments can be handled after having used an instrument. Such relations are mandatory to obtain from Malai models a graph of instruments from which test scripts can be produced.

Inferring these relations is automatically performed by analyzing the Malai actions: there exists actions that activate or inactivate instruments. For instance with Figure 3.9, the instrument EditingSelector is dedicated to select (i.e., to activate/inactivate) between the instruments Hand or Pencil. Thus, after having used the EditingSelector instrument, either the instruments Hand or Pencil can be used (transitions ¨). Similarly, Based on the IFG, the test cases can be generated to test both standard and advanced GUIs. For instance, we were able to test multiple ad hoc interactions used on advanced widgets. Also, actions permitted to compare the effective result of interacting with SUTs and the expected one. We do not provide, however, a fully automated framework as the case of GUITAR. Instead, we manually built Malai models and manually executed the test scripts.

In the next subsection, we present the benefits of this approach through two different use cases and describe research challenges to overcome.

Case studies

To illustrate the expected benefits of the use of Malai and the concept of IFG, we applied our method on two different use cases:

1. LaTeXDraw (3.0-alpha1): introduced in Section 3.4.1; 2. the CONNEXION project: an industrial project that aims at improving model-based GUI testing techniques.

LaTeXDraw

Table 3.9 gives an overview of the defects found during our experiment on LaTeX-Draw. The manual execution of the tests led to the detection of four defects. All of them were not reported in the official bug trackers of LaTeXDraw. These defects concern different parts of the system. Defects #1 and #2 have detected that several user interactions did not work as expected. These user interactions are a multi-click and a DnD interactions. Both of them are ad hoc interactions developed specifically for LaTeXDraw. With a multi-click interaction, users can click is several locations in the drawing area to create a shape composed of several points. In our case, executing the interaction did not perform the excepted action, i.e., the creation of the shape. The DnD interaction can be aborted. It means that while executing the DnD, the user can press the key "escape"t os t o p the interaction and to not execute the associated action. These two defects cannot be find by GUITAR since: they have been provoked by non-standard interactions; the two interactions can be executed on the drawing area and we explained that GUITAR cannot support multiple interactions for a same widget.

Defect #3 was an issue in the data model where changes in the Latexdraw's preferences were not considered.

Defect #4 was not a LaTeXDraw issue but a Java Swing one: clicking on the zoom buttons had not effect if performed too quickly. Still, this defect has been detected thanks to the action that zooms on and out the drawing area.

Industry: feedback from the CONNEXION project

The CONNEXION 12 project is a national industry-driven work program to prepare the design and implementation of the next generation of instrumentation and control (I&C) systems for nuclear power plants. One goal of this project is the development of model-based techniques for testing GUIs of such I&C systems, more precisely for:

• automating as far as possible the current error-prone, expensive, and manual GUI testing process;

• finding GUI errors as early as possible in the development phases to reduce the development cost;

• finding various kinds of GUI errors (not only crashes) on various kinds of ad hoc widgets.

The main constraint, imposed by norms [START_REF] Iec | Nuclear power plants -main control-room -verification and validation of design[END_REF][START_REF]Nuclear power plants -control rooms -design[END_REF], is that the testing process of I&C systems must be driven from their specifications. So, producing entire GUI models using reverse engineering techniques from the SUT is not possible (some specific information, however, can be extracted from GUIs to be used in GUI models as discussed below).

Similarly to the previous case study (i.e., LaTeXDraw), we manually design GUI models from the provided specifications using Malai. We then automatically generate abstract GUI tests. These last are then concretized to produce executable GUI tests that run on top of the SCADE LifeCycle Generic Qualified Testing Environment (SCADE QTE), a tool for testing GUIs developed with the SCADE Display technologies 13 . The concretization phase includes two steps:

• Mapping abstract test cases to the targeted testing framework and SUT. This step requires manual operations to map GUI model elements to their correspond elements in the GUI under test. For instance, the name of the widgets of the GUI under test have to be mapped to the widgets defined in the GUI models. To avoid this step, the specifications have to precisely specify the names to use, as discussed later in this section.

• Generating GUI oracles. We currently generate basic oracles that checks the correct GUI workflow when interacting with widgets.

These preliminary results highlighted the capability of the IFG, based on Malai UIDL, produces test cases capable of detecting some defects in advanced GUIs. However, if the Malai expressiveness permits to test advanced GUIs, we face two UI testing challenges relative to the concretization phase of MBT process (see Figure 2.6 in Chapter 2): GUI oracles generation. GUI oracles have to be produced as far as possible from GUI models. Our proposed fault model describes several faults that imply different ways to detect them. GUI faults imply the development of multiple GUI oracles based on techniques diametrically different. For instance, the graphical nature of GUIs requires their graphical rendering to be checked. To do so, a possible oracle consists of comparing screenshots of GUIs to detect differences. This oracle thus uses image processing techniques. However, checking that a widget is correctly activated can be done using classical code unit testing techniques. These differences between GUI oracles complexifies the GUI model-based testing process that has to generate such oracles. One challenge to tackle is how to write and generate GUI oracles to detect such failures? New GUI testing techniques have thus to be developed to automate the generation of GUI oracles being able to detect those failures other than standard GUI failures or crashes.

Incomplete, ambiguous GUI specifications. The specifications we use to build GUI models do not formally specify in detail the GUI to test. As a result, the GUIs and the GUI models, produced independently each other from the specifications, may differ. For instance, the position of widgets are not explicitly precised. Testers and developers have to determine these positions from GUI mockups. To limit this problem in the CONNEXION project, some information are extracted from the developed GUIs to be reused in the GUI testing models. These extracted information are notably the position of the widgets. It means that the position of the widgets is not tested but is used to detect other GUI errors (e.g., widget responsiveness). This problem of incomplete, ambiguous GUI specifications has been already reported in previous work on modelbased testing. Dalal et al., for instance, reported that "some of the constraints were not covered in the requirements and we had to run the application to see exactly how it had been implemented "[ D J K + 99].

Conclusion

This chapter proposes a GUI fault model for providing GUI testers with benchmark tools to evaluate the ability of GUI testing tools to detect GUI failures. This fault model has been empirically assessed by analyzing and classifying into it 279 GUI bug reports of different open-source GUIs. We have used our fault model to evaluate the limits of GUI testing frameworks. The experiments have shown that if current GUI testing tools have demonstrated their ability for finding several kinds of GUI failures, they also fail at detecting several GUI faults we identified. The underlying reasons are twofold. First, GUI failures may be related to the graphical rendering of GUIs. Testing a GUI rendering is a complex task since current testing techniques mainly rely on code analysis that can hardly capture graphical properties. Second, the current trend in GUI design is the shift from designing GUIs composed of standard widgets to designing GUIs relying on more complex interactions and ad hoc widgets. Instead, current GUI testing frameworks rely on the concepts of standard widgets and their simple interactions to provide an automated GUI testing.

New GUI testing techniques have thus to be proposed for fully GUI testing, as automated as possible, GUI rendering and complex interactions using ad hoc widgets. For this purpose, our fault model can assist GUI testing techniques to cover more GUI faults. We have provided 65 GUI mutants planted into standard and ad hoc widgets of a highly interactive GUI system to forge several GUI faults. These mutants are freely available and thus can be used by testing community to achieve that purpose. For example, the third experiment, we run on GUITAR and Jubula, has shown that 43 out of 65 GUI mutants remained alive. Most of them concern the graphical data rendering of ad hoc widgets and their complex interactions. These results help their developers to understand which kinds of GUI faults were not detected by their GUI testing tools.

Chapter 4

GUI Design Smells: The Case of Blob listener

In Chapter 3, we presented a new GUI fault model that describes faults specific for GUIs. Numerous GUI testing techniques have been proposed to detect errors that affect GUI systems. Besides, GUI errors may be accentuated by the low quality of GUI code. For example, the presence of design smells has been correlated to the introduction of faults [START_REF] Li | An empirical study of the bad smells and class error probability in the post-release object-oriented system evolution[END_REF][START_REF] Hall | Some code smells have a significant but small effect on faults[END_REF] or other aspects of code quality such as maintainability [SYA + 13]. Static analyses are developed to find defects in code or to measure the code quality. To contribute to the code assurance quality of GUIs we focus on studying GUI design smells.

This chapter presents a novel static analysis technique to automatically detect a new type of GUI design smell, the Blob listener . In particular, we have designed new heuristics that enable to search and locate Blob listeners in the source code. The main challenge of this analysis is to infer the code regions related to GUI and GUI controllers and to automatically locate the GUI commands handled by these controllers. The most critical step is to design and implement a heuristic that accurately detects GUI commands in GUI listeners. The reasons are twofold. First, GUI listeners may have conditional blocks that do not handle events produced by widgets, i.e., non-GUI commands. Also, we have identified three variants of Blob listeners that are different ways to identify the widget that produced the event: 1. comparing a property of the widget; 2. checking the type of the widget; and 3. comparing widget references. Second, GUI commands can be nested within other commands. To overcome this step, we have implemented an algorithm that infers recursively all references in conditional statements and determines whether they refer to a GUI object. To manage the case of the nested commands, our algorithm removes the irrelevant ones based on that variants.

We implement our static analysis in a tool called InspectorGuidget. This tool is an Eclipse plug-in publicly available 1 dedicated to Java software systems based on the Swing toolkit. The ability of our tool to detect Blob listeners is evaluated on six representative highly interactive software systems. These systems cover several user However, the use of Blob listeners in real-word GUI implementations complexifies the GUI code for the following reasons.

1. Use of multiple conditional statements. Blob listeners handle multiple GUI commands. Commands use conditional statements (e.g., if-then-else) to identify the widget that produced an event. Also, the conditional statements may be used or added to check a particular class type of a widget (e.g., JButton or JCheckbox). So, if listeners are implemented as Blob listeners, this implementation also collaborates to increase the cyclomatic complexity of a GUI code. A code with high CC is more error-prone [START_REF] Maji | Characterizing failures in mobile oses: A case study with android and symbian[END_REF] and harder to maintain [START_REF] Black | Guide to the ISTQB Advanced Certification As an Advanced Technical Test Analyst[END_REF][START_REF] Anna | Automated refactoring to the null object design pattern[END_REF]. An example of a GUI listener code excerpt from the Github repository is shown in Listing 5.4 (see Appendix). This listener has a high cyclomatic complexity (CC value is 174) and manages several widgets. We have identified 39 GUI commands in this listener, which characterizes a Blob listener .O n em a yn o t et h a tah i g h cyclomatic complexity of a listener indicates that it is a candidate to be a Blob listener . Another point is that if developers use a single listener to manage several widgets (which is the case of Listing 5.4), this listener may grow significantly and thus more difficult to be read (e.g.,m u l t i p l eif-then-else statements that can be very large) and maintained (e.g., time-consuming changes if the GUI evolves often).

2. Similar code within a GUI listener. Blob listeners may contain the same or similar code structure in more than one GUI command. We have observed this practice in GUI listeners that implement commands concerning opposite actions such as undo/redo or zoom in/out actions. Listing 4.2 illustrates this case. The two if blocks contain a set of statements to be executed in reaction of "zoom in" (Lines 4-10) and "zoom out" (Lines 12-18) actions. These blocks represent two commands (Command #1 and #2), which share five out of six statements. Methods with duplicated code have been associated with maintainability problems for instance leading to more faults or more change effort [SYA + 13]. The listener method "actionPerformed " (Lines 10-22) handles two commands: Command #1 (Lines 12-18) and Command #2 (Lines 19-21). Command #1 and Command #2 have a set of statements to be executed when the widgets labeled "Clear "a n d" Leave " are pressed, respectively. However, GUI failures will occur when users interact with such widgets. The two GUI faults are located in the conditional expressions of that commands (Lines 12 and 19) used to check which widgets produced the event. The strings associated to identify each widget are incorrect. The correct strings are "Clean"a n d" Exit" (Lines 4 and 6) instead of "Clear "a n d" Leave ", respectively. Both GUI faults are related to the category Action of our fault model (recall Table 3.2 in Chapter 3).

The above scenarios highlight our findings in the implementations of GUI controllers. These findings provide a strong motivation for characterizing Blob listeners as a new kind of GUI design smells, and for the development of tools that detect them. Indeed, a Blob listener is a GUI specific instance of a more general bad smell: God method [START_REF] Brown | AntiPatterns: Refactoring Software, Architectures, and Projects in Crisis[END_REF], that characterizes methods that "know too much or do too much".

In the next sections, we present the systematic approach to identify and to detect automatically Blob listeners in GUI controllers.

What Compose GUI listeners? An Empirical Study

In this section, we present the empirical study to identify current coding practices in Java implementations of GUI controllers. We also present how this study led us to identify and characterize a Blob listener as a new GUI design smell.

As any other code artifact, the code of GUI controllers may be affected by good and bad coding practices. In most widespread GUI toolkits (e.g., in Java Swing, JavaFX4 , GWT 5 ,a n dS W T6 ) controllers rely on GUI listeners for treating events triggered by widgets. In this section, we provide empirical observations about how such GUI listeners are coded in legacy Java Swing code7 . In particular, we focus on the following research question:

RQ0 Is there any difference in term of code metrics between GUI listener methods and methods that are not listeners?

This preliminary analysis focuses on the Java Swing toolkit because of its popularity and the large quantity of Java Swing legacy code stored on various Web code hosting services (e.g., github.com or sourceforge.net). In this study, we collected 511 code repositories from Github that contain references to Java Swing in their description8 .

Blob listener

The previous analysis shows that some GUI listener methods make an intensive use of conditional statements. We pored over these listeners and identified one recurrent bad practice that developers use while coding GUI listeners using Java Swing. We call this bad practice the Blob listener , as defined as follows:

Definition 4.1 (GUI Command) AG U Ic o m m a n d[ G H J V 9 5 ,B L 0 0 ] ,a k a . ac- tion [BB10]
, is a set of statements executed in reaction to a user interaction, captured by an input event, performed on a GUI. GUI commands may be supplemented with: a pre-condition checking whether the command fulfils the prerequisites to be executed; undo and redo functions for, respectively, canceling and re-executing the command.

Definition 4.2 (Blob listener ) A Blob listener is a GUI listener that can produce several GUI commands. Blob listeners can produce several commands because of the multiple widgets they have to manage. In such a case, Blob listeners' methods (such as actionPerformed) may be composed of a succession of conditional statements that:

1. Check whether the widget that produced the event to treat is the good one, i.e., the widget that responds a user interaction; and 2. Execute the command when the widget is identified.

We identified three variants of the Blob listener that are detailed in the next subsection.

Variants of Blob listener

The variations of a Blob listener reside in the way of identifying the widget that produced the event. These three variants are described and illustrated as follows.

Detecting Conditional GUI Listeners

We define a conditional GUI listener as follows: Definition 4.3 (Conditional GUI listener) Ac onditionalGUIlistenerisalistener composed of conditional blocks used to identify the widget that produced an event to process. Such conditional blocks may encapsulate a command to execute in reaction to the event.

For example, five nested conditional blocks (Lines 8, 10, 11, 13, and 15) compose the listener method actionPerformed in Listing 4.4 (Section 4.3). The first conditional block checks the type of the widget that produced the event (Line 8). This block contains three other conditional blocks that identify the widget using its action command (Lines 10, 13, and 15). Each of these three blocks encapsulates one command to execute in reaction of the event.

Algorithm 1 details the detection of conditional GUI listeners. The inputs are all the classes of an application and the list of classes of a GUI toolkit. First, the source code classes are processed to identify the GUI controllers. When a class implements a GUI listener (Line 5), all the implemented listener methods are retrieved (Line 6). For example, a class that implements the MouseMotionListener interface must implement the listener methods mouseDragged and mouseMoved. Next, each GUI listener is analyzed to identify those having at least one conditional statement (Lines 8 and 9). All listeners with those statements are considered as conditional GUI listeners (Line 10).

Algorithm 1 Conditional GUI Listeners Detection

Input: classes,t h es o u r c ec l a s s e so ft h es o f t w a r es y s t e m Input: tkClasses,t h ec l a s s e so ft h eG where e refers to a GUI event, Component to a Swing class, and copy to a Swing widget. The algorithm recursively analyzes the variables and class attributes used in the conditional statements until a reference to a GUI object is found in the controller class. For instance, the variable actionCmd in the following code excerpt is also considered by the algorithm.

String actionCmd = e.getSource().getActionCommand() if("copy".equals(actionCmd)) ... When a reference to a GUI object is found in a conditional statement, it is considered as a potential command (Line 9). These potential commands are then more precisely analyzed to remove irrelevant ones (Lines 12-22) as discussed below.

Algorithm 2 Commands Detection

Blob listener Detection

Blob listeners represent all GUI listeners that can produce more than one command. Thus, detecting commands is the crucial step to identify Blob listeners. For this reason our command detection algorithm requires to select the most representative commands per listener.

Algorithm 3 describes the Blob listeners detection. To detect Blob listeners,o u r algorithm first gathers all the detected commands per GUI listeners (Line 2). These commands are representative since Algorithm 2 removes the irrelevant commands as detailed in Section 4.4.3. Then, if a GUI listener has more than one command, it is marked as a Blob listener (Lines 4-5). blobListeners ← blobListeners ∪ {candidate}

Evaluation

To evaluate the efficiency of our approach, we address the three following research questions:

RQ1 To what extent is the detection algorithm able to detect GUI commands in GUI listeners correctly?

RQ2 To what extent is the detection algorithm able to detect Blob listeners correctly?

RQ3 Are all Blob listeners look alike?

The evaluation has been conducted using InspectorGuidget, our implementation of the Blob listener detection algorithm. InspectorGuidget is an Eclipse plug-in that can analyze Java Swing software systems. InspectorGuidget leverages the Eclipse development environment to raise warnings in the Eclipse Java editor on detected Blob listeners and their GUI commands. Initial tests have been conducted on software systems not reused in this evaluation.

InspectorGuidget and all the material of the evaluation are freely available at the following address: https://github.com/diverse-project/InspectorGuidget.

Objects

We conducted our evaluation by selecting six well-known or large open-source software systems based on the Java Swing toolkit: FastPhotoTagger, GanttProject, JAxoDraw,

Methodology

The accuracy of the static analyses that compose the detection algorithm is measured by the recal l and precision metrics [START_REF] Ocariza | Detecting inconsistencies in JavaScript MVC applications[END_REF]. We ran InspectorGuidget on each software system to detect GUI listeners, commands, and Blob listeners.W ea s s u m ea s a precondition that only GUI listeners are correctly identified by our tool. Thus, to measure the precision and recall of our automated approach, we manually analyzed all the GUI listeners detected by InspectorGuidget to:

• Check conditional GUI Listeners. For each GUI listener, we manually checked whether it contains at least one conditional GUI statement. The goal is to answer RQ1 and RQ2 more precisely, by verifying whether all the conditional GUI listeners are statically analyzed to detect commands and Blob listeners.

• Check commands. We analyzed the conditional statements of GUI listeners to check whether they encompass commands. Then, recal l measures the percentage of relevant commands that are detected (Equation ( RelevantCmds corresponds to all the commands defined in GUI listeners, i.e., the commands that should be detected by InspectorGuidget. Recal l and precision are calculated over the number of false positives (FP) and false negatives (FN). A command incorrectly detected by InspectorGuidget while it is not a command, is classified as false positive. A false negative is a command not detected by InspectorGuidget.

• Check Blob listeners. To check whether a GUI listener is a Blob listener ,w e stated whether the commands it contains concern several widgets. We use the same metrics of commands detection to measure the accuracy of Blob listeners detection:

Recall blob (%) = |{RelevantBlobs} ∩ {DetectedBlobs}| |{RelevantBlobs}| × 100 (4.3)
P recision blob (%) = |{RelevantBlobs} ∩ {DetectedBlobs}| |{DetectedBlobs}| × 100 (4.4)
Relevant Blob listeners are all the GUI listeners that handle more than one command (see Section 4.4). Detecting Blob listeners is therefore dependent on the commands detection accuracy.

Results and Analysis

In this section, we present the results concerning the evaluated Blob listeners and the ability of InspectorGuidget in detecting them accurately. The discussion of the findings follows the three research questions we previously introduced.

RQ1: Command Detection Accuracy.

Table 4.4 shows the number of commands successfully detected per software system. TripleA has presented the highest number of GUI listeners (580), conditional GUI listeners (174), and commands (152). One can notice that despite the low number of conditional GUI listeners that has TerpPaint (4), this software system has 34 detected commands. So, according to the sample we studied, the number of commands does not seem to be correlated to the number of conditional GUI listeners. 3 classifies the 76 FN commands according to the cause of their nondetection. 28 commands were not detected because of the use of widgets inside block statements rather than inside the conditional statements our approach analyzes. For example, their conditional expressions refer to boolean or integer types rather than widget or event types. 16 other commands were not detected since they rely on ad hoc widgets or GUI listeners. These widgets are developed for a specific purpose and rely on specific user interactions and complex data representation, as we explained in Chapter 3. Thus, our approach cannot identify widgets that are not developed under Java Swing toolkit. All the FN commands reported in this category concern TripleA (14) and Jmol (2) that use several ad hoc widgets. Similarly, we found eight FN commands that use classes defined outside the Swing class hierarchy. A typical example is the use of widgets' models (e.g., classes ButtonModel or TableModel ) in GUI listeners.

GUI Design Smells: The Case of Blob Listener Also, we identified 24 FN commands caused by an incorrect code analysis (either bugs in InspectorGuidget or in the Spoon library). This result was mainly affected by Jmol, that has a listener with 14 commands not detected.

To conclude on RQ1, our approach is efficient for detecting GUI commands that compose GUI listener, even if some improvements are possible.

RQ2: Blob listeners Detection Accuracy. The average recall is 98.81 %. Only the analysis of Jmol produced one FN Blob listener . In contrast to the command detection, we noticed a higher number of FPs (30). TripleA presented the highest number of FP Blob listeners (19) followed by Jmol (4). The average precision is 69.07 %. The average time spent to analyze the software systems is 10810 milliseconds. It includes the time that Spoon takes to process all classes plus the time to detect GUI commands and Blob listeners. The worst-case is measured in TripleA, i.e., the largest system, with 16732 milliseconds. Spoon takes a significant time to load the classes for large software systems (e.g., 12437 milliseconds out of 16732 milliseconds in TripleA).

Figure 4.4 depicts the FP Blob listeners distribution. We identified 14 FP Blob listeners are composed of commands based on checking the states of widgets.F o r instance, two commands can rely on the selection or the non-selection of a checkbox. 13 FP Blob listeners with several commands run over the same widget' attribute. Two FP Blob listeners concern reverse commands, e.g., undo operations. One FP Blob listener concerns the state of user interactions. Commands are in this case detected, while the GUI listener code just updates the running user interaction.

Listing 4.8 gives an example of a FP Blob listener detected in TripleA.I nt h i s example, our algorithm detects two commands (Lines 6-7 and Lines 8-9). This GUI listener is therefore classified as a Blob listener . However, these two commands are similar since: i) they are executed over the same widget attribute (i.e., m_model and m_playerNameLabel ); ii) they are reverse -enablePlayer vs disable-Player ;a n diii) the conditional statement handles the state of the widget "check box " (i.e., m_enabledCheckBox is selected or not). Thus, this GUI listener should not be detected as a Blob listener . Most of the FP Blob listeners have commands contained throughout a single if-thenelse statement (e.g., Lines 6-9). We observed that these statements are mainly used to handle the state of widgets. For example, checking whether a check box is selected (e.g., Line 6) or deselected (e.g.,L i n e8 ) . A l s o ,m o s to fF PBlob listeners identified in TripleA are found during a listener registration of a widget (e.g., Line 3). Defining listeners during a widget registration, i.e., as anonymous class, is a good practice (see Section 4.7.2) to avoid Blob listeners since we implement the corresponding listener methods for a single widget. We identified a listener in TerPaint with 17 commands10 running over a registration of an ad hoc widget (e.g., canvas).

RQ3: Do all Blob listeners look alike?

To answer RQ3 we analyze and discuss the Number of Commands per Blob listener (NCB) for each software system. This chart highlights that NCB can vary in the same software system. For instance, the NCB for JAxoDraw ranges from 2 to 23. For TerpPaint, it ranges from 2 to 17. By contrast, the NCB for GanttProject and TripleA ranges from 2 to 4 and 2 to 6, respectively.

In the case of JAxoDraw, the Blob listener detected with 23 commands handles events when widgets change their state. Listing 4.9 illustrates the code excerpt from this Blob listener . This example shows that for each widget, grouped in a "edit panel ", that changes its value, the Blob listener implements a GUI command. One may note that using a single controller for all the widgets produces a "long method " bad smell with all its consequences. Indeed, a Java method with more than a dozen lines is a strong indicator that it is a long method 11 . Besides, this Blob listener contains several duplicated code blocks. For example, the Lines 6, 9, and 12 are the same for the commands #1, #2 and #3, respectively. These code lines get the information from the model, for instance, the spinners sequence of values. Duplicated code has negative effects on the maintenance and evolution of software systems [SYA + 13]. One way to eliminate those lines is to move the duplicated code to the outside of conditional statements since they handle the same type of a widget (i.e., JSpinner). The duplicated code must be placed before the conditional statements for instance before the Line 5.

Threats to validity 113

The Blob listener with 17 commands in TerPaint has 125 LOC. The design solution for this Blob listener is quite similar to the Blob listener in JAxoDraw. However, its design solution is more difficult to understand since it has multiple and nested conditional statements. We have observed several conditional statements used to identify the widgets that produced the event (Lines 5, 8, and 11). These conditional statements can be eliminated by following the good coding practices in GUI listeners that we present in Section 4.7. The Blob listeners detected in TripleA and GanttProject seem less badly designed. The average NCB for both systems is less than or equal three commands. Indeed, TripleA implements several GUI listeners as anonymous class, which is one example of the good coding practices in GUI listeners.

We have also observed Blob listeners with few commands but several LOCs. For instance, Blob listeners detected with three commands in TripleA have LOC that range from 23 LOC to 66 LOC whereas in GanttProject one Blob listener with the same number of commands has 35 LOC. These results highlight that the LOC size of Blob listeners detected with the same NCB varies even in a same software system.

Threats to validity

The validity of the study to identify and detect automatically the Blob listeners is considered from two perspectives as follows:

External validity. This threat concerns the possibility to generalize our findings. We designed the experiments using six Java Swing open-source software systems to diversify the observations. These six unrelated software systems are developed by different persons and cover various user interactions. Several selected software systems have been used in previous research work, e.g., GanttProject [FBZ12, AZJH11], Jmol [AZJH11], and TerpPaint [CHM12] that have been extensively used against GUI testing tools.

GUI Design Smells: The Case of Blob Listener

Our implementation and the initial study (Section 4.2) focus on the Java Swing toolkit only. We focus on the Java Swing toolkit because of its popularity and the large quantity of Java Swing legacy code. We provide on the companion web page examples of Blob listeners in other Java GUI toolkits, namely GWT, SWT, and JavaFX 1 .

Construct validity. This threat relates to the perceived overall validity of the experiments. The detection of FNs and FPs have required a manual analysis of all the GUI listeners of the software systems. To limit errors during this manual analysis, we added a debugging feature in InspectorGuidget for highlighting GUI listeners in the code. We used this feature to browse all the GUI listeners and identify their commands to state whether these listeners are Blob listeners.D u r i n go u rm a n u a la n a l y s i s ,w ed i d not notice any error in the GUI listener detection. Another threat is the fact that we manually determined whether a listener is a Blob listener . To reduce this threat, we carefully inspected each GUI command highlighted in our tool.

Discussion

In the next two subsections, we discuss the scope of InspectorGuidget and good practices that should be used to limit Blob listeners.

Scope of the Approach

Our approach has the following limitations. First, InspectorGuidget currently focuses on GUIs developed using the Java Swing toolkit. This is a design decision since we leverage Spoon, i.e., a library to analyze Java source code. However, our solution is generic and can be applied to cover other GUI toolkits.

Second, our solution is limited to analyze GUI listeners and associated class attributes. We identified several GUI listeners that dispatch the event processing to methods, as illustrated in Listing 4.10. The GUI listener (Lines 1-3) was not analyzed by our algorithm since it was not identified as a conditional GUI listener. However, the method invoked in Line 2 contains a strong candidate for a Blob listener (Lines 4-16). Our implemented static analyses can be extended to traverse these methods to improve its performance. To identify such methods as listeners, our algorithm must analyze each listener statement to: 1. identify all call methods in a listener; and 2. analyse such methods to infer if they share the same parameter and return type (e.g.,v o i di nJ a v a Swing listeners) of that listener.

Last, the criteria for the Blob listeners detection should be augmented by inferring the related commands. An example of related commands are a command and its reverse one (the undo operation). For example, when a GUI listener is a Blob listener candidate, our algorithm should analyze its commands by comparing their commonalities (e.g., shared widgets and methods). The goal is to detect commands that form in fact a single command. Considering the GUI listener presented in Listing 4.8 and the proposed detection, the algorithm will not detect this GUI listener as Blob listener since the commands #1 and #2 will be marked as related commands.

the next steps towards a refactoring Blob listeners. We have started the implementation of this algorithm. The global solution consists of implementing three main steps:

1. Detecting Blob listeners;

2. Locating where the GUI commands included in Blob listeners are registered; and 3. Extracting GUI commands by producing one command per listener, for instance, commands into listeners as anonymous classes.

The step one is completed and evaluated as we detailed in Section 4.4 and Section 4.5. During the evaluation of Blob listeners detection we identified some criteria to precise our static analysis algorithm and thus decrease the number of false positive Blob listeners (recall Section 4.7).

We have implemented the step two based on the good coding practices that we explained in Section 4.7.2. Figure 4.6 shows the activity diagram of the algorithm to locate in the source code where the widget involved in a command is registered. First, the algorithm detects all listener registrations in the source code (e.g., butto-nUndo.addActionListener ). Also, the listener methods that implement a listener interface targeted by a registration are recovered. This information will be used to check whether one of these methods matches the listener method where a command is found. This preliminary check improves the overall performance of our algorithm. Next, the registrations are analyzed to obtain the widget targeted by them. Once the widget is identified, the algorithm obtains the statements referring to this widget. These statements contain the information about the widget properties such as buttonUndo.setActionCommand("undo"). A similar process is performed to extract the properties of commands. The difference is that the properties of commands are extracted from their conditionals statements (e.g., e.getActionCommand.equals("undo")). Finally, the properties of commands and widgets are compared, if they match we relate a command with a registration.

Note that gathering all the properties of a widget or a command is more accurate. For example, some conditional expressions do not refer directly to a widget attribute: e.getActionCommand().equals("undo"), where e refers to a non-specified widget. Instead, the widget attribute buttonUndo is easily identified in the conditional expression e.getSource() == buttonUndo.

The last step consist of extracting a command to its registration (in the case we choose to refactor a Blob listener as as anonymous class). However, several factors must be analysed to perform a safe refactoring to preserve the code behavior. For example, the dependency between the listeners as well as the attributes shared by them. Also, a GUI can be developed in different ways, for instance, a listener may register on a component, which represents several widgets. In such a case, there is no single widget targeted by a registration (e.g., this.addEventListener ).

While the goal of the second step is to locate the corresponding listener registrations of commands, we observed that this step can also be used to identify some GUI faults. For example, Listing 4.3 illustrates a Blob listener with GUI faults in their two commands (Command #1: Lines 12-18 and Command #2: Lines 19-21). In this case, our Figure 4.6: The activity diagram of the algorithm to detect the command registration algorithm will not identify the listener registrations for both commands since the GUI faults cause the mismatch between the properties. The values of the property invoked by the commands (e.g., label "Clear " in Command #1) to identify the widget that produced the event differ from the property values (e.g., label "Clean") of the widgets targetted by the listener registration (e.g., clearButton in Line 5).

Conclusion

We identified and characterized a Blob listener as a new design smell specific for GUIs. The empirical study has shown evidences that implemented Java GUI listeners use more conditional statements than other methods. We pored over these listeners and identified the Blob listeners can degrade the aspects of GUI quality code for instance by leading the introduction of GUI faults. We have observed three variations of a Blob listener that may occur in Java Swing listeners. Our proposed static analysis, implemented in InspectorGuidget, has successfully detected 67 Blob listeners out of 68 in six Java systems.

We believe that the presence of Blob listeners affects the quality of GUI code. We intend to investigate whether some GUI faults are accentuated by GUI design smells. This study can be assisted by our GUI fault model presented in Chapter 3. The effects of GUI design smells on GUI faults can help software engineers to prevent specific GUI faults, for instance by addressing the research question: which kind of GUI faults found in GUI controllers are correlated to the presence of Blob listeners? Also, this study will help us to demonstrate the empirical evidence that an automated refactoring of Blob listeners is worth to be done.

Chapter 5

Conclusion and Perspectives

This chapter summarizes the contributions of this thesis in GUI testing domain, and outlines the directions for future research.

Summary of contributions

From a software engineering point of view, this thesis contributes to improve the quality and reliability of interactive systems, i.e., software systems that provide users with user interfaces (graphical user interfaces in our case). The contributions are summarized below.

GUI fault model.

A GUI fault model is proposed to describe a set of GUI faults. This model is an original GUI fault classification scheme because of the following reasons. First, the fault model describes GUI faults that stem from standard GUIs (i.e., WIMP GUIs) and advanced GUIs (i.e., post-WIMP GUIs). Second, the fault model is structured at two fault levels: user interface and user interaction faults. Such a structure is essential to distinguish faults that affect the graphical components that compose GUIs from the ones that affect the user interactions that occur between users and systems. Third, our fault model covers seminal HCI concepts, mandatory to identify GUI faults that concern complex user interactions. Last, the fault model presents in detail which GUI is affected and how it occurs as a GUI failure.

The coverage and the benefits of the proposed fault model have been demonstrated as follows.

• An empirical study of real GUI failures : 279 GUI-related bug reports of five highly interactive open-source GUIs have been successfully classified using our fault model. This study highlights the relevance of our fault model in identifying and classifying faults observed in existing GUIs.

• Evaluation of two GUI testing tools against real GUI failures: some failures classified in our fault model that concern standard widgets were not detected by two standard GUI testing tools (GUITAR and Jubula). This evaluation demonstrates that some kinds of faults related to WIMP widgets are more difficult to detect

Conclusion

by the GUI testing tools, for instance, GUI faults found in the auto-completion feature. Also, the regression GUI testing tools are not able to detect some failures when a GUI faulty version is used to produce the test cases.

• Development of GUI mutants: 65 GUI mutants are derived from our fault model and planted in a highly interactive open-source system -LaTeXDraw (22 into standard widgets and 43 into ad hoc widgets). These mutants are freely available and can be reused by developers for benchmarking their GUI testing tools.

• Evaluation of GUI testing tools against GUI mutants: 43 out of 65 mutants were not killed by that standard GUI testing tools, where 40 of them concern ad hoc widgets and their user interactions. This evaluation demonstrates that GUI testing frameworks fail in detecting several failures that stem from ad hoc widgets, their multi-event interactions and data presentation.

• Ap r e c i s ea n a l y s i so fas t a n d a r dG U It e s t i n gf r a m e w o r k : an study explains the current limitations of GUI testing frameworks that focus on standard GUIs. This study helps software testers to understand why GUI failures that stem from GUI faults in our fault model were not detected by standard GUI testing tools.

Automatic detection of a GUI design smell. A systematic static analysis approach is developed to automatically detect a new type of design smell we identified and characterized, and that affect GUI implementations: the Blob listener . This approach has been implemented in a tool publicly available called InspectorGuidget. The achievements are outlined below.

• An empirical analysis of GUI controllers : the code of Java Swing listeners retrieved from 511 code repositories in Github was observed. The results pointed out a higher use of conditional statements (e.g., if ) in listeners used to identify widgets.

• Identification of GUI design smells: we identified a critical bad coding practice that we characterized as a new type of GUI design smell: Blob listener . Blob listeners are listeners that handle several GUI commands. A GUI command is a set of statements executed in reaction to a user interaction.

• Astaticanalysistoautomatic allydete ctthepr esenc eofBloblistenersinJavasystems: contrary to other code smells that can be located with structural rules on the whole code base of a software system, the detection of Blob listener requires a preliminary semantic code analysis to isolate the parts of the code base related to GUI implementation (e.g., identification of GUI listeners and conditional GUI listeners). The second step of our analysis consisted in detecting the GUI commands, i.e., GUI actions, that can produce each implemented GUI listener.

• An empirical evaluation :6 7o u to f6 8Blob listeners were successfully detected by InspectorGuidget in six highly interactive systems.

Perspectives

125

• Good coding practices to avoid the use of Blob listeners: these practices represent a step towards the automated refactoring of Blob listeners.

Experiments and tools. We have run our experiments on large interactive systems, which required building tools that can handle the complexity of real-world software.

The subject systems have been selected by using several criteria such as interactive features (e.g., direct manipulation, feedback), input devices (e.g., mouse, touch), the type of widgets (ad hoc), data graphics (2D or 3D objects). We also used an open-source interactive system to calibrate our tools during the experiments. For example, LaTeXDraw has been used to develop the GUI mutants as well as to bootstrap InspectorGuidget against Java GUI listeners.

The empirical analysis to evaluate the GUI fault model against real GUI failures was performed by carefully selecting the bug reports of five interactive systems. So, we analysed the bug report artifacts (e.g., description, patches, logs, or stack traces) to identify and classify the faults in our fault model. Our examination of GUI development practices relies on open-source code hosting repositories that we identified several interactive systems.

To run the GUI testing tools against the GUI mutants (e.g., GUITAR and Jubula), we have studied their documentation such as developer/user manuals, technical reports or research papers, homepages, and discussion forums. This study allowed us to minimize several threats regarding our experiments. To develop the GUI mutants, we have studied the code of LaTeXDraw in different versions to understand the GUI behavior of Java Swing implementations.

To implement InspectorGuidget we leveraged the existing tools to provide a more mature solution. For example, our static analysis uses Spoon to transform and analyse the Java source code. We also have implemented InspectorGuidget as an Eclipse plugin to facilitate the integration with other Java tools. Indeed, the evaluation of InspectorGuidget has been performed on six Java applications, which differ from the systems that we evaluated our fault model.

We built a complete data set of all experiments performed during this research work. This data set can be used to study for instance the correlation between GUI implementations and their GUI faults.

Perspectives

The proposed fault model has been used to identify the limits of GUI testing tools. We believe that this model can serve as the basis to improve the GUI testing techniques to cover more GUI faults. Also, these faults may be accentuated by the presence of GUI design smells. An example is the two bad coding practices listener with empty bodies and unsafe registration of listeners, as we explain later, that may introduce faults.

The directions for future research around the contributions of this thesis are presented below.

128

Conclusion

Given this behavior, GUI faults can be forged by breaking the code involved in these operations.

An example is the mutation operator introduced in the widget registration. This mutant changes the statement responsible for registering the listener on a widget. In such a case, when a user interacts with that widget the desired action is not executed Furthermore, some faults are more difficult to be modelled. One example is to forge a fault into the drag-and-drop (DnD) interaction. The basic behavior of a DnD starts by a mouse pressure followed by at least one move and ends with a release.I nJ a v a Swing, a DnD can be implemented by three GUI listeners which are mousePressed, mouseDragged,a n dmouseReleased. A mutant Java operator to introduce the fault "interaction behavior " in a DnD may be developed by breaking some attributes shared by these Java Swing listeners. Similarly, the unsafe use of the this reference in constructors exemplified previously by the bad practice unsafe registration of listeners may be used to forge GUI faults.

We also believe that the creation of GUI mutants may be more particular in other domains, for instance, GUI actions in XML. A future research can provide a mapping between GUI faults and the domain-specific mutants. One challenge is to develop a program analysis to automatically introduce such mutants in GUIs. For instance, the Java Swing mutants that we developed may be automatically planted in other Java Swing GUIs.

Refactoring Blob listeners

We presented the steps towards the refactoring of Blob listeners in Chapter 4. Refactoring Blob listeners, however, may involve another substantial cost and risks [START_REF] Kim | A field study of refactoring challenges and benefits[END_REF] that we should carefully study. We believe that Blob listeners can potentially introduce some GUI faults as we exemplified in Listing 4.3 (recall Chapter 4). In this example, refactoring the Blob listener will improve the GUI code quality (e.g., decreasing the cyclomatic complexity) and correct two GUI faults.

Abstract

The software engineering community takes special attention to the quality and the reliability of software systems. Software testing techniques have been developed to find errors in code. Software quality criteria and measurement techniques have also been assessed to detect error-prone code.

In this thesis, we argue that the same attention has to be investigated on the quality and reliability of GUIs, from a software engineering point of view. We specifically make two contributions on this topic. First, GUIs can be affected by errors stemming from development mistakes. The first contribution of this thesis is a fault model that identifies and classifies GUI faults. We show that GUI faults are diverse and imply different testing techniques to be detected.

Second, like any code artifact GUI code should be analyzed statically to detect implementation defects and design smells. As for the second contribution, we focus on design smells that can affect GUIs specifically. We identify and characterize a new type of design smell, called Blob listener. It occurs when a GUI listener, that gathers events to treat and transform as commands, can produce more than one command. We propose a systematic static code analysis procedure that searches for Blob listener that we implement in a tool called InspectorGuidget. Experiments we conducted exhibits positive results regarding the ability of InspectorGuidget in detecting Blob listeners. To counteract the use of Blob listeners, we propose good coding practices regarding the development of GUI listeners.

Figure 1 -

 1 Figure 1 -Principe du test d'interfaces utilisateur fondée sur les modèles

Figure 2 - 4 .

 24 Figure 2 -Example of a multi-event interaction : a bimanual interaction

Figure 3 -

 3 Figure 3 -Contributions de la thèse

  Retour d'action (feedback) Le retour d'action fournit pas un widget pour refléter l'état d'une action en cours ne fonctionne pas correctement Une barre de progression ne fonctionne pas correctement. Le retour d'action temporaire fournit par une interaction en cours d'exécution ne fonctionne pas Dans un éditeur de dessin, le tracé d'un rectangle à l'aide d'un glisser-déposer n'affiche pas le rectangle en cours de création.

Figure 4 -

 4 Figure 4 -Analyse statique permettant la detection automatique de Blob listeners.

Chapter 5

 5 presents the main achievements of this thesis and the future research. As a future research, we present simple examples of bad coding practices specific for Chapter 2

Figure 2 .

 2 Figure 2.1: Example of a small WIMP GUI 2 Au s e ro p e n saw i n d o wa n dt h e nc l i c k so na ni c o nb yap o i n t e r .

Figure 2 . 2 :

 22 Figure 2.2: The post-WIMP editor CNP2000 [BL04]

Figure 2 . 3 :

 23 Figure 2.3: The MVC architectural design pattern

Figure 2 . 4 :

 24 Figure 2.4: The MVC architectural design pattern

Figure 2 . 5 :

 25 Figure 2.5: Examples of V&V techniques for graphical user interfaces

Definition 2 .

 2 1 (Fault) Af a u l ti sas t a t i cd e f e c ti nas y s t e m[ W e i 1 0 ] .

Definition 2 . 2 (

 22 Error) An error is a wrong internal state of a running system[START_REF] Weißleder | Test models and coverage criteria for automatic model-based test generation with UML state machines[END_REF].ContextDefinition 2.3 (Failure) Af a i l u r ei sa ni n c o r r e c te x t e r n a lb e h a v i o ro fas y s t e m .

Definition 2 . 4 (

 24 Fault Model) Af a u l tm o d e ld e s c r i b e sas e to ff a u l t sr e s p o n s i b l ef o r af a i l u r ep o s s i b l ya tah i g hl e v e lo fa b s t r a c t i o na n di st h eb a s i sf o rm u t a t i o nt e s t i n g .

Context

Figure 2 .

 2 Figure 2.6: Model-based testing process. Adapted from [Lel13]

  Figure is: <square; none; create shape>.

Figure 2 .

 2 Figure 2.7: Overview of GUITAR process. Adapted from [Mem06]

Figure 2 .

 2 Figure 2.8: GUI Ripping artifacts presented by Memon et al. [MBNR13]

Figure 2 .

 2 Figure 2.9: GUISurfer process presented by Silva et al. [SSG + 10]

64 GUI fault model Definition 3 . 2 (

 32 GUI Error) AG U Ie r r o ri sa na c t i v a t i o no faG U If a u l tt h a tl e a d s to an unexpected GUI state. Definition 3.3 (GUI Failure) AGUIfailur eisamanifestationofanunexp e cte dGUI state provoked by a GUI fault.

  Figure 3.1 gives an overview of the selected and classified bug reports. These failures were classified into the Action (119 failures, 43%), GUI Structure and Aesthetics (75 failures, 27%), Data Presentation (39 failures, 14%), Reversibility (31 failures, 11%), Interaction behavior (12 failures, 4%), and Feedback (3 failures, 1%) fault categories. Most of the failures classified into GUI Structure and Aesthetics concern the incorrect layout of widgets (51%). Likewise, most of the failures in the Action category refer to incorrect action results (75%).

Figure 3 . 1 :

 31 Figure 3.1: Classification of the 279 bug reports using the GUI fault model

Figure 3 . 2 :

 32 Figure 3.2: Manifestation of failures in the user interface and interaction levels

Figure 3 . 3 :

 33 Figure 3.3: Screen-shot of the LaTeXDraw's GUI

Figure 3 . 4 :

 34 Figure 3.4: Representation of how interactions are currently managed and the current limit

Figure 3 . 5 :

 35 Figure 3.5: EFG sequence on the left. Interaction-action sequence on the right.

Figure 3 . 6 :

 36 Figure 3.6: The architectural design pattern Malai

Figure 3 . 7 :

 37 Figure 3.7: Example of a bi-manual interaction modelled by Malai UIDL

Figure 3 . 8 :

 38 Figure 3.8: Illustration of a Malai instrument

Figure 3 . 9 :

 39 Figure 3.9: Example of an interaction-action-flow graph

Figure 4 . 1 :

 41 Figure 4.1: Distribution of the listeners according to their number of if statements

Figure 4 . 3 :Figure 4 .

 434 Figure 4.3: Distribution of the false negative commands

Figure 4 . 4 :

 44 Figure 4.4: Distribution of the false positive Blob listeners

Figure 4 .

 4 5 depicts this distribution.

Figure 4 . 5 :

 45 Figure 4.5: Number of GUI commands per Blob listener per software system

Listing 5 . 3 :

 53 Listing 5.3 gives a piece of code to demonstrate the refactoring of the Blob listener shown in Listing 4.3. private void registerWidgetHandlers() { view.clearButton.addActionListener(e -> { if (Refactoring a small Blob listener using Java 8 Lambdas 5 Résumé La communauté du génie logiciel porte depuis ses débuts une attention spéciale à la qualité et la fiabilité des logiciels. De nombreuses techniques de test logiciel ont été développées pour caractériser et détecter des erreurs dans les logiciels. Les modèles de fautes identifient et caractérisent les erreurs pouvant affecter les différentes parties d'un logiciel. D'autre part, les critères de qualité logiciel et leurs mesures permettent d'évaluer la qualité du code logiciel et de détecter en amont du code potentiellement sujet à erreur. Les techniques d'analyses statiques et dynamiques scrutent, respectivement, le logiciel à l'arrêt et à l'exécution pour trouver des erreurs ou réaliser des mesures de qualité. Dans cette thèse, nous prônons le fait que la même attention doit être portée sur la qualité et la fiabilité des interfaces utilisateurs (ou interface homme-machine, IHM), au sens génie logiciel du terme. Cette thèse propose donc deux contributions dans le domaine du test et de la maintenance d'interfaces utilisateur : 1. Classification et mutation des erreurs d'interfaces utilisateur. 2. Qualité du code des interfaces utilisateur. Nous proposons tout d'abord un modèle de fautes d'IHM. Ce modèle a été conçu à partir des concepts standards d'IHM pour identifier et classer les fautes d'IHM ; Au travers d'une étude empirique menée sur du code Java existant, nous avons montré l'existence d'une mauvaise pratique récurrente dans le développement du contrôleur d'IHM, objet qui transforme les évènements produits par l'interface utilisateur pour les transformer en actions. Nous caractérisons cette nouvelle mauvaise pratique que nous avons appelée Blob listener, en référence à la méthode Blob. Nous proposons également une analyse statique permettant d'identifier automatiquement la présence du Blob listener dans le code d'interface Java Swing. N° d'ordre : 15ISAR 26 / D15 -26

Table 2 -

 2 Fautes d'interfaces utilisateur

	Catégories	Fautes	Défaillances possibles

2 .

 2 Qualité du code des interfaces utilisateur [LBB + 16] : Au travers d'une étude empirique menée sur du code Java existant, nous avons montré l'existence d'une mauvaise pratique récurrente dans le développement du contrôleur d'IHM, objet qui transforme les évènements produits par l'interface utilisateur pour les Résumé en réaction à des évènements produit par l'interface utilisateur. Le listing suivant illustre un Blob listener où deux commandes sont produite par le même écouteur qui gère deux widgets différents b1 et b2.Nous avons implémenté un outil Eclipse, appelé InspectorGuidget, permettant de détecter des Blob listeners dans du code Java Swing. La figure4détaille les différentes étapes de cette analyse.

	class AController implements ActionListener {
	JButton b1;
	JButton b2;
	@Override public void actionPerformed(ActionEvent e) {
	Object src = e.getSource();
	if(src==b1){
	// Commande 1
	}else if(src==b2)
	// Commande 2
	}
	}
	//...
	}
		Source code + libraries
	Listeners	GUI	GUI Listeners	GUI Listeners
	Processor	Listeners	Processor	Detection
			Conditional
	Commands Detection	GUI listeners	Blob Listeners Detection
	Def-Use Chain Creation	CFG	Control Flow Graph creation		Blob Listeners Output
	DefUse
	Conditional Statements Analysis	Candidate Commands	Commands Refinement	Commands	Commands Selection

transformer en actions. Nous caractérisons cette nouvelle mauvaise pratique que nous avons appelé Blob Listener, en référence à la méthode Blob.N o u sp r o p osons également une analyse statique permettant d'identifier automatiquement la présence de Blob listener dans le code d'interface Java Swing. Un Blob listener apparaît dés lors qu'un écouteur d'un contrôler peut produire plus d'une commande IHM. Une commande IHM est dans ce cas un ensemble d'instructions exécutés

Table 3 -

 3 Résultats de la détection de Blob listeners avec InspectorGuidget.

	Logiciel	Blob listeners FN FP Rappel blob Precision blob Temps
		Détectés (#) (#) (#)	(%)	(%)	(ms)
	FastPhotoTagger	4	0	1	100.00	80.00	3445
	GanttProject	3	0	3	100.00	50.00	1910
	JaxoDraw	16	0	3	100.00	84.21	13143
	Jmol	18	1	4	94.74	81.82	16904
	TerpPaint	4	0	0	100.00	100.00	12723
	TripleA	22	0 19	100.00	53.66	16732
	Total	67	1 30	98.81	69.07	10810

Des bonnes pratiques de codages visant à limiter l'usage de Blob listeners sont ensuite proposées.

  Chapitre 4 : ce chapitre se focalise sur les mauvaises pratiques de développement d'interfaces utilisateur. Les mauvaises pratiques affectent la qualité du code et peuvent augmenter le risque d'erreurs. Nous proposons principalement une mauvaise pratique, le Blob listener , que nous avons étudié empiriquement par l'analyse de code de projets existants. Une analyse statique pour identifier automatiquement cette mauvaise pratique est proposée et développée au travers d'un plug-in Eclipse analysant du code Java Swing.Le modèle de fautes proposés a permis d'identifier les limites actuelles des outils de test d'interfaces utilisateur. Nous pensons que ce modèle peut servir de base pour l'amélioration de ces outils. En particulier :• Oracles graphiques. Chaque faute doit être liée à un oracle graphique décrivant comment détecter cette faute. Cette étape est complexe car les oracles peuvent nécessiter des techniques variées. Par exemple, pour assurer que le rendu graphique

Chapitre 2 : ce chapitre introduit les concepts fondamentaux de cette thèse. Il présente notamment les concepts de base d'IHM. Il propose également une synthèse des travaux actuels sur le test d'IHM. Chapitre 3 : ce chapitre introduit le modèle de fautes d'IHM proposé. Ce modèle de fautes se divise en deux parties. La première est consacrée aux fautes d'interfaces utilisateur et la seconde aux fautes d'interactions utilisateur. Ce chapitre décrit également les études empiriques menées pour valider et discuter le modèle de fautes. Nous présentons également une étude empirique démontrant la capacité de notre outil à trouver des Blob listeners. Chapitre 5 : ce chapitre conclut cette thèse en proposant une synthèse des contributions et des perspectives de recherche détaillées dans la section suivante. Résumé Perspectives d'un objet est correct, il est possible d'analyser une capture d'écran de ce dernier. Par contre, pour assurer que objet graphique est un certain état, il est possible d'analyser le code définissant cet état. • Fautes d'IHM spécifiques à certains domaines. Certains domaines, tels que la réalité virtuelle ou la réalité augmentée, peuvent être affectés par des fautes spécifiques non présentes dans d'autres domaines plus standard et donc absents du modèle de fautes d'IHM que nous proposons. Il serait donc possible d'effectuer d'autres études se focalisant cette fois sur ces domaines afin d'identifier et de caractériser d'autres fautes. • Impact du Blob listener et ré-usinage du code. Le travail sur la mauvaise pratique Blob listener requière un approfondissement sur plusieurs points. Tout d'abord, une étude empirique pourrait être menée pour mesurer l'impact du Blob listener sur le code. Par exemple, la présence de Blob listeners implique-t-elle plus d'erreurs dans le code ? De plus, une étape de ré-usinage des Blob listeners pourrait être réalisée dans le but de supprimer automatique les Blob listeners en les remplaçant par des bonnes pratiques identifiées.

Table 2 .

 2 1: Examples of Interface defects presented by IEEE Std. [IEE10]

	Attribute	Value	Example of Defects

Type Interface

Incorrect module interface design or implementation Incorrect report layout (design or implementation) Incorrect or insufficient parameters passed Cryptic or unfamiliar label or message in user interface Incomplete or incorrect message sent or displayed Missing required field on data entry screen

Table 2 .

 2 2: ODC triggers for graphical user interfaces[START_REF]Extensions for defects in GUI, user documentation, build and national language support[END_REF]

	Defect Removal Activities Triggers	Defect Type
		Design Conformance	Assignment /Initialization
		Widget/Icon Appearance Checking
	GUI Review	Screen Text/Characters Input Devices	Algorithm/Method Timing/Serialization
		Navigation	Interface/O-O Messages
		Widget/GUI Behavior	Relationship

Likewise, Li et al. propose a new classification scheme called Orthogonal Defect Classification for Black-box Defect (ODC-BD)

Table 2 .

 2 3: Defects and their related objects presented by Xuebing[START_REF] Yang | Graphic User Interface Modelling and Testing Automation[END_REF]

	Defect Class	Related Object Type

Functional defects Button, Tool Button, Menu Item, List Item, Tree View, etc. Interactive defects EditBox, ComboBox, CheckBox, Spinner, TrackBar, etc.

GUI adjustment

Scroll Bar, Title Bar, Split Container, Tab Layouts, etc.

Table 2 .

 2 4: Examples of fault types presented by Strecker et al. [SM08]

	Fault ID Fault Classes	Examples
	1	Modify relational operator	>, < , >=, <=, ==, !=
	2I n v e r t t h e c o n d i t i o n s t a t e m e n t	N / A
	3	Modify arithmetic operator	+, -, *, /, =, ++, -, +=, -=,*=, /=
	4	Modify logical operator	&&, ||
	5S e t / r e t u r n d i fferent boolean value	true, false
	6I n v o k e d i fferent (syntactically similar) method	N/A
	7S e t / r e t u r n d i fferent attributes	N/A
	8	Modify bit operator	&, |, &=, !=

Table 2 .

 2 5: Concurrency Bugs presented by Lu et al. [LPSZ08]

	Dimension Category Description
	Atomicity The desired serializability among multiple memory accesses is violated
	Violation	(i.e.,ac o d er e g i o ni si n t e n d e dt ob ea t o m i c ,b u tt h ea t o m i c i t yi sn o t
	Bug	enforced during execution).
	Pattern

•

  Abstract GUI test cases are non-executable test scripts generated by traversing a GUI test model w.r.t. a test adequacy criterion. A test adequacy criterion is defined to constitute an adequate test suite (e.g., what to test in a GUI? ). It helps to determine whether the test cases adequately check the SUT. An abstract GUI test case represents one possible sequence of user interaction described in the GUI test model.

• Concrete GUI test cases are executable test scripts concretized from the abstract test cases. A concrete test case contains information (e.g., input data) that allows an abstract test case be executed over the SUT.

Table 2 .

 2 6: A comparison of some GUI static analysis approaches Silva et al. use a static analysis to extract automatically the GUI behavior from the source code [SSG+ 10]. The static analysis is implemented in a tool called GUISurfer.

	Purpose	Approach	Tool	Subject Artifact GUI Domain
		Arlt et al. [APB + 12]	Gazoo	GUI Model	Java and C#
	GUI testing	Yang et al. [YPX13]	ORBIT	Test Model	Android
		Silva et al. [SSG + 10]	GUISurfer	GUI Model	Java Swing
		Zhang et al. [ZLE13]	FlowFixer	GUI workflows	Java Swing
	GUI maintenance	Staiger [Sta07]	Bauhaus	GUI structures	C/C++
	and evolution	Zhang et al. [ZLE12]	WALA	Java bytecode	Java/Android
		Frolin et al. [OPM15] AUREBESH Inconsistencies	JavaScript
	Design smells	Silva et al. [SCSS14]	GUISurfer	Dialog models	Any GUI
		Chen & Wang[CW12] GTT	GUI test scripts	C/C++
	GUI metrics	Magel et al. [MA07]	-	Structural metrics	Any GUI

Table 2 .

 2 7: Bad smells for GUI test scripts. Adapted from[START_REF] Chen | Bad smells and refactoring methods for GUI test scripts[END_REF]

Table 3

 3

			.1: User Interface Faults
	Fault categories ID	Faults	Possible failures
		GSA1 Incorrect layout of widgets	The positions of 2 widgets are inverted.
			(e.g.,a l i g n m e n t ,d i m e n s i o n ,o r i -	A text is not fully visible since the size
			entation, depth)	of text field is too small.
				Rulers do not appear on the top of a
				drawing editor.
				The vertical lines for visualizing the
				precise position of shapes in the draw-
				ing editor are not displayed.
	GUI Structure and Aesthetics	GSA2 Incorrect state of widgets (e.g.,v i s i b l e ,a c t i v a t e d ,s e -lected, focused, modal, editable,
			expandable)

Table 3 .

 3 2: User Interaction Faults

	Fault categories ID	Faults	Possible failures
	IB1	Incorrect behavior of a user	Ab i -m a n u a li n t e r a c t i o nd e v e l o p e d
		interaction	for a specific purpose does not work
	Interaction Behavior		properly. The synchronization between the voice and the gesture does not work
			properly in a voice+gesture interac-
			tion.
	ACT1 Incorrect action results	Translating a shape to a position
			(x, y) translates it to the position
			(-x, -y).
			Setting the zoom level at 150%, sets
			it at 50%.
	ACT2 No action executed	Clicking on a button has no effect.
	Action		Executing a DnD on a drawing area
			to draw a rectangle has no effect.
	ACT1 Incorrect action executed	Clicking on the button Save shows
			the dialogue box used for loading.
			Scaling a shape results in its rota-
			tion.
			Performing a DnD to translate
			shapes results in their selection.
	RVSB1 Incorrect results of undo or	Clicking on the button redo does
		redo operations	not re-apply the latest undone ac-
			tion as expected.
			Pressing the keys ctrl+z does not
			revert the latest executed action as
			expected.
	Reversibility

Table 3 .

 3 3: Distribution of analyzed failures per software

	GUI	Analyzed User interface User interaction Bug Repositories
	Software	failures	failures	failures	link
	Sweet Home 3D	33	55%	45%	http://sourceforge.net/p/sweethome3d/bugs/
	File-roller	32	28%	72%	https://bugzilla.gnome.org/query.cgi
	JabRef	84	42%	58%	http://sourceforge.net/p/jabref/bugs/
	Inkscape	82	28%	72%	https://bugs.launchpad.net/inkscape/
	Firefox Android	48	60%	40%

https://bugzilla.mozilla.org/

Table 3 .

 3 4: JabRef failures detected by GUITAR and Jubula

	ID fault ID failure Bug repository link	GUITAR Jubula
	GSA1	#1	http://sourceforge.net/p/jabref/bugs/160/	77
	GSA2	#2	http://sourceforge.net/p/jabref/bugs/514/	73
	GSA3	#3	http://sourceforge.net/p/jabref/bugs/166/	73
	DT1	#4	http://sourceforge.net/p/jabref/bugs/716/	73
	DT2	#5	-
	DT3	#6	http://sourceforge.net/p/jabref/bugs/575/	73
	IB1	#7	-
	ACT1	#8	http://sourceforge.net/p/jabref/bugs/495/	33
	ACT2	#9	http://sourceforge.net/p/jabref/bugs/536/	33
	ACT3	#10	http://sourceforge.net/p/jabref/bugs/809/	77
	RV S B 1	# 1 1	http://sourceforge.net/p/jabref/bugs/560/	73
	RV S B 2	# 1 2	-
	RV S B 3	# 1 3	http://sourceforge.net/p/jabref/bugs/458/	33
	FDBK1	#14	http://sourceforge.net/p/jabref/bugs/52/	73
	FDBK2	#15	-

Table 3 .

 3 5: Example of a GUI mutant in LaTeXDraw

	Mutant attribute	Value
	Fault category	Action
	Fault	No action is executed
	Failure description	Any shap e available in a to olbar is drawn.
	WIMP/post-WIMP	post-WIMP
	Ad hoc widgets involved	yes
	Test case length	2 (Select Shap e, Add Shap e)
	Interactions	DnD, button click
	Minimal number of events to perform 4 (press button, press canvas, move canvas, release canvas)

Table 3 .

 3 GUIs for benchmarking 79 6: Mutants planted according to the user interface faults

	ID	GSA1	GSA2	GSA3	DT1	DT2	DT3
	#Mutants	374	2	1	1
	#Length	0..2	0..4	0..4	4	2	4

Table 3 .

 3 7: Mutants planted according to the user interfaction faults

	ID	IB1	ACT1	ACT2	ACT3	RVSB1	RVSB2	RVSB3	FDBK1	FDBK2
	#Mutants	18	1 6	5	9	2	-	3	3
	#Length	41 . . 71 . . 84 . . 5	2 . . 8	2	-	2 . . 5	3 . . 4

Table 3 .

 3 9: Defects found by applying the proposed approach on LaTeXDraw

	Id Link

https://bugs.launchpad.net/latexdraw/+bug/770726 data model #4 https://bugs.launchpad.net/latexdraw/+bug/770723 Java Swing

  Complex and large conditional expressions. We have observed different implementations in Blob listeners to identify which widgets produced the event. The typical implementations leverage the widget attribute as exemplified by Lines 7 and 9 in Listing 4.1. Other implementations, however, do not handle directly this attribute. Instead, they leverage the properties of widgets (e.g., getActionCommand) or other attributes to access the target widget. These kinds of implementations require a semantic code analysis to infer recursively their complex and large expressions to obtain for instance a reference to a GUI object. The examples of such expressions in Blob listeners are as follows: Faults have been reported into Blob listeners. One example is the two issues reported in a code repository 3 from Github. Listing 4.3 shows the excerpt of the GUI faulty code.

		What Compose GUI listeners? An Empirical Study	97
	3. if(label.equals("LABEL_DRAW_X_LABELS") || label.equals("LABEL_DRAW_Y_LABELS"))...
	if (!BaseEditDelegate.getEditMode(m_gameData)
		&& (!(e.isControlDown() || e.isAltDown() || e.isShiftDown())
		&& e.getButton() == MouseEvent.BUTTON1
		&& (m_clickedAt != null
		&& m_releasedAt != null)))...
	if ((evt.getX() >= center.pictureScrollPane.getViewport().getWidth())
		|| (evt.getY() >= center.pictureScrollPane.getViewport().getHeight())
		|| (evt.getX() <= 0)
		|| (evt.getY() <= 0)
		|| (evt.getX() > (w * zoom))
		|| (evt.getY() > (h * zoom)))...
	4. Faults. public class JWhiteBoard extends ReceiverAdapter
				implements ActionListener, ChannelListener {
		//..
		clearButton=new JButton("Clean");
		clearButton.addActionListener(this);
		leaveButton=new JButton("Exit");
		leaveButton.addActionListener(this);
		1 @Override public void actionPerformed(ActionEvent e){ //...more than 150 lines of code
		2 //...
		3 @Override public void actionPerformed(ActionEvent e) { if(label.equals("LABEL_ZOOM_IN")) {//Command #1
		4 String command=e.getActionCommand(); drawPanel.zoomIn();//non-shared statement
		5	drawPanel.getFrameParent().getToolbar().getZoomField().setValue(...); if("Clear".equals(command)) {//GUI fault in Command #1
		6		mainFrame.getXScale().repaint(); if(noChannel) {
		7		mainFrame.getYScale().repaint(); clearPanel();
		8		mainFrame.requestFocus(); return;
		9		}	return;
		10		} sendClearPanelMsg();
		11	}	if(label.equals("LABEL_ZOOM_OUT")){//Command #2
		12	drawPanel.zoomOut();//non-shared statement else if("Leave".equals(command)) {//GUI fault in Command #2
		13		drawPanel.getFrameParent().getToolbar().getZoomField().setValue(...); stop();
		14	}//...	mainFrame.getXScale().repaint();
		15 }//...	mainFrame.getYScale().repaint();
	}	16		mainFrame.requestFocus();
		17 18	return; } //... more than 50 GUI commands Listing 4.3: Example of GUI faults within a Blob listener
	Listing 4.2: Example of a quite similar code within a Blob listener 3 https://github.com/LinhTran95/Asg7--Team10/

  Algorithm 3 Blob listeners DetectionInput: commands,t h ec o m m a n d sd e t e c t e db yA l g o r i t h m2 Output: blobListeners,t h ed e t e c t e dBlob listeners

1: blobListeners ← ∅ 2: candidatesBlob ← gatherCommandsByListener(commands) 3: foreach candidate ∈ candidatesBlob do 4:

if hasCommands(candidate) then 5:

Table 4 .

 4 4 also reports the number of FN and FP commands, and the values of the recal l and precision metrics. TripleA and Jmol revealed the highest number of FN, whereas TerpPaint presented the lowest number of FN. The precision of the command detection is 99.10 %. Most of the commands (439/443) detected by our algorithm are relevant. We, however, noticed 76 relevant commands not detected leading to an average

	Evaluation

recal l of 86.05 %. Thus, our algorithm is less accurate in detecting all the commands than in detecting the relevant ones. For example, TripleA revealed 44 FN commands and no false positive result, leading to a recall of 77.55 % and a precision of 100 %. The four FP commands has been observed in JAxoDraw (2) and Jmol (2), leading to a precision of 98.02 %a n d98.10 % respectively.

Table 4 .

 4 [START_REF]1 Beizer's taxonomy adapted to cover GUIs[END_REF] gives an overview of the results of the Blob listeners detection per software system. The highest numbers of detected Blob listeners concern TripleA (22), Jmol (18), and JAxoDraw (16). Similarly to the command detection, we did not observe a correlation between the number of conditional GUI listeners, commands, and Blob listeners. Indeed, FastPhotoTagger, GanttProject,andTerpPaint have presented a quite similar number of detected Blob listeners against a different number of conditional GUI listeners.

Table 4 . 5 :

 45 Blob listeners Detection Results

	Software	Successfully Detected FN FP Recall blob Precision blob Time
	System	Blob listeners (#)	(#) (#)	(%)	(%)	(ms)
	FastPhotoTagger	40	1	1 0 0 .00	80.00	3445
	GanttProject	30	3	1 0 0 .00	50.00	1910
	JaxoDraw	16	0	3	100.00	84.21	13143
	Jmol	18	1	4	94.74	81.82	16904
	TerpPaint	40	0	1 0 0 .00	100.00	12723
	TripleA	22	0	19	100.00	53.66	16732
	OVERALL	67	1	30	98.81	69.07	10810

  2.

	public void stateChanged(final ChangeEvent evt) {
	final Component component = (Component) evt.getSource();
	final String name = component.getName();
	if ("spxin".equals(name)) {//Command #1
	final SpinnerNumberModel model = component.getModel();
	setParameter("xPosition", (Integer) model.getNumber());
	}else if ("spyin".equals(name)) {//Command #2
	final SpinnerNumberModel model = component.getModel();
	setParameter("yPosition", (Integer) model.getNumber());
	}else if ("spx".equals(name)) {//Command #3
	final SpinnerNumberModel model = component.getModel();
	setParameter("x", (Integer) model.getNumber());
	}//... more 20 commands
	}
	Listing 4.9: GUI code excerpt, from JAxoDraw 12

Une action est également appelée un évènement [Mem07] ou une commande [GHJV95, BL00].

Tous les mutants sont librement disp onibles sur le site suivant : https://github.com/arnobl/ latexdraw-mutants

Also called an event[START_REF] Atif M Memon | An event-flow model of GUI-based applications for testing[END_REF] or a command [GHJV95, BL00].

Also called long method.I ti sam e t h o dt h a th a sg r o w nt o ol a r g e[ F o w 9 9 ] .

All these mutants and the original version are freely available in https://github.com/arnobl/ latexdraw-mutants Contributions

The action may affect only the internal state of the system and thus its resulting may not be immediately visible by the user. For example, pressing the button "Save" in a text editor.

These interactions are more complex from a software engineering point of view. From a human point of view they should be more natural, i.e., more close to how people interact with objects in the real life.

"A multimodal HCI system is simply one that responds to inputs in more than one modality or communication channel (e.g., speech, gesture)"[START_REF] Jaimes | Multimodal human-computer interaction: A survey[END_REF].

A floating palette differs from traditional palettes since it does not have the notion of selection, instead it floats above other windows.

http://www.javaworld.com/article/2076557/java-web-development/ understanding-javaserver-pages-model-2-architecture.html

We use the term bug to characterize any problem in a software such as fault/defect, error, or failure.

"A defect trigger is a condition that allows a defect to surface"[ C B C +

92].

Also called mutation operators, mutagenic operators, mutagens, mutation transformations, and mutation rules[START_REF] Offutt | Mutation testing for the new century[END_REF][START_REF] Jia | An analysis and survey of the development of mutation testing[END_REF].

It is AOP extension dedicated to Java programming language: http://www.eclipse.org/ aspectj/

This version (aka. golden version) is considered a fault-free version of a system, and it is used for doing regression testing[START_REF] Xun Yuan | GUI interaction testing: Incorporating event context[END_REF][START_REF] Seyed | An automated framework for software test oracle[END_REF].

This is a formal programming language developed by Microsoft Research[START_REF] Barnett | The spec# programming system: An overview[END_REF].

This exploration is also called "crawling or ripping"t h eG U I .

http://tema.cs.tut.fi/

http://findbugs.sourceforge.net/

http://pmd.sourceforge.net/

These handlers are responsible for treating events fired by widgets, aka. (GUI) listeners[START_REF]Java Look and Feel Design Guidelines[END_REF], or (GUI) controllers [LBB + 16].

Aclickisoneinteractioncomposedoftheeventmouse pressed followed by the event mouse released. Its simple behavior has leaded to consider a click as an event itself.

https://docs.oracle.com/javafx/2/api/javafx/scene/input/GestureEvent.html

http://www.eclipse.org/jubula

http://sourceforge.net/apps/mediawiki/guitar/

http://jabref.sourceforge.net/

http://sourceforge.net/projects/latexdraw/

https://github.com/arnobl/latexdraw-mutants

https://github.com/arnobl/latexdraw-mutants/tree/master/GUImutants/mutant35

https://spreadsheets0.google.com/spreadsheet/pub?key=0Ah-FLr0Egz9zdGtINk54ZDlDbWdaNWdOSzR0clB4ZkE

http://argouml.tigris.org/

https://github.com/arnobl/Malai

http://www.cluster-connexion.fr/

https://github.com/diverse-project/InspectorGuidget

http://docs.oracle.com/javase/8/javase-clienttechnologies.htm

http://www.gwtproject.org/

https://www.eclipse.org/swt/

The sources used in our study and the resulting data are available here: https://github.com/ diverse-project/InspectorGuidget

The following Github query has been used: https://api.github.com/search/repositories?q= swing+GUI+in:description,readme+language:java&sort=stars&per_page=100. Because of resource constraints, only the 511 most starred repositories out of the 1200 available have been analyzed.

Path: src/games/strategy/engine/framework/startup/ui/ClientSetupPanel.java; lines: 316-326.

Path: src/TerpPaint.java; lines: 4951-5275.

Path: src/net/sf/jaxodraw/gui/panel/edit/JaxoOptionsPanelListener.java; lines: 83-183.

The original code is available here: https://github.com/LinhTran95/Asg7--Team10/ blob/master/jWhiteBoard/src/jWhiteBoard/JWhiteBoard.java

Acknowledgements

I would like to thank my supervisors, Benoit Baudry and Arnaud Blouin, for their guidance and mentoring that made this work possible. I would like to say that working in the Diverse team was an pleasure.

Code metrics allow developers to calculate the structural attributes of a source code. Several studies has been done to establish metrics to measure the complexity of code since they are a strong indicator of software quality and maintenance cost. Code metrics are, for example, the number of lines of code (LOC), the McCabe's cyclomatic complexity (CC) [START_REF] Thomas | A complexity measure[END_REF], the cohesion metrics [START_REF] Romano | Refactoring fat interfaces using a genetic algorithm[END_REF].

Code structures are useful to understand different aspects of a source code such as control flow, data flow and data structures. Control flow structures concern the paths of an execution and can be thus used, for instance, to identify unreachable code. Data flow structures track a data item as it is accessed and modified by the code. One example of data-flow error is assigning an incorrect or invalid value to a variable.

ID Defect types categories 1xxx

Functional Bugs: Requirements and Features 11xx Requirements Incorrect 12xx Logic 13xx Completeness 14xx Verifiability 15xx Presentation 16xx Requirements Changes 2xxx Functionality As Implemented 21xx Correctness 22xx Completeness -Features 23xx Completeness -Cases 24xx Domains 25xx User Messages and Diagnostics 26xx Exception Conditions Mishandled 3xxx Structural Defect 31xx Control Flow and Sequencing 32xx Processing 4xxx Data Defect 41xx Data Definition, Struc., Declaration 42xx Data Access and Handling 5xxx Implementation Defect 51xx Coding and Typographical 52xx Standards Violations 53xx GUI Defects 54xx Software Documentation 55xx User Documentation

94

GUI Design Smells: The Case of Blob Listener interactions implemented in different kind of GUI listeners. To build a ground truth for our experiments we manually retrieved all instances of Blob listeners in each application. We then run our tool against each application to detect GUI listeners, commands, and Blob listeners.

In this chapter, we first introduce the motivation of studying GUI controllers and explain why we have identified a Blob listener as a GUI design smell (Section 4.1). We then present the empirical study to investigate the current development practices regarding listeners in GUI controllers (Section 4.2). Based on this study, we identify and characterize a Blob listener as a GUI design smell presented in Section 4.3. We then propose a systematic static code analysis procedure to search for Blob listeners (Section 4.4). Next, we evaluate our approach and present the results (Section 4.5). The threats to validity of the experiments are presented in Section 4.6. We also discuss the scope of InspectorGuidget and the good coding practices we proposed to avoid the use of Blob listeners (Section 4.7). This chapter ends with the preliminary steps towards refactoring Blob listeners (Section 4.8).

Introduction

Software engineers develop GUIs following widespread architectural design patterns that consider GUIs as first-class concerns (recall Chapter 2). GUI implementations rely on event-driven programming where events are handled by controllers (or presenters 2 ). Listing 4.4 illustrates a simple example of GUI controller in Java Swing code. In this example, the AController manages events produced by two widgets, b1 and b2 (Lines 2-3). To handle events these widgets trigger in response of users' interactions, AController implements the ActionListener. The code that reacts to the events is included in the GUI listener actionPerformed. A GUI command, i.e., a set of statements executed in reaction of a GUI event, is produced for each widget (Lines 8 and 10). We define a Blob listener as a GUI listener that can produce multiple GUI commands. 2 For simplicity, we will use the term controller throughout this chapter to refer to any kind of component of MV* architectures that manage events triggered by GUIs, such as Presenter (MVP), or ViewModel (MVVM [START_REF] Smith | WPF apps with the model-view-viewmodel design pattern[END_REF]).

GUI Design Smells: The Case of Blob Listener

Java Swing provides a set of GUI listeners that controllers can implement. To identify GUI listener methods, we search for all the methods that match a Java Swing listener method. The 511 repositories contain 1 935 262 lines of Java code (LoC): 16 617 listener methods (3.6 % of the total LoCs) and 319 795 non-listener methods (96.4 % of LoCs).

To obtain an overview of the structure and the complexity of each Java method, we collected the cyclomatic complexity (CC) and the number of control flow statements. Empty methods are ignored.

The results are provided in Table 4.1. We performed an independent samples Mann-Whitney test [START_REF] Sheskin | Handbook Of Parametric And Nonparametric Statistical Procedures[END_REF] (data do not follow a normal distribution) to compare the data gathered from listener and non-listener methods, using a 95 % confidence level (i.e., p-value<0.05). We observe important variations for all the measured metrics, between listener and non-listener methods. Switch and loop statements per statement are more than 62 %t o68 % less used in listeners than in non-listener methods. Similarly, the mean CC of listeners is 16.4 % less than the mean CC of non-listener methods. Meanwhile, there are 24.3 %moreif statements per statement in listeners than in non-listener methods. All the p-values below 0.05 indicate that the variations we observed are statistically significant and not due to randomness. Based on these observations, we conclude that Java Swing GUI listener methods are not developed as other methods. Now, focusing on if statements, Figure 4.1 gives the distribution of the number of listeners according to their number of if statements. Most of listeners have less than three if statements (91.7 %, i.e., 13 227 of the 14 420 non-empty analyzed listeners). We also looked at the kinds of listeners that use more than two if statements in their code (8.3 %). 47.3 %( i.e., 564) of these listener methods are concrete implementations of actionPerformed declared in the ActionListener interface (used to receive events from triggerable widgets such as buttons, check-boxes, and menus).

In the next section we explain why listeners have a higher use of if statements than other methods.

Blob listener : Definition & Illustration

This section introduces the Blob listener and illustrates some bad practices found in the projects we retrieved from Github.

GUI Design Smells: The Case of Blob Listener

Comparing a property of the widget. Listing 4.4 is an example of the first variant of Blob listener : the widgets that produced the event (lines 10, 13, and 15) are identified with a String associated to the widget and returned by getActionCommand (line 9). Each of the three if blocks defines a behavior depending on the triggered widget (lines 11, 12, 14, and 16). Each block of instructions forms a command. In Java Swing, the properties used to identify widgets are mainly the name or the action command of these widgets. The action command is a string used to identify the kind of commands the widget will trigger. Listing 4.5, related to Listing 4.4, shows how an action command (lines 2 and 6) and a listener (lines 3 and 7) can be associated to a widget in Java Swing during the creation of the user interface. menuItem = new JMenuItem(); menuItem.setActionCommand("Copy"); menuItem.addActionListener(listener); button = new JButton(); button.setActionCommand("Cut"); button.addActionListener(listener); //... practice where the type of the widget is tested using the operator instanceof (Lines 3, 5, 7, and 9). One may note that such if statements may have nested if statements to test properties of the widget as explained in the previous point.

Listing 4.6: Widget identification using the operator instanceof Comparing widget references. The last variant of Blob listener consists of comparing widget references to identify those at the origin of the event. Listing 4.7 illustrates this variant where getSource returns the source widget of the event that is compared to widget references contained by the listener (e.g., lines 2, 4, and 6). In these three variants, multiple if statements are successively defined. Such successions are required when one single GUI listener gathers events produced by several widgets. In this case, the listener needs to identify the widget that produced the event to process.

The three variants design smell also appear in others Java GUI toolkits, namely SWT, GWT, and JavaFX. Examples for these toolkits are available on the webpage of this work 1 .

Detecting Blob listeners

In this section, we present our static analysis approach to automatically detect Blob listeners.

Approach Overview

We characterize Blob listeners as GUI listeners that can produce several GUI commands. Section 4.2 showed empirical evidence that listeners mainly use conditional statements to identify widgets. Figure 4 Selecting the most representative commands. A conditional block statement can be surrounded by other conditional blocks. Potential commands detected in the function getPotentialCmds can thus be nested within other commands. We define such commands as nested commands. In such a case, the algorithm analyzes the nested conditional blocks to detect the most representative command. We observed two cases:

1. Ap o t e n t i a lc o m m a n dc o n t a i n so n l yas i n g l ep o t e n t i a lc o m m a n d ,r e c u r s i v e l y . The following code excerpt depicts this case. Two potential commands compose this code. Command #1 (Lines 1-5) has a set of statements (i.e., command #2) to be executed when the widget labeled "Copy" is pressed. However, command #2 (Lines 2-4) only checks whether there is a text typed into the widget "output" to allow then command #1 be executed. So, command #2 works as a precondition to command #1, which is the command executed in reaction to that interaction. In this case, only the first one will be considered as a GUI command. These two cases are described in Algorithm 2 (Lines 17-21). Given a potential command, all its nested potential commands are gathered (Lines 15-16). The function getNestCmds analyses the commands by comparing their code line positions, statements, etc. So, if one command C contains other commands, they are marked as nested to C. Then, for each potential command and its nested ones: if the number of nested commands equals 1, the single nested command is ignored (Lines 18-19); if the number of nested commands is greater than 1, the root command is ignored (Line 21).

Good Practice

The analysis of Java Swing GUI listeners having a low CC reveals (see Section 4.2) what we consider as a good practice for developing GUI listeners. In most of the cases, this good practice consists of producing one command per listener (i.e.,m a n a g i n gone widget per listener). In some particular cases, several widgets can be managed by a single listener when a user interaction involves multiple widgets (e.g.,ad r a g -a n d -d r o p of an item from a list to another list). Because of features introduced in different Java versions, variants of this good practice exist as explained as follows.

Listeners as anonymous classes. Listing 4.11 is an example of this good practice. A listener, defined as an anonymous class (Lines 3-6), registers with one widget (Line 2). The methods of this listener are then implemented to define the command to perform when an event occurs. Since such listeners have to handle only one widget, if statements used to identify the involved widget are not more used, simplifying therefore the code.

GUI Design Smells: The Case of Blob Listener

Listeners as lambdas. Listing 4.12 illustrates the same code than Listing 4.11 but using Lambdas supported since Java 8. Lambdas simplify the implementation of anonymous class that have a single method to implement. With Lambdas, the header declaration of an anonymous class and of its unique method are not more required. The parameters of the unique method (here event, Line 10) are declared followed by an arrow pointing to instructions composing the body of the Lambdas (i.e., of the method). Note that only listeners composed of a single method can be written using Lambdas.

private void registerWidgetHandlers() { view.resetPageButton().addActionListener( e -> requestData(pageSize, null)); view.previousPageButton().addActionListener(e -> { if (hasPreviousBookmark()) requestData(pageSize, getPreviousBookmark()); }); //... } Listing 4.12: Same code than in Listing 4.11 but using Java 8 Lambdas Listeners as classes. In some cases, listeners have to manage different intertwined methods. This case notably appears when developers want to combine several listeners or methods of a single listener to develop a more complex user interaction. For example, Listing 4.13 is a code excerpt that describes a mouse listener where different methods are managed: mouseClicked (Line 3), mouseReleased (Line 8), and mouseEntered (Line 11). Data are shared among these methods (isDrag, Lines 4 and 9).

Towards a refactoring

A next step of our static analysis approach is to implement a behavior-preserving algorithm to automatically refactor the detected Blob listeners. In this section, we present

Towards a refactoring

Part III

Conclusion and Perspectives

Conclusion

GUI Design smells

In this thesis, we have characterized a GUI design smell: Blob listener . However, we believe that other GUI design smells may be identified from bad development practices. In Chapter 2, we have presented bug finders such as Findbugs and PMD Java tools. While these tools are widely used to detect bad programming practices and bugs in the Java source code, they do not focus on coding problems that affect the GUI source code. As a future work, we envision a set of checking rules, embedded in a tool similar to PMD, which automatically check for potential defects in GUI code at every project build. As an initial step in this direction, we have implemented in InspectorGuidget the automatic detection of simple bad coding practices that affect Java Swing code. The mere examples are presented below.

One bad practice we observed is the unsafe registration of listeners 1 . This problem occurs when a listener is registered in its constructor, for instance, by the code line "buttonA.registerListener(this)" in Listing 5.1 (Line 6). In such a case, the reference this is exposed to another thread before the constructor is finished. A failure may occur when that listener is used in its subclasses leading to a race condition. The following code depicts this case. When a subclass extends the class Listener, the call "super" must be the first statement in its constructor. In this case, the event listener (i.e., SubClass.actionPerformed()) could get called while the subclass fields (e.g., list) are not initialized yet. Another bad practice is several listeners with empty bodies. This practice is common in listener interfaces that require more than one method to be implemented (e.g., MouseListener interface requires five listener methods). This kind of methods allows empty bodies. However, a code with several empty method bodies is harder to read and maintain 2 . Furthermore, such flexibility may introduce unintended faults. For example, a listener is registered on a widget and none of its listener methods are implemented (e.g., all their bodies are empty or commented). Listing 5.2 gives an example of this practice observed in Jmol. All the three methods required by the MenuListener interface are not implemented: empty body (Line 10 and Line 12) or commented body (Line 7). In this case, an error may occur when a user interacts with that menu (i.e., processingMenu in Line 4). PMD detects unused private methods 3 , i.e., private methods with empty body, without any comment in their body. This rule, however, will not detect Java listeners with empty body since they are public methods.

Domain-specific mutants

A GUI code can by affected by different kinds of faults that we presented in our fault model. We have developed GUI mutants derived from our fault model using domainindependent mutation operators. GUI mutant operators, however, are domain-specific and thus may differ from one GUI toolkit to another. To develop Java Swing mutants, we have studied the behavior of GUI implementations in Java code. Thus, we designed manually the mapping between Java Swing mutants and the GUI faults in our fault model. For example, the creation of a standard and interactive widget in Java Swing is done by three basic operations:

We can refactor this Blob listener as lambdas supporting by Java 8 (recall 4.7.2 in Chapter 4) since its implementation has a single method, i.e., actionPerformed.I nt h i s case, the method actionPerformed and the identification of widgets that produced the event (used by GUI commands) are not required anymore (see Lines 2-8 and Lines 9-11). Thus, the two reported faults will be removed when the refactoring is done.

A future research on the refactoring of Blob listeners should first select which kinds of good practices will be applied and then provide the mechanisms to preserve the code's behavior. For instance, refactoring a Blob listener by producing one GUI command per listener (i.e., listener as anonymous class recall Chapter 4) should locate where the widget used in a GUI command is registered and handle its dependencies (e.g., shared attributes) within the Blob listener to perform the refactoring correctly. Thus, one challenge is to ensure that the refactoring approach will not introduce new GUI faults. To prevent this, the refactored software systems must be tested using non-regression GUI test suites generated from the original software systems. Another challenge is to ensure that the refactoring will not degrade the GUI code quality. So, we should compare the code quality of the original and refactored code by using some code quality metrics such as cyclomatic complexity, code duplication, code cohesion, or the correction of GUI faults in Blob listeners.

Appendix Beizer's Taxonomy

Beizer's taxonomy adapted by Brooks et al. [START_REF] Brooks | An initial characterization of industrial graphical user interface systems[END_REF] is presented in Table 5.1.