OTT Outillage Des Tests Cours 1 1

Introduction au test logiciel
Fabrice Ambert, Fabrice Bouquet

[email protected]
Orsay
1
16-18 novembre 2016
Automatisation des tests
logiciels
•  Résumé:
•  appréhender les méthodes et outils pour automatiser les tests logiciels (tests unitaires, fonctionnels,
d'intégration, de charge) afin de gagner en productivité et en sureté pour le développement logiciel
•  Durée:
•  4 jours
•  Pré-requis:
•  connaissances de base en test logiciel et capacité à effectuer des développements logiciels objet
2
Bienvenue
Faisons connaissance
•  Votre formateur
•  Pour chaque participant

•  Vos activités actuelles ?
•  Votre expérience ?
o  Sur des projets de développement de logiciels et systèmes
d’information
o  Sur les activités de test (Rôles, Outils utilisés)
•  Vos attentes pour cette formation ?
3
Contenu de la formation
Programme standard
Introduction, rappels sur le processus du test
Automatisation de la gestion des tests
Automatisation des tests unitaires
Automatisation des tests d'intégration
Automatisation du test fonctionnel
Automatisation des tests système
Synthèse
4
Déroulement de la formation (3 jours)
Alternance de Cours et de Pratique
Cours Thèmes Durée Exercices Outils Durée
1. Introduction, rappels sur le Types, Niveaux, J1,

processus du test logiciel Méthodes 9h-11h
2. Automatisation des tests Couverture de J1, Intégrés au cours Junit, mockito, J1

unitaires Code 11h30- Cahier coverTools 13h30-17h
12h30 d’exercices J2 9h-11h
3. Automatisation des tests Stratégie, J2, Cahier Maven, Jenkins, J2,
d'intégration Intégration 11h30- d’exercices SOnarQube 13h30-16h
continue 12h30
4. Test fonctionnel et son Partitions, Limites, J2, Intégrés au cours Concordion 9h-10h30
automatisation Combinatoire 16h-17h Selenium, HTMLUNit 11h-12h30
5. Automatisation de la gestion Conception, J3, Cahier Squash TM / TA J3,

des tests exécution, suivi 13h30- d’exercices 14h30-…
14h30
5
1. Introduction, rappels
sur le processus du test
logiciel
Rôle du test dans le processus de développement.
Les tests : unitaires, fonctionnels, etc.
Les différentes méthodes de test.
Processus de test et stratégie de test.
Outils et méthodes intervenant à différentes étapes
6
Rôle du test dans le processus de
développement
Les bugs sont nombreux et couteux pour la société
possédant le logiciel, ses fournisseurs, ses clients, les
utilisateurs finaux…
7
Les failles de sécurité sont également
nombreuses
Problèmes de sécurité (Figaro 21/09/16)
8
Les DSI ont des objectifs directement liés
au test
Source: « World Quality Report 2016-2017, Sogeti »
44% 42%
65% 42%
Augmenter la Améliorer
Améliorer la Optimiser les
Qualité des l’Expérience
sécurité coûts
Solutions Utilisateur
9
Le Test continue a être un investissement
nécessaire et important
Une place très importante dans l’IT
Source: PAC 2016, Arnold Aumasson
10
Définitions du test
•  « Le test est l’exécution ou l’évaluation d’un système ou d’un
composant par des moyens automatiques ou manuels, pour
vérifier qu’il répond à ses spécifications ou identifier les
différences entre les résultats attendus et les résultats obtenus.
»
IEEE (Standard Glossary of Software Engineering Terminology)‫‏‬
•  « Tester, c’est exécuter le programme dans l’intention d’y trouver

des anomalies ou des défauts. »
G. Myers (The Art of Software testing)‫‏‬
•  «Testing can reveal the presence of errors but never their

absence.» Edsgar W. Dijkstra (Notes on Structured
Programming)‫‏‬
11
La réalité du test
•  Le test constitue aujourd’hui le vecteur principal de l’amélioration
de la qualité du logiciel
•  Actuellement, le test dynamique est la méthode la plus diffusée

•  Il peut représenter jusqu’à 60 % de l’effort complet de
développement d’un logiciel
•  Coût moyen de l'activité de test :

•  1/3 durant le développement du logiciel
•  2/3 durant la maintenance du logiciel
12
Industrialiser et professionnaliser le test
logiciel avec des compétences spécifiques
Un schéma mondial de Formations et Certifications en Test
Logiciel
•  ISTQB: International Software Testing Qualifications Board

•  www.istqb.org
•  Un parcours de formations reconnu dans le monde entier
•  Près de 500 000 certificats délivrés dans le monde
13
Industrialiser et professionnaliser le test
logiciel avec des compétences spécifiques
Une implantation en France très importante
•  CFTL: Comité Français des Tests Logiciels

•  www.cftl.fr
•  Déploiement en France
o  Des certifications ISTQB
o  De certifications connexes au test
•  Près de 10000 certificats délivrés en France
14
Motivations du test
•  Complexité croissante des architectures et des comportements
•  Coût d’un bug (Ariane 5, carte à puces allemande bloquée, prime de la PAC…)‫ ‏‬

Erreur
SpécificaEon, concepEon, programmaEon

Défaut dans le logiciel

Anomalie de fonc-onnement

•  Coût des bugs informaEques : ≈ 60 milliards $ / an

•  22 milliards économisés si les procédures de test de logiciels étaient améliorées.
(source : NIST - Na0onal Ins0tute of Standards and Technology)‫‏‬
15
Les tests : unitaires, fonctionnels, etc.
•  V & V
–  ValidaEon : Est-ce que le logiciel offre les services aTendues ?
–  VérificaEon : Est-ce que les artefacts uElisés sont corrects ?
•  Méthodes de V & V
–  Test staEque : Revue de code, de spécificaEons, de documents de
design
–  Test dynamique : Exécuter le code pour s’assurer d’un
foncEonnement correct
–  VérificaEon symbolique : Run-Eme checking, ExecuEon symbolique,
…
–  VérificaEon formelle : Preuve ou model-checking d’un modèle
formel
16
Les tests : unitaires, fonctionnels, etc
La pratique du test
•  Le test appartient à l’activité de Validation du logiciel :

est-ce-que le logiciel fait les choses bien et les bonnes choses ?
•  Activité historiquement peu populaire en entreprise
•  Difficultés d’ordre psychologique ou « culturel » :

•  L’activité de programmation est un processus constructif : on
cherche à établir des résultats corrects
•  Le test est un processus destructif : un bon test est un test
qui trouve une erreur
17
Les différentes méthodes de test
Test statique
Traite le code du logiciel sans l’exécuter sur des données réelles.
Test dynamique
Repose sur l’exécution effective du logiciel pour un sous

ensemble bien choisi du domaine de ses entrées possibles.
18
Test statique
Définitions
Compilateur
•  Outil logiciel qui traduit un programme exprimé dans un langage de
haut niveau dans son équivalent en langage machine [IEEE 610]
Complexité
•  Degré par lequel un composant ou système a une conception et/ou
une structure interne difficile à comprendre, maintenir et vérifier
19
Test statique
L’analyse statique trouve des défauts (et non des défaillances)
•  Le code n’est pas exécuté mais des outils peuvent être utilisés
par des profils développeur
•  La compilation peut être considérée comme du test statique
outillé
•  Des défauts difficiles à trouver avec des tests dynamiques
peuvent être détectés
•  Dépendance dans des modèles
•  Violation de règles de sécurité et programmation
•  Maintenabilité difficile
•  Code mort
•  Variable jamais utilisée
•  Boucles infinies
20
Test statique
Exemples :
•  Lectures croisées / inspections
Vérification collégiale d’un document (programme ou spécification
du logiciel)‫‏‬
•  Analyse d’anomalies
Corriger de manière statique les erreurs (typage impropre, code
mort, …)‫‏‬
Avantages :
•  Méthodes efficaces et peu coûteuses
•  60% à 95% des erreurs sont détectées lors de contrôles statiques
Inconvénients :
•  Ne permet pas de valider le comportement d’un programme au
cours de son exécution
à Les méthodes de test statiques sont nécessaires, mais pas

suffisantes
21
Test statique
Exemple de rapport Sonar
22
Test statique
Exemple d’analyse de code outillée
23
Test statique
Exemple d’analyse de code outillée
24
Test dynamique - niveaux
Repose sur l’exécution du programme à tester
•  4 niveaux
complémentaires
•  Test de composants
(unitaire)
•  Test d’intégration des
composants
•  Test du système
global
•  Test d’acceptation
(recette)
25
Test dynamique - techniques
Deux techniques :
•  Test structurel
Jeu de test sélectionné en s’appuyant sur une analyse du code
source du logiciel (test boite blanche / boite de verre)‫‏‬
•  Test fonctionnel
Jeu de test sélectionné en s’appuyant sur les spécifications (test
boite noire)‫‏‬
En résumé, les méthodes de test dynamique consistent à :

•  Exécuter le programme sur un ensemble fini de données d’entrées
•  Contrôler la correction des valeurs de sortie en fonction de ce qui
est attendu
26
Test structurel (white box)
•  Les données de test sont produites

A
à partir d’une analyse du code source
Critères de test : ≤ 20 fois

•  tous les chemins,
•  toutes les instructions,
•  etc…
B
Fig. 1 : Flot de contrôle d’un petit programme
27
Test fonctionnel (black-box)‫‏‬
•  Test de conformité par rapport à la spécification
Spécification
Données de test
Oracle Programme
Résultats
de test Résultats d’exécution
28
Complémentarité (1) test fonctionnel /
structurel‫‏‬
•  Les 2 approches sont utilisées de façon complémentaire
•  Exemple : soit le programme suivant, censé calculer la somme de 2 entiers :

function sum (x,y : integer) : integer;
if (x = 600) and (y = 500)
then
sum := x-y
else
sum := x+y;
end
•  Une approche fonctionnelle détectera difficilement le défaut, alors qu’une

approche par analyse de code pourra produire la donnée de test :
x = 600, y = 500.
29
Complémentarité (2) test fonctionnel /
structurel‫‏‬
•  En examinant ce qui a été réalisé, on ne prend pas forcément en

compte ce qui aurait du être fait :
•  Les approches structurelles détectent plus facilement les
erreurs commises dans le programme
•  Les approches fonctionnelles détectent plus facilement les
erreurs d’omission et de spécification
•  Une difficulté du test structurel consiste dans la définition de

l’oracle de test.
30
Test de logiciels – auto-évaluation
L’exemple du triangle
•  Soit la spécification suivante :
Un programme prend en entrée trois entiers. Ces trois entiers sont

interprétés comme représentant les longueurs des cotés d’un
triangle. Le programme rend un résultat précisant s’il s’agit d’un
triangle scalène, isocèle ou équilatéral (ou une erreur si les données
ne correspondent pas aux longueurs d’un triangle).
G. Myers (The Art of Software testing - 1979)‫‏‬
•  Donnez un ensemble de cas de test que vous pensez adéquat pour

tester pour ce programme…
31
•  Avez-vous un cas de test pour :
1.  Cas scalène valide (1,2,3 et 2,5,10 ne sont pas valides)‫‏‬
2.  Cas équilatéral valide
3.  Cas isocèle valide (2,2,4 n’est pas valide)‫‏‬
4.  Cas isocèle valide avec les trois permutations (e.g. 3,3,4; 3,4,3; 4,3,3)‫‏‬
5.  Cas avec une valeur à 0
6.  Cas avec une valeur négative
7.  Cas où la somme de deux entrées est égale à la troisième entrée
8.  Trois cas pour le test 7 avec les trois permutations
9.  Cas où la somme de deux entrées est inférieure à la troisième entrée
10.  Trois cas pour le test 9 avec les trois permutations
11.  Cas avec les trois entrées à 0
12.  Cas avec une entrée non entière
13.  Cas avec un nombre erroné de valeurs (e.g. 2 entrées, ou 4)‫‏‬
14.  Pour chaque cas de test, avez-vous défini le résultat attendu ?
32
•  Chacun de ces cas correspond à un défaut constaté

dans des implantations de cet exemple du triangle
•  La moyenne des résultats obtenus par un ensemble de

développeurs expérimentés est de 7.8 sur 14.
=> Le test est une activité complexe, a fortiori sur de

grandes applications
33
Test dynamique – 4 activités
Sélection d’un jeu de tests : choisir un sous-ensemble des

entrées possibles du logiciel
Soumission du jeu de tests
Dépouillement des résultats : consiste à décider du succès ou

de l’échec du jeu de test (verdict): Fail, Pass, Inconclusive
Évaluation de la qualité et de la pertinence des tests effectués

(déterminant pour la décision d’arrêt de la phase de test)
34
Types de tests (1)
(renseignent la nature du test mené)
Tests fonctionnels
Valide les résultats rendus par les services
Tests non-fonctionnels
Valide la manière dont les services sont rendus
Tests nominaux / de bon fonctionnement

Vérifie que le résultat calculé est le résultat attendu, en entrant des
données valides au programme (test-to-pass)
Tests de robustesse
Vérifie que le programme réagit correctement à une utilisation non
conforme, en entrant des données invalides (test-to-fail)‫‏‬
35
Types de tests (2)
(renseignent la nature du test mené)
Test de performance
•  Load testing (test avec montée en charge)‫‏‬
•  Stress testing (soumis à des demandes de ressources
anormales)‫‏‬
Test de non-régression
Vérifie que les corrections ou évolutions dans le code n’ont pas
créé d’anomalies nouvelles
Test de confirmation
Valide la correction d’un défaut
36
Catégories de tests
Niveau de détail (situation dans le cycle de vie)‫‏‬
système
integration
module
unitaire
Techniques
(comment on teste)
fonctionnel
non fonctionnel white box black box
performance
ergonomie
robustesse
sécurité
type (ce que l’on veut tester)‫‏‬
37
Processus de test et stratégie de test
Le Test est un ensemble d’activités à dérouler à différents niveaux
Planification
Composant 1
Planification
Analyse et Intégration
Contrôle
Conception
Contrôle
Implémentation et
Exécution
Système
Evaluation &
Reporting
Clôture
Acceptation
Clôture
38
Développement et niveaux de tests
39
Niveaux de tests
(renseignent l’objet du test)‫‏‬
Tests (structurels) unitaires
Test de procédures, de modules, de composants
(coût : 50% du coût total du développement initial correspondant
Tests d’intégration
Test de bon comportement lors de la composition des procédures,
modules ou composants
(coût d’un bug dans cette phase : 10 fois celui d’un bug unitaire)‫‏‬
Tests système / de recette

Validation de l’adéquation aux spécifications
(coût d’un bug dans cette phase : 100 fois celui d’un bug unitaire)‫‏‬
40
Processus de test et stratégie de test
Test et cycle de vie du processus de test
41
Difficultés du test
•  Le test exhaustif est en général impossible à réaliser
•  En test structurel, le parcours du graphe de flot de contrôle conduit
à une forte explosion combinatoire
Exemple : le nombre de chemin logique dans le graphe de la figure
1 est supérieur à 1014 ≈ 520 + 519 + … + 51
•  En test fonctionnel, l’ensemble des données d’entrée est en général

infini ou très grande taille
Exemple : un logiciel avec 5 entrées analogiques sur 8 bits admet
240 valeurs différentes en entrée
=> le test est une méthode de validation partielle de logiciels

=> la qualité du test dépend de la pertinence du choix des données de
test
42
Coût d’un bug
Le but est de les détecter le plus tôt possible (Stratégie)
43
Stratégie de test
En début de projet, définition d’un Plan de Test et de Validation
(PTV)‫‏‬
Objectifs de test
Plan de
Test
et de Techniques de test
Validation
PTV Phases et planning
44
Acteurs du test
•  Deux situations :
-  Je teste un programme que j’ai écrit
-  Je teste un programme que quelqu’un d’autre a écrit
•  Trois questions :
-  Comment choisir la technique de test ?
=> boite blanche ou boite noire ?
-  Comment obtenir le résultat attendu ?
=> problème de l’oracle du test
-  Comment savoir quand arrêter la phase de test ?
=> problème de l’arrêt‫‏‬
45
Outils et Méthodes intervenants à
différentes étapes
Automatique & Choix métier

Manuel
Manuel
Tests Fonctionnels Tests Exploratoires

Exemples Scénarios
Tests de “story” Tests de utisabilité
Support de l’équipe
Prototypes Test d'acceptance
Critique du Produit
Simulations Alpha / Bêta
Q2 Q3
Q1 Q4
Tests Unitaires Tests de charge

Tests de composants Tests de performance
“ilité” tests
Automatique Outils
Choix technologique
46
Exemple Mingle pour les projets Agile
47
Build et Distribution: Utile pour tout le quadrant de test
Manuel
Manuel

Exemples Scénarios
Tests de “story” Tests de utilisabilité
Critique du Produit
Simulations Intégration continue Alpha / Bêta
Q2 Q3
Q1 Q4

“ilité” tests
Automatique Outils
Choix technologique
48
Intégration continue : Tableau de contrôle
Permet d’avoir en temps réel

le statut du projet (tests
unitaires, tests statiques,
couverture…)
49
Outils et Méthodes intervenants à différentes
étapes
Tests unitaires
Manuel
Manuel

Exemples Scénarios
Critique du Produit
Q2 Q3
Q1 Q4
Vrais tests Unitaires
“ilité” tests
Spock
Automatique Outils
Choix technologique
50
étapes
Tests statiques !
Manuel
Manuel

Exemples Scénarios
Critique du Produit
Q2 Q3
Q1 Q4

Tests
Tests Statiques
de composants Tests de performance
“ilité” tests
Automatique Outils
Choix technologique
51
Automatisation des tests
Manuel
Manuel

Exemples Scénarios
Automatisation = Dév !
Critique du Produit
Spock Q2 Q3
Q1 Q4

“ilité” tests
Automatique Outils
Choix technologique
52
Gestion des tests y compris exploratoires !
Manuel
Manuel
Tests Fonctionnels Testsmanuels

Gérer les tests Exploratoires
Exemples Scénarios
Critique du Produit
Q2 Q3
Q1 Q4

“ilité” tests
Automatique Outils
Choix technologique
53
Virtualisation et Cloud : un nouveau défit !
Manuel
Manuel

Exemples Scénarios
Critique du Produit
Q2 Q3
Q1 Itération
Q4 ⇒ Service Virtualization

“ilité” tests
Automatique Outils
Choix technologique
54
Couverture : un métrique important
Manuel
Manuel

Analyse de la couverture Exemples Scénarios
Critique du Produit
Cobertura Q2 Q3
Q1 Q4

“ilité” tests
Automatique Outils
Choix technologique
55
étapes
BDD avec JBehave
56
étapes
Tester avec FitNesse
•  FitNesse utilise un wiki pour définir les cas de tests : on écrit des tables de
décision. FitNesse est bien adapté à des testeurs fonctionnels
•  Le développeur doit écrire le “fixture” code pour appeler les fonctionnalités
concernées import fit.ColumnFixture;
public class AddRemovePlayerFixture {

private String playerName;
private Game theGame;
eg.triviaGameExample.fitnesseFixtures.AddRemovePlayerFixture public void setPlayerName(String playerName) {

playerName addPlayer? countPlayers? this.playerName = playerName;
}
Al true 1
Bertha true 2 public boolean addPlayer() {
theGame = StaticGame.theGame;
Player thePlayer = theGame.addPlayer(playerName);
return theGame.playerIsPlaying(thePlayer);
}
public int countPlayers() {

return theGame.getNumberOfPlayers();
}
}
57
Exemple: tests unitaires avec Junit depuis Eclipse
58
Exemple: qualité du code mesurée avec Sonar
59
2. Automatisation des
tests unitaires
Organisation et bonnes pratiques pour les tests unitaires.
Critères d'automatisation.
Tests unitaires : Tests Driven Development.
Mesure de la couverture de code : couverture d'instructions et branches.
Analyse statique de code : analyse outillée du code source hors exécution
Automatisation avec un fichier de configuration.
Analyse dynamique de code : couverture des instructions, des branches, des prédicats...
Organisation des tests unitaires, pair programming, pair testing.
Utilisation des Frameworks : gestion des scripts de tests
60
Test unitaire
Quoi ? Qui ?
•  Validation du fonctionnement •  Le développeur

d’une portion d’un
programme
Comment ?
Quand ?
•  Package disponibles dans de
nombreux langages
•  Dans un cycle en V : après la •  Java : Junit, TestNG
phase de développement •  PHP : PHPUnit, SimpleTest,
•  Dans un cycle agile : intégré atoum
au développement (TDD)
61
Test structurel
•  Le test structurel s’appuie sur l’analyse du code source de

l’application pour établir les tests en fonction de critères de
couverture
ð Basés sur le graphe de contrôle (toutes les instructions, toutes

les branches, tous les chemins, …)‫‏‬
ð Basés sur la couverture du flot de données (toutes les définitions
de variables, toutes les utilisations, …)‫‏‬
62
Graphe de contrôle
Définition
•  Permet de représenter n’importe quel algorithme
•  Les nœuds représentent des blocs d’instructions

instruction ou suite d’instructions insécables
instruction de contrôle
•  Les arcs représentent la possibilité de transfert de l’exécution

d’un nœud à un autre
•  Une seule entrée (nœud à partir duquel on peut visiter tous les
autres) et une seule sortie
63
Graphe de contrôle
Production
i := 1; i:=1
found := false; a found:=false
while (not found) do
begin
if (a[i] = E) then b found
begin not found f
found := true;
s := i; c
end;
a[i] = E
i := i + 1;
found:=true
end; a[i] ≠ E d s := i
e i=i+1
64
Graphe de contrôle
Exercice
Produire le graphe de contrôle de la fonction :
public static Coordinates nextForwardPosition(Coordinates position, Direction direction) {

if (direction == NORTH)
return new Coordinates(position.getX(), position.getY() - 1);
if (direction == SOUTH)
return new Coordinates(position.getX(), position.getY() + 1);
if (direction == EAST)
return new Coordinates(position.getX() + 1, position.getY());
return new Coordinates(position.getX() - 1, position.getY());
}
65
Graphe de contrôle
Exercice - correction
a
direction == NORTH
return new Coordinates(position.getX(), position.getY() - 1) b c

direction == SOUTH
return new Coordinates(position.getX(), position.getY() + 1) d e

direction == EAST
return new Coordinates(position.getX() + 1, position.getY()); f

g
Coordinates(position.getX() –
public static Coordinates nextForwardPosition(Coordinates position, Direction direction) {
if (direction == NORTH)
return new Coordinates(position.getX(), position.getY() - 1);
1, position.getY())
if (direction == SOUTH)
return new Coordinates(position.getX(), position.getY() + 1); h
return new
if (direction == EAST)
return new Coordinates(position.getX() + 1, position.getY());
return new Coordinates(position.getX() - 1, position.getY());
}
66
Chemins de contrôles
x≤0 a x >0
Définition
b x := abs(x)+4 c
•  Chemin dans le graphe de x := 2x-15
contrôle
•  Débute au nœud d’entrée du
d
x = -1 x ≠ -1
graphe
•  Termine au nœud de sortie e f
du graphe
g
•  Peut être activable ou non
•  4 chemins de contrôles
abdeg : un chemin de contrôle •  abdeg
bdfg : non •  abdfg
•  acdeg
•  acdfg
67
Couverture structurelle
Couverture du graphe de flot de contrôle
Considérer les
Produire des
chemins de
données d’entrée Exécuter le
contrôle (tous ou Établir les oracles
permettant programme dans
certains en associés
d’activer ces ces configurations
fonction du critère
chemins
de couverture)
68
Critères de couverture structurelle
Basés sur le graphe de contrôle
Couverture de tous-les-nœuds,
Couverture de tous-les-arcs,
Couverture des chemins limites et intérieurs
Couverture de tous les i-chemins,
Couverture de tous les chemins indépendants
Couverture de tous les chemins
69
Couverture de tous-les-nœuds
Couverture de toutes les instructions
•  Chaque nœud (chaque bloc d’instructions) est atteint par au

moins l’un des chemins parmi les chemins qui constituent le jeu
de test
•  Lorsqu’un jeu de test permet de couvrir tous les nœuds du

graphe, on dit qu’il satisfait TER=1 ou TER1 (Test Effectiveness
Ratio 1)‫‏‬
nb de nœuds couverts
nb total de nœuds
TER = 1 <=> le critère tous-les-nœuds est satisfait

<=> tous les nœuds du graphe de contrôle sont couverts
<=> toutes les instructions ont été exécutées
70
Tous-les-nœuds
Cas favorable
function sum (x,y : integer) : integer;

begin
if (x = 0) then a
x≠0 x=0
sum := x ;
else
sum := x + y ;
sum := x + y; b c sum := x;
end ;
d
⇒ L ’erreur est détectée par l’exécution du chemin [acd]
71
Tous-les-nœuds
Limite du critère a read(x);
Soit le programme suivant (avec erreur) :

b
read (x) ; x≠0
if (x ≠ 0) then
x := 1; c x=0
x := 1;
y := 1/x;
d y := 1/x;
⇒ Le critère tous-les-nœuds est satisfait par le chemin [abcd]

sans que l’erreur ne soit détectée.
L’unique donnée de test {x = 1} permet de couvrir tous les nœuds
du graphe sans faire apparaître l’anomalie.
72
Couverture de tous-les-arcs
Couverture des branches
•  Chaque arc est couvert par au moins l’un des chemins parmi les
chemins qui constituent le jeu de test
•  La valeur de vérité de chaque nœud de décision a été au moins
une fois vraie et une fois fausse
•  Lorsqu’un jeu de test permet de couvrir tous les arcs du graphe,

on dit qu’il satisfait TER=2 ou TER2 (Test Effectiveness Ratio 2)‫‏‬
nb d’arcs couverts
nb total d’arcs
TER = 2 <=> le critère tous-les-arcs est satisfait
<=> tous les arcs du graphe de contrôle ont été couverts
<=> toutes les décisions ont été exécutées
73
Couverture des Conditions / Decisions
A B A B
DC C/DC
A B A B
FPC MCC
Décision (A ∨ B) :
Ø Couverture des Décisions à A ∨ B
Ø Couverture des Conditions dans les Décisions à A , B
Ø Couverture des Conditions Exclusives à A ∧ ¬B , ¬ A ∧ B
Ø Couverture des Conditions Multiples à A ∧ B , A ∧ ¬ B , ¬ A ∧ B
74
Tous-les-arcs
Limite du critère
Pas de détection d’erreurs en cas de non-exécution d’une boucle

read (inf, sup);
⇒ tous-les-arcs est satisfait par le chemin [abcbd] a i := inf;
sum := 0;
⇒  La donnée de test suivante couvre le critère
tous-les-arcs :
i > sup
DT1= {a[1]=50, a[2]=60, a[3]=80, inf=1,sup=3} b d
writeln (1/sum)‫‏‬
⇒  Problème non détecté par le critère tous-les- i <= sup
arcs : si inf > sup, erreur sur 1/sum
c
sum := sum + a[i];
i := i + 1;
75
Couverture des boucles
Chemins limites et intérieurs
•  Chemins limites : traversent la boucle, mais ne l’itèrent pas
•  Chemins intérieurs : itèrent la boucle une seule fois
a a
Chemin limite : [abc]
chemin intérieur : [ababc]
b b
chemin limite : [abd]

c chemin intérieur : [abcbd] d c
76
Couverture de tous les i-chemins
Généralise couverture chemins limites et intérieurs
•  Couverture de tous les chemins possibles passant de 0 à i fois

dans chaque boucle du graphe de contrôle
•  La couverture de tous les i-chemins (pour i > 0) garantit les
critères TER1, TER2 et le critère de couverture des chemins
limites et intérieurs
a
Le jeu de tests constitué de données de
test permettant de couvrir les chemins
b [abc], [ababc] et [abababc] satisfait le
critère tous les 2-chemins.
c
77
indépendants
•  Déterminer un ensemble de •  Le nombre de chemins

chemins représentatif de nécessaire est donné par la
tous les comportements complexité cyclomatique du
•  Construire une base de graphe (Mc Cabe)
chemins qui par combinaison
linéaire donne tous les
chemins nombre de conditions
ν(G) = +1
élémentaires
•  Considérer les vecteurs des
chemins par rapport aux arcs
78
Chemins indépendants
Conditions élémentaires
a x≥0
a x ≥ 0 && x ≤ 9 true
false
true false
e x≤9
b c true false
b c
d
d
2 conditions élémentaires
3 chemins linéairement indépendants
79
Algorithme
1.  Evaluer V(G)

2.  Choisir un chemin dans le graphe en privilégiant dans l’ordre : les
chemins extérieurs, puis les chemins intérieurs, puis les 2-chemins…
dans les boucles
3.  Produire une donnée de test couvrant le chemin choisi. En cas
d’impossibilité, reprendre à l’étape 2 en affaiblissant le critère
4.  Choisir un chemin couvrant au moins un arc non encore couvert par
les données de test précédemment choisies, tout en essayant d’en
couvrir le moins possible (les stratégies utilisées à l’étape 1 restent
valides)
5.  Produire une donnée de test couvrant le chemin choisi à l’étape 4. En
cas d’impossibilité, rejeter le chemin choisi et reprendre l’étape 4 pour
choisir un autre chemin
…
80
Algorithme
6.  Vérifier l’indépendance du chemin calculé par rapport aux autres

chemins déjà calculés (2 chemins sont indépendants ssi il existe un
arc qui est couvert par l’un et pas par l’autre)
7.  Recommencer les étapes 4 à 6 jusqu’à la couverture de toutes les
décisions
8.  S’il n’y a plus de décisions à étudier, que le nombre de chemins
trouvés est inférieur à V(G) et que lors des étapes 3 et/ou 5 des
chemins ont été rejetés, il est probable que la combinaison des
décisions dans le code rendent la couverture inatteignable en l’état.
Il faut alors envisager une reprise du code.
81
•  En posant i=n (avec n le nombre maximal d’itérations possibles)

pour le critère tous les i-chemins revient à exécuter tous les
chemins possibles du graphe de contrôle
=> Critère tous-les-chemins
•  En pratique, ce critère est rarement envisageable sur des

applications même modestes (explosion du nombre de données
de test nécessaires)‫‏‬
82
Hiérarchie des critères basés sur le graphe
de contrôle
tous-les-chemins
tous-les-i-chemins tous-les-chemins-indépendants
tous-les-arcs
(TER2)
tous-les-nœuds
est plus fort que
(TER1)
Exercices
83
Le flot de données
•  Le flot de données est représenté en annotant le graphe de contrôle par certaines
informations sur les manipulations de variables par le programme :
•  Définition de variables : la valeur de la variable est modifiée

Exemple : membre gauche d’une affectation, paramètre d’une instruction de
lecture…
•  Utilisation de variables : accès à la valeur de la variable

Exemple : membre droit d’une affectation, paramètre d’une instruction
d’écriture, indice de tableau, utilisée dans une condition dans une instruction
conditionnelle, dans une boucle…
•  Si une variable utilisée l’est dans le prédicat d’une instruction de décision (if,
while, etc…), il s’agit d’une p-utilisation
•  Dans les autres cas (par exemple dans un calcul), il s’agit d ’une c-utilisation.
84
Définition et utilisation de variables
open (fichier1) ;
read (x,fichier1) ; Bloc 1
1 def(x), def(y), def(z)‫‏‬
read (y,fichier1) ; Définitions : x, y, z
Utilisations : aucune
z := 0 ;
----------------------------- util(x), util(y)‫‏‬
Bloc 2
while x ≥ y do Définitions : aucune 2
----------------------------- Utilisations : x, y
begin x≥y
x := x-y ; Bloc 3 x<y
z := z+1 ; Définitions : x, z 3
def(x), def(z),
end Utilisations : x, y, z
util(x), util(y), util(z)‫‏‬
-----------------------------
open (fichier2) ;
print (y,fichier2) ; Bloc 4 4 util(y)‫‏‬
close (fichier1) ; Définitions : aucune
Utilisations : y
close (fichier2) ;
85
Critères de couverture sur le flot de
données
Toutes les définitions
Toutes les utilisations
Tous les DU-chemins
86
Couverture de toutes les définitions
Pour chaque définition, il existe au moins un chemin qui
la couvre dans un test
x pair
1 read (x, y);
def(x), def(y)
use(x), use(y)
def(x) 2 x impair
Couverture du critère x := y+x/2
toutes-les-définitions :
3 use(x)
- [1,2,3,5,6]
x≥0 x<0
writeln (y); 4 5 writeln (y+2)‫‏‬

use(y) use(y)
87
Couverture de toutes les utilisations
Pour chaque définition et pour chaque utilisation
accessible à partir de cette définition, couverture d’un
chemin de la définition à l’utilisation
x pair
1 read (x, y);
def(x), def(y)
Couverture du critère use(x), use(y)
toutes-les-utilisations : def(x) 2 x impair
- [1,3,4,6] x := y+x/2
- [1,2,3,4,6] use(x)
- [1,3,5,6] 3
x≥0 x<0
- [1,2,3,5,6]
writeln (y); 4 5 writeln (y+2)‫‏‬
use(y) use(y)
6
88
Limite du critère toutes-les-utilisations
read (x);
1 def(x) Couverture du critère
toutes-les-utilisations :
2 use(x) - [1,2,3,5,6,8]
x<0 x≥0 - [1,2,4,5,7,8]
y := 1; 3 4 y := 2;
def(y) def(y) Ces deux tests ne couvrent pas
x pair
5 use(x) tous les chemins d’utilisation :
x impair (8) peut être utilisatrice
z := 1; 6 7 z := 3; de (3) pour la variable y et
def(z) def(z) de (7) pour la variable z
8
code := y+z; def (code) => critère tous-les-DU-chemins
writeln(code); use(y), use(z), use(code)
89
Couverture de tous les DU chemins
Couvrir tous les chemins possibles entre la définition et
la référence, en se limitant aux chemins sans cycle.
1 read (x);
def(x)
x<0
2 use(x)
x≥0
Couverture du critère
y := 1; 3 4 y := 2; tous les DU chemins :
def(y) def(y) - [1,2,3,5,6,8]
x pair
5 use(x) - [1,2,4,5,7,8]
x impair - [1,2,3,5,7,8]
z := 1; 6 7 z := 3; - [1,2,4,5,6,8]
def(z) def(z)
8
code := y+z; def (code)
writeln(code); use(y), use(z), use(code)
90
Hiérarchie des critères basés
sur le flot de données
tous-les-chemins
tous-les-du-chemins est plus fort que
toutes-les-utilisations
toutes-les-c-utilisations toutes-les-p-utilisations
toutes-les-définitions tous-les-arcs
tous-les-nœuds
91
TDD: Test Driven Development
Une autre vision des tests
•  Préconisé par les méthodes

ajout 1 test agiles
exécution
•  Écrire le test avant le code
•  Le test spécifie un comportement

refactoring codage de la fonctionnalité
•  Le cycle doit être court

exécution •  pas de test compliqué
93
Rejeux des tests
Garantir la non régression
•  Une fois écrit, les tests •  Il faut donc veiller à ce que :

unitaires ont vocation à être •  leur nombre ne devienne
rejoués pas trop important
•  chaque fois que la •  leur temps de passage soit
fonctionnalité est impactée acceptable
•  avant chaque commit du •  Il faut organiser les tests de
développeur sorte à ne pas exécuter
systématiquement tous les
tests unitaires
Exercices
94
p 28
3. Automatisation des
tests d'intégration
Stratégies propres à l’intégration : big-bang, « au fil de l’eau », par incréments etc…
Intégration ascendante versus descendante.
Objets simulacres : bouchons, mocking pour remplacer un objet
Intégration continue
Focus sur un gestionnaire de configuration logiciel.
Signalement automatique des anomalies.
Exécution automatique et cyclique des tests logiciels.
Focus sur une constructeur de build.
Focus sur un serveur d’intégration continue.
95
95
Stratégies pour le test d’intégration
Voir www.istqb.org Syllabus Fondation et Analyste Technique
de Test
Niveau Intégration
•  Objectifs génériques
•  Tester les interfaces, les interactions avec un système ou environnement
(logiciel et matériel)
•  Livrables ou documents de référence pour dériver les cas de test (Base de test)
•  Conception du logiciel et du système, Architecture, Flux de données, Cas
d’utilisation
•  Objets de test (Ce qui est testé)
•  Interfaces, Bases de données, Infrastructure
•  Défauts et défaillances typiques à trouver
•  Erreurs de compilation dans l’environnement d’intégration, Contrats
d’interface non respectés
•  Harnais de test (environnement requis pour l’exécution)
•  Environnement d’intégration disposant de bouchons et drivers
•  Outils nécessaires
•  Approche spécifique au niveau (stratégie): Big-Bang, Bottom-Up ou Top-Down
96
Termes, selon le glossaire ISTQB
Intégration
•  le processus de combiner des composants ou systèmes en assemblages
plus grands
Tests d’intégration
•  tests effectués pour montrer des défauts dans les interfaces et interactions
de composants ou systèmes intégrés. Voir aussi tests d’intégration de
composants
Tests d’intégration de composants

•  tests effectués pour découvrir des défauts dans les interfaces et les
interactions entre des composants intégrés
97
Particularités
•  Plus précisément, les tests d’intégration testent
•  Les interfaces entre les composants (tests 2 à 2)
•  Les interactions entre différentes parties d’un système (par exemple
le système d’exploitation)
•  La communication technique entre applications
•  Le comportement sur incident
•  Quelques éléments d’exploitabilité, de sécurité
•  Exemple: intégration d’applications dans un SI
Appli 1 Appli 2 Appli 3 Appli n
EAI Synapse
Information system
98
Particularités: Plusieurs niveaux d’intégration sont possibles
•  Intégration de composants (formant un système)
•  Intégration de systèmes (formant un système de systèmes)
Système de systèmes A
Système 1 Système 2
Composant A
Composant 1
Composant B
Composant 2
Composant C
99
Particularités
•  Le test d’intégration est souvent mené après livraison d’un ou
plusieurs composants ou systèmes par un sous-traitant ou
fournisseur
•  La complexité de l’intégration augmente avec le nombre de

composants à intégrer
•  Plusieurs approches sont possibles en fonction

•  du planning des livraisons
•  des interfaces et interactions entre composants
•  des flux (métiers ou techniques) sollicitant plusieurs composants
100
Particularités: exemple première partie
•  Evolution
complexe d’un
SI…
•  Quelles
applications
simuler?
•  Dans quel
ordre
intégrer?
101
Stratégie d’intégration « Big-Bang »
TEST KO: cherchez l’erreur!
Tous les Environnement d’intégration

composants
sont intégrés Composant A
en même Composant E
temps
Composant B
Composant F
A éviter!
Composant C
Composant G
Composant D Composant H
102
Stratégie d’intégration « Top-Down »
•  du composant le moins sollicité vers les composants qu’il sollicite, et ainsi de suite
•  Faire un “graphe d’appel”
•  Se demander par quel composant commencer! (celui qui demande le moins de bouchons/
drivers)
Composant E
Composant A Composant B
Composant C Composant G Composant F
103
Stratégie d’intégration « Bottom-Up »
•  du ou des composants “feuille(s)” (ne sollicitant aucun autre composant) vers les
composants “appelant”
Composant E
Composant A Composant B
Composant C Composant G Composant F
104
Définition (source: Wikipedia)
•  L'intégration continue est un ensemble de pratiques utilisées en
génie logiciel consistant à vérifier à chaque modification de code source
que le résultat des modifications ne produit pas de régression dans
l'application développée….
•  L'intégration continue se réfère généralement à la pratique de l’

extreme programming.
www.ranorex.com
105
Prérequis
•  Le code source doit être partagé (en utilisant des

logiciels de gestion de versions tels que CVS, Subversion, git,
Mercurial, etc)
•  Les développeurs intègrent (commit) quotidiennement (au moins)
leurs modifications
•  Des tests d'intégration sont développés pour valider l'application
(avec JUnit par exemple)
•  Il faut un outil d'intégration continue tel que CruiseControl ou
Jenkins (anciennement Hudson) pour le langage Java par
exemple
106
Avantages
•  le test immédiat des unités modifiées
•  la prévention rapide en cas de code incompatible ou manquant
•  les problèmes d'intégration sont détectés et réparés de façon

continue, évitant les problèmes de dernière minute
•  une version est toujours disponible pour un test, une

démonstration ou une distribution
107
Pratiques
•  Maintenir un dépôt unique de code source versionné

•  Automatiser les compilations
•  Rendre les compilations auto-testantes
•  Tout le monde commit tous les jours
•  Tout commit doit compiler le tronc (trunk) sur une machine
d'intégration
•  Maintenir une compilation courte
•  Tester dans un environnement de production cloné
•  Rendre disponible facilement le dernier exécutable
•  Tout le monde doit voir ce qui se passe
•  Automatiser le déploiement
108
Étape 1 : mise à jour des sources
109
Étape 2 : détection de la mise à jour
110
Étape 3 : récupération des sources
111
Étape 4 : construction et tests release
112
Étape 5 : livraison de la release
113
Étape 6 : publication du rapport
114
Outils
Exercices
115
p 58
4. Test fonctionnel et son
automatisation
Définition du test fonctionnel, non-régression.
Le test simulant l'action des utilisateurs à partir des interfaces
utilisateurs (IHM).
Constats sur l'automatisation du test fonctionnel.
Automatisation des tests via l'IHM, via des interfaces de
programmation (API).
Chaîne d'outils, robots de test, script (API publiques).
Gestion de l'obsolescence des tests
116
Test fonctionnel – Exemple (1)
Spécification : "Formulaire d’enregistrement pour un site web."
Login:' !ouquet'
Password:' ******'
Verifica7on:' ******'
Register' Cancel'
5Quels
Cas :sont
10 tests logiques
les tests ?
•  Login (non) vide (2)
•  Login (n’) existe (pas) (2)
•  Password (non) vide (2)
•  Password et Verification (ne) sont (pas) les mêmes (2)
•  Protocole http(s) (2)
117
Login:' !ouquet'
Password:' ******'
Quality(
Register' Cancel'
6
5 Cas
Cas :: 13
10 tests
tests logiques
logiques
• •  Login
Login (non)
(non) vide
vide (2)
(2)
• •  Login
Login (n’)
(n’) existe
existe (pas)
(pas) (2)
(2)
• •  Password
Password (non)
(non) vide
vide (2)
(2)
Password etet Verification
Verification (ne)
(ne) sont
sont (pas)
(pas) les
les mêmes
mêmes (2)
(2)
• •  Protocole http(s) (2)
Protocole http(s) (2)
•  Vérifier qualité du password (1 par niveau) : poor, average, good
118
Login:' !ouquet'
Password:' ******' Type'the'word:'

Quality(
Register' Cancel'
7
6 Cas
Cas :: 15
13 tests
tests logiques
logiques
• •  Login
Login (non)
(non) vide
vide (2)
(2)
• •  Login
Login (n’)
(n’) existe
existe (pas)
(pas) (2)
(2)
Password (non)
(non) vide
vide (2)
(2)
Password et et Verification
Verification (ne)
(ne) sont
sont (pas)
(pas) les
les mêmes
mêmes (2)
(2)
• •  Protocole
Protocole http(s)
http(s) (2)
(2)
• •  Vérifier
Vérifier qualité
qualité du
du password
password (1 (1 par
par niveau)
niveau) :: poor,
poor, average,
average, good
good
•  Vérifier si enregistrement (non) humain (2)
119
Test fonctionnel – Données des Test
•  Le test fonctionnel vise à examiner le comportement
fonctionnel du logiciel et sa conformité avec la
spécification du logiciel
ð Sélection des Données de Tests ( DT)
•  Méthodes de sélection :
–  Analyse partitionnelle des domaines des données d’entrée
–  Test aux limites
–  Test combinatoire – Algorithmes Pairwise
–  Test aléatoire
–  Génération de tests à partir d’une spécification
120
Analyse partitionnelle
Invalid inputs Valid inputs Une classe d’équivalence

correspond à un ensemble
de données de tests
System
supposé tester le même
comportement,
c’est-à-dire activer le même
défaut.
Outputs
121
Analyse partitionnelle - Méthode
•  Trois phases :
–  Pour chaque donnée d'entrée, calcul de classes
d'équivalence sur les domaines de valeurs,
–  Choix d’un représentant de chaque classe
d'équivalence,
–  Composition par produit cartésien sur l'ensemble
des données d'entrée pour établir les données de
test.
122
Règles de partitionnement
•  Si la valeur appartient à un intervalle, construire :
–  une classe pour les valeurs inférieures,
–  une classe pour les valeurs supérieures,
–  n classes valides.
•  Si la donnée est un ensemble de valeurs, construire :

–  une classe avec l'ensemble vide,
–  une classe avec trop de valeurs,
–  n classes valides.
•  Si la donnée est une obligation ou une contrainte (forme, sens, syntaxe),

construire :
–  une classe avec la contrainte respectée,
–  une classe avec la contrainte non-respectée
123
Exercice – Classe d’équivalence
On souhaite trouver les classes d’équivalence
d’un ascenseur.
Les fonctionnalités sont les suivantes :
•  Il est borné par un étage minimum : le rez-de-chaussée, il
ne descend donc pas plus bas
•  Il est borné par un étage maximum : N, il ne monte donc
pas plus haut
•  Il a une position de maintenance maintenance
N
88
0
0
124
Correction – Classe d’équivalence
On souhaite trouver les classes d’équivalence d’un
ascenseur.
Les fonctionnalités sont les suivantes :
•  Il est borné par un étage minimum : le rez-de-chaussée, il ne descend
donc pas plus bas
•  Il est borné par un étage maximum : N, il ne monte donc pas plus haut
•  Il a une position de maintenance
maintenance
4 classes d’équivalence : N
•  où l’étage est 0 (rez-de-chaussée)
•  où l’étage est N (le dernier étage) 88
•  où l’étage est entre les 2 (intervalle de valeurs 1..(N − 1))
N
•  où l’ascenseur est en position maintenance
…
0
0
125
Test aux limites
•  Principe : on s’intéresse aux bornes des intervalles partitionnant
les domaines des variables d'entrées :
–  pour chaque intervalle, on garde les 2 valeurs correspondant aux 2
limites, et les n valeurs correspondant aux valeurs des limites ± le
plus petit delta possible :
n ∈ 3 .. 15 ⇒ v1 = 3, v2 = 15, v3 = 2, v4 = 4, v5 = 14, v6 = 16
–  si la variable appartient à un ensemble ordonné de valeurs, on
choisit le premier, le second, l'avant dernier et le dernier
n ∈ {-7, 2, 3, 157, 200} ⇒ v1 = -7, v2 = 2, v3 = 157, v4 = 200
–  si une condition d’entrée spécifie un nombre de valeurs, définir les
cas de test à partir du nombre minimum et maximum de valeurs, et
des tests pour des nombres de valeurs hors limites invalides.
Un fichier d’entrée contient 1-255 records, produire un cas de test
pour 0, 1, 255 et 256.
126
Test aux limites – Types de données
•  Les données d’entrée ne sont pas seulement des

valeurs numériques : booléen, image, son, …
•  Ces catégories peuvent, en général, se prêter à une
analyse partitionnelle et à l’examen des conditions
aux limites :
–  True / False
–  Fichier plein / Fichier vide
–  Trame pleine / Trame vide
–  Nuances de couleur
–  Plus grand / plus petit
–  ….
127
Exemple – Valeur aux limites
7 Cas : 15 tests logiques

•  Login (non) vide (2)
•  Login (n’) existe (pas) (2)
•  Password (non) vide (2)
•  Password et Verification (ne) sont (pas) les
mêmes (2)
•  Protocole http(s) (2)
•  Vérifier qualité du password (1 par niveau) : poor,
average, good
•  Vérifier si enregistrement (non) humain (2)
4 variables :
•  Login : vide, court, normal, très longue chaine (+256c), login existant, ’invalide’ login
•  Password : vide, très longue chaine, même login, poor, average, good
•  Password verification : différent du Password, identique
•  Captcha : la bonne chaine, pas la bonne
128
Analyse partitionnelle et test aux limites –
synthèse
•  L’ analyse partitionnelle est une méthode qui vise à diminuer le

nombre de cas de test par calcul de classes d’équivalence
–  importance du choix de classes d’équivalence : risque de ne pas révéler
un défaut
•  Le choix de conditions d’entrée aux limites est une heuristique solide

de choix de données d’entrée au sein des classes d’ équivalence
–  cette heuristique n’est utilisable qu’en présence de relation d’ordre sur la
donnée d’entrée considérée.
•  Le test aux limites produit à la fois des cas de test nominaux (dans
l’intervalle) et de robustesse (hors intervalle)
129
Exercice – Test aux limites
Supposons que nous élaborions un compilateur pour
un langage. Un extrait des spécifications précise :
≪ L’instruction FOR n’accepte qu’un seul paramètre en tant que

variable auxiliaire. Son nom ne doit pas dépasser deux caractères
non blancs ; Après le signe = est précisée aussi une borne
supérieure et une borne inférieure. Les bornes sont des entiers
positifs et on place entre eux le mot-clé TO.≫
Par exemple : I=1 TO 10 …
Question : Déterminer par analyse partitionnelle des domaines des

données d’entrée les cas de test à produire pour l’instruction FOR.
130
Exercice – Test au limite correction
Exemples des 19 cas de tests :
•  FOR A=1 TO 10 Cas nominal
FOR AA=2 TO 7 Deux caractères pour la variable
FOR ABC=1 TO 10 Erreur - trois caractères
FOR A B=1 TO 8 Erreur - deux variables
FOR &=1 TO 10 Erreur - caractère spécial pour la variable
FOR =1 TO 5 Erreur - variable manquante
FOR A=10 TO 10 Egalité des bornes
FOR I=10 TO 5 Erreur - Borne sup < Borne inf
FOR I=a TO 5 Erreur - Borne inf non entier
FOR I=1 TO 9999999999999999999999999 Erreur - Borne sup dépasse 264
FOR I=-1 TO 5 Erreur - Borne inf négative
FOR I=1 TO -5 Erreur - Borne Sup négative
FOR I=0.5 TO 2 Erreur - Borne inf décimale
FOR I=1 TO 10.5 Erreur - Borne sup décimale
I=7 TO 10 Erreur – FOR manquant
FOR I 7 TO 10 Erreur - = Manquant
FOR I = 7 10 Erreur - TO Manquant
FOR I= TO 10 Erreur – Pas de borne inf
FOR I= 1 TO Erreur – Pas de borne Sup
131
Test aux limites - Evaluation
•  Méthode de test fonctionnel très productive :

–  le comportement du programme aux valeurs limites est
souvent pas ou insuffisamment examiné
•  Couvre l'ensemble des types de test
•  Inconvénient : caractère parfois intuitif ou subjectif

de la notion de limite
⇒ Difficulté pour caractériser la couverture de test.
132
Méthode pour le test combinatoire
•  Les combinaisons de valeurs de domaines d’entrée donne lieu à
explosion combinatoire
•  Exemple : Options d’une boite de dialogue MS Word :
On a 12 cases à cocher et un menu déroulant pouvant prendre 3 valeurs.
Jamais
Toujours
Lors de la sélection
è 212 * 3 = 12 288
133
Test combinatoire : Pair-wise
•  Tester un fragment des combinaisons de valeurs qui garantissent que
chaque combinaison de 2 variables est testé
•  Exemple : 4 variables avec 3 valeurs possibles chacune
OS Réseau Imprimante Format

Windows Cable Laser Texte
Toutes les
combinaisons : 81
Linux Wifi Encre Liquide Image
Mac Os Bluetooth Encre Solide Mixe Toutes les paires : 9
134
Pairwise – Exemple
•  9 cas de test : chaque combinaison de 2 valeurs est testée
N° OS Réseau Imprimante Applica-on
Cas 1 Windows Bluetooth Laser Texte
Cas 2 Windows Cable Jet d’encre Image
Cas 3 Windows Wifi Ruban Mixe
Cas 4 Mac OS Bluetooth Jet d’encre Mixe
Cas 5 Mac OS Cable Ruban Texte
Cas 6 Mac OS Wifi Laser Image
Cas 7 Linux Bluetooth Ruban Image
Cas 8 Linux Cable Laser Mixe
Cas 9 Linux Wifi Jet d’encre Texte
L’idée sous-jacente : la majorité des fautes sont détectées par
des combinaisons de 2 valeurs de variables
135
Exercice – n-wise
On désire tester la procédure de prise de commande d’un restaurant. Pour
cela, la procédure prend en paramètres 4 variables représentant
respectivement une entrée, un plat, un dessert et un café. Chacune possède
les valeurs possibles suivantes :
Entrée Plat Dessert Café

Pâté Grillade Fromage blanc Non
Salade Poisson Fruit Oui
Soupe Volaille Gâteau
Glace
Calculer un ensemble de données de tests avec un approche pairwise ?
136
Exercice – n-wise correction
N° Test Entrée Dessert Plat Café
1 Pâté Fromage blanc Grillade
2 Pâté Fruit Poisson
3 Pâté Gâteau Volaille
4 Pâté Glace
5 Salade Fromage blanc
6 Salade Fruit Grillade
7 Salade Gâteau Poisson
8 Salade Glace Volaille
9 Soupe Fromage blanc Volaille
10 Soupe Fruit
11 Soupe Gâteau Grillade
12 Soupe Glace Poisson
137
4 Pâté Glace
5 Salade Fromage blanc Poisson
10 Soupe Fruit
138
4 Pâté Glace Grillade
5 Salade Fromage blanc Poisson
10 Soupe Fruit Volaille
139
1 Pâté Fromage blanc Grillade Oui
2 Pâté Fruit Poisson Non
5 Salade Fromage blanc Poisson Non
6 Salade Fruit Grillade Oui
9 Soupe Fromage blanc Volaille Oui
10 Soupe Fruit Volaille Non
140
3 Pâté Gâteau Volaille Non
7 Salade Gâteau Poisson Oui
141
3 Pâté Gâteau Volaille Non
4 Pâté Glace Grillade Non
7 Salade Gâteau Poisson Oui
8 Salade Glace Volaille Oui
11 Soupe Gâteau Grillade -
12 Soupe Glace Poisson -
142
Test combinatoire
•  L’approche Pair-wise se décline avec des triplets, des
quadruplets, …. mais le nombre de tests augmente très vite
•  Différents outils permettent de calculer les combinaisons en

Pairwise (ou n-valeurs) :
–  http://www.pairwise.org/default.html
–  Prise en charge des exclusions entre valeurs des domaines et
des combinaison déjà testée
•  Problème du Pair-wise :
–  le choix de la combinaison de valeurs n’est peut-être pas celle qui
détecte le bug …
–  Le résultat attendu de chaque test doit être fourni manuellement
143
Test aléatoire ou statistique
•  Principe : utilisation d'une fonction de calcul pour

sélectionner les données de test :
–  fonction aléatoire : choix aléatoire dans le domaine de la
donnée d'entrée,
–  utilisation d'une loi statistique sur le domaine.
•  Exemples :
–  Echantillonnage de 5 en 5 pour une donnée d'entrée
représentant une distance,
–  Utilisation d'une loi de Gauss pour une donnée
représentant la taille des individus,
–  ...
144
Evaluation du test aléatoire
•  Intérêts de l'approche statistique :
–  facilement automatisable pour la sélection des cas de
test, (plus difficile pour le résultat attendu)
–  objectivité des données de test.
•  Inconvénients :
–  fonctionnement en aveugle,
–  difficultés de produire des comportements très spécifique
public int methodeImprobable(int x, int y) {

if (x == 600 && y == 500) then
thrown new Exception("Bonne chance pour me trouver");
return (x+y); 
}
145
Productivité du test aléatoire ou statistique
% couverture
Test déterministe
objectif
Test aléatoire
Effort
Les études montrent que le test statistique permet d'atteindre rapidement
50 % de l'objectif de test mais qu'il a tendance à plafonner ensuite.
146
Test à partir de modèles
Modélisation Spécifications
Techniques
de Besoins
Modèle formel 
StateCharts,UML,B, BPML…
Développement
Production des tests
Cas de test
générés
Production des scripts
Scripts de tests Validation

Implémentation
exécutables
147
Langages de modélisation
•  De nombreux paradigmes
–  Systèmes de transitions (Etats / Transitions / Evénements)
•  Flow Charts
•  Data Flow Diagrams
•  Diagramme d’état
–  Diagrammes objet & association (Entité-Relation, héritage, …)
•  Diagramme de classe (UML)
•  Entité-Relation
–  Représentation Pré-Post conditions
•  OCL (UML)
•  Machine Abstraite B
•  Représentation :
•  Graphique (plus « intuitive »)
•  Textuelle (plus précise)
148
Model Based Test Generation
Modèle formel
Ensemble de
Générateur Cas de tests
de tests
Directives de
•  séquence de stimuli
génération
•  résultats attendus
•  Directives de génération (définition de scénarii de test) :

–  Critères de couverture du modèle
–  Critères de sélection sur le modèle
149
Synthèse
•  La
production de test s’appuie (généralement) sur une
analyse du programme (test structurel) ou de sa
spécification (test fonctionnel)
•  Différentes stratégies permettent de sélectionner des

données de test pertinentes.
•  Ces stratégies ne sont que des heuristiques !

Elles ne fournissent aucune garantie de sélectionner la
valeur qui révélera les erreurs du programme.
150
Univers outillé
Conformiq,)SmartesGng,)
Tableur,)Doors,)) Test)opGmal,)BenderRBT),)
HP)ALM,)IBM)Rat.) Praspel,)JML…)
Requier.)Composer)
Artéfacts)
Exigences) de)Tests)
HP,)IBM,)salomeFTM)) Tableur,)Sonar,))
Squash)TM,)Testlink) Cobertura,)jenkins)
…)
Référen3el) ) Rapports)
de)Tests)
Scripts)
Anomalies) de)Tests)
Bugzlla,)Jira,)ManGs,) IBM)RFT,)Selenium,)
)Tableur,)Redmine) HP)QuickTestPro,)Sahi,)
XxUnit)
Exercices
151
p 95
5. Automatisation de la
gestion des tests
Gestion de la couverture des exigences par les tests.
Démarche de mise au point : organisation des suites de tests et création des cas.
Préparation à l'automatisation.
Construction de la population de test.
Mise au point et vérification des tests (Revue)
Exécution, enregistrement des anomalies. Notion de rapport d'incident d'après l'IEEE.
Gestionnaires d'anomalies. Automatisation de la création des anomalies.
Analyse de résultats d'exécution de tests. Consolidation des tests.
152
152
Etape -1 : Recueil des exigences
GesEonnaire
d’exigences
193
Etape 0 : utilisation des exigences
0 Cahier
de tests
GesEonnaire RéférenEel
d’exigences de tests
0 Développement
Postes de
développement
194
Etape 1 : mise à jour des sources
0 Cahier
de tests
0 Développement
1 Commit
Postes de Serveur de gesEon
développement de versions
195
Etape 2 : détection de la mise à jour
0 Cahier
de tests
0 Développement
Serveur
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit
196
Etape 3 : récupération des sources
0 Cahier
de tests
0 Développement
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit
197
Etape 4 : construction et tests realease
Compiling…
TesEng…
Unit tests … OK - Coverage: 64%
IntegraEon tests … OK – Coverage: 88%
0 Cahier Acceptance test … OK – Coverage: 88%

de tests SUCCESS
GesEonnaire RéférenEel 4 Build + Tests

0 Développement
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit
198
Etape 5 : livraison release
0 Cahier
de tests
0 Développement
5 Livraison
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit Serveur de
Postes de Serveur de gesEon déploiement
199
Etape 5a : livraison continue
0 Cahier
de tests
Serveur de test
0 Développement
5 Livraison
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit Serveur de
200
Etape 5b : test fonctionnel continu
5 Demande execuEon 5 ExecuEon
0 Cahier
de tests Robots de tests Serveur de test
0 Développement
5 Livraison
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit Serveur de
201
Etape 6 : publication du rapport
5 Demande execuEon 5 ExecuEon
0 Cahier
de tests 6 Verdict Robots de tests Serveur de test
0 Développement
6 NoEficaEon 5 Livraison
Serveur
3 Update
d’intégraEon
DétecEon de
2 DétecEon de
la
la modificaEon
modificaEon
1 Commit Serveur de
202
Outils
•  Gestions des exigences
•  Référentiel de tests
•  Gestionnaire des scripts de tests
•  Robot d’exécutions DOORS, Jazz
•  Rapport d’exécutions
Caliber – Silk Test
QTP
Exercices
203
p 121
Fin de la partie Cours
Merci pour votre participation et bonne continuation
204

OTT Outillage Des Tests Cours 1 1

Transféré par

Droits d'auteur :

Formats disponibles

OTT Outillage Des Tests Cours 1 1

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

OTT Outillage Des Tests Cours 1 1

Transféré par

Droits d'auteur :

Formats disponibles

Introduction au test logiciel

Fabrice Ambert, Fabrice Bouquet

• Pour chaque participant

Introduction, rappels sur le processus du test

Automatisation de la gestion des tests

Automatisation des tests unitaires

Automatisation des tests d'intégration

Automatisation du test fonctionnel

Automatisation des tests système

Cours Thèmes Durée Exercices Outils Durée

1. Introduction, rappels sur le Types, Niveaux, J1,

2. Automatisation des tests Couverture de J1, Intégrés au cours Junit, mockito, J1

5. Automatisation de la gestion Conception, J3, Cahier Squash TM / TA J3,

Source: PAC 2016, Arnold Aumasson

• « Tester, c’est exécuter le programme dans l’intention d’y trouver

• «Testing can reveal the presence of errors but never their

• Actuellement, le test dynamique est la méthode la plus diffusée

• Coût moyen de l'activité de test :

• ISTQB: International Software Testing Qualifications Board

• CFTL: Comité Français des Tests Logiciels

• Coût des bugs informaEques : ≈ 60 milliards $ / an

• Le test appartient à l’activité de Validation du logiciel :

• Activité historiquement peu populaire en entreprise

• Difficultés d’ordre psychologique ou « culturel » :

Traite le code du logiciel sans l’exécuter sur des données réelles.

Repose sur l’exécution effective du logiciel pour un sous

à Les méthodes de test statiques sont nécessaires, mais pas

En résumé, les méthodes de test dynamique consistent à :

• Les données de test sont produites

Critères de test : ≤ 20 fois

• Exemple : soit le programme suivant, censé calculer la somme de 2 entiers :

• Une approche fonctionnelle détectera difficilement le défaut, alors qu’une

• En examinant ce qui a été réalisé, on ne prend pas forcément en

• Une difficulté du test structurel consiste dans la définition de

Un programme prend en entrée trois entiers. Ces trois entiers sont

• Donnez un ensemble de cas de test que vous pensez adéquat pour

• Chacun de ces cas correspond à un défaut constaté

• La moyenne des résultats obtenus par un ensemble de

=> Le test est une activité complexe, a fortiori sur de

Sélection d’un jeu de tests : choisir un sous-ensemble des

Soumission du jeu de tests

Dépouillement des résultats : consiste à décider du succès ou

Évaluation de la qualité et de la pertinence des tests effectués

Tests nominaux / de bon fonctionnement

Tests système / de recette

Test et cycle de vie du processus de test

• En test fonctionnel, l’ensemble des données d’entrée est en général

=> le test est une méthode de validation partielle de logiciels

PTV Phases et planning

Automatique & Choix métier

Tests Fonctionnels Tests Exploratoires

Tests Unitaires Tests de charge

Tests Fonctionnels Tests Exploratoires

Tests Unitaires Tests de charge

Permet d’avoir en temps réel

Tests Fonctionnels Tests Exploratoires

Tests Fonctionnels Tests Exploratoires

Tests Unitaires Tests de charge

•  Pour chaque participant

•  « Tester, c’est exécuter le programme dans l’intention d’y trouver

•  «Testing can reveal the presence of errors but never their

•  Actuellement, le test dynamique est la méthode la plus diffusée

•  Coût moyen de l'activité de test :

•  ISTQB: International Software Testing Qualifications Board

•  CFTL: Comité Français des Tests Logiciels

•  Coût des bugs informaEques : ≈ 60 milliards $ / an

•  Le test appartient à l’activité de Validation du logiciel :

•  Activité historiquement peu populaire en entreprise

•  Difficultés d’ordre psychologique ou « culturel » :

•  Les données de test sont produites

•  Exemple : soit le programme suivant, censé calculer la somme de 2 entiers :

•  Une approche fonctionnelle détectera difficilement le défaut, alors qu’une

•  En examinant ce qui a été réalisé, on ne prend pas forcément en

•  Une difficulté du test structurel consiste dans la définition de

•  Donnez un ensemble de cas de test que vous pensez adéquat pour

•  Chacun de ces cas correspond à un défaut constaté

•  La moyenne des résultats obtenus par un ensemble de

•  En test fonctionnel, l’ensemble des données d’entrée est en général

•  Validation du fonctionnement •  Le développeur

•  Le test structurel s’appuie sur l’analyse du code source de

ð Basés sur le graphe de contrôle (toutes les instructions, toutes

•  Permet de représenter n’importe quel algorithme

•  Les nœuds représentent des blocs d’instructions

•  Les arcs représentent la possibilité de transfert de l’exécution

•  Chaque nœud (chaque bloc d’instructions) est atteint par au

•  Lorsqu’un jeu de test permet de couvrir tous les nœuds du

•  Lorsqu’un jeu de test permet de couvrir tous les arcs du graphe,

•  Couverture de tous les chemins possibles passant de 0 à i fois

•  Déterminer un ensemble de •  Le nombre de chemins

1.  Evaluer V(G)

6.  Vérifier l’indépendance du chemin calculé par rapport aux autres

•  En posant i=n (avec n le nombre maximal d’itérations possibles)

•  En pratique, ce critère est rarement envisageable sur des

•  Définition de variables : la valeur de la variable est modifiée

•  Utilisation de variables : accès à la valeur de la variable

•  Préconisé par les méthodes

•  Écrire le test avant le code

•  Le test spécifie un comportement

•  Le cycle doit être court

•  Une fois écrit, les tests •  Il faut donc veiller à ce que :

•  Exemple: intégration d’applications dans un SI

•  La complexité de l’intégration augmente avec le nombre de

•  Plusieurs approches sont possibles en fonction

•  L'intégration continue se réfère généralement à la pratique de l’

•  Le code source doit être partagé (en utilisant des

•  le test immédiat des unités modifiées

•  la prévention rapide en cas de code incompatible ou manquant

•  les problèmes d'intégration sont détectés et réparés de façon

•  une version est toujours disponible pour un test, une

•  Maintenir un dépôt unique de code source versionné