Qu'est-ce qu'un exemple de test d'intégration système (SIT) (2024)

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 (SIT) sont effectués pour vérifier les interactions entre les modules d'un système logiciel. Il traite de la vérification des exigences logicielles de haut et de bas niveau spécifiées dans les spécifications/données des exigences logicielles et le document de conception logicielle. Il vérifie également la coexistence d'un système logiciel avec d'autres et teste l'interface entre les modules de l'application logicielle. Dans ce type de test, les modules sont d'abord testés individuellement, puis combinés pour constituer un système. Par exemple, les composants logiciels et/ou matériels sont combinés et testés progressivement jusqu'à ce que l'ensemble du système soit intégré.

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

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écouvrir les erreurs associé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. Nous verrons plus de détails sur une approche incrémentale later dans le tutoriel.

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 Essais. 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 identifieront les problèmes spécifiques à l'environnement, tels que les erreurs d'allocation et de désallocation de mémoire. L’aspect pratique de la conduite intégration de logiciels dans l'environnement hôte dépendra de la quantité de fonctionnalités spécifiques à la cible. Pour certains systèmes embarqués le couplage avec l'environnement cible sera très simpletrong, ce qui rend peu pratique l'intégration de logiciels dans l'environnement hôte.

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, avec later les niveaux d’intégration logicielle deviennent de plus en plus dépendants de l’environnement cible.

Remarque: 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].

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

Habituellement, lors de l'exécution des tests d'intégration, la stratégie ETVX (critères d'entrée, tâches, validation et critères de sortie) est utilisée.

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].

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
• Incorrect operation d'un mécanisme permettant de vérifier la compatibilité et l'exactitude des logiciels chargeables 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.

• Noir box les tests 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
• Temps de livraison
• Corriger l'utilisation de la mémoire (adressage, chevauchements, etc.)
• Transitions d'état

Remarque: 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 operaau sein de l'ordinateur hôte/cible

Environnement, tout en simulant l'ensemble du système [autres CSC], et sur les fonctionnalités de haut niveau.

Il se concentre sur le comportement d'un CSC dans un environnement hôte/cible simulé. L'approche utilisée pour l'intégration logicielle peut être une approche incrémentale (approche descendante, ascendante ou une combinaison des deux).

Approche incrémentale

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 petit* 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 en tant qu'affichage.yed dans la suitewing diagramme:

Le processus d'intégration du module se déroule comme suitwing manière:

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.

Remarque: 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 des frais généraux importants, car les stubs deviennent de plus en plus complexes.plex.

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 exécutent 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 construction est testée.
4. Les pilotes sont supprimés et clusterLes programmes sont combinés en remontant dans la structure du programme.

À mesure que l’intégration progresse, il devient nécessaire de dispenser des cours distincts aux pilotes d’essai. En fait, si les deux niveaux supérieurs de la structure du programme sont intégrés de haut en bas, le nombre de facteurs déterminants peut être considérablement réduit, et l'intégration des clusters est grandement simplifié. L'intégration suit le modèle illustré ci-dessous. À mesure que l’intégration progresse, il devient nécessaire de dispenser des cours distincts aux pilotes d’essai.

Remarque: 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.

Résumé

• L'intégration est effectuée pour vérifier les interactions entre les modules d'un système logiciel. Cela aide à détecter les défauts à un stade précoce
• Des tests d'intégration peuvent être effectués pour l'intégration matériel-logiciel ou matériel-matériel.
• Les tests d'intégration sont effectués par deux méthodes
  • Approche incrémentale
  • Approche big-bang
• Lors de l'exécution des tests d'intégration, la stratégie ETVX (critères d'entrée, de tâche, de validation et de sortie) est généralement utilisée.