Qualité Logicielle PDF

QUALITE LOGICIELLE Préparé par: MAZOUZI Ilyes Année universitaire: 2024-2025  Product Vs Project C’est quoi un logiciel? Un logiciel est un ensemble de programmes informatiques qui nous aident à effectuer une tâche. Typ...

QUALITE LOGICIELLE Préparé par: MAZOUZI Ilyes Année universitaire: 2024-2025  Product Vs Project C’est quoi un logiciel? Un logiciel est un ensemble de programmes informatiques qui nous aident à effectuer une tâche. Types de logiciels : Logiciels système Ex : pilotes de périphériques, système d'exploitation, serveurs, utilitaires, etc. Logiciels de programmation Ex : compilateurs, débogueurs, interprètes, etc. Logiciels d'application Ex : automatisation industrielle, logiciels d'entreprise, jeux, télécommunications, etc. [Tapez ici]  Product Vs Project Si l'application logicielle est développée pour répondre aux besoins spécifiques d'un client, elle est appelée projet. Si l'application logicielle est développée pour répondre aux besoins de plusieurs clients, il s'agit d'un produit. [Tapez ici]  Qu'est-ce que le test logiciel ? Les tests de logiciels font partie du processus de développement de logiciels. Il s'agit d'une activité qui permet de détecter et d'identifier les défauts du logiciel. L'objectif des tests est de fournir un produit de qualité au client.  Pourquoi avons-nous besoin de tests ? S'assurer que le logiciel ne contient pas de bogues. Veiller à ce que le système réponde aux exigences du client et aux spécifications du logiciel. Veiller à ce que le système réponde aux attentes de l'utilisateur final. La correction des bogues identifiés après la sortie du logiciel est coûteuse.  Qualité logicielle La qualité : La qualité est définie comme la justification de toutes les exigences d'un client dans un produit. ✓ Remarque: la qualité n'est pas définie dans le produit. Elle est définie dans l'esprit du client. Un logiciel de qualité est raisonnablement ✓ sans bogues. ✓ Livré dans les délais. ✓ Respecter le budget. ✓ Répondre aux exigences et/ou aux attentes. ✓ être facile à entretenir. Error, Bug, Failure o Error : Toute action humaine incorrecte qui produit un problème dans le système est appelée une erreur. o Bug : l'écart entre le comportement attendu et le comportement réel du système est appelé défaut. o Failure : L'écart identifié par l'utilisateur final lors de l'utilisation du système est appelé défaillance. Pourquoi y a-t-il des bogues dans les logiciels ? Mauvaise communication ou absence de communication Complexité du logiciel Erreurs de programmation Modification des exigences Manque de testeurs qualifiés Etc... Cycle de vie du développement logiciel (SDLC) SDLC, ou cycle de vie du développement logiciel, est un processus utilisé par l'industrie du logiciel pour concevoir, développer et tester des logiciels de haute qualité. L'objectif du SDLC est de produire un logiciel de haute qualité qui répond aux attentes des clients.  SDLC Models Modèle en cascade (Waterfall model) Modèle incremental (Incremental model) Modèle en spirale (Spiral model) Modèle en V Modèle Agile Waterfall model Waterfall model 1. Définition des exigences Description : Recueillir et documenter toutes les exigences fonctionnelles et non fonctionnelles du système. Activités : Réunions avec les parties prenantes, rédaction des spécifications des exigences. Livrables : Document de spécification des exigences (SRS - Software Requirements Specification). 2. Conception du système Description : Créer l'architecture globale du système. Activités : Définition des modules, interfaces et interactions entre les composants. Livrables : Document de conception du système (SDD - System Design Document). 3. Conception détaillée Description : Se concentrer sur la conception détaillée de chaque module ou composant du système. Activités : Création de diagrammes de flux, de diagrammes de classes, etc. Livrables : Document de conception détaillée (DLD - Detailed Design Document). 4. Développement du code Description : Écrire le code source pour chaque module ou composant. Activités : Codage, intégration des modules. Livrables : Code source, modules intégrés. Waterfall model 5. Tests unitaires Description : Vérifier chaque module ou composant individuellement. Activités : Écriture et exécution de tests unitaires. Livrables : Rapports de tests unitaires. 6. Tests d'intégration Description : Tester les modules intégrés pour s'assurer qu'ils fonctionnent correctement ensemble. Activités : Écriture et exécution de tests d'intégration. Livrables : Rapports de tests d'intégration. 7. Tests système Description : Vérifier le système complet pour s'assurer qu'il répond aux exigences spécifiées. Activités : Écriture et exécution de tests système. Livrables : Rapports de tests système.  Waterfall model 8. Tests d'acceptation Description : Valider le système avec les utilisateurs finaux pour s'assurer qu'il répond à leurs attentes. Activités : Écriture et exécution de tests d'acceptation. Livrables : Rapports de tests d'acceptation. 9. Déploiement Description : Mettre en production le système. Activités : Installation, configuration, formation des utilisateurs. Livrables : Système déployé, documentation utilisateur. 10. Maintenance Description : Maintenir et mettre à jour le système après son déploiement. Activités : Correction de bugs, mises à jour, améliorations. Livrables : Mises à jour du système, rapports de maintenance.  Waterfall model Avantages du modèle en cascade Inconvénients du modèle en cascade Quand utiliser le modèle en cascade ? Simplicité et facilité d'utilisation. Manque de flexibilité pour revenir en Lorsque les exigences sont bien comprises arrière. et stables. Structure claire, avec des phases bien Mauvaise adaptabilité aux changements. Pour des projets de courte durée et définies. simples. Forte documentation, facilitant la Tests tardifs, ce qui peut retarder la Quand l'équipe préfère un suivi rigide et maintenance future. découverte de défauts. documenté. Adapté aux petits projets avec des Pas adapté aux projets complexes ou à exigences stables. long terme. Quand les exigences ne risquent pas de changer en cours de projet. Incremental model Incremental model Qu’est-ce que le développement itératif ? Le développement itératif consiste à répéter le cycle de développement plusieurs fois, chaque itération ajoutant de nouvelles fonctionnalités ou affinant celles déjà existantes. Chaque itération se base sur la précédente, en intégrant les retours d’expérience et les modifications pour améliorer le logiciel. Cette approche permet une flexibilité et une adaptabilité, car les exigences peuvent évoluer au fil du temps. Qu'est-ce que le développement incrémental ? Le développement incrémental consiste à livrer le logiciel par petites versions progressives. Chaque version comprend un sous-ensemble des fonctionnalités finales, permettant au logiciel d’être testé et utilisé par les parties prenantes dès les premières étapes du processus de développement. Cette approche permet un retour d'information et une validation des exigences plus rapides, réduisant ainsi le risque de livrer un produit qui ne correspond pas aux besoins des utilisateurs.  Incremental model Comment fonctionnent-ils ensemble ? La procédure de développement du logiciel est divisée en petites itérations ou incréments dans ce paradigme. Chaque itération implique la création d’un composant compact et fonctionnel du système logiciel. Les itérations permettent le raffinement progressif du logiciel grâce aux retours d’expérience et à l’amélioration continue. Les incréments fournissent une approche structurée pour ajouter de nouvelles fonctionnalités au logiciel, permettant une livraison incrémentale de la valeur aux utilisateurs. Ensemble, les itérations et les incréments permettent un processus de développement flexible et adaptatif qui peut répondre aux changements d’exigences, de technologies et de conditions du marché. Incremental model Les phases suivantes sont typiques du modèle itératif incrémental : 1. Planification 2. Analyse des exigences et de conception 3. Mise en œuvre 4. Test 5. Évaluation 6. Livraison incrémentale  Incremental model Avantages du modèle Inconvénients du modèle Quand utiliser le modèle incrémental/itératif incrémental/itératif incrémental/itératif ? Livraison progressive des fonctionnalités. Plus complexe à gérer en raison des Lorsque les exigences ne sont pas multiples cycles. complètement définies. Flexibilité pour intégrer les changements Difficile d’estimer précisément les coûts Pour des projets longs ou complexes avec en cours de projet. et le temps. des risques élevés. Amélioration continue grâce aux retours Demande une bonne coordination entre Lorsqu'on souhaite fournir des versions des utilisateurs. les équipes. fonctionnelles tôt. Meilleure gestion des risques à travers Peut ralentir le processus si les itérations Pour des projets avec des exigences des tests précoces. sont mal gérées. évolutives. Note: Ce modèle est plus adapté pour les projets où l'on doit itérer et ajuster au fur et à mesure, en particulier lorsque les exigences ne sont pas claires dès le départ ou évoluent pendant le projet Spiral Model Définition : Modèle en spirale : le modèle en spirale est un mode opératoire de développement logiciel inventé par Barry W. Boehm en 1986. Il part du principe que le développement d'applications représente un cycle itératif, qui doit être répété jusqu’à ce que le but fixé soit atteint. Par une analyse régulière des risques et des contrôles réguliers du produit intermédiaire, le modèle en spirale diminue considérablement le risque d’échec lors des projets logiciels de grande taille. Les problèmes survenant dans le cadre du processus de développement d’un logiciel peuvent avoir des conséquences très variées sur le projet dans son ensemble. Il faut s'attendre dans tous les cas à une augmentation des coûts, à des efforts supplémentaires et à un retard dans la sortie du logiciel - des facteurs qui peuvent vite se transformer en problème existentiel, surtout pour les petits éditeurs. Avec son approche incrémentielle et itérative - qui comprend aussi une évaluation régulière des risques sous forme d'ébauches de prototype, d’analyses ou de simulations - le modèle en spirale est censé éviter les scénarios de ce genre ou, du moins, en atténuer les répercussions négatives. Le projet logiciel suit donc continuellement le cycle du modèle en spirale jusqu'à l’état final, en passant normalement par les quatre étapes suivantes :  Spiral Model 1. Détermination des objectifs Description : Définir les objectifs, les contraintes et les alternatives pour le cycle de développement actuel. Activités : Identification des objectifs spécifiques, des contraintes et des alternatives possibles. Livrables : Document de définition des objectifs. 2. Analyse des risques Description : l'identification, l'analyse et la planification des risques. Activités : Identification des risques, évaluation de leur impact et planification des mesures d'atténuation. Livrables : Plan de gestion des risques. 3. Développement et validation Description : Cette étape consiste à développer une version du produit et à la valider. Activités : Conception, codage, tests et validation de la version actuelle du produit. Livrables : Version du produit, rapports de tests, documentation. 4. Planification de la prochaine itération Description : Cette étape implique la planification de la prochaine itération en fonction des résultats de la validation. Activités : Évaluation des résultats, identification des améliorations nécessaires, planification de la prochaine itération.  Spiral Model Livrables : Plan de la prochaine itération. 5. Répétition des cycles Description : Le modèle en spirale est itératif. Les étapes ci-dessus sont répétées pour chaque cycle de développement jusqu'à ce que le produit final soit atteint. Activités : Répétition des étapes de détermination des objectifs, analyse des risques, développement et validation, et planification de la prochaine itération. Livrables : Versions successives du produit, rapports de tests, documentation mise à jour. Note : Le modèle en spirale est flexible et peut être combiné avec d'autres modes opératoires. Les quatre phases fixent les objectifs fondamentaux d’un cycle, mais leur ordre et leur présence à chaque cycle ne sont pas strictement spécifiés. Spiral Model  Spiral Model Avantages Inconvénients Quand utiliser ✓ Réduction des risques grâce à une analyse régulière Peut-être coûteux en termes de temps et de des risques. ressources. Projets de grande taille et complexes. Nécessite une expertise et une gestion Projets nécessitant une gestion stricte ✓ Contrôle continu du produit intermédiaire. rigoureuse. des risques. Peut-être complexe à mettre en œuvre pour les Projets où les exigences peuvent ✓ Flexibilité et adaptabilité aux changements. petits projets. évoluer. ✓ Permet une évaluation régulière des alternatives et Peut nécessiter des ressources supplémentaires Projets nécessitant une évaluation des stratégies. pour les prototypes. continue des alternatives. ✓ Convient bien pour les projets de grande taille et Peut entraîner des retards si les cycles ne sont complexes. pas bien gérés. Projets avec des risques élevés. Peut être difficile à suivre pour les équipes Projets nécessitant une gestion ✓ Facilite la gestion des coûts et des délais. inexpérimentées. rigoureuse des coûts et des délais. V- Model Qu’est-ce que le cycle en V ? Le cycle en V en gestion de projet se sert d’un processus linéaire divisé en phases bien définies. Apparu dans les années 1970, il a été développé pour remplacer le modèle en cascade. Le cycle en V pour les projets informatiques a été largement utilisé dans les années 1990 et a été ajusté plusieurs fois depuis. Il se représente comme un V, avec deux lignes se rejoignant en une pointe. Sur le côté gauche du V, les exigences sont décrites (phase descendante), et sur le côté droit, des tests de validation sont menés parallèlement à chaque étape (phase ascendante). Quelles sont les étapes de la méthode cycle en V ? 1. Définition des exigences Description : Recueillir et documenter toutes les exigences fonctionnelles et non fonctionnelles du système. Activités : Réunions avec les parties prenantes, rédaction des spécifications des exigences. Livrables : Document de spécification des exigences (SRS - Software Requirements Specification). 2. Conception du système Description : Création de l'architecture globale du système. Activités : Définition des modules, interfaces et interactions entre les composants. Livrables : Document de conception du système (SDD - System Design Document). V- Model 3. Conception détaillée Description : La conception détaillée de chaque module ou composant du système. Activités : Création de diagrammes de flux, de diagrammes de classes, etc. Livrables : Document de conception détaillée (DLD - Detailed Design Document). 4. Développement du code Description : Ecrire le code source pour chaque module ou composant. Activités : Codage, intégration des modules. Livrables : Code source, modules intégrés. 5. Tests unitaires Description : La vérification de chaque module ou composant individuellement. Activités : Écriture et exécution de tests unitaires. Livrables : Rapports de tests unitaires. 6. Tests d'intégration Description : Tester les modules intégrés pour s'assurer qu'ils fonctionnent correctement ensemble. Activités : Écriture et exécution de tests d'intégration. Livrables : Rapports de tests d'intégration.  V- Model 7. Tests système Description : La vérification du système complet pour s'assurer qu'il répond aux exigences spécifiées. Activités : Écriture et exécution de tests système. Livrables : Rapports de tests système. 8. Tests d'acceptation Description : Valider le système avec les utilisateurs finaux pour s'assurer qu'il répond à leurs attentes. Activités : Écriture et exécution de tests d'acceptation. Livrables : Rapports de tests d'acceptation. 9. Déploiement Description : La mise en production du système. Activités : Installation, configuration, formation des utilisateurs. Livrables : Système déployé, documentation utilisateur. 10. Maintenance Description : Maintenir et mettre à jour le système après son déploiement. Activités : Correction de bugs, mises à jour, améliorations. V- Model  V- Model Aspect Avantages Inconvénients Quand utiliser - Les risques peuvent être identifiés et - Les risques liés aux changements - Projets avec des risques bien Gestion des risques gérés tôt dans le cycle de vie. tardifs peuvent être élevés. identifiés et gérables. - Les erreurs peuvent être - Peut conduire à une meilleure qualité découvertes tardivement dans le - Projets où la qualité du produit final Qualité du produit final. cycle de vie. est une priorité absolue. - Projets avec de nombreuses parties - Facilite la communication entre les - Peut nécessiter une communication prenantes nécessitant une Communication parties prenantes. constante et détaillée. communication claire. - Moins flexible que les méthodes - Difficile à adapter aux changements - Projets avec des exigences stables et Flexibilité agiles. fréquents. peu de changements attendus. - Les coûts peuvent être mieux planifiés - Peut être coûteux en termes de - Projets avec des budgets bien définis Coût et contrôlés. temps et de ressources. et contrôlés. - Projets avec des délais bien définis Temps de - Permet une estimation précise du - Peut être plus long en raison de la et des phases de développement développement temps de développement. phase de planification détaillée. claires. V- Model Conclusion : Le cycle en V est une méthode structurée et linéaire qui convient bien aux projets simples et de petite taille. Il permet une validation continue des phases de conception grâce à des tests parallèles, assurant ainsi une meilleure gestion des risques et des coûts. Agile Model Définition: Le modèle Agile est une approche de gestion de projet qui met l'accent sur la flexibilité, la collaboration, l'itération rapide et la livraison continue de valeur. Il est particulièrement populaire dans le développement de logiciels, mais il peut être appliqué à divers types de projets. Agile Model Valeurs de l’agile : Les individus et leurs interactions plus que les processus et les outils. Des logiciels opérationnels plus qu’une documentation exhaustive. La collaboration avec les clients plus que la négociation contractuelle. L’adaptation au changement plus que le suivi d’un plan Agile Model Agile Model Principes de l’agile : 1. Satisfaction du client : Livrer rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. 2. Adaptabilité : Accueillir positivement les changements de besoins, même tard dans le développement. 3. Livraison fréquente : Livrer fréquemment un logiciel opérationnel avec des cycles courts (quelques semaines à quelques mois). 4. Collaboration quotidienne : Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement. 5. Motivation et confiance : Réaliser les projets avec des personnes motivées, leur fournir l’environnement et le soutien nécessaires, et leur faire confiance. 6. Communication en face à face : La méthode la plus efficace pour transmettre de l’information est le dialogue en face à face. Agile Model 7. Mesure de progression : Un logiciel opérationnel est la principale mesure de progression. 8. Rythme de développement soutenable : Encourager un rythme de développement soutenable pour tous les participants. 9. Excellence technique : Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité. 10. Simplicité : La simplicité est essentielle pour minimiser la quantité de travail inutile. 11. Auto-organisation : Les meilleures architectures, spécifications et conceptions émergent d’équipes auto- organisées. 12. Amélioration continue : À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace et ajuste son comportement en conséquence.  Agile Model Méthodologies Agile Il existe plusieurs méthodologies Agile, chacune avec ses propres pratiques et outils. Les plus courantes sont : Scrum : Une méthodologie qui utilise des rôles spécifiques (Scrum Master, Product Owner, équipe de développement), des réunions régulières (Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective) et des cycles de développement courts appelés "sprints". Kanban : Une méthodologie qui se concentre sur la gestion visuelle du flux de travail et l'amélioration continue. Elle utilise des tableaux Kanban pour suivre les tâches à travers différentes étapes de développement. Extreme Programming (XP) : Une méthodologie qui met l'accent sur la qualité du code et les pratiques de développement, comme le pair programming, les tests unitaires, et les refactorisations fréquentes.  Agile Model Lean : Une méthodologie qui se concentre sur l'élimination des gaspillages et l'optimisation du flux de valeur. Agile Model  QA Vs QC Vs QE QA (Quality Assurance) ➔ Objectif : Prévenir les défauts. Le but est d'assurer que les processus de développement suivent des normes et des bonnes pratiques pour éviter les problèmes avant qu'ils n'apparaissent. ➔ Orientation : Processus. QA se concentre sur l'amélioration continue des processus de développement et de gestion de projet. ➔ Responsabilité : Tout le monde dans l'équipe de développement est impliqué dans l'assurance qualité. Cela peut inclure la rédaction de politiques, de plans de test, de revues de code, etc. ➔ Exemples d'activités : Revue de processus, audits de qualité, gestion des normes, formation des équipes. QC (Quality Control) ➔Objectif : Identifier les défauts. Le but est de vérifier que le produit ou le logiciel fonctionne correctement et de détecter les erreurs ou défauts après leur apparition. ➔Orientation : Produit. QC se concentre sur l'inspection et les tests du produit fini ou des composants pour s'assurer qu'ils respectent les exigences définies. ➔Responsabilité : Généralement, les équipes de test ou de contrôle de qualité sont directement responsables de cette tâche. ➔Exemples d'activités : Exécution de tests fonctionnels, tests de régression, vérification des résultats par rapport aux attentes, validation des correctifs. QE (Quality Engineering) Ingénierie de la qualité : QE combine les aspects de QA et QC pour garantir la qualité tout au long du cycle de vie du projet. Approche intégrée : QE utilise des pratiques d'ingénierie pour intégrer la qualité dans les processus de développement et de test. Amélioration continue : QE vise à améliorer continuellement les processus et les produits pour garantir une qualité élevée.  Static V/S Dynamic Testing Vérification Validation Les activités impliquées sont la vérification des exigences, la vérification du code Impliquent des tests de système, des tests de fonctionnalité, des tests de et la vérification de la conception. sécurité, des tests de performance, des tests d’utilisation, etc. Ils n’incluent pas l’exécution du code. Ils nécessitent l’exécution du code pour tester la fonctionnalité et la facilité d’utilisation du logiciel. Répondre à la question suivante : “Développez-vous le bon produit ? Répondre à la question suivante : “Le produit développé est-il correct et répond-il aux exigences du client ? Il s’agit d’une vérification humaine des fichiers et des documents. Il s’agit d’une exécution informatique du programme. La vérification est un exercice de bas niveau qui précède la validation. La validation est un exercice de haut niveau qui permet de détecter les erreurs qui n’ont pas été détectées lors de la vérification. L’équipe chargée de l’assurance qualité vérifie que le logiciel est réalisé La validation est effectuée après l’étape de vérification et implique l’équipe de conformément aux spécifications de conception définies dans le document. test. La vérification réduit les défauts ou les bogues à un stade précoce. La validation détecte les bogues qui n’ont pas été détectés lors de la phase de vérification. Static V/S Dynamic Testing Les tests statiques sont une approche pour tester les documents de projet sous forme de revues, d'examens et d'inspections.( inspection de code / spécifications fonctionnelles) Les tests dynamiques sont une approche pour tester le logiciel réel en fournissant des entrées et en observant les résultats. (tests fonctionnels / performance/ uat) Static V/S Dynamic Testing Review, Walkthrough & Inspection Reviews (Revue): Effectué sur les documents pour assurer leur exactitude et leur exhaustivité. Exemple: ▪ Revues des exigences ▪ Revues de conception ▪ Revues de code ▪ Revues des plans de test ▪ Revues des cas de test, etc.  Walkthroughs (Présentation): Processus informel où l'auteur guide les participants. Vise à partager des connaissances et obtenir des retours. Inclut des démonstrations et des explications. Permet une interaction directe et des questions.  Inspections: ✓ Processus formel et structuré d'examen. ✓ Implique une équipe dédiée avec des étapes spécifiques. ✓ Objectif : détecter défauts et assurer conformité aux normes. ✓ Plus rigoureuse que les revues et les walkthroughs. Niveaux des tests logiciels Tests unitaires Tests d’intégration Tests du système Tests d’acceptance (UAT) Unit Testing Une unité est la plus petite partie testable d'un logiciel. Elle a généralement une ou quelques entrées et généralement une seule sortie. Les tests unitaires sont effectués sur un seul programme ou un seul module. Les tests unitaires sont une technique de test en boîte blanche. Les tests unitaires sont réalisés par les développeurs. Integration Testing Dans les tests d'intégration, les modules logiciels individuels sont intégrés logiquement et testés en groupe. Les tests d'intégration se concentrent sur la vérification de la communication des données entre ces modules. Les tests d'intégration sont une technique de test en boîte blanche. Les tests d'intégration sont réalisés par les développeurs. Approaches: Approche descendante (Top Down Approach) Approche ascendante (Bottom Up Approach) Approche sandwich (hybride) (Sandwich Approach (Hybrid)) Intégration Ascendante Dans la stratégie ascendante, chaque module des niveaux inférieurs est testé avec les modules des niveaux supérieurs jusqu'à ce que tous les modules soient testés. Elle utilise des pilotes pour les tests. Exemple : Système de Gestion de Bibliothèque Supposons que nous avons un système de gestion de bibliothèque composé de trois modules : 1. Module C : Gestion des Livres Fonctionnalités : Ajouter, supprimer, mettre à jour et rechercher des livres. 2. Module B : Gestion des Emprunts Fonctionnalités : Emprunter, retourner et renouveler des livres. Dépendances : Utilise le module C pour vérifier la disponibilité des livres. 3. Module A : Interface Utilisateur Fonctionnalités : Interface graphique pour les utilisateurs pour interagir avec les modules B et C. Dépendances : Utilise les modules B et C pour effectuer des actions. Intégration Ascendante Étapes de l'Intégration Ascendante 1. Test du Module C (Gestion des Livres) : Nous commençons par tester le module C en isolation. Nous écrivons des pilotes (drivers) pour simuler les appels au module C afin de vérifier ses fonctionnalités (ajouter, supprimer, mettre à jour et rechercher des livres). 2. Test du Module B (Gestion des Emprunts) : Une fois que le module C est testé et validé, nous intégrons le module B avec le module C. Nous testons maintenant le module B en utilisant le module C réel. Par exemple, nous vérifions que le module B peut emprunter, retourner et renouveler des livres en utilisant les fonctionnalités du module C. Si nécessaire, nous utilisons des pilotes pour simuler les appels au module B. 3. Test du Module A (Interface Utilisateur) : Une fois que le module B est testé et validé, nous intégrons le module A avec les modules B et C. Nous testons maintenant le module A en utilisant les modules B et C réels. Par exemple, nous vérifions que l'interface utilisateur  permet aux utilisateurs d'emprunter, retourner et renouveler des livres en utilisant les fonctionnalités des modules B et C. Si nécessaire, nous utilisons des pilotes pour simuler les appels au module A. Intégration Descendante Dans l'approche descendante, les tests se déroulent de haut en bas en suivant le flux de contrôle du système logiciel. Elle utilise des bouchons (stubs) pour les tests.  Comparaison: Caractéristique Intégration Descendante Intégration Ascendante Direction de De bas en haut, en commençant par les modules de bas l'intégration De haut en bas, suivant le flux de contrôle du système. niveau. Modules testés en Les modules de bas niveau (comme les modules de gestion des premier Les modules de haut niveau (comme l'interface utilisateur). données). Utilisation de Utilise des bouchons (stubs) pour simuler les modules de bas Utilise des pilotes (drivers) pour simuler les appels aux bouchons/pilotes niveau. modules de haut niveau. Les erreurs dans les modules de haut niveau sont détectées en Les erreurs dans les modules de bas niveau sont détectées en Détection des erreurs premier. premier. Peut-être plus complexe au début, car les modules de haut niveau Généralement plus simple au début, car les modules de bas Complexité initiale dépendent souvent de plusieurs modules de bas niveau. niveau sont testés en premier. Module A (Interface Utilisateur) -> Module B (Gestion des Module C (Gestion des Livres) -> Module B (Gestion des Exemple de flux Emprunts) -> Module C (Gestion des Livres) Emprunts) -> Module A (Interface Utilisateur) Permet de détecter et de corriger les erreurs de bas niveau Avantages Permet de tester les fonctionnalités de haut niveau rapidement. avant de les intégrer avec des modules de haut niveau. Inconvénients Les bouchons peuvent être complexes à écrire et à maintenir. Les pilotes peuvent être complexes à écrire et à maintenir. Utilisée lorsque les fonctionnalités de haut niveau sont critiques et Utilisée lorsque les modules de bas niveau sont critiques et Utilisation typique doivent être testées rapidement. doivent être testés en premier.  System Testing Tester l'ensemble des fonctionnalités de l'application en fonction des exigences spécifiques du client. Il s'agit d'une technique de test en boîte noire. Ces tests sont réalisés par l'équipe de test. Avant de réaliser les tests système, nous devons connaître les exigences. Les tests système se concentrent sur les aspects suivants : ✓ Tests de l'interface utilisateur (GUI) ✓ Tests fonctionnels ✓ Tests non fonctionnels ✓ Tests d'utilisabilité User Acceptance Testing Après la fin des tests système, l'équipe UAT réalise des tests d'acceptation à deux niveaux : ✓ Tests Alpha : Réalisé en interne par l'équipe de développement ou de test. ✓ Tests Bêta : Réalisé par des utilisateurs finaux ou des clients dans un environnement réel. Testing Methodologies White box Testing Black box Testing Grey box Testing White Box Testing Les tests en boîte blanche sont effectués sur la logique interne des programmes. Des compétences en programmation sont requises, exemple de Unit Testing & Integration Testing Exemple : Dans une fonction de tri, le testeur examine le code pour vérifier si tous les cas sont bien couverts, comme les listes déjà triées, les listes vides, ou les éléments en double. Il peut vérifier que les boucles fonctionnent correctement et que l’algorithme optimise le temps d’exécution. White Box Testing Black Box Testing Les tests sont effectués sur les fonctionnalités de l'application pour vérifier si elles fonctionnent conformément aux exigences du client. Ex: System Testing & UAT Testing Black Box Testing  Grey Box Testing Combinaison à la fois des tests en boîte blanche et en boîte noire. Exemple : Pour tester un formulaire de connexion, le testeur peut entrer des données valides et invalides (comme des mots de passe incorrects ou des injections SQL) et vérifier comment le système répond. Avec un aperçu du code, il peut aussi tester comment les données sont validées et stockées. Black Box Testing Types ✓ Tests de l'interface graphique (GUI) ✓ Tests d'utilisabilité ✓ Tests fonctionnels ✓ Tests non fonctionnels What is GUI? ✓ Il existe deux types d'interfaces dans une application informatique. ▪ L'interface en ligne de commande (CLI) est celle où vous tapez du texte et l'ordinateur répond à cette commande. ▪ GUI signifie interface graphique, où vous interagissez avec l'ordinateur en utilisant des images plutôt que du texte. GUI Testing Les tests de l'interface utilisateur graphique (GUI) consistent à tester l'interface graphique du système. Les tests de l'interface graphique impliquent de vérifier les écrans avec les contrôles tels que les menus, les boutons, les icônes et tous les types de barres – barre d'outils, barre de menus, boîtes de dialogue et fenêtres, etc. Lors des tests de l'interface graphique, les ingénieurs de test valident l'interface utilisateur de l'application selon les aspects suivants : o Apparence et ressenti o Facilité d'utilisation o Navigation et touches de raccourci Objets GUI : o Fenêtre, boîte de dialogue, bouton-poussoir, bouton radio, groupe de boutons radio, barre d'outils, zone de texte, zone de saisie, case à cocher, boîte de liste, boîte déroulante, boîte combinée, onglet, vue arborescente, barre de progression, tableau, barre de défilement, etc. Liste de contrôle pour les tests de l'interface utilisateur graphique (GUI) ✓ Il vérifie si tous les éléments de base sont présents sur la page ou non. ✓ Il vérifie l'orthographe des objets. ✓ Il vérifie l'alignement des objets. ✓ Il vérifie l'affichage du contenu sur les pages web. ✓ Il vérifie si les champs obligatoires sont mis en évidence ou non. ✓ Il vérifie la cohérence des couleurs de fond, du type de police et de la taille de la police, etc. Usability Testing Durant ces tests, on valide si l'application fournit une aide contextuelle sensible aux utilisateurs ou non. On vérifie à quel point les utilisateurs finaux peuvent comprendre et utiliser facilement l'application, ce qui s'appelle les tests d'ergonomie.  Test fonctionnel ✓ Couverture des propriétés des objets ✓ Couverture du domaine des entrées (BVA, ECP) ✓ Tests de base de données / Couverture du backend ✓ Couverture de la gestion des erreurs ✓ Couverture des calculs / manipulations ✓ Existence et exécution des liens ✓ Cookies et sessions [Tapez ici] Object Properties Testing ✓ Chaque objet a certaines propriétés. ✓ Ex : Activer, Désactiver, Focus, Texte, etc. ✓ Lors des tests fonctionnels, les ingénieurs de test valident les propriétés des objets en temps réel. Input Domain Testing Lors des tests de domaine des entrées, les ingénieurs de test valident les données fournies à l'application en fonction de leur valeur et de leur longueur. Il existe deux techniques dans les tests de domaine des entrées : Partitionnement des classes d'équivalence (ECP) Analyse des valeurs limites (BVA)  ECP & BVA Requirement:- Le champ du nom d'utilisateur n'accepte que des lettres minuscules avec un minimum de 6 et un maximum de 8 lettres. ECP for User Name BVA for User Name Parameters Value Result Valid Invalid Min 6 Valid a….z A….Z Min+1 7 Valid 0…9 Min-1 5 Invalid Special characters Max 8 Valid ( @ , #, $, & etc..) Max+1 9 Invalid Max-1 7 Valid  Database Testing Lors des tests de base de données, les ingénieurs de test valident les données par rapport à la base de données. Valident les opérations DML (Insertion, Mise à jour, Suppression et Sélection) Langage SQL : DDL, DML, DCL, etc. DDL - Langage de définition de données - Créer, modifier, supprimer DML - Langage de manipulation de données - Insérer, mettre à jour, sélectionner, supprimer Database Testing DCL - Valider, annuler, etc. Error Handling Testing Valider les messages d'erreur générés par l'application lorsque nous fournissons des données invalides. Les messages d'erreur doivent être clairs et faciles à comprendre pour l'utilisateur. Calculations/Manipulations Testing Valider les calculs mathématiques. Links Coverage Existence des liens - Les liens sont-ils placés au bon endroit ou non ? Exécution des liens - Le lien redirige-t-il vers la page appropriée ou non ? Types de liens : Liens internes : redirection vers des pages internes (Contacte, à propos..) Liens externes : redirection vers des pages externes (instagram, Linkedin …) Liens brisés : Cliquer sur un lien qui n'existe plus ou est incorrect (par exemple, un lien d'article ancien) pour vérifier qu'une page d'erreur ou de redirection appropriée s'affiche. Cookies & Sessions Cookie - Fichiers temporaires Internet créés côté client lorsque nous ouvrons des sites web. Ces fichiers contiennent des données utilisateur. Session - Les sessions sont des créneaux horaires qui sont attribués à l'utilisateur côté serveur. Exemples:  Cookies & Sessions Test fonctionnel de cookie : 1. Création de cookie : Vérifiez si un cookie est correctement créé lorsque l'utilisateur se connecte. 2. Données du cookie : Assurez-vous que le cookie contient les bonnes informations, comme l'ID utilisateur ou les préférences enregistrées. 3. Expiration de cookie : Vérifiez que le cookie expire ou se supprime automatiquement après un délai défini ou lorsque l'utilisateur se déconnecte. 4. Suppression de cookie : Supprimez le cookie et vérifiez que l'utilisateur n’est plus connecté ou que les préférences sont réinitialisées.  Cookies & Sessions Test fonctionnel de session : 1. Création de session : Assurez-vous qu'une session est créée au moment de la connexion de l'utilisateur. 2. Expiration de session : Vérifiez que la session expire après une période d'inactivité prédéfinie, forçant ainsi l'utilisateur à se reconnecter. 3. Données de session : Assurez-vous que les données de session, comme les informations de connexion ou le panier d'achat, sont exactes et mises à jour en temps réel. 4. Fin de session : Lors de la déconnexion, vérifiez que la session est bien terminée côté serveur pour empêcher tout accès non autorisé. Test non fonctionnel Test de performance: Test de charge Test de résistance Test de volume Test de sécurité Test de récupération Test de compatibilité Test de configuration Test d’installation Test de validation Performance Testing Load: Tester la vitesse du système en augmentant progressivement la charge jusqu'au nombre attendu par le client. Stress: mesure les performances d'une application lorsqu'elle est confrontée à des charges de travail extrêmes afin de déterminer comment elle gère des niveaux de trafic ou de traitement de données élevées. L'objectif du test de stress est d'identifier le point de rupture de l'application. Volume: examine les performances d'une application lorsqu'elle est inondée par un nombre important de données. L'objectif du test de volume est d'exposer tout problème de performance causé par les fluctuations de données. Performance Testing Comment réaliser des tests de performance ? La mise en œuvre des tests de performance dépend largement de la nature de l'application ainsi que des objectifs et des mesures que les organisations jugent les plus importants. Néanmoins, il existe des directives générales ou des étapes que la plupart des tests de performance suivent. Performance Testing Choisir l'environnement de test Tout d'abord, identifiez l'environnement de test physique, l'environnement de production et les outils de test dont dispose votre équipe. Il est également important d'enregistrer le matériel, les logiciels, les spécifications de l'infrastructure et les configurations du réseau dans l'environnement de test et de production pour garantir la cohérence. Si certains tests peuvent avoir lieu dans l'environnement de production, il est essentiel d'établir des protections strictes pour éviter que les tests ne perturbent les opérations de production. Performance Testing Identifier les mesures de performance Ici, l'équipe de test doit déterminer les critères de réussite du test de performance en identifiant à la fois les objectifs et les contraintes pour des paramètres tels que le temps de réponse, le débit et l'allocation des ressources. Bien que les critères clés soient dérivés des spécifications du projet, les testeurs doivent néanmoins être libres d'établir une collection plus large de tests et de repères de performance. C'est essentiel lorsque les spécifications du projet manquent d'une grande variété de repères de performance. Performance Testing Liste des Mesures de Performance 1. Temps de Réponse (Response Time) o Temps pris par le système pour répondre à une requête ou action utilisateur. 2. Débit o Nombre de transactions ou requêtes traitées par le système par unité de temps (ex. requêtes par seconde). 3. Latence o Temps écoulé entre l'envoi d'une requête et le début de la réponse du système. 4. Taux d'Utilisation CPU (CPU Utilization) o Pourcentage d'utilisation du processeur par l'application ou le système. Performance Testing 5. Utilisation de la Mémoire (Memory Utilization) o Quantité de mémoire utilisée par l'application pendant l'exécution. 6. Utilisation du Disque (Disk I/O Utilization) o Mesure des opérations d'entrée/sortie sur le disque (vitesse de lecture/écriture). 7. Capacité (Capacity) o Nombre maximum d'utilisateurs simultanés ou de transactions que le système peut supporter avant de commencer à se dégrader. 8. Scalabilité (Scalability) o Capacité du système à gérer une augmentation de la charge sans perte significative de performance. 9. Disponibilité (Availability) o Pourcentage de temps où le système est opérationnel et accessible pour les Performance Testing utilisateurs. 10. Temps de Démarrage (Startup Time) o Durée nécessaire pour que l'application ou le service soit prêt après un démarrage. 11. Temps de Chargement de Page (Page Load Time) o Durée nécessaire pour afficher complètement une page web. 12. Utilisation du Réseau (Network Utilization) o Quantité de données transmises et reçues sur le réseau par l'application. 13. Temps d'Attente (Wait Time) o Temps pendant lequel une requête ou un processus est en attente de ressources (ex. attente de réponse de la base de données). 14. Temps de Traitement (Processing Time) Performance Testing o Temps pris par le système pour traiter une requête après l'avoir reçue. 15. Dégradation des Performances (Performance Degradation) o Diminution des performances du système sous une charge élevée. 16. Temps de Recouvrement (Recovery Time) o Temps pris par le système pour se rétablir après une panne ou un incident. 17. Taux de Rejets (Rejection Rate) o Pourcentage de requêtes ou de connexions rejetées par le système lorsque la charge maximale est atteinte. 18. Jitter o Variation dans le temps de réponse des requêtes, surtout critique dans les applications en temps réel. 19. Taux de Connexion (Connection Rate) Performance Testing o Nombre de connexions que le système peut établir par seconde Planifier et concevoir les tests de performance Déterminer comment l'utilisation variera parmi les utilisateurs finaux de l'application et créer des scénarios pour tester tous les cas d'utilisation possibles. En outre, veiller à identifier tous les paramètres qui doivent être mesurés pendant les tests. Configurer l'environnement de test Avant l'exécution du test, préparer l'environnement de test ainsi que tous les outils ou ressources nécessaires. Implémentation de la conception des tests En utilisant la conception de test, créer les tests de performance. Performance Testing Exécution des tests Exécuter les tests et surveiller les résultats. Analyse, rapport et nouveaux tests Analyser et partager les résultats. En fonction de besoins, exécuter à nouveau le test en utilisant les mêmes paramètres ou des paramètres différents. Security Testing Test de la sécurité fournie par le système. Types : Authentification Contrôle d'accès/Autorisation Chiffrement/Déchiffrement Recovery Testing Test de la récupération fournie par le système. Vérification si le système passe correctement d'une condition anormale à une condition normale. Exemple: Un serveur de base de données qui gère des transactions financières. Test de récupération : 1. Condition normale : Le système fonctionne correctement et les transactions sont traitées sans erreur. 2. Condition anormale : Une panne du serveur de base de données survient pendant une transaction financière, interrompant le processus de traitement.  Recovery Testing 3. Test de récupération : Après la panne du serveur, le test consiste à redémarrer le serveur de base de données et vérifier si celui-ci récupère correctement les transactions en attente ou incomplètes. Le test vérifie si : Les données corrompues sont corrigées ou ignorées. Les transactions non validées sont annulées ou réessayées. Le système retrouve son état normal sans perte de données. Critères de réussite : Le système doit être capable de récupérer et de poursuivre les transactions là où elles ont été interrompues, sans perte de données sensibles, et dans un délai raisonnable.  Test de compatibilité ✓ Test de compatibilité du système par rapport au système d'exploitation, au matériel et aux navigateurs. ✓ Compatibilité avec le système d'exploitation ✓ Compatibilité matérielle (test de configuration) ✓ Compatibilité avec les navigateurs Test d’installation ✓ Tester l'installation de l'application sur les plateformes prévues par le client et vérifier les étapes d'installation, la navigation, ainsi que l'espace occupé en mémoire. ✓ Vérifier la désinstallation.  Test d’installation Exemple de test d'installation et désinstallation : 1. Test d'installation : o Télécharger l'installateur et lancer l'installation sur différentes plateformes (Windows, macOS, Ubuntu). o Vérifier les étapes d'installation, l'affichage des fenêtres de dialogue, et les prérequis. o Tester la navigation dans l'application après installation. o Vérifier l'espace disque utilisé et la consommation de mémoire.  Test d’installation 2. Test de désinstallation : o Désinstaller l'application via les méthodes standards (panneau de configuration, suppression manuelle, commande terminal). o Vérifier que tous les fichiers sont supprimés et qu'aucun résidu ne reste. Problèmes possibles : Fichiers résiduels après désinstallation, erreurs d'installation sur certaines versions de l'OS. Sanitation/Garbage Testing Consiste à vérifier si le système nettoie correctement les données inutiles ou temporaires créées lors de l'exécution d'une application. L'objectif est d'assurer qu'aucun fichier résiduel, cache, ou données inutiles ne subsistent après la fermeture ou la désinstallation de l'application. Exemple : 1. Contexte : Une application de traitement d'images qui génère des fichiers temporaires pendant l'édition. Sanitation/Garbage Testing 2. Test : o Ouvrir l'application et effectuer des modifications sur une image. o Vérifier que des fichiers temporaires sont créés dans le dossier /tmp ou AppData pendant l'utilisation. Java utilise la classe java.nio.file.Files pour créer des fichiers temporaires et les supprimer lorsqu’ils ne seront plus utilsés, ou bien GC (Gabrage collection) o Fermer l'application. o Vérification : Confirmer que les fichiers temporaires sont supprimés automatiquement et qu'il ne reste aucun fichier inutile dans le dossier temporaire. Sanitation/Garbage Testing 3. Problème potentiel : o Les fichiers temporaires ne sont pas supprimés après la fermeture de l'application, occupant inutilement de l'espace disque. o Des fichiers de cache persistent même après la désinstallation de l'application. Objectif du test : Assurer que l'application gère correctement le nettoyage des fichiers temporaires et des caches pour éviter l'accumulation de données inutiles sur le système.  Testing Terminology Adhoc Testing: Le test ad hoc est une forme de test logiciel non planifié et non structuré. Il se fait généralement de manière spontanée, sans préparation préalable. Le testeur explore l'application sans suivre de scénarios de test définis, dans le but de trouver des erreurs ou des comportements inattendus. Caractéristiques du test ad hoc : Non structuré : Aucun plan de test spécifique n'est défini avant le test. Spontané : Il est souvent effectué sans préparation préalable, en explorant simplement le logiciel de manière informelle. Objectif : Identifier des défauts ou comportements anormaux que les tests formels pourraient avoir négligés. Facilité d'exécution : Ce test est simple et rapide à mettre en œuvre, mais ne fournit pas de couverture complète du logiciel.  Exemple : Un testeur utilise une application de gestion de contenu et, sans suivre de scénario précis, clique sur des éléments de l'interface, modifie des paramètres et observe si des erreurs se produisent, dans le but de détecter des bugs ou des comportements imprévus. Monkey Testing: Monkey Testing (ou test de singe) est une technique de test logiciel où le testeur effectue des actions aléatoires ou non planifiées sur l'application afin de détecter des défauts ou des comportements inattendus. Ce type de test est souvent automatisé et peut être réalisé à l'aide d'outils pour simuler des entrées aléatoires, comme des clics, des frappes clavier ou des gestes tactiles. Caractéristiques: Entrées aléatoires : Les actions réalisées sur l'application sont totalement aléatoires, sans tenir compte de la logique de l'application. Découverte de défauts inattendus : L'objectif est de trouver des erreurs qui pourraient survenir en raison de conditions imprévues ou non testées par des tests structurés. Simplicité : Le test ne suit pas de scénario particulier ou de processus de test défini, mais consiste à manipuler l'application de manière aléatoire pour détecter des anomalies. Automatisé : Souvent automatisé à l'aide d'outils comme MonkeyRunner pour Android ou d'autres outils de test de stress pour générer des entrées aléatoires. Exemple : Un testeur lance un Monkey Test sur une application mobile en générant des clics, des balayages ou des pressions de touches de manière aléatoire sur l'écran. L'application est observée pour vérifier si des plantages, des erreurs ou des comportements inattendus se produisent à la suite de ces actions imprévues. Objectif : Le Monkey Testing permet de tester la robustesse d'une application en simulant des conditions d'utilisation inhabituelles ou extrêmes qui peuvent ne pas être couvertes par des tests planifiés ou structurés. Testing Terminology Re- Testing: Des tests supplémentaires sont effectués pour confirmer que les cas de test qui ont échoué lors de l'exécution finale sont réussis une fois les défauts corrigés. Un nouveau test est effectué sur la base des défauts correctifs. Un nouveau test garantit que le défaut d'origine a été corrigé. La priorité des nouveaux tests est plus élevée que celle des tests de régression, ils sont donc effectués avant les tests de régression. Le nouveau test est effectué uniquement pour les cas de test ayant échoué. Testing Terminology Regression Testing: Effectué pour confirmer si un changement récent de programme ou de code n'a pas affecté négativement les fonctionnalités existantes. Le but des tests de régression est que les nouvelles modifications du code ne doivent avoir aucun effet secondaire sur les fonctionnalités existantes. Les tests de régression ne sont effectués que lorsqu'il y a une modification ou que les changements deviennent obligatoires dans un projet existent. Les cas de test pour les tests de régression peuvent être obtenus à partir de la spécification fonctionnelle, des didacticiels et manuels d'utilisation, ainsi que des rapports de défauts concernant les problèmes corrigés. Testing Terminology Sanity Testing: Le Sanity Testing (ou Test de Sanité ) est une forme de test logiciel qui vise à vérifier rapidement et superficiellement que les fonctionnalités de base d'un système ou d'une application fonctionnent correctement après une modification ou une mise à jour. L'objectif principal est de s'assurer que les changements apportés n'ont pas introduit de problèmes majeurs qui rendraient le système inutilisable ou instable. Caractéristiques du Sanity Testing : 1. Rapidité : Les tests de sanité sont généralement rapides à exécuter. Ils ne couvrent pas toutes les fonctionnalités de manière exhaustive, mais se concentrent sur les aspects critiques. 2. Superficialité : Contrairement aux tests de régression complets, les tests de sanité ne vont pas en profondeur. Ils vérifient simplement que les fonctionnalités de base fonctionnent comme prévu. 3. Objectif : L'objectif est de détecter rapidement les problèmes évidents qui pourraient empêcher le système de fonctionner correctement. Si un test de sanité échoue, cela signifie que des tests plus approfondis ne sont Testing Terminology pas nécessaires car le système n'est pas dans un état utilisable. 4. Contexte : Les tests de sanité sont souvent utilisés après des modifications mineures, des correctifs ou des mises à jour. Ils sont également couramment utilisés dans les environnements de développement agile pour vérifier rapidement les builds. Exemples de Tests de Sanité : Vérification des Fonctionnalités de Base : S'assurer que les fonctionnalités principales de l'application, comme la connexion, la navigation et les transactions de base, fonctionnent correctement. Tests de Navigation : Vérifier que les liens et les boutons de navigation fonctionnent et mènent aux bonnes pages. Tests de Formulaire : S'assurer que les formulaires peuvent être remplis et soumis sans erreur. Tests de Connexion : Vérifier que les utilisateurs peuvent se connecter et se déconnecter sans problème. Tests de Chargement de Page : S'assurer que les pages principales se chargent correctement et rapidement. Testing Terminology Smoke Testing: Le Smoke Testing (ou test de fumée ) est une technique de test logiciel qui consiste à effectuer une série de tests basiques et rapides sur une nouvelle version d'une application pour vérifier que les fonctionnalités essentielles fonctionnent correctement. Le terme "smoke test" provient de l'industrie du matériel électronique, où un dispositif est testé pour voir s'il "dégage de la fumée" lors de sa mise sous tension, indiquant ainsi un problème critique. Caractéristiques du Smoke Testing : 1. Tests basiques et essentiels: Ils vérifient les fonctionnalités critiques de l'application, comme le lancement du programme, la connexion utilisateur, l'affichage des interfaces principales, etc.. 2. Exécution rapide: Les tests sont conçus pour être simples et rapides, prenant souvent moins d'une heure à exécuter. 3.Critère de validation: ✓ Si le smoke test réussit, la version peut être envoyée pour des tests plus approfondis (tests fonctionnels, tests de régression, tests de performance, etc.). Testing Terminology ✓ Si le smoke test échoue, la version est rejetée et doit être corrigée avant d'être testée à nouveau. Exemples de Tests de Fumée : Imaginons une application web de gestion des tâches : Le smoke test vérifierait que : L'application se lance correctement. La page de connexion s'affiche et permet de se connecter. L'utilisateur peut accéder à son tableau de bord. Une tâche peut être ajoutée et supprimée. L'application peut se déconnecter proprement. Ces tests ne couvrent pas tous les cas d'utilisation, mais permettent de s'assurer que les fonctionnalités critiques fonctionnent.  Testing Terminology Différence entre Smoke Testing et Sanity Testing Smoke Testing : Effectué au début du cycle de test pour vérifier la stabilité de la version avant d'aller plus loin. Sanity Testing : Réalisé après une modification ou un correctif pour vérifier que les nouvelles fonctionnalités ou les corrections de bugs fonctionnent comme prévu sans introduire de nouveaux problèmes. Testing Terminology cont… Test de bout en bout (End to End Testing): Tester les fonctionnalités globales du système, y compris l'intégration des données entre tous les modules, s'appelle un test de bout en bout.. Test exploratoire (Exploratory Testing): Explorer l'application, comprendre les fonctionnalités et ajouter ou modifier les cas de test existants pour améliorer les tests s'appelle le test exploratoire. Testing Terminology cont… Test de globalisation (ou) Test d'internationalisation (I18N): Vérifie si l'application permet de configurer et de modifier la langue, le format de la date et de l'heure, la devise, etc. Si elle est conçue pour des utilisateurs mondiaux, cela s'appelle un test de globalisation. Test de localisation (Localization Testing): Vérifie la langue par défaut, la devise, le format de la date et de l'heure, etc. Si l'application est conçue pour une localité spécifique d'utilisateurs, cela s'appelle un test de localisation. Testing Terminology cont… Test positif (+ve): Les tests réalisés sur l'application avec une approche positive pour déterminer ce que le système est censé faire s'appellent des tests positifs. Les tests positifs aident à vérifier si les exigences du client sont bien respectées par l'application. Test négatif ( -ve): Tester une application logicielle avec une perception négative pour vérifier ce que le système ne doit pas faire s'appelle le test négatif. Exemple d'essayer de se connecter avec un nom d'utilisateur vide ou un mot de passe incorrect pour vérifier que l'application empêche l'accès et affiche un message d'erreur Testing Terminology cont… approprié. Software Testing Life Cycle (STLC) Analyse des exigences Planification des tests Conception des tests Exécution des tests Clôture des tests STLC (Software Testing Life Cycle) Définition du plan de test Un document décrivant la portée, l'approche, les ressources et le calendrier des activités de test. Il identifie les éléments à tester, les fonctionnalités à tester, les tâches de test, qui effectuera chaque tâche et les risques nécessitant une planification des mesures de contingence. Un détail de la manière dont le test va se dérouler, qui effectuera les tests, ce qui sera testé, combien de temps les tests prendront et à quel niveau de qualité les tests seront réalisés. Contenu du plan de test Objectif Fonctionnalités à tester Fonctionnalités non testées Approche de test Critères d'entrée Critères de sortie Critères de suspension et de reprise Environnement de test Livrables et jalons des tests Calendriers Risques et mesures d'atténuation Approbations Use case, Test Scenario & Test Case Use Case: Le cas d'utilisation décrit l'exigence. Le cas d'utilisation contient TROIS éléments. Acteur Action/Flux Résultat Test Scenario: Zone potentielle à tester (quoi tester) Test Case: Comment tester. Décrit les étapes de test, le résultat attendu et le résultat réel.  Use Case V/s Test Case Use Case – Décrit l'exigence fonctionnelle, préparée par le Business Analyst(BA). Test Case – Décrit les étapes/procédures de test, préparées par l'ingénieur de test. Test Case V/s Test Scenario Cas de test : Constitue un ensemble de valeurs d'entrée, de conditions préalables d'exécution, de résultats attendus et de conditions postérieures exécutées, développé pour couvrir une certaine condition de test. Le scénario de test n'est rien d'autre qu'une procédure de test. Cas de test : sont dérivés (ou écrits) à partir des scénarios de test. Les scénarios sont dérivés des cas d'utilisation. En bref, le scénario de test correspond à "Ce qui doit être testé" et le cas de test à "Comment tester".  Exemple: Scénario de test : Vérification de la fonctionnalité du bouton de connexion ❖ CT1 : Cliquer sur le bouton sans saisir de nom d'utilisateur ni de mot de passe. ❖ CT2 : Cliquer sur le bouton en saisissant uniquement le nom d'utilisateur. ❖ CT3 : Cliquer sur le bouton en saisissant un nom d'utilisateur et un mot de passe incorrects.  Cas de test positifs VS cas de test négatifs : Prérequis: Par exemple, si une zone de texte est mentionnée comme une fonctionnalité et que dans le SRS, il est indiqué que la zone de texte accepte entre 6 et 20 caractères et uniquement des lettres alphabétiques. Cas de test positifs: La zone de texte accepte 6 caractères. La zone de texte accepte jusqu'à une longueur de 20 caractères. La zone de texte accepte n'importe quelle valeur entre 6 et 20 caractères. La zone de texte accepte toutes les lettres alphabétiques. Cas de test négatifs: La zone de texte ne doit pas accepter moins de 6 caractères. La zone de texte ne doit pas accepter plus de 20 caractères. La zone de texte ne doit pas accepter de caractères spéciaux. La zone de texte ne doit pas accepter de chiffres. Techniques de conception de cas de test Analyse des valeurs limites (BVA) Partitionnement en classes d'équivalence (ECP) Test avec tableau de décision Diagramme de transition d'état Test basé sur les cas d'utilisation  Tableau de décision Un tableau de décision est une technique utilisée pour représenter et analyser les décisions complexes et leurs résultats possibles en fonction de différentes conditions. Il permet de formaliser les règles de décision sous une forme tabulaire, où chaque combinaison d'entrées (conditions) conduit à une action spécifique. Le tableau de décision est structuré de la manière suivante : 1. Conditions : Les différentes conditions d'entrée (ou critères) qui influencent la décision. 2. Actions : Les actions possibles qui doivent être prises en fonction des conditions. 3. Combinations de conditions : Chaque combinaison possible des conditions qui détermine une action spécifique. Exemple de tableau de décision : Tableau de décision Diagramme de transition d'état Un diagramme de transition d'état est une représentation graphique des états possibles d'un système et des transitions entre ces états en réponse à des événements ou des conditions spécifiques. Ce diagramme est utilisé pour modéliser le comportement dynamique d'un système, en particulier lorsqu'il dépend des événements internes ou externes. Chaque état représente une situation dans laquelle le système peut se trouver, et les transitions entre les états montrent comment le système passe d'un état à un autre en fonction des événements déclencheurs. Diagramme de transition d'état  Cas d’usage (Use case) Représente une séquence d’actions qu’un système ou toute autre entité peu accomplir en interagissant evec les acteurs du système. Test Suite Une suite est un groupe de cas de test qui appartiennent à la même catégorie. Test Case Template Élément Explication ID du cas de test Identifiant unique pour référencer un cas de test spécifique. Titre du cas de test Titre succinct décrivant l'objectif du cas de test. Description Explication détaillée de ce que couvre le cas de test. Pré-condition Conditions qui doivent être remplies avant d'exécuter le test (configuration, données, etc.). Priorité (P0, P1, P2, P3) Indication de l'importance du cas de test (P0 étant la priorité la plus élevée, P3 la moins élevée). ID de l'exigence Identifiant d'une exigence à laquelle le test est lié. Étapes/Actions Séquence d'actions à suivre pour exécuter le test. Résultat attendu Comportement ou résultat attendu une fois le test exécuté. Résultat réel Comportement ou résultat observé lors de l'exécution du test. Données de test Informations ou entrées spécifiques utilisées pour exécuter le test (valeurs, fichiers, configurations, etc.). Test Case Template  Caractéristiques d'un bon cas de test Un bon cas de test possède certaines caractéristiques, notamment: Doit être précis et tester ce pour quoi il est conçu. Ne doit inclure aucune étape inutile. Doit être réutilisable. Doit être traçable aux exigences. Doit être conforme aux réglementations. Doit être indépendant, c'est-à-dire qu'il doit pouvoir être exécuté dans n'importe quel ordre, sans dépendre d'autres cas de test. Doit être simple et clair, tout testeur doit pouvoir le comprendre en le lisant une seule fois. Données de test Les données de test sont nécessaires pour les cas de test. Les données de test sont fournies comme entrées aux cas de test. Préparées par les ingénieurs de test. Conservées dans des feuilles Excel.  Configuration l'environnement de test (Test Bed) L'environnement de test détermine les conditions logicielles et matérielles sous lesquelles un produit de travail est testé. Activités: Comprendre l'architecture requise, la configuration de l'environnement et préparer la liste des exigences matérielles et logicielles pour l'environnement de test. Configurer l'environnement de test et les données de test. Effectuer un test de fumée sur la version. livrables Environnement prêt avec les données de test configurées Résultats du test de fumée  Exécution des tests Pendant cette phase, l'équipe de test effectuera les tests en se basant sur les plans de test et les cas de test préparés. Les bogues seront signalés à l'équipe de développement pour correction et un nouveau test sera effectué.