Test de logiciels

4 544 vues

Publié le

Présentation 2ITMW
Test statique
Test dynamique

Publié dans : Formation
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
4 544
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
263
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Test de logiciels

  1. 1. Test de Logiciels Realisé par: Bilel Abed Encadrée par: Mme Asma Sallemi 1
  2. 2. PLAN 1. Introduction 2. Types de tests 3. Test statique 4. Test dynamique 5. Conclusion 2
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Cycle de vie du logiciel Cycle en V 12
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 34. Test d’intégration D Driver S Stub T D Composant testé Composant sous test Interface sous test Interface testé 34
  35. 35. Test d’intégration Bottom-up D D D D D D D T T T T 35
  36. 36. Test d’intégration Bottom-up 36
  37. 37. Test d’intégration Bottom-up 37
  38. 38. Test d’intégration Top-down 38
  39. 39. Test d’intégration Top-down 39
  40. 40. Test d’intégration Top-down 40
  41. 41. Test d’intégration Top-down 41
  42. 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

×