Licence

Cette oeuvre est entièrement placée sous licence Creative Commons (CC) : “Attribution
(BY) + Pas d’utilisation commerciale (NC) + Pas de modification (ND)”.

Auteurs : Chrysocode IT & All4Test

ATTRIBUTION Toutes les licences Creative Commons

(BY) obligent ceux qui utilisent cette oeuvre à nous
créditer de la manière dont nous le
demandons, sans pour autant suggérer que
nous approuvons leur utilisation ou leur
donnons notre aval ou notre soutien.

PAS D’UTILISATION COMMERCIALE Nous autorisons autrui à reproduire et à

(NC) diffuser notre œuvre, pour toute utilisation
autre que commerciale, à moins qu’ils
n’obtiennent notre autorisation au préalable.

PAS DE MODIFICATION Nous autorisons la reproduction et la diffusion

(ND) uniquement de l’original de notre oeuvre. Si
quelqu’un veut la modifier, il doit obtenir notre
autorisation préalable.

Plus d’informations sur [Link]

Date de publication :

Image de la page de couverture : photo by Lucas Gallone on Unsplash

En ligne : [Link]

1/109
Téléchargement direct :
[Link]
=jpg&crop=entropy&cs=tinysrgb&dl=[Link]

Jeux d’icônes
Role Playing Icons by Chanut is Industries (30 icons)
Legendora Icons by Teekatas Suwannakrua (88 icons)
Outer Space Icons by Chanut is Industries (15 icons)

2/109
 Table des matières

Introduction 8

Objectifs 8
Auteurs 8
Pourquoi un livre dédié aux tests automatisés ? 10
À qui ce livre est-il destiné ? 10
Vos retours nous sont précieux 11

Framework d’automatisation de test 16

Pourquoi recourir à un framework ? 17
Qu'est-ce qu'un framework d'automatisation de test ? 17
Sens 1 : solution intégrée d’automatisation de test 17
Sens 2 : cadre logiciel de développement de test automatisé 18
Framework versus Bibliothèque 22

Typologie des Frameworks d’automatisation de test 24

Démarche 26
Types de framework 27
Scénario fil rouge 28
Avantages et inconvénients supposés 29
Comprendre les types de framework de test 29
Framework par script linéaire 29
Définition 29
Utilisation 30
Observations 31
Framework par tests modulaires 31
Définition 31
Utilisation 33
Observations 35
Framework de test fondé sur des bibliothèques de fonctions 35
Définition 35
Utilisation 37
Observations 39
Framework de test piloté par les données 39
Définition 39
Utilisation 40
Observations 42
Framework de test piloté par mots d’action 43
Définition 43
Utilisation 45

3/109
 Observations 46
Framework de test hybride 46
Définition 46
Utilisation 48
Observation 48
Framework de test fondé sur les composants 48
Définition 48
Utilisation 48
Observations 48
Framework de développement piloté par les comportements 48
Définition 48
Utilisation 50
Observations 50
Framework de test piloté par les modèles 51
Définition 51
Utilisation 51
Observations 51
Comparaison des types de framework de test 51

Bonnes Pratiques d’automatisation de test 56

Un environnement de développement performant 56
Adopter des technologies de développement testables 57
Versionner les tests 57
Scénariser n'est pas Automatiser 57
Développer des applications facilement testables 58
Le saviez-vous ? 58
Choisir le bon framework d’automatisation 58
Prenez de l’avance avec le Walking Skeleton 58
Améliorer l’automatisation de test 58
Choisir les cas de test à automatiser 59
Principes FIRST 60
Motifs de conception de test 60
Page Object Model (POM) 60
Screenplay 60
Browser Factory 61
Given-When-Then 61
Organisation arborescente du référentiel de test 62
Principes de développement applicables au test 62
Séparation des préoccupations 62
Keep It Simple, Stupid (KISS) 63
You Ain't Gonna Need It (YAGNI) 63
Don’t Repeat Yourself (DRY) 64

4/109
Écueils à éviter dans un projet d’automatisation 64
Des outils inadaptés 64
Mal choisir les cas de test à automatiser 67
Confondre méthode et outil 69
Attendre un délai fixe 70

Implémentations de framework d’automatisation de test 71

Selenium 72
Selenium WebDriver 72
Selenium IDE 73
Selenium Grid 73
FluentLenium 74
Selenide 74
Atata 74
Un framework de ??? 74
Robot Framework 75
Un framework de Keyword-Driven Testing 75
Exemple d’automatisation 75
Astuces avec Robot Framework 75
Factorisation des phases de préparation et de suppression 75
Typer les étapes des cas de test 76
Given-When-Then dans la langue des tests 76
Sélection d'éléments web non standards 76
Paramétrage de RED 76
Codez-les 77
Nommer les arguments 78
Les trois petits points 78
Cypress 78
Un framework de ??? 78
Caractéristiques du cypress 79
Exemple d’automatisation 79
Astuces avec Cypress 79
Organisation des tests, connexion, contrôle de l'état 79
Sélection des éléments 79
Visiter des sites externes 80
Création de «tiny» tests avec une seule assertion 80
Attente inutile 82
Web Servers 83
Définition d'une baseUrl globale 83
Cucumber 83
Un framework de BDD 83
Fonctionnement de Cucumber 84

5/109
 Exemple d’automatisation 85
Behat 85
Un framework de BDD 85
SpecFlow 85
Un framework de BDD 85
Exemple d’automatisation 86
Protractor 86
Un framework de ??? 86
Exemple d’automatisation 86
Caractéristiques de Protractor 86
Bonnes pratiques avec Protractor 86
Astuces avec Protractor 87
SikuliX 89
Un framework de ??? 89
Gauge 89
Un framework de Behavior Driven Test 89
Caractéristiques de Gauge 90
Appium 90
Un framework de ??? 90
Architecture d’Appium 91
Avantages et inconvénients d'Appium 91
Avantages 91
Inconvénients 91
MaTeLo 92
Un framework de Model-Based Testing 92
Yest 92
Un framework de Model-Based Testing 92
TestCafé 93
Un framework de ??? 93
Exemple d’automatisation 94
Tests en parallèle 94
Les sélecteurs de TestCafé 95
Pas besoin de plugins externes 95
Intégration continue 95
Rapports TestCafé 95
Points forts de TestCafé 96
TestComplete 96
Un framework de ??? 96
Amélioration et révision des tests 97
Modification du type du test enregistré 97
Enregistrement de différents types de tests 97
Options et spécificités d'enregistrement 97

6/109
 Comparaison des implémentations de framework 98

Solutions Low-Code d’automatisation de test 98

Low-Code : de quoi s’agit-il ? 98
CloudNetCare 98
Agilitest 99
Avantages et points forts d’Agilitest 99
Limites et points faibles d’Agilitest 100
Katalon 100
Ranorex 100
Caractéristiques de Ranorex 100

Références Bibliographiques 102

7/109
Introduction

Combien d’entre vous n’ont jamais connu de problèmes pour automatiser leurs tests
dans leurs projets informatiques ?

Savez-vous que par expérience, on constate que plus de 50 % des projets

d’automatisation de test fonctionnel, soit 1 projet sur 2, sont des échecs ?!
Comme ces projets sont souvent trop compliqués et coûteux à maintenir, les causes
d’échec sont nombreuses. Afin d’éviter ces pièges, mieux vaut bien sûr mettre en
place une véritable stratégie d’automatisation de test. Mais il faut également être
capable de comprendre l’utilité d’un framework d’automatisation de test, et savoir
comment choisir le bon framework par rapport à ses besoins et ses contraintes
techniques et humaines.

C’est pour apporter des réponses concrètes à ces questions que nous avons rédigé
ce livre gratuit de plus de cent pages.
Pour avoir une vision complète du sujet, All4Test, pure player du Test logiciel en
France, et Chrysocode, expert de l’Ingénierie du Code et des Développements
Agiles, ont collaborés à la rédaction de cet opus.

Alors bonne lecture !

8/109
Objectifs

Auteurs

Expert Méthode & Qualité en Stratégie Auteur de GOST

IT, Coach Agile / Craftsmanship / Test [Link]
Fondateur & CEO de Chrysocode
Développeur de
TestAsYouThink
[Link]

Contributeur de
Wikipédia
Xavier [Link]
PIGEON contact@[Link]
[Link]

Xavier Pigeon est Ingénieur Logiciel, et évolue aujourd’hui en tant qu’Expert Méthode &
Qualité en Stratégie IT. Il est aussi l'auteur du framework méthodologique GOST dédié à une
approche holistique de gestion de la qualité logicielle et à la conception de stratégies
adaptatives de test.
Xavier se consacre au coaching organisationnel et technique, en associant étroitement
Agilité, Software Craftsmanship (artisanat du code et compagnonnage logiciel) et Test. Il
accompagne notamment les équipes dans leur cheminement vers l’excellence ingénierique,
en les guidant dans leur appropriation de méthodes et pratiques d’ingénierie alignées avec
un monde VUCA (volatile, incertain, complexe et ambigu).

En 2019, Xavier a fondé la marque CHRYSOCODE et sa société Chrysocode IT, un cabinet

de conseil dont il est le dirigeant.

CEO d’All4Test Co-auteur du livre Les

Tests Logiciels en Agile

[Link]
contact@[Link]

Julien
VAN QUACKEBEKE

9/109
Julien est passionné par le sujet du test et de la qualité et aime partager ses connaissances
sur le sujets. A ce titre il anime la communauté “test et qualité” de Telecom Valley (animateur
du numérique en PACA), il organise une fois par an la “Soirée du test logiciel”, créateur du
meetup “Software Tester Club” et co-rédacteur du livre du CFTL en 2019 Les tests logiciels
en Agile.

Julien Van Quackebeke est également le fondateur de la société ALL4TEST, un des

principaux pure player du test logiciel en France depuis 2006.

Consultant & Formateur Test / TODO

Test lead Automation

[Link]

Zied
HANNACHI

Zied Hannachi est un référent technique en automatisation de test, dont l'éventail des
technologies de programmation ou de test lui permettent d’intervenir dans de nombreux
contextes d’entreprise. Il consacre ses activités à implémenter des stratégies de test et des
solutions d’automatisation. Zied éprouve un attrait particulier pour les méthodes de Shift-Left
Testing comme Behavior-Driven Development. C’est ainsi qu’il a publié de nombreux articles
dont il fait profiter la communauté du test en France.
Zied a rejoint All4Test en 2017 où il a pu évoluer et participer à de nombreuses publications
sur l’automatisation des tests.

10/109
Pourquoi un livre dédié aux tests automatisés ?

Convaincus par le rôle incontournable des tests dans la création de logiciels de qualité, nous
voulons démocratiser les tests et leur automatisation, en rendant accessibles les choix
technologiques structuraux et les bonnes pratiques d’automatisation de test.

Avec le déploiement de l'agilité dans le entreprise, puis par la suite la mise en place du
DEvOps, les méthodes de travail on évoluées et la fréquences de livraison d’un logiciel a
augmenté.
La question n’est donc plus : est ce utile ou rentable d’automatiser les tests fonctionnels de
mon logiciel ?
En effet, il n’est simplement plus possible de garantir les rythme de livraison actuel sans
automatiser ces tests, au moins en partie.
L’enjeux est plutôt de savoir comment faire pour parvenir à automatiser ces tests avec une
approche “industrielle” et garantir que l’automatisation des test fonctionnera durant toutes la
vie du produit.
Mais le contexte peut varier : entre automatiser un historique de TNR (legacy) vieux de
plusieurs années et automatiser les tests de nouvelles fonctions “à la volée” dans une
équipe agile, le besoin n’est pas le même.
Automatiser des tests d’applications mobile, web ou un ERP là aussi les contraintes
techniques sont différents.
Il est donc nécessaire de bien definir le perimetre de votre projets d’automatisation en début
de projet, qui sera en charge de driver le projet, mais aussi de la maintenir

À qui ce livre est-il destiné ?

La vocation de ce livre est d'apporter une contribution utile à la communauté francophone
des praticiens du test logiciel. Nous nous sommes employés à écrire un contenu de qualité
et à en développer les idées de façon originale et authentique. Son ambition est d'apporter
des réponses concrètes que vous ne trouveriez pas ailleurs, à des questions qui nous
paraissent pourtant fondamentales dans l'automatisation des tests.
Nous destinons ce livre à tous ceux qui, néophytes ou experts du test, souhaitent élargir leur
vision du monde du Test.
Les novices y trouveront des recommandations et bonnes pratiques pour commencer un
projet, l’explication de l’architecture d’un framework d’automatisation de test, une
présentation des principaux outils du marché.

11/109
Les experts y trouveront des grilles de comparaison des outils afin de gagner du temps dans
leur stratégie d’automatisation de test.
TODO Julien

Vos retours nous sont précieux !

Souhaitez-vous nous faire un retour après avoir lu ce livre, voire pendant votre lecture ?
N'hésitez pas à nous écrire à l'adresse électronique suivante :
retour_lecteur_adtf2020@[Link]. Nous nous ferons un plaisir de vous répondre !

<================== À SÉLECTIONNER ET À INTÉGRER AU RESTE DU LIVRE

/!\ ATTENTION À NE PAS CONSERVER LA MISE EN FORME DE LA SOURCE !

Pourquoi et comment automatiser les tests fonctionnels ?

Automatisation des tests fonctionnels

Objectif: Le test automatisé a pour objectif de simplifier autant que possible les efforts de
test grâce aux scripts, nous permettant ainsi de réduire le risque de régression.
Les automatiser permet de garantir une couverture constante des fonctionnalités.

Comment: Utiliser les outils suivants :

● L’enregistreur de test : Il permet d’enregistrer les actions faites dans l’application. Il
permet de créer des scénarios de tests rapidement, mais demande généralement
d’être complété pour avoir une couverture satisfaisante.
● Les ‘players’ de test permettent de jouer les tests. Il existe deux grands types de
‘player’,
- Les locaux : ils tournent sur la machine de l’utilisateur et bloquent (au moins
partiellement) l’utilisateur (Ex : Selenium IDE, TestComplete, Katalon,
Ranorex).
- Les serveurs : ils tournent sur une machine liée ou non au projet. Ils sont plus
performants, ne bloquent pas l’utilisateur et peuvent s’intégrer dans un
workflow de développement (Ex : Selenium webdriver, IBM rational functional
tester, …). Les actions sont les différentes commandes qui seront jouées
dans un test. Cela va du clic à la gestion de variable, à la vérification
d’attribut.
● Les frameworks sont des outils d’écriture de tests. Il en existe dans de nombreux
langages. Ils ont différentes approches, allant du très technique au plus littéraire (Ex :
Nightwatch (JS), Behat (PHP), CodeCeption (PH, jBehave (java), Specflow (c#))
● Les drivers sont les connecteurs entre le ‘player’ de test et les navigateurs. Sur les
‘players’ locaux, ils sont généralement intégrés mais dans le cadre de Selenium

12/109
 webdriver (le serveur de tests le plus répandu), ils sont à installer indépendamment.

1- Framework d’automatisation de test

Un framework de test ou plus spécifiquement un framework d'automatisation de test est un

environnement d'exécution pour les tests automatisés. C'est le système global dans lequel
les tests seront automatisés. Il s'agit d'un ensemble d'hypothèses, de concepts et de
pratiques qui constituent une plate-forme de travail ou un support pour les tests automatisés.

Le framework de test est chargé de :

- Définir le format dans lequel exprimer les attentes.

- Créer un mécanisme pour connecter ou piloter l'application testée.
- Exécuter des tests
- Rapporter des résultats.

Propriétés d'un framework de test: Il est indépendant de l'application. Il est facile à

développer, maintenir et perpétuer.

13/109
6.2 Avantages des framework d’automatisation de test
L'utilisation d'une structure pour les tests automatisés augmentera la vitesse et l'efficacité
des tests d'une équipe, améliorera la précision des tests, réduira les coûts de maintenance
des tests et diminuera les risques. Les framework d’automatisation de tests sont essentiels à
un processus de test automatisé efficace pour plusieurs raisons :
● Amélioration de l'efficacité du test
● Réduction des coûts de maintenance
● Intervention manuelle minimale
● Couverture maximale des tests
● Réutilisation du code

2- Pyramide de tests

14/109
● On investit massivement sur les tests unitaires qui vont fournir une base solide à la
pyramide, avec un feedback précis et rapide. Couplés à l’intégration continue, les
tests unitaires fournissent un véritable harnais contre les régressions, indispensable
si l’on souhaite maîtriser notre composant à moyen/long terme.
● En haut de la pyramide, on réduit la quantité de tests de bout en bout ou IHM au
strict minimum : validation de l’intégration du composant dans le système global
(configuration, connectivité), composants graphiques faits maison, éventuellement
quelques smoke tests (en guise de tests d’acceptance).
● Et au milieu de la pyramide, les tests d’intégration nous permettent de valider le
composant (intégration interne) et ses frontières (intégration externe). Le principe est
là encore de privilégier les tests internes au composant (en isolation du reste du
système) par rapport aux tests externes, plus complexes à mettre en œuvre.

15/109
================================================>

16/109
Framework d’automatisation de test

17/109
La meilleure qualité logicielle... Un défi qu'on travaille la dessus chaque jour. Aujourd'hui, le
retour d'expérience m'a permis de mettre l'accent sur une étape primordiale de
l'automatisation des tests en entreprise qui est le choix du framework. Le choix d’un
framework approprié contribue à accroître la ré-utilisabilité et l’efficacité à long terme , en
effet un framework ne remplace pas un outil d’automatisation mais sert de feuille de route
pour l’utiliser de manière optimale. Dans un espace de stockage différent, il doit également
permettre de paramétrer les scripts de test et les données de test, pour que ces derniers
soient réutilisables autant que possible et plus simples à gérer.
- Zied Hannachi

Pourquoi recourir à un framework ?

Il est possible d’automatiser un test sans aucune méthode, ni aucune technologie autre que
les langages de programmation eux-mêmes et leur kit de développement respectif. Mais le
besoin des projets informatiques en matière d’automatisation va bien plus loin que quelques
tests seulement. Une application logicielle de quelques dizaines de milliers de lignes de
code, voire quelques centaines de milliers, aura besoin d’être qualifiée par des centaines,
puis des milliers de cas de test automatisés. Dès lors, se pose le problème du passage à
l’échelle, de ces quelques cas de test à des milliers, en terme d’efficacité et de coût. Ce
passage à l’échelle nécessite de coordonner les acteurs des projets qui contribuent aux
tests, et d’optimiser et rationaliser l’effort consenti à leur automatisation. C’est pour cette
raison qu’un projet ou un produit logiciel doit donner lieu à l’élaboration d’une stratégie de
test adaptée. Toute stratégie de test s’appuie sur des formes multiples de test pour répondre
aux problématiques de gestion de la qualité. Elle s’appuie également sur l’emploi de
méthodes, pratiques, processus et technologies d’ingénierie spécialisés afin de négocier
correctement ce passage à l’échelle des tests. Un framework d’automatisation de test, quel
qu’il soit, fournit des moyens pour implémenter une partie d’une stratégie de test, en
facilitant la standardisation et l’industrialisation des tests automatisés. Il est donc important
de prendre conscience tôt dans la vie des projets de ce besoin, et de faire des choix éclairés
de frameworks de test.

Qu'est-ce qu'un framework d'automatisation de test ?

Parmi toutes les sortes de framework que l’on peut rencontrer, un framework
d’automatisation de test est-il méthodologique ou informatique ? En fait, il peut avoir deux
sens, utilisés de façon exclusive. Et les aspects méthodologiques et informatiques sont
indissociables quand il s’agit d’un framework de test, même si selon le sens retenu, un
aspect peut l’emporter légèrement sur un autre.

Sens 1 : solution intégrée d’automatisation de test

C’est un ensemble de directives et de recommandations pour la mise en place de tests
automatisés, à tous les niveaux de test, dont l’objectif est de tirer tous les avantages
possibles de leur automatisation. Les directives portent sur :

18/109
 ● les règles et processus de collaboration,
● les conventions de codage,
● la gestion des jeux de données,
● la gestion des interactions simulées avec l’interface utilisateur,
● la gestion des environnements de test,
● l’utilisation de technologies relatives à l’automatisation et l’exécution des tests, ainsi
qu’à la gestion du patrimoine de test et à la génération de rapport,
● le suivi historisé des modifications apportées aux tests.

De telles préconisations visent à augmenter la productivité par la réutilisation du code entre

plusieurs cas de test, et à réduire les coûts de maintenance des tests face aux évolutions
d’un logiciel, ainsi que les coûts de correction des défauts en facilitant l’investigation.

Sous cet angle, un framework d’automatisation de test apporte un cadre de travail à la fois
méthodologique et informatique pour que l’automatisation des tests soit un succès par
rapport aux objectifs du projet logiciel global. Il intègre toutes les technologies nécessaires
pour implémenter une stratégie de test et automatiser toutes les formes de test pertinentes.
C’est généralement le sens le plus couramment utilisé par les testeurs logiciels, surtout
quand ils ont obtenu une certification1. D'après cette définition d'un framework, une stratégie
d'automatisation de test s'appuie sur un unique framework d'automatisation de test.
Il semble que cette définition d’un framework d'automatisation de test convienne bien mieux
à une solution intégrée d'automatisation de test en vérité, voire à une stratégie
d'automatisation de test.

Sens 2 : cadre logiciel de développement de test automatisé

C’est une technologie informatique pour l’écriture et l’exécution des tests automatisés, à un
niveau de test, voire plusieurs, qui a un impact important sur l’écriture par programmation
des cas de test et leur structuration selon un cycle de vie donné. Selon les choix effectués
lors de sa conception, une telle technologie offrira des facilités plus ou moins appréciées de
ceux qui développent et maintiennent les tests, et notamment un équilibre entre convention
et configuration. Plus de conventions signifient des choix d'utilisation déjà établis par défaut
par les concepteurs, et donc une standardisation accrue des usages, même entre projets,
sachant qu’il reste éventuellement possible de surcharger certains choix par défaut par une
personnalisation. La mise en place de conventions lisse également la courbe
d’apprentissage. Au contraire, plus de configurations impliquent une définition des choix de
personnalisation préalable à l’écriture des tests, et donc plus de travail. Les possibilités de
configuration sont néanmoins importantes, car elles apportent de la flexibilité.

Sous cet angle, un framework d’automatisation de test représente un moyen informatique

pour le développement de tests automatisés. C’est généralement le sens le plus
couramment utilisé par les développeurs logiciels, qui utilisent déjà des frameworks de
développement pour la création de logiciel, et bien évidemment par les concepteurs de
framework de développement ou de test, open source ou propriétaire. Les frameworks

1
ISTQB, syllabus Niveau Avancé Automatisation de Test 2016, pp 14-15,
[Link]

19/109
d’automatisation de test ont toutefois ceci de particulier qu’ils sont généralement enrichis et
complétés de fonctions spécifiques aux logiciels testés au cours de l’automatisation des
tests. Nous retrouverons d’ailleurs cette notion d'extension en définissant certains types de
framework. Ces facilités ne sont pas uniquement fonctionnelles et peuvent prendre une
tournure technique, quand elles relèvent de l'intégration de bibliothèques de test
spécialisées, comme dans le chargement de données ou dans les assertions de test. Sous
cet angle toujours, un framework d'automatisation de test revêt donc une nature composite
en réunissant les différentes technologies nécessaires à l'implémentation d'une forme de
test donnée, afin d'être complet.
D'après cette définition d'un framework, une stratégie d'automatisation de test peut
s'appuyer sur plusieurs frameworks d'automatisation de test, spécialisés et mieux adaptés
chacun à une forme de test. Finalement, c’est cette définition d’un framework
d’automatisation de test qui nous semble la plus pertinente et la plus pragmatique.

Par ailleurs, un framework d’automatisation de test est souvent aligné avec un cadre
méthodologique, soit relatif au domaine du test, soit relatif au domaine de la conception
logicielle. Ce n’est donc pas surprenant que les types de framework mentionnés plus tard
reprennent les noms de méthodes bien connues pour s’identifier à elles. Gardons toutefois à
l’esprit que ces frameworks ne font qu’apporter un support technologique à des méthodes
de travail : ils ne sauraient en aucun cas s’y substituer, en particulier en terme de
collaboration, de processus et de livrable.

Par ordre alphabétique :

Méthode Domaine d’ingénierie Objectifs

prévalent

Acceptance Test-Driven Méthode de ● Heuristique du besoin et

Development (ATDD) spécification compréhension partagée
● Approche itérative du
développement guidée
par les tests
● Automatisation des tests
d’acceptation
recommandée

Behavior-Driven Méthode de ● Heuristique du besoin et

Development (BDD) spécification compréhension partagée
● Approche itérative du
développement guidée
par les tests, du général
au spécifique
● Création d’une
spécification exécutable
et d’une documentation
vivante par
automatisation des tests

20/109
 Data-Driven Testing (DDT) Méthode de test ● Partitions d’équivalence
● Analyse des valeurs
limites

Keyword-Driven Testing Méthode de test ● Structuration des tests en

(KDT) mots d’action

Model-Based Testing (MBT) Méthode de test ● Conception des cas de

test sous forme
d’organigrammes
logiques
● Génération de plusieurs
cas de test à partir d’un
organigramme

Modularity-Driven Testing Méthode de test ● Construction hiérarchisée

(MDT) et ascendante des tests
fonctionnels

Test-Driven Development Méthode de ● Découpage du problème

(TDD) développement à résoudre par petits pas
● Approche incrémentale
et itérative du
développement guidé par
les tests
● Simplification de la
conception
● Conception émergente
par remaniement de
code

Cela peut paraître évident aux uns, surprenant pour d’autres : TDD/ATDD/BDD ne sont pas
des méthodes de test, qui seraient utilisées pour augmenter la couverture du code, à des
fins de non-régression, ni de près ni de loin. Ces méthodes s’appuient certes sur les tests,
qu’ils soient automatisés ou non, mais leurs bénéfices dépassent largement le cadre de la
définition des cas de test et de l’automatisation des tests de non-régression. En fait, elles
détournent les tests tels une trame, un caneva pour structurer et guider le processus de
développement depuis l’heuristique d’un besoin jusqu’à livraison. D’ailleurs, elles ont ceci en
commun qu’elles participent toutes du Shift Left Testing, cette approche moderne du Test qui
consiste à anticiper les activités de test par rapport à une approche prédictive et de contrôle
qualité traditionnelle, en les mettant à profit tôt dans le processus pour spécifier, concevoir et
développer, et non pas seulement tester. TDD détourne les tests pour découper la résolution
d’un problème par petits pas et pour faire émerger des conceptions qui répondent avec
justesse à un besoin par des remaniements en continu du code. ATDD et BDD les
détournent à leur tour pour explorer le besoin en le scénarisant, et pour le distiller en une
compréhension partagée de tous, jusqu’à constituer une spécification exécutable pour BDD.
À chaque fois, les tests sont une clé de voûte d’un édifice plus ambitieux.

21/109
 Méthode de développement Test-Driven Development (TDD) et son cycle global2

2
Wikipédia, Test-Driven Development, [Link]

22/109
TDD ne sera plus évoqué par la suite, car il n’existe pas de framework d’automatisation de
test qui s’y rapporterait en particulier, tous les frameworks implémentant le cycle
Préparation-Exécution-Suppression étant suffisant à la pratique de TDD. En revanche, il
existe une API de test pro-TDD qui a la faculté de rendre les bonnes pratiques de test
exécutables en favorisant une pratique stricte de TDD, TDD As If You Meant It : c'est
TestAsYouThink Core.
ATDD ne sera plus évoqué non plus, car les frameworks de Data-Driven Testing, de
Keyword-Driven Testing et de Behavior-Driven Development, que nous traiterons dans ce
livre, seront les mêmes employés à l’automatisation des tests qu’en ATDD.
Même si BDD met essentiellement l’accent sur les règles du métier, et que les interfaces
utilisateur ne sont qu’un moyen d’interagir avec le comportement d’un logiciel, nous
étudierons le framework BDD au sein de la typologie des frameworks d’automatisation de
test fonctionnel, car son formalisme, Gherkin, n’est pas restrictif et peut s’appliquer aux tests
fonctionnels d’interface utilisateur d’une part, et que nous avions à cœur de produire une
typologie exhaustive.

Framework versus Bibliothèque

La différence fondamentale entre un framework et une bibliothèque est l'inversion du flux
d'exécution, que l'on appelle le principe d’inversion de contrôle, et parfois le principe
Hollywood : "Ne nous appelez pas, c'est nous qui vous appellerons." (“Don’t call us, we’ll
call you!”) Une bibliothèque est invoquée à l'exécution en fonction des instructions du
programmeur. Au contraire d'un framework, les instructions du programmeur sont exécutées
en fonction du framework. Si on observe la pile d'exécution d'un logiciel, qui contient les
instructions à exécuter par la machine dans l'ordre chronologique, on constate que les
instructions du framework apparaissent avant et après les instructions du programmeur,
alors que les instructions qui font appel à une bibliothèque et celles de la bibliothèque
elle-même sont insérées parmi d'autres instructions du programmeur. Comment cela se
concrétise-t-il lors du développement ? Un framework impose son cadre de développement
soit par des méthodes abstraites qu’il faut implémenter et des classes abstraites dont il faut
hériter, soit par des annotations compilées portant sur des classes ou des méthodes, qui les
rendent reconnaissable par un framework et qui peuvent également spécifier le
comportement attendu du framework.

Les frameworks ont donc la capacité de définir eux-mêmes un cycle de vie, que ce soit
celui d'une application ou des objets instanciés par cette application. En particulier, tout
framework de test définit un cycle de vie des tests, ordonné en 3 phases.
● Préparation, pour constituer le contexte d'exécution du test.
● Exécution, pour dérouler le cas de test en appelant le sujet de test et en vérifiant
ses résultats.
● Suppression, pour effacer toute conservation d'état, ou effet de bord, entre deux cas
de test.
La plupart des frameworks de test implémentent ce cycle de vie à deux niveaux : un cycle
complet pour les cas de test, lui-même imbriqué dans un cycle simplifié pour les suites de
test (préparation et suppression seulement), sachant que ces dernières correspondent à une
organisation logique des cas de test. En faisant une utilisation éclairée d'un framework de

23/109
test, un automaticien structurera donc son code entre ces différentes phases, jusqu'à
organiser ses cas de test dans des suites appropriées. Si la syntaxe change d'un framework
à un autre, la sémantique reste la même.

TODO Xavier : un schéma

Cycle de vie standard des frameworks de test

TODO Xavier : donner des exemples de syntaxe avec JUnit, Jasmine, etc.

Les bibliothèques quant à elles sont spécialisées dans une activité de test, par exemple
l'utilisation de doublures de test, dont les bases de données en mémoire, l'utilisation d'un
oracle de test (assertions de test), l'instanciation d'un serveur ou d'une base de données
persistante, etc. Selon leur objectif, ces bibliothèques sont invoquées soit seulement lors de
la préparation et de la suppression, car elles satisfont des dépendances uniquement
consommées par le sujet de test, soit à chaque phase, à des fins de vérification pour la
phase d'exécution. En bref, les bibliothèques de test observent le cycle de vie implémenté
par les frameworks de test. Et elles peuvent même choisir de s'intégrer à certains
frameworks s'ils offrent des facilités d'extension de leurs fonctionnalités. À noter que cette
intégration ne fait pas d'une bibliothèque un framework : c'est toujours le framework qui
contrôle le flux d'exécution, pas l'inverse, même si la documentation officielle d'une
bibliothèque peut parfois déclarer le contraire.

24/109
Typologie des Frameworks d’automatisation de
test

Photographie par David Billings sur Unsplash

25/109
Démarche
Nous allons passer en revue tous les types de framework d’automatisation de test
fonctionnel. Par test fonctionnel, nous entendons tout test qui simule, par des interactions
avec une interface homme-machine, l’utilisation d’une fonctionnalité telle qu’elle est conçue
pour des utilisateurs humains, dans les exigences fonctionnelles d’un produit logiciel. Cette
forme de test ne doit pas être confondue avec le test de bout en bout : un test de bout en
bout consiste à exécuter un test en mettant le sujet de test en présence de toutes ses
dépendances, internes et externes, directes ou transitives. Ce dernier relève donc d’un choix
à l’exécution, et non de conception du cas de test.
Certains frameworks, que nous aborderons plus tard dans les technologies d’automatisation
de test, permettent parfois d’automatiser d’autres formes de test en plus des tests
fonctionnels. Toutefois, nous nous intéresserons uniquement à l’automatisation des tests
fonctionnels dans ce livre.

Tests fonctionnels d’interface utilisateur dans la Pyramide des tests

Chaque type de framework sera étudié selon le même plan.

1. Définition : qu’est-ce qui distingue un type de framework, quels sont ses concepts ?
2. Utilisation : au travers d’un exemple concret d’application, comment automatiser un
cas de test ?
3. Observations : que faut-il retenir de ce type de framework, quelles sont ses forces
et faiblesses ?

26/109
Types de framework
S’agissant d’automatisation de test, nous avons recensé les types de framework suivants.
Cette liste se veut exhaustive à ce jour.

Types de framework d’automatisation des tests

En Anglais En Français

Linear scripting framework Framework par script linéaire

Record & Playback framework Framework par capture et rejeu
Record & Replay framework

Modular-based testing framework Framework par tests modulaires

Module-based testing framework Framework par script modulaire
Modular framework Framework modulaire de test
Test modularity framework

Function library based testing framework Framework de test fondé sur des
Library architecture testing framework bibliothèques de fonctions
Framework de bibliothèques de fonctions
de test

Data-Driven Testing framework Framework de test piloté par les données

Framework de Data-Driven Testing (DDT)

Keyword-Driven Testing framework Framework de test piloté par mots d’action

Action Word-Based Testing framework Framework de Keyword-Driven Testing
Table-Driven Testing framework (KDT)
Framework de mots d’action

Hybrid testing framework Framework de test hybride

Component-based testing framework Framework de test fondé sur des

composants

Behavior-Driven Development framework Framework de développement piloté par les

comportements
Framework de Behavior-Driven
Development (BDD)
Framework de Gherkin

Model-Based Testing framework Framework de test fondé sur les modèles

Framework de Model-Based Testing (MBT)

Comme nous le verrons plus en détails, certains frameworks entretiennent des relations
entre eux, par extension ou par combinaison.

27/109
Scénario fil rouge
Nous nous servirons d’un scénario de test comme fil rouge, afin d’accompagner chaque
définition de framework d’un exemple pratique de cas de test d’une
part, et de faciliter la comparaison des types de framework d’autre
part. Ce fil rouge s'étendra jusqu'aux implémentations de framework,
pour fournir des exemples d'automatisation : ces exemples
automatiseront un cas de test avec chacune des implémentations de
framework.

Considérons une application web “Todos” qui permet de gérer une

liste de tâches. Elle offre les fonctionnalités suivantes :
● ajouter une tâche,
● terminer une tâche,
● supprimer une tâche.

Un scénario possible pour un test fonctionnel est fourni ci-après, étape par étape.

Type d’étape Étape

Exécution J’ajoute une tâche “Définir ce qu’est un framework”.

Exécution J’ajoute une tâche “Écrire un scénario”.

Exécution J’ajoute une tâche “Comparer les types de framework”.

Vérification 3 nouvelles tâches sont à faire : “Définir ce qu’est un framework”,

“Écrire un scénario”, “Comparer les types de framework”.

Exécution Je termine la tâche “Définir ce qu’est un framework”.

Vérification La tâche “Définir ce qu’est un framework” est terminée.

Vérification Les tâches suivantes sont à faire : “Écrire un scénario”, “Comparer

les types de framework”.

Exécution Je supprime la tâche “Définir ce qu’est un framework”.

Vérification Il reste 2 tâches dans la liste.

Vérification Les tâches suivantes sont à faire : “Écrire un scénario”, “Comparer

les types de framework”.

NB : Ce scénario sera implémenté en pseudo-code pour produire un test automatisé par la

suite. Ce pseudo-code reflétera les capacités d’un type de framework, notamment en terme
de spécification du comportement de l’application. L’application comme le scénario se

28/109
veulent relativement simples, pour nous focaliser sur les singularités de chaque type de
framework plutôt que sur l’application elle-même.

Avantages et inconvénients supposés

Les compétences en programmation comme prérequis à l'automatisation des tests sont
parfois interprétées comme un inconvénient. C'est un peu un comble dans le monde du
Logiciel et de l'IT... Nous croyons au contraire que l'automatisation programmatique des
tests est riche de nouvelles possibilités et opportunités. La programmation ouvre de
nouvelles perspectives pour le métier de testeur, en le renouvelant, et elle doit être accueillie
avec enthousiasme. De fait, maîtriser la programmation permet d'accéder à des pratiques
plus avancées dans l'automatisation des tests. Par ailleurs, comment aujourd'hui
pourrions-nous justifier qu'un testeur soit réticent à l'idée de se former en programmation
quand on demande aux développeurs de prendre une part de plus en plus active dans
l'automatisation des tests ? Qui plus est, sans compétence en programmation, la plupart des
frameworks d'automatisation de test que nous verrons dans ce livre sont inaccessibles,
même ceux qui paradoxalement supportent une formulation littérale.

Certains frameworks reposent sur une formulation littérale des cas de test. Si cela semble
forcément avantageux en terme de collaboration avec les non-développeurs, il faut aussi
considérer qu'élever le niveau de formalisme des cas de test s'accompagne de quelques
contre-coûts qu'on aurait tort de négliger : quitte à les assumer, autant s'assurer qu'ils sont
contre-balancés par une utilité réelle dans un contexte donné. Les gains pour une approche
agile des développements peuvent être considérables, notamment par une collaboration
renforcée, à condition de satisfaire quelques prérequis sine qua none.
● Les tests servent-ils à spécifier le logiciel ? Ou au contraire, sont-ils utilisés à seule
fin de non-régression ?
● Le porteur de produit ou l’analyste métier contribue-t-il à rédiger les cas de test à
vérifier, voire les tests d’acceptation émanant des utilisateurs ? Ou au contraire, les
développeurs sont-ils seuls à les formuler ?
● L’impact des changements est-il étudié en mettant à jour la définition des cas de test
ciblés par ces changements ? Ou au contraire, attend-on que les tests cassent pour
analyser s’il s’agit d’un impact souhaité ou d’une régression ?

Comprendre les types de framework de test

Framework par script linéaire

Définition
Un framework par script linéaire, ou linear scripting framework en Anglais, consiste à
enregistrer une première fois le déroulement manuel d’un script manuel de test, puis à
rejouer automatiquement et à l’identique la séquence des interactions homme-machine
précédemment enregistrées. Ce type de framework est aussi appelé framework “Record &
Playback” (parfois aussi nommé “Record & Replay”).

29/109
Les tests à enregistrer doivent d’abord être définis sur un support quelconque (papier ou
logiciel), puis déroulés manuellement par un opérateur humain pour être capturés par
l’enregistreur fourni par le framework de test. Cet enregistreur est un programme qui
convertit les interactions de l’opérateur en une suite d’instructions dans un langage de script
ou de programmation. Il faut ensuite vérifier que chaque test enregistré est exécuté avec
succès par l’automate, et l’adapter si besoin.

Exemple de framework : Selenium IDE

Utilisation
Après enregistrement, le scénario de test précédent donnerait lieu au script de test
ci-dessous, en pseudo-code. Nous avons laissé les types d’étape seulement pour en faciliter
la compréhension. Les fonctions invoquées dans le script sont natives, c'est-à-dire fournies
par le framework de test, c'est pourquoi elles sont précédées d'un trait de soulignement.

TODO Xavier : réécrire ce pseudo-code.

Type d’étape Étape

Exécution déplacer_focus_par_id(“nouvelle description”)

taper(“Définir ce qu’est un framework”)
taper_entrer()

Déplacer le focus sur le champ “nouvelle description”.

Taper “Définir ce qu’est un framework”.
Taper Entrer.

Exécution déplacer_focus_par_id(“nouvelle description”)

taper(“Écrire un scénario”)
taper_entrer()

Déplacer le focus sur le champ “nouvelle description”.

Taper “Écrire un scénario”.
Taper Entrer.

Exécution déplacer_focus_par_id(“nouvelle description”)

taper(“Comparer les types de framework”)
taper_entrer()

Déplacer le focus sur le champ “nouvelle description”.

Taper “Comparer les types de framework”.
Taper Entrer.

Vérification Sélectionner le champ “description de tâche” de la tâche 1.

30/109
 Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 1 à “Définir ce qu’est un
framework”.
Sélectionner la case à cocher “case à cocher 1” de la tâche 1.
Vérifier que la case à cocher sélectionnée est décochée.
Sélectionner le champ “description de tâche” de la tâche 2.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 2 à “Écrire un scénario”.
Sélectionner la case à cocher “case à cocher 2” de la tâche 2.
Vérifier que la case à cocher sélectionnée est décochée.
Sélectionner le champ “description de tâche” de la tâche 3.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 3 à “Comparer les types de
framework”.
Sélectionner la case à cocher “case à cocher 3” de la tâche 3.
Vérifier que la case à cocher sélectionnée est décochée.

Exécution Sélectionner la case à cocher “case à cocher 1” de la tâche 1.

Cocher la case à cocher sélectionnée.

Vérification Vérifier que la case à cocher de la tâche 1 est à l’état coché.

Vérification Sélectionner la case à cocher “case à cocher 2” de la tâche 2.

Vérifier que la case à cocher sélectionnée est à l’état décoché.
Sélectionner la case à cocher “case à cocher 3” de la tâche 3.
Vérifier que la case à cocher sélectionnée est à l’état décoché.

Exécution Sélectionner le bouton “supprimer” de la tâche 1.

Cliquer sur le bouton “supprimer” de la tâche 1.

Vérification Sélectionner la liste “liste de tâches”.

Comparer la taille de la liste à 2.

Vérification Sélectionner les cases à cocher de la liste “liste de tâches”.

Pour chaque case à cocher de la liste, comparer son état à
décoché.

Observations
● À noter que toutes les étapes de vérification doivent être ajoutées après
l’enregistrement des interactions homme-machine, en modifiant le code du test
généré : l’enregistreur n’intercepte que les interactions.
● Le test obtenu est verbeux et des lignes de code similaires reviennent souvent. En
développement logiciel, on parle de duplications. Et plus un code est dupliqué, moins
il est maintenable.

31/109
 ● Le test est au plus près des clics de souris et des frappes de clavier, sans aucune
abstraction qui permettrait d’appréhender les intentions de l’utilisateur.
○ Ce test ne peut pas servir de spécification, car sa lecture reste hermétique.
Le scénario de départ semblait particulièrement simple en comparaison.
○ Pour remédier à cela, il est possible d’accoler une documentation au code du
test. Toutefois, il faudra bien penser à mettre à jour la documentation du test
à chaque modification du code de test.
○ Il sera difficile de reprendre ce test pour le modifier. Le réenregistrer sera plus
rapide.
○ Si la technologie de développement change, le test sera jeté.
● Si l’écran de l’application est modifié, il faudra modifier le code du test à de multiples
endroits pour les mêmes raisons, à cause des duplications, ou bien regénérer le
code du test et réécrire les vérifications.
● Les données sont écrites dans le script de test.

Framework par tests modulaires

Définition
Un framework par tests modulaires, ou un framework modulaire de test, modular-based
testing framework en Anglais, consiste à développer des scripts de test automatisés
regroupés d'après des modules fonctionnels. Ces modules doivent remplir plusieurs
conditions :
● les modules sont identifiés d’après des thèmes macro-fonctionnels du produit ;
● les modules couvrent entièrement les fonctionnalités du produit ;
● les modules correspondent à un découpage vertical de l’application à tester,
autrement dit ils sont matérialisés comme modules de l’architecture applicative ;
● les modules peuvent être testés séparément, en isolation.
La conception des cas de test repose donc sur l’architecture de l’application testée : pour
chaque module isolé de l’architecture applicative, il existe un module de tests. Par
conséquent, ce type de framework est uniquement adapté à une architecture modulaire.

Les tests modulaires doivent être développés de manière à réutiliser le code de test pour
des cas de test dont le scénario couvrira plusieurs modules. Pour cela, deux possibilités
s’offrent à nous :
● soit les méthodes de test appelées directement par un cas de test modulaire sont
réutilisables par un cas de test inter-module ;
● soit les méthodes de test sont séparées du cas de test modulaire et appelées par
l’intermédiaire de méthodes-étapes, auquel cas les méthodes-étapes sont
spécifiques d’un cas de test et seules les méthodes de test sont développées pour
être réutilisées.
Mais cette dernière possibilité dépasse déjà le cadre du framework modulaire et s'inscrit
plutôt dans celui du framework de bibliothèques de fonctions de test.

Les tests sont construits de manière ascendante, du périmètre d’un module au périmètre de
plusieurs modules. La hiérarchisation entre tests modulaires, couvrant un seul module, et

32/109
tests intermodulaires, couvrant plusieurs modules, s’applique de la même façon aux tests
fonctionnels qu’aux tests d’intégration ascendants.

Scripts de test modulaires et intermodulaires

La construction hiérarchisée des tests permet de niveler la difficulté d'automatisation des

tests, et de structurer par étapes la réutilisation du code de test.
Les tests modulaires constituent un premier niveau d'abstraction, de sorte que des
changements fonctionnels peuvent avoir un impact sur les tests modulaires mais pas sur les
tests intermodulaires. La maintenance des tests n'en sera que plus facile.
La séparation des tests par module permet d'anticiper et circonvenir les impacts du
changement dans un module, sans déborder sur d'autres modules.

Utilisation
Juste à titre d’exemple, on peut imaginer que notre application de gestion de tâches est
architecturée en deux modules : un module dédié à la gestion des nouvelles tâches, l’autre à
celle des tâches existantes. Le module “Nouvelles Tâches” est donc capable de créer une
tâche et de la restituer ; le module “Tâches Existantes” de terminer ou supprimer une tâche,
et de restituer l’état d’une tâche modifiée.

TODO Xavier : réécrire ce pseudo-code.

Module Script de test

33/109
Nouvelles Script NT1 : créer 3 nouvelles tâches
Tâches Déplacer le focus sur le champ “nouvelle description”.
Taper “Définir ce qu’est un framework”.
Taper Entrer.
Déplacer le focus sur le champ “nouvelle description”.
Taper “Écrire un scénario”.
Taper Entrer.
Déplacer le focus sur le champ “nouvelle description”.
Taper “Comparer les types de framework”.
Taper Entrer.
Sélectionner le champ “description de tâche” de la tâche 1.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 1 à “Définir ce qu’est un
framework”.
Sélectionner la case à cocher “case à cocher 1” de la tâche 1.
Vérifier que la case à cocher sélectionnée est décochée.
Sélectionner le champ “description de tâche” de la tâche 2.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 2 à “Écrire un scénario”.
Sélectionner la case à cocher “case à cocher 2” de la tâche 2.
Vérifier que la case à cocher sélectionnée est décochée.
Sélectionner le champ “description de tâche” de la tâche 3.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche 3 à “Comparer les types de
framework”.
Sélectionner la case à cocher “case à cocher 3” de la tâche 3.
Vérifier que la case à cocher sélectionnée est décochée.

Tâches Script TE1 : terminer ou supprimer des tâches existantes

Existantes Sélectionner la liste “liste de tâches”.
Si la liste sélectionnée est vide, injecter le jeu de données de test “3
tâches”.

Sélectionner la case à cocher “case à cocher 1” de la tâche 1.

Cocher la case à cocher sélectionnée.
Vérifier que la case à cocher de la tâche 1 est à l’état coché.
Sélectionner la case à cocher “case à cocher 2” de la tâche 2.
Vérifier que la case à cocher sélectionnée est à l’état décoché.
Sélectionner la case à cocher “case à cocher 3” de la tâche 3.
Vérifier que la case à cocher sélectionnée est à l’état décoché.
Sélectionner le bouton “supprimer” de la tâche 1.
Cliquer sur le bouton “supprimer” de la tâche 1.
Sélectionner la liste “liste de tâches”.
Comparer la taille de la liste à 2.
Sélectionner les cases à cocher de la liste “liste de tâches”.
Pour chaque case à cocher de la liste, comparer son état à décoché.

Supprimer toutes les tâches persistées.

34/109
Vous remarquerez que nous avons ajouté au script TE1 une étape de préparation, afin
d’alimenter l’application en données de test, ainsi qu’une étape de suppression, afin de
supprimer tout résidu du contexte de test. Ainsi nos deux premiers scripts sont
indépendants, et peuvent être exécutés séparément et dans n’importe quel ordre. Le jeu de
données de test “3 tâches” est conçu de la façon suivante.
Numéro Description Tâche terminée

1 Définir ce qu’est un framework Faux

2 Écrire un scénario Faux

3 Comparer les types de framework Faux

Le script de test intermodulaire est implémenté comme suit.

Script de test

Script IM1 : créer puis modifier des tâches

Script NT1 : créer 3 nouvelles tâches
Script TE1 : terminer ou supprimer des tâches existantes

Nous obtenons ainsi un exemple de l’utilisation d’un framework d’automatisation par tests
modulaires.

Application Todos : scripts de test modulaires

35/109
Observations
● Un petit script de test automatisé tôt après la livraison d’une nouvelle fonctionnalité
peut déjà être exécuté à des fins de non-régression. Il sera réutilisable par la suite,
sans duplication. Son retour sur investissement sera d’autant plus important.
● Il est possible d’exécuter de petits scripts de test indépendamment de scripts de test
beaucoup plus longs. Les plus petits ont d’autant plus de valeur qu’ils fournissent un
retour très rapide sur la stabilité d’une application : ils peuvent donc être exécutés
très fréquemment, et tôt après les modifications apportées au code source. Les
scripts les plus longs sont aussi les plus longs à l’exécution : leur valeur est de
détecter des régressions à plus large échelle.
● L’organisation des scripts de test par module simplifie l’automatisation des tests en
réduisant le périmètre à couvrir à un seul module. Par la suite, leur combinaison
permet d’obtenir des scripts plus élaborés, couvrant des processus métier, sans coût
supplémentaire.
● Les données sont écrites dans le script de test : changer les données implique de
dupliquer un script de test. Toutefois, des variantes d’un script modulaire sont
interchangeables dans des scripts intermodulaires.

Framework de test fondé sur des bibliothèques de fonctions

Définition
Un framework de test fondé sur des bibliothèques de fonctions, ou function library-based
testing framework en Anglais, consiste à développer des tests automatisés en s'appuyant
sur des fonctions de test paramétrables et réunies dans une ou des bibliothèques de test.
Ces fonctions de test sont elles-mêmes conçues en partant de scripts de test couvrant
séparément des modules fonctionnels de l'application à tester, modules répondant aux
mêmes critères que ceux d'un framework modulaire de test. Leur degré de réutilisabilité est
supérieur à celui d'un script de test, car elles sont capables de recevoir des données
d'entrée en paramètres. Du fait de leur réutilisabilité, les bibliothèques de fonctions de test
sont mises à profit pour automatiser n'importe quels cas de test, qu'ils soient modulaires ou
intermodulaires.

Un framework de bibliothèques de fonctions de test requiert une meilleure structuration du

code de test que les scripts de test précédents, que ce soit par script linéaire ou par script
modulaire. Cette organisation du code de test fait qu'on abandonne la programmation
déstructurée pour adopter la programmation structurée : le code source est divisé en
procédures ou fonctions, c'est-à-dire des séquences d'instructions séparées, qui peuvent
être invoquées indépendamment en passant des arguments. C'est pourquoi, s'agissant du
framework de bibliothèques de fonctions de test, on parle aussi parfois de scripts structurés
ou de décomposition fonctionnelle, qui correspond à l'analyse et la résolution d'un problème
en plusieurs fonctions et sous-fonctions.

36/109
 Bibliothèque de fonctions de test

Une bibliothèque de fonctions de test est utilisée à travers son interface de programmation,
ou API (Application Programming Interface), c'est-à-dire la liste des fonctions exposées
publiquement en vue de programmer des cas de test automatisés. Ces fonctions respectent
un contrat d'utilisation entre celui qui automatise les tests et celui qui conçoit ces fonctions.
Ce contrat vise à faciliter l'appropriation d'une bibliothèque de fonctions de test par ceux qui
l'utiliseront, à maîtriser les impacts d'un changement d'implémentation d'une fonction sur les
tests automatisés, selon qu'il y a rétrocompatibilité ou non. En cas de large diffusion d'une
bibliothèque de test, le contrat global d'une API pourra être suivi en fonction d'un système de
numérotation de version, telle que le versionnage sémantique.

Utilisation
Revenons à notre application de gestion de tâches architecturée en deux modules : un
module dédié à la gestion des nouvelles tâches, l’autre à celle des tâches existantes.
Comme précédemment, le module “Nouvelles Tâches” est donc capable de créer une tâche
et de la restituer ; le module “Tâches Existantes” de terminer ou supprimer une tâche, et de
restituer l’état d’une tâche modifiée. Les scripts de test précédents, linéaires puis
modulaires, faisaient apparaître nombre de duplications. Ce code de test va enfin pouvoir
être factorisé dans des fonctions de test.

TODO Xavier : réécrire ce pseudo-code.

Fonctions de test

37/109
 fonction ajouter_une_tâche($description)
Déplacer le focus sur le champ “nouvelle description”.
Taper $description.
Taper Entrer.

fonction une_tâche_devrait_être_à_faire($id, $description)

Sélectionner le champ “description de tâche” de la tâche $id.
Obtenir la valeur textuelle du champ sélectionné.
Comparer la description de la tâche à $description.
Sélectionner la case à cocher “case à cocher $id” de la tâche $id.
Vérifier que la case à cocher sélectionnée est décochée.

fonction une_tâche_devrait_être_finie($id, $description)

Sélectionner la case à cocher “case à cocher $id” de la tâche $id.
Vérifier que la case à cocher sélectionnée est décochée.

fonction terminer_une_tâche($id)
Sélectionner la case à cocher “case à cocher $id” de la tâche $id.
Cocher la case à cocher sélectionnée.

fonction supprimer_une_tâche($id)
Sélectionner le bouton “supprimer” de la tâche $id.
Cliquer sur le bouton “supprimer” de la tâche $id.

Ces fonctions sont placées dans une bibliothèque. Les scripts de test vont pouvoir les
utiliser directement. Nous aurions pu créer davantage de fonctions, mais nous avons préféré
nous concentrer sur la factorisation du code dupliqué.

Module Script de test

Nouvelles Script NT1 : créer 3 nouvelles tâches

Tâches ajouter_une_tâche(“Définir ce qu’est un framework”)
ajouter_une_tâche(“Écrire un scénario”)
ajouter_une_tâche(“Comparer les types de framework”)
une_tâche_devrait_être_à_faire(1, “Définir ce qu’est un framework”)
une_tâche_devrait_être_à_faire(2, “Écrire un scénario”)
une_tâche_devrait_être_à_faire(3, “Comparer les types de framework”)

Tâches Script TE1 : terminer ou supprimer des tâches existantes

Existantes Sélectionner la liste “liste de tâches”.
Si la liste sélectionnée est vide, injecter le jeu de données de test “3
tâches”.

terminer_une_tâche(1)
une_tâche_devrait_être_finie(1, “Définir ce qu’est un framework”)
une_tâche_devrait_être_à_faire(2, “Écrire un scénario”)
une_tâche_devrait_être_à_faire(3, “Comparer les types de framework”)
supprimer_une_tâche(1)
Sélectionner la liste “liste de tâches”.

38/109
 Comparer la taille de la liste à 2.
Sélectionner les cases à cocher de la liste “liste de tâches”.
Pour chaque case à cocher de la liste, comparer son état à décoché.

Supprimer toutes les tâches persistées.

Le jeu de données de test “3 tâches” est conçu de la façon suivante.

Numéro Description Tâche terminée

1 Définir ce qu’est un framework Faux

2 Écrire un scénario Faux

3 Comparer les types de framework Faux

Le script de test intermodulaire est implémenté comme suit.

Script de test

Script IM1 : créer puis modifier des tâches

Script NT1 : créer 3 nouvelles tâches
Script TE1 : terminer ou supprimer des tâches existantes

Nous obtenons ainsi un exemple de l’utilisation d’un framework d’automatisation de test

fondé sur des bibliothèques de fonctions.

Application Todos : scripts de test modulaires utilisant une bibliothèque de fonctions de test

39/109
Observations
● Les fonctions de test réduisent fortement les duplications du code test, et
augmentent ainsi considérablement sa maintenabilité.
● Les scripts de test sont plus courts et plus lisibles.
● L'utilisabilité d'une bibliothèque de fonctions repose sur la qualité de conception de
son API. Cela requiert des compétences de conception logicielle en plus de
compétences de programmation.
● Les données sont écrites dans les cas de test automatisés, mais elles sont
transmises des cas de test aux fonctions de test sous forme d'arguments.

Framework de test piloté par les données

Définition
Un framework de test piloté par les données, ou Data-Driven Testing framework en Anglais,
consiste à aborder l’automatisation d’un cas de test à partir de ses données d’entrée et de
sortie : les données d’entrée servent à la préparation du contexte et à l’exécution des
actions, tandis que les données de sorties servent à vérifier les résultats obtenus. Ces
données sont appairées dans un seul et même tableau pour chaque cas de test : pour une
ligne du tableau, les données des colonnes de gauche désignent les entrées du test et sont
mises en correspondance avec les données des colonnes de droite qui désignent les sorties
du test. L’utilisation de plusieurs lignes du tableau permet d’exécuter le cas de test plusieurs
fois en changeant les données à chaque exécution.
Chaque tableau est associé à une classe de test, dont les méthodes sont invoquées soit
pour recevoir les données d’une ligne, soit pour exécuter le cas de test de la classe. Le reste
du code de test sera structuré à la discrétion de l’automaticien. Si on connaît les tableaux
écrits dans des wikis, d’autres sources de données sont possibles, comme des fichiers
Excel, CSV et XML, ainsi que des bases de données.

En Data-Driven Testing, on sépare le code de test et les données de test. Mais où

trouve-t-on le cas de test lui-même, que nous avons à peine évoqué ? Il est implémenté par
le code de test. Et si on veut documenter le cas de test de façon littérale, on pourra le
rédiger comme commentaire du tableau des données. Bien sûr, ce commentaire n’est pas
pris en compte lors de l’exécution des tests, et il faudra donc le mettre à jour en plus du
code de test si le cas de test évolue. Dès lors, on comprend mieux l’intérêt des wikis, afin de
rendre facilement accessible la définition des cas de test, et de les partager entre plusieurs
personnes.

Exemple de framework :

FitNesse

Utilisation
Le scénario de test précédent donnerait sous sa forme tabulaire en Data-Driven Testing :

40/109
 Entrées Sorties

Tâches à Tâches à Tâches à Nombre de Tâches à Tâches

ajouter terminer supprimer tâches faire terminées

Définir ce Définir ce 3 Définir ce

qu’est un qu’est un qu’est un
framework framework framework

Écrire un Écrire un Écrire un

scénario scénario scénario

Comparer Comparer Comparer

les types de les types de les types de
framework framework framework

Définir ce Définir ce 0
qu’est un qu’est un
framework framework

Écrire un Écrire un
scénario scénario

Comparer Comparer
les types de les types de
framework framework

Définir ce Définir ce Définir ce 0

qu’est un qu’est un qu’est un
framework framework framework

Écrire un Écrire un Écrire un

scénario scénario scénario

Comparer Comparer Comparer

les types de les types de les types de
framework framework framework

Définir ce Définir ce Écrire un 2 Comparer Définir ce

qu’est un qu’est un scénario les types de qu’est un
framework framework framework framework

Écrire un
scénario

41/109
 Comparer
les types de
framework

TODO Xavier Implémenter la classe de test en pseudo-code.

Classe de test

Attributs :
$tâches_à_ajouter : liste de chaînes de caractères
$tâches_à_terminer : liste de chaînes de caractères
$tâches_à_supprimer : liste de chaînes de caractères
$nombre_de_tâches : nombre entier
$tâches_à_faire : liste de chaînes de caractères
$tâches_terminées : liste de chaînes de caractères

Méthodes :
modifier_tâches_à_ajouter($tâches)
$tâches_à_ajouter = $tâches

modifier_tâches_à_terminer($tâches)
$tâches_à_terminer = $tâches

modifier_tâches_à_supprimer($tâches)
$tâches_à_supprimer = $tâches

modifier_nombre_de_tâches($nombre)
$nombre_de_tâches = $nombre

modifier_tâches_à_faire($tâches)
$tâches_à_faire = $tâches

modifier_tâches_terminées($tâches)
$tâches_terminées = $tâches

exécuter()
pour chaque $tâche dans $tâches_à_ajouter
ajouter_une_tâche($tâche)

$compteur = 1
pour chaque $tâche dans $tâches_à_ajouter
une_tâche_devrait_être_à_faire($compteur, $tâche)
$compteur = $compteur + 1

pour chaque $tâche dans $tâches_à_terminer

terminer_une_tâche($tâche)

$compteur = 1
pour chaque $tâche dans $tâches_à_terminer

42/109
 une_tâche_devrait_être_finie($compteur, $tâche)
$compteur = $compteur + 1

pour chaque $tâche dans $tâches_à_supprimer

supprimer_une_tâche($tâche)

$tâches = _sélectionner_des_élements_par_id(“liste de tâches”)

_est_égal($tâ[Link], $nombre_de_tâches)
TODO Xavier : il reste à vérifier les tâches à faire et terminées.
$cases_à_cocher = _sélectionner_des_éléments(chemin/vers/cases/à/cocher)
pour chaque $case
_est_décoché($case)

Les méthodes modificatrices (commençant par “modifier”) permettent de mémoriser les

entrées et les sorties du test. En fait, le framework se charge de lire les données du tableau,
et pour chaque ligne, il appelle la méthode qui correspond au libellé de chaque colonne en
lui donnant la valeur de la colonne, puis le framework appelle la méthode “exécuter” qui
déroule le cas de test automatisé. Les fonctions de test utilisées par la méthode “exécuter”
sont identiques à celles déjà développées pour le framework d’automatisation par
bibliothèques de fonctions.

Observations
● Il est facile d’ajouter une nouvelle partition d’équivalence, sitôt que celle-ci est
découverte : il suffit d’ajouter une ligne au tableau des données.
● La couverture des cas de test augmente en fonction des combinatoires entre les
données du tableau.
● Le tableau de données n’explicite à aucun moment le scénario de test. Il faudra
documenter le tableau en rédigeant un scénario de test. Si le code de test évolue, il
faudra mettre à jour la documentation du tableau.
● Les données de test sont séparées du script de test : on peut donc ajouter ou
modifier des données sans modifier le script de test, et le script de test est
réutilisable indépendamment des données.
● Le script de test piloté par les données s'appuie aisément sur une bibliothèque de
fonctions de test.
● Il est facile d’invoquer un modificateur pour préparer le contexte du test, simplement
à partir d'une colonne du tableau, et inversement, grâce à une convention de
nommage du framework.

Framework de test piloté par mots d’action

Définition
Un framework de test piloté par mots d’action, ou Keyword-Driven Testing framework en
Anglais, consiste à automatiser un cas de test entièrement de façon littérale, au moyen de
phrases verbales brèves et invariantes. Plutôt que de phrases verbales, on parle en fait de
mots d’action, ou mots-clés : chacun d’eux est constitué d’un sujet facultatif, puis d’un verbe

43/109
obligatoire, puis d’un complément si nécessaire, le tout placé au début de chaque ligne. Un
mot d’action peut recevoir des arguments placés à sa droite. Pour distinguer un mot d’action
et ses arguments d’une part, et les arguments entre eux d’autre part, on utilise un
séparateur, qui peut être un nombre constant d’espaces, une tabulation ou un caractère
spécial. Du fait de cette structure, le code de test peut être lu soit sous forme de texte, soit
sous forme tabulaire. C’est pourquoi on rencontre parfois les termes d’Action Word-Based
Testing ou de Table-Driven Testing pour désigner le Keyword-Driven Testing (KDT).

Un framework de KDT fournit des mots d’action natifs, et l’automaticien peut et devra
implémenter des mots d’action personnalisés, spécifiques du logiciel à tester. Les mots
d’action personnalisés constituent un langage dédié au domaine du métier (Domain Specific
Language ou DSL). Ils sont implémentés en appelant d’autres mots d’action, qu’ils soient
eux-mêmes natifs ou personnalisés. Un framework de KDT devrait être extensible de façon
à importer des bibliothèques tierces de mots d’action en fonction des besoins
d’automatisation, en particulier l’automatisation des tests web ou mobiles, les appels
distants, la manipulation de fichiers ou de processus système, etc.

En Français, privilégiez l'expression "mot d'action" à "mot-clé", même si les deux sont
acceptées. En KDT, un tel mot quand il est interprété à l'exécution des tests réalise une
action du framework, il est plus près de la fonction en programmation que des mots-clés
réservés propres à un quelconque langage de programmation.

“C'est tout de même une chose surprenante et déroutante que d'appeler une phrase
un mot...”

Exemple de framework : Robot Framework

Fonctionnement
Le fonctionnement de base de test par mot-clé consiste à diviser le scénario de test en
quatre parties différentes:

● Etape de test ,
● Objet de l'étape de test,
● Action sur l'objet de test,
● Données pour l'objet de test.

44/109
 Work-flow of Keyword Driven Framework

● Execution Engine démarre le test et se connecte avec l'ensemble de test cases et

commence à s'exécuter un par un.
● Une fois le scénario de test sélectionné, les test steps liées sont suivies
séquentiellement.
● Test Steps sont en outre liées aux Page Objects, aux Actions et Test Data.
● Une fois que Execution Engine obtient toutes les informations nécessaires pour
effectuer une étape de test, il se connecte à l'application et effectue l'étape.

Le Keyword-Driven Testing convient tout particulièrement à l’automatisation de cas de test

qui reposent sur différents niveaux de préoccupation : les mots d’action s’inscrivent à des
niveaux variés d’abstraction ou de concrétion, qui vont de l’intention du point de vue du
métier jusqu’à l’interaction élémentaire avec le système à tester, telle qu’une saisie, une
sélection, un clic, etc, pour une interface homme-machine, en passant par des
préoccupations intermédiaires. Cette décomposition par les mots d’action en profondeur
permet de distiller une plus grande quantité de la sémantique du métier dans les tests, et de

45/109
distinguer le découpage de la complexité du métier en profondeur et le découpage du
parcours fonctionnel en longueur. Ainsi plus un cas de test est susceptible d'être complexe
ou long, plus il est possible d’en simplifier la séquence d’étapes en augmentant le niveau
d’abstraction des étapes, et ce afin de conserver des cas de test facilement lisibles et
maintenables.

Utilisation

Prenons le cas de test initial, très simple dans sa définition. Nous avons symbolisé la
séparation par un trait vertical. Son implémentation en pseudo-code donnerait :

Mot d’action Argument(s)

J’ajoute des tâches Définir ce qu’est un framework | Écrire un

scénario | Comparer les types de framework

Des tâches sont à faire Définir ce qu’est un framework | Écrire un

scénario | Comparer les types de framework

Je termine la tâche Définir ce qu’est un framework

Une tâche est terminée Définir ce qu’est un framework

Des tâches sont à faire Écrire un scénario | Comparer les types de

framework

Je supprime la tâche Définir ce qu’est un framework

Il reste des tâches dans la liste 2

Des tâches sont à faire Écrire un scénario | Comparer les types de

framework

Reste à implémenter les mots d’action personnalisés en appelant des mots d’action natifs,
voire d’autres mots d’action personnalisés. Par souci de simplicité, nous n’implémenterons
que les mots d’action ci-dessus. Nous désignerons toute variable comme ceci :
$nom_de_variable.

J’ajoute des tâches

Arguments: $nouvelles_tâches
Pour chaque $tâche_à_ajouter de la liste $nouvelles_tâches
Saisir un texte champ_pour_nouvelle_tâche $tâche_à_ajouter
Taper Entrer

Des tâches sont à faire

Arguments: $tâches_attendues

46/109
 $tâches_à_faire = Récupérer la liste des tâches à faire
Devraient être égaux $tâches_à_faire.taille $tâches_attendues.taille
Pour chaque $tâche_à_faire de la liste de $tâches_à_faire
La liste devrait contenir cet item $tâches_attendues $tâche_à_faire

Récupérer la liste des tâches à faire

$tâches_à_faire = Obtenir des éléments chemin/vers/tâches[case_finie=”décochée”]
Renvoyer $tâches_à_faire

Je termine la tâche
Arguments: $tâche
Cocher $tâche

Une tâche est terminée

Arguments: $tâche
Devrait être coché $tâche

Je supprime la tâche
Arguments: $tâche
Cliquer sur le bouton chemin/vers/bouton/de/suppression/de/$tâche

Il reste des tâches dans la liste

Arguments: $nombre_de_tâches
$tâches = Récupérer la liste de tâches
Devraient être égaux $tâ[Link] $nombre_de_tâches

Observations
● On réutilise la définition du cas de test pour son automatisation : la définition du cas
de test fait partie du code de test exécuté.
● Tout est mot d'action, car tout le code de test est littéral.
● Les données de test sont écrites dans le cas de test, mais elles sont transmises des
cas de test aux mots d'action sous forme d'arguments.

Framework de test hybride

Définition
Un framework de test hybride, ou hybrid test framework en Anglais, consiste à développer
des tests automatisés en combinant les concepts de plusieurs frameworks d’automatisation
de test. Les combinaisons possibles sont multiples. Elles permettent de cumuler les
avantages des frameworks choisis, tout en gommant ou en éliminant leurs faiblesses. Par
exemple, un framework hybride qui reposerait sur le Data-Driven Testing et le
Keyword-Driven Testing permettrait d’automatiser un cas de test dans sa forme littérale, en
réutilisant cette même définition pour plusieurs jeux de données, en paramétrant le cas de
test lui-même et non pas seulement les fonctions de test une à une.

47/109
Le fait d’associer des frameworks pour arriver à un framework hybride n’est pas
nécessairement un choix au départ d’un projet d’automatisation de test, il peut correspondre
à une évolution : en partant d’un seul framework au début, l’opportunité se présente à un
moment de le combiner à un autre framework pour répondre à un besoin nouveau. En
revanche, il faut que le choix du premier framework rende possible cette évolution, alors que
ce n’est pas toujours le cas. Il est donc important d’y penser lorsqu’on choisit un framework
plutôt qu’un autre au démarrage, dans une stratégie de test.
TODO Xavier

Framewor
Framewor Framewor
Framewor k de Framewor Framewor Framewor
Framewor k par k de Framewor
k bibliothèq k de k de mots k de
k script composa k de BDD
modulaire ues de données d'action modèles
linéaire nts
fonctions
Framewor
k par
script
E - - - - - -
linéaire
Framewor
k E
modulaire
Framewor
k de
bibliothèq
ues de
fonctions
Framewor
k de - - C
données
Framewor
k de mots C
d'action
Framewor
k de
composa
- C
nts
Framewor
k de BDD
C C
Framewor
k de C
modèles

48/109
 X
Combinaisons possibles des frameworks de test

Exemple de framework : Robot Framework

● Keyword-Driven Testing
● Data-Driven Testing
● Behavior-Driven Development

Utilisation

Observation

Framework de test fondé sur des composants

Définition
Un framework de test fondé sur des composants, ou component-based testing framework en
Anglais, consiste à automatiser un cas de test en s’appuyant sur des composants de test qui
modélisent chacun des parties de l’application à tester. Ces composants développés à seule
fin de test sont capables d’interagir avec l’application, pour restituer ou modifier son état. Ils
ont l’avantage d’être réutilisables, au moins pour automatiser un même cas de test, voire à
l’échelle de plusieurs cas de test. Ils apportent un degré d’abstraction et de découplage
supplémentaire entre les cas de test et les interactions directes avec l’application. Si
l’application est modifiée, on met à jour le composant de test, sans que cela n’affecte le
reste du code de test.

Il existe à ce jour plusieurs façons alternatives connues de concevoir un framework de test

fondé sur des composants, en fonction de la manière de modéliser l’application à tester du
point de vue des tests.
● Au niveau d’une page, les composants de test modélisent chacun un écran entier de
l’application à tester. Pour tester un écran donné, on a donc besoin d’un seul
composant. C’est le Page Object Model (POM).
● Au niveau d’une section, les composants de test modélisent chacun une partie
identifiable d’un écran de l’application à tester. Pour tester un écran donné, on a
donc seulement besoin des composants des quelques sections appartenant à cet
écran.
● Au niveau d’une fonctionnalité, les composants de test modélisent chacun l’élément
fonctionnellement le plus fin capable d’interaction ou d’affichage dans les écrans de
l’application à tester. Pour tester un écran donné, on a donc besoin des composants
relatifs aux fonctionnalités proposées par cet écran. C’est ce que fait le modèle
Screenplay par exemple, en modélisant soit des “interactions” soit des “questions”,
qui respectivement interagissent avec l’application ou interrogent son état.

49/109
En partant de ces alternatives, des modèles de conception de test ont émergé : c’est le cas
du Page Object Model et de Screenplay, déjà cités.

Un tel framework peut être utilisé seul, comme il peut être facilement combiné à un autre
framework de test.

Dans la population anglophone, on observe souvent une confusion entre le

component-based testing et le component testing : l’approche des tests fondés sur des
composants correspond à un cadre méthodologique pour automatiser des tests système,
alors que les tests de composant désignent une forme de test, à savoir les tests unitaires
dont ils sont simplement un synonyme.

Exemple de framework : Serenity BDD

Utilisation

Observations

Framework de développement piloté par les comportements

Définition
Un framework de développement piloté par les comportements, ou Behavior-Driven
Development framework en Anglais, consiste à automatiser un cas de test de façon littérale,
au moyen de phrases verbales brèves et paramétrables, selon une syntaxe étendue
nommée Gherkin, souvent connue pour son triplet Given-When-Then. Plutôt que de phrases
verbales, on parle en fait d’étapes de test : chacune d’elles est constituée d’un sujet
obligatoire, puis d’un verbe obligatoire, puis d’un complément si nécessaire, le tout placé sur
une même ligne. Une étape de test peut recevoir un ou des arguments, intégrés à sa
structure grammaticale. Gherkin permet également d’alimenter une étape de test par un
tableau de données : chaque colonne correspond à une donnée reçue en argument de
l’étape, et le cas de test sera exécuté autant de fois qu’il y a de lignes dans le tableau. Cette
facilité permet d’exécuter un même scénario en plusieurs cas de test, sans dupliquer le
scénario pour chaque jeu de données.

Un framework de BDD fait le lien entre la définition littérale d’un cas de test et
l’implémentation de ses étapes de test en utilisant des expressions régulières. Les étapes
de test sont donc réutilisables pour définir tout nouveau cas de test. De plus, elles sont
toutes spécifiques du logiciel à tester et constituent un langage dédié au domaine du métier
(Domain Specific Language ou DSL).

50/109
 Exemple de framework : Cucumber

BDD est une méthode de conception logicielle qui étend TDD, par l’apport de pratiques
additionnelles, et qui explore et spécifie les besoins, en mettant l’accent sur la collaboration
et en s’appuyant sur les tests et leur scénarisation.

Cycle global de BDD3

Avantages du BDD

3
GOST, Tempo of Testing, [Link]

51/109
 1. Un dialogue restauré.
2. Un développement guidé et documenté.
3. Une documentation à jour et toujours disponible.
4. Des tests en continu sur les fonctionnalités.

L’objectif principal est de passer de la réflexion sur les «tests» à la réflexion sur le
«comportement».L’écriture des scénarios se fait de manière collective: développeurs,
clients, équipe support…: tout le monde peut participer à l’expression du besoin.

Utilisation

Observations

Framework de test piloté par les modèles

Définition
Un framework de test fondé sur les modèles, ou Model-Based Testing framework en Anglais,
consiste à… TODO Xavier

52/109
Utilisation

Observations

Comparaison des types de framework de test

Nous distinguons deux catégories de frameworks :
● Les frameworks sur étagère sont prêts à l’emploi et sont directement utilisés pour
automatiser les tests. Ils sont utilisables pour de très nombreux logiciels.
● Les frameworks sur mesure sont construits en fonction de l’application à tester et
s’appuient sur des frameworks sur étagère. Ils ne sont utilisables que pour un
logiciel, celui pour lequel ils ont été conçus.

53/109
 Functio
Keywor Compo
Linear Modular n Data-Dri Model-
d-Drive Hybrid nent-ba Behavio
Type de scriptin -based library- ven Based
n testing sed r-Driven
framework g testing based Testing Testing
Testing automat testing Develop
d'automati automat automat testing automat autom
automat ion automat ment
sation de ion ion automat ion ation
ion framew ion framew
test framew framew ion framew framew
framew ork framew ork
ork ork framew ork ork
ork ork
ork
En
Français
Autres Record- Library
noms and-play architect
back ure
framewo testing
rk framewo
rk
Script de Script Script Script Script Script Script Script
test linéaire linéaire structuré structuré structuré structuré orienté
objet
Patterns Record Architect Architect Classe Mot Étape
n'Playba ure ure de test d'action de test
ck modulair modulair
e e,
fonction
de test
Affiliation - Modulari Modulari ATDD ATDD, ATDD, BDD ATDD
de ty-Drive ty-Drive BDD BDD
méthodes n n
Testing Testing
Séparation - - Donnée Donnée Scénario Scénario Scénario
s de test s de test de test de test, de test
et et code et code données et code
fonction de test de test de test de test
s de test et code
de test
Formulatio N/A N/A N/A N/A Formulat Formulat Syntaxe Organi
n ion ion Gherkin gramm
littérale, littérale, es
mais mais logique
non non s
standard standard
isée isée
Scénario À Implicite Implicite À Explicite Explicite Explicite
de test docume docume , , ,

54/109
 nter nter exécuta exécuta exécuta
ble ble ble
Données En dur Paramét Extraites Paramét Extraites Paramét
de test rables sous rables sous rables
forme forme
tabulaire tabulaire
Code de Déstruct Déstruct Structur Structur Structur Structur Structur
test uré, uré, é, é, é, é, é,
non-réuti réutilisa réutilisa réutilisa réutilisa réutilisa réutilisa
lisable ble ble ble ble ble ble
Catégorie Sur Sur Sur Sur Sur Sur Sur Sur
étagère mesure mesure étagère étagère étagère étagère étagère
Exemples - - - Robot - Robot - -
Seleniu FitNesse Framew Framew Cucumb MaTeL
m IDE - Robot ork ork er o
- Framew - - - Yest
TestCom ork TestCom JBehave
plete plete -
SpecFlo
w
Compéten Non Facultati Obligatoi Obligatoi Recom Recom Obligatoi Obligatoi Obligat
ces en ve re : re : mandée mandée re re. oire.
programm program program Séparati Séparat
ation mation mation on ion
structuré orientée possible possibl
e objet. des e des
Séparati compéte compét
on nces ences
possible entre entre
des définitio définitio
compéte n de test n de
nces et test et
entre automati automa
définitio sation tisation
n de test de test. de test.
et
automati
sation
de test
Compéten Partition Partition
ces en test s s
d'équival d'équival
ence ence
Analyse Analyse
des des
valeurs valeurs
limites limites

55/109
56/109
Type de Linear Data Driven Keyword Hybrid
framework Driven

Il s'agit d'un code Les données sont Le code est lié Il s'agit d'une combinaison
Objectif de procédure ou conservées en dehors à des mots clés qui choisit les points forts
d'un ensemble du test qui sont ensuite des autres types de cadre
d'instructions utilisés pour et atténue leurs faiblesses
implémenter
les tests
souhaités

Approche L'approche est Les données sont la La plupart des L'approche pourrait
logique en vue de clé et tout est conçu tâches dépendre de ce qui doit
faire fonctionner la pour accomplir la courantes sont être accompli et aussi de
tâche à accomplir tâche souhaitée avec organisées en l'imagination de l'architecte
un simple mots clés de
changement de base liés au
données code associé;
des tâches
complexes sont
réalisées en
combinant
plusieurs mots
clés

Exigence de Ne nécessite pas Peut nécessiter des Peut nécessiter Peut nécessiter des
compétences de connaissances compétences en des connaissances avancées
humaines avancées en programmation de compétences en programmation, qui
programmation; de niveau intermédiaire en pourraient être utilisées
simples associées à des programmation pour rendre le cadre plus
compétences compétences logiques de niveau générique et adaptable
logiques suffisent intermédiaire
associées à
des
compétences
logiques

Complexité Faible Moyen Moyen Haute

Comparaison du Pourrait nécessiter Nécessite un temps Nécessite un Pourrait nécessiter

temps de moins de temps modéré temps modéré beaucoup plus de temps
développement pour développer le
du framework cadre des cas
individuels

Avantages Simplicité et faible Complexité et Complexité et Grande flexibilité avec des

coût flexibilité modérées flexibilité possibilités illimitées
modérées

57/109
Inconvénients Faible flexibilité Flexibilité uniquement Flexibilité Peut devenir très complexe
en termes de données uniquement en au fil du temps et
termes de nécessiter un soutien
composants spécialisé

58/109
Bonnes Pratiques d’automatisation de test

TODO

Un environnement de développement performant

Commençons par le béaba. Ce n'est pas une bonne pratique d'automatisation de test à
proprement parler, mais plutôt une préconisation d'ordre managérial de première importance
pour automatiser les tests. Trop d'organisations fonctionnent en cloisonnant leurs budgets et
ne se rendent pas compte à quel point de soit-disant optimisations budgétaires locales
pénalisent leur productivité et sont ruineuses. En réduisant leur investissement dans le
matériel informatique d'un côté, ces organisations paient en main d'œuvre au moins 10 à 20
fois ce qu'elles ont économisé chaque année de l'autre en achetant des PC bas de gamme.
Un gaspillage inacceptable, pour ceux qui paient la facture de leurs deniers comme pour
ceux qui subissent leur matériel au quotidien !

Sachez-le : aujourd'hui, un environnement de développement standard minimal, c'est :

● 16 Go de RAM,
● un processeur de 4 coeurs physiques, cadencés à 2,5 GHz,
● un disque SSD de 256 à 512 Go,
● 2 écrans, dont un 16/9 de 23 pouces.
Et cela vaut aussi bien pour les développements logiciels que pour le développement de
tests automatisés. Ce n'est rien de luxueux pour des professionnels en informatique.
D'ailleurs, il n'est pas rare d'être mieux équipé à la maison qu'au bureau, c'est dire ! Et nous
n'avons pas même évoqué d'équipements ergonomiques, bien utiles quand on passe 8
heures assis devant écran et clavier, dans le respect essentiel de la santé
musculo-squelettique des personnels.

Adopter des technologies de développement testables

Avant d’arrêter un choix de technologies de développement pour un projet, soyez très
vigilant à ce que ces technologies rendent les tests faciles à implémenter. Si une technologie
de développement est préjudiciable à votre architecture ou à la conception de votre code, ce
préjudice rejaillira très probablement sur la testabilité de votre application. Parfois, c’est
l’association de deux technologies qui font des choses similaires dans les mêmes
composants qui rend votre application intestable. Par expérience, on constate qu’une
complexité outrancière est un obstacle à l’automatisation des tests.

59/109
Certaines technologies, en particulier parmi les frameworks de développement, peuvent être
très intrusives vis-à-vis de l’architecture et de la conception des logiciels, en induisant un
très fort couplage entre leurs composants et ceux des logiciels. Par exemple, si les classes
de votre logiciel doivent hériter d’autres classes imposées par un framework, il sera
impossible de les tester unitairement. À l’échelle de tests en boîte noire, assurez-vous que le
framework que vous vous apprêtez à choisir ne transforme pas l’automatisation des tests
fonctionnels en un chemin de croix, et qu’il ne contrevient pas à de bonnes pratiques de test.

Versionner les tests

S'il est très rare de croiser encore des projets dont le code source n'est pas versionné au
moyen d'un système de contrôle de version tel que Git ou Subversion, on déplore assez
souvent que les tests soient traités différemment. Or les tests et leur code font partie du
logiciel livré au même titre que son code source. On prendra donc grand soin du code de
test, comme des fichiers qui décrivent les scenarii de test automatisés, en les versionnant de
la même manière, avec le même degré d’exigence, sinon plus.

Scénariser n'est pas Automatiser

On peut réaliser un film avec une multitude d'effets spéciaux. Pour autant, sans un bon
scénario, le film restera au mieux médiocre. Il en va de même avec les tests automatisés :
un bon cas de test automatisé commence par une bonne scénarisation avant même de se
soucier de son automatisation. Dans notre analogie cinématographique, l'automatisation
remplace les effets spéciaux et ne saurait remplacer le scénario de test. Bien scénariser un
cas de test, c'est employer généreusement le vocabulaire du métier plutôt qu'un jargon
technico-fonctionnel d'appoint, faire parler les intentions plutôt que les interactions, adopter
un niveau de préoccupation et d'abstraction homogène pour toutes les étapes de test plutôt
que de passer d'un point de vue général à particulier et inversement.

La lisibilité et la maintenabilité des tests automatisés dépendront largement du soin apporté

à la définition et à la scénarisation des cas de test, indépendamment des moyens employés
à leur automatisation.

Développer des applications facilement testables

Il est toujours plus compliqué de revenir sur le développement d’une application après coup,
afin de la rendre facilement testable. Mieux vaut s’accorder au préalable sur les prérequis de
testabilité avant de commencer les développements. Par exemple, mettez en place la
sélection systématique de tout élément avec lequel on peut interagir par un identifiant dédié
aux tests, comme “test-id” ou “data-id”, ainsi qu’une nomenclature pour la valorisation de cet
attribut.

Le saviez-vous ?
L’attribut “data-id” est souvent adopté, car les frameworks de développement web
garantissent la prise en charge des attributs préfixés en “data-” dans leurs patrons HTML.

60/109
C’est le cas d’Angular et d’Aurelia par exemple. Il ne sera donc pas nécessaire d’ajouter la
moindre ligne de code pour utiliser ces attributs personnalisés. Pratique, n’est-ce pas ?

Choisir le bon framework d’automatisation

TODO
Comme nous l'avons vu avec le framework hybride, certaines combinaisons sont possibles
et d'autres non. Des choix faits au début de l'automatisation des tests peuvent interdire de
faire évoluer un framework dans une direction. C'est aussi un enjeu d'une stratégie
d'automatisation de test : faire un choix éclairé du type de framework en fonction d'un
contexte.

Prenez de l’avance avec le Walking Skeleton

TODO Xavier

Améliorer l’automatisation de test

Afin de profiter au mieux de l’automatisation des tests, voici des conseils destinés à aider
l’amélioration du retour sur investissement en automatisation de tests et à améliorer la
qualité logicielle.

● Choisissez bien ce que vous devez automatiser

● Choisissez bien vos outils de test
● Affinez vos processus
● Choisissez un Framework
● Ne sous-estimez pas l’effort manuel
● Veillez à la qualité de vos scripts
● Identifiez le responsable de l’exécution des tests
● Mesurez votre réussite avec précision

Choisir les cas de test à automatiser

Pour atteindre l’équilibre des coûts et des bénéfices, il est essentiel d’identifier les facteurs
qui augmentent la complexité de l’automatisation d’un projet de test spécifique.
L’automatisation des tests s’applique idéalement à du code qui :

● joue un rôle important dans une application ;

● traite de hauts volumes de données ;
● exécute des processus courants ;
● est utilisable sur un ensemble d’applications.

61/109
Il est conseillé aux entreprises de rechercher également les domaines non traditionnels,
voire non prévus dans le périmètre, auxquelles elles pourraient étendre leur investissement
en automatisation, notamment pour le test des routines d’installation des correctifs et
corrections d’anomalies, pour la gestion des tests, et pour la création des rapports de test.

Pour choisir des meilleurs candidats à l’automatisation, voici les critères à suivre :

● La faisabilité technique .
● La fréquence d’exécution des tests.
● Le degré de réutilisabilité des composants de test.
● Le nombre total de ressources nécessaires.
● La complexité des cas de test.
● La possibilité d’utiliser les mêmes cas de test pour de multiples navigateurs ou
environnements.
● Le temps nécessaire à l’exécution des tests.

Principes FIRST
TODO Xavier

62/109
Motifs de conception de test

Page Object Model (POM)

Le Page Object Model (POM, à ne pas confondre avec le Project Object Model d'Apache
Maven) est un modèle de conception qui consiste en la création d'un référentiel de classes
modélisant l'ensemble des écrans d'une interface utilisateur. Les classes du modèle
encapsulent chacune les éléments graphiques de tout ou partie d'un écran, ainsi que les
interactions possibles avec un écran sous forme de méthodes. Dès lors, le POM favorise la
réutilisation du code de test pour une multitude de scenarii de test. La maintenance des test
en est grandement facilitée.

Page Object Model (POM)4

Screenplay
Screenplay est un modèle de conception qui permet d'aller plus loin que le Page Object
dans la séparation des responsabilités entre les composants de test, pour organiser le code
de test en appliquant des principes de conception orientée objet éprouvés (cf. principes
SOLID). Il est entièrement documenté par le framework Serenity BDD, qui propose à travers
ce pattern une typologie de composants et des règles de dépendance : Abilities, Actions,
Actor, Elements, Questions, Screen, Tasks.

4
Page Object Model (POM) | Design Pattern,
[Link]

63/109
 The Screenplay pattern5

Browser Factory
Browser Factory est un motif de conception qui consiste à découpler l’initialisation d’un pilote
de navigateur web et son utilisation, afin que son utilisation soit toujours la même quel que
soit le nom du navigateur ciblé. Dès lors, un test web peut être exécuté au moyen de
n’importe quel navigateur web, sans être modifié.

Given-When-Then
Given-When-Then peut être utilisé indépendamment de Gherkin pour structurer les cas de
test, de la même façon que Setup-Execute-Verify ou Arrange-Act-Assert. Ces triplets
désignent dans l'ordre les étapes de préparation, d'exécution et de vérification d'un cas de
test. Un cas de test doit commencer par l’initialisation d’un contexte qui lui est spécifique
pour que ses résultats soient reproductibles, et il doit se terminer par des assertions pour
vérifier que les résultats obtenus sont conformes aux résultats attendus. Sans vérification,
un test sera par essence un faux-négatif, et ne servira qu’à entretenir une illusion de
couverture.

5
Serenity BDD, Writing automated acceptance tests using Serenity and the Screenplay Pattern,
[Link]

64/109
 Given-When-Then (Comme-Quand-Alors)

Organisation arborescente du référentiel de test

Il s’agit d’organiser les cas de test automatisés en suites de test, en tests imbriqués, et selon
une arborescence fonctionnelle pérenne de répertoires et de fichiers. L'objectif d'organiser
les cas de test est de faciliter grandement la maintenabilité du référentiel de test, au fil des
changements fonctionnels.

Principes de développement applicables au test

Ces principes répandus dans le développement de logiciel s’appliquent également au
développement de tests automatisés.

Séparation des préoccupations

Le cerveau humain ne fonctionne pas comme la mémoire d’un ordinateur. Pour être efficace,
il a besoin de se concentrer sur une tâche et de se focaliser sur un objectif. Si un problème

65/109
est trop gros pour être résolu correctement en une seule fois, il est découpé en de plus
petits sous-problèmes : c’est le principe de diviser pour régner, fondamental en informatique.
C’est vrai pour résoudre un problème la première fois, comme ça le restera quand le
problème d’origine changera en partie d’énoncé et que sa solution devra être adaptée. Il en
va de même pour l’écriture d’un code source et de ses évolutions. De fait, il est plus difficile
de concevoir la première fois un programme qui fonctionne et de le maintenir par la suite, si
ce programme est constitué d’une très longue suite d’instructions, s’étalant potentiellement
sur plusieurs hauteurs d’un écran d’ordinateur. Qu’il s’agisse d’un code de production ou
d’un code de test, il faut donc le découper en tout petits blocs, faciles à faire évoluer.
Séparer les préoccupations d’un code source implique d’identifier ces préoccupations, de les
matérialiser en classes, en méthodes et en sous-méthodes, et de nommer ces dernières
pour qu’elles reflètent ces préoccupations.

Si vous respectez la séparation des préoccupations dans le code de test, vos tests
automatisés n’en seront que plus fiables, compréhensibles et évolutifs.

Keep It Simple, Stupid (KISS)

La simplicité est une vertue en programmation. Le principe KISS nous rappelle qu’un code
source doit être simple dans son écriture et sa conception, et qu’il faut bannir toute
complexité inutile à la résolution d’un problème.

Mais il ne faut pas s’y tromper : on parle bien de la simplicité de la solution implémentée,
pas des moyens d’y parvenir. La simplicité des moyens employés risquerait fort de
déboucher au contraire sur une solution plus complexe. En cela, “la simplicité est la
sophistication suprême” (Léonard de Vinci).

En corollaire, rien ne sert d’optimiser un code source par anticipation, c’est-à-dire si la

complexité de cette optimisation n’est pas justifiée par un problème de performance avéré.

Prenez soin de votre code de test en le gardant simple, rappelez-vous-le grâce à KISS.

You Ain't Gonna Need It (YAGNI)

Cela peut paraître contre-intuitif à des non-développeurs, mais anticiper tout ou partie d’une
fonctionnalité pour le jour où on en aura besoin est contre-productif et coûte cher. Vous
payez le coût de développement sur le moment alors qu'il y avait plus important et que ces
développements plus importants vont devoir attendre, le coût de maintenance en attendant
que le besoin vienne vraiment, le coût de suppression quand le coût de maintenance n'est
plus acceptable et que le besoin n’est toujours pas confirmé. Le jour où le besoin survient
enfin, s'il arrive, la solution que vous aviez anticipée a de grandes chances de ne pas y
répondre correctement.

Avant de factoriser du code de test, que ce soit dans des fonctions de test ou des mots
d'action, assurez-vous que ce code est partagé à plusieurs reprises. Autrement dit, ne
factorisez pas trop tôt et seulement quand nécessaire. Sinon vous serez vite victime de
votre suringénierie.

66/109
Ainsi rappelez-vous YAGNI dès que l’envie vous brûle de développer un code de test qui ne
répond à aucun besoin avéré.

Don’t Repeat Yourself (DRY)

TODO Xavier

67/109
 Écueils à éviter dans un projet d’automatisation
TODO

On a toujours cherché à optimiser le degré de confiance des résultats du test, un soucis qui
nous a poussé à chercher un moyen efficace pour garantir la satisfaction de nos clients..,
peut être que c'est un moyen que je le considère comme une colonne dorsale qui ne peut
être fort et robuste qu'à travers des mesures des précautions basés sur des bonnes règles
qu'il faut les prendre au cours de notre test, tels que les écueils à éviter et dont l'objectif est
de planter une solution de test automation pure et dure.
- Zied Hannachi

Dans un projet d’automatisation de test, les équipes QA font souvent des erreurs qui coûtent
du temps, de l'argent, de la confiance et font dérailler les progrès.

Des outils inadaptés

TODO Zied : Les outils que vous avez sélectionnés ne conviennent pas à vos testeurs.
Les outils et les frameworks d'automatisation de test sont cruciaux pour la réussite des
projets d'automatisation des tests. Mais il est difficile de sélectionner un bon outils
d'automatisation des tests pour un projet car les problèmes découlent des compétences
techniques, ou du manque de celles-ci, chez les personnes qui travailleront avec les outils.

Type d'outils de test

Il existe de nombreux types d'outils de test, qu’un Test Manager peut prendre en compte lors
de la sélection des outils de test.

Outils open source

Les outils open source sont le programme dans lequel le code source est publié
ouvertement pour utilisation et/ou modification de sa conception originale, gratuitement.

68/109
Outils commerciaux

Les outils commerciaux sont les logiciels qui sont produits pour la vente ou à des fins
commerciales.
Les outils commerciaux ont plus de support et plus de fonctionnalités d’un fournisseur que
les outils open-source.

Outils personnalisés / fait maison

Dans certains projets de test, l’environnement de test et le processus de test ont des
caractéristiques particulières. Aucun outil open-source ou commercial ne peut répondre à
cette exigence.

Les éditeurs de logiciel conçoivent leurs outils pour les personnes qui sont les plus
susceptibles de les utiliser, les types des testeurs sont:

● Développeurs-testeurs, qui préfèrent rester dans leur milieu de codage préféré pour
la rédaction des tests.
● Testeurs techniques, spécialistes de l’automatisation des tests qui préfèrent les outils
de haut niveau qui utilisent la modélisation et ne nécessitent pas de compétences en
codage.
● Testeurs non techniques qui font des tests d’acceptation, des tests de convivialité,
etc., et préfèrent utiliser le langage naturel pour la rédaction des tests.

Si vous achetez un outil qui a été conçu pour un développeur-testeur et demandez à un

testeur technique ou d’affaires de l’utiliser, vous aurez des ennuis à chaque fois. Cela est
susceptible de se produire plus souvent que les organisations regardent au-delà de leur
offre limitée de développeur-testeurs et de demander à d’autres personas pour aider à
l’automatisation des tests.

Pour mieux sélectionner les outils qui conviennent à vos testeurs:

Identifier le besoin des outils

Comment pouvez-vous sélectionner un outil de test si vous ne savez pas ce que vous
cherchez?

Évaluez les outils et les fournisseurs

Après avoir établi les exigences de l’outil:
Analyser les outils commerciaux et open source disponibles sur le marché, en fonction des
exigences du projet.
Créer une liste restreinte d’outils qui répond mieux à vos critères.
Un facteur que vous devriez considérer est les fournisseurs. Vous devez tenir compte de la
réputation du fournisseur, du soutien après vente, de la fréquence de mise à jour des outils.

69/109
Évaluer la qualité de l’outil en procédant à l’essai et en lançant un projet pilote. De nombreux
fournisseurs rendent souvent les versions d’essai de leur logiciel disponibles pour le
téléchargement.

Estimer les coûts et les avantages

Pour s'assurer que l'outil de test est bénéfique pour l’entreprise, le Test Manager doit
équilibrer les facteurs suivants:

● Coût
● Valeur
● Avantage

Prenez la décision finale

Pour prendre la décision finale, le Test Manager doit:
● Avoir une forte connaissance de l'outil. Cela signifie que vous devez comprendre
quels sont les points forts et les points faibles de l'outil.
● Équilibrez les coûts et les avantages.

TODO Zied : Choisir un outil simplement parce qu'il est open source.
De nombreux testeurs ou managers préfèrent installer des applications open source pour
gérer leurs projets.
Les arguments en faveur
● Gratuit et économique
● Disponibilité facile
● Faible coût des tests
● Plus grande compatibilité
● Facilité d’utilisation pratique
Contre
● Manque de sécurité
● Manque d’amélioration
● Problèmes d'assistance

La gratuité et la disponibilité sont les deux principaux moteurs des outils open source.
L'objectif d'économiser de l'argent oblige beaucoup à se concentrer exclusivement sur les
outils de test open source et à éviter les outils sous licence disponibles dans le commerce.
Mais la sélection d'outils open source permet uniquement de mettre de côté le coût initial de
la licence, pas les autres coûts associés. Nous devons examiner attentivement les coûts
associés avant de prendre une décision.
Les coûts à engager pour la formation, l'accessibilité du support et l'acquisition de
ressources supplémentaires doivent être pris en compte. D'autres coûts, tels que le temps et
les dépenses nécessaires pour garantir l'adoptabilité, devraient également être pris en
charge. Outre ces coûts immédiats, il existe également des coûts futurs qui surviennent à

70/109
long terme, la répétition des tests et l'exécution de plusieurs projets. Souvent, les outils de
test open source ne donnent pas une vision claire de tous ces coûts associés.

En général, les outils open source nécessitent plus de compétences techniques. Ces outils
comportent, en dépit de leur manque attrayant de droits de licence. Certains ont des
fonctionnalités limitées et peuvent ne pas vous donner toutes les fonctionnalités dont vous
avez besoin, alors soyez clair sur ce que vous avez besoin.
Plusieurs sociétés utilisent à la fois des outils open-source et commerciaux ensemble, car
les outils commerciaux peuvent remplir toutes les fonctionnalités manquantes que les outils
open-source n’ont pas, et souvent ajouter de la valeur en plus des outils open-source.

Identifiez le problème que vous souhaitez résoudre et les fonctionnalités dont vous avez
besoin, puis recherchez un outil parmi les options commerciales et open-source qui
répondent à ces besoins. Examinez ensuite les compromis entre les options open-source et
les options commerciales. Par exemple, compte tenu du niveau de compétence de vos
utilisateurs et de leurs besoins en matière de formation et de soutien, l’option open-source
convient-elle? Enfin, évaluez la vitalité de la communauté libre qui est à l’origine de l’outil,
afin de déterminer s’il y aura un support communautaire gratuit.

Il est toujours recommandé de faire une comparaison de tous les outils de tests
commerciaux et open-source disponibles à la lumière de votre expérience, des exigences
spécifiques au projet et des feedback des utilisateurs. Faites une évaluation indépendante
de l’utilisation de l’outil pour le bénéfice global du client, du projet et de votre organisation.

Mal choisir les cas de test à automatiser

TODO Zied : Vous avez automatisé les mauvais cas de test.
La plupart des testeurs essaient d'automatiser des cas de tests qui ne sont pas de bons
candidats à l'automatisation, cela conduit à perdre beaucoup de temps et d'efforts sur des
cas de tests qui n'ont pas besoin d'être automatisées ou qui ne devraient pas l'être.
N'automatisez pas chaque «cas de test» juste pour le plaisir. Mettez un peu de réflexion
dans le jeu. Étudiez les diagrammes architecturaux de haut et de bas niveau. Demandez ce
qui peut mal tourner. Examinez les points d'intégration et recherchez les points de
défaillance potentiels.
Adoptez une approche de l'automatisation basée sur les risques comme vous le feriez avec
votre approche de test globale. Quelle est la probabilité que quelque chose échoue et quel
est l'impact de l'échec? Si la réponse est élevée, ces scénarios doivent être automatisés et
exécutés sur chaque build.
Dans chaque sprint, nous finissons souvent par écrire des tests automatisés autour des user
stories pour ce sprint et oublions l'intégration avec d'autres fonctionnalités. Il existe des tests
d'intégration faibles ou inexistants.
N'oubliez pas que l'automatisation des «cas de tests» prend du temps. Gardez également à
l'esprit qu'en automatisant un test, vous ne testez pas vraiment, vous vérifiez simplement
que la fonctionnalité en question satisfait certains critères d'acceptation.

71/109
Par conséquent, chaque fois que vous passez à automatiser un «cas de test», pensez au
temps que vous perdez en ne testant pas!

Alors, quels cas de test peuvent être automatisés?

Ainsi, les cas de test peuvent (et doivent être automatisés) si:
● Les tests sont utilisés à plusieurs reprises.
● Les tests impliquent beaucoup de saisie de données.
● Les tests réussissent ou échouent clairement.
● Les tests fournissent un résultat exact.
● Les tests utilisent une interface utilisateur cohérente et des contrôles réguliers.

TODO Zied : Essayer de convertir tous les tests manuels en automatisation.

Plusieurs projets de test tentent de convertir leurs scénarios de test manuels en scénarios
automatisés pour améliorer la productivité et la couverture.
L'une des étapes clés pour commencer les tests d'automatisation est la sélection des cas de
test appropriés et la détermination du ROI (Return On Investment).
L'une des erreurs les plus fondamentales commises par les testeurs n'est pas sélectionner
les cas de test appropriés pour l'automatisation.
Ne vous contentez pas de sélectionner n’importe quel suite de tests. Analysez
soigneusement les cas de test et sélectionnez les candidats à l'automatisation en tenant
compte du facteur le plus important, c'est-à-dire le retour sur investissement.

Quels cas de test peuvent être automatisés?

Automatiser tous vos tests peut sembler séduisant au début, mais c'est à la fois difficile et
peu pratique. Certains tests sont mieux adaptés aux tests manuels tandis que d'autres sont
d'excellents candidats pour les tests automatisés.

Voici des conseils pour décider quels cas de test peuvent être automatisés.

À quelle fréquence le test est-il exécuté? Souhaitez-vous qu'il soit exécuté plus souvent?
Un test courant, comme vous assurer que vous pouvez vous connecter, est simple et
souvent facile à automatiser. Il serait également utile de savoir immédiatement si vous ne
pouvez pas vous connecter et pourrait être exécuté après chaque build. Un test qui n’a
besoin d’être exécuté qu’une seule fois avant la release ne vaut probablement pas la peine
d’être automatisé.

Combien de données faut-il saisir pour le test? (Ou, à quel point le test est-il fastidieux)?
L'ajout de mille entrées à votre base de données est difficile à faire manuellement. Mais ce
n'est pas une sueur pour un test automatisé. En général, plus il y a de données saisies,
meilleur est le candidat à l'automatisation des tests .

La sortie du test est-elle facilement mesurable?

Si vous pouvez facilement dire si un test a réussi ou échoué, c'est un bon test à automatiser.

72/109
Le résultat du test est-il purement objectif?
Si le testeur doit s’assurer que le résultat est exact, un test automatisé peut habituellement
le faire. Si, par exemple, le testeur doit s’assurer qu’une image semble "bonne" ou même
"lisible", un test automatisé aura beaucoup de mal à vérifier l’image.

L'interface utilisateur autour de la zone testée change-t-elle beaucoup d'une version à

l'autre?
Un outil de test automatisé peut gérer certaines modifications des contrôles. Mais il ne
pourrait probablement pas gérer le déplacement d'un champ vers une boîte de dialogue
complètement différente. Vous devrez modifier le script automatisé pour le compenser.

Le test utilise-t-il des contrôles personnalisés?

Si un test utilise des boutons ordinaires, des zones d'édition, des zones de liste déroulante
ou des grilles, il peut s'agir d'un test automatisé. Si vous avez des contrôles personnalisés,
ce sera difficile. (Ce n'est pas que les contrôles personnalisés ne puissent pas être
automatisés. Mais vous pouvez obtenir de meilleurs résultats en automatisant d'abord les
parties les plus standard.)

Confondre méthode et outil

Confondre une méthode de travail et un outil est une grande cause d’échec. Bien souvent,
une méthode peut apporter de nouvelles pratiques, un nouveau processus de travail,
modifier les relations de collaboration, alors qu’un outil ne fait qu’apporter un support pour
faciliter la mise en place d’une méthode. Pourtant, il est courant de voir des organisations se
précipiter sur l’utilisation d’outils, sans se former aux méthodes, ni en adopter les
fondamentaux. Le cas échéant, le projet d’automatisation de test n’apporte pas les résultats
escomptés, et peut même être abandonné.

TODO Zied : Les outils que vous avez choisis ne peuvent pas résoudre tous vos problèmes.
Le succès de toute automatisation de test dépend de l'identification du bon outil
d'automatisation. La sélection de l'outil de test correct pour votre projet est l'un des meilleurs
moyens d'atteindre l'objectif du projet.
Plusieurs Managers souhaitent choisir un outil pour l’ensemble de la société, c'est une
erreur parce qu’il y a beaucoup des différents problèmes que vous voulez résoudre avec
l’automatisation, et un outil ne peut pas tous les résoudre. C’est très important de demander
si l'outil répond réellement aux problèmes que l'équipe doit résoudre, plutôt que choisir un
outil et ensuite trouver un problème pour le résoudre.
Lorsque vous lancez votre recherche du bon outil de test logiciel automatisé, il est important
de créer une liste d'exigences lors du choix d'un outil. Sinon vous risquez d’obtenir des
outils, puis de constater que vous devez faire beaucoup de contournements ou de
personnalisations pour les amener à faire ce dont vous avez vraiment besoin.

La sélection des bons outils est souvent basée sur:

● Définition des problèmes spécifiques que vous devez résoudre avant de chercher un
outil.

73/109
 ● Essayez l’outil tout au long du cycle de développement complet pour voir comment il
fonctionne dans votre environnement avant d’acheter.
● Assurez que l’outil répond au problème que vous essayez de résoudre.

Attendre un délai fixe

Il est souvent nécessaire d'attendre entre 2 actions, qu'un écran se rafraîchisse, qu'une
donnée soit affichée, etc. Par facilité, il est tentant de choisir un délai d'attente fixe, arbitraire.
Mais ces délais vont rendre vos tests lents et fragiles : lents parce que les délais prévus
peuvent être supérieurs au temps vraiment utile à l'exécution, fragiles car une lenteur
d'exécution provoquera des faux-positifs à répétition. Par conséquent, attendez qu'une
condition soit satisfaite avant de passer à la prochaine action plutôt que d'attendre un délai
arbitraire. Et les résultats de vos tests gagneront en fiabilité, et vous en temps d'analyse.

74/109
Implémentations de framework d’automatisation
de test

75/109
Maintenant, nous vous invitons à découvrir ou redécouvrir des frameworks d'automatisation
de test à la lumière de la typologie précédente : ce sont les implémentations des types de
framework étudiés. Nous vous les livrons avec des exemples d’automatisation d’un cas de
test, en reprenant le même scénario fil rouge, ainsi que toutes sortes d'astuces et bonnes
pratiques issues de nos retours d'expérience, dans des projets d'automatisation de test.

Le code source des exemples d’automatisation est entreposé dans des dépôts Git, un dépôt
par exemple. Vous pouvez retrouver tous nos dépôts ici.

Pour illustrer les implémentations de framework, nous avons créé une petite application de
gestion de tâches, simplement nommée Todos. Sans surprise, elle permet d'ajouter,
terminer et supprimer une tâche. Les cas de test automatisés peuvent ainsi être exécutés
pour tester la même application et les mêmes fonctionnalités, quels que soient les
implémentations de framework de test.

Selenium
Selenium est un projet qui chapeaute plusieurs technologies pour l’automatisation de test
d’application web. Selenium fournit une suite largement utilisée par la communauté des
tests. Sa force est de supporter tous les navigateurs web les plus populaires.

Selenium WebDriver
Selenium WebDriver est une bibliothèque de test d’application web, capable de prendre le
contrôle des principaux navigateurs web : Chrome, Firefox, Internet Explorer, Opera, Safari6.
Son API est portée dans de nombreux langages : Java, Python, C#, Ruby, JavaScript et
Kotlin. Même si le code de test écrit avec Selenium WebDriver peut être écrit n’importe où,
ce n’est jamais le cas dans la réalité des projets logiciels : le code de test est toujours écrit
au moyen d’un framework de test, dans des classes de test prises en charge par le
framework choisi, pour des raisons d’industrialisation dans une chaîne d’intégration
continue. Selenium WebDriver est utilisé avec l’un des frameworks suivants, en fonction du
langage de programmation adopté.

Langage Frameworks de test

Java JUnit
Kotlin TestNG

Python Unittest
Pytest
Pytest-django

C# NUnit
XUnit

6
Consumer browsers,
[Link]

76/109
 MSTest

Ruby7 RSpec
Minitest
Test-unit

JavaScript Jasmine
MochaJS
QUnit

Selenium WebDriver s’appuie sur… (TODO composants tels que WebDriver, etc).

Selenium WebDriver ne peut pas être utilisé pour automatiser des tests d’application de
bureau. Pour ce faire, on aura recours à d’autres technologies, telles que SikuliX ou AutoIt.

Selenium IDE
Selenium IDE est un framework d’automatisation par script linéaire. Il se présente comme
une extension de Chrome ou de Firefox qui facilite l'enregistrement et la lecture des tests
dans le navigateur.
Il suffit pour cela d'ouvrir le plugin situé en haut à droite du navigateur Firefox, puis
d'enregistrer nos différentes actions sur l'application.
Une fois la capture terminée, Selenium IDE nous permet de générer cette capture sous
forme de script. Différents langages sont proposés tels que : Python, Java, C#...

Selenium Grid
Selenium Grid est un serveur proxy intelligent qui facilite l'exécution de tests en parallèle sur
plusieurs machines. Cela se fait en acheminant les commandes vers des instances de
navigateur Web distantes, où un serveur agit comme un hub. Ce hub achemine les
commandes de test au format JSON vers plusieurs nœuds de grille enregistrés.
Le hub effectue une exécution simultanée de tests sur plusieurs machines, gérant différents
navigateurs de manière centralisée, au lieu de mener des tests différents pour chacun d'eux.

Selenium Grid facilite les tests multi-navigateurs, car un même test peut être exécuté sur
plusieurs machines et navigateurs, tous ensemble, ce qui facilite l'analyse et la comparaison
des résultats.
Les deux principaux composants de Selenium Grid sont:
● Le Hub est un serveur qui accepte les demandes d'accès du client WebDriver,
routant les commandes de test JSON vers les lecteurs distants sur les nœuds. Il
prend les instructions du client et les exécute à distance sur les différents nœuds en
parallèle
● Le nœud est un appareil distant composé d'un système d'exploitation natif et d'un
WebDriver distant. Il reçoit les requêtes du concentrateur sous forme de commandes
de test JSON et les exécute à l'aide de WebDriver

7
Ruby testing frameworks, [Link]

77/109
Jalenium
Jalenium …….

FluentLenium
FluentLenium est une bibliothèque de test pour tester des sites web. Cette bibliothèque
permet de rendre les tests fonctionnels d'interface utilisateur lisibles, réutilisables, fiables et
résilients. Elle est utilisée par des personnes qui automatisent quotidiennement les tests
interagissant avec un navigateur web.

FluentLenium fournit une API Java fluide à Selenium et apporte un peu de magie pour éviter
les problèmes courants rencontrés par les utilisateurs de Selenium.

FluentLenium s'intègre mieux avec AssertJ , mais vous pouvez également choisir d'utiliser le
framework d'assertion que vous souhaitez.

Selenide
Selenide est une API pour écrire des tests automatisés faciles à lire et faciles à entretenir en
Java, qui présente les avantages suivants :
● API fluide et concise pour les tests.
● Prise en charge Ajax pour des tests stables.
● Sélecteurs puissants.
● Configuration simple.
Selenide rend vos tests stables en résolvant (presque) tous les problèmes Ajax / timing.
Selenide fournit une API concise pour utiliser Selenium WebDriver dans les tests d'interface
utilisateur:
● Attente intelligente,
● WebDriver transparent,
● Méthodes pratiques,
● Prise en charge Ajax,
● Captures d'écran automatisées.

Atata

Un framework C # /. NET
Atata est un framework d'automatisation de test pour les applications web en C#/.Net basé
sur Selenium WebDriver.

Caractéristiques:
● WebDriver: Basé sur Selenium WebDriver et préserve toutes ses fonctionnalités.
● Intégration: Fonctionne sur n'importe quel moteur de test .NET (par exemple NUnit,
xUnit, SpecFlow) ainsi que sur les systèmes CI comme Jenkins, Azure DevOps.

78/109
 ● Configurable: Définit les stratégies de recherche de composants par défaut ainsi que
des paramètres supplémentaires. [Link] fournit des configurations
JSON flexibles.
● Rapports: Journalisation personnalisable intégrée et fonctionnalité de capture
d'écran.
● Page Object Model: Fournit un modèle d'objet de page fluide unique, facile à
implémenter et à gérer.
● Vérification: Un ensemble de méthodes et de déclencheurs d'assertion fluides pour la
vérification des composants et des données.

Robot Framework

Un framework de Keyword-Driven Testing

Robot Framework est surtout un framework de Keyword-Driven Testing, mais c’est aussi un
framework hybride, puisqu’il supporte les tableaux de données du Data-Driven Testing et la
syntaxe Gherkin de Behavior-Driven Development. Il fournit un cadre d'automatisation open
source générique pour les tests d'acceptation, le développement piloté par les tests
d'acceptation (ATDD) et l'automatisation des processus robotiques (RPA). Il a une syntaxe
de données de test tabulaire facile à utiliser et il utilise l'approche de test basée sur les
mots-clés.
Robot Framework peut être utilisé pour :
● les tests d’application web avec Selenium WebDriver ;
● les tests d’application mobile avec Appium ;
● les tests d’interface graphique avec SikuliX ;
● les tests d’API HTTP ;
● et bien d’autres tests encore8.
Ses capacités de test peuvent être étendues par des bibliothèques de test implémentées en
Python ou Java, et les utilisateurs peuvent créer de nouveaux mots d’action de niveau
supérieur à partir de mots d’action existants en utilisant la même syntaxe que celle utilisée
pour créer des cas de test.

Robot Framework vient avec plusieurs éditeurs de code ou IDE. Il s’accompagne

notamment d’un IDE nommé RED (Robot EDitor), fondé sur Eclipse IDE.

Exemple d’automatisation
TODO Xavier : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

8
Robot Framework, Libraries, [Link]

79/109
Astuces avec Robot Framework

Factorisation des phases de préparation et de suppression

Quand des instructions sont identiques pour tous les cas d'une même suite de test,
regroupez-les dans un mot d'action, puis invoquez ce dernier comme il convient.

Phase Mot d’action Invocation

Préparation Suite Setup Une seule fois, avant tous les cas de test.

Préparation Test Setup Avant chaque cas de test.

Suppression Test Teardown Après chaque cas de test.

Suppression Suite Teardown Une seule fois, après tous les cas de test.

Si ce mot d'action de préparation ou de suppression est utile à plusieurs suites de test,

partagez-le entre ces suites de test, en le plaçant dans un fichier ".resource".

Typer les étapes des cas de test

Si vos mots d'action dans un cas de test se focalisent tous sur une étape de test seulement,
que ce soit une préparation, une action ou une vérification, pourquoi ne pas les typer en les
préfixant par Given (préparation), When (action) ou Then (vérification), pour encore plus de
lisibilité ? Ces préfixes sont nativement supportés par Robot Framework9.

Given-When-Then dans la langue des tests

Si vos tests sont en Français par exemple, il serait dommage, et inélégant, de préfixer
chaque étape de test par Given, When ou Then. Alors comment leur substituer “Comme”,
“Quand” et “Alors” ? Pour cela, il suffit de définir des mots d’action personnalisés. Mieux
encore, il vous suffit d’utiliser la bibliothèque TestAsYouThink pour Robot Framework. Vous y
trouverez les mots d’action français pour utiliser Robot Framework en Gherkin, et d’autres
choses encore !

Sélection d'éléments web non standards

Votre application comporte des attributs HTML dont vous aimeriez vous servir pour identifier
une balise. Malheureusement pour vous, ces attributs ne sont pas standards… Aucun
problème ! Robot Framework permet de mettre en place des stratégies de sélection
personnalisées, puis de les utiliser de façon transparente dans un cas de test.

Paramétrage de RED
Pour une meilleure expérience de développement, et de collaboration en équipe, nous vous
recommandons de modifier quelques préférences de l’IDE, comme suit. Il vous faudra la
9
Robot Framework User Guide, Behavior-driven style,
[Link]

80/109
dernière version de RED (0.9.3 à ce jour), ainsi qu'installer le plugin “PyDev - Python IDE for
Eclipse".

Préférence Option Valeur (s’il y a)

General > Appearance Theme Dark

General > Editors > Text Editors Insert spaces for tabs

Remove multiple spaces on

backspace/delete

Show whitespace characters

PyDev > Editor > Code Style > Right trim lines?
Code Formatter

Robot Framework > Editor > Adjust separator lengths

Code Formatter
Separator length 2

Right trim lines

Robot Framework > Editor > Add library or resource name to only when
Content Assist > Keywords keyword proposal insertion conflict exists

Robot Framework > Editor > Format editor contents

Save Actions

Robot Framework > Errors / Keyword from nested library Ignore

Warnings > Validation > Code
style

Vous voilà équipé pour un code de test bien formaté et pour éviter des conflits de
versionnage inutiles.

Codez-les
Certaines opérations deviennent tellement plus simples en les programmant directement en
Python ou en JavaScript. Si vous ne souhaitez pas vous encombrer d'un fichier pour
quelques lignes de code, rien de plus facile. Vous disposez de quatre mots d'action pour
exécuter des lignes de code dans vos mots d'action personnalisés.
● Evaluate pour évaluer une expression en Python, ainsi que Call Method pour
invoquer une méthode sur un objet Python, avec la bibliothèque BuiltIn.
● Execute JavaScript pour JavaScript, avec la bibliothèque SeleniumLibrary, ainsi que
Execute Async JavaScript, mais pour un code asynchrone.

Langage Exemple de code

81/109
 Python # Ce code génère un nombre entier aléatoire.
${random} = Evaluate [Link](0, [Link])
modules=random, sys

JavaScript # Ce code génère un nombre entier aléatoire.

${random} = Execute JavaScript [Link]([Link]() *
Number.MAX_SAFE_INTEGER)

Nommer les arguments

Si un mot d’action comporte un nombre de paramètres supérieur ou égal à 3, ou que la
signification des arguments n’est pas évidente, vous auriez peut-être intérêt à les nommer à
la suite du mot d’action pour favoriser la lisibilité de votre code de test. Un autre avantage à
cela est de ne plus se préoccuper de la position respective des arguments.

Exemple de code

Open Browser browser=Firefox url=[Link]

remote_url=[Link]
desired_capabilities=platform:WINDOWS,version:75

Les trois petits points

Si vous souhaitez écrire une instruction sur plusieurs lignes, parce qu’une seule serait trop
longue et difficile à lire, les 3 points sont cet ami que vous cherchiez. C’est particulièrement
vrai avec les instructions conditionnelles.

Exemple de code

Run Keyword If ${boolean}

… Do Something
… ELSE Do Something Else

Mots d’action publics et privés

Pas plus avec Robot Framework qu’avec Python, il n’est possible de restreindre la visibilité
d’un mot d’action, comme d’une méthode. Vous pouvez toutefois adopter une convention
bien utile pour distinguer un mot d’action public, c’est-à-dire qui peut être invoqué à
l’extérieur du fichier “resource”, d’un mot d’action privé, utilisé seulement par un mot d’action
publique.
● Un mot d’action public commence par une lettre capitale.
● Un mot d’action privé commence par une lettre minuscule.

82/109
Cypress

Un framework de ???
Cypress est un framework de test javascript de bout en bout, qui comprend de nombreuses
fonctionnalités intégrées dont vous aurez besoin dans n'importe quel outil d'automatisation.
Cypress utilise le framework de test Mocha et la bibliothèque d'assertions chai dans son
framework et principalement il n'est pas construit au-dessus du selenium, c'est un nouveau
pilote qui fonctionne dans votre application et cela permet un très bon contrôle sur votre
frontend et backend de l'application.

Caractéristiques du cypress
● Cypress offre une nouvelle architecture et s’exécute dans le navigateur avec votre
application. Tests et développements se font donc simultanément.
● Cypress fonctionne, quel que soit le framework JavaScript que vous utilisez : React
Js, Angular, Vue Js,…
● Vous écrivez vos tests en JavaScript (avec Mocha, Chai et Sinon). Vous restez donc
dans une technologie commune.

Exemple d’automatisation
TODO Zied : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

83/109
Astuces avec Cypress

Organisation des tests, connexion, contrôle de l'état

Testez les spécifications isolément, connectez-vous par programme à votre application et
prenez le contrôle de l'état de votre application.

Sélection des éléments

Utilisez des data-* attributs pour fournir du contexte à vos sélecteurs et les isoler des
modifications CSS ou JS.

Chaque test que vous écrivez inclura des sélecteurs d'éléments. Pour vous éviter beaucoup
de maux de tête, vous devez écrire des sélecteurs résistants aux changements.
Souvent, nous voyons des utilisateurs rencontrer des problèmes pour cibler leurs éléments
parce que:
● Votre application peut utiliser des classes dynamiques ou des ID qui changent.
● Vos sélecteurs se séparent des modifications de développement apportées aux
styles CSS ou au comportement JS.
Il est possible d'éviter ces deux problèmes.
1. Ne ciblez pas les éléments en fonction des attributs CSS tels que: id, class, tag.
2. Ne ciblez pas les éléments susceptibles de modifier leur textContent.
3. Ajouter des data-* attributs pour faciliter le ciblage des éléments.

Comment ça fonctionne

Étant donné un bouton avec lequel nous voulons interagir:

<button id="main" class="btn btn-large" name="submission"
role="button" data-cy="submit">Submit</button>

Visiter des sites externes

Testez uniquement ce que vous contrôlez. Essayez d'éviter d'exiger un serveur tiers. Si
nécessaire, utilisez toujours [Link]() pour parler à des serveurs tiers via leurs API.

L'une des premières choses que beaucoup des utilisateurs tentent de faire est d'impliquer
des serveurs tiers dans leurs tests.
Vous souhaiterez peut-être accéder à des serveurs tiers dans plusieurs situations:
1. Tester la connexion lorsque votre application utilise un autre fournisseur via OAuth.
2. La vérification de votre serveur met à jour un serveur tiers.
3. Vérifier votre e-mail pour voir si votre serveur a envoyé un e-mail "mot de passe
oublié".
Au départ, vous pourriez être tenté d'utiliser [Link]() ou d'utiliser Cypress pour accéder à la
fenêtre de connexion tierce.

84/109
Cependant, vous ne devez jamais utiliser votre interface utilisateur ou visiter un site tiers lors
des tests car:
● Cela prend énormément de temps et ralentit vos tests.
● Le site tiers peut avoir changé ou mis à jour son contenu.
● Le site tiers peut avoir des problèmes hors de votre contrôle.
● Le site tiers peut détecter que vous testez via un script et vous bloquer.

Création de «tiny» tests avec une seule assertion

Ajoutez plusieurs assertions et ne vous en faites pas.

Plusieurs utilisateurs écrire ce type de code:

describe('my form', () => {

before(() => {
[Link]('/users/new')
[Link]('#first').type('johnny')
})

it('has validation attr', () => {

[Link]('#first').should('[Link]', 'data-validation',
'required')
})

it('has active class', () => {

[Link]('#first').should('[Link]', 'active')
})

it('has formatted first name', () => {

[Link]('#first').should('[Link]', 'Johnny') // capitalized
first letter
})
})

Bien que techniquement, cela fonctionne bien - c'est vraiment excessif et pas performant.
Pourquoi vous avez fait ce modèle dans les tests unitaires :

● Lorsque les assertions ont échoué, vous vous êtes appuyé sur le titre du test pour
savoir ce qui a échoué.
● On vous a dit que l'ajout de plusieurs assertions était mauvais et avez accepté cela
comme une vérité.

85/109
 ● Il n'y a pas eu de pénalité de performance en fractionnant plusieurs tests car ils
fonctionnent très vite.

Pourquoi vous ne devriez pas faire cela dans Cypress:

● L'écriture des tests d'intégration n'est pas la même chose que les tests unitaires
● Vous saurez toujours (et pouvez voir visuellement) quelle assertion a échoué dans
un grand test.
● Cypress exécute une série d'événements de cycle de vie asynchrones qui
réinitialisent l'état entre les tests.
● La réinitialisation des tests est beaucoup plus lente que l'ajout de nouvelles
assertions.

Il est courant que les tests dans Cypress émettent plus de 30 commandes. Parce que
presque toutes les commandes ont une assertion par défaut (et peuvent donc échouer),
même en limitant vos assertions, vous ne vous enregistrez rien car toute commande unique
pourrait échouer implicitement.

Comment réécrire ces tests:

describe('my form', () => {
before(() => {
[Link]('/users/new')
})

it('validates and formats first name', () => {

[Link]('#first')
.type('johnny')
.should('[Link]', 'data-validation', 'required')
.and('[Link]', 'active')
.and('[Link]', 'Johnny')
})
})

Attente inutile
Utilisez des alias de route ou des assertions pour empêcher Cypress de continuer jusqu'à ce
qu'une condition explicite soit remplie.
Dans Cypress, vous n'avez presque jamais besoin de l'utiliser [Link]() pendant une durée
arbitraire. Si vous vous trouvez en train de faire cela, il existe probablement un moyen
beaucoup plus simple.

[Link]()

86/109
[Link]('GET', /users/, [{ 'name': 'Maggy' }, { 'name': 'Joan'
}])
[Link]('#fetch').click()
[Link](4000) // <--- this is unnecessary
[Link]('table tr').should('[Link]', 2)

Une meilleure solution à ce problème consiste à attendre explicitement une route aliasée.

[Link]()
[Link]('GET', /users/, [{ 'name': 'Maggy' }, { 'name': 'Joan'
}]).as('getUsers')
[Link]('#fetch').click()
[Link]('@getUsers') // <--- wait explicitly for this route to
finish
[Link]('table tr').should('[Link]', 2)

Web Servers
Démarrez un serveur Web avant d'exécuter Cypress.
Le démarrage d’un serveur Web à partir de [Link]() ou [Link]() provoque des problèmes
car:

● Vous y perdez l'accès via le terminal.

● Vous n'avez pas accès à ses stdout ou les logs.
● Chaque fois que vos tests s'exécutent, vous devez déterminer la complexité du
démarrage d'un serveur Web déjà en cours d'exécution.
● Vous rencontreriez probablement des conflits de port constants.

Pourquoi ne puis-je pas arrêter le processus dans le hook after?

Parce qu'il n'y a aucune garantie que le code exécuté dans un after s'exécutera toujours.
Pendant que vous travaillez dans Cypress Test Runner, vous pouvez toujours redémarrer /
actualiser en cours de test. Lorsque cela se produit, le code dans after ne s'exécute pas.

Que dois-je faire alors?

Démarrez votre serveur Web avant d'exécuter Cypress et tuez-le une fois qu'il est terminé.

Définition d'une baseUrl globale

Définissez un baseUrl dans votre fichier de configuration ( [Link] par défaut).
L'ajout d'un baseUrl peut également gagner du temps lors du démarrage initial de vos tests
Cypress.

87/109
Lorsque vous commencez à exécuter vos tests, Cypress ne connaît pas l'URL de
l'application que vous prévoyez de tester. Ainsi, Cypress s'ouvre initialement sur
[Link] un port aléatoire.

Cucumber

Un framework de BDD
Cucumber est un framework de test qui prend en charge le cadre de développement axé sur
le comportement (BDD). Il définit le comportement de l'application à l'aide d'un texte anglais
simple, défini par une langue appelée Gherkin.

Gherkin utilise un ensemble de mots clés spéciaux pour donner une structure et un sens aux
spécifications exécutables. Gherkin permet d’écrire des scénarios de test compréhensibles
par des individus non techniques. Cette approche sert deux objectifs : documenter les
fonctionnalités à développer d’une part, et permettre l’automatisation des tests d’autre part.

La plupart des lignes d'un document Gherkin commencent par l'un des mots clés:
● Le “Given” mot-clé précède le texte définissant le contexte; l'état connu du système
(ou condition préalable).
● Le “When” mot-clé précède le texte définissant une action.
● Le “Then” mot-clé précède le texte définissant le résultat de l'action sur le contexte
(ou résultat attendu).

Fonctionnement de Cucumber
Au moment où le code et les scripts de test sont prêts. Le code doit passer les scripts de
test définis dans BDD. Si cela ne se produit pas, une refactorisation du code sera
nécessaire. Le code n'est gelé qu'après une exécution réussie des scripts de test définis.

88/109
Exemple d’automatisation
TODO Xavier : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de

89/109
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

Behat

Un framework de BDD
Behat est un framework de Behavior-Driven Development pour PHP. Il s'agit d'un outil pour
vous aider à fournir des logiciels importants par le biais d'une communication continue,
d'une découverte délibérée et d'une automatisation des tests.

SpecFlow

Un framework de BDD
SpecFlow est un framework de test et un plug-in qui s’intègre avec Visual Studio, qui permet
d’écrire des tests d’une manière naturelle, puis de les exécuter avec un dérouleur de [Link]
se base su un principe de BDD.
Specflow permet de créer des tests unitaires à partir de comportements écrits en syntaxe
Gherkin (Given,When,Then).

Exemple d’automatisation
TODO Zied : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

Protractor

Un framework de ???
Protractor est un framework de test pour les applications Angular et AngularJS. C’est un
superset de Selenium et se base sur le même driver que ce dernier afin d’envoyer des
commandes au navigateur.

Exemple d’automatisation
TODO Zied : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de

90/109
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

Caractéristiques de Protractor

Tester comme un utilisateur: Protractor est basé sur WebDriverJS, qui utilise des événements
natifs et des pilotes spécifiques au navigateur pour interagir avec votre application comme le
ferait un utilisateur.

Pour les applications angulaires: Protractor prend en charge les stratégies de localisation
spécifiques à Angular, ce qui vous permet de tester des éléments spécifiques à Angular sans
aucun effort de configuration de votre part.

Attente automatique: Vous n'avez plus besoin d'ajouter des temps d'attente à votre test.
Protractor peut exécuter automatiquement l'étape suivante de votre test au moment où la page
Web termine les tâches en attente.

Bonnes pratiques avec Protractor

Voici une liste des bonnes pratiques pour construire un framework d’automatisation efficace
avec Protractor.

● Utilisez TypeScript au lieu de JavaScript

● L'objet de page est définitivement un modèle de conception incontournable
● Un fichier TypeScript, une classe d'objets page
● Ayez toujours de bonnes conventions de codage pour les objets de page
● Supprimer l'importation circulaire TypeScript / JavaScript
● Gérer le comportement asynchrone de JavaScript en utilisant asynchrone
● Envelopper l'élément Protractor et les objets originaux du navigateur
● La méthode de l'objet page doit attendre que la page soit entièrement chargée avant
de quitter
● ProtractorBy est le plus rapide mais XPath est le localisateur le plus stable
● Le cas de test ne doit appeler que les méthodes de l'objet de page
● Ne placez pas d'assertions dans les classes d'objets de page
● Avoir une structure de projet simple mais efficace
● Poussez uniquement les éléments nécessaires vers le référentiel de code

Astuces avec Protractor

Écrire un cas de test n'est pas un gros problème, mais le plus important c’est d’écrire un bon
cas de test. Vous devez savoir quelle méthode de Protractor utiliser. Voici des meilleures
pratiques à suivre lors de la rédaction d'un scénario de test.

TODO Zied

91/109
[Link] () VS [Link] ()

Supposons que nous appuyons sur un bouton et qu'ensuite un pop-up s'ouvre. Maintenant,
pour tester cela, nous voulons une pause après avoir appuyé sur le bouton.

Lorsque nous utilisons sleep (5000), c'est-à-dire sleep de 5 secondes, après avoir appuyé
sur le bouton. le navigateur cessera de fonctionner pendant 5 secondes après avoir appuyé
sur le bouton et après 5 secondes, il commencera à fonctionner, c'est-à-dire qu'il
commencera à effectuer des actions sur le pop-up. Maintenant, lorsque nous utilisons wait
([Link] (), 5000) , il attendra que le pop-up soit affichée dans les 5 secondes.

Donc, quelle est la différence entre les deux, “sleep” va se mettre en pause pendant 5
secondes, même si le pop-up peut être affichée en 1 seconde seulement, mais “wait” va
s'arrêter pendant seulement 1 seconde si le pop-up s'affiche en 1 seconde.

Il est préférable d'utiliser [Link] () au lieu de [Link] ()

toBe () vs toEqual ()

toEqual () est similaire à l'équivalence (==) en JavaScript, tandis que toBe () est similaire à
l'équivalence stricte (===) en JavaScript.
Donc, si nous avons deux objets A et B,
var A = {
firstName = FirstName,
lastName = LastName
}
var B = {
firstName = FirstName,
lastName = LastName
}

expect(A).toEqual(B); // returns true

expect(A).toBe(B); // returns false

toBe (true) vs toBeTruthy () vs toBeTrue ()

toBe (true) fonctionne de la même manière que l'équivalence stricte JavaScript (===)

return {
pass: actual === expected
};

toBeTruthy ()

92/109
Quand quelque chose est truthy, il peut ou non être un booléen, mais la valeur de «cast» est
un booléen.
return {
pass: !!actual
};

Certaines des valeurs qui sont “Truthy” sont :

true == true; // truthy
1 == true; // truthy
"hello" == true; // truthy
[1, 2, 3] == true; // truthy
[] == false; // truthy
false == false; // truthy
0 == false; // truthy
"" == false; // truthy
undefined == false; // truthy
null == false; // truthy

toBeTrue () vérifie si la valeur retournée est True

return actual === true ||
is(actual, 'Boolean') &&
[Link]();

Utiliser toBe (true) est la meilleure option

isPresent () vs isDisplayed ()

isPresent () vérifie si l'élément existe dans le DOM et peut être visible ou masqué. D'un
autre côté, isDisplayed () vérifie si l'élément existe dans le DOM et est également visible.

[Link] () vs [Link] ()

presence () vérifie un élément présent dans le DOM et peut être visible ou non.
visibilityOf() vérifie un élément présent dans le DOM et également visible c'est à dire à la
hauteur et la largeur.

SikuliX

Un framework de ???
SikuliX automatise tout ce que vous voyez sur l'écran de votre ordinateur de bureau
fonctionnant sous Windows, Mac ou Linux / Unix. Il utilise la reconnaissance d'image

93/109
optimisée par OpenCV pour identifier les composants de l'interface graphique. C’est pratique
dans les cas où il n'y a pas d'accès facile aux composants internes d'une interface
graphique ou au code source de l'application ou de la page Web sur laquelle vous souhaitez
agir.

Gauge

Un framework de Behavior Driven Test

Gauge est un framework d'automatisation de test open source gratuit publié par les
créateurs de Selenium, ThoughtWorks. L'automatisation des tests avec le framework Gauge
est utilisée pour créer des tests lisibles et maintenables avec la langage de développement
de votre choix.
Gauge est l'un des outils avancés d'automatisation des tests légers qui fournit des
fonctionnalités multiplates-formes. Il présente une syntaxe simple, riche et flexible et
effectue une exécution pilotée par les données. Les cas de test dans ce framework peuvent
être facilement compris et maintenus.

Caractéristiques de Gauge
Vous pouvez choisir Gauge pour créer vos scripts de test d'automatisation, car il fournit des
fonctionnalités puissantes comme:

● La parallélisation
● La gestion transparente des modifications
● Une syntaxe flexible et facile à utiliser
● Tests créés à l'aide d'un langage professionnel
● Prise en charge de toutes sortes de plateformes et de langues
● Une tonne de plugins
● Prise en charge des sources de données externes
● Toute cette génialité est open source

Appium

Un framework de ???
Appium est une bibliothèque d'automatisation de test open source pour automatiser les tests
des applications natives, web, mobiles et hybrides sur des plateformes iOS et Android. Il
s'agit essentiellement d'un outil d'automatisation mobile multiplate-forme.

94/109
Appium supporte les applications natives, web mobiles et hybrides, les codes de test
peuvent être écrits dans n'importe quel framework ou langage comme C # et Java sans
avoir à modifier les applications.
Appium est utilisé avec l’un des frameworks suivants, en fonction du langage de
programmation adopté.

Langage Frameworks de test

Java JUnit
Kotlin TestNG

Python Unittest
Pytest
Pytest-django

C# NUnit
XUnit
MSTest

Ruby RSpec
Minitest
Test-unit

JavaScript Jasmine
MochaJS
QUnit

Objective C

Php PHPUnit

Architecture d’Appium

Appium est presque identique au serveur Selenium. L’outil Appium est principalement un
serveur, il est implémenté en [Link] et s’appuie sur les Webdriver de Selenium.
Appium lance un « scénario de test» sur le périphérique qui génère un serveur et écoute les
commandes de proxy du serveur principal Appium. Chaque fournisseur, comme iOS et
Android, utilise une méthode et un mécanisme différents pour exécuter un scénario de test
sur le périphérique. Appium s'introduit dans le programme et exécute ce scénario de test
après avoir écouté les commandes du serveur Appium.

● Similaire à WebDriver Server

● Une architecture client-serveur
● Serveur - Nœud Js

95/109
 ● Client - vos scripts automatisés
● Recevoir une demande du client> Exécuter des commandes sur des appareils /
émulateurs> Une réponse HTTP est répondue

Avantages et inconvénients d'Appium

Avantages

● Appium peut automatiser les tests des applications mobiles, web, hybrides et
natives.
● Différents langages sont supportés (Java, Objective-C, JavaScript, PHP, Python,
Ruby, C#...)

Inconvénients

● Appium ne supporte pas les versions d’Android inférieures à 4.2.

● Le test d’application IOS en parallèle n’est pas possible mais peut être contourné
avec le test cloud.

MaTeLo

Un framework de Model-Based Testing

MaTeLo (d’All4tec) est un outil de le model based testing (MBT) qui permet la génération
automatique de tests, leur automatisation et la gestion des données à partir d'un design
graphique.
MaTeLo intègre un éditeur graphique ergonomique pour concevoir le comportement de vos
applications, en utilisant des concepts simples. Il peut importer vos besoins et surveiller leur
couverture par les cas de test générés, déduits de votre conception comportementale.
MateLo est basé sur un diagramme hiérarchique état / transition, permettant de représenter
l'entrelacement des chemins fonctionnels. Les représentations graphiques dans MaTeLo
intègrent également l'environnement applicatif (comportement utilisateur, autres applications,
etc.) pour pouvoir générer des cas de test complets et représentatifs pour tout type de
système testé.

Yest

Un framework de Model-Based Testing

Yest (de Smartesting) met en œuvre la bonne pratique d’automatisation par mots-clé[Link]
apporte une maîtrise de bout-en-bout du processus d’automatisation, depuis la conception
jusqu’aux phases de maintenance en optimisant vos ressources d’automaticiens.
Yest permet:

96/109
 ● La conception visuelle de tests avec contrôle de la couverture (ATDD graphique)
● L'implémentation de tests optimisés pour l'exécution manuelle.
● La définition simple et efficace de jeux de données.
● La génération de scripts fonctionnels pour l'automatisation.

Les principaux fonctionnalitées de Yest:

● Éditeur graphique simple pour conception visuelle des tests et maîtrise de la

couverture.
● Accélérateur d’implémentation des scénarios de test.
● Création et validation des jeux de données.
● Préparation des campagnes d’exécution manuelle.
● Génération des scripts de tests pour l’automatisation.
● Fonctions d’ergonomie et de gestion de projets.
● C’est aussi un outil de modélisation des spécifications (workflow métier)

TestCafé

Un framework de ???
TestCafé est un framework d’automatisation de test…
est un outil d’automatisation s'appuyant sur [Link] pour les tests orientés UI. Il est gratuit
et open source, facile à configurer et fonctionne sur tous les environnements populaires. La
rédaction des tests se fait en langage Javascript ou Typescript.
TestCafe s’interface avec toutes les plateformes (Windows, Mac OS, Linux, mobile ou
encore Cloud) et tous les navigateurs (Internet Explorer, Edge, Firefox, Safari, Chrome, …).

Facile à installer- Vous n'avez pas besoin de WebDriver ou de tout autre logiciel de test.
Installez TestCafé avec une seule commande et vous êtes prêt à tester. npm install -g
testcafe

Gratuit et Open Source- TestCafé est gratuit à utiliser sous la licence MIT. Les plugins
fournissent des rapports personnalisés, l'intégration avec d'autres outils, le lancement des
tests à partir d'IDE, etc. Vous pouvez utiliser les plugins créés par la communauté GitHub ou
créer les vôtres.
Fonctionne sur tous les environnements populaires- TestCafé fonctionne sur Windows,
MacOS et Linux. Il prend en charge les navigateurs de bureau, mobiles, distants et cloud (UI
ou headless).

97/109
Comment ça fonctionne ?
TestCafé utilise un URL-rewriting proxy au lieu de WebDriver. Ce proxy injecte le script de
pilote qui émule les actions des utilisateurs dans la page testée. De cette façon, TestCafé
peut faire tout ce qui est nécessaire pour les tests: il peut émuler les actions de l'utilisateur,
l'authentification, exécuter ses propres scripts, etc. Il ne subit aucune interférence directe
avec les scripts.

Fonctionnalités proposées par TestCafé

● Le support du design pattern Page Object Model (POM)
● La gestion des rôles: permettant de faire plusieurs sessions au sein d’un même
navigateur sans devoir faire un login/logout pour passer d’une session à une autre
● L’exécution concurrentielle pour gagner en temps d’exécution
● L’intégration facile à une CI avec la présence d’une image Docker prête à l’emploi

Exemple d’automatisation
TODO Zied : À partir du moment où l’on a identifié qu’une technologie appartient à un type
de framework, implémenter un cas de test tel que défini par le scénario fil rouge de la
typologie pour une application Todos, avec ce framework. /!\ Attention : ce cas de test doit
être automatisé conformément à l’implémentation en pseudo-code relative au type de
framework correspondant (par ex. : se reporter au paragraphe “Utilisation” de
“Automatisation de test par mots d’action” pour un framework de Keyword-Driven Testing
comme Robot Framework).

98/109
Tests en parallèle

TestCafé peut exécuter les tests sur la même instance de navigateur plusieurs fois
simultanément ou sur plusieurs instances de navigateur à la fois. Cela peut également être
fait sur des navigateurs distants. Cette pratique peut réduire considérablement le temps
d’exécution des tests.

Les sélecteurs de TestCafé

Avec un ensemble des sélecteurs à usage général basés sur des sélecteurs CSS ou du
code JS, TestCafe fournit plusieurs sélecteurs pour les frameworks populaires.

● React selectors
● Angular selectors
● AngularJS selectors
● Vue selectors
● Aurelia selectors

Pas besoin de plugins externes

TestCafé ne nécessite aucun plugin externe pour exécuter des tests sur différents
navigateurs. Il peut détecter automatiquement tous les navigateurs populaires installés sur
l'ordinateur local, ce qui permet aux testeurs d'éliminer plus facilement les efforts de
configuration des plugins.

Intégration continue
TestCafe peut s’intégrer dans un processus de génération sur des systèmes d'intégration
continue populaires.

● AppVeyor
● Azure DevOps
● Bitbucket Pipelines
● CircleCI
● GitHub Actions
● GitLab
● Jenkins
● TeamCity
● Travis
● Travis + Sauce Labs

99/109
Rapports TestCafé

TestCafé permet de générer différents types de rapports pour afficher le résultat de test à
l'aide de son reporter intégré. Il permet également de créer un reporter personnalisé qui
produira des informations dans un format et style souhaités. Les rapports qui peuvent être
créés répertoriés ci-dessous:

● spec (utilisé par défaut)

● liste
● minimal
● XUnit
● JSON

Points forts de TestCafé

● Haute stabilité sur la quasi totalité des navigateurs du marché
● Langage maîtrisé par des développeurs front
● Simplicité et facilité pour démarrer les tests mais aussi inclure ces derniers dans une
CI
● Lisibilité et maintenabilité du code avec l’utilisation du POM
● Gestion des échecs: captures d’écran, mode debug dans le navigateur, prise de
vidéo (avec une dépendance tiers)
● Documentation claire et riche
● Gratuit et opensource

TestComplete

Un framework de ???
TestComplete est un outil logiciel automate de tests, qui vous permet de créer, piloter et
exécuter automatiquement les tests pour les applications Windows (desktop), web ou
mobiles.

TestComplete fonctionne sur des environnements de machines virtuelles, ou sur des postes
fixes, selon la configuration, et avec les principaux référentiels de tests (QAComplete, HP
Quality Center…) et également avec Selenium (Open Source), en utilisateur unique ou en
accès multi-utilisateurs sur un ou plusieurs postes de travail.

TestComplete supporte toutes les technologies et peut travailler pour tous types
d’applications (Windows store Apps, WPF, Visual C++, Delphi, Java, Qt) et Web (HTML5,
Flash, Silverlight, AIR, Apache Flex, AJAX…), et supporte tous les langages de scripts
(JavaScript, VBScript, DelphiScript, C++Script, C#Script…).

100/109
TestComplete est un outil d’automatisation par script linéaire (record & playback) permet de
créer rapidement des tests automatisés en enregistrant des actions dans les applications de
bureau, Web et mobiles. TestComplete peut enregistrer la saisie de données, la sélection
d'éléments, la navigation sur le site Web, la soumission de formulaires, les gestes mobiles et
d'autres actions de l'utilisateur. Vous pouvez également créer des points de contrôle pendant
l'enregistrement de test. En utilisant TestComplete, vous pouvez enregistrer des tests de
mots clés, des scripts et des procédures low-level.

Amélioration et révision des tests

Après avoir enregistré un test, vous pouvez le réviser et l'améliorer dans les éditeurs
intégrés de TestComplete.

● Démarrage, pause et arrêt de l'enregistrement

● Ajout d'enregistrements au test de mots clés actuel
● Après le début de l'enregistrement
● Choses qui peuvent être faites pendant l'enregistrement du test
● Enregistrement du démarrage de l'application
● Modification du type du test enregistré
● Noms par défaut des tests enregistrés
● Enregistrement de différents types de tests
● Options et spécificités d'enregistrement

Modification du type du test enregistré

TestComplete peut enregistrer des tests sous la forme:

● Keyword Tests
● Scripts
● Procédures low-level (pour les applications de bureau et Web uniquement)

Enregistrement de différents types de tests

TestComplete permet d’enregistrer différents types de tests:

● Création et enregistrement de tests de mots clés

● Création et enregistrement de tests Web
● Enregistrement de tests Android
● Enregistrement de gestes (événements multi-touch)
● Enregistrement de tests iOS
● Enregistrement des tests pour les applications mobiles hybrides
● Création et enregistrement de procédures de bas niveau

Options et spécificités d'enregistrement

TestComplete a des options qui affectent le processus d'enregistrement. Pour les afficher ou
les modifier, vous pouvez effectuer l'une des opérations suivantes:

101/109
 ● Au moment du design, sélectionnez Tools> Options dans le menu principal
TestComplete, puis sélectionnez la catégorie Engines> Recording.
● Pendant l'enregistrement test, cliquez sur la barre d'outils Recording.

Comparaison des implémentations de framework

Caracté Robot
Katalon Seleniu TestCo Appiu Cypres TestCaf
ristique UFT Sikulix Gauge framew
Studio m mplete m s é
s ork
Platefor Multipla Multipla window window Multipla Multipla Multipla Multipla Multipla Multipla
me de teforme teforme s s teforme teforme teforme teforme teforme teforme
dévelop
pement
de test
Applicat Web, Applicat Bureau Bureau Applicat Applicat Applicat Applicat Applicat Applicat
ion mobiles ions Window Window ion ion ions ion ion ion
, API / Web s, Web, s, Web, Bureau, Web Mobile Web,m Web,m Web,
Web mobiles mobiles Web, obile obile mobile
services , API / , API /
Web Web
services services
Langag Java / Java, C VBScrip JavaScr Java,Py Java, C Java, C JavaScr Php JavaScr
es de Groovy #, Perl, t ipt, thon,Ja #, #, Perl, ipt ipt
script Python, Python, vaScript Python, Python,
JavaScr VBScrip ,Ruby,C JavaScr JavaScr
ipt, t, # ipt,Type ipt,
Ruby, JScript, script et Ruby,
PHP Delphi, Golang, PHP
C ++ et Ruby
C#
Coût Gratuit Gratuit Licence Licence Gratuit Gratuit Gratuit Gratuit Gratuit Licence

102/109
Solutions Low-Code d’automatisation de test

Low-Code : de quoi s’agit-il ?

Une plateforme Low-Code donne la possibilité à des personnes qui ne sont pas forcément
des expertes techniques de mettre en place rapidement des applications pour son
organisation, sans avoir besoin de faire de développement outre mesure.

CloudNetCare
CloudNetCare est une solution 100% Web permettant aux équipes techniques et marketing
de superviser la qualité de leur application. Vous pourrez créer des scénarios de navigation
afin de tester régulièrement l'expérience utilisateur et le comportement de l'application. Le
détail du reporting permet de mesurer les temps de réponses mais aussi le temps passé par
les utilisateurs sur une page donnée.

CloudNetCare vous permet par ailleurs d'intégrer des scénarios au format Selenium pour
créer rapidement vos parcours avec Firefox. Chaque scénario peut être utilisé pour un test
de montée en charge, un test fonctionnel, ou une supervision applicative. Le tableau de bord
de CloudNetCare offre une vue macro de tout le scénario mais également une vue précise
par page, le détail des requêtes HTTP, et une vue détaillée des erreurs. Un enregistrement
vidéo est également réalisé pour comprendre les erreurs ou les bonnes performances de
l'application.

Agilitest
Agilitest est un outil d’automatisation de test low-code, conçu pour les testeurs fonctionnels
qui n’ont pas de compétence en développement, mais qui souhaitent quand même prendre
en main l’automatisation des tests fonctionnels d’IHM sans dépendre des développeurs ou
automaticiens. La conception des cas de test est purement visuelle, et celle des jeux de
données supporte le format tabulaire du Data-Driven Testing.

Pour faciliter la conception des cas de test, Agilitest dispose d’un outil de capture 10 pour
identifier les éléments graphiques à cibler par les interactions scriptées. La sélection des
éléments graphiques d’une IHM repose ainsi sur leurs attributs HTML ou classes CSS pour
les applications web, leurs “AutomationIds” pour les applications de bureau Windows11, ou
encore sur la reconnaissance graphique.

À partir du diagramme visuel d’un cas de test, Agilitest génère un script linéaire de test écrit
en ActionTestScript (ATS), qui est un langage de test descriptif open-source, uniquement
utilisé par Agilitest, puis le convertit en un code source Java qui utilise TestNG, ainsi que

10
L’outil de capture Agilitest, [Link]
11
L’automatisation desktop Windows avec Agilitest,
[Link]

103/109
Selenium WebDriver pour le web, un pilote pour Windows, ou l’Android Debug Bridge (ADB)
pour le mobile.

Après l’exécution des tests, des rapports générés sont disponibles au format XML (JUnit),
HTML (TestNG), PDF et ATSV (vidéo). Ces rapports peuvent ensuite être intégrés par
d’autres outils.

Avantages et points forts d’Agilitest

● Les tests sont automatisables sur plusieurs canaux : Agilitest supporte les
technologies Web, Mobile et Desktop.
● Les scripts de test au format ATS peuvent être échangés et versionnés avec un
système de contrôle de version comme Git ou autre.
● L’outil permet à des testeurs sans compétence en développement ou automatisation
d’automatiser des tests logiciels. Cela peut aussi intéresser les représentants du
métier, comme les analystes métier ou les product owners.
● Réduire le coût d’exécution des tests : l’éditeur annonce des gains de productivité de
10 à 30% par rapport à des campagnes de test manuelles.
● Il est possible d’extraire des “sous-scripts” réutilisables.

Limites et points faibles d’Agilitest

● Difficulté à comprendre certains mots clés donc la documentation explicative est très
recommandée et nécessaire.
● L’outil est payant, mais les montants sont peu élevés et vite rentabilisés. De plus, il
est disponible à l’essai pendant une période de 30 jours.
● La reconnaissance graphique est sensible à la résolution de l’écran utilisé au
moment de la capture graphique. Il est recommandé de régler le zoom de la page du
navigateur à 100% et d’utiliser la reconnaissance graphique en dernier recours.

Katalon
Katalon est une plate-forme de test automatisée qui offre un ensemble complet de
fonctionnalités pour implémenter des solutions de test automatisées complètes pour le Web,
l'API et le mobile. Construit sur les frameworks open source Selenium et Appium, Katalon
permet aux équipes de démarrer rapidement l'automatisation des tests en réduisant l'effort
et l'expertise nécessaires à l'apprentissage et en intégrant ces frameworks pour les besoins
de tests automatisés.

Grâce à son IDE Katalon Studio, Katalon est facile à utiliser pour les testeurs non
techniques mais offre des capacités avancées pour les utilisateurs avec des compétences
en développement.

104/109
Ranorex
Ranorex est un framework d'automatisation de test GUI fourni par Ranorex GmbH. Le
framework est utilisé pour tester des applications de bureau, Web et mobiles.

Caractéristiques de Ranorex
● Reconnaissance d'objets GUI
● Filtrage des éléments GUI à l'aide de la technologie RanoreXPath.
● Enregistrement et relecture basés sur des objets à l'aide de Ranorex Recorder.
● Les actions enregistrées sont disponibles en code C # et [Link].
● L' enregistrement et la relecture sont pris en charge sur les appareils mobiles pour
des actions telles que les appuis sur les touches et les gestes tactiles.

105/109
Références Bibliographiques

Référence Ressources

GOST GOST, pour Gears Of Software Testing, est une démarche holistique
de gestion de la qualité logicielle, assortie d’un cadre méthodologique
pour concevoir des stratégies de test adaptatives.
Site officiel : [Link]

ISTQB L’ISTQB est le comité international de qualifications du test logiciel

(International Software Testing Qualifications Board).
Site officiel : [Link]

Ressources :
● Syllabus Niveau Avancé Automatisation de test
[Link]
s/

Wikipedia Programmation
Séparation des préoccupations
Principe KISS

Tests
Acceptance Test-Driven Development
Behavior-Driven Development
Data-Driven Testing
Keyword-Driven Testing
Modularity-Driven Testing
Specification By Example
Test-Driven Development

Articles Most Popular Test Automation Frameworks with Pros and Cons of
Each – Selenium Tutorial #20
Test Automation Frameworks

106/109
 CONTACT@[Link]
All4Test est un pure player du test logiciel en France depuis 2006, présent à Paris,
Sophia-Antipolis, Bordeaux et Tunis.

All4Test et Chrysocode œuvrent ensemble pour construire des offres centrées sur la
Qualité By Design, une approche globale de la qualité, dont l’objectif est
d’accompagner les clients sur les thèmes du “Mieux Spécifier”, “Mieux Développer”,
“Mieux Tester”.

ALL4TEST

CHRYSOCODE
Chrysocode est un cabinet de conseil spécialisé en stratégie IT (augmentation des
capacités opérationnelles des organisations) et dans la conduite du changement
en ingénierie logicielle. Son ambition est de rendre à l'Ingénierie du Code ses lettres
de noblesse, en libérant les potentiels humains et les savoir-faire. Chrysocode a
pour mission de changer et d'améliorer...
✓ la flexibilité de vos organisations et logiciels,
✓ les délais de mise sur le marché de vos produits,
✓ la qualité perçue par vos utilisateurs.

Découvrez la proposition de valeur de Chrysocode à travers son pitch deck, son

offre de conseil et son offre de formation.

CONTACT@[Link]
TODO 4ème de couverture