what is integration testing
Qu'est-ce que le test d'intégration: apprendre avec des exemples de test d'intégration
Les tests d'intégration sont effectués pour tester les modules / composants lorsqu'ils sont intégrés pour vérifier qu'ils fonctionnent comme prévu, c'est-à-dire pour tester les modules qui fonctionnent correctement individuellement ne pose pas de problèmes lorsqu'ils sont intégrés.
Lorsque l'on parle de tester une grande application à l'aide de la technique de test de la boîte noire, implique la combinaison de nombreux modules qui sont étroitement couplés les uns aux autres. Nous pouvons appliquer les concepts de la technique de test d'intégration pour tester ces types de scénarios.
Liste des tutoriels couverts dans cette série:
Tutoriel n ° 1: Qu'est-ce que le test d'intégration? (Ce tutoriel)
Tutoriel n ° 2: Qu'est-ce que le test incrémentiel
Tutoriel n ° 3: Qu'est-ce que le test des composants
Tutoriel n ° 4: Intégration continue
Tutoriel # 5 Différence entre les tests unitaires et l'intégration
Tutoriel n ° 6: Top 10 des outils de test d'intégration
Ce que vous apprendrez:
- Qu'est-ce que le test d'intégration?
- Pourquoi le test d'intégration?
- Avantages
- Défis
- Types de tests d'intégration
- Approches d'intégration de test
- Test d'intégration de l'application GUI
- Étapes pour lancer les tests d'intégration
- Critères d'entrée / sortie pour les tests d'intégration
- Cas de test d'intégration
- L'intégration est-elle une technique de boîte blanche ou de boîte noire?
- Outils de test d'intégration
- Test d'intégration de système
- Différence entre les tests d'intégration et les tests système
- Conclusion
- lecture recommandée
Qu'est-ce que le test d'intégration?
La signification des tests d'intégration est assez simple - Intégrez / combinez le module testé un par un et testez le comportement en tant qu'unité combinée.
La fonction principale ou le but de ce test est de tester les interfaces entre les unités / modules.
Nous faisons normalement des tests d'intégration après les «tests unitaires». Une fois que toutes les unités individuelles sont créées et testées, nous commençons à combiner ces modules «testés unitaires» et commençons à faire les tests intégrés.
La fonction principale ou le but de ce test est de tester les interfaces entre les unités / modules.
Les modules individuels sont d'abord testés isolément. Une fois les modules testés unitaires, ils sont intégrés un par un, jusqu'à ce que tous les modules soient intégrés, pour vérifier le comportement combinatoire, et valider si les exigences sont implémentées correctement ou non.
Ici, nous devons comprendre que les tests d'intégration ne se produisent pas à la fin du cycle, mais plutôt qu'ils sont menés simultanément avec le développement. Donc, dans la plupart du temps, tous les modules ne sont pas réellement disponibles pour tester et voici le défi de tester quelque chose qui n'existe pas!
Pourquoi le test d'intégration?
Nous pensons que les tests d'intégration sont complexes et nécessitent un certain développement et des compétences logiques. C'est vrai! Alors quel est le but de l'intégration de ces tests dans notre stratégie de test?
Voici quelques raisons:
- Dans le monde réel, lorsque des applications sont développées, elles sont décomposées en modules plus petits et les développeurs individuels se voient attribuer 1 module. La logique implémentée par un développeur est assez différente de celle d'un autre développeur, il devient donc important de vérifier si la logique implémentée par un développeur est conforme aux attentes et rend la valeur correcte conformément aux normes prescrites.
- Souvent, le visage ou la structure des données changent lorsqu'ils passent d'un module à un autre. Certaines valeurs sont ajoutées ou supprimées, ce qui pose des problèmes dans les modules ultérieurs.
- Les modules interagissent également avec certains outils ou API tiers qui doivent également être testés pour vérifier que les données acceptées par cette API / cet outil sont correctes et que la réponse générée est également conforme aux attentes.
- Un problème très courant dans les tests - Changement fréquent des exigences! :) Souvent, les développeurs déploient les modifications sans les tester unitaire. Les tests d'intégration deviennent alors importants.
Avantages
Il existe plusieurs avantages de ces tests et peu d'entre eux sont énumérés ci-dessous.
- Ce test permet de s'assurer que les modules / composants intégrés fonctionnent correctement.
- Les tests d'intégration peuvent être lancés une fois que les modules à tester sont disponibles. Il ne nécessite pas que l'autre module soit terminé pour que les tests soient effectués, car les stubs et les pilotes peuvent être utilisés pour le même.
- Il détecte les erreurs liées à l'interface.
Défis
Voici quelques défis impliqués dans le test d'intégration.
#1) Les tests d'intégration consistent à tester au moins deux systèmes intégrés afin de s'assurer que le système fonctionne correctement. Non seulement les liens d'intégration doivent être testés, mais un test exhaustif en tenant compte de l'environnement doit être effectué pour s'assurer que le système intégré fonctionne correctement.
Il peut y avoir différents chemins et permutations qui peuvent être appliqués pour tester le système intégré.
#deux) La gestion des tests d'intégration devient complexe en raison du peu de facteurs impliqués, tels que la base de données, la plate-forme, l'environnement, etc.
# 3) Tout en intégrant tout nouveau système avec l'ancien système, cela nécessite beaucoup de changements et d'efforts de test. Il en va de même lors de l'intégration de deux systèmes hérités.
# 4) L'intégration de deux systèmes différents développés par deux sociétés différentes est un grand défi, car la façon dont l'un des systèmes aura un impact sur l'autre système si des modifications sont apportées à l'un des systèmes n'est pas sûre.
Afin de minimiser l'impact lors du développement d'un système, peu de choses doivent être prises en compte comme une éventuelle intégration avec d'autres systèmes, etc.
Types de tests d'intégration
Vous trouverez ci-dessous un type d'intégration de test avec ses avantages et ses inconvénients.
Approche du Big Bang:
L'approche Big Bang intègre tous les modules en une seule fois, c'est-à-dire qu'elle ne va pas pour intégrer les modules un par un. Il vérifie si le système fonctionne comme prévu ou pas une fois intégré. Si un problème est détecté dans le module complètement intégré, il devient alors difficile de savoir quel module a causé le problème.
L'approche Big Bang est un processus fastidieux de recherche d'un module qui présente un défaut lui-même, car cela prendrait du temps et une fois le défaut détecté, le réparer coûterait cher car le défaut est détecté à un stade ultérieur.
Avantages de l'approche Big Bang:
- C'est une bonne approche pour les petits systèmes.
Inconvénients de l'approche Big Bang:
- Il est difficile de détecter le module qui cause un problème.
- L'approche Big Bang nécessite tous les modules réunis pour les tests, ce qui réduit le temps de test car la conception, le développement et l'intégration prendraient la plupart du temps.
- Les tests ont lieu en une seule fois, ce qui ne laisse pas le temps de tester isolément les modules critiques.
Étapes du test d'intégration:
- Préparer l'intégration Plan de test.
- Préparez des scénarios de test d'intégration et des cas de test.
- Préparez des scripts d'automatisation de test.
- Exécutez des cas de test.
- Signalez les défauts.
- Suivez et testez à nouveau les défauts.
- Les nouveaux tests et tests se poursuivent jusqu'à ce que les tests d'intégration soient terminés.
Approches d'intégration de test
Il existe fondamentalement 2 approches pour effectuer l'intégration des tests:
- Une approche en profondeur
- Approche descendante.
Prenons la figure ci-dessous pour tester les approches:
Une approche en profondeur:
Les tests ascendants, comme son nom l'indique, commencent à partir de l'unité la plus basse ou la plus interne de l'application et progressent progressivement. Le test d'intégration commence à partir du module le plus bas et progresse progressivement vers les modules supérieurs de l'application. Cette intégration se poursuit jusqu'à ce que tous les modules soient intégrés et que l'application entière soit testée comme une seule unité.
Dans ce cas, les modules B1C1, B1C2 & B2C1, B2C2 sont le module le plus bas qui est testé à l'unité. Les modules B1 et B2 ne sont pas encore développés. La fonctionnalité du module B1 et B2 est qu'il appelle les modules B1C1, B1C2 & B2C1, B2C2. Puisque B1 et B2 ne sont pas encore développés, nous aurions besoin d'un programme ou d'un «stimulateur» qui appellera les modules B1C1, B1C2 & B2C1, B2C2. Ces programmes de stimulation sont appelés CONDUCTEURS .
En termes simples, CONDUCTEURS sont les programmes factices qui sont utilisés pour appeler les fonctions du module le plus bas dans le cas où la fonction appelante n'existe pas. La technique ascendante nécessite que le pilote de module alimente l'entrée de cas de test à l'interface du module testé.
L'avantage de cette approche est que, si un défaut majeur existe au niveau de l'unité la plus basse du programme, il est plus facile de le détecter et des mesures correctives peuvent être prises.
L'inconvénient est que le programme principal n'existe en réalité que lorsque le dernier module est intégré et testé. En conséquence, les défauts de conception de niveau supérieur ne seront détectés qu'à la fin.
Approche descendante
Cette technique part du module le plus haut et progresse progressivement vers les modules inférieurs. Seul le module supérieur est testé isolément. Après cela, les modules inférieurs sont intégrés un par un. Le processus est répété jusqu'à ce que tous les modules soient intégrés et testés.
quels appareils fonctionnent à la couche osi 2
Dans le contexte de notre figure, les tests commencent à partir du module A, et les modules inférieurs B1 et B2 sont intégrés un par un. Maintenant, ici, les modules inférieurs B1 et B2 ne sont pas réellement disponibles pour l'intégration. Afin de tester les meilleurs modules A, nous développons ' STUBS ».
«Stubs» peut être appelé code un extrait de code qui accepte les entrées / demandes du module supérieur et renvoie les résultats / la réponse. De cette façon, malgré les modules inférieurs, n'existent pas, nous sommes en mesure de tester le module supérieur.
Dans les scénarios pratiques, le comportement des stubs n'est pas aussi simple qu'il y paraît. Dans cette ère de modules et d'architecture complexes, le module appelé, implique la plupart du temps une logique métier complexe comme la connexion à une base de données. En conséquence, la création de stubs devient aussi complexe et prend du temps que le vrai module. Dans certains cas, le module Stub peut s'avérer plus gros que le module stimulé.
Les stubs et les pilotes sont des morceaux de code factices qui sont utilisés pour tester les modules «non existants». Ils déclenchent les fonctions / méthode et renvoient la réponse, qui est comparée au comportement attendu
Concluons une différence entre Stubs et pilote :
Bouts | Chauffeur |
---|---|
Utilisé dans l'approche descendante | Utilisé dans l'approche ascendante |
La plupart des modules sont testés en premier | Les modules les plus bas sont testés en premier. |
Stimule le niveau inférieur des composants | Stimule le niveau supérieur de composants |
Programme factice de composants de niveau inférieur | Programme factice pour composant de niveau supérieur |
Le seul changement est constant dans ce monde, nous avons donc une autre approche appelée « Test sandwich »Qui combine les caractéristiques de l'approche descendante et ascendante. Lorsque nous testons d'énormes programmes comme les systèmes d'exploitation, nous devons avoir plus de techniques qui sont efficaces et renforcent la confiance. Les tests sandwich jouent ici un rôle très important, où les tests top down et bottom up sont lancés simultanément.
L'intégration commence par la couche intermédiaire et se déplace simultanément vers le haut et vers le bas. Dans le cas de notre figure, nos tests commenceront à partir de B1 et B2, où un bras testera le module supérieur A et un autre bras testera les modules inférieurs B1C1, B1C2 & B2C1, B2C2.
Étant donné que les deux approches commencent simultanément, cette technique est un peu complexe et nécessite plus de personnes ainsi que des compétences spécifiques et augmente ainsi le coût.
Test d'intégration de l'application GUI
Voyons maintenant comment nous pouvons impliquer des tests d'intégration dans la technique de la boîte noire.
Nous comprenons tous qu'une application Web est une application à plusieurs niveaux. Nous avons un frontal qui est visible pour l'utilisateur, nous avons une couche intermédiaire qui a une logique métier, nous avons une couche intermédiaire supplémentaire qui effectue des validations, intègre des API tierces, etc., puis nous avons la couche arrière qui est la base de données.
Exemple de test d'intégration:
Regardons l'exemple ci-dessous:
Je suis propriétaire d'une agence de publicité et je publie des annonces sur différents sites Web. À la fin du mois, je souhaite voir combien de personnes ont vu mes annonces et combien de personnes ont cliqué sur mes annonces. J'ai besoin d'un rapport pour mes annonces affichées et je facture en conséquence à mes clients.
Logiciel GenNext développé ce produit pour moi et ci-dessous était l'architecture:
OIGNON - Module d'interface utilisateur, visible par l'utilisateur final, où toutes les entrées sont données.
BL - Est le module Business Logic, qui contient tous les calculs et méthodes spécifiques à l'entreprise.
VAL - Est le module Validation, qui a toutes les validations de l'exactitude de l'entrée.
CNT - Est le module de contenu qui a tout le contenu statique, spécifique aux entrées saisies par l'utilisateur. Ces contenus sont affichés dans les rapports.
DANS - Est le module Engine, ce module lit toutes les données provenant du module BL, VAL et CNT et extrait la requête SQL et la déclenche dans la base de données.
Planificateur - Est un module qui planifie tous les rapports en fonction de la sélection de l'utilisateur (mensuel, trimestriel, semestriel et annuel)
DB - Est la base de données.
Maintenant, après avoir vu l'architecture de l'ensemble de l'application Web, comme une seule unité, les tests d'intégration, dans ce cas, se concentreront sur le flux de données entre les modules.
Les questions ici sont:
- Comment les modules BL, VAL et CNT liront et interpréteront les données saisies dans le module UI?
- Le module BL, VAL et CNT reçoit-il les données correctes de l'interface utilisateur?
- Dans quel format les données de BL, VAL et CNT sont-elles transférées vers le module EQ?
- Comment l'égaliseur lira-t-il les données et extraira-t-il la requête?
- La requête est-elle extraite correctement?
- Le planificateur obtient-il les données correctes pour les rapports?
- L'ensemble de résultats reçu par l'EN, de la base de données est-il correct et conforme aux attentes?
- EN est-il capable de renvoyer la réponse au module BL, VAL et CNT?
- Le module d'interface utilisateur est-il capable de lire les données et de les afficher de manière appropriée sur l'interface?
Dans le monde réel, la communication des données se fait au format XML. Ainsi, quelles que soient les données saisies par l'utilisateur dans l'interface utilisateur, elles sont converties au format XML.
Dans notre scénario, les données saisies dans le module UI sont converties en fichier XML qui est interprété par les 3 modules BL, VAL et CNT. Le module EN lit le fichier XML résultant généré par les 3 modules et en extrait le SQL et interroge la base de données. Le module EN reçoit également l'ensemble de résultats et le convertit en un fichier XML et le renvoie au module d'interface utilisateur qui convertit les résultats sous une forme lisible par l'utilisateur et l'affiche.
Au milieu, nous avons le module de planification qui reçoit l'ensemble de résultats du module EN, crée et planifie les rapports.
Alors, où le test d'intégration entre en jeu?
Eh bien, tester si les informations / données circulent correctement ou non sera votre test d'intégration, qui dans ce cas validerait les fichiers XML. Les fichiers XML sont-ils générés correctement? Ont-ils les bonnes données? Les données sont-elles correctement transférées d'un module à un autre? Tous ces éléments seront testés dans le cadre des tests d'intégration.
Essayez de générer ou d'obtenir les fichiers XML et de mettre à jour les balises et de vérifier le comportement. C'est quelque chose de très différent des tests habituels que les testeurs font normalement, mais cela ajoutera de la valeur aux connaissances et à la compréhension des testeurs de l'application.
Peu d'autres conditions de test d'échantillon peuvent être les suivantes:
- Les options de menu génèrent-elles la bonne fenêtre?
- Les fenêtres peuvent-elles appeler la fenêtre testée?
- Pour chaque fenêtre, identifiez les appels de fonction pour la fenêtre que l'application doit autoriser.
- Identifiez tous les appels de la fenêtre vers d'autres fonctionnalités que l'application doit autoriser
- Identifier les appels réversibles: la fermeture d'une fenêtre appelée doit revenir à la fenêtre d'appel.
- Identifier les appels irréversibles: la fenêtre d'appel se ferme avant l'apparition de la fenêtre appelée.
- Testez les différentes manières d'exécuter des appels vers une autre fenêtre, par ex. - menus, boutons, mots-clés.
Étapes pour lancer les tests d'intégration
- Comprenez l'architecture de votre application.
- Identifier les modules
- Comprendre ce que fait chaque module
- Comprenez comment les données sont transférées d'un module à un autre.
- Comprendre comment les données sont saisies et reçues dans le système (point d'entrée et point de sortie de l'application)
- Séparez l'application en fonction de vos besoins de test.
- Identifier et créer les conditions de test
- Prenez une condition à la fois et notez les cas de test.
Critères d'entrée / sortie pour les tests d'intégration
Critères d'admission:
- Le document du plan de test d'intégration est signé et approuvé.
- Des cas de test d'intégration ont été préparés.
- Les données de test ont été créées.
- Test unitaire des modules / composants développés est terminé.
- Tous les défauts critiques et hautement prioritaires sont fermés.
- L'environnement de test est configuré pour l'intégration.
Critère de sortie:
- Tous les cas de test d'intégration ont été exécutés.
- Aucun défaut critique et de priorité P1 et P2 n'est ouvert.
- Le rapport d'essai a été préparé.
Cas de test d'intégration
Les cas de test d'intégration se concentrent principalement sur interface entre les modules, liaisons intégrées, transfert de données entre les modules en tant que modules / composants déjà testés unitairement, c'est-à-dire que la fonctionnalité et les autres aspects de test ont déjà été couverts.
Donc, l'idée principale est de tester si l'intégration de deux modules de travail fonctionne comme prévu une fois intégrée.
Pour les exemples de tests d'intégration pour l'application Linkedin, vous trouverez:
- Vérification du lien d'interface entre la page de connexion et la page d'accueil, c'est-à-dire lorsqu'un utilisateur entre les informations d'identification et se connecte, il doit être dirigé vers la page d'accueil.
- Vérifier le lien d'interface entre la page d'accueil et la page de profil, c'est-à-dire que la page de profil doit s'ouvrir.
- Vérifiez le lien d'interface entre la page réseau et vos pages de connexion, c'est-à-dire que cliquer sur le bouton Accepter sur les invitations de la page réseau devrait afficher l'invitation acceptée dans votre page de connexion une fois que vous avez cliqué.
- Vérifiez le lien d'interface entre les pages de notification et le bouton dire félicitations, c'est-à-dire que cliquer sur le bouton dire félicitations devrait diriger vers la nouvelle fenêtre de message.
De nombreux cas de test d'intégration peuvent être écrits pour ce site spécifique. Les quatre points ci-dessus ne sont qu'un exemple pour comprendre quels cas de test d'intégration sont inclus dans les tests.
L'intégration est-elle une technique de boîte blanche ou de boîte noire?
La technique de test d'intégration peut être comptée dans les deux boîtes noires ainsi que technique de la boîte blanche . Technique de la boîte noire C'est là où un testeur n'a pas besoin d'avoir une connaissance interne du système, c'est-à-dire que la connaissance du codage n'est pas requise alors que la technique de la boîte blanche nécessite une connaissance interne de l'application.
Désormais, tout en effectuant des tests d'intégration, il pourrait inclure le test des deux services Web intégrés qui récupéreront les données de la base de données et fourniront les données selon les besoins, ce qui signifie qu'il pourrait être testé à l'aide de la technique de test de boîte blanche tout en intégrant une nouvelle fonctionnalité dans le site Web peut être testé en utilisant la technique de la boîte noire.
Il n’est donc pas spécifique que les tests d’intégration soient une technique de boîte noire ou de boîte blanche.
Outils de test d'intégration
Il existe plusieurs outils disponibles pour ce test.
Ci-dessous, une liste d'outils:
- Testeur d'intégration rationnelle
- Rapporteur
- Vapeur
- TESSY
Pour plus de détails sur les outils ci-dessus, consultez ce tutoriel:
Top 10 des outils de test d'intégration pour écrire des tests d'intégration
Test d'intégration de système
Le test d'intégration du système est effectué pour tester le système intégré complet .
Les modules ou composants sont testés individuellement dans des tests unitaires avant d'intégrer les composants.
Une fois tous les modules testés, les tests d'intégration du système sont effectués en intégrant tous les modules et le système dans son ensemble est testé.
Différence entre les tests d'intégration et les tests système
Le test d'intégration est un test dans lequel un ou deux modules qui sont testés à l'unité sont intégrés pour tester et une vérification est effectuée pour vérifier si les modules intégrés fonctionnent comme prévu ou non.
Le test du système est un test où le système dans son ensemble est testé, c'est-à-dire que tous les modules / composants sont intégrés ensemble pour vérifier si le système fonctionne comme prévu et qu'aucun problème ne se produit à cause des modules intégrés.
Conclusion
Tout cela concerne les tests d'intégration et leur implémentation dans les techniques de la boîte blanche et de la boîte noire. J'espère que nous l'avons expliqué clairement avec des exemples pertinents.
L'intégration des tests est une partie importante du cycle de test car elle permet de trouver plus facilement le défaut lorsque deux modules ou plus sont intégrés afin d'intégrer tous les modules ensemble dans la première étape elle-même.
Cela aide à trouver les défauts à un stade précoce, ce qui économise également des efforts et des coûts. Il garantit que les modules intégrés fonctionnent correctement comme prévu.
J'espère que ce didacticiel informatif sur les tests d'intégration aurait enrichi votre connaissance du concept.
lecture recommandée
- Qu'est-ce que le test de composant ou le test de module (apprendre avec des exemples)
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- Spock pour l'intégration et les tests fonctionnels avec sélénium
- Les différences entre les tests unitaires, les tests d'intégration et les tests fonctionnels
- Intégration de Selenium avec JMeter
- Téléchargement de l'e-book 'Testing Primer'
- Test fonctionnel vs test non fonctionnel
- Tutoriel de test par paires ou de test toutes paires avec outils et exemples