Qu'est-ce qu'un test d'intégration ?

Qu’est-ce qu’un test d’intégration ?

La signification des tests d’intégration est assez simple : intégrer/combiner les modules testés un par un et tester leur comportement comme une unité combinée.

La fonction principale ou le but de ce test est de tester les interfaces/intéractions entre les unités/modules.

Nous effectuons normalement les tests d’intégration après les tests de composants (test unitaires). Une fois que toutes les composants individuelles sont créées et testées, nous commençons à intégrer ces modules « testés en unité » et à effectuer les tests d’intégration.

La fonction principale ou le but de ces tests est de tester les interfaces/l’interaction/l’interopérabilité entre les unités/modules.

Exemple: Est ce que toutes les informations communiquées entre le back office et le front office sont bien les bonnes.

Les modules individuels sont d’abord testés de manière isolée. Une fois les modules testés en unité, ils sont intégrés avec différentes méthodes (Big bang, on intègre tout d’un coup, ou alors de façon incrémentale (de bas en haut « Bottom Top » ou du haut vers le bas : « Top down » : 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 mises en œuvre correctement ou non.

Il faut comprendre que les tests d’intégration ne sont pas effectués à la fin du cycle, mais en même temps que le développement. Ainsi, la plupart du temps, tous les modules ne sont pas réellement disponibles pour être testés et c’est là que réside le défi de tester quelque chose qui n’existe pas !

Pour pallier ce risque, les testeurs utilisent des pilotes ou bouchons (un morceaux de code qui servira de simulateur) pour pouvoir réaliser leurs tests d’intégration.


Pourquoi tester l’intégration ?

Nous pensons que le test d’intégration est complexe et nécessite un certain développement et des compétences logiques. C’est vrai !

Alors quel est le but d’intégrer ce test dans notre stratégie de test ?

Voici quelques raisons :

  1. Dans le monde réel, lorsqu’une application est développée, elle est décomposée en modules plus petits et chaque développeur se voit attribuer un module. La logique mise en œuvre par un développeur est très différente de celle d’un autre développeur, il devient donc important de vérifier si la logique mise en œuvre par un développeur est conforme aux attentes et rend la valeur correcte conformément aux normes prescrites.
  2. Souvent, le visage ou la structure des données change lorsqu’elles passent d’un module à l’autre. Certaines valeurs sont ajoutées ou supprimées, ce qui pose des problèmes dans les modules ultérieurs.
  3. Les modules interagissent également avec des outils ou des API tiers qui doivent également être testés pour vérifier que les données acceptées par l’API ou l’outil sont correctes et que la réponse générée est également conforme aux attentes.
  4. Un problème très courant dans les tests : les changements fréquents d’exigences ! 🙂 Il arrive souvent que le développeur déploie les changements sans les tester à l’unité. Les tests d’intégration deviennent importants à ce moment-là.


Avantages

Il y a plusieurs avantages à ce test et quelques-uns 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 dès que les modules à tester sont disponibles. Il n’est pas nécessaire que l’autre module soit terminé pour que le test soit effectué, car les stubs (bouchons) et les pilotes peuvent être utilisés pour cela.
  • Il détecte les erreurs liées à l’interface.


Défis

Voici une liste de quelques défis que pose le test d’intégration.

  1. Le test d’intégration consiste à tester deux systèmes intégrés ou plus 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 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é.
  2. La gestion des tests d’intégration devient complexe en raison des nombreux facteurs impliqués, tels que la base de données, la plate-forme, l’environnement, etc.
  3. L’intégration d’un nouveau système dans un système existant nécessite beaucoup de changements et d’efforts de test. Il en va de même pour l’intégration de deux systèmes existants.
  4. L’intégration de deux systèmes différents développés par deux entreprises différentes est un grand défi car on ne sait pas comment l’un des systèmes aura un impact sur l’autre si des changements sont effectués dans l’un des systèmes. Afin de minimiser l’impact lors du développement d’un système, quelques éléments doivent être pris en considération comme l’intégration possible avec d’autres systèmes, etc.


Types de tests d’intégration

Vous trouverez ci-dessous un type de test d’intégration ainsi que ses avantages et ses inconvénients.


Approche Big Bang :

L’approche Big Bang intègre tous les modules en une seule fois, c’est-à-dire qu’elle ne va pas intégrer les modules un par un. Elle vérifie si le système fonctionne comme prévu ou non une fois intégré. Si un problème est détecté dans le module complètement intégré, il devient alors difficile de trouver quel module a causé le problème.

L’approche Big Bang est un processus qui prend beaucoup de temps pour trouver un module qui a un défaut, car cela prend du temps et une fois le défaut détecté, le réparer coûte 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.
  • Si pressé par le temps, ca permet d’intégrer rapidement les composants

Inconvénients de l’approche Big Bang :
  • Il est difficile de détecter l’origine du problème d’intégration (est ce le composant 1 qui s’est mal intégré avec le composant 7).
  • L’approche Big Bang exige que tous les modules soient testés ensemble, ce qui réduit le temps consacré aux tests car la conception, le développement et l’intégration prennent la majeure partie du temps.
  • Les tests ont lieu en une seule fois, ce qui ne laisse pas de temps pour tester les modules critiques de manière isolée.


Étapes du test d’intégration :

  1. Préparer le plan projet de test d’intégration.
  2. Préparer les scénarios de test d’intégration et les cas de test.
  3. Préparer les scripts d’automatisation des tests (si besoin)
  4. Exécuter les cas de test.
  5. Signaler les défauts.
  6. Suivre et re-tester les défauts.
  7. Le re-testage et le test se poursuivent jusqu’à ce que le test d’intégration soit terminé.


Approches de l’intégration des tests

Il y a fondamentalement 2 approches pour faire l’intégration des tests :

  1. L’approche ascendante
  2. L’approche descendante.


Approche ascendante (bottom up) pu du bas vers le haut :

Le test ascendant, comme son nom l’indique, commence par l’unité la plus basse ou la plus interne de l’application, et progresse progressivement vers le haut. Le test d’intégration commence par le composant le plus bas et progresse progressivement vers les composants supérieurs de l’application. Cette intégration se poursuit jusqu’à ce que tous les comosants 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é en unité. Les modules B1 et B2 ne sont pas encore développés. La fonctionnalité des modules B1 et B2 est qu’ils appellent les modules B1C1, B1C2 & B2C1, B2C2. Comme B1 et B2 ne sont pas encore développés, nous avons besoin d’un programme ou d’un « stimulateur » qui appelle les modules B1C1, B1C2 et B2C1, B2C2. Ces programmes stimulateurs sont appelés DRIVERS.

En d’autres termes, les DRIVERS sont des programmes factices qui sont utilisés pour appeler les fonctions du module le plus bas dans le cas où la fonction d’appel n’existe pas. La technique ascendante exige que le pilote du module alimente l’interface du module testé avec les entrées du cas de 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 fait que lorsque le dernier module est intégré et testé. Par conséquent, les défauts de conception de niveau supérieur ne seront détectés qu’à la fin.


Approche descendante (top down ou du haut vers le bas)

Cette technique part du composant le plus élevé et progresse progressivement vers les modules inférieurs. Seul le module supérieur est testé de manière isolée. Ensuite, 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.

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. Ici, les modules inférieurs B1 et B2 ne sont pas réellement disponibles pour l’intégration. Ainsi, afin de tester les modules supérieurs A, nous développons des « STUBS » (bouchons)

Les « Stubs » peuvent être considérés comme un extrait de code qui accepte les entrées/demandes du module supérieur et renvoie-les résultats/réponses. De cette façon, malgré l’inexistence des modules inférieurs, 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 n’y paraît. À l’ère des modules et des architectures complexes, le module appelé, la plupart du temps, implique une logique commerciale complexe comme la connexion à une base de données. Par conséquent, la création de stubs devient aussi complexe et longue que le module réel. Dans certains cas, le module Stub peut s’avérer être plus grand que le module stimulé.

Les stubs et les drivers (pilotes) sont des éléments de code factices utilisés pour tester les modules « non existants ». Ils déclenchent les fonctions/méthodes et renvoient la réponse, qui est comparée au comportement attendu.

Le seul changement est constant dans ce monde, nous avons donc une autre approche appelée « test en sandwich » qui combine les caractéristiques des approches descendante et ascendante. Lorsque nous testons d’énormes programmes comme les systèmes d’exploitation, nous devons disposer de techniques supplémentaires qui sont efficaces et renforcent la confiance. Le test sandwich joue un rôle très important ici, où les tests descendants et ascendants sont lancés simultanément.

L’intégration commence par la couche intermédiaire et se déplace simultanément vers le haut et le bas. Dans le cas de notre figure, nos tests commenceront par 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.

Comme les deux approches commencent simultanément, cette technique est un peu complexe et nécessite plus de personnes avec des compétences spécifiques, ce qui augmente le coût.


Étapes pour lancer les tests d’intégration

Comprenez l’architecture de votre application : Identifier la base de test (toutes références qui décrit l’intégration des composants: exemple (document d’architecture, exigences fonctionnelles, spécifications …)

  1. Identifier les modules
  2. Comprendre ce que fait chaque module
  3. Comprendre comment les données sont transférées d’un module à l’autre.
  4. Comprendre comment les données sont entrées et reçues dans le système (point d’entrée et point de sortie de l’application).
  5. Séparer l’application pour répondre à vos besoins de test.
  6. Identifiez et créez les conditions de test
  7. Prenez une condition à la fois et écrivez les cas de test.


Critères d’entrée/sortie pour les tests d’intégration


Critères d’entrée :

  • Le document du plan projet de test d’intégration est signé et approuvé.
  • Les cas de test d’intégration ont été préparés.
  • Les données de test ont été créées.
  • Les tests unitaires des modules/composants développés sont terminés.
  • Tous les défauts critiques et de haute priorité sont fermés.
  • L’environnement de test est configuré pour l’intégration.


Critères de sortie :

  • Tous les cas de test d’intégration ont été exécutés.
  • Aucun défaut critique et prioritaire P1 & P2 n’est ouvert.
  • Le rapport de test a été préparé.


Cas de test d’intégration

Les cas de test d’intégration se concentrent principalement sur l’interface/intéraction entre les modules, les liens intégrés, le transfert de données entre les modules en tant que modules/composants qui sont déjà testés en unité, c’est-à-dire que la fonctionnalité et les autres aspects de test ont déjà été couverts.

Ainsi, l’idée principale est de tester si l’intégration de deux modules fonctionnels fonctionne comme prévu lorsqu’ils sont intégrés.

Par exemple, les cas de test d’intégration pour l’application Linkedin comprendront :

  • La vérification du lien d’interface entre la page de connexion et la page d’accueil, c’est-à-dire que lorsqu’un utilisateur saisit 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érifier le lien d’interface entre la page du réseau et vos pages de connexion, c’est-à-dire qu’en cliquant sur le bouton d’acceptation des invitations de la page du réseau, l’invitation acceptée doit s’afficher dans votre page de connexion après avoir été cliquée.
  • Vérifiez le lien d’interface entre les pages de notification et le bouton « félicitations », c’est-à-dire qu’en cliquant sur le bouton « félicitations », vous serez dirigé vers la fenêtre du nouveau message.

De nombreux cas de tests d’intégration peuvent être écrits pour ce site spécifique. Les quatre points ci-dessus sont juste un exemple pour comprendre ce que les cas de test d’intégration sont inclus dans les tests.


L’intégration est-elle une technique boîte blanche ou boîte noire ?

La technique de test d’intégration peut être considérée comme une boîte noire ou une boîte blanche. La technique de la boîte noire est celle 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.

En effectuant des tests d’intégration, on peut tester les deux services Web intégrés qui vont chercher les données dans la base de données et fournir les données requises, ce qui signifie qu’ils peuvent être testés en utilisant la technique de la boîte blanche, tandis que l’intégration d’une nouvelle fonctionnalité dans le site Web peut être testée en utilisant la technique de la boîte noire.

Ainsi, il n’est pas spécifique que le test d’intégration soit une technique boîte noire ou boîte blanche.


Outils de test d’intégration

Il existe plusieurs outils disponibles pour ces tests.

Vous trouverez ci-dessous une liste d’outils :
  • Rational Integration Tester
  • Protractor
  • Steam
  • TESSY


Test d’intégration du système

Le test d’intégration du système est effectué pour tester le système intégré complet.

Les modules ou les composants sont testés individuellement dans les tests unitaires avant d’intégrer les composants.

Une fois que tous les modules sont testés, le test d’intégration du système est effectué 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 de système

Le test d’intégration est un test dans lequel un ou deux modules testés en unité sont intégrés pour être testés et la vérification est faite pour vérifier si les modules intégrés fonctionnent comme prévu ou non.

Le test de 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 si aucun problème ne survient à cause des modules intégrés.


Conclusion

Tout ceci concerne les tests d’intégration et leur mise en œuvre dans les techniques de boîte blanche et de boîte noire. Nous espérons l’avoir expliqué clairement à l’aide d’exemples pertinents.

Les tests d’intégration est une partie importante du cycle de test car elle permet de trouver plus facilement les défauts lorsque deux ou plusieurs modules sont intégrés afin d’intégrer tous les modules ensemble dans la première étape elle-même.

Elle aide à trouver les défauts à un stade précoce, ce qui permet de réduire les efforts et les coûts. Il garantit que les modules intégrés fonctionnent correctement comme prévu.