1 / 87

Le test de logiciels

Le test de logiciels. Yves Le Traon. Plan du cours 1. Introduction: importance du test et positionnement dans un contexte de GL Hiérarchisation des tests Etapes de test Le test statique Le test dynamique 2 techniques élémentaires de test fonctionnel l’analyse partitionnelle

xanti
Télécharger la présentation

Le test de logiciels

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 logiciels Yves Le Traon

  2. Plan du cours 1 • Introduction: importance du test et positionnement dans un contexte de GL • Hiérarchisation des tests • Etapes de test • Le test statique • Le test dynamique • 2 techniques élémentaires de test fonctionnel • l’analyse partitionnelle • le test aux limites

  3. De la difficulté de la validation intra-composant: Programming-in-the small Acquérir une valeur positive n Tant que n > 1 faire si n est pair alors n := n / 2 sinon n := 3n+1 Sonner alarme; • Prouver que l’alarme est sonnée pour tout n? • Indécidabilité de certaines propriétés • problème de l’arrêt de la machine de Turing... • Recours au test • ici, si machine 32 bits, 2^31 = 10^10 cas de tests • 5 lignes de code => 10 milliards de valeurs !

  4. Programming-in-the-Large • Compilateur …………… 10 KLOC (C) • Système de commutation X25… 100 KLOC (C) • Contrôle de sous-marin nucléaire … 1 MLOC (ADA) • Station spatiale……… 10 MLOC (ADA)

  5. Programming-in-the-Large Gestion de la complexité due à la taille (différence entre le bricoleur et l’architecte) • Méthodes basées sur la modularité (SADT, UML) • Gestion des ressources (matérielles, humaines) et des synchronisation de tâches => multiplication des risques d’erreur => impossibilité d’obtenir des certitudes => “se convaincre que”, notion de “confiance”

  6. Validité inter-composants : Peut-on (ré)-utiliser un composant?

  7. Ex: Ariane 501 Vol de qualificationKourou, ELA3 -- 4 Juin 1996,12:34 UT • H0 -> H0+37s : nominal • Dans SRI 2: • BH (Bias Horizontal) > 2^15 • convert_double_to_int(BH) fails! • exception SRI -> crash SRI2 & 1 • OBC disoriented • Angle attaque > 20°, • charges aérodynamiques élevées • Séparation des boosters

  8. Ariane 501 : Vol de qualificationKourou, ELA3 -- 4 Juin 1996,12:34 UT • H0 + 39s: auto-destruction (coût: 500M€)

  9. Pourquoi ? (cf. IEEE Comp. 01/97) • Pas une erreur de programmation • Non-protection de la conversion = décision de conception ~1980 • Pas une erreur de conception • Décision justifiée vs. trajectoire Ariane 4 et contraintes TR • Problème au niveau du test d’intégration • As always, could have theoretically been caught. But huge test space vs. limited resources

  10. Pourquoi? (cf. IEEE Computer 01/97) • Réutilisation dans Ariane 5 d’un composant de Ariane 4 ayant une contrainte « cachée » ! • Restriction du domaine de définition • Précondition : abs(BH) < 32768.0 • Valide pour Ariane 4, mais plus pour Ariane 5 • Pour la réutilisation, pour une architecture répartie => • Spécification = contrat entre un composant et ses clients

  11. La maintenance : Programming-in-the-Duration • Etalement sur 10 ans ou plus d’une “ligne de produits” • Age moyen d’un système : 7 ans • 26% des systèmes ont plus de 10 ans (Cf. Application banquaire et Cobol)

  12. Problème Définition des besoins Spécification globale détaillée programme Problématique analyse des besoins conception Maintenance Programme livrable tests implémentation

  13. Problématique 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 !!!

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

  15. Problématique Pourquoi ? Coût Effort Confiance

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

  17. Problématique • Objectifs du test • examiner ou exécuter un programme dans le but d’y trouver des erreurs • éventuellement mise à l’épreuve de : • la robustesse (test hors bornes/domaine) • des performances (test en charge) • de conformité (protocoles normalisés) • de propriétés de sûreté

  18. Hiérarchisation des tests But :séparer les plans Typiquement confusion entrefautes hardware et software fautes fonctionnelles/structurelles faute temps-réel / fautes classiques Exemple :décodeur numérique utilisateur service Noyau tps-réel « mou » Décodeur Couche applicative 90% des fautes « tps-réel » sont en fait des fautes logicielles classiques détectées trop tard

  19. Hiérarchisation des tests But :séparer les plans Risques : perte d ’information d ’un plan à l ’autre Mauvaise compréhension des fonctions à réaliser Introduction de défauts de conception Tendance à repousser les problèmes aux niveaux inférieurs Maison n ’a encore rien trouvé de mieux … à moins que l ’objet n ’offre des solutions

  20. Problème Systè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) 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 »

  21. Niveau unitaire INSTRUCTION • Unit Level Components => implement specified functions • how can you trust them ? • How using/reusing them safely ? “off-the-shelf” E_FEATURE + is_deferred : Boolean = initval LOCAL_NAME CALL_PROC_CALL A component has a stability an identified interface BASE_CLASS + path : String + is_manifest_string : Boolean + is_deferred : Boolean + is_result : Boolean + is_expanded : Boolean + is_void : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST (from InheritanceClause) (from InheritanceClause)

  22. 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) Intégration • Integration/Evolution • How integrating them safely ? • How optimizing integration? • A Transition Step

  23. E_RETRY ONCE_PROCEDURE ONCE_FUNCTION E_CHECK NATIVE_C DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_SMALL_EIFFEL NATIVE_JVM 0..* 0..* IFTHENELSE IFTHEN INSTRUCTION +then_compound ONCE_ROUTINE PROCEDURE FUNCTION EXTERNAL_FUNCTION EXTERNAL_PROCEDURE +else_compound COMPOUND E_DEBUG +loop_body +routine_body E_LOOP NATIVE EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINE +native + language_name : String +initialize +rescue_compound +else_compound WRITABLE_ATTRIBUTE CST_ATT +local_vars E_INSPECT +list +list WHEN_LIST E_WHEN WHEN_ITEM +value LOCAL_VAR_LIST ATTRIBUTE ROUTINE REVERSE_ASSIGNMENT EXPRESSION WHEN_ITEM_1 WHEN_ITEM_2 CREATION_CALL PROC_CALL ASSIGNMENT +call +type E_FEATURE DECLARATION + is_deferred : Boolean = initval +arguments TYPE DECLARATION_LIST FORMAL_ARG_LIST + count : Integer +left_side +right_side +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 +name +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 système • System = a coherent components set =>implement specified functions => a more elaborated component A finalized system has a stability an identified interface System = Component

  24. Unit Testing Validation Regression Testing Evolution Integration Unit component System component Des composants au système? A Classical View...

  25. Hiérarchisation des tests Développements spécifiques au test • Test unitaire: drivers (lanceur des tests), oracle (succès/échec), intrumentation (mesure couverture) • Test intégration: idem + “bouchons” de tests (stubs), pour simuler les modules non disponibles • Test système : test des fonctions + environnement matériel + performances.

  26. Conditions (théorique) de possibilité du test • H1 : programmeur “compétent” Préalisé = (Pidéal) • H2 : Axiome de couplage (optionel) anomalies complexes = combinaison d’anomalies simples

  27. G é n é r a t i o n C a s d e t e s t E x é c u t i o n D i a g n o s t i c P r o g r a m m e C o r r e c t i o n R é s u l t a t O r a c l e n o n R é s u l t a t - C o r r e c t D é f a i l l a n c e ? o u i C r i t è r e d ' a r r ê t A r r ê t d e s t e s t s Etapes de test

  28. C r i t è r e d ' a r r ê t Etapes de test G é n é r a t i o n C a s d e t e s t E x é c u t i o n D i a g n o s t i c P r o g r a m m e C o r r e c t i o n R é s u l t a t O r a c l e n o n R é s u l t a t - C o r r e c t D é f a i l l a n c e ? o u i A r r ê t d e s t e s t s

  29. Etapes de test Test fonctionnel a b s1 c d s2 e f

  30. a b s1 C1 M2 c d s2 M1 M3 e C2 f Etapes de test Test fonctionnel ou test structurel Génération aléatoire ou déterministe

  31. a b s1 C1 M2 c d s2 M1 M3 e C2 f déterministe aléatoire Etapes de test Test fonctionnel ou test structurel Génération aléatoire ou déterministe difficulté génération

  32. a b s1 C1 M2 c d s2 M1 M3 e C2 f déterministe aléatoire Etapes de test Test fonctionnel ou test structurel Génération aléatoire ou déterministe difficulté génération difficulté oracle

  33. déterministe aléatoire Etapes de test Test fonctionnel (« black-box », boîte noire) Test structurel (« glass box », boîte blanche ou « de verre ») Génération aléatoire ou déterministe Indépendant de l ’implémentation Planifier à partir de la spécification fonctionnelle Réutilisables Dépend de l implémentation difficulté génération difficulté oracle

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

  35. Le test en général Problème :Génération des cas de test • trouver les données efficaces pour révéler les fautes • minimiser le nombre des données de test Exemple : générateur aléatoire une addition sur 32 bits un ensemble

  36. Le test en général Méthodes de génération des tests : 1) Génération déterministe Génération « à la main » des cas de test et des oracles Deux critères : - couvrir une portion précise du logiciel (critère stucturel) - couvrir les fonctions du logiciel (critère fonctionnel) Pas de méthode miracle Avantage ? :nécessitant une forte implication humaine les tests plus efficaces ?

  37. Le test en général Méthodes de génération des tests : 2) Génération aléatoire des données Profil opérationnel Freq Performances T° Seuil_alerte 120 750 P (bars) Crash ou grosses défaillances 1 4.5

  38. Le test en général Méthodes de génération des tests : 2) Génération aléatoire des données Test par mutation Variantes Test statistique On ne connaît pas les données d ’entrée Exemples : Le flot d ’entrée est fourni par le client Le flot d ’entrée est obtenu via une antenne etc.

  39. Le test en général 2) Génération guidée par les contraintes (analyse symbolique) Procedure lissage(in: integer; var out :integer) begin if in < Val1 then begin if in > Val2 then out := trt1; out:=trt2; end else out:=trt3; Val2 Val1 trt2 trt1; trt2; trt3 Contraintes rapidement trop complexes Uniquement test structurel (on a accès au code)

  40. Le test en général Limites du test aléatoire : couvre toujours les mêmes cas Nb_fautes Test aléatoire Test déterministe compromis Analyse aux limites (contraintes) Nb_cas_test AT AT AT

  41. ! Le test en général Problèmes :exécution des tests • environnement de développement « propre » • environnement de test • debugger (points d ’arrêt, suivi de l ’état des données du programme sous test) • instrumentation automatique du code/outils d ’observation (couverture etc.) -> logiscope & Co. • on ne teste que rarement le système tel qu’il sera chez le client (partie simulée, systèmes embarqués, parties non-terminées ou sous traitées ailleurs …) -> environnement de simulation (potentiellement bogué) Exemple : ARIANE V

  42. Le test en général Problèmes: oracle (ou verdict) Oracle :expression booléenne caractérisant la détection d ’une erreur Généralement = (resultat_attendu = résultat_obtenu) Ou bien : levée d ’une exception Exemple : génération aléatoire des données de test Système Données générées aléatoirement ? Résultat correct

  43. Avant le test…mieux vaut prévenir que guérir Un principe : plus une faute est détectée tard, plus elle coûte cher Moralité : Mieux vaut prévenir que guérir 2 moyens principaux a) Analyse de testabilité b) « test statique »

  44. Too late! Avant le test…mieux vaut prévenir que guérir $ Testabilité Traçabilité Spécifications non ambiguës Faute de conception Tests unit. Tests int. Tests Syst. Conception Implé. Maintenance.

  45. Avant le test…mieux vaut prévenir que guérir Testabilité Définition 1 : effort d’effort de mise en œuvre d’une technique de test et d’obtention du critère d’arrêt le nombre de cas de test structure à couvrir critère d’arrêt nombre de chemins à activer en général chemins de contrôle

  46. Test statique Techniques de « test statique » Définition : ne requiert pas l ’exécution du logiciel sous-test sur des données réelles réunions de 4 personnes environ pour inspecter le code 1 modérateur, le programmeur, le concepteur et 1 inspecteur

  47. Test statique Préparation:Distribution des documents quelques jours avant la séance (code, spec, éventuellement cas de test prévus) Durée :1h30 à 2h max But :le programmeur lit et explique son programme le concepteur et l ’inspecteur apportent leur expertise les fautes sont listées (pas corrigées-> à la charge du programmeur)

  48. Test statique 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

  49. Test statique • Règles • être méthodique (cf. transparents suivants) • un critère : le programme peut-il être repris par quelqu’un qui ne l’a pas fait • un second critère : les algorithmes/l’architecture de contrôle apparaît-elle clairement ? • > décortiquer chaque algo et noter toute redondance curieuse (coller) et toute discontinuité lorsqu’il y a symétrie (ce qui peut révéler une modif incomplète du programme)

  50. Test statique Exemple: vérification de la clarté (procédural) R1 :Détermination des paramètres globaux et de leur impact sur les fonctions propres program recherche_tricho; uses crt; 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

More Related