Mémoire - L'automatisation des tests fonctionnels - Emeline Simon

L’automatisation des tests fonctionnels
SIMON Emeline
L’AUTOMATISATION DES
TESTS FONCTIONNELS
[Présenté par Emeline SIMON – 2015-2016]
Mémoire de Master 1 Alternance– Expert en études et
développement du SI -

HITEMA – Groupama Gan Vie
SIMON Emeline
1
Table des matières
Introduction............................................................................................................................................. 3
I. La phase de recette dans un projet................................................................................................. 4
A. Pourquoi et à quel moment réaliser des tests ? ......................................................................... 4
1) Les différentes méthodes de projet et les différents types de tests. ..................................... 4
2) Pourquoi réaliser des tests ? ................................................................................................... 7
3) A quel moment réaliser ces tests ? ......................................................................................... 7
B. La préparation de recette et les plannings.................................................................................. 8
1) Planning et plan de tests ......................................................................................................... 8
2) Jeux de données et base de données...................................................................................... 9
3) Le cahier de recette................................................................................................................. 9
C. L’exécution de recette et les suivis d’avancement. .................................................................. 10
II. Les outils de recettage................................................................................................................... 12
A. Les logiciels de tests sur PC ....................................................................................................... 12
1) Sélénium................................................................................................................................ 12
2) Quicktest Professional........................................................................................................... 12
3) QAWizard .............................................................................................................................. 13
B. Les logiciels de tests sur mobile ................................................................................................ 13
1) Des tests spécifiques aux mobiles......................................................................................... 13
2) Les outils à disposition : payants........................................................................................... 14
3) Les outils à disposition : gratuits ........................................................................................... 14
C. Les logiciels de suivi d’anomalie................................................................................................ 15
1) Un logiciel open source : MantisBT....................................................................................... 15
2) Des concurrents à MantisBT.................................................................................................. 16
III. Peut-on envisager une totale automatisation des tests ?......................................................... 17
A. Les avantages de l’automatisation............................................................................................ 17
B. Les inconvénients...................................................................................................................... 18
C. La reconnaissance des formes : les CAPTCHA........................................................................... 19
Conclusion ............................................................................................................................................. 21
Annexes................................................................................................................................................. 24

SIMON Emeline
2
Remerciements
Je tiens à remercier dans un premier temps toute l’équipe pédagogique de l’école HITEMA.
Je remercie Jean-Paul DAVID et Aurélien ARRIBEY, sans qui je n’aurais pu effectuer mon alternance
chez Groupama Gan Vie.
Je tiens à remercier Etienne BONTEMPS et Florence MOUGEL qui m’ont accompagné dans mon
travail de tous les jours en m’apportant leur expérience et leurs conseils, leur écoute et leur
pédagogie.
Je remercie tout particulièrement Jérémy LE HELLOCO, mon tuteur depuis 2014, pour toute son
attention et son suivi à mon égard, ses conseils et son expérience au sein de Groupama.
Enfin, je remercie toute l’équipe de la MOA Collectives, pour leur écoute et leur soutien tout au long
de mon apprentissage.

SIMON Emeline
3
Introduction
De nos jours, la robotisation est très présente dans l’industrie, ainsi que dans l’informatique. La
robotisation des tests en informatique, c’est-à-dire le principe de réaliser les tests par un ordinateur
est appelé l’automatisation des tests. La qualité est également très normée, telle que ISO 2000, et il
est nécessaire de la contrôler.
Lorsqu’une application est créée ou améliorée dans une entreprise, elle est soumise à différents
types de tests. Ceux-ci permettent de vérifier le bon fonctionnement de ce qui a été développé et
contrôler que la solution correspond à ce que le client a demandé.
Je m’attarderai dans un premier temps sur les tests fonctionnels, tout d’abord en expliquant ce que
sont les plans et cahier de tests (aussi appelés Recette) utilisés pour les réaliser. Ensuite je vous
présenterai les différents outils de recettage qui existent et ceux utilisés dans mon propre domaine
professionnel. Enfin, je répondrai à la question concernant la pertinence et la possibilité de
l’automatisation totale des tests fonctionnels.
Nous sommes en effet en droit de nous demander si les robots sont en mesure de réaliser le travail
effectué par des humains aujourd’hui.

SIMON Emeline
4
I. La phase de recette dans un projet
Dans cette première partie, nous allons tout d’abord comprendre la notion de projet et ce qu’elle
représente. Au sein de celui-ci, il est nécessaire de réaliser des tests mais pas à n’importe quel
moment. C’est pourquoi, après avoir détaillé le système de projet et l’importance des tests, je
développerai l’étape de préparation de recette et des plannings. Enfin, je détaillerai l’étape suivante
qui est l’exécution de recette et les suivis d’avancements réalisés pendant cette phase.
A. Pourquoi et à quel moment réaliser des tests ?
1) Les différentes méthodes de projet et les différents types de tests.
Il existe plusieurs méthodes de gestion de projet et chacune sans exception possède une phase
de tests. Elles ont bien évidemment des avantages et des inconvénients. Ayant pour expérience de
travail la méthode linéaire, je développerai la suite de mon mémoire en me basant sur cette
méthode.
La méthode linéaire (ou « cycle en V ») :
Cette méthode est classique en gestion de projet : c’est une succession de phases permettant
d’aboutir au résultat final. Chaque phase ne chevauche pas sur la précédente ou la suivante :
1 – Source : http://www.ice-tech.fr/fr/p/domaines-interventions
Cette méthode est assez rigoureuse est nécessite une organisation précise. Ses avantages sont :
- Normalisation des étapes de développement
- Rédaction de spécification pour les développements mais aussi pour les tests
- Les tests sont effectués dans un environnement stable

SIMON Emeline
5
L’inconvénient majeur de cette méthode est que le résultat est dépendant du travail effectué en
amont. C’est-à-dire la validation et la vérification des documents de chaque phase précédente. Cela
peut entrainer des détections d’erreurs jusqu’à la fin du développement.
La méthode Agile
Cette méthode est de plus en plus répandue de nos jours car elle possède des avantages non
négligeables. Elle s’organise de la manière suivante : c’est une réalisation itérative qui permet
d’éviter l’effet tunnel. Le produit est adapté au besoin du client plus rapidement. Le code est mis à
jour à chaque itération.
2 - Source : http://www.ntiercustomsolutions.com/training-courses/agile-software-development/
Deux pratiques essentielles constituent cette méthode :
- La réalisation des tests dits exploratoires, consistant à tester les nouvelles fonctionnalités mis
en place lors de la dernière livraison
- L’exécution des tests couvrant systématiquement les fonctionnalités définies et garantissant
en permanence le contrôle de conformité aux besoins métiers.
Cette façon de travailler permet de répartir de manière plus efficace la charge de travail. Le cycle
en V possède une phase de test en « dent de scie » tandis que la méthode Agile axée sur le principe
de l’itération, permet d’avoir une charge constante donc optimale.

SIMON Emeline
6
Les différents types de tests :
Les tests unitaires
Ceux-ci sont réalisés par les développeurs/concepteurs de l’application. Ils sont effectués
pour tester les modules de l’application, c’est-à-dire les bouts de code. A chaque modification du
code, ces tests (automatisés) sont rejoués afin de vérifier que celui-ci fonctionne correctement.
Les tests d’intégration logiciel :
Ceux-ci suivent les tests unitaires et ils couvrent toute l’application. Ces tests comportent des aspects
techniques et fonctionnels.
Les tests techniques applicatifs :
Lorsque la livraison a été effectuée, il est nécessaire de vérifier les aspects techniques :
- Conformité des livraisons (versions…)
- Installation des composants selon la documentation
- Bon fonctionnement (crash, bugs à l’exécution…)
- Erreurs techniques : paramétrage, fichier manquant
Les tests fonctionnels applicatifs :
Ces tests sont à la fois techniques et fonctionnels. Bien souvent, les équipes sautent cette étape pour
passer directement aux tests fonctionnels métier et effectuer les deux types de tests en même
temps.
Ces tests doivent vérifier les cas non passant (générant des messages d’erreurs), les cas aux limites
(des cas mettant en jeu des données se situant aux limites des règles métiers) et les cas de non
régression au niveau applicatif.
Les tests fonctionnels métier :
Ces tests ont pour but de jouer des scénarios type utilisateur. Ce sont des scénarios « bout en bout »
qui sont mis en place et joués par les testeurs. Le but étant de vérifier la qualité du produit. Ces tests
doivent être réalisés dans des conditions « réelles » pour simuler les actions utilisateurs qui seront
effectuées en production.
Ces tests sont accomplis par la MOA, qui a une connaissance métier indispensable à cette phase.
Les tests de non régression :
Ces tests sont essentiels dans toutes les phases de recette. Comme indiqué par leurs noms, ces tests
permettent de vérifier que l’application en question n’a pas régressé.
Si une application subi une évolution, il est possible que celle-ci impacte des fonctionnalités déjà
présentes. Il est impératif de s’assurer que les anciens modules sont toujours fonctionnels.
L’unique solution permettant de détecter la régression est de réaliser l’ensemble des cas de tests à
chaque livraison. Cette procédure s’avère très fastidieuse si une automatisation n’est pas mise en
place.

SIMON Emeline
7
2) Pourquoi réaliser des tests ?
Lors de la création d’une nouvelle application ou d’un nouveau logiciel dans une compagnie,
celle-ci ne peut se permettre de livrer un logiciel à un client sans vérifier le fonctionnement de celui-
ci.
On peut donc affirmer que « toute modification d’un programme engendrant une nouvelle
livraison nécessite une phase de tests ». Bien qu’idéal, cette affirmation n’est pas toujours respectée.
Certaines entreprises ayant des délais très courts et peu de ressources se passent de cette phase ou
la réduise au maximum.
Cependant, les grandes entreprises respectent bien souvent cette phase et effectuent
différents types de tests. Il en va de même pour les évolutions sur une application déjà existante :
chaque livraison doit être précédée de vérifications par l’entreprise.
Le développement d’une application est toujours régi par des règles techniques et métier. Celles-
ci doivent être respectées afin de satisfaire la demande du client. Il ne suffit donc pas de développer
l’application en question sans se soucier du bon fonctionnement. Livrer un produit à destination d’un
client final, avec de multiples erreurs, nuit à l’image de l’entreprise.
3) A quel moment réaliser ces tests ?
Que la recette soit manuelle ou automatisée, il est donc nécessaire d’accorder du temps aux
phases de recette, qui sont proportionnelles à l’ampleur des spécifications fonctionnelles. Cette
phase doit être répétée avant chaque mise en production d’un produit.
Il est nécessaire lors d’une livraison d’une évolution, de tester les nouvelles fonctionnalités, mais
également les anciennes, appelées Tests de Non Régression.

SIMON Emeline
8
En fonction de la méthode utilisée, ce sont deux chronologies qui apparaissent :
3 - Source : http://fr.slideshare.net/JUGLausanne/initiation-aux-tests-fonctionnels-philippe-kernevez-
october-2009
Avant d’effectuer ces tests, l’étape primordiale est la préparation de recette.
B. La préparation de recette et les plannings
1) Planning et plan de tests
Comme décrit ci-dessus, la recette nécessite une préparation ainsi qu’un suivi complet. C’est
pourquoi il est nécessaire avant de commencer la recette, de réaliser des plannings. C’est en
planifiant des réunions MOA – MOE qu’il est possible de déterminer la charge de travail nécessaire.
En effet, la MOE étant responsable du développement, elle est en capacité de donner des dates
butoirs à la MOA. Ces dates constituent les différentes livraisons des composants de l’application.
Cela peut être une fonctionnalité ou bien une interface. Quoiqu’il en soit, ces dates de livraison
permettent à la MOA d’organiser les différentes phases de recette et surtout l’enchainement
logique.
C’est ce qui s’appelle un plan de tests : ce plan est constitué du planning mais aussi de la trame
logique à suivre. Pour chaque période est associée un module à tester et une ou plusieurs
ressources. [Annexe 1]
Il possible de chevaucher les développements avec la recette lorsque le temps est précieux et
non suffisant. Dans ce cas, la Moa effectue les tests fonctionnels sur les modules livrés par la MOE.
Cependant, cela peut engendrer quelques problèmes de fonctionnement de l’application car
certaines interfaces / fonctionnalités nécessitent d’autres modules qui ne sont pas encore livrés. Cela
engendre du travail inutile de tests.

SIMON Emeline
9
Cette opération de préparation de planning pré-recette, permet de donner une date de fin de
recette aux responsables. Parfois – et c’est le cas chez Groupama gan vie – la phase de recette est
suivi d’une phase d’homologation. Cette phase se présente comme une phase de recette mais de
façon bien plus synthétique : c’est la phase de pré-production. Il faut donc également prévoir dans
les plannings cette phase ainsi que les réunions adéquates. La Moa se chargeant de la recette, c’est
bien souvent des référents métiers qui se chargent de l’homologation. Ceux sont eux qui décident si
oui ou non il est possible de mettre en production. Ce n’est en aucun cas la MOA qui donne le GO
pour la mise en production.
Le planning est donc un élément indispensable dans un projet pour toutes les ressources de celui-ci.
2) Jeux de données et base de données
Qu’elle soit manuelle ou automatisée, la recette fonctionnelle nécessite dans tous les cas des
données. Celles-ci sont utilisées pour effectuer des tests. Cela peut être des noms, des numéros de
téléphone, des adresses…. Toutes ces informations doivent être préparées afin de ne pas perdre de
temps durant la phase de test.
Si une ou plusieurs informations venaient à manquer durant le cycle de recette, cela ralentirait le
processus : il faut chercher les informations, les préparer et ré-exécuter les tests.
C’est pourquoi il est idéal de fabriquer un fichier référence regroupant l’ensemble des données qui
seront utilisées :
- Pour une recette manuelle, les testeurs s’appuieront sur ce fichier pour préparer le cahier de
test et si besoin pendant les tests en complément.
- Pour une recette automatisée, c’est le logiciel utilisé qui aura pour point d’appui ce fichier. Il
s’alimentera avec les informations contenues dans ce fichier, en fonction des paramètres
fournis par les testeurs.
De même, la phase de préparation nécessite avant tout une base de données pour les tests. Il
faut donc créer la base en fonction des spécifications si elle n’existe pas. Dans le cas d’évolution sur
une application existante, il faut s’assurer que la base a bien été modifiée en conséquence. Celle-ci
doit également être soumise aux tests.
3) Le cahier de recette
Avant de démarrer l’exécution de la recette – celle-ci ne se fait pas « à l’aveugle » - il faut rédiger
un cahier de recette. J’ai eu l’occasion dans mon travail de rédiger plusieurs cahiers de tests et donc
d’apprendre à le faire. En effet, ceux-ci se préparent en suivant les spécifications fonctionnelles
rédigées après l’expression de besoin. Les spécifications fonctionnelles (détaillées ou générales)
décrivent le fonctionnement de l’application, de ses modules ainsi que de ses interfaces. Elles
répertorient alors la totalité des attentes du client détaillées sous formes de points à traiter.
Le travail à réaliser est alors de prendre un à un les points énoncés et de préparer des scénarios
de test. Un scénario, comporte de une à plusieurs manipulations à effectuer sur l’application.

SIMON Emeline
10
Il faut évidemment tester les scénarios « passants » : quels sont les résultats attendus pour
une utilisation correcte ? Mais il faut également tester les scénarios non passants – aussi appelés
« bloquants » : que se passe-t-il si je provoque une erreur ? La réponse à cette question est définie
entre le client, la maitrise d’ouvrage et la maitrise d’œuvre. Il faut définir ce que le client attend et ce
qui est réalisable, c’est la maitrise d’ouvrage qui effectue le lien entre les deux parties.
Créer un scénario pour tester une fonctionnalité nécessite d’envisager une multitude de tests
différents. Prenons l’exemple d’un champ de saisie à l’écran : si celui-ci attends un numéro de
téléphone, il faut tester l’écriture d’un numéro de téléphone à 10 chiffres et vérifier que cela ne
provoque pas d’erreur. Il faut également tester l’écriture de caractères (voire caractères spéciaux)
pour provoquer une erreur. Mais aussi : un mix entre chiffre et lettres, un champ vide (ce champ est-
il obligatoire ou facultatif ?), la taille du champ (celui-ci est-il limité ?)…
Tous ces scénarios sont écris uniquement sur une seule et même «fonction » : celle du
champ « numéro de téléphone ». Il y a donc environ 6 tests pour celui-ci, tout en sachant que l’on
peut en faire 1, 2 ou plus, en fonction du temps imparti et de la pertinence des scénarios.
Cet exemple basique prouve qu’il existe alors une quantité importante de tests pour une
application. De nos jours, chaque logiciel ou applications possède plusieurs interfaces, composées
elle-même de plusieurs fonctionnalités, boutons et autres actions. Ces actions peuvent être très
simple comme l’exemple précédent ou bien plus compliquées : on peut imaginer des affichages de
données en fonction de critères choisis, mais encore des envois de mails automatiques à des
adresses différentes en fonction d’une maille entité / produit / objet.
C. L’exécution de recette et les suivis d’avancement.
Un cahier de recette correctement rédigé et précis, facilite grandement le travail à effectuer sans
oublier de tests « évidents ». Cela permet également un suivi du travail effectué ou non, en cours,
validé ou non.
Ce cahier permet aussi de répertorier les problèmes rencontrés. En effet, le but étant de corriger
les anomalies découvertes, il est ainsi très pratique de savoir pour chaque scénario ce qui pose
problème. Lorsqu’un bogue est découvert, nous procédons comme suit :
- Définir si le bogue est reproductible
o Si oui, alors il est assez simple de définir la manipulation effectuée.
o Si non, cela peut être dû à un problème qui n’est pas lié au développement, mais
d’éléments externes (exemple : mauvaise connexion internet). Cela peut être
également un problème « aléatoire ». Dans ce dernier cas, il est difficile de les
résoudre.
- Définir le périmètre du bogue : entité, écran, utilisateurs particuliers, etc.
- Rapporter le bogue aux développeurs et le rapporter dans le cahier de tests.
Pendant que l’anomalie est en cours d’analyse et de correction chez l’équipe de développement,
la maitrise d’ouvrage peut poursuivre les autres tests. Lorsque le bogue est corrigé, un patch est alors
appliqué et il est possible de tester à nouveau le scénario bloquant. Ce schéma est répété jusqu’à ce
que le scénario soit complètement validé.

SIMON Emeline
11
Il est possible de différencier les thèmes à recetter sur une application, notamment quand
plusieurs collaborateurs sont en charge de la recette. Ainsi il est assez facile de séparer l’IHM1
, des
requêtes sur la base de données ou encore des appels aux web services…
Au cours de la recette, la MOA se doit d’être informée au mieux de la situation. Elle est très
souvent sollicitée par les différents acteurs pour connaitre l’état de l’avancement, ce qui est terminé,
ce qui est validé ou non, etc…
Ainsi, pour être en mesure de répondre au mieux, la MOA réalise un suivi d’avancement de la
recette. C’est un principe très précis et qui ne doit pas être fait « approximativement ».
Pour chaque scénario existant, il existe plusieurs états que l’on peut définir comme suit :
- RAF : reste à faire, le scénario n’a pas encore été testé
- KO : scénario exécuté et non valide (une fiche d’anomalie lui est associé)
- OK : scénario exécuté et validé
- NT/Abandon : scénario abandonné car non testable
Ces états permettent de réaliser une synthèse sur la totalité des scénarios. Il est alors possible de
suivre quotidiennement l’avancement sur un thème en particulier ou sur la globalité.
De multiples calculs et tableaux croisés peuvent être générés pour répondre aux différentes
questions des acteurs, mais aussi pour gérer au mieux le temps et les ressources. [Annexe 2]
En effet, le nombre total de test à réaliser au cours de la recette a été défini lors de la
préparation de recette. Le nombre total a ensuite été divisé par le nombre de jours/semaines
disponible afin d’obtenir une courbe idéale. Celle-ci permet d’avoir un point d’accroche et de suivi
pour les différents chefs de projets. Cela a pour but d’éviter des retards sur le déroulement : on fait
apparaitre sur le graphique les courbes de tests validés et les tests réalisés. [Annexe 3]
1
Interface Homme Machine

SIMON Emeline
12
II. Les outils de recettage
Afin de réaliser la phase de recette, il faut bien évidemment s’appuyer sur des outils de tests. Il
est possible – et c’est ce qui est pratiqué dans mon service – d’utiliser simplement le logiciel Excel
pour réaliser les cahiers de recette. Cela permet d’effectuer les tests à la main. Cependant, il existe
des outils adaptés à la réalisation de tests automatisés.
A. Les logiciels de tests sur PC
Il existe des logiciels pour effectuer des tests fonctionnels automatisés ; Ceux-ci se choisissent
principalement en fonction du langage de programmation utilisé par l’application à tester, ainsi que
par sa complexité, l’objectif à atteindre et le coût.
1) Sélénium
Sélénium est un outil très utilisé pour automatiser les tests fonctionnels.
[Annexe 4] Même s’il semble un peu compliqué d’apparence il est en réalité
logique d’utilisation. Sélénium se décompose comme suit :
 Selenium IDE : c'est une extension de Firefox, qui permet d'enregistrer une suite d'actions,
qu'il sera possible de rejouer à volonté ;
 Selenium Web Driver : il s'agit cette fois d'une API, disponible pour plusieurs langages,
permettant de programmer des actions sur l'interface, et à vérifier les réponses. Les
actions à réaliser peuvent être exportées depuis Selenium IDE.
2) Quicktest Professional
QTPro, de HP, représente ce jour l’offre phare dans le monde
professionnel. 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é.

SIMON Emeline
13
3) QAWizard
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.
B. Les logiciels de tests sur mobile
Comme expliqué dans le paragraphe précédent, il existe une multitude de logiciel afin
d’automatiser les tests sur PC. Ces logiciels ne sont pas adaptés pour réaliser des tests sur mobile. En
effet, une application mobile est parfois développée dans un langage qui diffère de ceux utilisés pour
une application PC. Il y a également des actions qui ne sont pas réalisables sur un PC (le zoom à deux
doigts par exemple) et donc non pris en compte par les logiciels de test PC. On retrouve notamment
les langages JAVA pour Android, mais aussi Objective C pour IOS, et plus couramment HTML5 /
JavaScript qui reste le langage le plus simple à ce jour.
Je vais dans cette partie exposer les moyens qui ont été conçu afin de réaliser des tests
fonctionnels automatisés pour les mobiles.
1) Des tests spécifiques aux mobiles
Il existe certains types de tests qui ne sont présents que pour les téléphone portable / tablettes.
Ils sont réalisés par les constructeurs de ceux-ci :
Les tests d'interopérabilité (IOT)
Ces tests sont réalisés en général dans les labos des opérateurs pour s'assurer que le mobile
qu'ils vont proposer à leur client est capable de communiquer correctement avec leur réseau sans
perturbation.
La variété d'équipements avec des fournisseurs différents permet à l'opérateur de réduire
les coûts de son réseau en faisant jouer la concurrence, mais aussi d'éviter d'être dépendant d'un
seul fabriquant au risque de se confronter à l'obligation de renouveler complètement son réseau au
cas où son principal fournisseur disparaît.
Ces équipements remplissent les mêmes normes de fonctionnement d'un constructeur à un
autre ; mais la norme ne les oblige pas à intégrer les mêmes protocoles de communication. Ce qui
explique le but des tests IOT qui permet de s'assurer que le mobile est capable de communiquer avec
tous les types d'équipements du réseau de l'opérateur.
Les tests protocolaires ou procédures (couche 3 du réseau mobile)
Ces tests sont réalisés par les fabricants de téléphonie mobile. Le but est de s'assurer que le
mobile implémente correctement les procédures ou protocoles de niveau 3 (couche réseau), comme
par exemple les procédures de mise à jour de localisation, l'attachement sur une cellule convenable,
les appels entrants et sortants, etc....

SIMON Emeline
14
2) Les outils à disposition : payants
Je n’évoquerai ici que quelques outils, car il en existe un grand nombre, tout comme sur PC.
TouchTest est un outil de test mobile autonome développé par SOASTA. Il
nécessite d'installer un agent dans le code source de l'application, ainsi qu'un
client sur le téléphone.
SEETEST est un outil développé par EXPERITEST et JAMO
est un outil de test mobile développé par JAMO Solution
Ces outils n'ont pas besoin que le mobile soit jailbreaké2
;
aussi le même test effectué sur un Android pour une
application fonctionnera sur les autres OS supportés (iOS,
BlackBerry, Windows Phone). L'outil peut être intégré à
QTP, TestComplete, Visual Studio, etc…
3) Les outils à disposition : gratuits
MonkeyTalk, appartenant à la société Gorilla Logic, est un outil permettant
l'automatisation des tests fonctionnels pour les applications mobile natives et
hybrides (iOS et Android). Gratuit, open source, simple à utiliser, efficace,
MonkeyTalk ne demande pas que l'appli soit jailbreacké.
Appium est un outil open source d'automatisation des tests pour les
applications mobile natives et hybrides (iOS et Android), utilisant le WebDriver
JSON wire protocol. Appium vise à automatiser n'importe quelle application
mobile depuis n'importe quel langage et n'importe quel système de test, avec
un accès complet au API back-end et aux bases de données à partir du code
test.
2
Jailbreak : débridage d’un appareil mobile tournant sous IOS pour accéder à toutes les fonctionnalités du
système d’exploitation.

SIMON Emeline
15
C. Les logiciels de suivi d’anomalie
Lorsqu’un bogue est découvert sur l’application testée, une fiche d’anomalie doit être écrite afin
que l’équipe de développement puisse corriger le problème. Ce rapport n’est généralement pas fait
« à la main » sans une norme spécifique. Il existe des logiciels de suivi d’anomalie, qui ont tous le
même principe de base : écrire une fiche de bogue. C’est pourquoi je fonderai mes explications sur le
logiciel Mantis, utilisé dans mon service, et citerai d’autres logiciels.
1) Un logiciel open source : MantisBT.
Mantis Bug Tracker est basé sur une interface
Web et facile à prendre en main pour un novice. Il
est écrit en PHP et nécessite une base de données
(exemple : MySQL, SQL Server) supportées par un
serveur web (par exemple : Apache). Cet outil est
open source et personnalisable : c’est pourquoi il
est largement utilisé dans le monde professionnel.
C’est un outil très adapté pour la déclaration d’anomalies et leur suivi : lorsqu’un bogue est
découvert, une fiche est créée dans l’outil. Cette fiche regroupe les informations essentielles pour
que l’équipe de développement puisse traiter la fiche au mieux. On retrouve dans cette fiche les
informations suivantes :
 Projet associé (paramétrable par l’administrateur)
 Lot associé / Version du produit (paramétrables)
 Sévérité et Priorité : ces critères sont les plus importants car ils permettent de traiter les
bogues bloquants et urgents dès leur soumission.
 Résumé de la fiche : généralement soumis à une normalisation pour une meilleure
organisation des équipes.
 Description du problème : c’est ici que l’on indique la description du bogue rencontré ainsi
que des étapes à réaliser pour reproduire le problème.
 Fichier joints : des captures d’écrans sont appréciées car elles permettent de montrer le
bogue rencontré sur son propre écran.
 Commentaires : il est possible pour un utilisateur d’ajouter un ou plusieurs commentaires à
la fiche.
Il existe bien évidemment, d’autres champs qui sont paramétrables par l’administrateur, en
fonction de la demande et des besoins.
Lorsque qu’une fiche est envoyée à l’équipe de développement, celle-ci se charge alors de
reproduire et corriger l’anomalie. Ainsi, une fiche possède un état qui indique sa situation : ouverte,
résolue, fermée… ces états sont également paramétrables. Cela permet, sur l’écran de synthèse,
d’avoir une vue globale sur les anomalies traitées ou non. Il est possible de trier par domaine,
priorité, sévérité… et autres filtres.

SIMON Emeline
16
Chaque employé qui a accès à Mantis, possède un compte associé à un profil. C’est pourquoi,
chaque fiche est associée à une personne. C’est un système qui facilité le suivi, car une personne qui
reporte un bogue sera plus efficace pour le corriger. De plus, il est possible d’être averti par e-mail
d’un changement d’état, un ajout de commentaire ou autre caractéristique, sur chaque fiche
associée à notre nom (avoir écrit la fiche, écris un commentaire…).
Ainsi le schéma de correction des anomalies peut se représenter comme suit :
2) Des concurrents à MantisBT
HP Quality Center est sans doute l’un des plus connu, notamment car il permet non seulement de
suivre des fiches d’anomalies mais il gère également les campagnes de tests de bout en bout. Outil
est capable de communiquer avec ses outils d’automatisation des tests ainsi que ses outils
permettant les tests de performance.
JIRA est développé par Atlassian SoftWare Systems. C’est une contraction de Gojira (nom japonais de
Godzilla). Son langage de programmation est le JAVA. Cet outil est proposé pour des projets open
source et des organisations non commerciales.
On peut également citer : Redmine, application web libre développée en Ruby On Rails. Mais aussi,
Bugzilla développé en Perl et Trac développé en Python.
4 - Source : http://www.conseilorga.com/publications/recettes-tests-et-qualifications

SIMON Emeline
17
III. Peut-on envisager une totale automatisation des tests ?
A. Les avantages de l’automatisation
La rentabilité
Le premier avantage évident de l’automatisation des tests est la rentabilité. Il est nettement
plus rapide de passer un robot plutôt que de réaliser les tests à la main. Un humain peut également
assez facilement se tromper sur un test à réaliser. Ce n’est pas génant pour l’utilisation de
l’application. Seulement, le processus de tests est retardé : il faut recommencer et parfois le
processus peut être un peu long (redémarrage de l’application - d’une fonction - manipulation à
recommencer depuis le début).
La rentabilité de l’entreprise est largement améliorée grâce à l’automatisation. Celle-ci gagne en
temps et donc en argent. L’argent qui n’est pas dépensé en ressources humaines est réinvesti dans
d’autres utilisations.
Logiciel plus fiable car meilleure couverture
L’automatisation permet de couvrir l’application jusqu’aux tests les plus détaillés. En effet
grâce au gain de temps obtenu, il est possible de tester chaque partie de l’application même pour les
tests « minimes ». Il est possible alors de déceler une anomalie qui aurait pu être masquée par la
recette manuelle : pas le temps pour le moment de tester si un champ peut comprendre des chiffres
et/ou des lettres et/ou des caractères spéciaux.
Gain de temps
L’automatisation des tests « déporte » la charge de travail en fin de cycle de développement
plus en amont. L’effort d’écriture des suites de test s’effectue avant la phase de tests.
En fin de projet, le temps est souvent « compressé » et le travail demandé auprès des testeurs est
bien souvent assez conséquent. Grace à l’automatisation, les tests réalisés et les anomalies détectées
permettent un retour plus raide à l’équipe de développement et donc un traitement immédiat.
Moins de stress pour les équipes
Suite à la rapidité des retours cités ci-dessus, les testeurs ont donc une pression moins forte.
Ceux-ci peuvent rejouer les tests plusieurs fois et ne se précipitent pas pour effectuer les tests
comme le feront les testeurs manuels. Ils évitent ainsi de passer certains tests.
L’application étant de meilleure qualité a donc un meilleur retour du client, c’est un facteur essentiel
de motivation des équipes.

SIMON Emeline
18
B. Les inconvénients
Le cout de la mise en place de l’application de tests
Choisir une application d’automatisation des tests est la première étape lorsque l’on veut
réaliser l’automatisation sur une application. Cependant, il faut mettre cette application en place au
sein de l’entreprise. Ce n’est pas anodin car la mise en place nécessite des installations,
configurations au sein des différents services. Cela a un certain cout non négligeable : installation,
configuration, licence, maintenance.
La formation des utilisateurs
Lorsque l’application est installée au sein de l’entreprise, les utilisateurs en charge de la
recette – la MOA généralement – doivent apprendre à se familiariser avec le logiciel.
Il est possible que l’entreprise choisisse d’installer un logiciel lorsqu’une équipe est au
complet depuis plusieurs années : cela signifie que la plupart – voire tous les membres – de l’équipe
ne sachent pas se servir de l’application. L’entreprise se doit alors de former l’équipe, ou de laisser
l’équipe s’auto-former. Dans les deux cas, il y a un coût et du temps accordé à cette étape non
négligeable.
Contrainte sur l’écriture du test :
Les tests à écrire doivent être robustes : après une modification de l’interface graphique, le
test doit continuer à être fonctionnel.
De plus, il est bien souvent nécessaire de connaitre l’interface graphique avant de pouvoir
écrire le test.
Enfin et comme précisé ci-dessus, il est plus facile d’écrire un test manuel qu’un test
automatique : lorsque les délais sont courts, il est difficile d’écrire des tests automatisés.
La maintenance
Le problème de l’exécution des tests est déporté vers la maintenance des tests automatisés.
En effet, le temps passé à maintenir les une ou plusieurs bases de scripts automatisés est parfois plus
important que de ré-exécuter les tests manuellement.
Cette maintenance est le point majeur à prendre en compte lorsqu’une entreprise souhaite
automatiser sa recette. Elle doit s’assurer que le temps accordé à la maintenance reviendra moins
cher que de continuer à exécuter manuellement les tests.

SIMON Emeline
19
C. La reconnaissance des formes : les CAPTCHA
Automatiser les tests fonctionnels « classiques », c’est une fonctionnalité assez simple et très
rentable pour l’entreprise ; Cependant nous avons discuté des tests basiques ayant une interface, un
champ de données, et des résultats attendus. Qu’en est-il de la reconnaissance des formes à ce
jour ?
De plus en plus, nous utilisons la reconnaissance vocale, faciale ou encore manuscrite. Un outil de
test peut-il effectuer automatiquement les tests de reconnaissance de ces formes ? Est-il à même de
déterminer si un test est valable ou non ?
Définition
D’après Wikipédia :
“Le terme CAPTCHA est une marque commerciale de l'université Carnegie-Mellon désignant une
famille de tests de Turing permettant de différencier de manière automatisée un utilisateur humain
d'un ordinateur.
L'acronyme « CAPTCHA » est basé sur le mot capture, et vient de l'anglais completely automated
public Turing test to tell computers and humans apart.”
Voici des exemples de captcha :
Il existe plusieurs techniques pour fabriquer un
captcha. La première étant d’ajouter un dégradé
de couleur en fond et en modifiant la forme des
lettres.
La deuxième, plus récente, n’utilisent pas de
fond de couleur différente, c’est une ligne brisée
qui est ajoutée par-dessus les lettres.
Enfin, il est également possible d’imbriquer les
lettres les unes dans les autres.
Ces techniques basées sur les déformations de lettres sont à ce jour de moins en moins efficaces. Les
robots de reconnaissance de caractères sont de plus en plus puissants et arrivent à 98% à déchiffrer
les captcha sous cette forme.

SIMON Emeline
20
Nouveautés
Il a donc été nécessaire de développer de nouveaux tests de Turing, simple pour l’utilisateur
et irrésolvable pour un ordinateur.
C’est ainsi que depuis 2009, le projet ReCaptcha
appartient à Google. Celui-ci révolutionne les captcha
habituels. En ne proposant qu’une simple case à cocher et
quelques informations à écrire, il est possible de déterminer si
l’utilisateur est un ordinateur ou humain.
Le système ne va pas contrôler les informations rentrées, mais comment elles ont été
rentrées : les mouvements réalisés par l’utilisateur, le scroll3
, les mouvements de souris… En fonction
de ceux-ci, le système est capable de différencier un robot d’un humain.
Et ce n’est pas tout, en cas de doute, un
deuxième test est proposé. Cela peut être un captcha
classique, ou bien un test encore très difficile pour un
robot : une série de photos présentant un intrus à
retrouver. Une étape simple sur le plan cognitif pour
un cerveau, beaucoup plus complexe pour un
programme. Trouver une photo similaire à celle
présentée, ou à l’inverse un intrus parmi les photos,
reste trop difficile à ce jour pour un robot.
De plus, d’après Google, le moteur s’enrichit également sans cesse : toutes les actions
menées par les utilisateurs servent à lui apprendre à affiner sa détection de ce qui semble réel ou, au
contraire, de ce qui est simulé.
Pourquoi ne peut-on pas automatiser les tests ?
Un CAPTCHA comme expliqué précédemment, ne peut être reconnu par un ordinateur. Cela
signifie que lancer des reconnaissances de forme par un logiciel, ne rendrait pas un résultat correct.
Il existe à ce jour des logiciels permettant la comparaison d’image. Ceux-ci comparent l’image
fournie au départ (par les testeurs / clients) avec l’image rencontrée durant le test. Il est possible de
régler un “taux de validation”. On considère pour chaque type d’image un taux de validation à
passer. Par exemple, en moyenne pour une image de type .JPG, on accepte le scénario de test à
partir de 80% de ressemblance. En revanche, pour un GIF, ce taux monte à 95%. Cela prouve qu’il
existe néanmoins une marge d’erreur possible.
Ce système ne peut être utilisé avec les captcha, générés aléatoirement. Le logiciel n’ayant aucun
point de comparaison, il ne peut utiliser cette méthode.
3
Faire défiler verticalement le contenu d’un document à l’aide de la molette d’une souris – Source : Wikipédia

SIMON Emeline
21
Conclusion
L’automatisation des tests fonctionnels est de plus en plus répandue dans les entreprises.
C’est une méthode efficace et qui a fait ses preuves. Cependant, Comme nous l’avons vu dans les
avantages et les inconvénients, cela peut être couteux à mettre en place.
De plus, Il existe une multitude de logiciels, que ce soit sur PC ou sur mobile. Il n’est donc pas
simple pour l’entreprise de faire son choix parmi toutes ces possibilités.
L’entreprise a donc tout intérêt de vérifier que son choix sera rentable avant d’engager quoi
que ce soit.
Les robots tendent de plus en plus à ressembler aux humains, et ce, dans tous les domaines.
Nous avons constaté que l’évolution de la reconnaissance des formes nous amène de moins en
moins à différencier un ordinateur d’un humain.
Cette évolution se traduit également dans d’autres domaines, telle que la médecine
(exemple : les robots chirurgiens), les réceptionnistes d’hôtel au Japon ou encore plus
communément les bornes d’achats dans les fast-foods.
Nous sommes aujourd’hui en droit de nous poser la question du bénéfice de ces évolutions :
en effet, ne sommes-nous pas tous enclins à être remplacé par des robots ?

SIMON Emeline
22
Glossaire
Anomalies : Absence de conformité entre un comportement applicatifs attendu et un comportement
obtenu en phase de test.
Campagne de test : ensemble de cas de test à exécuter sur une partie de l’application.
MOA : Maitrise d’ouvrage, correspond à l’ensemble des personnes définissant les besoins devant
être satisfait par une application.
MOE : Maitrise d’œuvre, correspond à l’ensemble des personnes en charge de la réalisation d’un
composant ou d’un système.
Open-Source : désigne un logiciel dans lequel le code source est à la disposition du grand public.
Test de Turing : Ce test consiste à mettre en confrontation verbale un humain avec un ordinateur et
un autre humain à l’aveugle.

SIMON Emeline
23
Bibliographie / Webographie
https://fr.wikipedia.org/wiki/Test_unitaire
https://fr.wikipedia.org/wiki/Extreme_programming#Tests_de_recette_.28ou_tests_fonctionnels.29
http://blog.octo.com/demarches-de-tests-fonctionnels/
http://fr.slideshare.net/gmantel/automatisation-des-tests-le-mythe-du-roi
https://fr.wikipedia.org/wiki/Mantis_Bug_Tracker
http://www.e-systemes.com/live-blog/suivi-des-bugs-et-des-projets-quelle-application-pour-e-
systemes/434/
http://atatorus.developpez.com/tutoriels/java/test-application-web-avec-selenium/#LI
http://www.osaxis.fr/blog/automatiser-ses-tests-fonctionnels-partie-2-2/
http://www.zdnet.fr/actualites/6-conseils-pour-les-tests-d-applications-mobiles-39806167.htm
http://www.all4test.fr/actualites/477-test-mobile-comment-tester-les-applications-mobiles
https://fr.wikipedia.org/wiki/CAPTCHA
http://www.nextinpact.com/news/91233-recaptcha-google-veut-prouver-que-vous-netes-pas-robot-
avec-case-a-cocher.htm
http://www.conseilorga.com/publications/recettes-tests-et-qualifications
Livre : Industrialiser le test fonctionnel - 2e édition: Pour maîtriser les risques métier et accroître
l'efficacité du test - Bruno Legeard, Fabrice Bouquet, Natacha Pickaert

SIMON Emeline
24
Annexes
Annexe 1 : Exemple de plan de test sur le lot 6 du logiciel IGC, Groupama Gan Vie.
Annexe 2 : Exemple de suivi d’avancement format Tableau sur le logiciel TCS WEB,
Groupama Gan Vie.
Annexe 3 : Exemple de suivi d’avancement format courbe sur le lot 6 du logiciel IGC,
Groupama Gan Vie.
Annexe 4 : Exemple de test avec Selenium, classe Selenium

SIMON Emeline
Annexe 1 : Exemple de plan de test sur le lot 6 du logiciel IGC, Groupama Gan Vie.
Cette image représente un plan de test se déroulant sur 8 semaines. On peut y observé les dates pour chaque période, le nombre de jours alloué à la
période indiquée, le thème à recetter, le ou les acteurs (les testeurs), le nombre de cas à tester par thème et le nombre total.
Ce plan permet à chaque ressources de savoir ce qu’elle a à faire et en combien de temps. Tous les acteurs de la recette sont ainsi informés de la situation.

SIMON Emeline
1
Annexe 2 : Exemple de suivi d’avancement format Tableau sur le logiciel TCS WEB, Groupama Gan Vie.
Sur cet exemple, le suivi d’avancement est organisé sur un cahier de recette comprenant plusieurs onglets (chacun représentant un thème).
On peut ainsi suivre le détail du nombre de cas de tests sur chaque domaine, puis le pourcentage.

SIMON Emeline
Annexe 3 : Exemple de suivi d’avancement format courbe sur le lot 6 du logiciel IGC, Groupama Gan Vie.
Sur cet exemple, le suivi d’avancement est réalisé à partir de quatre types de résultats : prévisionnel, révisé, exécuté, validé. Ces états permettent de situer
le point d’avancement des équipes. Les deux schémas représentent le même suivi mais de façon différente : nombre de cas et pourcentage, et tous deux
avec TNR (tests de Non régressions) inclus.
L’état Prévisionnel est le nombre de tests prévu au départ, l’état « révisé » est le nombre de cas revu à chaque période (on peut dire Ajusté).
L’état « exécuté » est le nombre de cas qui ont été testé, qu’ils soient OK ou KO.
Enfin l’état « Validé » est le nombre de cas qui sont OK, donc corrects.

SIMON Emeline
Annexe 4 : Exemple de test avec Selenium, classe Selenium.
public class selenium {
private Selenium selenium;
@Before
public void setUp() throws Exception {
WebDriver driver = new FirefoxDriver();
String baseUrl = "http://localhost:8080/tutoselenium";
selenium = new WebDriverBackedSelenium(driver, baseUrl);
}
@Test
public void testSelenium() throws Exception {
// Connexion au site
selenium.open("/tutoselenium/");
// On est page 1, on va page 2
selenium.type("id=contentForm:pageText", "2");
selenium.click("id=contentForm:nextPage");
selenium.waitForPageToLoad("30000");
// puis page 3
selenium.click("id=contentForm:page3Button");
// et retour page 1
selenium.select("id=contentForm:pageList_input", "value=1");
selenium.click("id=contentForm:nextPageButton");
// On passe en anglais
selenium.click("id=headerForm:english_button");
// etc.
}
@After
public void tearDown() throws Exception {
selenium.stop();
}
}

SIMON Emeline
1

Mémoire - L'automatisation des tests fonctionnels - Emeline Simon

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Mémoire - L'automatisation des tests fonctionnels - Emeline Simon

Similaire à Mémoire - L'automatisation des tests fonctionnels - Emeline Simon (20)

Mémoire - L'automatisation des tests fonctionnels - Emeline Simon