Qu'est-ce que le test d'intégration de système?
Le test d'intégration de système 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.
Le test d'intégration de système (SIT) est effectué 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 bas niveau spécifiées dans les spécifications / données des exigences logicielles et le document de conception de logiciel.
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 former un système.
Par exemple, les composants logiciels et / ou matériels sont combinés et testés progressivement jusqu'à ce que tout le système soit intégré.
Dans ce didacticiel, vous apprendrez-
- Qu'est-ce que le test d'intégration de système?
- Pourquoi faire des tests d'intégration de système
- Comment faire des tests d'intégration système
- Critères d'entrée et de sortie pour les tests d'intégration
- Test d'intégration du matériel au logiciel
- Test d'intégration de logiciel à logiciel
- Approche descendante
- Une approche en profondeur
- Approche du Big Bang
Pourquoi faire des tests d'intégration de système
En génie logiciel, les tests d'intégration système sont effectués parce que,
- Il aide à détecter les défauts tôt
- Des commentaires plus tôt sur l'acceptabilité du module individuel seront disponibles
- La planification des corrections de défauts est flexible et peut se chevaucher avec le développement
- Corriger le flux de données
- Corriger le flux de contrôle
- Le bon timing
- Utilisation correcte de la mémoire
- Corriger avec les exigences logicielles
Comment faire des tests d'intégration système
C'est une technique systématique pour construire la structure du programme tout en effectuant des tests pour découvrir les erreurs associées à l'interfaçage.
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 ensemble d'erreurs est susceptible de se produire.
La correction de telles erreurs est difficile car les causes d'isolement sont compliquées par la vaste expansion de l'ensemble du programme. Une fois ces erreurs corrigé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émentielle. Nous verrons plus en détail une approche incrémentielle plus loin dans le didacticiel.
Il existe certaines méthodes incrémentielles comme les tests d'intégration sont effectués sur un système basé sur le processeur cible. La méthodologie utilisée est le Black Box Testing. Une intégration ascendante ou descendante peut être utilisée.
Les cas de test sont définis à l'aide des exigences logicielles de haut niveau uniquement.
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 à être simulées dans l'hôte. La répétition des tests dans l'environnement cible pour confirmation sera à nouveau nécessaire.
Les tests de confirmation à ce niveau identifieront les problèmes spécifiques à l'environnement, tels que les erreurs d'allocation de mémoire et de désallocation. Le caractère pratique de l'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 fort, ce qui rendra impossible la réalisation d'une intégration logicielle dans l'environnement hôte.
Les grands développements logiciels diviseront l'intégration logicielle en un certain nombre de niveaux. Les niveaux inférieurs d'intégration logicielle pourraient être basés principalement dans l'environnement hôte, les niveaux ultérieurs d'intégration logicielle devenant plus dépendants de l'environnement cible.
Remarque: Si seul le logiciel est testé, il est appelé Test d'intégration logicielle logicielle [SSIT] et si le matériel et le logiciel sont testés, alors il est appelé 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âche, Validation et Critères de sortie) est utilisée.
Critères d'admission:
- Achèvement des tests unitaires
Contributions:
- Données sur les exigences logicielles
- Document de conception de logiciel
- Plan de vérification du logiciel
- Documents d'intégration de logiciels
Activités:
- Sur la base des exigences de haut et 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 construction 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 plate-forme basée sur le processeur cible et obtenez les résultats
Critère de sortie:
- Réussite de l'intégration du module logiciel sur le matériel cible
- Corriger les performances du logiciel conformément aux exigences spécifiées
Les sorties
- Rapports de test d'intégration
- Cas de test et procédures de logiciels [SVCP].
Test d'intégration de logiciel matériel
Le test d'intégration logicielle matérielle est un processus de test des 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.
Test d'intégration matériel-logiciel basé sur les exigences
Le but 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 comprennent:
- Erreurs d'interface matériel / logiciel
- Violations du partitionnement logiciel.
- Incapacité à détecter les pannes par 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 incorrect du matériel de gestion de la mémoire
- Problème de contention de bus de données
- Fonctionnement incorrect du mécanisme pour vérifier la compatibilité et l'exactitude du logiciel chargeable sur le terrain
L'intégration logicielle matérielle s'occupe de la vérification des exigences de haut niveau. Tous les tests à ce niveau sont effectués sur le matériel cible.
- Le test de la boîte noire est la principale méthodologie de test utilisée à ce niveau de test.
- Définir des cas de test à partir des exigences de haut niveau uniquement
- Un test doit être exécuté sur du matériel standard de production (sur la cible)
Éléments à prendre en compte lors de la conception de cas de test pour l'intégration matérielle / logicielle
- Acquisition correcte de toutes les données par le logiciel
- Mise à l'échelle et plage de données attendues 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
- Interrompt le traitement
- Horaire
- Utilisation correcte 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'à la fin. Les cas de test seront spécifiquement conçus afin de tester adéquatement les interruptions.
Test d'intégration de logiciel à logiciel
C'est le test du composant logiciel de l'ordinateur fonctionnant dans l'ordinateur hôte / cible
Environnement, tout en simulant l'ensemble du système [autres CSC], et sur la fonctionnalité 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 (descendante, ascendante ou une combinaison des deux).
Approche incrémentale
Les tests incrémentiels sont un moyen de tester l'intégration. Dans ce type de méthode de test, vous testez d'abord chaque module du logiciel individuellement, puis continuez les tests en y ajoutant d'autres modules, puis un autre et ainsi de suite.
L'intégration incrémentale est le 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 vous déplacez vers le bas en intégrant les couches inférieures et inférieures comme indiqué dans l'image ci-dessous.
- En commençant par le module de contrôle principal, les modules sont intégrés en se déplaçant vers le bas dans la hiérarchie de contrôle
- Les sous-modules du module de commande principal sont incorporés dans la structure soit d'une manière en largeur d'abord, soit d'une manière en profondeur d'abord.
- L'intégration en profondeur d'abord 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 fait de la manière suivante:
- Le module de commande principal est utilisé comme pilote de test et les stubs sont remplacés par tous les modules directement subordonnés au module de commande principal.
- Les stubs subordonnés sont remplacés un par un par des modules réels en fonction de l'approche choisie (largeur en premier ou profondeur en premier).
- Les tests sont exécutés au fur et à mesure que chaque module est intégré.
- À la fin de chaque série de tests, un autre stub est remplacé par un vrai module à la fin de chaque série de tests
- Pour s'assurer qu'aucune nouvelle erreur n'a été introduite, des tests de régression peuvent être effectués.
Le processus continue à 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 survient lorsque le traitement à des niveaux bas de la hiérarchie est nécessaire pour tester de manière adéquate 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 stubs 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 des tests spécifiques et l'incorporation de modules spécifiques. Cela peut entraîner des difficultés à déterminer la cause des erreurs qui ont tendance à violer la nature très contraignante 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.
Une approche en profondeur
L'intégration ascendante commence la construction et les tests avec des 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
- Les modules de bas niveau sont combinés en clusters qui exécutent une sous-fonction logicielle spécifique.
- Un pilote est écrit pour coordonner l'entrée et la sortie du cas de test.
- Le cluster ou la construction est testé.
- Les pilotes sont supprimés et les grappes sont combinées en progressant vers le haut dans la structure du programme.
Au fur et à mesure que l'intégration progresse, il est nécessaire de disposer de leçons distinctes pour les pilotes de test. En fait, 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 grappes est grandement simplifiée. L'intégration suit le modèle illustré ci-dessous. Au fur et à mesure que l'intégration progresse, il est nécessaire de disposer de leçons distinctes pour les pilotes de test.
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 versions 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 qu'ils sont 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 première de l'échec du fait de tout intégrer à la fois.
En outre, il y aura de fortes chances d'apparition des bogues critiques dans l'environnement de production.
Cette approche n'est adoptée que lorsque les tests d'intégration doivent être effectués en une seule fois.
Résumé:
- L'intégration est effectuée pour vérifier les interactions entre les modules d'un système logiciel. Il aide à détecter rapidement les défauts
- Les 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, Tâche, Validation et Critères de sortie) est généralement utilisée.