1 / 105

Le test de logiciel

Le test de logiciel. Yves Le Traon Yves.letraon@francetelecom.com Benoit Baudry bbaudry@irisa.fr. Objectifs du cours. Test de composants « unitaires » classes ou {classes} Assemblage de composants Le problème du test d’intégration

andrew
Download Presentation

Le test de logiciel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Le test de logiciel Yves Le Traon Yves.letraon@francetelecom.com Benoit Baudry bbaudry@irisa.fr

  2. Objectifs du cours • Test de composants « unitaires » • classes ou {classes} • Assemblage de composants • Le problème du test d’intégration • Test d’un composant depuis ses exigences ou ses cas d’utilisation – test « système »

  3. Objectifs du cours • À chaque étape, une technologie (outillée) est choisie • Un ou plusieurs exemples sont traités en TD et en TP • La notion de « contrat » est importante • Pré/post conditions • Langage prédominant : Java

  4. Plan • Problématique du test • Rappels test de logiciel • Test de composants unitaires OO • Test d'intégration • Test système • Diagnostic

  5. Problématique du test • On ne peut pas tester tout le temps ni tous les cas possibles • Il faut des critères pour choisir les cas intéressants et la bonne échelle pour le test • Prouver l’absence d’erreurs dans un programme est un problème indécidable • il faut des heuristiques réalistes

  6. Problématique du test Le coût du test dans le développement analyse des besoins Implém. spécification Spécif. Test An. b Implémentation test + maintenance = 80 % du coût global de développement !!!

  7. Problématique: une définition ! conformité du produit par rapport à sa spécification La validation Vérification/preuve tests

  8. Problématique du test Pourquoi ? Coût Effort Confiance

  9. Vocabulaire Testabilité faute bogue erreur Fiabilité (Reliability) défaillance Test de Robustesse Test statique Test de non-régression Tolérance aux fautes Séquence de test Données de test Sûreté de fonctionnement (Dependability) Jeu de test Test statistique Cas de test

  10. Défaillances • Catastrophe humaine ou financière: • Automobile (2004) – régulateur de vitesse • Therac-25 (1985-1987) – radiologie et contrôle d'injection de substances radioactives • London Ambulance System (1992) – central et dispatch ambulances • Iran Air Flight 655 (1988) – guerre d'Irak et missile américain – système radar • Ariane 5 (1996) • SI du FBI (2005) – SI qui n'a pas pu être déployé • Mars Climate Orbiter (1999) – kilos – pounds • Bourse de Londres (Taurus, 1993) – SI qui n'a pas pu être déployé • Image de marque : • FT et Bouygues en 2004 – crash des serveurs – indisponibilité 48h • Succès financier: Windows • Sans conséquence mais énervant : bogue Irisa

  11. Dues à des bugs • USS Yorktown (1998) • Une division par zéro coupe les moteurs • Ariane 5 (1996) • Mauvaise réutilisation • Mars orbiter (1999) • Plusieurs unités de mesure • Système de guidage (2002) • Initialisation erronée • The Patriot and the Scud • mauvais arrondi dans une soustraction

  12. Dues au processus • Therac-25 (official report) • The software code was not independently reviewed. • The software design was not documented with enough detail to support reliability modelling. • The system documentation did not adequately explain error codes. • AECL personnel were at first dismissive of complaints. • The design did not have any hardware interlocks to prevent the electron-beam from operating in its high-energy mode without the target in place. • Software from older models had been reused without properly considering the hardware differences. • The software assumed that sensors always worked correctly, since there was no way to verify them. (see open loop) • Arithmetic overflows could cause the software to bypass safety checks. • The software was written in assembly language. While this was more common at the time than it is today, assembly language is harder to debug than high-level languages. • ….

  13. Processus (cf. IEEE Spectrum 09/2005) • Système d’information du FBI • abandonné en avril 2005 : coût 170 M $ • mauvaise spécification, exigences mal exprimées • réutilisation dans un contexte inadapté • trop d’acteurs concurrents (hommes politiques, agents secrets, informaticiens)

  14. Problématique du test • Un jeune diplômé sur trois commence par faire du test • 50% des start-up échouent à cause du trop grand nombre de bugs • mauvaise campagne de test • maintenance difficile • pas de non régression

  15. 2- Rappels test de logiciel 2.1. Le test : quoi et comment 2.2. Etapes et processus de test 2.3. Génération de test

  16. 2- Rappels test de logiciel 2.1. Le test: quoi et comment 2.2. Etapes et processus de test 2.3. Génération de test

  17. Apprendre • pourquoi c’est fait • ce que ça doit faire • comment c’est fait • comment ça marche • modéliser • s’en faire une idée • exécuter • analyser • qu’est ce qui devrait marcher? • identifier une erreur • diagnostiquer une erreur • catégoriser ces erreurs • Qu’y a-t-il à voir? • Que faut-il regarder? • Qu’est-ce qui est visible? • Qu’est ce qu’on cherche? • Comment le regarder? Le test Essayer pour voir si ça marche.

  18. Qu’est-ce qu’on teste?(quelles propriétés?) • fonctionnalité • sécurité / intégrité • utilisabilité • cohérence • maintenabilité • efficacité • robustesse • sûreté de fonctionnement

  19. Comment on teste? • Test statique • relecture / revue de code • analyse automatique (vérification de propriétés, règles de codage... • Test dynamique • on exécute le programme avec des valeurs en entrée et on observe le comportement

  20. Avec quoi on teste? • Une spécification: exprime ce qu’on attend du système • un cahier des charges (en langue naturelle) • commentaires dans le code • contrats sur les opérations (à la Eiffel) • un modèle UML • une spécification formelle (automate, modèle B...)

  21. Exemple Comment tester la classe StringList? • tester l’ajout dans une liste vide • tester l’ajout dans une liste avec un élément • tester le retrait dans une liste avec deux éléments • .... Comment écrire ces tests? Comment les exécuter? Les tests sont-ils bons? Est-ce que c’est assez testé? ...

  22. Test Résultat attendu Résultat Comparer différent égal Test passe Test échoue Test de logiciel décrit Programme Spécification implante

  23. 2- Rappels test de logiciel 2.1. Le test : quoi et comment 2.2. Etapes et processus de test 2.3. Génération de test

  24. Test de logiciel • Plusieurs échelles: • Unitaire, intégration, système • Plusieurs techniques • Dynamique / statique • Génération de test • Fonctionnel / structurel

  25. Cycle de vie en V (normalisé AFNOR) Analyse Validation • Expression du besoin • Validation • Analyse détaillée • Mise en œuvre Conception Intégration • Etude technique préalable • Intégration • Conception préliminaire • Tests d'Intégration • Conception détaillée Réalisation • Codage • Mise au point • Tests unitaires

  26. Problème Intégration Composants unitaires Définition des besoins Conception globale programme Hiérarchisation des tests Maintenance Programme livrable analyse des besoins Test de recette (avec client) Plan de test système (fonctionnel) Système Tests systèmes Cahier des charges Plan de test d’intégration Tests d ’intégration ? Tests unitaires Conception détaillée implémentation le cycle en « V »

  27. Analyse détaillée Analyse préliminaire « (de risque) » Conception V1 V2 Réalisation Validation Intégration Cycle de vie en « spirale » Synergie avec approche par objets

  28. Test unitaire • Validation d’un module indépendamment des autres • Valider intensivement les fonctions unitaires • Les unités sont-elles suffisamment spécifiées? • le code est-il lisible, maintenable...?

  29. Test unitaire • Pour un langage procédural • unité de test = procédure • Dans un contexte orienté objet • unité de test = classe void Ouvrir (char *nom, Compte *C, float S, float D ) { C->titulaire = AlloueEtCopieNomTitulaire(nom); (*C).montant = S ; (*C).seuil = D ; (*C).etat = DEJA_OUVERT ; (*C).histoire.nbop = 0; EnregistrerOperation(C); EcrireTexte("Ouverture du compte numero "); EcrireEntier(NumeroCourant+1); EcrireTexte(", titulaire : \""); EcrireTexte(C->titulaire); EcrireCar('"'); ALaLigne(); }

  30. Test d’intégration • Choisir un ordre pour intégrer et tester les différents modules du système

  31. Test d’intégration Cas simple: il n’y a pas de cycle dans les dépendances entre modules Les dépendances forment un arbre et on peut intégrer simplement de bas en haut

  32. E_RETRY ONCE_PROCEDURE ONCE_FUNCTION E_CHECK NATIVE_C DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_SMALL_EIFFEL NATIVE_JVM IFTHENELSE IFTHEN INSTRUCTION +then_compound ONCE_ROUTINE PROCEDURE FUNCTION EXTERNAL_FUNCTION EXTERNAL_PROCEDURE COMPOUND E_DEBUG E_LOOP NATIVE EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINE +native WRITABLE_ATTRIBUTE CST_ATT E_INSPECT WHEN_LIST E_WHEN WHEN_ITEM LOCAL_VAR_LIST ATTRIBUTE ROUTINE REVERSE_ASSIGNMENT EXPRESSION WHEN_ITEM_1 CREATION_CALL PROC_CALL ASSIGNMENT +call +type E_FEATURE DECLARATION + is_deferred : Boolean = initval TYPE DECLARATION_LIST FORMAL_ARG_LIST + count : Integer +result_type EXPRESSION CALL_PROC_CALL GLOBALS 1 1 +writable 1 1 DECLARATION_GROUP DECLARATION_1 +target 0..* 0..* +arguments +list FEATURE_CLAUSE SMALLEIFFEL + magic_count : Integer LOCAL_NAME ARGUMENT_NAME +list + is_ready : Boolean TYPE +result_type + load_class() + get_started() +clients TYPE +name_list +to_runnable + falling_down() CALL +clients +result_type + afd_check() CLIENT_LIST +name FEATURE_CLAUSE_LIST LOCAL_ARGUMENT FEATURE_NAME CLASS_NAME +list + is_frozen : Boolean CLASS_NAME +feature_clause_list +base_class_dictionary +names +base_class +base_class CREATION_CLAUSE FEATURE_NAME_LIST NAME BASE_CLASS +procedure_list + path : String + is_manifest_string : Boolean +list + is_deferred : Boolean + is_result : Boolean + is_expanded : Boolean + is_void : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean CREATION_CLAUSE_LIST FEATURE_NAME EXPRESSION +origin_base_class +creation_clause_list +base_class +base_class +base_class EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST (from InheritanceClause) (from InheritanceClause) SIMPLE_FEATURE_NAME FROZEN_FEATURE_NAME INFIX_NAME PREFIX_NAME +export_list +rename_list +undefine_list +parent_list PARENT_LIST +redefine_list +current_type (from InheritanceClause) PARENT +select_list (from InheritanceClause) TYPE FORMAL_GENERIC_ARG / path : String + constrained : boolean +constraint + rank : Integer +generic_list +list FORMAL_GENERIC_LIST +formal_generic_list TYPE_CHARACTER +formal_generic_list TYPE_GENERIC TYPE_FORMAL_GENERIC (from TYPE) (from TYPE) TYPE_ANY TYPE_NONE TYPE_POINTER TYPE_CLASS (from TYPE) Test d’intégration Cas plus complexe: il y a des cycles dans les dépendances entre modules Cas très fréquent dans les systèmes à objets Il faut des heuristiques pour trouver un ordre d’intégration

  33. Test système • Valider la globalité du système • Les fonctions offertes • A partir de l’interface

  34. Test de non régression • Consiste à vérifier que des modifications apportées au logiciel n’ont pas introduit de nouvelle erreur • vérifier que ce qui marchait marche encore • Dans la phase de maintenance du logiciel • Après refactoring, ajout/suppression de fonctionnalités • Après la correction d’une faute

  35. Etapes et hiérarchisation des tests Test structurel Tests unitaires Tests d ’intégration Tests système Test fonctionnel

  36. 2- Rappels test de logiciel 2.1. Le test : quoi et comment 2.2. Etapes et processus de test 2.3. Génération de test

  37. Génération de données de test Oracle Diagnostique Le test dynamique : processus Donnée de test Programme P Exécution Résultat Spécification S Oracle Localisation / Mise au point faux Verdict Problèmes vrai non vérifié Critère d’arrêt

  38. Le test dynamique de logiciel • Soit D le domaine d’entrée d’un programme P spécifié par S, on voudrait pouvoir dire • Soit D le domaine de P:  xD P(x) = S(x) • Test exhaustif impossible dans la plupart des cas • Domaine D trop grand, voire infini • Trop long et coûteux

  39. Le test dynamique • On cherche alors un ensemble de données de test T tel que • T  D • si  xT P(x) = S(x) alors  xD P(x) = S(x) • Critère d’arrêt pour la génération de données de test • {données de test} = T

  40. I1 O1 I2 O2 I3 I1 O1 I2 O2 I3 La génération de test • Test fonctionnel (test boîte noire) • Utilise la description des fonctionnalités du programme • Test structurel (test boîte blanche) • Utilise la structure interne du programme

  41. Test fonctionnel • Spécification formelle • Modèle B, Z • Automate, système de transitions • Description en langage naturel • UML • Use cases • Diagramme de classes (+ contrats) • Machines à états / diagramme de séquence

  42. Test structurel • A partir d’un modèle du code • modèle de contrôle (conditionnelles, boucles...) • modèle de données • modèle de flot de données (définition, utilisation...) • Utilisation importante des parcours de graphes • critères basés sur la couverture du code

  43. Génération de test • Génération déterministe • « à la main » • Génération automatique aléatoire • Génération automatique aléatoire contrainte • mutation • test statistique • Génération automatique guidée par les contraintes

  44. Génération de test • Reste à savoir quand on a suffisamment testé • critères de test structurels, fonctionnels • analyse de mutation • Choisir le bon niveau pour le test

  45. E B1 P1 p=q p<>q P2 p>q p<q B2 B3 B4 S Exemple de test unitaire structurel PGCD de 2 nombres Précondition: p et q entiers naturels positifs pgcd: integer is local p,q : integer; do read(p, q) B1 while p<> q do P1 if p > q P2 then p := p-q B2 else q:= q-p B3 end -- if end -- while result:=p B4 end-- pgcd

  46. E B1 P1 p=q p<>q P2 p>q p<=q B2 B3 B4 S Exemple de test unitaire structurel 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 (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)

  47. Techniques de test fonctionnel • Test « boite noire » • N’utilise que la description fonctionnelle du programme • c’est la spécification • Plusieurs informations • domaine d’entrée • scénarios • use cases • ...

  48. Domaine d’entrée • Plusieurs niveaux • type des paramètres d’une méthode • pré-condition sur une méthode • ensemble de commandes sur un système • grammaire d’un langage • ... • On ne peut pas tout explorer, il faut délimiter • Génération aléatoire • Analyse partitionnelle • Test aux limites • Graphe causes - effets

  49. Technique 1: Analyse partitionnelle • A partir de la spécification • déterminer le domaine d’entrée du programme • Partitionner le domaine d’entrée en classes d’équivalences • identifier des classes d’équivalence pour chaque donnée • les classes d’équivalence forment une partition du domaine de chaque donnée en entrée • choisir une donnée dans chacune

  50. Technique 2 : Test aux limites • Intuition: • de nombreuses erreurs se produisent dans les cas limites • Pour chaque donnée en entrée • déterminer les bornes du domaine • prendre des valeurs sur les bornes et juste un peu autour • Exemple • pour un intervalle [1, 100] • 1, 100, 2, 99, 0, 101

More Related