Présentation 2ITMW Test statique Test dynamique

1. Test de Logiciels
Realisé par:
Bilel Abed
Encadrée par:
Mme Asma Sallemi
1

2. PLAN
1.
Introduction
2.
Types de tests
3.
Test statique
4.
Test dynamique
5.
Conclusion
2

3. Pourquoi vérifier et valider?
Pour éviter les bugs
coût de la correction des bugs
phase d'implantation
phase d'intégration (bug de
conception)
en phase de recette (bug de
spécification)
phase d'exploitation
3

4. Pourquoi vérifier et valider?
Pour assurer la qualité
Capacité fonctionnelle
Facilité d'utilisation
Fiabilité
Performance
Maintenabilité
Portabilité
• réponse aux besoins des utilisateurs
• prise en main et robustesse
• tolérance aux pannes
• temps de réponse, débit, fluidité...
• facilité à corriger ou transformer le logiciel
• aptitude à fonctionner dans un environnement différent
de celui prévu
4

5. Méthodes de vérification et validation
« Are we building the right product ? »
Vérification
Validation
assurer que le
système fonctionne
correctement
assurer que le
système fonctionne
selon les attentes de
l'utilisateur
Preuve formelle de
propriétés sur un
modèle du système
Assurance d'un
certain niveau de
confiance dans le
système
model-checking
Preuve
Test
5

6. Comparaison des méthodes de V&V
Test :
✔ Nécessaire : exécution du système réel, découverte d'erreurs à tous les niveaux
(spécification, conception, implantation)
✗ Pas suffisant : exhaustivité impossible
Preuve :
✔ Exhaustif
✗ Mise en oeuvre difficile, limitation de taille
Model-checking :
✔ Exhaustif, partiellement automatique
✗ Mise en oeuvre moyennement difficile (modèles formels, logique)
6

7. Comparaison des méthodes de V&V
Méthodes complémentaires :
 Test non exhaustif mais facile à mettre en oeuvre
 Preuve exhaustive mais très technique
Model-checking exhaustif et moins technique que la preuve
Mais :
Preuve et model-checking limités par la taille du système et vérifient des
propriétés sur un modèle du système (distance entre le modèle et le système réel ?)
Test repose sur l'exécution du système réel, quelles que soient sa taille et sa
complexité
7

8. Definitions
Tester un logiciel consiste à l’exécuter en ayant la totale maîtrise des données
qui lui sont fournies en entrée (jeux de test) tout en vérifiant que son
comportement est celui attendu
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)
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)
Le test est une technique de contrôle consistant à s’assurer, au moyen de son
exécution, que le comportement d’un programme est conforme à des données
8

9. Bug?
Anomalie (fonctionnement) : différence entre comportement attendu et
comportement observé
Défaut (interne) : élément ou absence d'élément dans le logiciel
entraînant une anomalie
Erreur (programmation, conception) : comportement du programmeur
ou du concepteur conduisant à un défaut
Anomalie
Défaut
Erreur
9

10. Processus de test
1.Choisir les comportements à tester (objectifs de test)
2. Choisir des données de test permettant de déclencher ces comportements &
décrire le résultat attendu pour ces données
3. Exécuter les cas de test sur le système + collecter les résultats
4. Comparer les résultats obtenus aux résultats attendus pour établir un verdict
sélection
• Spécifica
_tion,
génération
• Objectif
de test
exécution
• Cas de
test
oracle
• Résultats
.verdict
des tests
• Résultats
attendus
10

11. Types de tests
Stratégie (cycle de vie)
Système
Intégration
Unitaire
Boîte noire
Conformité
Boîte Blanche
Accessibilité
Robustesse
Performance
Sécurité
Critère d'évaluation
(qualité du logiciel)
11

12. Cycle de vie du logiciel
Cycle en V
12

13. Etapes et hiérarchisation des tests
Test fonctionnel - boîte noire
Indépendant de l’implémentation
Planifier à partir de la spécification fonctionnelle
Réutilisables
Test structurel - boîte blanche
Dépend de l implémentation
Les données de test sont produites à partir d’une analyse du code source
13

14. Test de conformité
But : Assurer
que le système
présente les
fonctionnalités
attendues par
l'utilisateur
Méthode : Sélection des
tests à partir de la
spécification, de façon à
contrôler que toutes les
fonctionnalités spécifiées
sont implantées selon
leurs spécifications
Exemple: Service de
paiement en ligne
Scénarios avec
transaction
acceptée/refusée,
couverture des
différents cas et cas
d'erreur prévus
14

15. Test de robustesse
But : Assurer
que le système
supporte les
utilisations
imprévues
Méthode : Sélection des
tests en dehors des
comportements spécifiés
(entrées hors domaine,
utilisation incorrecte de
l'interface,
environnement dégradé...)
Exemple: Service de
paiement en ligne
Login dépassant la
taille du buffer
 Coupure réseau
pendant la
transaction
15

16. Test de sécurité
But : Assurer que
le système ne
possède pas de
vulnérabilités
permettant une
attaque de
l'extérieur
Méthode : Simulation
d'attaques pour découvrir
les faiblesses du système
qui permettraient de
porter atteinte à son
intégrité
Exemple: Service de
paiement en ligne
Essayer d'utiliser
les données d'un
autre utilisateur
Faire passer la
transaction pour
terminée sans avoir
payé
16

17. Test de performance
But : Assurer que le
système garde des
temps de réponse
satisfaisants à
différents niveaux
de charge
Méthode : Simulation à
différents niveaux de
charge d'utilisateurs
pour mesurer les temps
de réponse du système,
l'utilisation des
ressources...
Exemple: Service
de paiement en
ligne
 Lancer plusieurs
centaines puis
milliers de
transactions en
même temps
17

18. Test de non régression
Un type de test transversal
But : Assurer que
les corrections et
les évolutions du
code n'ont pas
introduit de
nouveaux défauts
Méthode : À chaque
ajout ou modification de
fonctionnalité, rejouer
les tests pour cette
fonctionnalité, puis pour
celles qui en dépendent,
puis les tests des
niveaux supérieurs
Lourd mais
indispensable
Automatisable
en grande partie
18

19. Techniques de « test statique »
Définition : ne requiert pas l ’exécution du logiciel sous test sur des données
réelles
Efficacité : plus de 50 % de l ’ensemble des fautes d ’un projet sont détectées
lors des inspections si il y en a (en moyenne plus de 75%)
Défaut : mise en place lourde, nécessité de lien transversaux entre équipes,
risques de tension…tâche plutôt fastidieuse
Règles
être méthodique
un critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait(R1)
un second critère : les algorithmes/l’architecture de contrôle apparaît-elle
clairement ?(R2)
décortiquer chaque algorithme et noter toute redondance curieuse et toute
discontinuité
19

20. Test statique
Exemple: vérification de la clarté procédurale
R1 :Détermination des paramètres globaux
et de leur impact sur les fonctions propres
Program :recherche_rec;
const
max_elt = 50;
choix1 = 1;
choix2 = 2;
fin = 3;
type
Tliste = array[1..max_elt] of
integer;
var
liste : Tliste;
taille, choix, val : integer;
complex : integer;
But du
programme non
exprimé
Manque de
commentaires
Identificateurs
non explicites
20

21. Test statique
Exemple: vérification de la clarté
R2 : Existence d’un entête clair pour chaque fonction
{-------------------------------------------------------------------Recherche récursive d'une valeur dans une liste triée
--------------------------------------------------------------------}
{ paramètres d'entrée :
liste L
la valeur recherchée
indice gauche
indice droit
résultat : complexité de la recherche }
Interface Spécifiée
Interface implanté
function rech_rec(L : Tliste ; val, g, d : integer) : integer ;
21

22. Techniques de « test dynamique »
 DT : Donnée de Test = une (séquence) d’entrée(s)
JT = {DT}
 D = domaine d’entrée du programme P sous test
 Soient F, les fonctions spécifiées du logiciel
F : D -> Sorties
Le problème du test dynamique est :
F=P?
D -----> Sorties
DEUX REGLES :
Conserver les tests déjà écrits
Conserver les réponses correctes correspondantes
22

23. Test dynamique structurel
“Testing can prove the presence of bugs, but
never their absence” (Dijkstra)
Le test structurel: abstraire pour
obtenir un critère formel
C
Si C alors l1
Sinon l2
l1
l2
23

24. Test unitaire structurel
Graphe de Contrôle (langages procéduraux/actionnels)
 But : représenter tous les chemins d’exécution potentiels
 Graphe orienté : avec un noeud d’entrée E et un noeud de sortie S
(noeud fictif ajouté si plusieurs sorties)
Sommets :
blocs élémentaires du programme, ou prédicats des conditionnelles
/boucles, ou noeuds de jonction “vide” associé à un noeud prédicat
Bloc élémentaire : séquence maximale d’instructions séquentielles
Arcs :enchaînement d’exécution possibles entre deux sommets
24

25. Test unitaire structurel
Exemple : PGCD de 2 nombres
Précondition: p et q entiers
naturels positifs lus au clavier
Effet : result = pgcd(p, q)
En pseudo-langage
pgcd: integer is
local p,q : integer;
do
read(p, q) B1
while p<> q do P1
P2
if p > q
then p := p-q B2
else q:= q-p B3
end -- if
end -- while
result:=p B4
end-- pgcd
E
B1
P1
P=q
P<>q
P2
P>q
B4
B2
P<=q
B3
S
25

26. Test unitaire structurel
Chemins : suite d’arcs rencontrés dans le graphe, en partant de E et finissant en S.
en général représenté sans perte d’information par une liste de sommets
 Prédicat de chemin : conjonction des prédicats (ou de leur négation) rencontrés
le long du chemin.
Pas toujours calculable
E B1 P1 P2 B2 S : p1=q1 & p0 > q0 (pi = ième valeur de p)
E B1 P1 P2 B3 S : p1=q1 & p0 <= q0 (pi = ième valeur de p)
E B1 P1 (P2 B2)n S : pn=qn & (pi > qi i ∈ [0..n])
Chemins infaisables : problème en général indécidable
26

27. Test unitaire structurel
Sélection des tests fondés sur le flot de contrôle
Couverture des instructions : chaque bloc doit être exécuté au moins une fois
 Couverture des arcs ou enchaînements
 tous les chemins élémentaires ou 1-chemins
tous les i-chemins : de 0 à i passages dans les boucles
tous les chemins : si boucles, potentiellement infinis
27

28. Test unitaire structurel
E
B1
P1
P=q
P<>q
P2
P>q
B4
S
B2
P<=q
B3
Tous les noeuds:
(E, B1, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B3, P1, B4, S)
Tous les arcs : idem
Tous les chemins élémentaires (1chemin) :
idem + (E, B1, P1, B4, S)
Tous les 2-chemins :
idem +
(E, B1, P1, P2, B2, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B2, P1, P2, B3, P1, B4, S)
(E, B1, P1, P2, B3, P1, P2, B2, P1, B4, S)
(E, B1, P1, P2, B3, P1, P2, B3, P1, B4, S)
Questions : qu’est-ce que ne capture pas ce modèle ?
28

29. Test unitaire structurel
Couverture des
prédicats
Aspects données
if then imbriqués
Couverture des
dépendances
entre variables
Flot de données
Couverture des
domaines
d’entrée
Pertinence des
données
29

30. Test unitaire structurel
Graphe de Flot de Données
 But : représenter les dépendances entre les données du programme
dans le flot d’exécution.
 Graphe de contrôle décoré d’informations sur les données (variables)
du programme.
Sommets :idem GC
une définition (= affectation) d’une variable v est notée def(v)
une utilisation d’une variable est v notée P_use(v) dans un
prédicat et C_use(v) dans un calcul.
30

31. Test unitaire structurel
Exemple : PGCD de 2 nombres
Précondition: p et q entiers
naturels positifs lus au clavier
Effet : result = pgcd(p, q)
En pseudo-langage
pgcd: integer is
local p,q : integer;
do
P=q
read(p, q) B1 Def(p)
Def(q)
while p<> q do P1 Puse(p) Puse(q)
P2 Puse(p) Puse(q)
if p > q
Def(p)
Cuse(q) then p := p-q B2 Cuse(p)
Def(q)
Cuse(p) else q:= q-p B3 Cuse(q)
B4
end -- if
Cuse(p)
end -- while
result:=p B4 Cuse(p)
S
end-- pgcd
E
B1
P1
Def(p)
Puse(p)
P<>q
P2
P>q
Puse(p)
P<=q
B2
B3
Cuse(p)
Cuse(p)
31

32. Test d’intégration
But : vérifier les interactions entre composants (se base sur
l’architecture de conception
Difficultés principales de l’intégration
interfaces floues
implantation non conforme au modèle architectural (dépendances
entre composants non spécifiées)
réutilisation de composants (risque d’utilisation hors domaine)
32

33. Test d’intégration
Stratégies possibles (si architecture sans cycles)
big-bang : tout est testé ensemble. Peu recommandé !
top-down : de haut en bas. Peu courant. Ecriture uniquement de
drivers de tests.
bottom-up : la plus classique. On intègre depuis les feuilles.
33

34. Test d’intégration
D
Driver
S
Stub
T
D
Composant testé
Composant sous test
Interface sous test
Interface testé
34

35. Test d’intégration
Bottom-up
D
D
D
D
D
D
D
T
T
T
T
35

36. Test d’intégration
Bottom-up
36

37. Test d’intégration
Bottom-up
37

38. Test d’intégration
Top-down
38

39. Test d’intégration
Top-down
39

40. Test d’intégration
Top-down
40

41. Test d’intégration
Top-down
41

42. Conclusion
Facteurs de bonne testabilité :
Précision, complétude, traçabilité des documents
Architecture simple et modulaire
Politique de traitements des erreurs clairement définie
Facteurs de mauvaise testabilité :
Fortes contraintes d’efficacité (espace mémoire, temps)
Architecture mal définie
Difficultés du test :
Indécidabilité : une propriété indécidable est une propriété
qu’on ne pourra jamais prouver dans le cas général
Explosion combinatoire : Le test n’examine qu’un nombre
fini (ou très petit) d’exécutions
Impossibilité d’une automatisation complète satisfaisante
42