Software As A Service

WEBMATE

L’article de Dallmeier et al. (2012) part du constat qu’il est long et délicat de maintenir une suite de test, ce serait même la raison principale pour laquelle relativement peu de compagnies testent leurs solutions extensivement. L’objectif annoncé de WebMate est de réparer cet état de fait, de rendre le test automatique d’applications web 2.0 efficace et simple.
L’application contrôle un navigateur sans tête : PhantomJS, basé sur l’interpréteur WebKit. WebMate base son identification des états d’application sur le contenu du DOM, non pas sur les URL, et permet donc de naviguer dans des applications type web 2.0.
Afin de détecter les éléments qui sont susceptibles de changer l’état du DOM,WebMate se base sur les fonctionnalités des librairies jQuery et Prototype. WebMate implémente une couche d’abstraction sur le DOM, afin d’optimiser le parcours de l’application, tout en détectant les différentes actions qui pourraient amener aux mêmes états de l’application, afin d’optimiser la taille du graphe de parcours.

Grâce à PhantomJS, WebMate permet de réaliser de tests « Cross Browser » 1. Pour ce faire, WebMate utilise une approche comparative : un navigateur est défini comme base fonctionnelle, et tous les comportements changeants de cette base valide seront considérés comme anormaux.

Tester l’uniformité du site sous différents navigateurs

SAAS 2. On constate que leur logiciel s’est concentré test d’interface, et à abandonné la possibilité des tests personnalisés. Comme nous le voyons dans la figure 3.1, WebMate a pris une orientation un peu différente, se spécialisant dans la comparaison d’impressions écrans prises avec différents navigateurs. WebMate met ensuite en valeur les différences visuelles entre les images récupérées, afin de permettre à l’utilisateur d’avoir une meilleure vision des potentiels problèmes d’affichages de son application web.

Hélas, depuis le début de l’écriture de notre travail, le projet Webmate est tombé à l’eau. En effet, plus aucune trace du projet n’est disponible en ligne, et leur nom de domaine a été libéré.
La direction prise par le projet ne leur a probablement pas permis de perdurer dans le domaine professionnel commercial.

Software As A Service

CRAWLJAX

Le constat de base de l’article de Mesbah et al. (2012) est que les applications AJAX sont difficiles à tester. Leur objectif annoncé est de rendre possible le test automatisé d’applications AJAX. Pour ce faire, ils se basent sur leur outil présenté dans leurs publications précédentes Mesbah et al. (2008) Mesbah et van Deursen (2009) : Crawljax. Crawljax est un crawleur spécialisé dans l’analyse d’applications AJAX.

Crawljax permet de crawler un site complet et de réaliser un « web State Machine», c’està- dire une représentation sous forme de graphe du crawl réalisé. L’outil permet également de visualiser ce State Machine, comme illustré dans la figure 3.2, où nous voyons le graphe d’exploration interactif.
En interne, les liens entre les noeuds du graphe sont représentés par une combinaison d’élément du DOM via leur sélecteur XPATH et d’une action utilisateur. L’outil possède une liste d’éléments suspectés d’être cliquables grâce à AJAX (a, div, input, img, accompagnés par les personnalisations de l’utilisateur). Les actions les plus courantes (click, hover, double click, etc.) sont lancées sur ces éléments, avec une vérification de changement d’état du DOM.
L’article insiste sur de nombreux détails d’implémentation technique du crawleur, confirmant leur volonté de créer un logiciel de référence dans le domaine.
L’auteur se penche sur l’analyse de site par « invariant ». Un invariant est une valeur censée valoir « true » durant toute l’exécution du programme. En langage de test, c’est comparable à une assertion. L’analyse d’états AJAX par invariant revient donc à exécuter des tests et à vérifier leur valeur retour.

Quelques exemples de tests applicables au DOM sont donnés : validation du DOM, nonprésence de messages d’erreur (500, 404), accessibilité, etc. L’article décrit également la possibilité d’écrire ses propres invariants en conditions XPath, Java ou JavaScript. Il est également possible d’effectuer des tests sur la formation de l’URL, ou de vérifier la visibilité d’éléments du DOM.
Il est également possible d’appliquer des invariants au « web State Machine », par exemple : vérifier l’absence de liens morts (code 404), la consistance du bouton retour (en particulier dans les applications AJAX), etc. Ici aussi, il est possible d’ajouter des tests personnalisés.

Le logiciel est très ouvert et permet de vraiment personnaliser le comportement du crawleur et des tests via un système de plug-ins complet. L’intégration continue semble avoir été développée, mais la page n’est plus disponible en ligne, ce qui ne nous permettra pas de juger du développement de cette fonctionnalité à l’heure actuelle.

WEBMOLE

L’article de Le Breton et al. (2013) présente leur outil Webmole. Webmole est un crawler d’applications AJAX fonctionnant dans un navigateur web. Webmole utilise un système « d’Oracles » pour évaluer des conditions écrites en JavaScript par l’utilisateur. Les Oracles sont des fonctions prenant en argument un état du DOM, et retournant vrai ou faux. Les Oracles permettant de manipuler l’exploration du robot de façon précise et personnalisée. Webmole est un outil open source au code disponible depuis la publication de l’article. L’installation se fait au moyen de machine virtuelle. Cela demande quelques connaissances, mais tout développeur PHP devrait pouvoir en venir à bout. Les Oracles sont entièrement personnalisables et permettent même de contrôler l’évolution du crawleur dans le site. L’intégration continue n’est pas disponible et ne semble pas être une direction retenue pour le développement de l’application.

Au lancement, Webmole propose deux modes d’exploration : manuel et automatique. L’exploration manuelle permettra à l’utilisateur d’aller cibler les pages désirées de façon précise, mais relativement lente (vitesse de navigation humaine). Le mode automatique réalisera un crawl complet de l’application ciblée. Avant de lancer l’exploration, l’utilisateur peut définir des conditions en JavaScript, à l’aide d’un éditeur embarqué, afin de marquer certaines pages, ou encore stopper l’exploration.

L’application parcourt ensuite le site visé en direct, et affiche les résultats à l’écran, ainsi qu’une légende du code couleur utilisé, comme nous le voyons dans la figure suivante.

À noter que les conditions JavaScript, ici appelées Oracles, sont là afin de permettre à l’utilisateur de créer un filtre de navigation. Leur but est de guider le crawler dans son exploration du site, non pas de créer une série de tests à rouler sur le site (bien qu’a priori, cela puisse indirectement être réalisable).

REGRESSION TESTING

L’article Raina et Agarwal (2013) met en oeuvre une suite logicielle spécifiquement créée pour conduire des tests de régression. L’outil intègre un crawler web 1.0, donc sans support des applications AJAX. Il compare ensuite le contenu du DOM de chaque crawl, pour mettre en avant les modifications du contenu de la page.
Les auteurs mettent à l’épreuve leur outil sur le CMS WordPress, et font remonter avec succès les modifications de page détectées.
Les auteurs ne donnent aucun accès à leur code source ou bien à une version téléchargeable de l’application. Il nous est donc impossible de détailler le fonctionnement de l’outil développé.

A priori, cette solution ne permet pas la personnalisation de tests, seulement la comparaison entre deux pages HTML. D’ailleurs, il est notable que l’outil ne mette pas en avant les bugs, ou ne réponde à aucune réelle assertion, mais permette juste de détecter les changements HTML d’une page. Cela limite grandement l’utilisation de l’outil dans le cadre d’un processus de test personnalisé et adapté à une logique métier précise.

AUTOMATED SYSTEM TESTING

L’article de Tanida et al. (2013) se base sur l’outil déjà présenté Crawljax, qu’il améliore du point de vue des tests de conformité de modèles. L’outil permet de valider des contraintes de navigation sur le « State Transition Graph » 3 obtenu par le crawleur.

L’objectif principal est donc de valider les séquences de navigation, les liens, entre les états d’une application web 2.0.

Par exemple, l’outil pourrait permettre de vérifier que toutes les pages sont accessibles à partir d’interactions, ou bien que l’accueil soit accessible depuis tous les écrans. Une proposition de langage de description de séquences de navigation est faite dans l’article.

L’outil proposé tient en deux temps : une extension Crawljax nommée « GuidedCrawl » et un validateur de modèle de navigation. L’extension permet ajouter à Crawljax la possibilité d’avoir des suites d’actions définies par l’utilisateur qui prendront le dessus sur le crawl automatique afin de pouvoir valider des comportements spécifiques propres à certaines applications. Le second outil, Goliath, quant à lui, est spécialisé dans la validation des données sorties par Crawljax au regard de modèles définis par l’utilisateur.
Des exemples d’utilisation de leur application sont ensuite proposés, afin de valider leur approche.

L’implémentation du modèle proposé est faite en deux temps : une amélioration de l’outil existant Crawljax par le biais d’un plug-in, et la livraison d’un second outil : Goliath, l’outil de vérification de conformité. Leur outil bénéficie donc d’un environnement stable et éprouvé (Crawljax), ce qui permet de ne pas réinventer la roue et de bénéficier des avancées de ce premier. À noter que leur champ de test est spécialisé et ne rend pas Crawljax plus ouvert, mais lui permet d’exceller dans un domaine précis : la vérification de contraintes de navigation.

LEVERAGING EXISTING TESTS

L’article de Milani Fard et al. (2014) propose une approche différente de tous les autres papiers ici retenus. En effet, partant du principe que les tests dits “scénarisés” 4 sont de bonne qualité et démontrent une connaissance réelle de l’application testée, les auteurs proposent une méthode pour récupérer cette connaissance de l’information afin de la coupler à la puissance d’un crawler. Le crawleur est amélioré par les informations récupérées dans les tests manuels, ce qui permet au final d’améliorer considérablement la couverture d’application permise par le 4. Ici, l’auteur parle principalement des tests réalisés avec la suite Sélénium crawleur simple.

Dans un premier temps, il est nécessaire d’analyser les tests manuels existants afin d’en extraire la connaissance de l’application. Pour ce faire, les interactions réalisées avec le DOM de chaque test sont utilisées pour établir un « state transition graph » (STG)temporaire. Le STG temporaire est soumis à Crawljax comme base pour explorer l’application et découvrir les chemins alternatifs.
Les assertions manuelles sont utilisées pour détecter les fonctionnalités importantes et récurrentes à tester. Chaque test portant sur un élément générique du template (bannière, etc.) sera répété sur tous les états de l’application. En même temps, des mécanismes sont mis en place pour éviter de générer trop d’assertions inutilement, qui rendraient la tâche de maintenir les tests trop délicate.
L’outil proposé est disponible 5 sous licence open source. Testilizer est présenté sous la forme d’un plug-in Crawljax. Encore une fois, on remarque que Crawljax est utilisée comme base solide pour faciliter la suite d’un travail reposant sur le besoin de crawler un site. Testilizer permet d’améliorer la génération de tests à partir d’une suite déjà établie, sans empêcher de personnaliser par la suite les tests existants.

JAEK

L’article de Pellegrino et al. (2015) remet en cause l’efficacité des solutions de crawl actuelles.

Il se positionne en nouveauté dans la méthodologie de crawl d’applications 2.0 grâce à une méthode de redéfinition des fonctions de base de JavaScript.

En redéfinissant la fonction addEvenListener, nerf de la guerre pour détecter les éléments déclenchant un changement d’état, Jaek ne risque donc pas de manquer de lien vers les nouveaux états de l’application. Là où tous les autres crawlers tâtonnaient en essayant de repérer de façon arbitraire les événements de chaque application JavaScript, Jaek impose une nouvelle méthodologie puissante.

Cette analyse d’exécution de l’application est utilisée pour rendre le crawleur attentif à tous les comportements de l’application.

Pendant la période de crawl, Jaek maintient un graphe de navigation complet, lui permettant de prendre en compte l’état complet de l’application à chaque changement d’état, afin de mieux décider vers quelles directions crawler.
Il s’avère qu’en comparant les résultats aux autres outils existants, Jaek repousse les limites de l’état de l’art des crawlers actuel en termes de couverture d’états (2502 états découverts sur 13 applications, contre 142 pour Crawljax, pour ne citer que lui).

Cet outil est disponible 6 sous licence GPL 3. Jaek demande à être implémenté sous forme de programme pour être fonctionnel. En effet on constate qu’en soi, Jaek n’est pas capable de gérer l’exécution de tests d’aucune manière que ce soit. Il va de soi que l’intégration continue n’est pas mise en place étant donné qu’aucun test n’est utilisable via Jaek. L’outil ne correspond donc pas vraiment à nos attentes en matière de test logiciel, mais reste une base extrêmement prometteuse en matière de crawl d’application web 2.0.

DISCUSSION

Littérature existante Les articles analysés sont triés par ordre de publication : du plus ancien au plus récent. On constate une réelle évolution dans le domaine au fil de la lecture. On passe d’un sujet relativement neuf et simplement compréhensible à des articles scientifiques longs, poussés, et de plus en plus complexes. Des termes spécifiques font surface, une réelle littérature se met en place, et les logiciels sont de plus en plus performants.

On constate que Crawljax est clairement l’outil le plus avancé dans son domaine et le plus souple, grâce à son système de plug-in. Pour autant, depuis son apparition, Crawjax ne semble pas avoir particulièrement percé dans le domaine du test d’applications de l’industrie. On constate également que Crawljax n’a reçu aucune mise à jour depuis fin 2015, et a récemment été surpassé en termes de couverture d’application par le nouveau crawler Jaek. Codé en Python, ce dernier semble être le meilleur candidat comme base de crawl pour un outil répondant aux besoins de l’industrie. Afin de s’assurer de ce statut de leader, il serait judicieux de faire passer à Jaek le protocole de test de Hallé et al. (2014). En effet, leur protocole de test est transposable aux crawlers modernes, sans limitation de technologie ou d’implémentation.

Le modèle théorique proposé dans l’article de Deyab et Atan (2015) semble, quant à lui, être prometteur et proposer un environnement assez complet pour être utile et adoptable par l’industrie. Bien que quelques concepts définis par les auteurs semblent trop détaillés et risquent de ne pas laisser la liberté nécessaire aux acteurs de l’implémentation du modèle, la base théorique reste solide et réfléchie.

Il serait judicieux d’adapter et de généraliser leur modèle afin de permettre un travail d’implémentation plus libre et plus souple. Des concepts non évoqués dans l’article pourraient également être ajoutés, par exemple l’intégration continue.

Pistes Si le domaine du test d’application web par crawler a beaucoup évolué en cinq ans, on peut toutefois constater que l’état de l’art n’est pas rendu à un stade d’exploitation industrielle.

En effet, les logiciels proposés ne semblent pas avoir percé hors du monde académique. En ce décembre 2016, la recherche “crawljax”, logiciel le plus populaire du domaine étudié, sur Google retourne moins de 7 500 résultats Google (2016). Selon nous, la prochaine étape dans le domaine est l’élaboration d’un modèle théorique global basé sur le travail de Deyab et Atan (2015). En effet, le modèle actuel peut être améliorable sur plusieurs points :

ORCHESTRATION FRAMEWORK : UNE BASE DE TRAVAIL

La publication de Deyab et Atan (2015) est utilisée comme base théorique pour le développement de notre nouveau travail. Toutefois, comme nous allons le voir, nous n’avons pas gardé l’intégralité de leur approche. Ce chapitre présente notre approche de leur modèle, afin d’introduire notre implémentation finale.

L’HÉRITAGE

Quels sont les concepts pertinents à garder ?

Crawler web Le crawler web est une brique essentielle sur laquelle va reposer notre projet.

C’est lui qui va nous permettre de récupérer l’ensemble du site, et donc d’avoir la matière même sur laquelle faire travailler nos tests. Le crawler devrait être capable de parcourir à la fois des sites web classiques, mais également des applications web 2.0 et modernes, afin de permettre de tester toute la diversité du web actuel. Il est donc primordial que nous puissions récupérer l’état du DOM des pages après chaque interaction du crawler avec le JavaScript.

Notre crawler devra être un composant totalement indépendant du reste de l’application, afin de respecter l’architecture modulaire voulue, permettant à Cowtest de ne pas être lié de façon définitive au crawler implémenté. Nous ne nous concentrerons toutefois pas sur la programmation du crawler web, domaine complexe et spécialisé s’il en est. Cowtest sera capable, dans un premier temps, de travailler avec une liste d’url en entrée. En plus de respecter l’architecture modulaire visée, cela nous permettra de nous concentrer sur la logique métier du test running, tout en laissant le champ ouvert à l’intégration par après d’un crawler moderne et approprié.

Il est important de noter que nous devrons programmer un moyen standardisé de communiquer entre le crawler et Cowtest. En effet, l’objectif est de pouvoir interchanger le crawler à l’avenir.

Non pas d’une façon complètement transparente “plug-and-play”, il faudra obligatoirement faire des adaptations du code, mais nous souhaitons garder cette étape d’adaptation la plus simple possible. Il s’agira donc très probablement d’écrire une interface logicielle à respecter pour adapter le fonctionnement du crawler à Cowtest.

Test Runner Une suite de test n’est rien sans un test runner approprié. Le test runner est chargé de faire le lien entre les tests écrits et le code à tester. C’est également le test runner qui va être chargé de gérer le parallélisme des tests, la gestion mémoire, la remontée des diagnostics de tests, etc.
Dans notre cas, le test runner est la librairie qui va lancer les tests à proprement parler. Cette librairie sera choisie par l’utilisateur, et retournera ses informations à Cowtest. Étant donné que le choix de la librairie est laissé à l’utilisateur, il est impératif de développer un moyen standard de communiquer. C’est par le biais du concept des “connecteurs” que nous arriverons à éclaircir cette communication, comme nous allons le voir dans les paragraphes suivants.

Table des matières

1 Introduction : du besoin à l’outil Cowtest 
1.1 Question de recherche
1.2 Difficultés et verrous
1.3 Objectifs
1.4 Plan
I État de l’art
2 Concepts 
2.1 Technologies Web
2.2 Testing
2.3 Généralités
3 Littérature 
3.1 WebMate
3.2 Crawljax
3.3 Webmole
3.4 Regression testing
3.5 Automated System Testing
3.6 Leveraging existing tests
3.7 Jaek
3.8 Orchestration
3.9 Résumé et analyse
3.10 Discussion
II Modèle théorique
4 Orchestration Framework : une base de travail 
4.1 L’héritage
4.2 Les parties laissées de côté
5 Cowtest : Les apports 
5.1 Nouveau concept : les connecteurs
5.2 Abstraction du modèle théorique
5.3 Dépendances simples, modularité forte
5.4 Schématisation du modèle théorique
III Implémentation 
6 Conception 
6.1 Cas d’utilisation
6.2 Du modèle théorique à la conception logicielle
7 Choix technologiques 
7.1 Langage
7.2 Données et stockage
7.3 Modularité du code
7.4 Difficultés rencontrées
8 L’outil 
8.1 Interface
8.2 Exemple d’utilisation
8.3 Fonctionnalités non implémentées
8.4 Futur du développement
9 Conclusion : au-delà de Cowtest, prise de recul et ouverture
9.1 Chemin parcouru
9.2 Cowtest : limites et visions
9.3 Traitement automatisé d’une application AJAX : domaine complexe et problème ouvert
9.4 Retours sur les objetifs
Bibliographie