Qu'est-ce que le test d'intégration?
L'ESSAI D'INTÉGRATION est défini comme un type de test où les modules logiciels sont intégrés de manière logique et testés en tant que 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. Par conséquent, il est également appelé «I & T» (intégration et test), «test de chaîne» et parfois «test de thread» .
- Qu'est-ce que le test d'intégration?
- Pourquoi faire des tests d'intégration?
- Exemple de scénario de test d'intégration
- Approches, stratégies, méthodologies de test d'intégration
- Approche du Big Bang:
- Approche incrémentale
- Qu'est-ce que Stub and Driver?
- Intégration ascendante
- Intégration descendante:
- Intégration hybride / sandwich
- Comment faire des tests d'intégration?
- Brève description des plans de test d'intégration:
- Critères d'entrée et de sortie des tests d'intégration
- Meilleures pratiques / directives pour les tests d'intégration
Pourquoi faire des tests d'intégration?
Bien que chaque module logiciel soit testé à l'unité, 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 des autres programmeurs. Les tests d'intégration deviennent nécessaires pour vérifier que les modules logiciels fonctionnent à l'unité
- Au moment du développement du module, il y a de grandes chances de changement des exigences par les clients. Ces nouvelles exigences peuvent ne pas être testées à l'unité et par conséquent, des tests d'intégration du système deviennent nécessaires.
- Les interfaces des modules logiciels avec la base de données peuvent être erronées
- Les interfaces matérielles externes, le cas échéant, peuvent être erronées
- Une gestion des exceptions inadéquate peut entraîner des problèmes.
Cliquez ici si la vidéo n'est pas accessible
Exemple de scénario de test d'intégration
Le cas de test d'intégration diffère des autres cas de test en ce sens qu'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 liens d'intégration plutôt qu'aux fonctions unitaires déjà testées.
Exemples de cas de test d'intégration pour le scénario suivant: L'application dispose de 3 modules: «Page de connexion», «Boîte aux lettres» et «Supprimer les e-mails» et chacun d'eux est intégré de manière logique.
Ici, ne vous concentrez pas beaucoup sur les tests de la page de connexion, car cela a déjà été fait dans les tests unitaires. Mais vérifiez comment il est lié à la page Boîte aux lettres.
De même Boîte aux lettres: vérifiez son intégration au module Supprimer les courriels.
| ID de cas de test | Objectif du scénario de test | Description du scénario de test | résultat attendu |
|---|---|---|---|
| 1 | Vérifiez le lien d'interface entre le module Login et Mailbox | Entrez les informations de connexion et cliquez sur le bouton Connexion | Pour être dirigé vers la boîte aux lettres |
| 2 | Vérifiez le lien d'interface entre la boîte aux lettres et le module de suppression des courriels | Dans la boîte aux lettres, sélectionnez l'e-mail et cliquez sur un bouton de suppression | L'e-mail sélectionné doit apparaître dans le dossier Supprimé / Corbeille |
Approches, stratégies, méthodologies de test d'intégration
Le génie logiciel définit une variété de stratégies pour exécuter des tests d'intégration, à savoir.
- Approche du Big Bang:
- Approche incrémentale: qui est ensuite divisée en ce qui suit
- 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.
Essais du Big Bang
Big Bang Testing est une approche de test d'intégration dans laquelle tous les composants ou modules sont intégrés ensemble à la fois, puis testés en tant qu'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 pannes est difficile.
- Étant donné le grand nombre d'interfaces qui doivent être testées dans cette approche, certaines liaisons d'interfaces à tester pourraient facilement être manquées.
- Puisque les tests d'intégration ne peuvent commencer qu'après que "tous" les modules sont conçus, l'équipe de test aura moins de temps pour l'exécution dans 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 traitent des interfaces utilisateur ne sont pas non plus isolés et testés en priorité.
Test incrémental
Dans l' approche de test incrémental , les tests sont effectués en intégrant deux ou plusieurs modules qui sont 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 de manière incrémentielle et le processus continue jusqu'à ce que tous les modules liés logiquement soient intégrés et testés avec succès.
L'approche incrémentale, à son tour, est effectuée par deux méthodes différentes:
- De bas en haut
- De haut en bas
Stubs et pilotes
Les stubs et les pilotes sont les programmes factices utilisés dans les tests d'intégration pour faciliter l'activité de test de logiciels. Ces programmes se substituent aux modèles manquants dans les 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.
Stub : est appelé par le module sous test.
Driver : appelle le module à tester.
Test d'intégration ascendante
Les tests d'intégration ascendants sont 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 que les modules de niveau inférieur sont testés et intégrés, le niveau suivant de modules est formé.
Représentation schématique :
Avantages:
- La localisation des pannes est plus facile.
- Pas de temps perdu à attendre que tous les modules soient développés contrairement à l'approche Big-bang
Désavantages:
- Les modules critiques (au plus haut niveau de l'architecture logicielle) 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
Le test d'intégration de haut en bas est une méthode dans laquelle les tests d'intégration ont lieu de haut en bas en suivant le flux de contrôle du système logiciel. Les modules de niveau supérieur sont d'abord testés, 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:
Avantages:
- La localisation des pannes est plus facile.
- Possibilité d'obtenir un prototype précoce.
- Les modules critiques sont testés en priorité; des défauts de conception majeurs ont pu être trouvés et corrigés en premier.
Désavantages:
- Nécessite de nombreux talons.
- Les modules à un niveau inférieur sont testés de manière inadéquate.
Test de sandwich
Le test sandwich est une stratégie dans laquelle les modules de niveau supérieur sont testés avec des modules de niveau inférieur en même temps que les modules inférieurs sont intégrés aux modules supérieurs 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 stubs et des pilotes.
Comment faire des tests d'intégration?
La procédure de test d'intégration indépendamment des stratégies de test du logiciel (discutées ci-dessus):
- Préparer le plan de tests d'intégration
- Concevez les scénarios de test, les cas et les scripts.
- Exécution des cas de test suivi du rapport des défauts.
- Suivi et re-test des défauts.
- Les étapes 3 et 4 sont répétées jusqu'à ce que l'intégration réussisse.
Brève description des plans de test d'intégration:
Il comprend les attributs suivants:
- Méthodes / approches des tests (comme indiqué ci-dessus).
- Champs d'application et éléments hors limites 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 de la phase de test d'intégration dans tout modèle de développement logiciel
Critères d'admission:
- Composants / modules testés à l'unité
- Tous les bogues de priorité élevée ont été corrigés et fermés
- Tous les modules doivent être codés et intégrés avec succès.
- Tests d'intégration Plan, cas de test, scénarios à valider et à documenter.
- Environnement de test requis à configurer pour les tests d'intégration
Critère de sortie:
- Test réussi de l'application intégrée.
- Les cas de test exécutés sont documentés
- Tous les bogues de priorité élevée ont été corrigés et fermés
- Documents techniques à soumettre suivis des notes de publication.
Meilleures pratiques / directives pour les tests d'intégration
- Tout d'abord, déterminez la stratégie de test d'intégration qui pourrait être adoptée, puis préparez les cas de test et les données de test en conséquence.
- Étudiez la conception de l'architecture de l'application et identifiez les modules critiques. Ceux-ci doivent être testés en priorité.
- Obtenez les conceptions d'interface de l'équipe d'architecture et créez 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 le rôle critique.
- Préparez toujours les données factices avant de les exécuter. Ne sélectionnez pas les données de test lors de l'exécution des cas de test.