La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

Cours de Génie Logiciel Validation (par le test) Lydie du Bousquet Novembre 2004.

Présentations similaires


Présentation au sujet: "Cours de Génie Logiciel Validation (par le test) Lydie du Bousquet Novembre 2004."— Transcription de la présentation:

1 Cours de Génie Logiciel Validation (par le test) Lydie du Bousquet Novembre 2004

2 2 Introduction Philippe Lalanda Cas d'étude : Ariane 5Yves Ledru Les cycles de vie Pierre-Yves Cunin Spécifications en logicielPhilippe Lalanda Conception logicielle Philippe Lalanda ValidationLydie du Bousquet La génération de codeJean-Marie Favre UML : Principes 1Philippe Lalanda UML : Principes 2Philippe Lalanda UML : exemple industrielDidier Pellegrin Liste des interventions

3 3 Objectifs du cours d'aujourd'hui Comprendre ce quest la validation Identifier les principales difficultés du « test » de programmes, de logiciels Connaître quelques techniques permettant de tester des programmes

4 4 Rappels Principe du test Techniques relatives au test Conclusion Plan

5 5 Rappel Le Génie Logiciel Les processus de développement Principe du Test Techniques relatives au test Conclusion Plan

6 6 Le GL est une réponse à la "crise du logiciel" erreurs, budgets et échéances dépassés Le GL est une démarche d'ingénierie définition de processus, de méthodes et d'outils s'applique à tous les aspects du logiciel Il existe de nombreux processus, méthodes et techniques qu'il faut choisir au mieux sans trop en faire ! Génie Logiciel

7 7 Les processus logiciels définissent les activités liées à la production de logiciels Tous les processus incluent les phases : de spécification du logiciel de conception du logiciel d'implantation du logiciel de vérification / validation Processus logiciels

8 8 Validation établissement par des preuves objectives que toutes les exigences ont été correctement et complètement implémentée (prises en compte) produit répond aux besoins Vérification confirmation que ce qui est produit pendant une étape de développement correspond à toutes les exigences exprimée au début de cette phase produit conforme à sa définition Vérification et validation (1)

9 9 On peut se placer à différents niveaux Spécification correspond-elle aux exigences ? Conception correspond-elle à la spécification, aux exigences ? Implantation correspond-elle à la conception, à la spécification, aux exigences ? Vérification et validation (2)

10 10 Analyse statique revue de code, relecture croisée Tests Preuve model-checking preuves déductives Quelques techniques

11 11 Rappel Principe du Test Définition Problématiques Techniques relatives au test Conclusion Plan

12 12 Tester un logiciel, c'est : exécuter le logiciel en maîtrisant les données en entrée en sassurant que le comportement est celui attendu Maîtrise des entrées sélectionner assez de données mais pas trop Vérification du comportement pouvoir observer le comportement adopter une vision critique Définition du test

13 13 Exécution des tests « à la main » Programmes de test / batch Utilisation doutils spécialisés J-unit Cpp-unit …

14 14 Cest la question clé Pourquoi est-ce que vous testez ? Pourquoi tester ?

15 15 On attend du logiciel certaines propriétés adéquation aux besoins absence derreur, robustesse, performances,... Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un avion qui na jamais été testé en vol mais dont les fabricants vous garantissent quils ont «!prouvé!» que tout allait bien se passer ? Pourquoi tester ? (2)

16 16 On attend du logiciel certaines propriétés adéquation aux besoins absence derreur, robustesse, performances,... Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un avion qui na jamais été testé en vol mais dont les fabricants vous garantissent quils ont «!prouvé!» que tout allait bien se passer ? Pourquoi tester ? (2)

17 17 Soit une propriété attendue Exemple : absence d erreur Le test ne peux pas garantir que la propriété est vraie Si un contre-exemple est trouvé, on a la preuve que la propriété est fausse Tester : rechercher des erreurs (Myers 79) Pourquoi tester ? (3)

18 18 On caractérise lactivité de test en fonction de son objectif Test de conformité Test de performances, test de montée en charge Test de non régression du moment ou il effectué dans le développement Test unitaire Test dintégration Test système Test dacceptation (ou de recette) Test de non-régression Types de tests

19 19 On caractérise lactivité de test en fonction de son objectif Test de conformité Test de performances, test de montée en charge Test de non régression du moment ou il effectué dans le développement Test unitaire Test dintégration Test système Test dacceptation (ou de recette) Test de non-régression Types de tests

20 20 Types de test (2) Tests unitaires Spécification Conception globale Conception détaillée Codage Analyse des besoins Tests dintégration Tests système Test dacceptation

21 21 Difficultés théoriques On ne peut pas tout tester Infinité de données et/ou pas le temps/argent Quelles données choisir ? Comment décider que le résultat est correct ? Quand peut-on / doit-on sarrêter ? Difficulté psychologique Programmation : activité constructive Test : activité « destructive » Il est difficile de détruire ce que lon a construit Pourquoi le test est difficile (1)

22 22 Test exhaustif Exécuter le logiciel avec toutes les données dentrée possibles dans toutes les situations possibles Impossible Choisir des donnée pour découvrir des erreurs Quelles données pour trouver des erreurs ? Quelles données pour trouver toutes les erreurs ? Chaque programme est particulier = aucune technique générale Démarches classiques, basées sur lexpérience (ensemble de « trucs ») Pourquoi le test est difficile (2) Le choix de données

23 23 Décider si le comportement du programme est correct Problème de loracle Pouvoir observer : quelles sont les sorties du logiciels Savoir décider Comment décide-t-on que le comportement est OK ? Exple : Soit un programme de tri alphabétique Pourquoi le test est difficile (3) Résultat correct ? Lagaf Mafalda Lagaf OK KO

24 24 Décider si le comportement du programme est correct Problème de loracle Pouvoir observer : quelles sont les sorties du logiciels Savoir décider Comment décide-t-on que le comportement est OK ? Exple : Soit un programme de tri alphabétique Pourquoi le test est difficile (3) Résultat correct ? Lagaf G. La Poste Lagaf G.

25 25 Le test na pas révélé danomalies Absence derreur ? Mauvais choix de données ? Le test a révélé des anomalies Existe-t-il dautres erreurs ? Pourquoi le test est difficile (4) Quand sarrêter ?

26 26 Rappel Principe du Test Techniques relatives au test Arrêt du test Choix des données Correction du résultat (oracle) Conclusion Plan

27 27 Sassurer que toutes les fonctionnalités ont été testées Base : cahier des charges; exigences et/ou spécification « Couverture fonctionnelle » Sassurer que tout le code a été exécuté Base : code « Couverture structurelle » Étudier lévolution du nombre de fautes découvertes Analyse de fiabilité Arrêt du test

28 28 Sassurer que toutes les fonctionnalités ont été testées Base : cahier des charges; exigences et/ou spécification « Couverture fonctionnelle » Sassurer que tout le code a été exécuté Base : code « Couverture structurelle » Étudier lévolution du nombre de fautes découvertes Analyse de fiabilité Arrêt du test

29 29 Exemple a ed C2 C1 b c E S a si C1 alors b sinon c si C2 alors d sinon e Graphe de contrôle

30 30 Types de couverture Instructions Branches Conditions et conditions multiples Chemins avec itérations LCSAJ Flux de données... a ed C2 C1 b c E S

31 31 Mesures de couverture Attention! Mesure de couverture Soit un critère On sarrête quand le critère est atteint Lindustrie aime Manipulation de données quantitative Peut être outillé Attention : Un critère darrêt signifie Tant que le critère nest pas couvert, on nest sûr que lon na pas fini de testé Un critère darrêt NE signifie PAS Quand on a atteint le critère on a fini de tester Quand on a atteint le critère on a trouvé toutes les erreurs

32 32 Couverture des instructions Objectif : Exécuter au moins une fois toutes les instructions du programme But : Détecter des instructions fautives Justification : Si on na pas testé toutes les instructions, on na pas testé tout le programme

33 33 Couvertures des instructions Limites On peut exécuter toutes les instructions sans exécuter tous les cas Exemple : C = vrai satisfait le critère (S1, S2 et S3 exécutés). C = faux potentiellement jamais testé. S1; Si C alors S2; S3;

34 34 Couverture des branches Objectif : Exécuter au moins une fois chaque branche But : Mettre en évidence des défauts dans les instructions conditionnelles ou itératives Justification Si toutes les conditions nont pas été exécutée au moins une fois à vraie et à faux, …

35 35 Couverture des branches Limites Si C1 alors S1 sinon S2; Si C2 alors S3 sinon S4; (C1, C2) = (F, F) et (V, V) satisfont le critère. (F, V) et (V, F) jamais testés.

36 36 Couverture des conditions Objectif : Exécuter chaque condition avec la valeur vrai puis faux But : Similaire couverture des branches Limites : si A et B alors... si A alors si B alors... « A et B » est considéré comme une condition unique

37 37 Couverture des conditions multiples Objectif : Exécution de toutes les combinaisons possibles entre conditions élémentaires constituant une condition composée Justification : Meilleure détection des défauts dans les conditions

38 38 Couverture des chemins avec itérations Objectif Exécution au moins une fois de chaque chemin sélectionné suivant deux critères : Sélection des chemins nitérant pas plus de k fois (k fixé suite étude défauts,...). Sélection de tous les chemins correspondant à 1 passage dans la boucle (pas ditération) ou 2 passages (1 itération)

39 39 Couverture de tous les chemins Objectifs Exécuter tous les chemins du programme Limites Nombre de chemins infini en général Existence de « chemins impossibles » Détection de défauts situés sur un chemin non garantie par une seule exécution « Chemin manquant »

40 40 Mesures de couverture Attention (bis) ! Un critère darrêt signifie Tant que le critère nest pas couvert, on nest sûr que lon na pas fini de testé Un critère darrêt NE signifie PAS Quand on a atteint le critère on a fini de tester Quand on a atteint le critère on a trouvé toutes les erreurs

41 41 Rappel Principe du test Techniques relatives au test Arrêt du test Choix des données Correction du résultat (oracle) Conclusion Plan

42 42 Génération de données Il existe de nombreuses méthodes de choix de données On génère des données En utilisant la structure du code En utilisant la description des exigences, de la spécification… De façon aléatoire ou par rapport à un profil opérationnel En utilisant sa propre expérience / sensibilité

43 43 Génération de données et couverture(s) structurelle(s) Approche « mesure a posteriori » Les jeux de test sont produits aléatoirement ou à partir de spécifications Le code est instrumenté A la fin de lopération de test on obtient une mesure de la couverture atteinte (quon compare au critère darrêt) Approche actuellement présente dans la plupart des outils du marché

44 44 Génération de données (1) Approche « génération a priori » Choix dun chemin permettant datteindre un élément visé, Calcul des entrées permettant lexécution du chemin A la main = coûteux Automatiquement = du domaine de la recherche

45 45 Génération de données basées sur la spécification Un exemple de démarche : à partir de la spec : Identification densemble de données pour lesquelles on suppose que le programme aura un comportement identique = hypothèse de test Exécution du programme avec 1 données par ens. Éventuellement : identification de cas limite Exemple : fonction de débit dun compte Valeur positives, négatives Valeur nulle Valeur entières, relatives Valeur Maximum …

46 46 Génération de données Notion de profil opérationnel Idée : tester en priorité les fonctionnalités Qui seront les plus utilisées Qui sont essentielles Principe Définition dune description statistique Génération des données par rapport à cette description Plus une fonctionnalité sera utilisée/critique, plus on produit de tests

47 47 Rappel Principe du test Techniques relatives au test Arrêt du test Choix des données Correction du résultat (oracle) Conclusion Plan

48 48 On exécute le programme sous test Souvent loracle est humain Erreur dinterprétation Erreur dinattention Automatisation de loracle Faire un programme qui observe lexécution et décide Ce programme « oracle » peut contenir des erreurs Maintenance de ce programme de test Construire une « spécification formelle exécutable » Exemple : assertion en Java Code peut être un copier-coller de lassertion Cette spécification nest généralement pas « complète » Elle peut contenir des erreurs Problème de loracle

49 49 Rappel Principe du test Techniques relatives au test Conclusion Résumé Exercice Plan

50 50 Résumé Points durs du test Choix des données et arrêt du test Problème de loracle Quelques techniques de base Choix des données : pour trouver des erreurs Terminaison : analyse de couverture de la structure du code, de la spécifications, des exigences … Attention : indique que le test nest pas fini Oracle Spécifications formelles exécutables (assertions Java)

51 51 Exercice : longueur dun mot est-elle paire ? Test fonctionnel Quel ensemble de valeur choisir / spécification Test structurel Soit le code dun programme Construire le graphe de contrôle Trouver un ensemble de valeurs permettant de couvrir Les instructions Les branches Les chemins

52 52 Exercice : longueur dun mot est-elle paire ? 1.M <- LireMot 2.L = 0 3.Tant que M[L] != MarqueDeFin faire 4.L = L Fin 6.Ecrire(L contient un nombre) 7.Si (L mod 2) = 0 8.Alors Ecrire(pair) 9.Sinon Ecrire(impair) 10.Ecrire(de lettres) Mot : séquence de caractères + marque de fin rangé dans un tableau de [0..N]

53 53 Exercice : longueur dun mot est-elle paire ? E 3 7 S


Télécharger ppt "Cours de Génie Logiciel Validation (par le test) Lydie du Bousquet Novembre 2004."

Présentations similaires


Annonces Google