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)

Présentations similaires


Présentation au sujet: "Cours de Génie Logiciel Validation (par le test)"— Transcription de la présentation:

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

2 Liste des interventions
Introduction Philippe Lalanda Cas d'étude : Ariane 5 Yves Ledru Les cycles de vie Pierre-Yves Cunin Spécifications en logiciel Philippe Lalanda Conception logicielle Philippe Lalanda Validation Lydie du Bousquet La génération de code Jean-Marie Favre UML : Principes 1 Philippe Lalanda UML : Principes 2 Philippe Lalanda UML : exemple industriel Didier Pellegrin 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

3 Objectifs du cours d'aujourd'hui
Comprendre ce qu’est la validation Identifier les principales difficultés du « test » de programmes, de logiciels Connaître quelques techniques permettant de tester des programmes 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

4 Plan Rappels Principe du test Techniques relatives au test Conclusion

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

6 Génie Logiciel 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 ! 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

7 Processus logiciels 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 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

8 Vérification et validation (1)
é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 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

9 Vérification et validation (2)
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 ? 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

10 Analyse statique Quelques techniques revue de code, relecture croisée
Tests Preuve model-checking preuves déductives 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

12 Définition du test Tester un logiciel, c'est : Maîtrise des entrées
exécuter le logiciel en maîtrisant les données en entrée en s’assurant 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 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

14 Pourquoi tester ? C’est la question clé
Pourquoi est-ce que vous testez ? 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

15 Pourquoi tester ? (2) On attend du logiciel certaines propriétés
adéquation aux besoins absence d’erreur, robustesse, performances, ... Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un avion qui n’a jamais été testé en vol mais dont les fabricants vous garantissent qu’ils ont «!prouvé!» que tout allait bien se passer ? 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

16 Pourquoi tester ? (2) On attend du logiciel certaines propriétés
adéquation aux besoins absence d’erreur, robustesse, performances, ... Preuves formelles ou autres techniques Pas toujours possibles Pas toujours convaincantes Est-ce que vous accepteriez de monter dans un avion qui n’a jamais été testé en vol mais dont les fabricants vous garantissent qu’ils ont «!prouvé!» que tout allait bien se passer ? 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

17 Pourquoi tester ? (3) 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) 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

18 Types de tests On caractérise l’activité 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 d’intégration Test système Test d’acceptation (ou de recette) Test de non-régression 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

19 Types de tests On caractérise l’activité 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 d’intégration Test système Test d’acceptation (ou de recette) Test de non-régression 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

21 Pourquoi le test est difficile (1)
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 s’arrêter ? Difficulté psychologique Programmation : activité constructive Test : activité « destructive » Il est difficile de détruire ce que l’on a construit 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

22 Pourquoi le test est difficile (2) Le choix de données
Test exhaustif Exécuter le logiciel avec toutes les données d’entré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 l’expérience (ensemble de « trucs ») 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

23 Pourquoi le test est difficile (3) Résultat correct ?
Décider si le comportement du programme est correct Problème de l’oracle 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 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis Lagaf Mafalda OK KO

24 Pourquoi le test est difficile (3) Résultat correct ?
Décider si le comportement du programme est correct Problème de l’oracle 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 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis Lagaf G. La Poste

25 Pourquoi le test est difficile (4) Quand s’arrêter ?
Le test n’a pas révélé d’anomalies Absence d’erreur ? Mauvais choix de données ? Le test a révélé des anomalies Existe-t-il d’autres erreurs ? 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

27 Arrêt du test S’assurer que toutes les fonctionnalités ont été testées
Base : cahier des charges; exigences et/ou spécification « Couverture fonctionnelle » S’assurer que tout le code a été exécuté Base : code « Couverture structurelle » Étudier l’évolution du nombre de fautes découvertes Analyse de fiabilité 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

28 Arrêt du test S’assurer que toutes les fonctionnalités ont été testées
Base : cahier des charges; exigences et/ou spécification « Couverture fonctionnelle » S’assurer que tout le code a été exécuté Base : code « Couverture structurelle » Étudier l’évolution du nombre de fautes découvertes Analyse de fiabilité 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

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

31 Mesures de couverture Attention!
Mesure de couverture Soit un critère On s’arrête quand le critère est atteint L’industrie aime Manipulation de données quantitative Peut être outillé Attention : Un critère d’arrêt signifie Tant que le critère n’est pas couvert, on n’est sûr que l’on n’a pas fini de testé Un critère d’arrê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 Couverture des instructions
Objectif : Exécuter au moins une fois toutes les instructions du programme But : Détecter des instructions fautives Justification : Si on n’a pas testé toutes les instructions, on n’a pas testé tout le programme

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 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 n’ont pas été exécutée au moins une fois à vraie et à faux, …

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 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 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 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 n’ité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 d’itération) ou 2 passages (1 itération)

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 Mesures de couverture Attention (bis) !
Un critère d’arrêt signifie Tant que le critère n’est pas couvert, on n’est sûr que l’on n’a pas fini de testé Un critère d’arrê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 Plan Rappel Principe du test Techniques relatives au test Conclusion
Arrêt du test Choix des données Correction du résultat (oracle) Conclusion

42 Il existe de nombreuses méthodes de choix de données
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 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 l’opération de test on obtient une mesure de la couverture atteinte (qu’on compare au critère d’arrêt) Approche actuellement présente dans la plupart des outils du marché

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

45 Génération de données basées sur la spécification
Un exemple de démarche : à partir de la spec : Identification d’ensemble 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 d’un compte Valeur positives, négatives Valeur nulle Valeur entières, relatives Valeur Maximum …

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 d’une 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 Plan Rappel Principe du test Techniques relatives au test Conclusion
Arrêt du test Choix des données Correction du résultat (oracle) Conclusion

48 Problème de l’oracle On exécute le programme sous test
Souvent l’oracle est humain Erreur d’interprétation Erreur d’inattention Automatisation de l’oracle Faire un programme qui observe l’exé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 l’assertion Cette spécification n’est généralement pas « complète » Elle peut contenir des erreurs 1968 NATO conference coined “Software Engineering” to attempt to apply engineering techniques to solve the software crisis

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

50 Quelques techniques de base
Résumé Points durs du test Choix des données et arrêt du test Problème de l’oracle 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 n’est pas fini Oracle Spécifications formelles exécutables (assertions Java)

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

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

53 Exercice : longueur d’un mot est-elle paire ?
1-2 4 3 6 7 8 9 10 S


Télécharger ppt "Cours de Génie Logiciel Validation (par le test)"

Présentations similaires


Annonces Google