Upload
bilel-abed
View
1.243
Download
7
Embed Size (px)
DESCRIPTION
Présentation 2ITMW Test statique Test dynamique
Citation preview
1
Test de Logiciels
Realisé par:Bilel Abed
Encadrée par:Mme Asma Sallemi
2
PLAN
Types de tests2.
Test statique3.
Test dynamique4.
Conclusion5.
Introduction1.1.
3
Pourquoi vérifier et valider?
Pour éviter les bugscoû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
4
Pourquoi vérifier et valider?Pour assurer la qualité
• réponse aux besoins des utilisateursCapacité fonctionnelle
• prise en main et robustesseFacilité d'utilisation
• tolérance aux pannesFiabilité • temps de réponse, débit, fluidité...Performance • facilité à corriger ou transformer le logicielMaintenabilité
• aptitude à fonctionner dans un environnement différent de celui prévuPortabilité
5
Méthodes de vérification et validation
assurer que le système fonctionne correctement
Preuve formelle de propriétés sur un modèle du système Vérifica
tion
assurer que le système fonctionne selon les attentes de l'utilisateur
Assurance d'un certain niveau de confiance dans le système Validatio
n
« Are we building the right product ? »
model-checking Preuve
Test
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)
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 techniqueModel-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é
8
DefinitionsTester 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
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
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
11
Types de testsStratégie (cycle de vie)
Accessibilité
Critère d'évaluation (qualité du logiciel)
Système
Intégration
Unitaire
Boîte noire Boîte Blanche
Conformité
Robustesse
Performance
Sécurité
12
Cycle de vie du logiciel
Spécification
Conceptiongénérale
Conceptiondétaillée
Réalisation
Tests unitaires
Tests d'intégration
Tests système
Cycle en V
13
Etapes et hiérarchisation des testsTest fonctionnel - boîte noireIndépendant de l’implémentationPlanifier à partir de la spécification fonctionnelleRéutilisablesTest structurel - boîte blancheDépend de l implémentationLes données de test sont produites à partir d’une analyse du code source
Test de logiciel
Teststructurel
Tests unitaires Tests d ’intégration
Testfonctionnel
Tests système
14
Test de conformité
But : Assurer que le système présente les fonctionnalités attendues parl'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 selonleurs spécifications
Exemple: Service de paiement en ligneScénarios avec transaction acceptée/refusée, couverture desdifférents cas et cas d'erreur prévus
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 ligneLogin dépassant la taille du buffer Coupure réseau pendant la transaction
16
Test de sécurité
But : Assurer que le système ne possède pas de vulnérabilitéspermettant 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 ligneEssayer d'utiliser les données d'un autre utilisateurFaire passer la transaction pour terminée sans avoir payé
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
18
Test de non régression Un type de test transversal
But : Assurer que les corrections et les évolutions du code n'ont pasintroduit de nouveaux défauts
Méthode : À chaque ajout ou modification de fonctionnalité, rejouerles tests pour cette fonctionnalité, puis pour celles qui en dépendent,puis les tests des niveaux supérieurs
Lourd mais indispensableAutomatisable en grande partie
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éthodiqueun 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é
20
Test statiqueExemple: vérification de la clarté procédurale
R1 :Détermination des paramètres globauxet de leur impact sur les fonctions propres
Program :recherche_rec;const
max_elt = 50;choix1 = 1;choix2 = 2;fin = 3;
typeTliste = array[1..max_elt] of integer;
varliste : Tliste;taille, choix, val : integer;complex : integer;
But du programme non exprimé
Manque de commentaires
Identificateurs non explicites
21
Test statiqueExemple: 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 Lla valeur recherchéeindice gaucheindice droit
résultat : complexité de la recherche }
function rech_rec(L : Tliste ; val, g, d : integer) : integer ;
Interface Spécifiée
Interface implanté
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 logicielF : D -> Sorties
Le problème du test dynamique est :
D -----> Sorties
DEUX REGLES :
Conserver les tests déjà écrits
Conserver les réponses correctes correspondantes
F=P?
23
Test dynamique structurel“Testing can prove the presence of bugs, but
never their absence” (Dijkstra)
Le test structurel: abstraire pourobtenir un critère formel
C
l1 l2Si C alors l1Sinon l2
24
Test unitaire structurelGraphe 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édicatBloc élémentaire : séquence maximale d’instructions séquentielles
Arcs :enchaînement d’exécution possibles entre deux sommets
25
Test unitaire structurelExemple : PGCD de 2 nombresPrécondition: p et q entiers naturels positifs lus au clavierEffet : result = pgcd(p, q)En pseudo-langagepgcd: integer islocal p,q : integer;do
read(p, q)while p<> q do
if p > qthen p := p-qelse q:= q-pend -- if
end -- whileresult:=p
end-- pgcd
B1
B1
E
P1
P1
P2P2
B2B2B3 B3
P=q
B4
SB4
P>q P<=q
P<>q
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 calculableE 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
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
28
Test unitaire structurel
B1
E
P1
P2
B2 B3
P=q
B4
S
P>q P<=q
P<>q
Tous les noeuds:(E, B1, P1, P2, B2, P1, B4, S)(E, B1, P1, P2, B3, P1, B4, S)Tous les arcs : idemTous les chemins élémentaires (1-chemin) :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 ?
29
Test unitaire structurelAspects données
Couverture desprédicats
if then imbriqués
Couverture desdépendances
entre variablesFlot de données
Couverture desdomainesd’entréePertinence desdonnées
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 GCune 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.
31
Test unitaire structurelExemple : PGCD de 2 nombresPrécondition: p et q entiers naturels positifs lus au clavierEffet : result = pgcd(p, q)En pseudo-langagepgcd: integer islocal p,q : integer;do
read(p, q)while p<> q do
if p > qthen p := p-qelse q:= q-pend -- if
end -- whileresult:=p
end-- pgcd
B1
B1
E
P1
P1
P2P2
B2B2B3 B3
P=q
B4
SB4
P>q P<=q
P<>qDef(p) Def(q)
Def(p)
Puse(p) Puse(q)
Puse(p)
Puse(p) Puse(q)Puse(p)
Def(p) Cuse(q) Cuse(p)
Cuse(p)
Def(q) Cuse(p) Cuse(q)
Cuse(p)
Cuse(p)
Cuse(p)
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)
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.
34
Test d’intégration
D
S
T
Driver
Stub
Composant testé
Composant sous test
Interface sous test
Interface testé
D
35
Test d’intégration
T
D D DD
T T T
D D D
Bottom-up
36
Test d’intégrationBottom-up
37
Test d’intégrationBottom-up
38
Test d’intégrationTop-down
39
Test d’intégrationTop-down
40
Test d’intégrationTop-down
41
Test d’intégrationTop-down
42
Conclusion
Facteurs de bonne testabilité :Précision, complétude, traçabilité des documentsArchitecture simple et modulairePolitique 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éralExplosion combinatoire : Le test n’examine qu’un nombre fini (ou très petit) d’exécutionsImpossibilité d’une automatisation complète satisfaisante