Test d'intégration Maintenant que chaque unité a fait
ses preuves correctement individuellement et prêt à partir, le niveau suivant serait de mettre ces
unités ensemble pour construire le système. C'est ce que nous
appelons l'intégration. À ce stade, les testeurs se
concentrent uniquement sur l'intégration elle-même. Par exemple, si ils
intègrent le module A avec le module B, ils sont intéressés à tester la
communication entre les modules, pas la fonctionnalité du module individuel car cela a déjà été
fait lors des tests de composants. Base de test Ainsi,
des exemples de produits de travail qui peuvent être utilisé comme base de
test pour les tests d'intégration
comprennent: • Conception de logiciels et de systèmes • Diagrammes de séquence
• Spécifications d'interface et de protocole de communication • Cas d'utilisation
• Architecture au niveau des composants ou du système •
Workflows • Définitions d'interface externe Objets de test Bien que
les objets de
test typiques pour les tests d'intégration
incluent: • Sous-systèmes • Bases de données • Infrastructure
• Interfaces • API • Microservices
Objectifs des tests d'intégration Les tests d'intégration se concentrent sur les interactions
entre les composants ou les systèmes. Objectifs des tests d'intégration comprennent:
• Réduction des risques • Vérification de la conformité des
comportements fonctionnels et non fonctionnels des interfaces et spécifié
• Renforcer la confiance dans la qualité des les interfaces •
Recherche de défauts (qui peuvent être dans les interfaces eux-mêmes ou au sein des composants ou des systèmes)
• Empêcher les défauts de s’échapper niveaux de test Comme
pour les tests de composants, dans certains cas automatisés les tests de régression d'intégration
donnent l'assurance que les changements n'ont pas brisé les interfaces existantes, composants ou systèmes.
Il existe deux niveaux d'intégration différents tests décrits dans ce programme: • Les tests d'intégration de composants se
concentrent sur les interactions et les interfaces entre les composants intégrés et est
effectuée après test des composants. Ce type de test d'intégration est
généralement effectué par les développeurs et est généralement automatisé. En développement itératif et incrémental,
intégration de composants les tests font généralement partie du
processus d'intégration continue. • Les tests d'intégration système se concentrent sur
les interactions et les interfaces entre les systèmes, packages et microservices. Nous parlons donc ici de plus gros
objets de test… des systèmes. Les tests d'intégration de système peuvent également couvrir les
interactions et les interfaces fournies par des organisations externes (e. g. , services Web).
Pour utiliser l'exemple de la voiture, l'intégration du système est fait lorsque la voiture entière
est déjà assemblée et testée et que vous voulez essayer la voiture avec un autre système,
disons un camping-car… la voiture fonctionne parfaitement bien par elle-même et le camping-car fonctionne
bien par lui-même et maintenant vous voulez essayer les 2 ensemble, en particulier l'attelage partie qui relie la voiture au camping-car.
Pour avoir un exemple de l'industrie du logiciel, un système commercial d'une
banque d'investissement interagira avec la bourse pour obtenir le derniers cours de ses actions
et parts sur le marché international. Ce type d'intégration les tests sont généralement effectués par des testeurs.
Dans ce cas, l'organisation en développement ne contrôle pas les interfaces externes, ce qui peut créer
divers défis pour les tests (e. g. , en veillant à ce que
les défauts de blocage des tests dans le code de l'organisation externe soient résolu, organisation des environnements de
test, etc. ). Les tests d'intégration
du système peuvent être effectués après les tests du système ou en parallèle avec les tests en cours les activités de test du
système (en développement séquentiel et en itération et incrémental développement).
Idéalement, les testeurs devraient comprendre l'architecture et influencer la planification de l'intégration. Si des tests d'intégration sont prévus
avant les composants ou les systèmes sont construits, nous pouvons peut-être construire ces composants
dans l'ordre requis pour les tests les plus efficaces.
Défauts et défaillances typiques Voici des exemples de défauts et d'échecs typiques pour
les tests d'intégration de composants: • Données incorrectes,
données manquantes ou encodage de données incorrect • Séquencement
ou synchronisation incorrects
des appels d'interface • Inadéquation de l'interface • Défaillances de communication entre les composants
• Défaillances de communication non gérées ou mal gérées entre les composants
• Hypothèses incorrectes sur la signification, les unités ou les limites des données
transmises entre les composants Exemples de défauts et de
défaillances typiques pour les tests
d'intégration du système comprennent: • Des structures de messages incohérentes
entre systèmes • Données incorrectes, données manquantes ou incorrectes encodage
des données • Inadéquation de l'interface • Défaillances dans la communication
entre les systèmes • Communication non gérée ou mal gérée défaillances entre
systèmes • Hypothèses incorrectes sur la signification, unités ou limites des données
transmises entre les systèmes
• Non-respect des règles
de sécurité obligatoires Approches et responsabilités spécifiques • Fonctionnelles, non fonctionnelles et structurelles les types de tests sont applicables.
• Il existe différentes stratégies d’intégration: o intégration «big bang» où nous intégrons un ensemble d'unités en une seule
étape, résultant en un système complet. Le problème avec ce type d'intégration
qu'il semble comme construire le système plus rapidement mais dans la vie
réelle, cela prend beaucoup plus de temps. Soit parce que nous devrons attendre d'avoir
un tas d'unités prêtes à intégrer ou pour la fait que lors des tests de ce
système, il est difficile d'isoler les erreurs trouvées. Nous avons une erreur causée lorsque peu d'unités
ont été ajoutées, alors quelle unité a causé l'erreur… c'est difficile à savoir.
o Mais d'autre part, il y a plus systématique des stratégies d'intégration qui reposent généralement sur:  l'architecture
du système (e. g. , de
haut en bas et de bas en haut),  tâches fonctionnelles,  séquences de traitement
des transactions, ou  certains autres aspects du système ou des composants.
Dans de telles stratégies systématiques - où nous intégrer les composants un par
un - il est beaucoup plus facile d'isoler et de détecter les défauts tôt, l'intégration
devrait normalement être progressive (i. e. , un petit nombre de composants
supplémentaires ou des systèmes à la fois) plutôt que du big bang • Plus la portée de l'intégration
est grande, plus il devient difficile d'isoler les défauts d'un composant ou d'un système spécifique, ce qui peut entraîner
un risque accru et un délai supplémentaire pour le dépannage. C’est une des raisons intégration continue, où le logiciel
est intégré composant par composant (je. e. , intégration fonctionnelle),
est devenu une pratique courante. Une telle intégration continue comprend souvent des tests
de régression automatisés, idéalement à plusieurs niveaux de test. • Une analyse des risques des interfaces les plus complexes
peut aider à concentrer les tests d'intégration.