Qu’est-ce que le SIT ? Tests d’intégration système avec exemple

Qu’est-ce que les tests d’intégration système ?

Système Test d'intégration est défini comme un type de test logiciel effectué dans un environnement matériel et logiciel intégré pour vérifier le comportement du système complet. Il s'agit de tests effectués sur un système complet et intégré pour évaluer la conformité du système à ses exigences spécifiées.

Les tests d'intégration système (TIS) sont réalisés pour vérifier les interactions entre les modules d'un système logiciel. Ils consistent à vérifier les exigences logicielles de haut et de bas niveau spécifiées dans le cahier des charges/les données des exigences logicielles et le document de conception logicielle.

Les tests d'intégration système (SIT) vérifient également la coexistence d'un système logiciel avec d'autres et testent l'interface entre les modules de l'application. Dans ce type de test, les modules sont d'abord testés individuellement, puis combinés pour former un système. Par exemple, les composants logiciels et/ou matériels sont combinés et testés progressivement jusqu'à l'intégration complète du système.

Le diagramme ci-dessus illustre la progression qui définit le SIT : les modules vérifiés séparément sont fusionnés étape par étape jusqu’à ce qu’il ne reste plus qu’un seul système intégré sous test.

Pourquoi effectuer des tests d'intégration système ?

En génie logiciel, les tests d'intégration de systèmes sont effectués car,

• Cela aide à détecter Défaut tôt
• Des commentaires antérieurs sur l’acceptabilité de chaque module seront disponibles
• La planification des corrections de défauts est flexible et peut chevaucher le développement
• Flux de données correct
• Flux de contrôle correct
• Synchronisation correcte
• Utilisation correcte de la mémoire
• Corriger avec les exigences logicielles

Tests d'intégration système vs tests système vs tests d'acceptation utilisateur

Comme ces trois niveaux se succèdent, ils sont souvent confondus. Test du système SIT examine une version finale par rapport à ses exigences, SIT examine les points de jonction entre les versions, et User Acceptance Test Elle examine la performance de l'entreprise du point de vue du client. Le tableau ci-dessous les distingue.

Paramètres	Tests d'intégration système	Test du système	User Acceptance Test
Objectif principal	Interfaces et flux de données entre les modules intégrés	Comportement de l'ensemble assemblé	L'aptitude professionnelle pour une utilisation réelle
Niveau de test	Niveau deux	Niveau trois	Dernière étape avant la mise en service
Technique	Boîte noire	boîte noire, boîte blanche ou boîte grise	Boîte noire
Interprété par	testeurs d'intégration et développeurs	Équipe de test indépendante	Clients ou utilisateurs finaux
défauts typiques	Interface, synchronisation, mémoire et carte de donnéesping erreurs	Erreurs fonctionnelles et non fonctionnelles du système	Inadéquation entre l'utilisabilité et les exigences
S'exécute lorsque	Après Tests unitaires	Après SIT	Après les tests du système

L'ordre est important. Les modules passent les tests unitaires, les tests d'intégration système (SIT) valident les interfaces, les tests système valident le produit assemblé et les tests d'acceptation utilisateur (UAT) confirment que le produit répond aux attentes métier. Passer à l'étape suivante.ping SIT repousse les défauts d'interface jusqu'à la phase de test d'acceptation utilisateur (UAT), où chaque correction coûte beaucoup plus cher à réaliser.

Comment effectuer des tests d'intégration système

Il s'agit d'une technique systématique permettant de construire la structure du programme tout en effectuant des tests pour déceler les erreurs liées à l'interface.

Tous les modules sont intégrés à l'avance et l'ensemble du programme est testé dans son ensemble. Mais au cours de ce processus, un certain nombre d’erreurs sont susceptibles de se produire.

La correction de telles erreurs est difficile car l'isolement des causes est compliqué par la vaste expansion de l'ensemble du programme. Une fois ces erreurs rectifiées et corrigées, une nouvelle apparaîtra et le processus se poursuivra de manière transparente dans une boucle sans fin.. Pour éviter cette situation, une autre approche est utilisée : l’intégration incrémentale. Cette approche est expliquée en détail dans la section suivante.

Il existe certaines méthodes incrémentielles telles que les tests d'intégration sont effectués sur un système basé sur le processeur cible. La méthodologie utilisée est Noir Box Tests. Une intégration ascendante ou descendante peut être utilisée.

Les cas de test sont définis en utilisant uniquement les exigences logicielles de haut niveau.

L'intégration logicielle peut également être réalisée en grande partie dans l'environnement hôte, les unités spécifiques à l'environnement cible continuant d'être simulées dans l'hôte. Il sera à nouveau nécessaire de répéter les tests dans l’environnement cible pour confirmation.

Les tests de confirmation à ce niveau permettront d'identifier les problèmes spécifiques à l'environnement, tels que les erreurs d'allocation et de libération de mémoire. La faisabilité de l'intégration logicielle dans l'environnement hôte dépendra de l'importance des fonctionnalités spécifiques à la cible. Pour certains systèmes embarqués, le couplage avec l'environnement cible sera très fort, rendant l'intégration logicielle dans l'environnement hôte impraticable.

Les développements logiciels à grande échelle diviseront l’intégration logicielle en plusieurs niveaux. Les niveaux inférieurs d'intégration logicielle pourraient être basés principalement sur l'environnement hôte, les niveaux ultérieurs d'intégration logicielle devenant davantage dépendants de l'environnement cible.

À noter: Si seul le logiciel est testé, cela s'appelle Test d'intégration logicielle logicielle [SSIT] et si le matériel et les logiciels sont testés, cela s'appelle Test d'intégration logicielle matérielle [HSIT].

Approche incrémentale

Étant donné que l'intégration de tous les éléments en même temps rend difficile l'isolement des défauts, la plupart des équipes suivent la voie progressive décrite ici.

Les tests incrémentiels sont une méthode de test d'intégration. Dans ce type de méthode de test, vous testez d'abord chaque module du logiciel individuellement, puis continuez le test en y ajoutant d'autres modules, puis un autre et ainsi de suite.

L’intégration incrémentale contraste avec l’approche du big bang. Le programme est construit et testé en petits segments, où les erreurs sont plus faciles à isoler et à corriger. Les interfaces sont plus susceptibles d'être testées complètement et une approche de test systématique peut être appliquée.

Il existe deux types de tests incrémentiels

• Approche descendante
• Une approche en profondeur

Approche descendante

Dans ce type d'approche, l'individu commence par tester uniquement l'interface utilisateur, avec la fonctionnalité sous-jacente simulée par des stubs, puis vous descendez en intégrant des couches de plus en plus basses, comme le montre l'image ci-dessous.

• En commençant par le module de contrôle principal, les modules sont intégrés en descendant dans la hiérarchie de contrôle.
• Les sous-modules du module de commande principal sont incorporés dans la structure soit en largeur d'abord, soit en profondeur.
• L'intégration en profondeur intègre tous les modules sur un chemin de contrôle majeur de la structure, comme illustré dans le diagramme suivant :

Le processus d'intégration du module se déroule de la manière suivante :

1. Le module de contrôle principal est utilisé comme pilote de test et les talons remplacent tous les modules directement subordonnés au module de contrôle principal.
2. Les talons subordonnés sont remplacés un par un par des modules réels en fonction de l'approche choisie (largeur d'abord ou profondeur d'abord).
3. Les tests sont exécutés au fur et à mesure de l'intégration de chaque module.
4. A la fin de chaque série de tests, un autre stub est remplacé par un module réel à la fin de chaque série de tests
5. Pour s'assurer qu'aucune nouvelle erreur n'a été introduite Les tests de régression peut être effectuée.

Le processus se poursuit à partir de l'étape 2 jusqu'à ce que la structure entière du programme soit construite. La stratégie descendante semble relativement simple, mais dans la pratique, des problèmes logistiques surviennent.

Le plus courant de ces problèmes se produit lorsqu'un traitement aux niveaux inférieurs de la hiérarchie est nécessaire pour tester correctement les niveaux supérieurs.

Les stubs remplacent les modules de bas niveau au début des tests descendants et, par conséquent, aucune donnée significative ne peut remonter dans la structure du programme.

Défis auxquels le testeur pourrait être confronté :

• Retardez de nombreux tests jusqu'à ce que les talons soient remplacés par des modules réels.
• Développez des stubs qui exécutent des fonctions limitées qui simulent le module réel.
• Intégrez le logiciel du bas de la hiérarchie vers le haut.

À noter: La première approche nous fait perdre un certain contrôle sur la correspondance entre les tests spécifiques et l'incorporation de modules spécifiques. Cela peut entraîner des difficultés à déterminer la cause des erreurs, ce qui tend à violer la nature hautement contrainte de l'approche descendante.

La deuxième approche est réalisable mais peut entraîner une surcharge importante, à mesure que les stubs deviennent de plus en plus complexes.

Une approche en profondeur

L'intégration ascendante commence la construction et les tests avec les modules au niveau le plus bas de la structure du programme. Dans ce processus, les modules sont intégrés de bas en haut.

Dans cette approche, le traitement requis pour les modules subordonnés à un niveau donné est toujours disponible et le besoin de stubs est éliminé.

Ce processus de test d'intégration est effectué en une série de quatre étapes

1. Les modules de bas niveau sont combinés en clusters qui remplissent une sous-fonction logicielle spécifique.
2. Un pilote est écrit pour coordonner les entrées et les sorties du scénario de test.
3. Le cluster ou la build est testé.
4. Les pilotes sont supprimés et les clusters sont combinés en montant dans la structure du programme.

À mesure que l'intégration progresse, le besoin de leçons distinctes pour les pilotes de test diminue. En effet, si les deux niveaux supérieurs de la structure du programme sont intégrés de manière descendante, le nombre de pilotes peut être considérablement réduit et l'intégration des clusters grandement simplifiée. L'intégration suit le modèle illustré ci-dessous.

À noter: Si les deux niveaux supérieurs de la structure du programme sont intégrés de haut en bas, le nombre de pilotes peut être considérablement réduit et l'intégration des builds est grandement simplifiée.

Approche du Big Bang

Dans cette approche, tous les modules ne sont pas intégrés tant que tous les modules ne sont pas prêts. Une fois prêts, tous les modules sont intégrés puis exécutés pour savoir si tous les modules intégrés fonctionnent ou non.

Dans cette approche, il est difficile de connaître la cause profonde de l’échec car il faut tout intégrer en même temps.

En outre, il y aura de fortes chances que des bogues critiques surviennent dans l’environnement de production.

Cette approche n'est adoptée que lorsque les tests d'intégration doivent être effectués en même temps.

Tests d'intégration matérielle et logicielle

Tests d'intégration matérielle et logicielle est un processus de test de composants logiciels informatiques (CSC) pour des fonctionnalités de haut niveau sur l'environnement matériel cible. L'objectif des tests d'intégration matériel/logiciel est de tester le comportement des logiciels développés intégrés sur le composant matériel.

Tests d'intégration matériel-logiciel basés sur les exigences

L'objectif des tests d'intégration matériel/logiciel basés sur les exigences est de s'assurer que le logiciel de l'ordinateur cible satisfera aux exigences de haut niveau. Les erreurs typiques révélées par cette méthode de test incluent :

• Erreurs d'interfaces matérielles/logicielles
• Violations du partitionnement logiciel.
• Incapacité de détecter les pannes par le test intégré
• Réponse incorrecte aux pannes matérielles
• Erreur due au séquençage, aux charges d'entrée transitoires et aux transitoires de puissance d'entrée
• Comportement incorrect des boucles de rétroaction
• Contrôle incorrect ou inapproprié du matériel de gestion de la mémoire
• Problème de conflit de bus de données
• Fonctionnement incorrect du mécanisme permettant de vérifier la compatibilité et l'exactitude du logiciel chargeable sur site

L'intégration matérielle et logicielle s'occupe de la vérification des exigences de haut niveau. Tous les tests à ce niveau sont effectués sur le matériel cible.

• Les tests en boîte noire sont la principale méthodologie de test utilisée à ce niveau de test.
• Définir cas de test uniquement à partir des exigences de haut niveau
• Un test doit être exécuté sur du matériel standard de production (sur cible)

Éléments à prendre en compte lors de la conception de scénarios de test pour l'intégration matérielle/logicielle

• Acquisition correcte de toutes les données par le logiciel
• Mise à l'échelle et gamme de données comme prévu, du matériel au logiciel
• Sortie correcte des données du logiciel vers le matériel
• Données conformes aux spécifications (plage normale)
• Données hors spécifications (plage anormale)
• Données limites
• Traitement des interruptions
• Timing
• Corriger l'utilisation de la mémoire (adressage, chevauchements, etc.)
• Transitions d'état

À noter: Pour les tests d'interruption, toutes les interruptions seront vérifiées indépendamment de la demande initiale jusqu'à la maintenance complète et jusqu'à l'achèvement. Les cas de test seront spécifiquement conçus afin de tester adéquatement les interruptions.

Tests d'intégration logiciel à logiciel

Il s'agit du test du composant logiciel informatique fonctionnant dans l'environnement informatique hôte/cible, tout en simulant l'ensemble du système [autres CSC], et sur la fonctionnalité de haut niveau.

Ce document porte sur le comportement d'un CSC dans un environnement hôte/cible simulé. L'approche d'intégration logicielle peut être incrémentale (descendante, ascendante ou une combinaison des deux, également appelée approche sandwich ou hybride).

Critères d'entrée et de sortie pour les tests d'intégration

Une fois l'approche et les deux variantes d'intégration définies, il reste à déterminer quand une équipe peut commencer et quand elle peut arrêter. Généralement, lors des tests d'intégration, on utilise la stratégie ETVX (critères d'entrée, tâches, validation et critères de sortie).

Critère d'entrée:

• Achèvement de Tests unitaires

Entrées:

• Données sur la configuration logicielle requise
• Document de conception de logiciel
• Plan de vérification du logiciel
• Documents d'intégration logicielle

Activités:

• Sur la base des exigences de haut et de bas niveau, créer des cas de test et des procédures
• Combinez des versions de modules de bas niveau qui implémentent une fonctionnalité commune
• Développer un harnais de test
• Tester la construction
• Une fois le test réussi, la version est combinée avec d'autres versions et testée jusqu'à ce que le système soit intégré dans son ensemble.
• Réexécutez tous les tests sur la plateforme basée sur le processeur cible et obtenez les résultats

Critères de sortie:

• Réussite de l'intégration du module Logiciel sur le Matériel cible
• Performance correcte du logiciel selon les exigences spécifiées

Sortie

• Rapports de tests d'intégration
• Cas et procédures de tests logiciels [SVCP].

Défis courants des tests d'intégration de systèmes

Même avec une approche rigoureuse et des critères de sortie clairs, les environnements intégrés engendrent des problèmes qui ne se manifestent jamais lors des tests unitaires. Les identifier au plus tôt permet de respecter le calendrier prévu.

• Inadéquation de l'environnement : l'intégré environnement de test La production reflète rarement la réalité, de sorte que les défauts de synchronisation et de configuration ne sont détectés que très tardivement.
• Préparation à la dépendance : Les interfaces tierces et les interfaces héritées sont souvent inachevées, ce qui oblige les testeurs à utiliser des stubs et des simulateurs bien plus longtemps que prévu.
• Incohérence des données : Deux modules peuvent représenter différemment le même enregistrement, produisant des incohérences silencieuses au lieu de défaillances visibles.
• Propriété du défaut : lorsqu'une défaillance concerne deux équipes, l'analyse des causes profondes et gestion des défauts ralentir sensiblement.
• Coût de régression : chaque nouvelle interface agrandit le les tests de régression la suite, de sorte que la réexécution manuelle devient rapidement impossible à maintenir.

La plupart de ces risques sont liés au calendrier plutôt qu'à des impasses techniques. Définir les dates de disponibilité des interfaces, le périmètre du simulateur et la responsabilité du tri des anomalies avant l'intégration de la première version permet d'en éliminer la majorité. Pour les interfaces appartenant au fournisseur, il est également important de consigner le format des messages convenu et les coordonnées d'un contact en cas d'escalade, car l'absence de responsable retarde la correction plus longtemps que ne le justifie la nature de l'anomalie.

Meilleures pratiques pour les tests d’intégration de systèmes

Un cycle SIT reproductible dépend moins des outils que de la rigueur appliquée aux interfaces, aux données et aux preuves. Les cinq pratiques ci-dessous conviennent aussi bien à une petite configuration embarquée qu'à un vaste environnement multi-fournisseurs, et chacune permet de réduire les reprises lors des phases de test ultérieures.

1. Cartographiez d'abord chaque interface. Avant d'écrire un seul cas de test, listez chaque échange de données, sa direction, son protocole et son propriétaire.
2. Prioriser par risque. Vérifiez les interfaces transportant des données financières, d'identité ou réglementées avant les interfaces purement esthétiques.
3. Concevoir des données de test réalistes. Couvrir les plages normales, limites et anormales afin que les erreurs d'échelle et d'arrondi apparaissent rapidement.
4. Automatisez les chemins stables. L'interface filaire vérifie dans un intégration continue pipeline afin que chaque compilation les revérifie.
5. Conserver des preuves traccapable. Associez chaque résultat à une exigence via un tracmatrice de capacité Les critères de sortie peuvent donc être prouvés, et non pas seulement affirmés.

⚠ Conseil : Figez les spécifications d'interface avant de commencer l'intégration. Toute modification tardive du format d'un message invalide les cas de test des deux côtés de l'interface et constitue la principale cause de reprise des tests d'intégration système.

FAQ