e Test des logicielsLe test de logiciels Yves Le Traon e Test des logiciels 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 – techniques élémentaires de test fonctionnel • l’analyse partitionnelle • le test aux limites • les graphes cause-effet – test structurel unitaire • Test d’intégration: stratégies de base e Test des logiciels De la difficulté de la validation intracomposant: Programming-in-the small Acquérir une valeur positive n Acquérir une valeur positive n Tant que n > 1 faire Tant que n > 1 faire si n est pair si n est pair alors n := n //2 alors n := n 2 sinon n := 3n+1 sinon n := 3n+1 Sonner alarme; 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 ! e Test des logiciels Programming-in-the-Large Compilateur …………… Système de commutation X25… Contrôle de sous-marin nucléaire … Station spatiale……… 10 KLOC (C) 100 KLOC (C) 1 MLOC (ADA) 10 MLOC (ADA UML) – Gestion des ressources (matérielles. notion de “confiance” .e Test des logiciels 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. humaines) et des synchronisation de tâches => multiplication des risques d’erreur => impossibilité d’obtenir des certitudes => “se convaincre que”. e Test des logiciels Validité inter-composants : Peut-on (ré)-utiliser un composant? . ELA3 -.e Test des logiciels Ex: Ariane 501 Vol de qualification Kourou.4 Juin 1996.12:34 • H0 -> H0+37s : nominal • Dans SRI 2: – BH (Bias Horizontal) > 2^15 – convert_double_to_int(BH) fails! – exception SRI -> crash SRI2 & 1 UT • OBC disoriented – Angle attaque > 20°. – charges aérodynamiques élevées – Séparation des boosters . 12:34 UT • H0 + 39s: auto-destruction (coût: 500M€) . ELA3 -.e Test des logiciels Ariane 501 : Vol de qualification Kourou.4 Juin 1996. trajectoire Ariane 4 et contraintes TR • Problème au niveau du test d’intégration – As always. limited resources . IEEE Comp.e Test des logiciels Pourquoi ? (cf. could have theoretically been caught. 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. But huge test space vs. 0 – Valide pour Ariane 4. 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.e Test des logiciels Pourquoi? (cf. mais plus pour Ariane 5 • Pour la réutilisation. pour une architecture répartie => – Spécification = contrat entre un composant et ses clients . Application banquaire et Cobol) .e Test des logiciels 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. e Test des logiciels Problématique Problème analyse des besoins Définition des besoins conception Spécification globale détaillée implémentation programme Maintenance Programme livrable tests . An. Spécif.e Test des logiciels Problématique Le coût du test dans le développement Implém. b Test analyse des besoins spécification Implémentation test + maintenance = 80 % du coût global de développement !!! . e Test des logiciels Problématique: une définition ! conformité du produit par rapport à sa spécification Vérification/preuve La validation tests . e Test des logiciels Problématique Pourquoi ? Coût Effort Confiance . e Test des logiciels Vocabulaire Testabilité faute erreur Test de Robustesse bogue Fiabilité (Reliability) défaillance Test statique Tolérance aux fautes Séquence de test Données de test Sûreté de fonctionnement (Dependability) Jeu de test Cas de test Test statistique Test de non-régressio . e Test des logiciels 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é . e Test des logiciels Hiérarchisation des tests But : séparer les plans Typiquement confusion entre fautes hardware et software fautes fonctionnelles/structurelles faute temps-réel / fautes classiques utilisateur Exemple : décodeur numérique Noyau tps-réel « mou » service Décodeur Couche applicative 90% des fautes « tps-réel » sont en fait des fautes logicielles classiques détectées trop tard . e Test des logiciels 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 Mais on n ’a encore rien trouvé de mieux … à moins que l ’objet n ’offre des solutions . e Test des logiciels Maintenanc Hiérarchisation des tests Problème analyse des besoins Définition des besoins Plan de test système (fonctionnel) Programme livrable Test de recett (avec client) Système Tests systèmes Cahier des charges Conception globale Plan de test d’intégration Intégration Tests d ’intégration ? Conception détaillée implémentation programme Composants unitaires Tests unitaires le cycle en « V » . e Test des logiciels Niveau unitaire Unit Level Components => implement specified functions • how can you trust them ? • How using/reusing them safely ? “off-the-shelf” LOCAL_NAME CALL_PROC_CALL E_FEATURE + is_deferred : Boolean = initval INSTRUCTION A component has a stability an identified interface BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST (from InheritanceClause) InheritanceClause) (from . .* +arguments SMALLEIFFEL LOCAL_NAME ARGUMENT_NAME FEATURE_CLAUSE +list CALL + magic_count : Integer +list TYPE + is_ready : Boolean + load_class() + get_started() +name_list +to_runnable + falling_down() +result_type+ afd _check() +name FEATURE_CLAUSE_LIST +feature_clause_list +base_class_dictionary +base_class +base_class +result_type +clients TYPE +clients CLIENT_LIST FEATURE_NAME + is_frozen : Boolean LOCAL_ARGUMENT CLASS_NAME +list CLASS_NAME +names CREATION_CLAUSE FEATURE_NAME_LIST +procedure_list +list NAME BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean +origin_base_class +base_class EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST (from InheritanceClause) InheritanceClause) (from CREATION_CLAUSE_LIST EXPRESSION FEATURE_NAME +creation_clause_list +base_class +base_class SIMPLE_FEATURE_NAME FROZEN_FEATURE_NAME INFIX_NAME PREFIX_NAME +export_list +rename_list +undefine_list +parent_list PARENT_LIST +redefine_list (from InheritanceClause) +select_list PARENT (from InheritanceClause) +current_type TYPE / path : String +generic_list FORMAL_GENERIC_ARG + +constraint : boolean constrained + rank : Integer +list FORMAL_GENERIC_LIST TYPE_CHARACTER +formal_generic_list +formal_generic_list TYPE_GENERIC TYPE_FORMAL_GENERIC TYPE_CLASS (from TYPE) (from TYPE) (from TYPE) TYPE_POINTER TYPE_ANY TYPE_NONE .e Test des logiciels Intégration INSTRUCTION E_RETRY E_CHECK IFTHENELSE ONCE_PROCEDURE ONCE_FUNCTION DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_C NATIVE_SMALL_EIFFEL NATIVE_JVM IFTHEN EXTERNAL_FUNCTION EXTERNAL_PROCEDURE Integration/Evolution • How integrating them safely ? • How optimizing integration? TYPE E_DEBUG +then_compound ONCE_ROUTINE FUNCTION PROCEDURE COMPOUND E_LOOP EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINENATIVE +native WRITABLE_ATTRIBUTE CST_ATT E_INSPECT WHEN_LISTE_WHEN WHEN_ITEM LOCAL_VAR_LIST ROUTINE REVERSE_ASSIGNMENT EXPRESSION CREATION_CALL PROC_CALL ASSIGNMENT +call +type WHEN_ITEM_1 ATTRIBUTE DECLARATION + count : Integer E_FEATURE + is_deferred : Boolean = initval DECLARATION_LIST FORMAL_ARG_LIST – A Transition Step +result_type EXPRESSION CALL_PROC_CALL GLOBALS 1 +writable 1 DECLARATION_GROUP DECLARATION_1 +target 0. .e Test des logiciels Test système E_RETRY System = a coherent components set =>implement specified functions => a more elaborated component E_CHECK 0..* +arguments LOCAL_NAME ARGUMENT_NAME TYPE CALL FEATURE_CLAUSE +list SMALLEIFFEL + magic_count : Integer +list + is_ready : Boolean +result_type +clients TYPE +clients CLIENT_LIST + load_class() + get_started() +name_list +to_runnable + falling_down() +result_type+ afd _check() +name FEATURE_NAME + is_frozen : Boolean LOCAL_ARGUMENT CLASS_NAME +name +base_class_dictionary +base_class +base_class FEATURE_CLAUSE_LIST +feature_clause_list A finalized system has a stability an identified interface +list CLASS_NAME System = Component +names CREATION_CLAUSE FEATURE_NAME_LIST +procedure_list +list NAME BASE_CLASS + is_manifest_string+ path : String : Boolean + is_result : Boolean+ is_deferred : Boolean + is_void : Boolean + is_expanded : Boolean /+ is_generic : Boolean + is_any : Boolean = initval + is_general : Boolean +origin_base_class +base_class EXPORT_ITEM RENAME_PAIR FEATURE_NAME_LIST (from InheritanceClause) InheritanceClause) (from CREATION_CLAUSE_LIST EXPRESSION FEATURE_NAME +creation_clause_list +base_class +base_class FROZEN_FEATURE_NAME INFIX_NAME PREFIX_NAME SIMPLE_FEATURE_NAME +export_list +rename_list +undefine_list +parent_list PARENT_LIST +redefine_list (from InheritanceClause) +select_list PARENT (from InheritanceClause) +current_type TYPE / path : String +generic_list FORMAL_GENERIC_ARG + +constraint : boolean constrained + rank : Integer +list FORMAL_GENERIC_LIST TYPE_CHARACTER +formal_generic_list +formal_generic_list TYPE_GENERIC TYPE_CLASS TYPE_FORMAL_GENERIC (from TYPE) (from TYPE) (from TYPE) TYPE_POINTER TYPE_ANY TYPE_NONE .* INSTRUCTION IFTHENELSE ONCE_PROCEDURE ONCE_FUNCTION DEFERRED_FUNCTION DEFERRED_PROCEDURE NATIVE_C NATIVE_SMALL_EIFFEL NATIVE_JVM IFTHEN EXTERNAL_FUNCTION EXTERNAL_PROCEDURE +then_compound ONCE_ROUTINE FUNCTION PROCEDURE +else_compound COMPOUND E_DEBUG E_LOOP +loop_body +initialize +else_compound +local_vars E_INSPECT +list +list WHEN_LISTE_WHEN WHEN_ITEM LOCAL_VAR_LIST +routine_body EFFECTIVE_ROUTINE DEFERRED_ROUTINE EXTERNAL_ROUTINENATIVE +native + language_name : String +rescue_compound WRITABLE_ATTRIBUTE CST_ATT ROUTINE REVERSE_ASSIGNMENT WHEN_ITEM_1 WHEN_ITEM_2 +value ATTRIBUTE EXPRESSION CREATION_CALL PROC_CALL ASSIGNMENT +call +type TYPE +left_side +right_side DECLARATION + count : Integer E_FEATURE +arguments DECLARATION_LIST FORMAL_ARG_LIST+ is_deferred : Boolean = initval +result_type EXPRESSION CALL_PROC_CALL GLOBALS 1 +writable 1 DECLARATION_GROUP DECLARATION_1 +target 0. .e Test des logiciels Des composants au système? Integration Evolution Unit component System component A Classical View.. . e Test des logiciels 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. e Test des logiciels 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 e Test des logiciels Etapes de test Génération Cas de test Exécution Programm e Résultat Oracle Résultat-Correct ? oui Critère d'arrêt non Défaillanc e Diagnostic Correction Arrêt des tests e Test des logiciels Etapes de test Génération Cas de test Exécution Programm e Résultat Oracle Résultat-Correct ? oui Critère d'arrêt non Défaillanc e Diagnostic Correction Arrêt des tests e Test des logiciels Etapes de test 4 Test fonctionnel a b c d e f s1 s2 . e Test des logiciels Etapes de test 4 Test fonctionnel ou test structurel a b c d e f s1 s2 C1 M1 C2 M2 M3 4 Génération aléatoire ou déterministe . e Test des logiciels Etapes de test 4 Test fonctionnel ou test structurel a b c d e f s1 s2 C1 M1 C2 M2 M3 4 Génération aléatoire ou déterministe déterministe difficulté génération aléatoire . e Test des logiciels Etapes de test 4 Test fonctionnel ou test structurel a b c d e f s1 s2 C1 M1 C2 M2 M3 4 Génération aléatoire ou déterministe déterministe difficulté génération aléatoire difficulté oracle . e Test des logiciels Etapes de test 4 Test fonctionnel (« black-box ». boîte noire) Indépendant de l ’implémentation Planifier à partir de la spécification fonctionnelle Réutilisables 4 Test structurel (« glass box ». boîte blanche ou « de verre ») 4 Dépend de l implémentation Génération aléatoire ou déterministe déterministe difficulté génération aléatoire difficulté oracle . e Test des logiciels Etapes et hiérarchisation des tests Test structurel Tests unitaires Tests d ’intégration Test fonctionnel Tests système . e Test des logiciels 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 . couvrir une portion précise du logiciel (critère stucturel) .e Test des logiciels 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 les fonctions du logiciel (critère fonctionnel) Pas de méthode miracle Avantage ? : nécessitant une forte implication humaine les tests plus efficaces ? . 5 .e Test des logiciels 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 T° 120 750 Performances Seuil_alerte P (bars) Crash ou grosses défaillances 1 4. .e Test des logiciels 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. Val2 Val1 trt2 trt1. var out :integer) begin if in < Val1 then begin if in > Val2 then out := trt1. out:=trt2. trt3 Contraintes rapidement trop complexes Uniquement test structurel (on a accès au code) . end else out:=trt3.e Test des logiciels Le test en général 2) Génération guidée par les contraintes (analyse symbolique) Procedure lissage(in: integer. trt2. e Test des logiciels 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 . ! on ne teste que rarement le système tel qu’il sera chez le client (partie simulée. suivi de l ’état des données du programme sous test) • instrumentation automatique du code/outils d ’observation (couverture etc. systèmes embarqués.e Test des logiciels 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. parties non-terminées ou Exemple : sous traitées ailleurs …) -> environnement de simulation ARIANE V (potentiellement bogué) .) -> logiscope & Co. e Test des logiciels 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 Données générées aléatoirement Système Résultat correct ? . e Test des logiciels 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 » . Tests Syst. Tests unit. .e Test des logiciels Too late! Avant le test… mieux vaut prévenir que guérir $ Faute de conception Testabilité Traçabilité Spécifications non ambiguës Conception Implé. Tests int. Maintenance. e Test des logiciels Test statique Techniques de « test statique » Définition : ne requiert pas l ’exécution du logiciel soustest sur des données réelles réunions de 4 personnes environ pour inspecter le code 1 modérateur. le concepteur et 1 inspecteur . le programmeur. é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) .e Test des logiciels Test statique Préparation: Distribution des documents quelques jours avant la séance (code. spec. e Test des logiciels 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 . e Test des logiciels 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) . . complex : integer. choix1 = 1. fin = 3.max_elt] of integer. var liste : Tliste. But du programme non exprimé Manque de commentaires Identificateurs non explicites . const max_elt = 50. uses crt. val : integer. choix2 = 2.e Test des logiciels 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. taille. choix. type Tliste = array[1. e Test des logiciels Test statique Exemple: vérification de la clarté R2 : Existence d’un entête clair pour chaque fonction {-------------------------------------------------------------------------Recherche recursive d'une valeur dans une liste triee --------------------------------------------------------------------------} . .e Test des logiciels Test statique: pour chaque fonction Commentaires minimum { parametres d'entree : liste L la valeur recherchee manque indice gauche e nom de la fonction indice droit dépendance avec resultat : complexite de la recherche } utres Interface Spécifiée ? ariables/fonctions Interface implantée unction rech_rec(L : Tliste . d : integer) : integer . val. g. g.e Test des logiciels var i. dt+1. val. if val > L[pt] Répétition ? then begin dt := (pt+1+d) div 2. val. { rech_rec } . pt+1. pt. d) else rech_rec:=2+rech_rec(L. pt) end else rech_rec:=0 end. dt : integer. Action non spécifiée if g<d then begin pt :=g+(d-g) div 3. if val > L[pt] then rech_rec:=2+rech_rec(L. val. d). g. Test statique Quézako ? begin affiche(L. dt) end else rech_rec:=1+rech_rec(L. . règles (de bon sens!) identificateurs clairs. analyse d ’anomalies (du graphe de contrôle/de données). variables globales) preuves d ’algorithmes. exécution symbolique.e Test des logiciels Test statique Autre méthodes : revues.). métriques (contraintes etc. simulation de modèles. etc. découpage fonctionnel « naturel » limiter les effets de bords (interfaces. les fonctions spécifiées du logiciel F : D -> Sorties Le problème du test dynamique est : D → Sorties Pratiquement : T⊂D : t∈T→P(t)=F(t) F=P ? .e Test des logiciels Test dynamique : Vocabulaire • • • • 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. e Test des logiciels Test dynamique • DEUX REGLES : – Conserver les tests déjà écrits – Conserver les réponses correctes correspondantes . e Test des logiciels Test dynamique Exemple simplissime: exe < fichier_testi • quand correct : exe < fichier_testi > res_testi • Lorsque intégration : Driver de test existe déjà • Lorsque évolution : Tests de non-régression newexe < fichier_testi > res_test_newexe diff res_test_newexe C’est plus simple en OO (classes autotestables) . but never their absence” (Dijkstra) .e Test des logiciels Test dynamique structurel “Testing can prove the presence of bugs. e Test des logiciels Le test structurel: abstraire pour obtenir un critère formel C si C alors I1 sinon I2 I1 I2 . ou prédicats des conditionnelles /boucles.e Test des logiciels Le 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 nœud de sortie S (nœud fictif ajouté si plusieurs sorties) – Sommets : blocs élémentaires du programme. ou nœuds 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 . if end -.e Test des logiciels Le test unitaire structurel Exemple : PGCD de 2 nombres Précondition: p et q entiers naturels positifs lus au clavier Effet : result = pgcd(p.pgcd P2 B2 B3 S B4 E B1 P1 p<>q P2 p>q B2 p<=q B3 . q) B1 P1 while p<> q do if p > q then p := p-q else q:= q-p end -. do p=q read(p.q : integer.while result:=p B4 end-. q) En pseudo-langage pgcd: integer is local p. e Test des logiciels Le test unitaire structurel • Question : Sur ce modèle imaginer un critère de couverture – minimal – maximal . • 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.n]) Chemins infaisables : problème en général indécidable .e Test des logiciels Le test unitaire structurel • Chemins : suite d’arcs rencontrés dans le graphe. en partant de E et finissant en S.. • 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. potentiellement infinis .e Test des logiciels Le 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. e Test des logiciels Le test unitaire structurel • Question : différence entre couverture arcs et couverture instructions ? • Faire Exemple . P1. B1. B1. P1. B2. B4. P2. S) S . B2. P2. P1. B4. P1. B1. P1. B1. B4. P1. P2. B2. P2. S) Tous les arcs : idem Tous les chemins élémentaires (1-chemin) : idem + (E. P1. P1. B3. B4. B1. P2. P1. P1. P2. P1. S) (E. B4. P2. B1. B4. B4. B3. P1. S) Tous les 2-chemins : idem + (E. B2. S (E. P2. B3. P1. B1. S) (E. B2. B3. P2. P1. S (E. P1. B3.e Test des logiciels Le test unitaire structurel E B1 P1 p=q P2 p>q B4 B2 p<=q B3 p<>q Tous les noeuds: (E. P1. P1. P2. diff if then imbriqués Aspects données Flot de données (Weyuker) Pertinence des données .pas de modèle (Mutation etc. .e Test des logiciels Test unitaire structurel • Questions : qu’est-ce que ne capture pas ce modèle ? Couverture des prédicats Couverture des dépendances entre variables Couverture des domaines d’entrée Cf. – 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.e Test des logiciels Le test unitaire structurel • Graphe de Flot de Données (Weyuker) – But : représenter les dépendances entre les données du programme dans le flot d’exécution. if B4 end -. q) while p<> q do P1 .e Test des logiciels Exemple Le test unitaire structurel E B1 Def(p) Puse(p) pgcd: integer is local p.Cuse(q) end -.Cuse(p).Puse(p). Cuse(p) else q:= q-p B3 . Def(q) read(p. end-.q : integer. Puse(q) then p := p-q B2.while Cuse(p) result:=p B4. Cuse(p). Cuse(q).Def(q).Puse(p).pgcd S P2 Puse(p) p>q p<=q B2 Cuse(p) B3 Cuse(p) . do B1.Def(p).Def(p). Puse(q) P1 p=q p<> if p > q P2. end Définition 1 Utilisation 1.1 Définition Utilisation 1.2 Utilisation 2. … while not probleme do begin piloter(avion. auto. direction) end.360] begin … saisir_direction(direction). direction : integer in [1. … if capteur_pression < 120 then probleme := true end … if probleme then traiter_probleme(capteur_pression) …. … probleme := false.e Test des logiciels Le test en général: critères d ’arrêt unitaire : flot de données Autres critères structurels : lien definition-utilisation (Weyuker) Program pilote_automatique var probleme: boolean.. . ∀ JT satisfaisant C1 on a JT satisfait C2 .e Test des logiciels Test structurel : relation d’implication entre critères • Définition : C1 ⇒ C2 (“subsumes”) ssi ∀ P. e Test des logiciels Test structurel : relation d’implication entre critères • Question : ordonner les critères selon cette définition Tous les chemins chemins élémentaires Lien définition-utilisatio (all-uses) all-p-uses/some-c-uses all-p-uses K-chemins arcs all-c-uses/some-p-uses Couverture instructions all-defs . e Test des logiciels Le test unitaire structurel: classement Tous les chemins n-cycles chemins élémentaires Lien définition-utilisation (all-uses) all-p-uses/some-c-uses all-c-uses/some-p-uses all-p-uses arcs all-defs Couverture instructions . complexité et flot de contrôle 1 2 5 3 2 2 1 1 4 6 6 3 4 5 V= 2 Npath = 2 V= 6 Npath = 6 V= 6 Npath = 32 Couverture de chemins : le nombre cyclomatique (Mc Cabe) le Npath (Nejmeh) .e Test des logiciels Le test unitaire structurel: critère d ’arrêt. e Test des logiciels Le test en général: critères d ’arrêt Nombre cyclomatique Nombre de chemins pour couvrir la structure de contrôle Nombre total des chemins de contrôle effort de mise en œuvre d’une technique de test structurel Npath . ..... Traitement_reconfiguration Traitement_urgenc . .. .....vers le test structurel d’intégration Couverture du graphe d ’appel Pilote_automatique Pilotage_manuel Saisir_direction piloter traiter_probleme ..e Test des logiciels . e Test des logiciels Le test d’intégration • But : vérifier les interactions entre composants (se base sur l’architecture de la 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) . Ecriture uniquement de drivers de tests.e Test des logiciels Le test d’intégration • Stratégies possibles (si architecture sans cycles) – big-bang : tout est testé ensemble. Peu courant. On intègre depuis les feuilles. – bottom-up : la plus classique. . Peu recommandé ! – top-down : de haut en bas. D D S T Driver Stub Composant testé Composant sous test Interface sous test Interface testée . Top-down. Big-Bang.e Test des logiciels Le test d’intégration • 3 stratégies: bottom-up. e Test des logiciels Le test d’intégration • Bottom-up D D D T T D D D D T T . e Test des logiciels Le test d’intégration D D D D T T T T T T T T T T T T T T T T T . e Test des logiciels Le test d’intégration D T T T T T T T T T T T . e Test des logiciels Le test d’intégration Top-Down D T S S S S D S . e Test des logiciels Le test d’intégration D T S S S . e Test des logiciels Le test d’intégration D T T T T T T T T D S S S S S T S . e Test des logiciels Le test d’intégration D T T T T T T T T T T D T T T T T T T T T T T . e Test des logiciels Le test d’intégration • • • • • intégration Big-Bang intégration Top-down intégration bottom-up intégration backbone intégration par domaines de collaboration .