Automatisation des tests - objectifs et concepts - partie 2

@crochefolle
Automatisation
des tests
Généralités
Objectifs & concepts
Partie 2
@crochefolle

@crochefolle
Rappel de la session précédente
• Quoi ? Qu’est-ce qu’on automatise ?
• Les tests conçus et sélectionnés par les testeurs
• Tout ce qu’on peut et qui est pertinent : construction environnement, générations
de JDD, …
• Qui ?
• Le testeur conçoit, sélectionne, exécute et analyse les résultats
• L’automaticien développe les tests, met à disposition l’infra de test et aide à
l’analyse
• Où ?
• Sur une infrastructure de test
• Quand ?
• Quand c’est pertinent : fréquent, réutilisable, critique, complexe, …
• Combien ?
• Un ROI moyen autour de la 6ième itération
• Comment ?
• C’est l’objet de cette session
• Pourquoi ?

@crochefolle
Objectifs de l’automatisation des tests
• Exécuter des tests répétitifs ou avec beaucoup de calcul (et donc risqués si fait
manuellement)
• Libérer les testeurs de l’exécution de tests répétitifs (et ennuyant ) ou avec
beaucoup de calcul (et donc risqué si fait manuellement)
• Exécuter plus de tests
• Exécuter les tests de régression plus souvent
• S’assurer de la répétabilité des tests de régression
• Construire une plateforme de tests automatisés durable et maintenable
• Ajouter de nouveaux tests facilement

@crochefolle
Agenda
Comment automatiser les tests ?
1. Les différents types de tests automatisés : TU, BDD/TDD, GUI, TDC, Test de
vie …
2. Méthodes d’automatisation
1. Capture/replay
2. Projet de développement
3. Techniques d’automatisation
1. Data driven
2. Keyword driven
3. DSTL
4. Composants technique pour l’automatisation
1. Oracle
2. Bouchon
3. Techniques de comparaison
4. Reporting

@crochefolle
Source : http://dept-info.labri.u-bordeaux.fr/~felix/
Classification des tests

@crochefolle 6
Mike Cohn Testing Pyramid
Répartition des tests

@crochefolle
Tests unitaires
• Tests unitaires
– Code qui permet de tester du code
– Validation basé sur des assertions
• Tests unitaires de base de données
– Code TSQL qui permet de tester une base de données
– Tests des procédures stockées, temps de réponse, cohérence
du résultat, etc.
– Généré au sein d’un test unitaire .NET classique pour
l’exécution

@crochefolle
Test driven development
Écrire un cas de
test
Exécuter les cas
de test
Faire un petit
changement
Exécuter les cas
de test
échec
succès
échec
développement s’arrête
développement
continue
Given Mon compte bancaire possède un crédit de 1000€
And Mon compte épargne possède un crédit de 0€
When Je procède à un virement de 500€ de mon compte bancaire vers
mon compte épargne
Then Mon compte bancaire à un crédit de 500€
And Mon compte épargne à un crédit de 500€

@crochefolle
SpecFlow est à la fois un composant ou framework de test, et un
plug-in pour Visual Studio, qui permet d’écrire des tests d’une
manière naturelle, puis de les exécuter avec votre test-runner
favori.

@crochefolle
Tests UI
• Tests codés de l’interface utilisateur
– Simulent les interactions de l’utilisateur au clavier et à
la souris
– Code généré à partir d’un enregistreur
– Peuvent être personnalisés / écrits manuellement

@crochefolle
Tests de performance/charge
• Tests de performance de site web
– Simulation d’un scénario d’utilisation d’une application web
– Uniquement les interactions au niveau de la couche http
– Peuvent tester des services web
– Permettent de valider le temps de réponse / contenu des
pages
• Tests de charge
– Souvent utilisés de pair avec les tests web
– Permettent de simuler une charge utilisateur sur une
application
– Récoltent des indicateurs permettant l’analyse du
comportement

@crochefolle
Schéma de principe
Postes d’injection
Scénarios de test
Utilisateurs
virtuels simulés
Contrôleur du test
Réseau
Plate-forme testée
application
1.0
données du
test
sonde
Plan de test
Mesures des
sondes système
Temps de réponses
mesurés
Analyse
Recueil du besoin
Rapport du test

@crochefolle
Tests de vie
• Tests de vie de site web
– Simulation d’un scénario d’utilisation d’une application web
– Mesure de la qualité de service

@crochefolle
Exemple de dashboard
15

@crochefolle
Tests de vulnérabilité
• Tests d’intrusion
– Un test d'intrusion (« penetration test » en anglais) est une
méthode d'évaluation de la sécurité d'un système ou
d'un réseau informatique.
– La méthode consiste généralement à simuler une attaque d'un
utilisateur mal intentionné, voire d'un logiciel malveillant. On
analyse alors les risques potentiels dus à une mauvaise
configuration d'un système, d'un défaut de programmation ou
encore d'une vulnérabilité liée à la solution testée. Lors d'un
test d'intrusion, nous nous retrouvons dans la position de
l'attaquant potentiel. Le principal but de cette manœuvre est de
trouver des vulnérabilités exploitables en vue de proposer un
plan d'actions permettant d'améliorer la sécurité d'un système.

@crochefolle
Exemple de dashboard
17

@crochefolle
Méthodes d’automatisation
18
Capture / Replay
Développement

@crochefolle
Capture / Replay
19
Scénario
de test
Capture Script
de test
Instructions
& JDD
Outil de test
Application
à
tester
testeurs automaticiens

@crochefolle
Capture / Replay
• Avantages :
– Mise en place très rapide
– Permet d’enregistrer beaucoup de scénarios rapidement
• Inconvénients
– Impossible à maintenir
– Pour chaque scénario, on réenregistre tout : aucune factorisation. Le script
est linéaire et déroule la séquence de test
– Les données et les étapes sont mélangées : autant de scripts de test que de
cas de test
20
Intéressant pour une démo, un POC jetable mais on
ne peux l’envisager sérieusement comme une
démarche durable

@crochefolle
Développement
21
Scénario
de test
Développe
Script
de
test
Outil de test
Application
à
tester
testeurs automaticiens
Librairie de
composants
de test
réutilisables
Données
de test
Référentiel
d’objets

@crochefolle
Développement
• Référentiel d’objets : liste partagés par tous les scripts de test permettant de
centraliser l’ensemble des objets qui seront utilisés lors des tests avec les
moyens de les retrouver .
Ex : une page, un champ ou un bouton dans une page
La constitution de ce référentiel est essentielle, c’est qui permettra de maintenir
les scripts de test synchrone avec l’évolution de l’application à tester.
On favorisera donc la reconnaissance des objets par leurs ID plutôt que par leur
position (qui peut être amené à évoluer). On évitera autant que faire ce peut
d’utiliser les coordonnées à l’écran ou la reconnaissance d’image.
• Composant de test : ensemble d’instructions de test réutilisable dans plusieurs
scripts (équivalent des « Shared steps »)
• Script de test : équivalent à un scénario de test, principalement composé
d’appel à des composants de tests
22

@crochefolle
Développement
• Avantages :
– Composants de test réutilisables
– Maintenance facilité :
• Le découpage des composants permet de cibler plus facilement les
modifications
• Peu de modification à faire en cas de modification dans l’application à tester
– Permet d’enrichir facilement le patrimoine de tests en multipliant les cas de test ou
les scénarios de tests une fois que l’on dispose d’un référentiel d’objet et d’une
librairie de composants de test conséquents.
• Inconvénients
– Mise en place plus longue : un investissement initial important est nécessaire pour
mettre en place le framework de test
23
Seule solution viable sur le long terme

@crochefolle
Techniques d’automatisation
On distingue principalement 3 techniques d’automatisation :
1. Data driven
2. Keyword driven
3. DSTL : Domain specific test language
24

@crochefolle
Data driven
• Les données sont externalisées des scripts de test :
– Csv
– Xls
– Xml
– Base de donnée
• Un script exécute de multiples tests basés sur les données en
entrée
– Maintenance faible sur le script
– Facilité d’enrichir les cas de tests en ajoutant un nouveau jeu de
donnée
25

@crochefolle
Data driven : exemple
26
Test de régression basé sur la donnée

@crochefolle
Keyword driven
• Constitution d’un librairie de composants de test basé sur des
mots-clefs :
– S’authentifier
– Mettre au panier
– Ajouter une adresse
• Les scripts de test sont constitués uniquement de l’appel à ces
composants.
• L’automaticien se concentre sur les moyens de test en
enrichissant la librairie de composants.
• Le testeur peut multiplier les scénarios de test en variant les
enchaînements d’appel à ces composants sans avoir besoin de
se préoccuper de la technique utilisée.
27

@crochefolle
Keyword driven : exemple
28
Test de régression Front

@crochefolle
Domain Specific Test Language (DSTL)
• Version plus abstraite que la méthode « Keyword »
• L’ensemble des mots-clefs est prédéfini dans un dictionnaire
• Plus proche du langage courant mais dans un format imposé
• Les testeurs peuvent le rédiger en respectant ce format quelle
que soit l’utilisation future (manuelle ou automatisée)
29

@crochefolle
DSTL: exemple
30
TDD : La syntaxe Gherkin
Gherkin est le Domain Specific Language de SpecFlow. Cette syntaxe, qui contient très peu de
mots clés, se veut compréhensible de tous et est orientée spécification. Ce DSL permet
de spécifier un comportement au travers de 3 mots clés:
Given est l’instruction de définition d’un contexte
When est l’instruction qui présente l’action a tester
Then est l’instruction permettant de valider l’action effectuée.

@crochefolle
Composants techniques pour l’automatisation
31
Dans tous frameworks d’automatisation, il est nécessaire de mettre
en place des composants techniques pour faciliter le
développement :
• Oracle
• Bouchon
• Techniques de comparaison
• Reporting

@crochefolle
Oracle
Un oracle est un mécanisme permettant de décider la réussite
d’un scénario de test, c’est à dire de déterminer si les réponses
obtenues à l’exécution du test correspondent bien à ce que
requiert le scénario.
Dans la plupart des frameworks de test, les oracles sont écrits
sous forme d’assertion.
32

@crochefolle
Les assertions
• Exemples d’assertions
– Assert.AreEqual(…)
– Assert.AreSame(…)
– Assert.IsFalse(…)
– CollectionAssert.AllItemsAreNotNull(…)
– CollectionAssert.AreEqual(…)
– CollectionAssert.Contains(…)
– StringAssert.Contains(…)
– StringAssert.DoesNotMatch()
– …

@crochefolle
Assertions : résultats
 Lors d’un test, 3 situations possibles
Vert  REUSSITE
– La condition vérifiée est exécutable et vraie, p.e.
public void test1() {
assertTrue(sqrt(4) == 2); }
FAILURE
– Condition vérifiée est exécutable mais fausse, p.e.
assertEquals(3, sqrt(4), 0.001); }
ERREUR
– Une expression exécutée lors du test à lancée une erreur ou exception, p.e.
• Division par zéro
assertTrue(2 / 0 == 1); }
Ça marche et ça
fait ce qu’on veut.
Ça ‘marche’ mais ça
ne fait pas ce qu’on veut.
Ça ne ‘marche’ même pas.

@crochefolle
Bouchon
Un bouchon (stub en anglais) est un code qui n'effectue aucun
traitement et retourne toujours le même résultat.
Un bouchon sert d'alternative à un code qui n'est pas utilisable
parce qu'il n'est pas encore codé, qu'il est en cours d'évolution ou
non disponible dans l’environnement courant.
Ex : bouchon de paiement
Dans les frameworks de test, on utilise le concept de Mocking pour
simuler le comportement de « l’extérieur »
35

@crochefolle
Exemples de frameworks
• Liste non exhaustive de framework .NET
– RhinoMock
– TypeMock
– Nmock
– Moq
• Moq (prononcer « Mock You »)
– Est extrêmement simple à aborder
– Est plus récent
– Permet de simuler des classes et des interfaces

@crochefolle
Exemple d’utilisation
• La classe DateManager implémente l’interface
IDateManager
public interface IDateManager
{
DateTime DateTimeNow();
}
public class DateManager:IDateManager
{
public DateTime DateTimeNow () {
return DateTime.Now;
}
}

@crochefolle
Exemple d’utilisation
• Etape 1 : créer le conteneur moq
• Etape 2 : décrire le comportement
• Etape 3 : utiliser l’objet généré
var mock = new Mock<IDateManager>();
mock.Setup(p => p.DateTimeNow())
.Returns(new DateTime(2000, 01, 01));
IDateManager testemoi = mock.Object;
Assert.AreEqual(testemoi.DateTimeNow().Year, 2013);

@crochefolle
Techniques de comparaison
39
La comparaison du résultat obtenu au résultat
attendu est un point crucial du test automatisé.
Il est important de faire attention à ce point et de :
• garder le plus simple possible,
• bien documenter ,
• éviter la comparaison d’images
Une technique de comparaison défaillante peut
rendre inutilisable les résultats de tests et mettre en
cause une politique d’automatisation.
Attention aux faux-positifs

@crochefolle
2 types de comparaison
40
Comparaison dynamique
• Effectuée pendant l’exécution
du test
• Exécutée par l’outil de test (les
assertions)
• Peut donner un suivi en direct
de l’avancée des tests
• Les informations d’échecs sont
enregistrés permettant l’analyse
postérieure
Comparaison post-exécution
• Effectuée après l’exécution du
test
• Très utilisés pour la
comparaison en masse de
donnée dans des fichiers ou
des bases
• Peut être exécuté
indépendamment de l’exécution
du test
• Peut avoir différents niveaux de
comparaisons (en détaillé sur
les points avec différences, en
surface pour les autres)

@crochefolle
Comparaison post-exécution
41
• Très peu d’outils pour la comparaison en masse post-exécution.
• Quelques-uns existent autour de la comparaison de fichiers sont
disponibles :
– Diff (Unix/Linux)
– winmerge, windiff (Windows)
• On utilise plutôt des outils de manipulations de texte :
– Sed, awk, grep, Perl, Tcl, Python
• Important de mettre en place de la reconnaissance de pattern
plutôt que de la comparaison stricte

@crochefolle
Reporting
42
Dernier composant important d’un framework de test, le reporting est
un point essentiel pour que l’automate de test soit utilisables par les
testeurs :
• Il doit être de plusieurs niveaux :
– Vue globale des résultats
– Vue détaillée pour les étapes en
échec ou en erreur.
• Intégré à l’outil de test mais consultable par tous sans avoir besoin
d’installer l’outil en question.
• Pouvoir être généré partiellement (notamment en cas d’erreurs et
d’interruptions des tests)

@crochefolle
Statuts de test
Les statuts de tests ne sont pas seulement : Pass/Fail
Voire plus spécifique :
• Partenaire
• Problèmes d’environnement (réseau indisponible, dns, time-out)
• Fichiers manquants
• Test obsolète par rapport au dev
A comparer à Pas de
différence
Des différences
trouvées
Résultat attendu Pass Fail
Erreur attendue Expected Fail Unknown
Pas d’information Unknown Unknown

@crochefolle
Exemple de reporting test unitaire

@crochefolle
Exemple de reporting test fonctionnel

@crochefolle
Mike Cohn Testing Pyramid
En résumé
Comment automatiser les tests ?
1. Les différents types de tests automatisés : le bon test au bon moment
2. Méthodes d’automatisation : Projet de développement
3. Techniques d’automatisation
1. Data driven : NRA Compta
2. Keyword driven : NRA Front
3. DSTL : TDD
4. Composants techniques pour un framework d’automatisation
1. Oracle : les assertions
2. Bouchon : mock
3. Techniques de comparaison : Attention aux faux-positifs
4. Reporting

@crochefolle
Pour aller plus loin
http://www.dorothygraham.co.uk/
Librement inspiré du travail de Dorothy Graham
Spécialiste reconnue dans le domaine du test, elle a
contribué à la définition du syllabus ISTQB et notamment
sur l’automatisation des tests.

Automatisation des tests - objectifs et concepts - partie 2

Contenu connexe

Tendances

Similaire à Automatisation des tests - objectifs et concepts - partie 2

Plus de Christophe Rochefolle

Automatisation des tests - objectifs et concepts - partie 2