Support Tes

Formation
ISTQB
Laroussi Merhbene
Plan
• Présentation du formateur
• Objectifs de la formation
• Le plan de formation
• Public concerné
• Connaissances requises
• Documents utiles
04/02/2023 2
Plan de la formation
1) Introduction au test logiciel
2) Stratégie & plan de tests
3) Automatisation des test unitaires
4) xUnit
5) Apache ANT
6) Automatisation des tests d'intégration
7) Tests de validation
8) Recette
9) Maturité des processus de tests
10) Maturité des tests avec TMMI/CMMI
04/02/2023 3
Let’s begin
04/02/2023 4
Introduction au test
logiciel
04/02/2023 5
Plan
• Rôle du test dans le processus de développement
• DSIs & tests
• Couts des tests
• Validation & Vérification
• Définition des tests
• Concept des tests
• Tests dans TIC
• Cycle en V
• Test Diven Development (TDD)
• Différentes méthodes de test
• Oracle & verdict
• Niveaux et stratégie des tests
Rôle du test dans le processus de développement (1/2)
Les bugs sont nombreux et couteux pour la société possédant le

logiciel, ses fournisseurs, ses clients, les utilisateurs finaux…
04/02/2023 7
Rôle du test dans le processus de développement (2/2)
Problèmes de sécurité (Figaro 21/09/16)
04/02/2023 8
DSIs et tests
Source: « World Quality Report 2016-2017, Sogeti »
44% 42%
65% 42%
Augmenter la Améliorer
Améliorer la Optimiser les
sécurité Qualité des l’Expérience coûts
Solutions Utilisateur
04/02/2023 9
Couts des tests
Une place très importante dans l’IT
Source: PAC 2016, Arnold Aumasson
04/02/2023 10
Validation & Vérification
Qui/Pourquoi ?
► Validation : Est-ce que le logiciel réalise les fonctions attendues ?
► Vérification : Est-ce que le logiciel fonctionne correctement ?
Exemple de méthodes de V & V

► Test statique : Revue de code, de spécifications, de documents de design
► Test dynamique : Exécuter le code pour s’assurer d’un fonctionnement
correct
► Vérification symbolique : Run-time checking, Exécution symbolique
► Vérification formelle : Preuve ou model-checking d’un modèle formel,
raffinement et génération de code
04/02/2023 11
Pourquoi tester
Motivation
► Ariane 5, Carte à puce en Allemagne, Réseau Orange...
► Complexité des comportements
Erreur dans les spécifications, la conception, ou le programme

⇓
Défaut (faute) dans le logiciel
⇓
Défaillance (anomalie de fonctionnement) duprogramme
Quelques chiffres
► Coût des bogues informatiques : 60 Milliards e/ an
► 22 Milliards économisés si processus tests
04/02/2023 12
Définition des tests
I E E E (Standard Glossary of Software Engineering Terminology)

"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".
G. Myers (The Art of Software testing)

"Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou
des défauts".
Edsgar W. Dijkstra. Notes on structured programming. Academic Press, 1972

"Tester peut révéler la présence d’une anomalie mais jamais son absence".
04/02/2023 13
Concept des tests
Le test est une activité de validation du logiciel
Est-ce que le logiciel a été développé correctement en fonction des différentes
exigences ?
Test est une activité pas très populaire

Difficultés d’ordre psychologique ou culturel :
► Le développement est constructif car on cherche à établir des résultats
corrects
► Le test est destructif car un bon test est un test qui trouve une anomalie
Cependant, le test est une activité centrale :
► C’est un élément principal d’amélioration de la qualité logiciel
► Il peut représenter jusqu’à 60% du coût complet du logiciel :
► 1/3 durant le développement du logiciel
► 2/3 durant la maintenance du logiciel
04/02/2023 14
Tests dans TIC
Top 4 des points d’amélioration Europe de l’ouest

► Choisir une méthodologie s’intégrant dans un développement agile/composant.
► Fournir une couverture automatisée de test automatique pour permettre l’agilité dans le test
► Plus se concentrer sur les aspects non-fonctionnels comme la performance, la
disponibilité, la sécurité, etc
► Avoir une stratégie de test qui optimise l’usage de services de tests (traditionnel ou cloud).
04/02/2023 15
Cycle de développement en V
04/02/2023 16
Principe de la méthode SCRUM
04/02/2023 17
Coûts du projet
Mise en Mise en Mise en Mise en Mise en Prod. 2
product i o n Prod. 1 Prod. 3 Prod. n
Test
Développement
Concep'on
Maintenance
Concep'on
Développement
Coût
Coût
Test
Etape du projet Etape du projet
04/02/2023 18
Développement Guidé par les Tests (TDD)
Développement Dirigé par les Tests
► Méthode de développement dans les méthodes agiles
► Préconise l’écriture des tests avant le développement du code
Début
Ajout (test)
Refactoring Exécu/on
Exécu/on Codage
04/02/2023 19
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.
04/02/2023 20
Test statique (1/4)
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
04/02/2023 21
Test statique (2/4)
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
04/02/2023 22
Test statique (3/4)
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
04/02/2023 23
Test statique (4/4)
Exemple de rapport Sonar
04/02/2023 24
Niveaux des tests dynamiques
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)
04/02/2023 25
Techniques des tests dynamiques
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
04/02/2023 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
04/02/2023 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
04/02/2023 28
Récapitulation des boites de test
04/02/2023 29
Techniques et échelle
04/02/2023 30
Oracle et verdict (1/2)
• La définition de l’oracle est un problème très difficile
• limite fortement certaines méthodes de test (ex : probabiliste, BN)

• impose un trade-off avec la sélection de tests
• point le plus mal maitrisé pour l’automatisation
04/02/2023 31
Oracle et verdict (2/2)
• Quelques cas pratiques d’oracles parfaits automatisables

• comparer à une référence : logiciel existant, tables de résultats résultat simple à vérifier
(ex : solution d’une équation) disponibilité d’un logiciel similaire : test dos à dos
• Des oracles partiels mais automatisés peuvent être utiles

• oracle le plus basique : le programme ne plante pas ; instrumentation du
code (assert)
• plus évolué : programmation avec contrats (Eiffel, Jml pour Java)
04/02/2023 32
Le verdict
04/02/2023 33
Quelques principes de testing
1 Le programmeur ne doit pas être le testeur ...

2 Ne pas faire les tests en prenant comme hypothèse qu’il n’y a pas
d’erreur ... être suspicieux
3 La définition des sorties doit être effectuée AVANT l’exécution du
test et pas après ...
4 Faire une analyse soigneuse des traces/résultats
5 Faire des jeux de test avec des entrées valides E T invalides
6 Tester que le logiciel fait ce qu’il doit faire ... mais aussi regarder
ce qu’il se passe quand on lui fait faire ce qu’il ne doit pas faire
(robustesse)
04/02/2023 34
Complémentarité test
fonctionnel / structurel (1/2)
• Les 2 approches sont utilisées de façon complémentaire
• Exemple : soit le programme suivant, censé calculer la somme de 2 entiers :
• 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.
04/02/2023 35
Complémentarité test
fonctionnel / structurel (2/2)
• 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.
04/02/2023 36
Tests de (non) régression
• Tests de régression : à chaque fois que le logiciel est modifié, s’assurer que “ce qui fonctionnait
avant fonctionne toujours”
• Pourquoi modifier le code déjà testé ?
• correction de défaut
• ajout de fonctionnalités
• Quand ?
• en phase de maintenance / évolution ou durant le
développement
• Quels types de tests ?

• tous : unitaires, intégration, système, etc.
• Objectif : avoir une méthode automatique pour rejouer
automatiquement les tests
04/02/2023 37
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)
04/02/2023 38
Niveaux de tests
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)
04/02/2023 39
Processus de test et
stratégie de test
Test et cycle de vie du processus de test
04/02/2023 40
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 chemins logiques 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
04/02/2023 41
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
04/02/2023 42
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
04/02/2023 43
Outils et Méthodes
intervenants à différentes
étapes
Build et Distribution: Utile pour tout le quadrant de test
Automatique & Choix métier
Manuel
Manuel
Tests Fonctionnels Tests Exploratoires

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

Tests de composants Tests de performance
“ilité” tests
Automatique Outils
Choix technologique
04/02/2023 44
Outils et Méthodes
intervenants à différentes
étapes
Intégration continue : Tableau de contrôle
Permet d’avoir en temps réel

le statut du projet (tests
unitaires, tests statiques,
couverture…)
04/02/2023 45
Ce qu’on a couvert
• Principe et importance des tests.
• Choix des jeux de données.
• Choix des tests.
04/02/2023 46
STRATÉGIE & PLAN DE
TESTS
Plan
• Introduction
• Stratégie des tests
• Typologie des tests
• Tests à réaliser
Introduction
• Stratégie & plan de tests sont initialisés en phase de conception
• Tous les types de tests ne sont pas forcément mis en œuvre.
• Leur mise en œuvre dépend des contraintes, besoins et contenu du projet.
• Il est aussi normal qu'en début de conception, la totalité des types de

tests ne soit pas complètement figée (plan de test).
Comment tester ?
Exigences / Contraintes
contraintes contractuelles
Client
Périmètre
Moyens
des À valider avec le client Planning
tests
Stratégie de tests
La stratégie de tests
(1/3)
 Définir le périmètre applicatif
 Définir les exclusions du périmètre
Objectifs
 Définir les phases et types de tests à effectuer
✓ Tests unitaires, d’intégration, de validation, de
non régression, de performance , …
 Définir le taux de couverture de tests pour chaque

phase
Une bonne stratégie de tests et des mauvais outils feront

quand même des bons tests, pas l’inverse !!
(2/3)
Définition du périmètre
➢ Quelles sont les fonctions, les interfaces que l’on va tester?
NORMALEMENT TOUTES
➢ Parmi les fonctions testées, lesquelles sont testées dans leur globalité,
partiellement, par quoi commence-t-on?
➢ Quels sont les éléments qui vont guider nos choix?

✓ La fonction est-elle très utilisée (de nombreux utilisateurs sont coincés)
✓ Si la fonction ne marche pas, quels sont les risques que cela provoque
• Risque humain (centrale nucléaire, aviation)
• Grosse perte financière
✓ Qualité du code produit (facteur technique et/ou humain)
✓ Exigences client
(3/3)
Exemple de définition du périmètre
➢ Électricité d’une maison
✓ On va tester
• Que l’électricité est bien au compteur
• Que les lumières s’allument
• La lumière de l’entrée, des salles principales
✓ On ne va pas tester
• Que la centrale nucléaire fournit bien l’électricité
• Si la lumière de la cave ne marche pas, cela n’est pas trop grave,
celle-ci n’est pas encore aménagée
Typologie des tests (1/6)
Les Tests Unitaires
Rappel définition : Un test unitaire -qu'on pourrait aussi appeler élémentaire-
porte sur un élément fin et précis dont on veut vérifier le fonctionnement
correct sur tel ou tel aspect. Cet élément peut être technique (fonction,
méthode, comportement face à une situation donnée,…) ou fonctionnel (règles
de gestion, règle de saisie,...).
Objectif des TU : Vérifier que le composant répond aux exigences de bas niveau
décrites dans la conception, ou découlant de sa fonction
Exemple :
➢ Toutes les prises de courant sont bien montées (Aucun fil nu qui subsiste ?)
➢ Le compteur électrique est connecté physiquement au réseau électrique
Les Tests d’Intégration

Rappel définition : L’intégration est l’assemblage progressif des différents
composants de la solution.
Objectif des TI : Vérifier que l’assemblage progressif des composants répond
aux exigences de spécification ; vérifier les interfaces entre composants.
On va aussi se poser la question de savoir :
➢ Le critère d’entrée en phase d’intégration
➢ s’il faut le faire en plusieurs étapes, une partie puis une autre,
➢ par quoi on commence (les composants les plus critiques, les plus utilisés)
➢ Le critère de sortie de phase d’intégration
Exemple :
Vérifier que le courant est présent en sortie du tableau électrique (liaison réseau +
compteur + câblage + disjoncteur + tableau électrique + prise).
Les Tests de validation interne
Rappel définition : Test d’un système complet par rapport à sa spécification
Objectif des TV : Vérifier la conformité du logiciel avec les exigences Client
On va aussi se poser les questions suivantes :

➢Critère d’entrée en phase de validation
➢Choix du niveau de couverture fonctionnelle attendu
➢Critère de sortie de phase de validation (itérations possibles selon
anomalies résiduelles)
Exemple :
On vérifie par l’utilisation de la machine à laver que le système électrique fonctionne.
Typologie des tests
(4/6)
Les Tests de non régression
Rappel définition : Tests ayant pour objectif de vérifier que les modifications
induites par la correction d’un ou plusieurs défauts (ou l'apport d'évolutions)
n’ont pas eu pour effet d'introduire de nouvelles erreurs sur des
fonctionnalités non modifiées. Les tests préexistants (unitaires, d’intégration
ou de validation) qui s’exécutaient sans lever de défaut, doivent toujours
faire de même après les modifications.
En cas d’ajout ou de modification de composant(s) il faut vérifier que tout ce qui a pu être
impacté de près ou de loin continue de fonctionner.
On va aussi se poser la question (dès la stratégie de test) :
➢ Doit-on tout vérifier ?
➢ Ne doit-on vérifier que les composants en relation avec le composant modifié ?
Exemple :
Après toute intervention, on choisit de tester une prise par pièce de la maison, un seul
radiateur, l’alimentation du congélateur.
Typologie des tests
(5/6)
Les Tests de performance

Rappel définition : Tests dont l'objectif est de contrôler que les performances
de l’application ou de certains composants logiciels, sont conformes au
seuil d’acceptation (défini par le Client sous forme d’exigence)
Dans certains cas, il va être nécessaire de vérifier que le nouveau système répond à des
contraintes de temps de réponse, différentes opérations par minute, durée du
traitement ou de charge réseau (exigences client).
Les tests de performance sont déclenchés au moyen de :
- Montées en charge (augmentation du nombre d’utilisateurs)
- Montées en stress (augmentation du volume des données)
Exemple :
Faire un test aux limites avec le maximum d’appareils électriques branchés et en
fonctionnement.
Les Tests opérationnels
ou « de bout en bout »
Rappel définition : Les tests opérationnels ont pour but de jouer

en amont des phases de recette des scénarios assez complexes
et faisant intervenir la plupart des fonctions du système testé.
Objectif : détecter au plus tôt dans un contexte « réaliste »

d’utilisation les défauts du logiciel.
L’objectif des tests doit être défini avec le client.

Exemple :
Mettre une famille en situation d’utilisation normale d’une maison durant une
journée
RÉALISER LESTESTS
+ Campagne: planification des tests. Une campagne est composée de un

ou plusieurs scénarios
+ Scenario : ensemble de tests à réaliser. Un scénario est composé de un

ou plusieurs cas de tests
+ Cas de tests : c'est le test à réaliser. Une petite histoire à raconter et
vérifier. Un cas de tests ressemble beaucoup à une user-story :
contexte, déclencheur, action, résultat attendu « given when-then »
+ L'exécution des cas de tests permet de détecter des écarts par rapport
aux spécifications (vérification), objectif initial (validation).
• Type des tests à réaliser.
• Stratégie de mise en œuvre des tests.
Automatisation des
tests unitaires
04/02/2023 62
Plan
• Processus des tests
• Tests unitaires
• Graphe de contrôle
• Couverture structurelle
• Flot de données
• Rejeux des tests
Processus
04/02/2023 64
Test unitaire
Quoi ? • Qui ?
• Validation du fonctionnement • Le développeur

d’une portion d’un
programme
• Comment ?
Quand ?
• Package disponibles dans de
• Dans un cycle en V : après la nombreux langages
phase de développement • Java : Junit, TestNG
• Dans un cycle agile : intégré
au développement (TDD) • PHP : PHPUnit, SimpleTest, atoum
65
04/02/2023
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, …)
04/02/2023 66
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
04/02/2023 67
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 f
not found
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
04/02/2023 68
Chemins de contrôles
• Définition x0 a x >0
b x = abs(x)+4 c
• Chemin dans le graphe de contrôle x = 2x-15
• Débute au nœud d’entrée du graphe d
x = -1 x  -1
• Termine au nœud de sortie du graphe
e f
• Peut être activable ou non
g
• abdeg : un chemin de contrôle bdfg : non • 4 chemins de contrôles
• abdeg
• abdfg
• acdeg
• acdfg 69
04/02/2023
Couverture structurelle
Couverture du graphe de flot de contrôle
Considérer les Produire des

chemins de données Exécuter le
contrôle (tous ou d’entrée Établir les programme
permettant oracles dans ces
certains en associés
d’activer ces configurations
fonction du critère chemins
de couverture)
04/02/2023 70
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
04/02/2023 71
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
04/02/2023 72
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]
04/02/2023 73
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.
04/02/2023 74
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
04/02/2023 75
Couverture de 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;
04/02/2023 76
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
04/02/2023 77
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
04/02/2023 78
• Déterminer un ensemble de chemins

représentatif de tous les comportements • Le nombre de chemins nécessaire est
• Construire une base de chemins qui par donné par la complexité cyclomatique
combinaison linéaire donne tous les du graphe (Mc Cabe)
chemins
• Considérer les vecteurs des chemins par
nombre de conditions
rapport aux arcs (G) = +1
élémentaires
04/02/2023 79
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
04/02/2023 80
Couverture de tous les chemins
• 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)
04/02/2023 81
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)
04/02/2023 82
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 droite 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 est utilisée 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.
04/02/2023 83
Rejeux des tests
Garantir la non régression
• Une fois écrits, les tests unitaires ont vocation à être rejoués
• chaque fois que la fonctionnalité est impactée
• avant chaque commit du développeur
• Il faut donc veiller à ce que :
• leur nombre ne devienne pas trop important
• leur temps de passage soit acceptable
• Il faut organiser les tests de sorte à ne pas exécuter systématiquement tous les
tests unitaires
04/02/2023
• Importance des tests unitaire.

• Choix des jeux de tests selon les branches.
• Couverture des jeux de test.
04/02/2023 85
xUnit
04/02/2023 86
Plan
• Principe des xUnit
• Concept du framework JUnit
• Les cas de test
• Aspects méthodologiques
• Du XP au TDD
Principe des xUnit
• Tests unitaires réalisés au niveau des langages informatiques.
• jUnit
• PHPunit
• Cunit
• CPPunit
Concept du framework JUnit
• La référence des tests unitaires en Java
• Trois des avantages de l’eXtreme Programming appliqués aux tests :
– Comme les tests unitaires utilisent l’interface de l’unité à tester, ils
amènent le développeur à réfléchir à l’utilisation de cette interface
tôt dans l’implémentation
– Ils permettent aux développeurs de détecter tôt des cas aberrants
– En fournissant un degré de correction documenté, ils permettent
au développeur de modifier l’architecture du code en confiance
04/02/2023 89
Exemple de JUnit
class Money {
• Une classeint
private Money
fAmount;
private String fCurrency;
public Money(int amount, String currency) {
fAmount= amount;
fCurrency= currency;
}
public int amount() {

return fAmount;
}
public String currency() {

return fCurrency;
}
}
04/02/2023 90
Premier Test avant d’implémenter simpleAdd
import static org.junit.Assert.*;
public class MoneyTest {

//…
@Test public void simpleAdd() {
Money m12CHF= new Money(12, "EUR"); // (1)
Money m14CHF= new Money(14, "EUR");
Money expected= new Money(26, "EUR");
Money result= m12CHF.add(m14CHF); // (2)
assertTrue(expected.equals(result)); // (3)
}}
1. Code de mise en place du contexte de test (fixture)

2. Expérimentation sur les objets dans le contexte
3. Vérification du résultat, oracle…
04/02/2023 91
Les cas de test
• Ecrire des classes quelconques
• Définir à l’intérieur un nombre quelconque de méthodes annotés @Test
• Pour vérifier les résultats attendus (écrire des oracles !), il faut appeler
une des nombreuses variantes de méthodes assertXXX() fournies
– assertTrue(String message, boolean test), assertFalse(…)
– assertEquals(…) : test d’égalité avec equals
– assertSame(…), assertNotSame(…) : tests d’égalité de référence
– assertNull(…), assertNotNull(…)
– Fail(…) : pour lever directement une AssertionFailedError
– Surcharge sur certaines méthodes pour les différentes types de base
– Faire un « import static org.junit.Assert.* » pour les rendre

toutes disponibles
04/02/2023 92
Application à equals dans Money
@Test public void testEquals() {
Money m12CHF= new Money(12, "CHF");
assertTrue(!m12CHF.equals(null));
assertEquals(m12CHF, m12CHF);
assertEquals(m12CHF, new Money(12, "CHF"));
assertTrue(!m12CHF.equals(m14CHF));
}
public boolean equals(Object anObject) {

if (anObject instanceof Money) {
Money aMoney= (Money)anObject;
return aMoney.currency().equals(currency())
&& amount() == aMoney.amount();
}
return false;
}
04/02/2023 93
Fixture : contexte commun
• Code de mise en place dupliqué !
• Des classes qui comprennent plusieurs méthodes de test peuvent utiliser

les annotations @Before et @After sur des méthodes pour initialiser,
resp. nettoyer, le contexte commun aux tests (= fixture)
– Chaque test s’exécute dans le contexte de sa propre installation, en appelant la
méthode @Before avant et la méthode @After après chacune des méthodes de test
– Pour deux méthodes, exécution équivalente à :
• @Before-‐method ; @Test1-‐method(); @After-‐method();
• @Before-‐method ; @Test2-‐method(); @After-‐method();
– Cela doit assurer qu’il n’y ait pas d’effet de bord entre les exécutions de tests
– Le contexte est défini par des attributs de la classe de test
04/02/2023 94
Fixture : application
public class MoneyTest {
private Money f12CHF;
private Money f14CHF;
@Before public void setUp() {

f12CHF= new Money(12, "CHF");
f14CHF= new Money(14, "CHF");
}
@Test public void testEquals() {

assertTrue(!f12CHF.equals(null));
assertEquals(f12CHF, f12CHF);
assertEquals(f12CHF, new Money(12, "CHF"));
assertTrue(!f12CHF.equals(f14CHF));
}
@Test public void testSimpleAdd() {

Money expected= new Money(26, "CHF");
Money result= f12CHF.add(f14CHF);
assertTrue(expected.equals(result));
}
04/02/2023 95
Fixture au niveau de la classe
• @BeforeClass
– 1 seule annotation par classe
– Evaluée une seule fois pour la classe de test, avant tout autre
initialisation @Before
– Finalement équivalent à un constructeur…
• @AfterClass
– 1 seule annotation par classe aussi
– Evaluée une seule fois une fois tous les tests passés, après le dernier
@After
– Utile pour effectivement nettoyer un environnement (fermeture
de fichier, effet de bord de manière générale)
04/02/2023 96
Aspects méthodologiques
• Coder/tester, coder/tester…
• lancer les tests aussi souvent que possible
– aussi souvent que le compilateur !
• Commencer par écrire les tests sur les parties les plus critiques
– Ecrire les tests qui ont le meilleur retour sur investissement !
– Approche Extreme Programming
• Quand on ajoute des fonctionnalités, on écrit d’abord les tests
– Test-‐Driven Development…
• Si on se retrouve à déboguer à coup de System.out.println(), il vaut mieux écrire
un test à la place
• Quand on trouve un bug, écrire un test qui le caractérise
04/02/2023 97
De l’eXtreme Programming au Test-‐Driven
Development
• Qu’est-‐ce vraiment ?
– Livrer les fonctionnalités dont le logiciel a réellement besoin, pas celles que le
programmeur croît devoir fournir !
– Une évidence a priori
• Comment ?
– Ecrire du code client comme si le code à développer existait déjà et avait été
conçu en tout point pour nous faciliter la vie !
– Le code client, ce sont les tests !
– Modifier le code pour compiler les tests
– Implémenter le code au fur et à mesure
– Refactorer le tout pour rendre les choses toujours plus simples pour soi
– Ecrire un test, ecrire du code, refactorer…
• + Principe d’intégration continue
– pendant le développement, le programme marche toujours, peut être ne fait-‐il pas
tout ce qui est requis, mais ce qu’il fait, il le fait bien !
04/02/2023 98
TP : Tests unitaires avec JUnit
04/02/2023 99
Apache Ant
04/02/2023 100
Plan
• Concept de ANT
• Avantages & inconvénients
• Fichier de configuration : Build.xml
Concept de ANT
■ Séquenceur de travaux
■ Graphe de dépendance de « cibles »
■ Remplaçant de make
■ Un des projets Jakarta/Apache

■ Ecrit en Java
■ Licence Open Source
■ Integré à de nombreux IDE java
■ Jbuilder, NetBeans Forte for Java, VisualAge for Java,
Eclipse, Jedit, …
04/02/2023 102
Avantages & inconvénients
■ Avantages
■ Portable (path, séparateurs, commandes Unix et Win32)
■ Rapide (une seule VM utilisée)
■ Très nombreuses taches déjà implémentées
■ Largement répandu et intégré aux IDE (Eclipse, …)
■ Syntaxe rigoureuse d’XML (document bien formé)
■ Inconvénients
■ Verbeux (XML oblige)
■ Pas de DTD !
■ Pas de lancement de « tâches » interactives !!

■ Dépendance de tâches (non temporelles)
■ Java-Centric tout de même !!
■ Bien que http://nant.sourceforge.net/
04/02/2023 103
Build.xml
■ Définit l’enchainement à suivre pour la construction d’un
projet
■ Un projet comporte des cibles (target)
■ Correspondant à des activités telles que la compilation,
l’installation, l’exécution, …
■ Chaque cible est composée de tâches (task)
■ exécutées en séquence (voir en //) quand la cible est exécutée
■ dépendance avec d’autres cibles
■ Ces cibles sont exécutées au préalable
■ Tâche ANT
■ Correspondent à des commandes usuelles (javac, jar, copy, …)
■ Ecrites en Java et portable quelque soit le SE
■ Built-in (fournis avec la distribution ANT) / Proprietaire
04/02/2023 104
Structure
build.xml:<project>
<?xml version="1.0" encoding="UTF-8"?>

<project basedir="." default="compile" name=" Typical ANT Build ">



</project>
04/02/2023 105
Structure build.xml:
<property>

<property name="src.dir" value="./src"/>
<property name="build.dir" value="./build"/>
<property name="doc.dir" value="./doc"/>
<property name="apidoc.dir" value="${doc.dir}/api"/>
<property file="project.properties"/>
<property environment="env"/>
<property name="lib.dir" value="${env.LIBDIR}"/>


</project>
04/02/2023 106
<path>
<path id="project.classpath">
<pathelement path="${build.dir}"/>
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
</path>

</project>
04/02/2023 107
<target>
<target name="init">
<mkdir dir="${build.dir}"/>
</target>
<target name="compile" depends="init">

<javac srcdir="${src.dir}"
destdir="${build.dir}“
classpathref="project.classpath"/>
</target>
</project>
04/02/2023 108
Lancement de Ant
■ ant [options] [target [target2 [target3] ...]]
■ Options:
-help print this message
-projecthelp print project help information
-buildfile <file> use given build file (-file, -f)
-find [<file>] search for build.xml, or file, towards the root of the filesystem
-D<property>=<value> use value for given property
-propertyfile <file> load all properties from file (with -D taking precedence)
-version print the version information and exit
-quiet be extra quiet (-q)
-verbose be extra verbose
-debug print debugging information
-emacs produce logging information without adornments
-logfile <file> write logging output to given file (-l)
-logger <classname> the class that is to perform logging
-listener <classname> add an instance of classname as a project listener
-inputhandler <class> the class that will handle input requests
04/02/2023 109
Exemples de lancement
■ ant
■ ant clean
■ ant –f build4jonas322.xml
■ ant –Dpassword=toto
■ ant -listener org.apache.tools.ant.XmlLogger
04/02/2023 110
Exemple de sortie
Z:\dev\proj1>ant compile
Buildfile: build.xml
init:
[mkdir] Created dir: Z:\dev\proj1\build
compile:
[javac] Compiling 2 source files to Z:\dev\proj1\build
[javac] Z:\dev\proj1\src\hello\Hello.java:44: cannot resolve symbol
[javac] symbol : method length ()
[javac] location: class java.lang.String[]
[javac] int len = argv.length();
[javac] ^
[javac] 1 error
BUILD FAILED
file:Z:/dev/proj1/build.xml:49: Compile failed;
see the compiler error output for details.
Total time: 6 seconds
04/02/2023 111
Ordre d’exécution des cibles
■ Exécution une et une seule fois

de A puis B puis C puis D (si ant D)
<target name="A"/>
<target name="B" depends="A"/>
<target name="C" depends="B"/>
<target name="D" depends="C,B,A"/>
■ Condition d’exécution if/unless
<target name="build.windows" if="os.is.windows"/>
<target name="build.no.windows" unless="os.is.windows"/>
04/02/2023 112
Les tâches
■ Built-in
■ Optional
■ Requière des bibliothèques Java supplémentaires ou des
outils externes (csc, vss, …)
■ Peuvent être disponibles que sur une plate-forme
particulière
■ Propriétaire
■ Ajoute pour les besoins du projet (jcrmic, apdutool …)
04/02/2023 113
Quelques tâches supplémentaires
■ Chargement de propriétés
■ LoadFile, LoadProperties, XmlProperty, EchoProperties
■ Interaction utilisateur
■ Echo, Input, Sound, Splash
■ Structures de contrôle
■ Condition, Available, Parallel, Sequential, Waitfor, Sleep, Fail, Ant,
Antcall, MacroDef, Script (JavaScript, PerlScript, VBScript, Jython ,
…)
■ Pas de boucle !
■ Compilation/Génération
■ Javac, Javah, Rmic, Style, EjbJar, Jspc, ANTLR, JavaCC, …
■ .NET (csc, vbc, jsharp,Ilasm, Ildasm, WsdlToDotnet,), …
■ Patch
■ Source code management
■ CVS, VSS, ClearCase, Perforce
04/02/2023 114
Quelques tâches supplémentaires
■ Test
■ Junit, Cactus (formally J2EEUnit)
■ Documentation
■ Javadoc, JUnit reporting, Mail / MimeMail, Stylebook,
■ Package (Emballage)
■ Jar, Manifest, SignJar, GenKey, War, Ear, …
■ Zip, BZip2, War, Tar, Cab, Rpm …
■ Exécution
■ Java, Exec, SQL
■ Déploiement
■ Copy, Move, Chmod, Mkdir, Attrib
■ Unwar, unzip, unjar, untar, …
■ Checksum
■ FTP, Telnet, Get, Scp, Sshexec
04/02/2023 115
• Implémentation de ANT
• Séquencement et automatisation des instructions.
04/02/2023 116
Automatisation des
tests d'intégration
04/02/2023 117
Plan
• Stratégies pour le test d’intégration

• Les tests d’intégration : avantages, préréquis et étapes
04/02/2023 118
Stratégies pour le test d’intégration
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.
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
04/02/2023 119
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
04/02/2023 120
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
04/02/2023 121
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
04/02/2023 122
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
04/02/2023 123
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
04/02/2023 124
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
04/02/2023 125
Ascendant contre descendant
• Avantages du descendant
• Les composants testés de plus haut niveau constituent
une maquette de l'application
• Désavantages du descendant
• Le composant utilisateur peut ne pas traiter tous les cas
du composant utilisé
• Dans le test d'un module de bas niveau il peut être
difficile
• D'imaginer les entrées de haut niveau
• De récupérer les résultats
04/02/2023 126
Intégration continue
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
04/02/2023 127
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
04/02/2023 128
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
04/02/2023 129
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
04/02/2023 130
Étape 1 : mise à jour des sources
Étape 2 : détection de la mise à jour
Étape 3 : récupération des sources
Étape 4 : construction et tests release
Étape 5 : livraison de la release
Étape 6 : publication du rapport
Outils
TP – Intégration continue
04/02/2023 138
• Concept de l’intégration continue et tests d’intégration.

• Etapes des tests d’intégration.
04/02/2023 139
Tests de validation
Plan
• Introduction
• Typologie des tests de validation
04/02/2023 141
Introduction
• Rechercher les erreurs de réalisation par rapport a la spécification
• Test boite blanche
• Graphe causes/effets ou partitions en classes d’équivalence
• + Analyse aux bornes
• + La méthode intuitive
• Taux de couverture = % couvert des spécifications
04/02/2023 142
Tests de validation
• Test du volume : tester les capacités du logiciel a gérer le
maximum du volume d'informations prévu,
• Test du "stress" : tester les capacités du logiciel a gérer les
pointes d'occupance ou les cadences maximales prévues,
04/02/2023 143
Tests de validation
• Test de l'ergonomie : l'utilisation du logiciel est-elle :
• Adaptée aux connaissances de l'utilisateur final ?
• Les sorties sont-elles compréhensibles ?
• Les messages d'erreurs sont-ils compréhensibles ?
• Les conventions, syntaxes, abréviations, styles sont-ils
uniformes dans tous les dialogues ?
• La quantité d'options est-elle excessive ?
• Toutes les entrées sont-elles acquittées aussitôt ?
• Le système est-il humainement facilement utilisable ?
04/02/2023 144
Tests de validation
• Test de sécurité
• Test de performance : test des performances spécifiées
• Test de stockage : test des débordements possibles de la
mémoire de masse,
• Test de configuration : lorsque le logiciel doit pouvoir s’exécuter
sur différents types de matériels, chaque configuration doit être
testée,
• Test de la compatibilité : lors d'une réutilisation, test des
portages,
04/02/2023 145
Tests de validation
• Test d'installation : test des procédures d'installation,
• Test de fiabilité : test des performances spécifiées en matière de
fiabilité,
• Test des fonctions de correction d'erreur,
• Test de la qualité des fonctions de maintenance,
• Test de la documentation qui peut être operée par inspection,
• Test des procédures manuelles ou automatiques de test.
04/02/2023 146
• Concept des tests de validation
• Différents aspects des test de validation.
04/02/2023 147
Recette
Plan
• Principe de la recette
• Cycle de vie du logiciel
• cahier de recette
• Cycle de vie d'une anomalie
• Suivi des anomalies
• Modèle de fiche d'anomalie
• Evaluation de la recette
• Acteurs de la recette
• Contrôles & normes
• Critères utilisés
• Indicateurs de la recette
La Recette
Définition : La recette est une suite d'opérations permettant de montrer qu'un
produit, réalisé suivant un processus industriel défini et approuvé, est conforme
aux spécifications détaillées validées par le client (vision Contrat) et répond aux
exigences d'acceptation des utilisateurs (vision Métier).
• Cette étape est de la responsabilité du client et s’effectue généralement chez lui
• Elle est en principe bornée contractuellement (délais et critères)
• Le client peut mettre à disposition du développeur un cahier de test de recette
pour détecter de manière anticipée les anomalies de recette
• Démarre à la livraison du produit.
• Se concrétise par la signature du Procès Verbal de fin de Recette
• Garantie (ou passage en TMA) : est en général déclenchée à partir de la
signature du Procès Verbal de fin de Recette
04/02/2023 151
Le cycle de vie du logiciel
Spécification
Conception
Paramétrage
Développement
Recette
Installation & Diffusion
Evolutions & Maintenance

Préparation des jeux d’essais
Recevabilité
Qualification
04/02/2023 152
Trois phases s’enchaînent
• La préparation des jeux d’essais
Conception générale des jeux d’essais
Conception détaillée des jeux d’essais
Valorisation des jeux d’essais
• La recevabilité
Contrôle de la livraison
• La qualification
Tests fonctionnels
Tests techniques
Procès verbal de recette
Période de garantie
04/02/2023 153
La conception générale
des jeux d’essais
• Identification des cas fonctionnels
• Constitution d’une matrice de découverte
• Recherche des critères de variance
• Choix de cas significatifs à retenir pour les tests
04/02/2023 154
La conception détaillée
des jeux d’essais
• Analyse fine des cas fonctionnels
• Constitution de scènes
• Détermination de l’ensemble des traitements à effectuer
• Choix des données à utiliser
• Assemblage des scènes : les scénarios
• Production des plans de tests formalisés
04/02/2023 155
La qualification fonctionnelle
• Vérification du bon et correct fonctionnement du système livré
relativement aux exigences fonctionnelles prédéfinies
• Des utilisateurs exécutent les essais dans l’ordre des plans de
tests
• Les anomalies (description de l’incident et des conditions de

l’événement) sont signalées à l’équipe de développement
04/02/2023 156
La qualification technique
• Vérification, sur l’environnement technique cible, du futur
système et des performances atteintes
• Des experts d’exploitation et du réseau effectuent des contrôles
relativement aux exigences techniques prédéfinies
• Les anomalies (description de l’incident et des conditions de

l’événement) sont signalées à l’équipe de développement
04/02/2023 157
-tests
• Contrôle de recevabilité
• Contrôles de conformité
• recette par lot
• recette par logiciel
• recette du système
• Contrôle d’intégration
• recette d’intégration
 procès verbal provisoire (de recette)
04/02/2023 158
-tests
• Contrôle de recevabilité
• Vérifications dans l’environnement réel :
• restreint, mono-établissement
• complet, mono-établissement
• complet, multi-établissement
 procès verbal définitif (de recette)
04/02/2023 159
Le cahier de recette
1 Conditions de déroulement
Environnement
Moyens
2 Procédures de contrôle
Définition des standards de référence
Plans de tests
Confection des jeux d’essais
Traitement des résultats
3 Traitement des anomalies et incidents
Procédure incident
Fiche d’anomalie
04/02/2023 160
Cycle de vie d’une anomalie
04/02/2023 161
Suivi des anomalies
• Caractéristiques d’une anomalie
• Référence du projet
• Référence anomalie
• Environnement
• Description
• Information et suivi
04/02/2023 162
Modèle de fiche d’anomalie
04/02/2023 164
Intérêt de la recette
• Pourquoi faire une recette alors que le fournisseur (la
maîtrise d’œuvre) a déjà réalisé des campagnes d'essais au
niveau unitaire et au niveau intégration?
• En fait les essais réalisés jusque-là ont été des tests que
l'on peut qualifier de « techniques ». Il importe maintenant
de réceptionner tous les livrables du projet (logiciel,
documentation et prestations associées).
• Pour cela il va falloir procéder à des tests « métiers »
réalisés par les utilisateurs du futur système afin de vérifier
que les exigences formulées par le client (la maîtrise
d'ouvrage) sont bien satisfaites avec le niveau de qualité
requis.
Accord de réceptabilité
Cet accord est consigné dans un document procès verbal de recette

signé respectivement par les parties contractantes.
Par ce document le client (maîtrise d'ouvrage) reconnaît prendre
livraison officiellement des livrables logiciels et prestations
associées objet du contrat.
Le fournisseur (maîtrise d'oeuvre) est donc déchargé de la
responsabilité de la conception et de la réalisation du système
logiciel.
C'est la concrétisation du transfert de responsabilité et de propriété
avec les conséquences financières en matière de paiement des
sommes restantes dues et c'est souvent le fait générateur du
départ de la période de garantie
Les livrables
• Bordereau de Livraison – Fiche de recevabilité
C’est l’inventaire précis et détaillé des composants (logiciels,
documentation, prestations) que le fournisseur à livré au client.
Les dossiers de tests de validation
Chaque dossier de test de validation doit contenir au moins les informations suivantes :
Des plans de tests définissant et organisant le séquencement des actions.
• La planification de ces actions.
• La liste des scénarios métier formalisés et leur ordre de passage.
Et pour chaque test :
• les fonctions à tester
• l'environnement nominal nécessaire
• les moyens nécessaires
• les conditions d'activation du test
• les jeux d'essais
• les résultats attendus
• les critères d'arrêt du test
• les dispositions à suivre en cas d'échec du test
• les mesures à effectuer.
Dans le cas de scénarios complexes les tests sont modélisés au moyen de graphes.
Des diagrammes représentent les éléments déclenchants, l'enchaînement opératoire
et les résultats.
Test du déploiement de la solution
• Les processus
• Concevoir et réaliser un produit logiciel représente une
partie importante des activités d'ingénierie. Toutefois,
lorsque le nombre de sites à installer est important, il ne
faut pas négliger de maîtriser l'installation puis la diffusion
d'un produit logiciel. La mise sous assurance qualité de ces
activités doit alors s'exercer dans le temps et dans l'espace.
Les impacts ne seront pas de la même nature pour gérer
cinq, dix ou cent sites ou plus. Par ailleurs, les activités
d'installation et de diffusion concernent non seulement la
première mise en place du système logiciel, mais elles
devront être intégralement reprises et supportées dans le
processus de maintenance
• L'installation
• Tout d'abord une installation ne peut intervenir que sur un produit
logiciel qui a fait l'objet d'une recette satisfaisante, c'est-à-dire pour
lequel il ne reste plus aucune anomalie bloquante pour les
utilisateurs. Sinon la mise en production doit être
systématiquement refusée.
• Ensuite, l'identification des éléments composant la configuration
(logiciels, données, procédures, documentation) sera réalisée. Pour
les tâches d'identification des composants on se reportera a La
gestion de configuration.
• Toutes les opérations d'une installation doivent être effectuées
sans risque d’erreurs. Une installation comporte des travaux
entièrement automatiques et des travaux manuels .
• Une planification de l'installation doit être rédigée. Elle identifie de manière

détaillée les travaux à faire, en précisant l'ordre d'enchaînement des tâches et
les affectations de responsabilités. Un mode doit expliquer les actions à
entreprendre en cas d'anomalies. Le plan d'installation du système doit être
élaboré en collaboration entre les équipes de développement et d’exploitation .
• Il doit être compatible avec l'environnement cible, conformément aux
exigences prévues au contrat. Les ressources nécessaires pour l'installer
doivent être identifiées et disponibles.
• La procédure peut être diversifiée, avec par exemple
• La procédure d'installation automatique.
• La procédure d'installation manuelle.
• Le mode d'emploi.
• L'équipe de développement assistera l'équipe d'exploitation pour la mise

en place du système.
• L’installation doit être conforme au plan d'installation. Le déroulement
et les résultats de l'installation doivent être documentés. La traçabilité
doit être assurée ainsi que l’enregistrement des références de la version
installée
• La finalité de tâche de l'installation sera obligatoirement une tâche de
vérification comme une revue d'acceptation qui permet de valider les
travaux réalisés.
• La diffusion
• L'organisation de la diffusion à mettre, en place est conditionnée par la

dispersion des sites cibles sur lesquels il est prévu d'exploiter le système
logiciel.
• Dans le cas d'un nombre restreint de sites d'installation, la diffusion va
se limiter à une duplication de la procédure d'installation sur chacun des
sites.
• La principale difficulté réside alors à gérer les montées de version pour
chaque site et à garantir l’intégrité de l'ensemble des systèmes lorsque, à
un instant donné, tous les sites ne sont pas au même niveau de version
• L’Exploitation
• Une fois que le système/logiciel est installé correctement dans
l'environnement de production d'un site, les équipes d'exploitation vont
prendre le relais des équipes de développement.
• A partir de ce moment le système/logiciel va être exploité en utilisant des
données réelles, il est mis a la disposition des utilisateurs dans le cadre de
l’exercice de leurs métiers.
• La montée en puissance peut se faire progressivement , par exemple une
agence après l'autre, une usine après l'autre, une société après l'autre .
Livrables du test du déploiement
• Les livrables
• Dossier d’installation
Il regroupe toutes les informations
nécessaire a l’installation du logiciel, La
liste des tâches ainsi que l’ordre
d’exécution , les ressources …
La Maintenance
• Les processus
• L’objectif de cette septième étape est de conserver le

système/logiciel dans un état tel qu'il pourra continuer d'être
exploité, longtemps après son installation. En fajt avec le
temps, des événements surgissent qui viennent perturber
plus ou moins gravement l'exploitation. Ces événements,
sont générateurs de modifications. Il est possible de, les
classer en deux catégories :
• Les anomalies de fonctionnement.
• Les évolutions fonctionnelles ou techniques
La Maintenance
• La gestion des anomalies
• Tout d'abord une anomalie est la manifestation d'une non-conformité
du logiciel à ses spécifications ou à ses manuels d'utilisation et
d'exploitation. C'est un incident dans le fonctionnement du logiciel qui
a été détecté. Une anomalie va engendrer deux types de maintenance :
• Maintenance corrective.
• Maintenance évolutive (impact sur la conception).
La Maintenance
• La gestion des évolutions
• Une demande d'évolution du système/logiciel représente un changement
des spécifications pour ajouter, supprimer ou modifier des fonctionnalités.
• Une évolution va engendrer deux typologies de maintenance
• Maintenance adaptative.
• Maintenance préventive.
• Le logiciel et sa documentation, tout en étant conformes, doivent prendre
en compte les évolutions de l'environnement.
• Ces évolutions seront souhaitées et négociées par les utilisateurs ou les
décideurs de l'entreprise.
• Il arrive souvent qu'elles soient aussi imposées à l'entreprise par des
contraintes extérieures qui résulteront, par exemple, d'impératifs légaux ou
réglementaires, voire de contingences commerciales dictées parles lois de la
concurrence.
La Maintenance
• L'établissement d'un constat d'anomalie ou d'une demande d'évolution
En présence d'un constat d'anomalie la demande doit être formalisée et stipuler au
moins :
• Le nom du demandeur.
• La date.
• La description complète des conditions et des résultats de non-conformités.
• En présence d'une demande d'évolution la demande doit être formalisée et stipuler
au moins :
• Le demandeur (client, utilisateur, personnel de développement ou test).
• La date
• Le but de la modification.
• Le délai d'obtention souhaité.
• La description complète du besoin et de la modification demandée.
• L'évaluation des bénéfices estimés résultant de l'amélioration.
Evaluation de la recette
• Les dossiers de conception générale de jeux d’essais sont-ils
conformes aux standards ?
• (même question pour ceux de la conception détaillée)
• Les dossiers de valorisation de jeux d’essais sont-ils conformes aux
standards ?
• Tous les éléments de configuration ont-ils été livrés ?
• Reste-il des anomalies de recette maîtrise d’ouvrage non corrigées ?
• Reste-il des corrections d’anomalies, rectifiées par la maîtrise
d’œuvre, non validées par la maîtrise d’ouvrage ?
04/02/2023 189
Evaluation de la recette (suite)
• Est-ce que les corrections font apparaître de nouvelles anomalies ?
• Les tests de non régression ont-ils été faits ?
• Les documents de conception sont-ils à jour ?
• Les documents de développement et de paramétrage sont-ils à
jour ?
• Les tests techniques ont-ils satisfait les exigences techniques ?
• Reste-il des essais complémentaires à effectuer ?
• Le procès-verbal de recette a-t-il été établi sans réserves ?
04/02/2023 190
Normes
Contrôles et essais ISO 9001 § 4.10
Maîtrise des équipements de contrôle et d’essai ISO 9001 § 4.11
Tests et validation ISO 9000-3 § 5.7
Mesures ISO 9000-4 § 6.4
Fourniture et achèvement ISO 12207 § 5.2.7
Essais de qualification du logiciel ISO 12207 § 5.3.9
Essais de qualification du système ISO 12207 § 5.3.11
Assistance à l’acceptation du logiciel ISO 12207 § 5.3.13
Processus de vérification ISO 12207 § 6.4
Vérification de l’intégration ISO 12207 § 6.4.2.6
Vérification de la documentation ISO 12207 § 6.4.2.7
Processus de validation ISO 12207 § 6.5
Processus de revue conjointe ISO 12207 § 6.6
04/02/2023 193
Pilotage de la recette par des KPIs
• La recette doit être pilotée et suivie par différents indicateurs.
• KPI: Key Performance Indicators
• Ces indicateurs permettent de suivre la qualité et efficacité des
tests réalisés.
04/02/2023 195
Pilotage de la recette par des KPIs
KPI Type Objectif
Nombre d’écarts détectés Volume <0, 1 anomalie par journée
par niveau de criticité, opérationnelle (conception,
urgence, type construction)
Nombre d’écarts détectés Efficacité des tests <10 anomalies par journée
par journée de test de tests
>3 anomalies par journée
de test
% de cas de tests exécutés Taux de couverture des 90% des cas de test choisis
% des exigences vérifiées / tests réalisés
validées 80% des exigences vérifiées
et validées.
Qualité des corrections Nombre d’écarts reouverts 0 écart réouvert après
après clôture correction
Vitesse de résolution Durée de vie moyenne des N/A
écarts par niveau de
criticité, urgence, type
04/02/2023 196
• Principe des tests de recette.
• Cycle de vie des anomalies.
• Indicateurs de pilotage des recettes.
04/02/2023 197
Maturité des processus
de tests
plan
• Introduction
• Principe du TPI
• REX de mise en œuvre d'une étude de maturité
Introduction
• ENJEUX :
Améliorer la qualité des pratiques et
des livrables des activités de test
• OBJECTIFS :
➢ Dresser un bilan objectif des pratiques de test
➢ Identifier les axes d’amélioration :

Quicks wins & Préconisations
04/02/2023 200
Qu’est-ce que TPI Next ® ?
• TPI = Test Process Improvement

• Modèle d'évaluation du niveau de maturité des processus de test :
✓ permet de dresser un état des lieux,
✓ propose des axes d’amélioration.
• Historique :
– Créé par Sogeti NL en 1998
– Next = nouvelle version de TPI® (2009)
• Cadre de référence de TPI® Next : TMAP® Next
• Le modèle est décliné sous la forme d’une matrice de questions à poser

dans le cadre d’interview
04/02/2023 201
Les principes
16 secteurs clés
Ils couvrent les activités du test selon plusieurs axes :
✓ Organisation ✓ Mise en œuvre
✓ Outils et méthodologie ✓ RH
3 niveaux de maturité
Contrôlé → « Doing the right things »
Efficient → « Doing things the right way »
Optimisé → « Continuously adapting to ever-changing circumstances »
~150 points de contrôle

Permettent de mesurer de façon objective
l’atteinte des exigences de chaque niveau.
Suggestions d’amélioration
Préconisations pour permettre l’atteinte
= questions à d’un certain niveau de maturité.
poser en entretien
04/02/2023 202
Les 16 secteurs clés
Catégorie # Secteur clé
3 Stratégie de test
5 Communication
6 Reporting
7 Gestion du processus de test
Mise 8 Estimations et planification
en 9 Métriques
œuvre 10 Gestion des anomalies
11 Gestion du patrimoine de test
14 Conception des cas de test
12 Méthodologie
Outils et
15 Outils de test
méthodo
16 Environnement de test
1 Implication des acteurs projet dans les processus de test
Degré de participation de l'équipe de test dans la
Organisation 2
gestion globale du projet
4 Fonctionnement des activités de tests (équipes et
procédures)
RH 13 Compétence de l'équipe de test
04/02/2023 203
Exemple de restitution TPI® Next
# Secteurclé Init. Contrôlé Efficient Optimisé
Implication des acteurs projet dans les
1
processus de test
Degré de participation de l'équipe de test dans
2
la gestion globale du projet
3 Stratégie de test
Fonctionnement des activités de tests (équipes
4
et procédures)
5 Communication
6 Reporting
7 Gestion du processus de test
8 Estimations et planification
9 Métriques
10 Gestion des anomalies
11 Gestion du patrimoine de test
12 Sommaire
13 Synthèse des résultats
14 Conception des cas de test
15 Outils de test
16 Environnement de test
REX de mise en œuvre
d’une étude de maturité
04/02/2023 205
Enjeux et objectifs de l’étude de
maturité
• La direction YYY d’un grand groupe de l’assurance engage une réflexion
sur la professionnalisation du métier de l’homologation.
• Organisation de la qualification dans le service :

o une équipe dédiée sur une partie du SI (réf. produit) → ~4 p.
• ENJEUX DE L’ÉTUDE DE MATURITÉ :
➢ Sécuriser les phases d’homologation du SI
➢ Harmoniser les pratiques :
– au sein de la direction YYY,
– avec un CS de qualification existant dans une autre direction
• OBJECTIFS :
✓ Dresser un état des lieux factuel des activités de qualification
✓ Identifier les axes d’amélioration
✓ Proposer un plan de mise en œuvre
04/02/2023 206
Déroulement de l’étude
• Périmètre de l’étude = 3 équipes différentes :

P1 P2 P3
SI Historique
Projet de Qualif.
Réglementaire Contrats & refonte produit
Internet
/ Transverses Prestations
• Calendrier :
Déc. 2019 Jan. 2020 Fév. 2020
Cadrage & Analyse &

Préparation Restitution
Diagnostic
5 jours 12 jours 10 jours
• Personnes interviewées ou rencontrées :
– AMO : 9 personnes
– MOE : 4 personnes
– Centre de service de qualification : 1 personne
– Utilisateurs : 2 personnes
04/02/2023 207
La démarche mise en œuvre à base de Squash +
TPI® Définition des objectifs et du périmètre de l’audit
Prise de connaissance :
Phase 1 ➢ le contexte organisationnel et fonctionnel,
➢ le cadre de référence méthodologique
Cadrage &
Préparation Adressé Préparation des interviews en constituant un questionnaire
par TPI® et une trame d’entretien adaptés au contexte du client
Analyse des processus de qualification Analyse des livrables produits

(stratégie de test, référentiel des tests,
(Rencontre des équipes chargées des tests lors tableaux de bords…)
d’interviews avec le questionnaire TPI Next®)
Maturité des process Qualité des livrables

Phase 2 4 axes d’analyse :
✓ Conformité → respect des modèles de livrables en
Méthodologie Mise en termes d’existence et de formalisme (CH).
Analyse & RH Organisation
Diagnostic & Outillage œuvre ✓ Pertinence → vérification de l'atteinte des objectifs
définis dans la méthodologie.
✓ Profil des équipes de test ✓ Pilotage opérationnel ✓ Lisibilité → évaluation de la clarté du livrable, de sa
✓ Méthodologie ✓ Respect de la méthodologie facilité d'appropriation et de compréhension.
✓ Motivation ✓ Mise en œuvre des outils
✓ Cycle de vie → respect du cycle de validation du
✓ Implication des acteurs projets ✓ Capitalisation… livrable et de la traçabilité des modifications qui lui
sont apportées.
Présentation des conclusions de l’étude et des

axes d’amélioration préconisés :
Phase 3
Rapport de l’étude :
Restitution - Constats Plan de mise en œuvre
- Cartographie du niveau de maturité
- Préconisations et recommandations
04/02/2023 208
Présentation du rapport de l’étude de maturité
➢ Démarche
➢ Déroulement de l’étude
ÉTAT DES LIEUX
➢ Synthèse des constats

➢ Bilan : cartographie du niveau de maturité
➢ Bilan : qualité des livrables Couvert
par TPI®
RECOMMANDATIONS
➢ Préconisations détaillés
PLAN DE MISE EN ŒUVRE
➢ Proposition de plan de mise en œuvre

➢ Plan d’action court terme
➢ Risques
04/02/2023 209
Exemple : bilan de la maturité des process
04/02/2023 210
REX : points forts et limites de TPI® Next
• POINTS FORTS :
• Une couverture exhaustive des process de qualification (selon TMAP)
• Un cadre d’interview structuré
• Des questions pouvant s’adapter à un large panel de profils Un
questionnaire aux vertus didactiques
• LIMITES & POINTS DE VIGILANCE :
• Modèle très riche, orienté TMAP → Adapter le questionnaire au contexte
(ex: terminologie, profils) et au cadre de référence
• Questionnaire pénible (~150 questions) → Alléger le
questionnaire ou réaliser l’interview en plusieurs fois
• Un côté intrusif → Expliquer la démarche / rassurer
• Non adapté aux projets agiles
• Ne couvre pas la qualité des livrables / la mise en œuvre
04/02/2023 211
• TPI® Next adresse la problématique de maturité sous l’angle process.
• Approche nécessaire à long terme, mais :

– Études de maturité assez lourdes
– Mise en œuvre des préconisations longue, parfois complexe (gest° du changement)
➔ROI potentiellement long

• Nécessité de compléter TPI® Next avec la vision ‘livrables’ :
✓ QUALITÉ DES LIVRABLES

Préconisations court terme / quick wins ➔ Bénéfices rapides
✓ QUALITÉ DES PROCESS

Préconisations moyen / long terme ➔ Bénéfices sur la durée
04/02/2023 212
Maturité des tests avec
TMMI/CMMI
Plan
• Introduction
• CMMi & tests
• Principe du TMMi
• Pourquoi choisir TMMi?
• En quoi consiste TMMi?
• Les 5 niveaux de TMMi
• Comment évaluer son niveau de TMMi?
• Récap : Maturité des processus de tests des organisations
Introduction
• (Integrated) Capability maturity model (CMM, CMMI)

• Software process improvement and capability determination (SPICE)
• ISO 9001, Bootstrap, …
Test Process Improvement Models:

• Test maturity model (TMM, TMMi)
• Test process improvement model (TPI)
• Test improvement model (TIM)
• Minimal Test Practice Framework (MTPF)
• …
04/02/2023 215
Le CMMI et les tests
• Le modèle CMMI couvre les tests avec 3 domaines :
• PI (Product Integration)
• VER (Verification)
• VAL (Validation)
• Le CMM formule des exigences bien compréhensibles :
1. Se préparer à la vérification/intégration/validation
• Choisir les produits à vérifier-valider
• Définir la séquence d’intégration
• Assurer la compatibilité des interfaces
• Etablir l’environnement
• Établir les procédures et critères
2. Vérifier / assembler / valider le produit ou les composants de produit
• Etablir les plans de tests
• Réaliser la vérification / intégration / validation
• Analyser les résultats
04/02/2023 216
Principe du TMMi
• Test Maturity Model integration
• un modèle pour rentabiliser une organisation de test et afficher
son niveau.
• 5 niveaux de maturité.
• Importance d’une certification du niveau de maturité pour

optimiser son ROI.
04/02/2023 217
Pourquoi choisir TMMi?
04/02/2023 219
Car il fait partie de l’« état de l’art »
Qui se caractérise par

• Des normes et standards
• Ex: IEEE 830, IEEE 829, IEEE 1028, ISO 9126, ISO 29119…
• Des organismes de définition et certification des compétences
des métiers du test
• Ex: ISTQB, CFTL, REQB
• Des ouvrages ou publications sur le test
• Des outils de test (Editeur ou Open Source)
• Des échanges sur ce qui se fait sur le terrain
• Ex: club ECUME, club Qualimétrie/Qualité Logicielle
• Des pratiques spécifiques par métier et technologie
• Des modèles d’industrialisation et d’évaluation
• Ex: TPI, CTP, STEP, CMMi et…TMMi
04/02/2023 220
Car il se distingue des autres modèles
Pour plusieurs raisons
• Il est indépendant de toute société
• Il est structuré et facilement reproductible

• Similarités par rapport à CMMi
• Il s’applique à tous les cycles de développement
• Il est disponible pour tous, ainsi que ses composants et ses résultats
04/02/2023 221
En quoi consiste le
TMMi?
04/02/2023 222
3 éléments principaux
Disponibles sur www.tmmi.org
1. TMMi : « Test Maturity Model integration » = le modèle
2. TAMAR: « TMMi Assessment Method Application Requirements » = les

exigences que doit satisfaire une méthode d’évaluation
3. DSR: « Data Submission Requirements » = les éléments à fournir à la

Fondation TMMi pour
• Valider et publier une certification officielle
• Comptabiliser la participations des évaluateurs
04/02/2023 223
des parties prenantes et des résultats
La Fondation publie la liste des organismes accrédités, des
évaluateurs et des organisations certifiées
04/02/2023 224
Les 5 niveaux de TMMi
04/02/2023 225
Les 5 niveaux TMMi
Niveau 1 : Niveau initial

•Processus chaotique,
•Pas de distinction entre debugging et phase de tests, (5) En Optimisation
•Tests conçus et réalisés après les phases de codage, Prévention des défauts
•Manque de personnel et d’outils.

Niveau 2 : Phase de définition (4) Mesuré
•Distinction entre phase de debugging et phase de Mesure du test
tests, (
•Création d’une phase spécifique aux tests,
(3) Défini
documentée et structurée, Test non-fonctionnel
•Standardisation des processus,

•Capitalisation et initialisation des principes de
(2) Géré
réutilisation. Politique et Stratégie de
test Gestion
(1)
Initial
04/02/2023 228
Les 5 niveaux TMMi
Niveau 3 : Intégration
•Intégration de la phase de tests dans le processus de
production logicielle, (5) En Optimisation
•Organisation formelle des tests, Prévention des défauts
•Objectivation des tests,

•Professionnalisation des tests. (4) Mesuré
Niveau 4 : Gestion et mesure Mesure du test
•Les tests sont un processus identifiable, qualifiable et (

mesurable,
(3) Défini
•Les cas, scenarii et jeux sont contrôlés, mis à jour et Test non-fonctionnel
enregistrés,
•Les anomalies et corrections associées sont
(2) Géré
priorisées. Politique et Stratégie de
test Gestion
(1)
Initial
04/02/2023 229
Les 5 niveaux TMMi
Niveau 5 : Optimisation
•Les coûts de tests sont identifiés, leur efficacité y est
associée, (5) En Optimisation
•Des outils de tests sont utilisés, ils sont régulièrement Prévention des défauts
évalués et maintenus,
•Les processus de tests sont audités, leur optimisation (4) Mesuré
est constante, Mesure du test
•Les automates de tests sont implémentés et (

disponibles.
(3) Défini
Test non-fonctionnel
(2) Géré
Politique et Stratégie de
test Gestion
(1)
Initial
04/02/2023 230
Comment évaluer son
niveau de TMMi?
04/02/2023 231
Méthode informelle
Sans méthode ni évaluateur agréé
04/02/2023 232
Méthode informelle
Avec une méthode et un évaluateur agréés
Level 3 Average Achievement 92%

85
3.5-Peer Reviews
%
3.4-Non-functional Testing
3.3-Test Life Cycle and Integration
3.2-Test Training Programme
3.1-Test Organisation
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
Fully Achieved Largely Achieved Partially/Not Achieved Not Applicable/Not Rateable
04/02/2023 233
Méthode informelle
Des résultats précis et exploitables pour une amélioration
Consolidated Average Achievement 94%
4.3-Advanced Reviews
4.2-Product Quality Evaluation
96% de réalisation du 4.1-Test Measurement
3.5-Peer Reviews
niveau 2 3.4-Non-functional Testing
3.3-Test Life Cycle and Integration
92% de réalisation du 3.2-Test Training Programme
niveau 3 (à l’exclustion du 3.1-Test Organisation
2.5-Test Environments
domaine de processus Test 2.4-Test Design and Execution
Non-Fonctionnel) 2.3-Test Monitoring and Control
2.2-Test Planning
2.1-Test Policy and Strategy
0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100%
04/02/2023 234
Méthode formelle
Avec une méthode, un évaluateur et un évaluateur directeur
agréés
Les résultats sont

vérifiés et le niveau
est publié par la
fondation TMMI
04/02/2023 235
La valeur ajoutée du TMMI selon votre profil
Différents intérêts
• DSI, Responsable Qualité, Directeurs de projets

1. Améliorer ses pratiques avec des objectifs précis
2. Sélectionner un Fournisseur de TRA ou Offre de test
3. Fixer des objectifs lors de la création d’une organisation en test
• SSII proposant TRA /Offres de test

1. Améliorer ses pratiques avec des objectifs précis
2. Gagner des marchés de TRA/Offre de test grâce au niveau de
maturité affiché
04/02/2023 236
Maturité des processus de tests des
organisations
TMMi : Un modèle pour rentabiliser et optimiser votre organisation de
test. Il permet d’afficher et comparer votre maturité en test avec des
organisations semblables à la vôtre, ici et ailleurs.
TPI-Next : Modèle de Sogeti (grande firme de consultation) qui consiste
en 16 domaines clés et 4 niveaux de maturité.
CTP : Est principalement un modèle léger de référence de contenu basé
sur 12 processus de tests critiques.
STEP : Est aussi un modèle de référence de contenu découpant les
phases de tests en 3 niveaux principaux (planification, acquisition,
mesure).
04/02/2023 238
• Principe de maturité des tests d’un organisme.
• Modèles et référentiels à suivre.
• Une bonne organisation et déploiement des tests permet de
fournir un point de référence et un annuaire de confiance aux
clients.
04/02/2023 239
Conclusion
Objectifs de la formation
▪ Découvrir les enjeux du test et les référentiels en vigueur
▪ Cadrer et mettre en oeuvre une démarche de test
▪ Comprendre le principe des tests unitaires et la notion de couverture
structurelle
▪ Découvrir le processus de tests d'intégration
▪ Organiser la validation fonctionnelle et faire un reporting des résultats
04/02/2023 241
Plan de la formation
1) Introduction au test logiciel
2) Stratégie & plan de tests
3) Automatisation des test unitaires
4) xUnit
5) Apache ANT
6) Automatisation des tests d'intégration
7) Tests de validation
8) Recette
9) Maturité des processus de tests
10) Maturité des tests avec TMMI/CMMI
04/02/2023 242

Support Tes

Transféré par

Informations du document

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

Support Tes

Transféré par

Droits d'auteur :

Formats disponibles

Formation

Les bugs sont nombreux et couteux pour la société possédant le

Problèmes de sécurité (Figaro 21/09/16)

Source: PAC 2016, Arnold Aumasson

Exemple de méthodes de V & V

► Complexité des comportements

Erreur dans les spécifications, la conception, ou le programme

I E E E (Standard Glossary of Software Engineering Terminology)

G. Myers (The Art of Software testing)

Edsgar W. Dijkstra. Notes on structured programming. Academic Press, 1972

Test est une activité pas très populaire

Top 4 des points d’amélioration Europe de l’ouest

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

L’analyse statique trouve des défauts (et non des défaillances)

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

Repose sur l’exécution du programme à tester

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

• Les données de test sont produites

• Test de conformité par rapport à la spécification

• La définition de l’oracle est un problème très difficile

• limite fortement certaines méthodes de test (ex : probabiliste, BN)

• Quelques cas pratiques d’oracles parfaits automatisables

• Des oracles partiels mais automatisés peuvent être utiles

1 Le programmeur ne doit pas être le testeur ...

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

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

• Une difficulté du test structurel consiste dans la définition de l’oracle de test.

• Pourquoi modifier le code déjà testé ?

• Quels types de tests ?

Niveau de détail (situation dans le cycle de vie)

Tests (structurels) unitaires

Tests système / de recette

• Le test exhaustif est en général impossible à réaliser

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

En début de projet, définition d’un Plan de Test et de Validation

PTV Phases et planning

Tests Fonctionnels Tests Exploratoires

Tests Unitaires Tests de charge

Permet d’avoir en temps réel

• Stratégie & plan de tests sont initialisés en phase de conception

• Tous les types de tests ne sont pas forcément mis en œuvre.

• Leur mise en œuvre dépend des contraintes, besoins et contenu du projet.

• Il est aussi normal qu'en début de conception, la totalité des types de

 Définir le taux de couverture de tests pour chaque

Une bonne stratégie de tests et des mauvais outils feront

➢ Quels sont les éléments qui vont guider nos choix?

Les Tests d’Intégration

Rappel définition : Test d’un système complet par rapport à sa spécification

Objectif des TV : Vérifier la conformité du logiciel avec les exigences Client

On va aussi se poser les questions suivantes :

Les Tests de performance

Rappel définition : Les tests opérationnels ont pour but de jouer

Objectif : détecter au plus tôt dans un contexte « réaliste »

L’objectif des tests doit être défini avec le client.

+ Campagne: planification des tests. Une campagne est composée de un

+ Scenario : ensemble de tests à réaliser. Un scénario est composé de un

• Validation du fonctionnement • Le développeur

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

• Permet de représenter n’importe quel algorithme

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

• Les arcs représentent la possibilité de transfert de l’exécution d’un nœud à un

• Définition x0 a x >0