Soutenance mémoire
ÉTAT DE L’ART
Il existe un certain nombre d’outils servant à tester les applications web. Dans ce chapitre, nous classons les approches existantes en quatre grandes familles qu’on nomme successivement :
outils de tests, approches visuelles, approches déclaratives et outils RWD. Nous allons les exposer en donnant un peu plus de détails sur quelques outils relatifs à chaque famille d’approches. Enfin, nous citons leurs points faibles en montrant leurs limites dans certains cas.
OUTILS DE TEST
La détection de bugs d’interface peut d’abord être abordée comme un problème de test logiciel classique. Sous cet angle, il se veut une généralisation des fonctionnalités offertes par des logiciels d’analyse de sites web comme Google Analytics 1 ou Piwik 2. Ces outils suivent les requêtes HTTP et fournissent un tableau de bord pour analyser des données de base : pays d’origine, durée d’une session, etc. Cependant, ces outils ne gèrent généralement pas Ajax, ne peuvent pas être utilisés comme outils de test (ils n’évaluent pas les conditions sur le contenude la page par exemple) et ne signalent rien sur le contenu de la page, sur les actions de l’utilisateur ou les requêtes Ajax.
Les logiciels de test en ligne tels que Capybara, Selenium WebDriver, Watij ou Sahi sont plus proches de nos objectifs. Ces outils fournissent différents langages pour décrire les tests et écrire des assertions sur l’application. Les scripts WebDriver sont écrits en Java ; Capybara a sa propre API 3 dans le langage Ruby ; Watij utilise WebSpec, 4 qui est une API définie par-dessus Java (3.5 donne un exemple de test webspec-watij) ; et Sahi utilise SahiScript, une extension de JavaScript. 5 Tous ces langages sont impératifs (c’est-à-dire procéduraux) et visent à piloter une application en effectuant des actions. La partie test se réduit à l’insertion d’instructions similaires à assert dans le code du script. A titre d’exemple, la figure 3.1 donne un extrait de code Java pour Selenium WebDriver pour vérifier que tous les éléments satisfaisant un sélecteur CSS sont à gauche.
CAPYBARA
Capybara est un framework d’automatisation Web utilisé pour créer des tests fonctionnels qui simulent l’interaction des utilisateurs à une application. Il constitue une bibliothèque conçue pour être utilisée sur un pilote Web sous-jacent (underlying web driver) tels que selenium-web driver, rack test driver ou capybara-webkit. Il fournit un DSL (Domain Specific Language) servant à décrire les actions exécutées par ces pilotes Web [30] Une fois la page est chargée via le DSL et le pilote Web sous-jacent, Capybara essayera de localiser l’élément pertinent dans le DOM (Document Object Model) et exécutera une action, du genre : clics de boutons, de liens, etc. Son DSL déployé pour exprimer les actions à exécuter est très intuitif. la figure 3.2 montre quelques unes de ses commandes de base. Dans le but de trouver un élément[30], Capybara, par l’intermédiaire du DSL, cherchera dans le DOM, les attributs suivants :
— Champ de texte (fill_in) : id, name, élément d’étiquette associé (label).
— Cliquez sur un lien/bouton (click_link/ click_button) : id, titre, texte dans la balise, valeur.
— Case à cocher/bouton radio/liste déroulante (check/ uncheck/ choose/ select) : id, nom, élément d’étiquette associé (label).
— Télécharger le fichier (attach_file) : id, nom.
WATIJ
Watij ou Web Application Testing en Java est un projet de test, implémenté en Java, destiné à automatiser les tests fonctionnels des applications Web au-dessus de IE (Internet Explorer). Il est basé sur la conception de Watir [33] et possède une capacité de recherche d’éléments lui permettant de trouver, d’accéder et de contrôler facilement n’importe quel élément HTML à travers le DOM en mobilisant l’interface COM. Il prend en charge, d’autre part, les expressions XPath pour trouver les éléments HTML sur une page et gère les pop-up (fenêtres contextuel du navigateur) en les interceptant et les rendant disponibles pour l’interaction. Watij peut détecter la fin du chargement d’une page en cours de chargement.Watij dispose d’un ensemble relativement riche d’API pour l’écriture de scripts de simulation. La connexion à un site Web exige à chaque fois, des informations tel que le nom de l’utilisateur et le mot de passe (page de connexion (login) de Yahoo figure 3.4). Les tâches manuelles demandées, dans ce cas, à l’utilisateur sont les suivantes :
1. Afficher une fenêtre de navigateur ;
2. Mettre l’URL correcte pour ouvrir cette page ;
3. Attendre que la page se charge et se stabilise ;
4. Taper le nom d’utilisateur dans le champ ID ;
5. Taper le mot de passe ;
6. Cliquer sur le bouton Connexion.
Le code approprié pour automatiser les tests fonctionnels de ces étapes, en utilisant Watij, est donné dans la figure 3.3.
SAHI
Sahi est un outil open source d’automatisation et de test d’applications web. En tant qu’outil d’automatisation, Sahi offre la possibilité d’enregistrer et de lire des scripts. Il prend en charge Java et JavaScript. Même si SahiScript ressemble à JavaScript, il n’est pas exécuté comme le JavaScript normal dans le navigateur. L’idée de base du fonctionnement de Sahi est décrite
ci-dessous : les parties centrales de Sahi montrés dans la figure 3.7 incluent le serveur proxy Sahi et le moteur JavaScript. Les réponses HTML qui transitent par le proxy sont modifiées de telle sorte que JavaScript soit injecté au début et à la fin de la réponse. Cela permettra au navigateur d’enregistrer et de lire les scripts et de communiquer avec le proxy en cas de besoin. En plus de la gestion des demandes de pages du navigateur, Sahi gère également les commandes personnalisées liées à l’enregistrement, à la lecture, etc ; envoyées par celui-ci.
Les fonctionnalités propres de Sahi, font de lui un bon support des fichiers de base de données,
supportant JavaScript, AJAX ainsi que les API simples, Outre ses fonctionnalités normales, à l’égard de la prise en charge de « ant »(l’outil logiciel). Du fait que ses API ne dépendent pas beaucoup de la structure HTML, le contrôleur Sahi (IDE) peut être utilisé dans différents navigateurs. Sahi qui n’utilise pas XPath, renferme des API tels que : _ near, _in, etc, l’aidant à trouver un élément par rapport à un autre. « SahiScript » est fondé sur JavaScript.
Il est analysé par Sahi et exécuté par le moteur JavaScript rhino. La figure 3.6 illustre un exemple de constructions (exemple d’écriture de conditions) dans Sahi. Elles sont identiques à JavaScript hormis le $ obligatoire utilisé dans les variables.
De plus, tous les outils mentionnés ci-dessus (à l’exception de Sahi) nécessitent un plugin spécifique au navigateur pour fonctionner, et ne supportent donc qu’une poignée de navigateurs, en général les « Big Five » (Firefox, Safari, IE, Opera et Chrome). Cependant, la part de marché des navigateurs autres que ceux-ci équivaut à 20%, et s’élève à 63% pour les appareils autres que les ordinateurs de bureau (tablettes, consoles et mobiles). 6. En dehors de Sahi, ces outils de test n’atteignent pas plus des trois quarts du marché, et pour certains, seulement 25% pour les appareils autres que les ordinateurs de bureau. Par conséquent, l’affirmation selon laquelle « la plupart des utilisateurs » sont pris en charge par eux est à peu près non fondée.
APPROCHE VISUELLE
Pour déceler les défauts dans la mise en page, l’outil principal déployé par ce genre de techniques est généralement la vision par ordinateur. Ces dernières consistent entre autres, en la délimitation des bordures des éléments par la détection des contours et en la découverte des changements par le calcul de la différence entre deux captures d’écran dont les couleurs du texte des arrière-plans seront comparées pour repérer le texte illisible. Au lieu d’agir sur des informations spécifiques à la mise en page, telles que la taille et la position des éléments, ces techniques sont basées sur la comparaison des captures d’écran, pixel par pixel. Dans ce cas, les erreurs sous la forme d’une capture d’écran sont signalées et clairement marquées.
WEBSEE
Certains travaux ont également été réalisés sur l’utilisation des techniques d’analyse d’image pour identifier les problèmes de mise en page [69]. WebSee [58] est en particulier, un outil implémenté en Java qui utilise plusieurs bibliothèques tierces pour implémenter certains des algorithmes spécialisés. Il applique des techniques du domaine de la vision par ordinateur pour analyser la représentation visuelle des pages Web pour détecter automatiquement et localiser les échecs de présentation. WebSee identifie les échecs de présentation, puis détermine les éléments dans la source HTML de la page qui pourraient être responsables des échecs observés en comparant la représentation visuelle de la page Web rendue sous test et son apparence d’origine (oracle).
A cette fin, WebSee prend en entrée le code HTML/CSS de la page à analyser et un oracle (une image) du rendu attendu de la page. Un ensemble de différences entre la page rendue et l’image de référence est calculé, et ces différences sont ensuite regroupées en groupes susceptibles de représenter différents défauts sous-jacents dans la page. Une deuxième phase de traitement tente d’identifier les éléments HTML correspondant aux pixels de différence, qui sont ensuite ordonnés par une métrique de priorité et envoyés à l’utilisateur. La figure 3.8 montre les différentes phases de l’approche : La première entrée est la page web (P) qui devrait être analysé pour déterminer les défaillances de présentation. La forme de P est une URL qui pointe vers soit un emplacement sur le réseau ou d’un système de fichiers où tous les fichiers HTML, CSS, JavaScript, et les fichiers médias de P sont accessibles.
La deuxième entrée est l’oracle (O) qui spécifie les propriétés d’exactitude visuels de P. La forme de O est une image qui peut être soit une maquette ou une capture d’écran d’une version correcte de P.
PHANTOMCSS
PhantomCSS [20] est un framework de test d’interface graphique open source qui possède la capacité de situer les changements d’une itération à une autre par des algorithmes différant sur deux images. D’autre part, il permet d’exclure certaines parties de l’interface graphique du test. Les pages Web susceptibles d’afficher des données non contrôlées par le développeur et des éléments tels que des annonces Web, des données utilisateur, des bannières animées, des images et du texte, trouvent dans ces caractéristiques un instrument bénéfique. Le développeur dans ce cas est obligé de spécifier manuellement les parties de l’interface graphique non concernées par les tests en nommant l’élément en question, ou le spécifiant ses coordonnées x et y.
SIKULI
Un autre framework d’automatisation est Sikuli [39], qui identifie et manipule les contrôles de l’interface graphique dans une page web en utilisant la recherche par image (sub-image searching). Les captures d’écran constituent la base de cette approche visuelle pour la recherche et l’automatisation des interfaces utilisateurs. Elle permet aux utilisateurs :
— de prendre une capture d’écran d’un élément de l’interface graphique (comme un bouton de la barre d’outils, une icône ou une boîte de dialogue) ;
— d’interroger un système d’aide en faisant appel à la capture d’écran au lieu du nom de l’élément;
— de fournir également une API de script visuel pour automatiser les interactions de l’interface graphique, par l’intermédiaire des modèles de capture d’écran pour diriger les événements de la souris et du clavier.
Dans l’exemple montré dans la figure 3.11, le bouton de fermeture doit effacer le contenu de la zone de texte ainsi que lui-même. Supposons que l’interface graphique soit déjà dans un état qui contient un « 5 », au début nous trouvons la zone de texte bleue sur l’écran et stockons la région correspondante qui a la plus grande similarité dans la zone bleue. Ensuite, après avoir cliqué sur le bouton de fermeture, deux assert Not Exist sont utilisés pour vérifier la disparition dans la zone bleue [39].
APPLITOOLS
La segmentation pure de l’image des pages Web et la comparaison visuelle pixel par pixel sont à l’origine de l’outil commercialisé AppliTools Eyes [2], qui offre une interaction des scripts de test crées par l’utilisateur et son application. Dans cet outil, le serveur Web est chargé de télécharger les captures d’écran en appliquant un algorithme de différence d’image entre lui et une capture d’écran précédente. La différence entre les deux images est traduite par AppliTools par une détection des régressions dans une mise en page GUI. Ces changements dans une interface Web sont exploités par le développeur pour actualiser l’image de base dans le cas où le changement était intentionnel.
Cependant, cette approche est orientée vers la détection de bugs de type statique de chevauchement ou de débordement des éléments dans un document, et actuellement ne supporte pas la vérification de modèles temporels à travers plusieurs instantanés de la même page. De plus, l’approche génère beaucoup de faux positifs si la page rendue contient du texte légèrement différent de l’image de référence. C’est le cas lorsque, par exemple, la fenêtre du navigateur a des dimensions différentes et que le texte s’écoule différemment (mais pas nécessairement incorrectement) par rapport à l’image. Pour résoudre ce problème, l’utilisateur doit définir manuellement, pour chaque oracle, ce que l’on appelle des régions dynamiques qui devraient être ignorées par le système lors de l’analyse de la page.
APPROCHE DÉCLARATIVE
Les techniques dans cette dernière famille fonctionnent directement sur des informations sur la mise en page. Elles peuvent obtenir des informations sur les éléments (position, largeur et hauteur) impliqués dans l’interface graphique, que ce soit par analyse d’image ou par « siphonnage » (scraping) de l’interface graphique. C’est d’ailleurs ce que ces techniques ont en commun. La manière de relier les différents éléments de mise en page les uns aux autres ainsi que les valeurs de leurs paramètres de mise en page sont indiqués par les entrées de ces approches, qui ne sont pas tant un script que des documents déclaratifs.
Les assertions opérées sur l’interface graphique peuvent par exemple être de la forme « l’élément 1 est-il situé à gauche de l’élément 2 ? » ou « l’élément 1 a-t-il une largeur inférieure à l’élément 2 ? ». Certaines de ces techniques ont des langages spécialisés décrivant des assertions comme celles-ci.
Les spécifications déclaratives des interfaces utilisateurs ont fait l’objet de beaucoup de recherches dans le passé. Les premières tentatives incluent le système MASTERMIND, qui utilise un langage de modélisation basé sur CORBA [67] ; d’autres approches incluent le modèle de mise en page d’Auckland [57], Adobe Adam et Eve [66] et les modèles de propriétés [57].
MASTERMIND
Dans MASTERMIND, le développeur de l’interface utilisateur doit créer des modèles de tâche (task model), d’application (domaine) et de présentation. Le modèle d’application est spécifié à l’aide du langage de définition d’interface CORBA (IDL). Le modèle de tâche présente les tâches de l’utilisateur final dans une structure hiérarchique et comporte les informations de commande nécessaires pour contrôler l’interface utilisateur lors de l’exécution. Le modèle de présentation décrit la disposition de l’interface utilisateur, y compris les affichages statiques et dynamiques. Il permet la spécification des mises à jour automatiques de présentation lorsque les données d’application ou le contexte de présentation changent. En outre, il intègre des principes de conception graphique afin de donner un soutien complet au concepteur de dialogue.
AUCKLAND LAYOUT MODEL (ALM)
Le modèle de mise en page d’Auckland (ALM) est une technique implémenté pour « .NET », Java et Haiku, permettant de spécifier une mise en page 2D. Elle est utilisée pour organiser les contrôles dans une interface graphique. Le modèle permet la spécification de contraintes basées sur l’algèbre linéaire. Il calcule une disposition optimale en utilisant la programmation linéaire.
Les égalités et les inégalités linéaires peuvent être spécifiées sur les tabulations horizontales et verticales, qui sont des lignes virtuelles formant une grille dans laquelle tous les éléments de l’interface graphique sont alignés [57]
L’exemple dans la figure 3.12 montre, la manière de disposer trois boutons en mobilisant trois zones. Les boutons ont déjà été ajoutés à la fenêtre, mais ils n’ont pas été arrangés. Leur emplacement et leur taille sont déterminés par la spécification ALM (figure 3.13). Quelque soit le redimensionnement de la fenêtre, les deux colonnes auront toujours la même largeur, et les deux lignes la même hauteur en raison de la linéarité des deux contraintes.
ADOBE ADAM ET EVE
ASL (Adobe Source Libraries) est un projet au sein du Adobe Software Technology Lab (STLab). C’est un ensemble de bibliothèques de composants logiciels, rendu disponible sous licence Open Source par Adobe Systems, permettant de définir des algorithmes sous forme déclarative. Les deux premières bibliothèques significatives dans ASL sont : la bibliothèque de modèle de propriétés (Adam) et la bibliothèque de modèle de mise en page (Eve) dont les composants permettent de modéliser l’apparence et le comportement d’une interface dans une application logicielle. Adam consiste en un solveur et un langage déclaratif pour décrire les contraintes et les relations sur une collection de valeurs qui sont généralement les paramètres d’une commande d’application (une fonction). Adam fournit la logique qui contrôle le comportement d’une interface Humaine (IH). Il est similaire dans son concept à une feuille de calcul ou à un gestionnaire de formulaires. Les valeurs sont définies et les valeurs dépendantes sont recalculées. Adam procure des fonctionnalités pour résoudre les valeurs interdépendantes, mais il ne constitue pas un système de contrainte général. Eve consiste en un solveur et un langage déclaratif pour la construction d’une IH. Le solveur de mise en page prend en compte une description riche des éléments de 14 interfaces pour obtenir une disposition de haute qualité rivalisant avec ce qui peut être réalisé avec le placement manuel.
Une seule description suffit pour plusieurs plateformes et langages OS. Eve a été développée pour fonctionner avec Adam ; il peut cependant aussi, être utilisée seule. Adam et Eve peuvent être intégrées dans un certain nombre d’environnements. Ils ont la faculté de fonctionner ensemble, ou indépendamment, mais, ils doivent être combinés avec d’autres installations pour construire une application. Parmi les exemples typiques d’interfaces utilisateur effectuant la synthèse de paramètres de commande : la boîte de dialogue « Enregistrer sous » dans le cas d’enregistrement d’un fichier image (figure 3.14). Elle se compose d’un champ de texte pour entrer le nom du fichier, un menu de types de fichiers et des curseurs offrant deux possibilités pour configurer la compression lors de l’enregistrement dans un format qui le prend en charge.
Les valeurs des curseurs sont liées par une relation exprimant le compromis entre le taux de compression et la qualité de l’image.
|
Table des matières
Introduction
1 Notions générales sur le web
1.1 Le fonctionnement du web
1.2 Le langage HTML
1.3 Les Cascading StyleSheets (CSS)
1.4 JavaScript
1.5 Le fonctionnement interne des navigateurs web
2 Les bugs d’interface dans les applications web
2.1 Types d’applications web
2.2 Types de bugs d’interface
3 État de l’art
3.1 Outils de test
3.2 Approche visuelle
3.3 Approche déclarative
3.4 Outils RWD
3.5 Discussion sur les approches exisantes
4 Détection de bugs d’interface
4.1 Un interpréteur pour les propriétés Cornipickle
4.2 Le langage Cornipickle .
4.3 Exprimer des propriétés avec Cornipickle
5 Détection avancée : bugs comportementaux et RWD
5.1 Bugs comportementaux dans le Beep Store
5.2 Solutions actuelles
5.3 Solution proposée
5.4 Expériences et résultats
6 Vers un meilleur feedback pour l’utilisateur
6.1 Génération de contre-exemple : les témoins
6.2 Localisation des erreurs dans les applications web
6.3 Calcul de la réparation
6.4 Exemples
7 Conclusion générale
Bibliographie
