1 / 16

Tests et Validation du logiciel

Tests et Validation du logiciel. 02/2007 – 06/2007. Tests d’intégration. Système d’information. Domaine. Applicatif métier. Fonctionnalité. Tests d’intégration. Tests d’intégration. Objectifs des tests d’intégration par rapport aux tests métiers Objectif des tests d’intégration

Download Presentation

Tests et Validation du logiciel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Tests et Validation du logiciel 02/2007 – 06/2007

  2. Tests d’intégration Système d’information Domaine Applicatif métier Fonctionnalité

  3. Tests d’intégration

  4. Tests d’intégration • Objectifs des tests d’intégration par rapport aux tests métiers • Objectif des tests d’intégration • Validation des interfaces des composants • Validation de l’interaction matérielle • Objectif des tests métiers • Vérifier la bonne mise en œuvre des besoins utilisateurs. • Tests fonctionnels visant à contrôler la réponse de l’application aux différents évènements du métier. • Conclusion : les tests d’intégration représentent la partie “technique” des tests métier. Ainsi, les tests d’intégrationse focaliseront sur le fonctionnement et les aspects techniques de l’assemblage des différents composants ; ils n’entreront pas dans le détail du fonctionnel.

  5. Tests d’intégration • Périmètre couvert • le bon dialogue entre les modules, • Appel, transmission de données, compatibilité • la livraison par module métier et le fonctionnement des composants de chaque module fonctionnel dans l’environnement d’intégration, • le fonctionnement des menus de module métier, • le fonctionnement des types d’habilitation et types de profils utilisateurs : les droits d’accès, le droit d’utiliser les différents modes pour chaque dialogue technique, etc. • Synchronisations, points de reprises • Périmètre exclus • les vérifications liées à une action fonctionnelle (à un « business event »), • la création des différentes entités fonctionnelles (par exemple, la création d’un fournisseur dans une application commerciale).

  6. Unité à tester Dépendance à tester Tests d’intégration - suite • Architecture des dépendances

  7. Tests d’intégration • Approches classiques • Big-Bang : non recommandé • De haut en bas (top-down) • De bas en haut (bottom-up) • Mixte • Par « paquet » de modules ensemblistes

  8. Approche Big Bang • Intégration de tous les composants à tester en une seule étape. (intégration massive) • Intégration rapide, utilisation privilégiée dans les petits projets. • Inadapté pour les projets importants : risque de se perdre suite à un nombre important de modules à intégrer. Perte d’efficacité.

  9. Unité à tester Dépendance à tester Unité sous test Dépendance sous test Bouchon de test (stub) Dépendance simulée Unité testée Dépendance testée Approche Descendante

  10. Approche descendante • Création de bouchons • Test tardif des couches basses • Détection précoce des défauts d'architecture • Effort important de simulation des composants absents et multiplie le risque d’erreurs lors du remplacement des bouchons. • La simulation par « couches » n’est pas obligatoire

  11. Unité à tester Dépendance à tester Lanceur Dépendance sous test Unité testée Dépendance testée Approche Ascendante

  12. Approche ascendante • Avantages • Faible effort de simulation • Construction progressive de l'application s'appuie sur les modules réels. Pas de version provisoire du logiciel • Les composants de bas niveau sont les plus testés, • Définition des jeux d'essais plus aisée • Démarche est naturelle. • Inconvénients • Détection tardive des erreurs majeures • Planification dépendante de la disponibilité des composants • La simulation par « couches » n’est pas obligatoire

  13. Approche Mixte • Combinaison des approches descendante et ascendante. • Avantages : • Suivre le planning de développement de sorte que les premiers composants terminés soient intégrés en premier , • Prise en compte du risque lié à un composant de sorte que les composants les plus critiques puissent être intégrés en premier. • La principale difficulté d’une intégration mixte réside dans sa complexité car il faut alors gérer intelligemment sa stratégie de test afin de concilier les deux modes d’intégration : ascendante et descendante.

  14. Approche par paquets de modules • Par importance de modules (criticité) • Par ensemble fonctionnel • …..

  15. Approche Mixte

  16. Approche - exercice • Dès que possible dans le planning, donner des cinématiques d’étapes d’intégration ascendante, descendante et mixtes définissant : • Les éléments testés • Les lanceurs • Les bouchons • Planning : • T : A,C,D • T1 : H,G • T2 : F • T3 : B,E

More Related