Qu’est-ce que les tests d’intégration ? (Exemple)

Qu’est-ce que les tests d’intégration ?

Test d'intégration est défini comme un type de test dans lequel les modules logiciels sont intégrés logiquement et testés en groupe. Un projet logiciel typique se compose de plusieurs modules logiciels, codés par différents programmeurs. Le but de ce niveau de test est d'exposer les défauts dans l'interaction entre ces modules logiciels lorsqu'ils sont intégrés

Les tests d'intégration se concentrent sur la vérification de la communication des données entre ces modules. C'est pourquoi il est également appelé 'IL' (Intégration et Tests), « Test de chaîne » et parfois « Test de fil ».

Pourquoi faire des tests d'intégration ?

Test d'intégration


Bien que chaque module logiciel soit testé unitairement, des défauts existent toujours pour diverses raisons telles que

  • Un module, en général, est conçu par un développeur de logiciel individuel dont la compréhension et la logique de programmation peuvent différer de celles des autres programmeurs. Les tests d'intégration deviennent nécessaires pour vérifier que les modules logiciels fonctionnent dans l'unité
  • Au moment du développement du module, il existe de grandes chances que les exigences des clients changent. Ces nouvelles exigences peuvent ne pas être testées unitairement et des tests d'intégration du système deviennent donc nécessaires.
  • Les interfaces des modules logiciels avec la base de données peuvent être erronéesneous
  • Les interfaces matérielles externes, le cas échéant, pourraient être erronéesneous
  • Une gestion inadéquate des exceptions pourrait entraîner des problèmes.

Cliquez ici si la vidéo n'est pas accessible

Exemple de cas de test d'intégration

Intégration Cas de test diffère des autres cas de test dans le sens où il se concentre principalement sur les interfaces et le flux de données/informations entre les modules. Ici, la priorité doit être donnée aux intégrer des liens plutôt que les fonctions unitaires déjà testées.

Exemples de cas de test d'intégration pour la suitewing Scénario : L'application comporte 3 modules : "Page de connexion", "Mailbox" et " Supprimer emails' et chacun d'eux est intégré logiquement.

Ici, ne vous concentrez pas beaucoup sur les tests de la page de connexion car cela a déjà été fait dans Tests unitaires. Mais vérifiez comment c'est lié au Mail Box Page.

De même Mail Box: Vérifier son intégration au Supprimer MailModule s.

ID de cas de test Objectif du scénario de test Description du cas de test résultat attendu
1 Vérifiez le lien d'interface entre le login et Mailbox module Entrez les identifiants de connexion et cliquez sur le bouton Connexion A diriger vers le Mail Box
2 Vérifiez le lien d'interface entre le Mailbox et Supprimer MailModule s A partir de Mailbox sélectionnez le email et cliquez sur un bouton Supprimer Sélectionné email devrait apparaître dans le dossier Supprimé/Corbeille

Types de tests d'intégration

Le génie logiciel définit une variété de stratégies pour exécuter des tests d'intégration, viz.

  • Approche Big Bang :
  • Approche incrémentale : qui est divisée en deux catégorieswing
    • Approche descendante
    • Une approche en profondeur
    • Approche sandwich – combinaison de haut en bas et de bas en haut

Vous trouverez ci-dessous les différentes stratégies, la manière dont elles sont exécutées et leurs limites ainsi que leurs avantages.

Tests du Big Bang

Tests du Big Bang est une approche de test d'intégration dans laquelle tous les composants ou modules sont intégrés ensemble en même temps, puis testés comme une unité. Cet ensemble combiné de composants est considéré comme une entité lors des tests. Si tous les composants de l'unité ne sont pas terminés, le processus d'intégration ne s'exécutera pas.

Avantages:

  • Pratique pour les petits systèmes.

Désavantages:

  • La localisation des défauts est difficile.
  • Étant donné le grand nombre d’interfaces qui doivent être testées dans cette approche, certains liens d’interfaces à tester pourraient facilement passer inaperçus.
  • Étant donné que les tests d'intégration ne peuvent commencer qu'une fois que « tous » les modules ont été conçus, l'équipe de test aura moins de temps pour l'exécution pendant la phase de test.
  • Étant donné que tous les modules sont testés en même temps, les modules critiques à haut risque ne sont pas isolés et testés en priorité. Les modules périphériques qui gèrent les interfaces utilisateur ne sont pas non plus isolés et testés en priorité.

Tests incrémentiels

Dans le Tests incrémentiels Dans cette approche, les tests sont effectués en intégrant deux ou plusieurs modules logiquement liés les uns aux autres, puis testés pour le bon fonctionnement de l'application. Ensuite, les autres modules associés sont intégrés progressivement et le processus se poursuit jusqu'à ce que tous les modules logiquement liés soient intégrés et testés avec succès.

L'approche incrémentale, à son tour, est réalisée par deux méthodes différentes :

  • De bas en haut
  • De haut en bas

Talons et pilotes

Talons et pilotes sont les programmes factices dans les tests d'intégration utilisés pour faciliter le test logiciel activité. Ces programmes remplacent les modèles manquants lors des tests. Ils n'implémentent pas toute la logique de programmation du module logiciel mais simulent la communication de données avec le module appelant lors des tests.

Talon: Est appelé par le module sous test.

Tournevis: Appelle le module à tester.

Test d'intégration ascendante

Test d'intégration ascendante est une stratégie dans laquelle les modules de niveau inférieur sont testés en premier. Ces modules testés sont ensuite utilisés pour faciliter le test de modules de niveau supérieur. Le processus se poursuit jusqu'à ce que tous les modules du niveau supérieur soient testés. Une fois les modules de niveau inférieur testés et intégrés, le niveau de modules suivant est formé.

Représentation schématique:

Tutoriel de test d'INTÉGRATION : Big Bang, Top Down et Bottom Up

Avantages:

  • La localisation des défauts est plus facile.
  • Aucun temps n'est perdu à attendre que tous les modules soient développés contrairement à l'approche Big-bang

Désavantages:

  • Modules critiques (au plus haut niveau du logiciel architecture) qui contrôlent le flux d’application sont testés en dernier et peuvent être sujets à des défauts.
  • Un premier prototype n’est pas possible

Test d'intégration descendante

Tests d'intégration descendants est une méthode dans laquelle les tests d'intégration se déroulent de haut en baswing le flux de contrôle du système logiciel. Les modules de niveau supérieur sont testés en premier, puis les modules de niveau inférieur sont testés et intégrés afin de vérifier la fonctionnalité du logiciel. Les stubs sont utilisés pour tester si certains modules ne sont pas prêts.

Représentation schématique :

Tutoriel de test d'INTÉGRATION : Big Bang, Top Down et Bottom Up

Avantages:

  • La localisation des défauts est plus facile.
  • Possibilité d'obtenir un premier prototype.
  • Les modules critiques sont testés en priorité ; les défauts de conception majeurs pourraient être trouvés et corrigés en premier.

Désavantages:

  • Nécessite de nombreux talons.
  • Les modules de niveau inférieur ne sont pas testés de manière adéquate.

Test de sandwich

Test de sandwich est une stratégie dans laquelle les modules de niveau supérieur sont testés avec des modules de niveau inférieur, tandis que les modules inférieurs sont intégrés aux modules de niveau supérieur et testés en tant que système. Il s'agit d'une combinaison d'approches descendantes et ascendantes, c'est pourquoi on l'appelle Test d'intégration hybride. Il utilise à la fois des talons et des pilotes.

Tutoriel de test d'INTÉGRATION : Big Bang, Top Down et Bottom Up

Comment faire des tests d'intégration ?

La procédure de test d'intégration quelles que soient les stratégies de test logiciel (discutées ci-dessus) :

  1. Préparer l'intégration Plan d'essais
  2. Concevez les scénarios de test, les cas et les scripts.
  3. Exécuter les cas de tests suivi du reporting des défauts.
  4. Suivi et re-test des défauts.
  5. Les étapes 3 et 4 sont répétées jusqu'à ce que l'intégration soit réussie.

Brève description des plans de tests d'intégration

Il comprend le suiviwing attributs:

  • Méthodes/approches des tests (comme indiqué ci-dessus).
  • Portées et éléments hors portée des tests d’intégration.
  • Rôles et responsabilités.
  • Pré-requis pour les tests d'intégration.
  • Environnement de test.
  • Plans de risque et d’atténuation.

Critères d'entrée et de sortie des tests d'intégration

Critères d'entrée et de sortie pour la phase de test d'intégration dans tout modèle de développement logiciel

Critère d'entrée:

  • Composants/modules testés unitairement
  • Tous les bugs hautement prioritaires corrigés et fermés
  • Tous les modules doivent être codés et intégrés avec succès.
  • Tests d'intégration Plan, scénario de test, scénarios à valider et documenter.
  • Requis Environnement de test à configurer pour les tests d'intégration

Critères de sortie:

  • Test réussi de l’application intégrée.
  • Les cas de test exécutés sont documentés
  • Tous les bugs hautement prioritaires corrigés et fermés
  • Documents techniques à soumettre suivis des notes de version.

Meilleures pratiques/lignes directrices pour les tests d'intégration

  • Tout d’abord, déterminez l’intégration Stratégie de test qui pourrait être adopté et later préparer les cas de test et les données de test en conséquence.
  • Étudier le Archiconception architecturale de l'application et identification des modules critiques. Ceux-ci doivent être testés en priorité.
  • Obtenez les conceptions d'interface auprès du Archiéquipe structurelle et créer des cas de test pour vérifier toutes les interfaces en détail. L’interface avec la base de données/le matériel externe/l’application logicielle doit être testée en détail.
  • Après les cas de test, ce sont les données de test qui jouent un rôle critique.
  • Préparez toujours les données fictives avant de les exécuter. Ne sélectionnez pas de données de test lors de l'exécution des scénarios de test.