Qu’est-ce que le test d’intégration de système?
Le test d’intégration de système (SIT) est le test global de l’ensemble du système qui est composé de nombreux sous-systèmes. L’objectif principal du SIT est de s’assurer que toutes les dépendances des modules logiciels fonctionnent correctement et que l’intégrité des données est préservée entre les modules distincts de l’ensemble du système.
Le SIT (System Under Test) peut être composé de matériel, de base de données, de logiciels, d’une combinaison de matériel et de logiciels ou d’un système qui nécessite une interaction humaine (HITL – Human in the Loop Testing).
Dans le contexte de l’ingénierie logicielle et des tests logiciels, le SIT peut être considéré comme un processus de test qui vérifie la cooccurrence du système logiciel avec d’autres.
Le SIT a un prérequis dans lequel plusieurs systèmes intégrés sous-jacents ont déjà subi et réussi des tests système. Le SIT teste alors les interactions requises entre ces systèmes dans leur ensemble. Les livrables du SIT sont transmis à l’UAT (User acceptance testing).
Nécessité du test d’intégration du système
La principale fonction du SIT est de faire des tests de dépendances entre les différents composants du système et donc, le test de régression est une partie importante du SIT.
Pour les projets collaboratifs, le SIT fait partie du STLC (Software Testing lifecycle). Généralement, un tour de pré-SIT est effectué par le fournisseur du logiciel avant que le client n’exécute ses propres cas de test SIT.
Dans la plupart des organisations travaillant sur des projets informatiques suivant le modèle de sprint Agile, un tour de SIT est effectué par l’équipe d’assurance qualité avant chaque version. Les défauts trouvés dans le SIT sont renvoyés à l’équipe de développement et ils travaillent sur les correctifs.
La version MVP (Minimum Viable Product) du sprint ne va que lorsqu’elle passe par le SIT.
Le SIT est nécessaire pour exposer les défauts qui se produisent lorsque l’interaction se produit entre les sous-systèmes intégrés.
Il y a plusieurs composants utilisés dans le système et ils ne peuvent pas être testés individuellement par unité. Même si l’unité est testée individuellement, alors aussi il y a une possibilité qu’elle échoue lorsqu’elle est combinée dans le système, car il y a de nombreux problèmes qui surviennent lorsque les sous-systèmes interagissent les uns avec les autres.
Donc, le SIT est très nécessaire pour exposer et corriger les défaillances avant de déployer le système chez l’utilisateur. Le SIT détecte les défauts à un stade précoce et permet ainsi d’économiser le temps et le coût de la correction ultérieure. Il vous aide également à obtenir un retour plus précoce sur l’acceptabilité du module.
La granularité du SIT
Le SIT peut être mené à trois niveaux de granularité différents :
(i) Test intra-système : Il s’agit d’un test d’intégration de bas niveau qui vise à fusionner les modules pour construire un système unifié.
(ii) Test inter-système : Il s’agit d’un test de haut niveau qui nécessite l’interfaçage de systèmes testés indépendamment.
(iii) Test par paires : Ici, seuls deux sous-systèmes interconnectés dans l’ensemble du système sont testés à la fois. Cela vise à s’assurer que les deux sous-systèmes peuvent bien fonctionner lorsqu’ils sont combinés ensemble en présumant que les autres sous-systèmes fonctionnent déjà bien.
Comment réaliser des tests d’intégration de systèmes ?
La façon la plus simple de réaliser des TIS est la méthode axée sur les données. Elle nécessite une utilisation minimale des outils de test logiciel.
D’abord, l’échange de données (importation et exportation de données) se produit entre les composants du système, puis le comportement de chaque champ de données au sein de la couche individuelle est examiné.
Une fois que le logiciel est intégré, il existe trois états principaux du flux de données, comme mentionné ci-dessous :
#1) État des données au sein de la couche d’intégration
La couche d’intégration agit comme une interface entre l’importation et l’exportation de données. L’exécution de l’ITS au niveau de cette couche nécessite des connaissances de base sur certaines technologies comme le schéma (XSD), XML, WSDL, DTD et EDI.
La performance de l’échange de données peut être examinée au niveau de cette couche à travers les étapes suivantes :
- Valider les propriétés des données au sein de cette couche par rapport au BRD/ FRD/ TRD (document d’exigences commerciales/ document d’exigences fonctionnelles/ document d’exigences techniques).
- Cross check the web service request using XSD and WSDL.
- Run some unit tests and validate the data mappings and requests.
- Review the middleware logs.
#2) Data state within the Database layer
Performing SIT at this layer requires a basic knowledge of SQL and stored procedures.
La performance de l’échange de données au niveau de cette couche peut être examinée à travers les étapes suivantes :
- Vérifier si toutes les données de la couche d’intégration sont parvenues avec succès au niveau de la couche de base de données et ont été engagées.
- Valider les propriétés des tables et des colonnes par rapport au BRD/ FRD/ TRD.
- Valider les contraintes et les règles de validation des données appliquées dans la base de données conformément aux spécifications métier.
- Vérifier les procédures stockées pour toute donnée de traitement.
- Revoir les journaux du serveur.
#3) État des données au sein de la couche Application
La SIT peut être effectuée au niveau de cette couche par les étapes suivantes :
- Vérifier si tous les champs requis sont visibles dans l’interface utilisateur.
- Exécuter quelques cas de test positifs et négatifs et valider les propriétés des données.
Note : Il peut y avoir beaucoup de combinaisons correspondant à l’importation et à l’exportation de données. Vous devrez exécuter le SIT pour les meilleures combinaisons en tenant compte du temps dont vous disposez.
Test de système Vs test d’intégration de système
Différences entre le test de système et le SIT :
| SIT (System Integration Testing) | System Testing |
|---|---|
| Le SIT est principalement effectué pour vérifier comment les modules individuels interagissent entre eux lorsqu’ils sont intégrés dans un système dans son ensemble. | Les tests système sont principalement effectués pour vérifier si l’ensemble du système fonctionne comme prévu en référence aux exigences spécifiées. |
| Ils sont effectués après les tests unitaires et seront effectués chaque fois qu’un nouveau module est ajouté au système. | Ils sont effectués au niveau final c’est-à-dire.c’est-à-dire après l’achèvement des tests d’intégration et juste avant de livrer le système pour l’UAT. |
| Il s’agit d’un test de bas niveau. | Il s’agit d’un test de haut niveau. |
| Les cas de test SIT se concentrent sur l’interface entre les composants du système. | Les cas de test, dans ce cas, se concentrent sur la simulation des scénarios de la vie réelle. |
Test d’intégration du système Vs test d’acceptation de l’utilisateur
Voici la différence entre SIT et UAT :
| SIT (System Integration Testing) | UAT (User Acceptance Testing) |
|---|---|
| Ce test est du point de vue de l’interfaçage entre les modules. | Ce test est du point de vue des exigences des utilisateurs. |
| SIT est effectué par les développeurs et les testeurs. | UAT est effectué par les clients et les utilisateurs finaux. |
| Fait après les tests unitaires et avant les tests système. | C’est le dernier niveau de test et il est fait après les tests système. |
| Généralement, les problèmes trouvés dans le SIT seraient liés au flux de données, au flux de contrôle, etc. | Les problèmes trouvés dans UAT seraient généralement comme les fonctionnalités qui ne fonctionnent pas selon les exigences des utilisateurs. |
L’image ci-dessous sur les niveaux de test vous rendrait clair le flux des tests unitaires à l’UAT :
Exemple de SIT
Supposons qu’une entreprise utilise un logiciel pour stocker les coordonnées des clients.
Ce logiciel comporte deux écrans dans l’interface utilisateur – écran 1 & écran 2, et il possède une base de données. Les détails saisis dans l’écran 1 et l’écran 2 sont saisis dans la base de données. À ce jour, l’entreprise est satisfaite de ce logiciel.
Cependant, quelques années plus tard, l’entreprise constate que le logiciel ne répond pas aux exigences et qu’il est nécessaire de l’améliorer. Par conséquent, ils ont développé un écran 3 et une base de données. Maintenant, ce système ayant un écran 3 et une base de données est intégré au logiciel plus ancien/existant.
Maintenant, le test effectué sur l’ensemble du système après l’intégration est appelé test d’intégration du système. Ici, la coexistence d’un nouveau système avec un système existant est testée pour s’assurer que l’ensemble du système intégré fonctionne bien.
Techniques SIT
Principalement, il existe 4 approches pour faire le SIT :
- Approche descendante
- Approche ascendante
- Approche sandwich
- Approche Big Bang
L’approche descendante et l’approche ascendante sont une sorte d’approches incrémentales. Commençons d’abord la discussion avec l’approche descendante.
#1) Approche descendante :
Dans ce cadre, le test commence avec juste le module le plus haut d’une application c’est-à-dire l’interface utilisateur que nous appelons comme un pilote de test.
La fonctionnalité des modules sous-jacents est simulée avec des stubs. Le module supérieur est intégré au stub du module de niveau inférieur un par un et plus tard la fonctionnalité est testée.
Une fois que chaque test est terminé, le stub est remplacé par le module réel. Les modules peuvent être intégrés soit de manière breadth-first, soit de manière depth-first. Le test continue jusqu’à ce que l’application entière soit construite.
L’avantage de cette approche est qu’il n’y a pas besoin de pilotes et que les cas de test peuvent être spécifiés en termes de fonctionnalité du système.
Le principal défi de ce type d’approche est la dépendance à la disponibilité de la fonctionnalité des modules de niveau inférieur. Il peut y avoir un retard dans les tests jusqu’à ce que les modules réels soient remplacés par des stubs. L’écriture des stubs est également difficile.
#2) Approche ascendante :
Elle élimine les limitations de l’approche descendante.
Dans cette méthode, tout d’abord, les modules de plus bas niveau sont assemblés pour former des clusters. Ces clusters servent de sous-fonction de l’application. Ensuite, un pilote est créé pour gérer l’entrée et la sortie des cas de test. Après cela, le cluster est testé.
Une fois que le cluster est testé, le pilote est supprimé, et le cluster est combiné avec le niveau supérieur suivant. Ce processus se poursuit jusqu’à ce que toute la structure de l’application soit réalisée.
Il n’y a pas besoin de stubs dans cette approche. Elle se simplifie au fur et à mesure que le traitement se déplace vers le haut et que le besoin de pilotes se réduit. Cette approche est conseillée pour faire le SIT pour les systèmes orientés objet, les systèmes temps réel et les systèmes avec des besoins stricts de performance.
Cependant, la limitation de cette approche est le sous-système le plus important c’est-à-dire l’interface utilisateur est testé en dernier.
#3) Approche sandwich :
Ici, les approches top down et bottom up discutées ci-dessus sont combinées ensemble.
Le système est perçu comme ayant trois couches – la couche intermédiaire qui est la couche cible, une couche au-dessus de la cible et une couche en dessous de la cible. Les tests sont effectués dans les deux sens et se rassemblent au niveau de la couche cible qui se trouve au milieu, ce qui est illustré dans l’image ci-dessous.
Stratégie de test en sandwich
Un avantage de cette approche est que la couche supérieure et la couche inférieure du système peuvent être testées en parallèle. Cependant, la limitation de cette approche est qu’elle ne teste pas de manière exhaustive les sous-systèmes individuels avant l’intégration.
Pour éliminer cette limitation, nous avons modifié le test sandwich dans lequel l’intégration des couches supérieure, intermédiaire et inférieure sont testées en parallèle en utilisant des stubs et des pilotes.
#4) Approche Big Bang:
Dans cette approche, l’intégration est effectuée une fois que tous les modules de l’application sont complètement prêts. Les tests sont effectués après l’intégration de tous les modules pour vérifier si le système intégré fonctionne ou non.
Il est difficile de trouver la cause profonde du problème dans cette approche car tout est intégré en une seule fois, contrairement aux tests incrémentaux. Cette approche est généralement adoptée lorsqu’un seul tour de SIT est nécessaire.
Conclusion
Dans cet article, nous avons appris ce qu’est le test d’intégration du système (SIT) et pourquoi il est important de l’effectuer.
Nous avons compris les concepts de base, les techniques, les approches et les méthodes impliquées dans la réalisation du SIT. Nous avons également parcouru comment le SIT est différent de l’UAT et des tests de système.
J’espère que vous avez apprécié cet excellent article !!