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.
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 ?
Il y a plusieurs avantages à ce test et quelques-uns d’entre eux sont énumérés ci-dessous.
Voici une liste de quelques défis que pose le test d’intégration.
Vous trouverez ci-dessous un type de test d’intégration ainsi que ses avantages et ses inconvénients.
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.
Il y a fondamentalement 2 approches pour faire l’intégration des tests :
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.
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.
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 …)
Les cas de test d’intégration se concentrent principalement sur l’interface/interaction 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 :
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.
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.
Il existe plusieurs outils disponibles pour ces tests.
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é.
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.
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.
N’hésitez pas a enregistrer notre cheatsheet pour ne plus jamais vous tromper entre test d’intégration et test de système.
