Cours Test et Qualité de Logiciels PDF

1 Cours Test et Qualité de Logiciels Responsable du cours : Dr. Ing. Mariam LAHAMI  2 Présentation du module Volume horaire : 26 CI Pré-requis ▫ Programmation orientée objet ▫ Théorie de graphes ▫ Développement Web N...

1 Cours Test et Qualité de Logiciels Responsable du cours : Dr. Ing. Mariam LAHAMI  2 Présentation du module Volume horaire : 26 CI Pré-requis ▫ Programmation orientée objet ▫ Théorie de graphes ▫ Développement Web Note du module ▫ Note contrôle continu: QCM, Projet portant sur un outil de test au choix, travail en classe ▫ Note examen  3 Liste des outils Test unitaire avec TestNG Test de stress avec Jmeter Test de performance avec NeoLoad Automatisation des tests avec selenium, Cypress ou playwright Tests unitaires avec Angular ou React Tests unitaires des applications mobiles Tests des applications basées blockchain BDD testing avec Cucumber Test de service Web avec SOAP UI Robot Framework Testlink ou Xray de Jira etc  4 Contenu du cours Introduction Préparation à la Test dans le cycle de certification ISTQB développement de logiciels Le test unitaire avec JUnit ▫ Cours +TP Les techniques de test ▫ TD sur le test fonctionnel ▫ TD sur le test structurel Inspection et revue de code Test des applications Web avec Spring test  5 A propos de la certification ISTQB Certified Tester Foundation Level (CTFL) v4.0 Syllabus and sample exams : https://www.isIStqb.org/certifications/certified- tester-foundation-level 6  7 Ce cours s’intéresse à la qualité et au test des logiciels 8  9 Sommaire Génie logiciel Utilité de logiciels Crise de logiciels Exemples de bugs informatiques Discussion Test logiciel  10 Qu’est-ce que le génie logiciel (1/4) ? Le génie logiciel est un domaine des sciences de l’ingénieur dont l’objet d’étude est la conception, la fabrication et la maintenance des systèmes informatiques complexes. Cours Génie Logiciel Avancé Yann Régis-Gianas, 2011  11 Qu’est-ce que le génie logiciel (2/4) ? L’art de spécifier, de concevoir, de réaliser, et de faire évoluer, avec des moyens et dans des délais raisonnables, des programmes, des documentations et des procédures de qualité en vue d’utiliser un ordinateur pour résoudre certains problèmes Gaudel et al, 1996 Précis de génie logiciel, Edition Masson.  12 Qu’est-ce que le génie logiciel (3/4) ? L’application des principes de l’ingénierie à la conception des logiciels: l’établissement et l’application des approches méthodiques au développement, à l’opération et à la maintenance des logiciels dans le but d’obtenir des systèmes logiciels économiques, fiables et efficaces dans un contexte de fonctionnement pratique Tony Wong, Ecole Technologique Supérieure, Université du Québec  13 Qu’est-ce que le génie logiciel (4/4) ? Ensembles des activités de conception et de mise en œuvre des produits et des procédures tendant à rationaliser la production du logiciel et de son suivi. Dictionnaire Encyclopédique du Génie Logiciel, Masson, 1997  14 Objectifs du génie logiciel Le génie logiciel vise à garantir que : 1. la spécification répond aux besoins réels de ses clients; 2. le logiciel respecte sa spécification ; 3. les coûts alloués pour sa réalisation sont respectés ; 4. les délais de réalisation sont respectés.  15 Utilité du logiciel (1/2) Le logiciel est omniprésent dans nos sociétés ! Le logiciel est de plus en plus critique Le logiciel est de plus en plus complexe  16 Utilité du logiciel (2/2) Le logiciel a amélioré le quotidien de plusieurs manières: Le logiciel accélère les traitements Le logiciel résout des problèmes complexes rapidement Capacité de calcul, de stockage et de traitement incroyables Le logiciel a introduit de nouveaux loisirs ▫ Exemples: Paiement électronique, Achat sur internet, Recherche d’information, Logiciels métier (ERP, tableurs, traitement de texte), des objets connectés, etc.  17 Crise du logiciel (1/4) En dépit des énormes succès, la réputation de l’industrie du logiciel n’est pas si glorieuse que cela: ▫ Dépassement de budget ▫ Dépassement d’échéance ▫ Mauvaises fonctions livrées ▫ Erreurs (bugs) et autres problèmes  18 Crise du logiciel (2/4) Historiquement, il y a eu une prise de conscience dans les années 70, appelée la crise du logiciel, dû à un tournant décisif :  19 Crise du logiciel (3/4) Deux constatations : ▫ Le logiciel n’était pas fiable ▫ Il était incroyablement difficile de réaliser dans des délais prévus des logiciels satisfaisant leurs cahiers des charges  Certains projets n’aboutissent jamais  D’autres aboutissent avec des retards importants et des remises en cause dramatiques  20 Crise du logiciel (4/4) Les symptômes les plus caractéristiques de cette crise sont : ▫ Les logiciels réalisés ne correspondent souvent pas aux besoins des utilisateurs ▫ Les logiciels contiennent trop d’erreurs (qualité du logiciel insuffisante) ▫ Les coûts de développement sont rarement prévisibles et sont généralement prohibitifs ▫ La maintenance des logiciels est une tâche complexe et coûteuse ▫ Les délais de réalisation sont généralement dépassés ▫ Les logiciels sont rarement portables  21 Exemples de bugs informatiques dans l’histoire (1/6) Mariner 1 (1962): La première sonde vers Venus qui s’est perdue dans l’espace Détruite après 294,5 s de son lancement car elle n’est plus controllable La cause: l'omission d'un trait d'union dans le code informatique Fortran  22 Exemples de bugs informatiques dans l’histoire (2/6) Ariane 5 (1996): 37 sec après le décollage, la fusée Ariane 501 (prototype de la version Ariane 5) fut détruite par une explosion La cause: un nombre à virgule flottante originalement codé sur 64 bits a été converti vers un entier signé à 16 bits C’est le bug le plus cher de l’histoire qui a coûté environ 457 million d’euro  23 Exemples de bugs informatiques dans l’histoire (3/6) Therac (1985-1987): appareil canadien servant à traiter le cancer et ayant tué 3 patients d’une surdose de radiation  24 Exemples de bugs informatiques dans l’histoire (4/6) Panne de courant (2003): Une immense panne d'électricité a gravement touché les États et provinces du nord-est de l'Amérique du Nord. Il s'agit de la plus grande catastrophe énergétique de l'histoire du continent, les dommages s'élevant à environ six milliards de dollars américains.  25 Exemples de bugs informatiques dans l’histoire (5/6) Bug du moteur de recherche Google (2009): Google a notifié par erreur ses utilisateurs que chaque site web dans le monde entier était potentiellement dangereux, y compris lui-même  26 Exemples de bugs informatiques dans l’histoire (6/6) la court californienne (2012): un clique de souris au mauvais endroit et ce sont 1200 résidents californiens qui ont été convoqués en tant que jurés au même endroit, au même moment, à un même procès Autres bugs informatiques : https://www.rocketprojet.com/29-bugs-informatiques-catastrophe/  27 Bug de l’an 2024 : Panne mondiale 19 juillet 2024 Tous les PCs ayant Windows comme SE ont cessé de fonctionner à cause d’une mise à jour qui s’est mal passée.  28 Conséquences des bugs Types de conséquences graves des Bugs: ▫ Physique : Blessures ou mort ▫ Financières; Coût de correction, impact sur les utilisateurs ou clients Les acteurs concernés: ▫ L’entreprise ▫ Les utilisateurs finaux Un coût complexe difficile à calculer: ▫ Temps de correction ▫ Pénalités de retard de livraison ▫ Impact commercial en terme de confiance et image de la société …  29 Quelques sources de la crise (1/4) Une idée grossière du logiciel à réaliser est suffisante pour commencer à écrire un programme (il est assez tôt de se préoccuper des détails). => Faux : une idée imprécise du logiciel à réaliser est la cause principale d’échecs  30 Quelques sources de la crise (2/4) Une fois que le programme est écrit et fonctionne, le travail est terminé. => Faux : la maintenance du logiciel représente un travail important : le coût de la maintenance représente plus du 50 % du coût total d’un logiciel  31 Quelques sources de la crise (3/4) Si les spécifications du logiciel à réaliser changent continuellement, cela ne pose pas de problème, puisque le logiciel est un produit souple => Faux : des changements de spécifications peuvent se révéler coûteux et prolonger les délais  32 Quelques sources de la crise (4/4) Si la réalisation du logiciel prend du retard par rapport aux délais prévus, il suffit d’ajouter plus de programmeurs afin de finir dans les délais. => Faux : si l’on ajoute des gens à un projet, il faut compter une période de familiarisation. Le temps passé à communiquer à l’intérieur du groupe augmente également, lorsque la taille du groupe augmente.  33 Selon les études faites par Standish group Plus de 71% des projets informatiques n’aboutissent pas comme ils l’étaient prévus au début.  34 Discussion (1/10) Les critères de réussite lors de développement d’un logiciel Délai Qualité Réussite du Projet Coût  35 Discussion (2/10) Standish Group Chaos Studies 2018. https://laurineautin.fr/pourquoi-votre-projet-informatique-a-86-de-chance-dechouer/  36 Discussion (3/10) Projet réussi : les 3 critères sont atteints. Le projet a été terminé dans les temps, le budget initialement prévu a été respecté et le logiciel comporte les fonctionnalités demandées Projet en difficulté : 2 critères sur 3 sont atteints. Le logiciel a été terminé et fonctionne mais il est en retard sur le planning prévu, a dépassé le budget ou propose moins de fonctionnalités qu’il aurait dû Projet en échec : le projet a été arrêté lors du développement ou il a bien été développé mais n’est pas utilisé  37 Discussion (4/10) Facteurs d’échec Besoins en évolution constante Besoins ambigus Echec Client et non clairs Peu d’ouverture aux propositions technologiques  38 Discussion (5/10) Facteurs d’échec Manque de Client compétences Echec Manque Equipe d’engagement Contrôle insuffisant de la qualité  39 Discussion (6/10) Facteurs d’échec Client Echec Equipe Outils Outils inadéquats  40 Discussion (7/10) Client Facteurs d’échec Évaluation non Equipe précise Echec Manque de Outils contact Gestion du Pas ou peu de projet suivi Mauvaise gestion des risques Tests en environnement de production  41 Discussion (8/10) Client Facteurs d’échec Equipe Echec Outils Budget insuffisant Gestion du projet Recrutement non adéquat Décideurs Manque de moyens Pression sur les plannings  42 Discussion (9/10) Un bon logiciel de point de vue client Livré Peu dans les coûteux délais Respecte Fait ce des critères Un bon qu’on lui de qualité logiciel demande de faire  43 Discussion (10/10) Un bon logiciel de point de vue Fournisseur Fait ce qu’on attend de Minimise lui Minimise le coût les délais Respecte les exigences Un bon Maximise de qualité logiciel les profits  44 Problèmes actuels du génie logiciel(1/4) La taille et la complexité du logiciel : ▫ La complexité fonctionnelle  On demande de plus en plus de fonctionnalités  Les utilisateurs sont de plus en plus exigeants ▫ Les technologies en perpétuelle mutation  Évolution continue  Matériel  logiciels  Technologie (web, mobile,…) ▫ Une complexité architecturale  Architecture répartie en réseaux (client/serveur, …)  Sites distants, …  45 Problèmes actuels du génie logiciel(2/4) La taille croissante des équipes ▫ Des compétences de plus en plus variées  Les fonctionnalités des logiciels sont de plus en plus complexes, une seule personne ne peut pas maîtriser toutes les exigences des utilisateurs Des délais de plus en plus courts  46 Problèmes actuels du génie logiciel(3/4) Des spécifications du logiciel sont peu précises ▫ Les spécifications des besoins :  sont les fondements d’un projet informatique ,  sont une interface difficile entre le domaine métier et l’informatique. ▫ Si elles sont mal expliquées, tout le projet peut échouer.  47 Problèmes actuels du génie logiciel(4/4) L’évolution rapide des applications ▫ Evolution fonctionnelle et technique  Modification des besoins du client  Modification de l’activité du client  Modification de l’environnement technique  48 Discussion 04/10/2024  49 Solution Adoption des techniques de vérification et de validation  50 C’est quoi V&V? Vérification ▫ Le développement est-il correct par rapport à la spécification initiale ? ▫ Est-ce que le logiciel fonctionne correctement? Vérifier que le système répond aux exigences spécifiées  51 C’est quoi V&V? Validation ▫ a-t-on décrit le « bon » système ? ▫ est-ce que le logiciel fait ce que le client veut ? Assurer que le système répondra aux besoins des utilisateurs et des autres parties prenantes dans son (ses) environnement(s) opérationnel(s).  52 Méthodes de V&V Test statique ▫ examen ou analyse du texte ▫ Revue de code, de spécifications, de documents de design Test dynamique ▫ Exécuter le code pour s’assurer d’un fonctionnement correct ▫ Exécution sur un sous-ensemble fini de données possibles Vérification symbolique ▫ Run-time checking ▫ Exécution symbolique Vérification formelle ▫ Preuve ou model-checking d’un modèle formel ▫ Raffinement et génération de code  53 Le test logiciel Test Test statique: dynamique: N’implique pas Implique l'exécution du l'exécution du composant ou du composant ou du système testé système testé Test  54 Importance du test Le test est une activité de V&V dominante et cruciale dans le monde du logiciel: ▫ Le poids de l’activité du test dans l’industrie du logiciel aux USA s’élève à plusieurs dizaines de milliards de dollars par an ▫ En moyenne, le test représente 30% du coût de développement d’un logiciel standard ▫ Pour un logiciel critique (avionique, nucléaire, médical, transport), cette part moyenne monte à 50 %  55 Importance du test Des tests rigoureux des composants et des systèmes, peuvent aider à réduire le risque de défaillances pendant l'exploitation Lorsque des défauts sont détectés et corrigés par la suite, cela contribue à la qualité des composants ou des systèmes. Les tests logiciels peuvent être nécessaires pour répondre à des exigences légales ou à des normes spécifiques de l'industrie.  56 Terminologie Une erreur : c’est une action humaine produisant un résultat incorrect. Un défaut : c’est une imperfection ou une déficience d'un produit d’activités lorsqu'il ne répond pas à ses exigences ou à ses spécifications. Défaillance (failure): Événement dans lequel un composant ou un système n'exécute pas une fonction requise dans les limites spécifiées.  57 Définitions du test Définition de IEEE « Le test est l’exécution ou l’évaluation d’un système ou d’un composant par des moyens automatiques ou manuels, pour vérifier qu’il répond à ses spécifications ou identifier les différences entre les résultats attendus et les résultats obtenus ». (Standard Glossary of Software Engineering Terminology) Le test est une méthode dynamique visant à trouver des bugs «Tester, c’est exécuter le programme dans l’intention d’y trouver des anomalies ou des défauts » G. Myers (The Art of Software testing) Le test est une méthode de validation partielle des logiciels « Tester permet seulement de révéler la présence d’erreurs mais jamais leur absence. » E. W. Dijkstra (Notes on Structured Programming, 1972)  58 Objectifs du test Le test vise à mettre en évidence les erreurs d’un logiciel ▫ Évaluer les produits d’activités ▫ Construire la confiance ▫ Trouver des défaillances et défauts ▫ Prévenir des défauts ▫ Réduire le niveau de risque  59 Objectifs du test Le test n’a pas pour objectif de diagnostiquer la cause des erreurs Le test n’a pas pour objectif de corriger les erreurs Le test n’a pas pour objectif de prouver la correction d’un programme objectif irréaliste : 0 défaut  60 Les 7 principes de test 1. Les tests montrent la présence de défauts mais ne peuvent pas en prouver l'absence. 2. Les tests exhaustifs sont impossibles, utiliser l’analyse des risques et des priorités pour focaliser les efforts de tests. 3. Tester tôt : les activités de tests devraient commencer aussitôt que possible dans le cycle de développement du logiciel ou du système 4. Regroupement des défauts, l’effort de test devrait être fixé proportionnellement à la densité des défauts prévus et constatés dans les différents modules. 5. Paradoxe du pesticide Si les mêmes tests sont répétés de nombreuses fois, le même ensemble de cas de tests ne trouvera plus de nouveaux défauts =>les cas de tests doivent être régulièrement revus et révisés 6. Les tests dépendent du contexte : les logiciels de santé ou de transport critiques seront testés différemment à un site de commerce électronique. 7. L’illusion de l’absence d’erreurs : Si le système conçu est inutilisable et ne comble pas les besoins et les attentes des utilisateurs l'absence de défaut n'est pas d'une grande utilité  61 Question ISTQB: cocher les objectifs de test Donner un niveau de confiance Corriger les défauts Prouver la conformité logicielle Diagnostiquer les défauts Mettre en évidence les défauts d’un logiciel Prouver qu’un logiciel est correct Prévenir les défauts  62 Question ISTQB: lequel des énoncés décrit correctement l’un des 7 principes de test ? En utilisant les tests automatisés, il est possible de tout tester Avec un effort et un support d’outils suffisants, des tests exhaustifs sont réalisables pour tous les logiciels Il est impossible de tester toutes les combinaisons d’entrée et des pré-conditions dans un système Le but des tests est de prouver l’absence des défauts  63 Test vs Débogage  64 Test vs Débogage Test Débogage Test de confirmation Fait par le testeur Fait par le développeur. Fait par le testeur. Dans l’Agile : Le testeur peut Vérifie si les correctifs être impliqué dans le ont résolu les défauts. débogage et les tests de composants.  65 Processus de test fondamental (1/4) Planification Implémentati Analyse et Évaluation et on et Clôture et contrôle conception exécution reporting Les activités de test  66 Processus de test fondamental (2/4) Planification et contrôle des tests: définir les objectifs du test et l'approche retenue pour atteindre les objectifs du test dans le respect des contraintes imposées par le contexte ▫ ex. spécifier les techniques et tâches de test appropriées, et produire un calendrier de test pour respecter une date limite). Analyse et conception de test: l'analyse de test répond à la question « quoi tester ? » alors que la conception des tests répond à la question « comment tester ? ».  67 Processus fondamental de test (3/4) La conception des tests comprend essentiellement les activités suivantes : ▫ Concevoir et prioriser les cas de test et les ensembles de cas de test ▫ Identifier les données de test nécessaires pour les conditions de test et les cas de test ▫ Concevoir l'environnement de test et identifier l'infrastructure et les outils nécessaires  68 Processus fondamental de test (4/4) L'implémentation des tests comprend les activités principales suivantes : ▫ Développer et prioriser les procédures de test, et, éventuellement, créer des scripts de test automatisés ▫ Créer des suites de tests à partir des procédures de test et (le cas échéant) des scripts de tests automatisés ▫ Positionner les suites de tests dans un calendrier d'exécution des tests de manière à obtenir une exécution efficace des tests La clôture des tests comprend les activités principales suivantes : ▫ Vérifier si tous les rapports de défauts sont clôturés, et saisir des demandes de modification ou des items du backlog du produit pour tous les défauts non résolus à la fin de l'exécution des tests ▫ Créer un rapport de synthèse de test à communiquer aux parties prenantes ▫ Finaliser et archiver l’environnement de test, les données de test, l'infrastructure de test et autres testware pour une réutilisation ultérieure  69 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Exemples de cas de test ▫ Un tableau de N entiers non redondants ▫ Un tableau vide ▫ Un tableau de N entiers dont 1 est redondant ▫ Etc.  70 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 1 : On définit un cas test (CT) à exécuter, i.e. un “scénario” que l’on veut appliquer ▫ Un tableau de N entiers non redondants Cas de test  71 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 2 : On concrétise le cas de test en lui fournissant les données de test (DT) ▫ Le tableau [1,0,12,4,41,5] Cas de test [1,0,12,4,41,5] Données de test  72 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 3 : On indique le résultat que l’on attend pour ce CT (prédiction de l’Oracle) ▫ [1,0,12,4,41,5] => [0,1,4,5,12,41] Cas de test [1,0,12,4,41,5] Données de test  [0,1,4,5,12,41] Prédiction de l’oracle  73 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 4 : On exécute le script de test testant le CT sur les DT Cas de test [1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]  [0,1,4,5,12,41] Prédiction de l’oracle  74 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 5 : On compare le résultat obtenu avec le résultat attendu (oracle) Cas de test [1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]  [0,1,4,5,12,41] Prédiction de l’oracle Comparaison  75 Processus de test simplifié Tester ?: réaliser une exécution d’un programme pour y trouver des défauts Exemple: soit un programme pour trier un tableau d’entiers en enlevant les redondances Interface : int[] mon_tri(int[] vec) Etape 6 : On rapporte le verdict final : Pass/Fail, échec/succès Cas de test [1,0,12,4,41,5] Données de test Script de test Résultat [1,0,12,4,41,5]  [0,1,4,5,12,41] Prédiction de l’oracle Comparaison  76 Processus de test simplifié: Résumé  77 Processus de test simplifié: Résumé  78 Exercice 1 Soit la méthode erronée suivante : public static int lastZero ( int [] x ) { for(int i = 0 ; i < x.length ; i++) { if (x [i] == 0) { return i ;} } return -1; } Pour x={0,1,0} ce code provoque une défaillance a) Identifier la faute b) Si possible, Identifier un cas de test qui n’exécute pas la faute c) Si Possible, Identifier un cas de test qui exécute la faute mais n’aboutie pas à une défaillance d) Corrigez la faute et vérifier que le test donné produit maintenant le résultat attendu  79 Exercice 2 Soit la méthode erronée suivante : public static int oddOrPos ( int [] x ) { int count = 0 ; for (int i = 0 ; i < x.length ; i++) { if (x[i]%2 == 1 || x [i] > 0) { count++; } } return count ; } Pour x={-3,-2,0,1,4} ce code provoque une défaillance a) Identifier la faute b) Si possible, Identifier un cas de test qui n’exécute pas la faute c) Si Possible, Identifier un cas de test qui exécute la faute mais n’aboutie pas à une défaillance d) Corrigez la faute et vérifier que le test donné produit maintenant le résultat attendu  80 Exercice 3 Soit la méthode erronée suivante : public static int findLast (int [] x , int y) { for (int i=x.length-1; i > 0 ; i--) { if ( x[i] == y ) { return i ; } } return -1; } Pour x={2,3,5} et y=2 ce code provoque une défaillance a) Identifier la faute b) Si possible, Identifier un cas de test qui n’exécute pas la faute c) Si Possible, Identifier un cas de test qui exécute la faute mais n’aboutie pas à une défaillance d) Corrigez la faute et vérifier que le test donné produit maintenant le résultat attendu  81 Exercice 4 Soit la méthode erronée suivante : public static int countPositive ( int [] x ) { int count = 0 ; for (int i =0; i < x.length ; i++) { if ( x [i] >= 0 ) { count++; } } return count ; } Pour x={-4,2,0,2} ce code provoque une défaillance a) Identifier la faute b) Si possible, Identifier un cas de test qui n’exécute pas la faute c) Si Possible, Identifier un cas de test qui exécute la faute mais n’aboutie pas à une défaillance d) Corrigez la faute et vérifier que le test donné produit maintenant le résultat attendu 82  83 Sommaire Le cycle de vie d’un logiciel Méthodes classiques Méthodes agiles  84 Le cycle de vie d’un logiciel On appelle cycle de vie d’un logiciel l’ensemble des étapes à suivre lors de la création du logiciel ainsi que leur enchaînement  85 Les étapes du cycle de vie d’un logiciel Expression des besoins : Développer ou Acheter ou Louer ? Spécification : Fonctions métiers ? Analyse et Conception (Modélisation) : Modèles ? Implémentation : Codes sources ? Test de vérification : Erreurs de programmation et du métier ? Validation : Taux de satisfaction du client par le logiciel développé ? Maintenance et Evolution  86 Les étapes du cycle de vie d’un logiciel Expression des besoins : Choix d’une solution d’automatisation du SI ? Spécification : Choix d’une approche de développement de logiciels ? Analyse : Choix d’une méthode d’analyse et de conception et d’un AGL? Conception : Choix des architectures et du SGBD ? Implémentation : Choix des outils de développement de logiciels ? Test de vérification : Choix d’un outil de test ? Validation Maintenance et Evolution  87 Le cycle de vie d’un logiciel Deux méthodes existent: Méthodes Méthodes classiques agiles Cascade Scrum En V XP Incrémental Spirale  88 Les tests dans le cycle en cascade Un des premiers modèles qui a été proposé Il date des années 70 Séquentiel Ce modèle est strict et lourd Chaque phase doit être approuvée avant de pouvoir commencer l'autre  89 Les tests dans le cycle en cascade Avantages Inconvénients Chaque phase est finie, elle est Modèle trop séquentiel donc gérable tant au niveau – dure trop longtemps du temps que des ressources Faible implication du client Le code est créé assez Validation trop tardive : les tardivement, il y a donc une tests sont prévus bonne compréhension du tardivement et remise en système question coûteuse des phases précédentes Fonctionne très bien quand la Sensibilité à l'arrivée de qualité est plus importante nouvelles exigences que les coûts et les délais – refaire toutes les étapes  90 Les tests dans le cycle en cascade Quand l’utiliser ? Réponse: Quand les besoins sont connus et stables Quand la technologie à utiliser est maîtrisée Lors de la création d’une nouvelle version d’un produit existant Lors du portage d’un produit sur une autre plateforme  91 Les tests dans le cycle en V Le modèle du cycle en V a été imaginé pour pallier le problème de réactivité du modèle en cascade  92 Les tests dans le cycle en V: caractéristiques Tâches effectuées en parallèle – horizontalement : préparation de la vérification ▫ Ex. : dès que la spécification fonctionnelle est faite : (↑)  plan de tests de qualification  plan d'évaluation des performances  documentation utilisateur – verticalement : développement des modules ▫ Ex. : dès que la conception globale est validée : (↑)  conception détaillée des modules  programmation et tests unitaires  93 Les tests dans le cycle en V Avantages Inconvénients Met l’accent sur les tests et la Ne gère pas les activités validation et par conséquent, parallèles ça accroît la qualité du logiciel Ne gère pas explicitement Chaque livrable doit être testable les changements des spécifications Facile à planifier dans une gestion de projets Ne contient pas d’activités d’analyse de risque Facile à utiliser  94 Les tests dans le cycle en V Quand l’utiliser ? Réponse: Quand le produit à développer a de très hautes exigences de qualité Quand les besoins sont connus à l’avance Les technologies à utiliser sont connues à l’avance  95 Les tests dans le cycle par incrément Dans ce modèle, un seul composant est développé à la fois On débute par définir les exigences et on les décompose le logiciel en sous-systèmes À chaque version du logiciel, de nouvelles fonctionnalités venant combler les exigences sont ajoutées On continue de la sorte jusqu'à ce que toutes les fonctionnalités demandées soient comblées par le système Chaque incrément peut utiliser un autre modèle (v, en cascade...)  96 Les tests dans le cycle par incrément Expression des besoins Incrément 1 Conception de Codage Test Maintenance Spécification l’incrément Incrément i Conception Conception de système Codage Test Maintenance l’incrément Incrément n Conception de Codage Test Maintenance l’incrément  97 Les tests dans le cycle par incrément Le développement est ainsi moins complexe, L'intégration est moins brutale et le client a plus rapidement un système même s'il n'est pas complet Ce modèle convient aux gros projets complexes L'architecture doit être bien pensée dès le départ afin de réduire les risques par la suite.  98 Les tests dans le cycle par incrément Avantages Inconvénients Développement de Exige une bonne fonctionnalités à risque en planification et une bonne premier conception Chaque incrément donne un produit fonctionnel Exige une vision sur le Le client intervient à la fin de produit final pour pouvoir le chaque incrément diviser en incréments Utiliser l’approche « diviser pour mieux régner » Le coût total du système Le client entre en relation avec peut être cher le produit très tôt  99 Les tests dans le cycle par incrément Quand l’utiliser ? Réponse: Quand la plupart des spécifications sont connues à l’avances et vont être sujettes à de faibles évolutions Quand on veut rapidement un produit fonctionnel Pour des projets de longues durées Pour des projets impliquant de nouvelles technologies  100 Les tests dans le cycle itératif Ce modèle est inspiré de la roue de Deming qui est une approche itérative dont le but est d'améliorer en permanence la qualité Elle se compose de 4 étapes : Plan, Do, Check, Act (PDCA)  101 Les tests dans le cycle itératif Elle se compose de 4 étapes : Plan, Do, Check, Act (PDCA) ▫ Plan : ce que l'on prévoit de faire, étude la faisabilité, spécifications ▫ Do : on imagine comment on va le réaliser : élaboration, architecture ▫ Check : vérification et mesure des risques ▫ Act : tests, validation et livraison au client  102 Les tests dans le cycle en spirale C’est un cycle itératif et incrémental => On réalise une mini Cascade à chaque itération  103 Les tests dans le cycle en spirale Avantages Inconvénients Identification rapide des L’évaluation des risques peut risques prendre beaucoup de temps Impacts minimaux des Le modèle est très complexe risques sur le projet La spirale peut s’éterniser Fonctions critiques développées en premier Les développeurs doivent être réaffectés pendant les phases Feedback rapide du client de non-développement Une évaluation continue du Les objectifs ne sont pas procédé souvent faciles à formuler  104 Synthèse sur les tests dans le cycle de vie d’un logiciel Interpréter ce graphique Plus la détection des fautes est tardive plus que le coût de la maintenance est élevé Constatation : Les cycles itératifs et incrémentaux sont meilleurs car ils évitent la détection tardive des erreurs  105 Tests dans les méthodes agiles La notion de méthode agile a été officialisée en 2001 par un document, le Manifeste Agile (Agile Manifesto), signé par 17 chefs de projets But: résoudre la lourdeur des processus classiques Caractéristiques: ▫ Méthodes itératives et incrémentales ▫ Petites et fréquentes livraisons ▫ Accent sur le code et moins sur la documentation ▫ Convient aux projets de petite et moyenne taille Exemple de méthodes: ▫ Scrum (1996) ▫ eXtreme Programming XP (1999)  106 Tests dans les méthodes agiles Quatre valeurs fondamentales: Logiciels Individus et fonctionnels au lieu interactions au lieu d’une de processus et documentation outils massive Collaboration du Réagir aux client au lieu de changements au lieu négociation de de suivre le plan contrat  107 Tests dans les méthodes agiles Les 12 principes agiles: 1. Toujours satisfaire le client à travers des livraisons rapides et continues 2. Bien accueillir tous les changements même les tardifs 3. Livrer fréquemment un système fonctionnel 4. Les clients et les développeurs doivent collaborer 5. Conduire le projet autour d’équipes motivées 6. La meilleure méthode de faire circuler l’information c’est le contact direct entre collaborateurs 7. La première mesure d’avancement c’est un logiciel fonctionnel 8. Le développement doit être durable et à un rythme constant 9. La bonne conception et l’excellence technique augmentent l’agilité 10. Simplifier au maximum 11. Les meilleurs architectures, besoins et conceptions proviennent d’équipes qui s’organisent d’elles-mêmes 12. L’équipe s’améliore d’une manière autonome et régulière  108 Tests dans les méthodes agiles: Test Driven Development (TDD) En français, Développement Piloté par les Tests C’est une pratique basée sur: L’écriture des Les tests tests par les unitaires développeurs L’écriture des tests avant le code  109 Tests dans les méthodes agiles: Test Driven Development (TDD) Le cycle préconisé par TDD comporte cinq étapes : Écrire le Refactoriser tout Ecrire un Vérifier Vérifier code premier qu’il que le test en gardant le satisfaisan test échoue passe fonctionnement t le test  110 Tests dans les méthodes agiles: Test Driven Development (TDD) Ceci facilite la production d'un code valide en toutes circonstances et on obtient donc un code plus juste et plus fiable. En écrivant les tests d'abord, on utilise le programme avant même qu'il existe et On s'assure ainsi que le code produit est testable unitairement Il est donc impératif d'avoir une vision précise de la manière dont on va utiliser le programme avant même d'envisager son implémentation Cela évite souvent des erreurs de conception dues à une précipitation dans l'implémentation avant d'avoir défini les objectifs  111 Tests dans les méthodes agiles: eXtreme Programming Les fondamentaux de cette méthodologie Test Itération Implication Programma unitaire courte et massive du tion par continu livraison client paires (TDD) rapide  112 Tests dans les méthodes agiles: eXtreme Programming Principales activités Conception Codage Tests Ecoute ( le (pendant le client ou le (encore (noyau XP) codage) partenaire) basée sur le codage)  113 Synthèse Méthodes Caractéristiques Méthodes classiques Modèles stricts Étapes très clairement définis Documentation très fournie Fonctionne bien avec les grands projets Méthodes agiles Modèles itératives et incrémentaux Petites et fréquentes livraisons Accent sur le code et moins sur la documentation Convient aux moyens et petits projets Implication forte du client  114 Synthèse  115 Synthèse  116 Synthèse  117 Synthèse 118  119 Sommaire Classification des tests Difficulté des tests Méthodes de tests ▫ Test fonctionnel ▫ Test structurel  120 Classification des tests  121 Classification des tests: le niveau dans le cycle de développement Tests unitaires (ou test de composant): s'assurer que les composants logiciels pris individuellement sont conformes à leurs spécifications et prêts à être regroupés. Tests d'intégration: s'assurer que les interfaces des composants sont cohérentes entre elles et que le résultat de leur intégration permet de réaliser les fonctionnalités prévues. Tests système: s'assurer que le système complet, matériel et logiciel, correspond bien à la définition des besoins tels qu'ils avaient été exprimés.  122 Cône de glace de tests De nombreuses équipes de développement, soumises à des contraintes fortes de délais et de coûts, ont développé de mauvaises pratiques de tests. ▫ La plus connue est sûrement la mauvaise pratique du cône de glace de tests  123 Pyramide des tests  124 Classification des tests: le niveau dans le cycle de développement Tests de recette (Acceptance testing): Test avec des données clients pour vérifier que le système répond aux exigences du client  125 Classification des tests: le niveau dans le cycle de développement Test de régression (Regression testing): sont un sous-ensemble des tests originaux. ▫ Les tests de régression vérifient qu’une modification n’a pas eu d’effets de bord sur le produit ▫ Les tests de régression sont utiles parce que la ré- exécution de tous les tests est très coûteuse  126 Classification des tests: le niveau dans le cycle de développement Test de confirmation: confirmer que le défaut d'origine a été réparé avec succès. ▫ Après la correction d'un défaut, le logiciel doit être testé (retest all) Des tests de confirmation et de régression sont effectués à tous les niveaux de test.  127 Classification des tests: le niveau dans le cycle de développement Alpha-test (alpha testing): test effectué en phase de développement, avant la distribution du produit (→ alpha-versions du produit) Bêta-test (beta testing): test effectué après l'alpha-test, en distribuant le produit (→ des bêta- versions) à un groupe limité d'utilisateurs avertis A/B testing consiste à comparer deux versions d'une application afin de vérifier laquelle est la plus performante  128 Classification des tests  129 Classification des tests: Sélection de tests Deux grandes familles de tests Test fonctionnel (ou test en boîte noire) ▫ Ne nécessite pas une connaissance de la structure interne du système Test structurel (ou test en boîte blanche) ▫ La structure interne du système doit être accessible  130 Sélection de tests :Test fonctionnel  131 Sélection des tests :Test fonctionnel Black-box testing  132 Sélection des tests : Test structurel  133 Sélection des tests: Comparaison (1/2) Test fonctionnel Test structurel (+) taille des spécifications, (+) description précise, facilité oracle facilité script de test (+) détectent plus facilement (+)détectent plus les erreurs d’omission et de facilement les erreurs spécification commises (- ) spécifications parfois peu (- ) oracle difficile, précises, concrétisation manque d’abstraction des DT  134 Sélection des tests: Comparaison (2/2)  135 Couverture fonctionnelle La couverture fonctionnelle est la mesure selon laquelle un certain type d'élément fonctionnel a été exercé par des tests. Elle est exprimée en pourcentage du ou des types d'éléments couverts. Par exemple, en utilisant la traçabilité entre les tests et les exigences fonctionnelles, le pourcentage de ces exigences qui sont couvertes par les tests peut être calculé, identifiant potentiellement des lacunes de couverture.  136 Couverture structurelle La couverture structurelle est la mesure dans laquelle un certain type d'élément structurel a été exercé par des tests et est exprimée en pourcentage du type d'élément couvert. Au niveau du test des composants, la couverture du code est basée sur le pourcentage de code du composant qui a été testé. Au niveau des tests d'intégration des composants, les tests de boîte-blanche peuvent être basés sur l'architecture du système, comme les interfaces entre composants, et la couverture structurelle peut être mesurée en terme de pourcentage d'interfaces exercées par les tests.  137 Classification des tests  138 Test de performance  139 Test de stress Consiste à exciter le système au delà de ses capacités nominales Vise à tester le bon comportement du système dans les situations de surcharge ou également à détecter la façon et l'instant auquel le système échoue dans ce genre de situations Exemples de situations extrêmes: dépasser les capacités de stockage, envoyer un très grand nombre de requêtes à une base de données, etc.  140 Test de sécurité Consiste à tester la vulnérabilité du système à être pénétré ou attaqué par un autre programme malveillant Vise à tester également si le système est en mesure de se protéger contre les accès internes ou externes non autorisés Permet aussi de tester si la base de données du système est accessible depuis l'extérieur ou non  141 Application Remplir ce tableau Test Portée Catégorie Exécutant Unitaire Intégration Fonctionnel Système Acceptation Bêta Régression  142 Application Test Portée Catégorie Exécutant Unitaire Petites portions de code blanche Développeur/ source Machine Intégration Classe/Composant/ Blanche/noire Développeur service Fonctionnel Produit Noire Testeur Système Produit / Noire Testeur environnement simulé Acceptation Produit / Noire Client environnement réel Bêta Produit / Noire Client environnement réel Régression N’importe quel Blanche/ noire N’importe  143 Difficultés du test (1/2) Le test exhaustif est en général impossible à réaliser En test fonctionnel, l’ensemble des données d’entrée est en général infini ou très grande taille Exemple : un logiciel avec 5 entrées analogiques sur 8 bits admet 2^40 valeurs différentes en entrée En test structurel, le parcours du graphe de flot de contrôle conduit à une forte explosion combinatoire => le test est une méthode de vérification partielle de logiciels => la qualité du test dépend de la pertinence du choix des données de test  144 Difficultés du test (2/2) Difficultés d’ordre psychologique ou «culturel» Le test est un processus destructif : un bon test est un test qui trouve une erreur alors que l’activité de programmation est un processus constructif -on cherche à établir des résultats corrects Les erreurs peuvent être dues à des incompréhensions de spécifications ou de mauvais choix d’implantation => L’activité de test s’inscrit dans le contrôle qualité, indépendant du développement  145 Méthodes de tests Test fonctionnel Test structurel Analyse Couverture partitionnelle structurelle Flot de contrôle Test aux limites Flot de données  146 Analyse partitionnelle Principe : diviser le domaine des entrées en un nombre fini de classes tel que le programme réagisse de la même façon pour toutes les valeurs d’une classe But: vise à diminuer le nombre de cas de tests par calcul de classes d’équivalence =>évite des tests redondants (si classes bien identifiées) => il ne faut tester qu’une valeur par classe !  147 Analyse partitionnelle  148 Analyse partitionnelle Procédure : 1. Analyser les exigences pour identifier d’une part les entrées du programme et leurs domaines, et d’autre part les fonctionnalités réalisées 2. Utiliser cette information pour identifier les classes d’équivalence des entrées ▫ Sur la base des conditions sur les entrées/sorties ▫ En prenant des classes d’entrées valides et invalides 3. Définir un ou quelques CTs pour chaque classe  149 Analyse partitionnelle: Exemple 1 Supposons que la donnée à l’entrée est un entier naturel qui doit contenir cinq chiffres, donc un nombre compris entre 10,000 et 99,999. Le partitionnement en classes d’équivalence identifierait alors les trois classes suivantes (trois conditions possibles pour l’entrée): a. ----------------------------------------------------------------------------- b. ----------------------------------------------------------------------------- c. ----------------------------------------------------------------------------- On va alors choisir des cas de test représentatifs de chaque classe, par exemple, au milieu et aux frontières (cas limites) de chacune des classes: a. ------------------------------------------------------------------------------ b. ------------------------------------------------------------------------------ c. ------------------------------------------------------------------------------  150 Analyse partitionnelle: Exemple 1 Supposons que la donnée à l’entrée est un entier naturel qui doit contenir cinq chiffres, donc un nombre compris entre 10,000 et 99,999. Le partitionnement en classes d’équivalence identifierait alors les trois classes suivantes (trois conditions possibles pour l’entrée): a. N < 10000 b. 10000 2 au lieu de X ≥ 2 ▫ Erreur de borne : X + 2 = y au lieu de X + 3 = y ▫ Échange de paramètres : 2x + 3y > 4 au lieu de 3x + 2y >4 ▫ Ajout d’un prédicat qui ferme un ensemble : (2x > 4) et (3x < 6) ▫ Frontière manquante : (x + y > 0) ou (x + y