Après les principes de fonctionnement des outils d’automatisation de tests fonctionnels sur deux exemples élémentaires, voyons plus globalement les fonctionnalités requises de ce type de solution et un rapide tour d’horizon des principales offres du marché.

Les grandes fonctionnalités attendues d’un outil d’automatisation de tests fonctionnels

Un outil d’automatisation de tests fonctionnels doit donc avant tout disposer d’un enregistreur, directement à partir d’une navigation sur le site ou l’application, et d’une fonctionnalité de rejeu. Ceci permet à un non informaticien d’enregistrer puis de rejouer autant de fois que souhaité son scénario sans avoir recours à de la programmation. Néanmoins, de nombreuses autres fonctionnalités sont requises pour mener des tests plus poussés, fonctionnalités plus ou moins abouties selon les outils présents sur le marché.

Un des aspects les plus importants de ce type d’outil concerne la capacité de gestion et de reconnaissance des objets de l’interface. En effet, il ne suffit pas lors du rejeu de se repositionner en coordonnées graphiques pour effectuer une action, encore faut-il pouvoir localiser un objet afin de pouvoir mener l’action appropriée. Par exemple, si lors de l’enregistrement du script de test un bouton « Enregistrer » se trouvait en bas à gauche de son navigateur, il ne faut pas qu’une redéfinition de la charte du site le positionnant désormais en bas à droite génère une erreur lors du rejeu. Ainsi, il est demandé à l’outil d’automatisation des tests de reconnaître les objets lors de l’enregistrement afin de pouvoir effectuer l’action souhaitée lors du rejeu, quel que soit leur positionnement à l’écran. Pour aller plus loin, certains outils gèrent même un référentiel d’objets, voire permettent d’effectuer un mapping d’objets pour l’activation d’évènements non prévus sur un objet non reconnu lors de l’enregistrement. Ceci est important pour des enregistrements effectués sur des interfaces particulières comprenant des objets non standards, ou plus communément sur des utilisations dérivées d’objets graphiques. Par exemple, pouvoir mapper une image cliquable en bouton permet de gérer cette image avec toutes les propriétés propres à un bouton, comme le clic pour validation d’un formulaire.

Un autre aspect important concerne la mise en place de points de contrôle, et les paramétrages offerts pour ceux-ci. Exécuter un scénario et le rejouer est certes important, mais insérer des points de contrôle pour valider la cohérence du résultat obtenu par rapport à celui attendu l’est encore plus. Ainsi, certains outils, via la présence d’assistants, permettent a posteriori de positionner des points de contrôle à certains endroits du script. Ceux-ci ont pour objectif lors de la réexécution du scénario de valider les propriétés de la page et des objets, permettant d’interrompre ou pas l’exécution du scénario si des différences sont constatées par rapport à l’enregistrement initial.

D’un point de vue plus général, certains outils sont destinés aux tests de non régression sur des applications Web exclusivement, alors que d’autres vont supporter d’autres types d’interfaces telles les interfaces graphiques Windows, les interfaces Java, les modules Flash, etc. Les capacités des outils à ce niveau diffèrent fortement, certains pouvant même concilier au sein d’un même test des objets issus d’interfaces hétérogènes. Par exemple, il est parfois utile de pouvoir piloter le navigateur Web depuis sa barre de menu, sur un test d’interface graphique, et continuer le test en validant le contenu HTML de la page, le test basculant alors dans un contexte Web. A l’inverse, une application Web peut ouvrir une feuille de calcul Excel ou Calc, et il peut être intéressant au sein des tests menés sur l’application Web de valider le contenu d’une cellule du tableur ouvert depuis son site Web. A noter à ce niveau que les outils permettant de forcer l’exhaustivité d’un test sur le positionnement en coordonnées graphiques du pointeur de la souris peuvent plus facilement s’affranchir de l’hétérogénéité des interfaces. Ces tests sont néanmoins fortement limités car contraints à une constance de la charte graphique des applications testées pour pouvoir répondre aux attentes des testeurs. Par exemple, dans cette situation, le simple fait de changer la taille d’un menu rend l’ensemble des tests caducs lors du rejeu.

Un objectif prioritaire de ces tests consiste également à analyser les résultats obtenus lors de l’exécution d’un scénario. Ce dernier pouvant prendre plusieurs dizaines de minutes, il est important de pouvoir rapidement obtenir une synthèse des résultats obtenus à partir des fichiers de résultats de tests créés par l’outil. Sur ce point, la lisibilité des journaux, hiérarchisant par exemple les tests et mettant en évidence les erreurs relevées, les points de contrôle en échec ou encore les avertissements ou doutes sur validation d’un aspect se révèlent à l’usage essentiels. Il en va de même pour la capacité offerte par l’outil pour paramétrer les journaux résultats, plus ou moins verbeux selon la volumétrie du test, ou encore pour un export de ces logs aux formats PDF, pour une exploitation de qualité, ou bien aux formats Calc ou Excel pour effectuer des analyses statistiques.

Pendant le déroulement du rejeu d’un scénario, un évènement extérieur à l’application peut intervenir, bloquant le bon déroulement de celui-ci. Par exemple, lors du test de son site, un popup d’avertissement « mémoire disponible insuffisante » généré par le système d’exploitation peut survenir, prenant le focus sur l’application testée. Dans cette situation, l’outil va donc rechercher dans cette fenêtre popup l’objet concerné par le test, et ne le trouvera bien entendu pas. Il est toujours possible, pour les outils permettant de faire cohabiter dans un même test plusieurs applications de type différent, de demander à ce moment-là de cliquer sur le bouton « annuler » et de poursuivre le test. Ceci se traduit néanmoins par l’obligation d’effectuer ce test à tous les niveaux du code du script, chose impossible pour un scénario même relativement petit. Certains outils gèrent heureusement la gestion d’évènement sur l’ensemble d’un scénario, permettant d’effectuer un bout de script particulier lorsque survient un évènement extérieur particulier. La quintessence de la couverture de cette fonctionnalité consiste à proposer un assistant pour traiter ces évènements et la gestion d’erreur associée, mais très peu d’outils vont aussi loin à ce niveau.

Dans un contexte plus orienté développement d’entreprise, les outils d’automatisation de tests peuvent être utilisés pour valider le bon état de marche d’une application sur une couverture fonctionnelle plus large que celle qui pourrait être effectuée manuellement. Dans un tel contexte, ces outils vont alors bien au-delà du test de non régression. C’est ainsi le cas quand on souhaite valider l’application sur un jeu de données dynamique. L’enregistrement du scénario se fait alors à partir d’un scénario basé sur un jeu de données unique, et le scénario est rejoué en boucle autant de fois que souhaité sur un jeu de données le plus exhaustif possible. Par exemple, un scénario de test est censé valider la modification d’un formulaire proposant les informations d’un fournisseur. Lors de l’enregistrement, le testeur va ouvrir le formulaire d’un fournisseur en le sélectionnant dans la liste, modifier son prénom, appuyer sur le bouton enregistrer puis demander la vérification de la page de confirmation de la modification affichant le nouveau prénom. Lors du test, l’utilisation d’un jeu de données dynamique va permettre de rejouer ce scénario pour chacun des fournisseurs sans avoir à effectuer une opération supplémentaire, et ainsi valider le bon fonctionnement de l’application pour tous les fournisseurs. Selon les capacités de l’outil de test, ce jeu de données pourra être parcouru séquentiellement ou aléatoirement, à partir d’un fichier plat, d’un tableur ou même directement depuis des tables stockées dans une base de données.

Enfin, la richesse du langage de développement et de ses API constitue un des aspects essentiels dans la puissance proposée par un outil d’automatisation de tests fonctionnels. En effet, pour des tests très poussés, il est essentiel de pouvoir s’appuyer sur un nombre de fonctions/méthodes le plus étendu possible. En ce sens, un outil reposant sur un serveur d’applications J2EE dispose de capacités bien plus étendues qu’une solution articulée sur son script propriétaire. Par exemple, si l’outil de tests exploite pleinement J2EE ou .Net, il est aisé d’automatiser lors de la détection d’une anomalie l’envoi d’un message électronique au testeur en s’interfaçant avec un serveur de messagerie. Ce service est impossible à implémenter avec un outil de tests proposant un langage de script propriétaire n’intégrant pas nativement cette fonctionnalité.

Selon la nature de tests à mener, de nombreuses autres fonctionnalités peuvent être utiles. Parmi celles-ci, on peut citer la comparaison de fichiers et d’images (figure 8), la reconnaissance de caractères, très utile par exemple pour valider le contenu d’un fichier PDF, le paramétrage de l’exécution des scripts, la possibilité de debugger, l’interfaçage avec le back-office, etc. L’interfaçage avec d’autres solutions d’amélioration de la qualité logicielle, tels les outils de gestion d’anomalies ou encore les solutions de tests de montée en charge, constitue également un plus.

Un outil doté de la plupart de ces fonctionnalités offre ainsi une probabilité plus forte d’arriver à ses fins, les solutions de contournement délivrées pour effectuer un test étant ainsi d’autant plus nombreuses quand un point de blocage apparaît.


Figure 8 : comparaison d’image sur une zone de l’application testée [cliquer sur l’image pour l’agrandir]

Dans quelles situations retenir un outil d’automatisation de tests ?

Si l’intérêt d’automatiser les tests paraît évident, le ROI (retour sur investissement) n’est malheureusement pas toujours au rendez-vous. En effet, la réalisation d’un scénario de tests complet est beaucoup plus coûteuse en temps que la réalisation manuelle des tests. A cela, il faut compter également une charge supplémentaire de maintenance lors de chaque rejeu, plus ou moins importante selon le type d’évolutions apportées à l’application ou au site Web testé. Enfin, n’oublions pas le coût de la ou des licences de développement de l’outil qui peut s’ajouter au temps passé à réaliser et maintenir les tests.

D’un point de vue général, l’utilisation d’outils d’automatisation de tests fonctionnels devient très avantageuse à partir du moment où on arrive à maîtriser le périmètre des tests à couvrir. L’effort consenti par exemple pour couvrir 20% des tests sera assez faible, alors que la couverture de 30% des tests peut doubler la charge de travail requise, et il faudra même parfois 10 fois plus de temps pour développer et couvrir 40% des tests à partir de son outil d’automatisation. L’autre facteur prépondérant concerne le type d’application testée. Ainsi, un site Web censé fonctionner sur plusieurs navigateurs différents, sous les 2 ou 3 dernières versions de chaque navigateur, qui plus est dans un contexte multilingue, sera d’autant plus adapté à l’automatisation. Dans cette situation, le script réalisé pourra ainsi avec très peu de modifications tourner sous toutes les versions de navigateur dans toutes les langues requises, multipliant ainsi l’utilisation de l’automatisation sans effort supplémentaire. Un autre cas bien adapté concerne les phases de tests et de recette pour les applications manipulant une volumétrie importante de données. A partir d’un scénario écrit pour un jeu de données unique, il est possible de dérouler celui-ci sur un jeu de données bien plus exhaustif sans avoir à effectuer les tests manuels au cas par cas pour chacun des enregistrements de sa base de données. Enfin, dans le milieu de l’entreprise, les tests sur les applications requérant d’incessantes évolutions et donc des tests répétitifs, notamment de non-régression, gagnent à être automatisés. C’est notamment le cas des éditeurs de logiciel particulièrement consommateurs en tests et donc en outils d’automatisation. Une ébauche de R.O.I. obtenu par l’industrialisation de l’automatisation des tests fonctionnels fera prochainement l’objet d’un article sur le présent site Osaxis.

Panorama des offres

Au-delà de Selenium et de TestComplete présentés succinctement dans le présent article, une trentaine d’offres cohabitent sur le marché de l’automatisation des tests fonctionnels. Si certains ont pour objectif d’adresser la plupart des problématiques, certains se spécialisent dans des domaines d’expertise très ciblés afin de se démarquer de la concurrence. Voici un rapide aperçu de ces solutions.

En acquérant Borland et les outils de tests de Compuware, Microfocus s’est doté de deux solutions d’automatisation de tests fonctionnels. Tout d’abord SilkTest, produit initialement lancé par Segue Software avant un rachat par Borland, s’adresse avant tout aux maîtrises d’œuvre avec intégration des tests dans le cycle de vie du développement. De l’autre côté, TestPartner, provenant de l’ancienne offre de Compuware, est plutôt destiné aux maîtrises d’ouvrage. SilkTest, assez difficile à appréhender, se distingue par la couverture de nombreux types d’interface graphique, y compris au sein d’un même test. TestPartner, qui permet d’effectuer des tests assez poussés à partir de son atelier de développement abouti, atteint néanmoins ses limites dès qu’il faut entrer plus précisément dans le code pour des besoins non couverts nativement par le produit.

IBM propose également deux outils à son catalogue, Robot et RFT, issus tous deux de la société Rational achetée en 2003. Plus complet, Rational Functional Tester (RFT) est depuis quelques années clairement positionné comme l’offre phare d’IBM pour ce type de besoins. S’intégrant dans Visual Studio et Eclipse pour respectivement des développements .Net et J2EE, RFT respecte ainsi la notion de fenêtre unique en proposant aux équipes de développement un outil de tests fonctionnels directement intégré dans l’atelier de développement. Au-delà du prix, le principal inconvénient de l’outil demeure sa lourdeur, une machine performante étant requise pour réaliser confortablement ses scripts de tests.

QAWizard, de la société Seapine Software, ne manque pas d’intérêt malgré une présence encore marginale en France. Peu onéreux, QAWizard est très simple d’utilisation. Le passage d’un mode « tableau » pour les débutants à un mode « code » pour les testeurs aguerris permet d’appréhender progressivement et en douceur la complexité des tests fonctionnels. Le support en France reste un des points faibles du produit.

Enfin, QuickTest Pro, de HP, représente ce jour l’offre phare dans le monde professionnel. WinRunner, autre produit d’automatisation de tests fonctionnels de l’éditeur, a été mis de côté au profit du très complet QuickTest Pro. Le référentiel d’objets est particulièrement bien conçu, celui-ci pouvant notamment être généré lors de l’enregistrement, enrichi manuellement ou encore importé à partir d’un autre scénario. Paradoxalement, le produit souffre principalement de sa complétude, difficile à prendre en main pour un débutant. De plus, le coût de la licence est assez élevé par rapport aux autres offres du marché.


Il est possible de retrouver l’intégralité de cet article dans le numéro 149 du mois de Février 2012 du magazine « Programmez ».