Utilisateur:Seldin/Brouillon
- → N'hésitez pas à publier sur le brouillon un texte inachevé et à le modifier autant que vous le souhaitez.
- → Pour enregistrer vos modifications au brouillon, il est nécessaire de cliquer sur le bouton bleu : « Publier les modifications ». Il n'y a pas d'enregistrement automatique.
Si votre but est de publier un nouvel article, votre brouillon doit respecter les points suivants :
- Respectez le droit d'auteur en créant un texte spécialement pour Wikipédia en français (pas de copier-coller venu d'ailleurs).
- Indiquez les éléments démontrant la notoriété du sujet (aide).
- Liez chaque fait présenté à une source de qualité (quelles sources – comment les insérer).
- Utilisez un ton neutre, qui ne soit ni orienté ni publicitaire (aide).
- Veillez également à structurer votre article, de manière à ce qu'il soit conforme aux autres pages de l'encyclopédie (structurer – mettre en page).
- → Si ces points sont respectés, pour transformer votre brouillon en article, utilisez le bouton « publier le brouillon » en haut à droite. Votre brouillon sera alors transféré dans l'espace encyclopédique.
Pour les articles homonymes, voir Intégration.
Dans le monde du développement informatique, le test d'intégration est une phase dans les tests, qui est précédée des tests unitaires et est généralement suivi par les tests de validation[1]. Dans le test unitaire, on vérifie le bon fonctionnement d'une partie précise d'un logiciel ou d'une portion d'un programme (appelée « unité » ou « module »), dans le test d’intégration chacun des modules indépendants du logiciel sont assemblés et testés dans l’ensemble.
Objectif[modifier | modifier le code]
L'objectif de chaque phase de test est de détecter les erreurs qui n'ont pas pu être détectées lors de la précédente phase. Pour cela, le test d’intégration a pour cible de détecter les erreurs non détectables par le Test unitaire[2].
Le test d’intégration permet également de vérifier l'aspect fonctionnel, les performances et la fiabilité du logiciel. L'intégration fait appel en général à un système de gestion de versions, et éventuellement à des programmes d'installation. Cela permet d'établir une nouvelle version, basée soit sur une version de maintenance, soit sur une version de développement.
L'organisation d'un test d’intégration[3][modifier | modifier le code]
Le but de l'organisation d'un test d’intégration est de définir la stratégie de l'activité de test d’intégration en terme d'ordre d’intégration, de test à réaliser, du matériel sur lequel seront lancés les tests et les outils /procédure employée.
Il est recommandé d'employer la procédure suivante pour l'organisation d'un test d’intégration, cette procédure peut être adaptée en fonction des besoins. Par exemple pour un système comprenant plusieurs sous-systèmes, il est d'usage de répéter la procédure n° 3 (contenu des spécifications des tests d'intégration) pour chacun des sous-systèmes.
- Introduction et organisation
- présentation du document
- décrire l'organisation en terme de procédure à suivre et les outils et matériels disponibles pour l'équipe d’intégration
- Stratégie
- identifier le produit fini du test d’intégration
- identifier les spécifications du test d'intégration qui doivent être produites
- mettre en évidence l’intérêt de chaque test
- définir l'ordre dans lequel les tests doivent être effectués
- Contenu des spécifications du test d’intégration
- pour chaque spécification mentionnée dans la stratégie, définir l’assemblage inhérent aux tests et les attentes du design qui sont à vérifier
- identifier la configuration matérielle requise pour le test
- lister les outils et logiciels de test
- identifier les assemblages précédemment testés nécessaires au test.
Méthode d’approche de l’intégration[modifier | modifier le code]
Il existe plusieurs méthodes pour les tests d’intégration dont voici les plus courants : Top-down, Bottom-up, Sandwich et Big-bang[4]
Pour une meilleur compréhension, ce schéma va être employé comme exemple pour chaque cas :
Top-down[modifier | modifier le code]
On teste les modules les plus hauts puis ceux en dessous.
On obtient donc les tests de :
- première étape
- 1
- seconde étape
- 1, 2 et 3
- troisième étape
- 1, 2, 3, 4, 5 et 6
- quatrième étape
- 1, 2, 3, 4, 5, 6, 7, 8 et 9
Les avantages :[modifier | modifier le code]
- Localisation des erreurs plus facile
- Nécessite peu de Mock (ou driver)
- Possibilité d'obtenir un prototype rapidement
- Plusieurs ordres de test/ implémentation(s) possible(s)
- Les erreurs de conception majeures sont détectées en premier dans les modules au plus haut niveau
Les désavantages :[modifier | modifier le code]
- Nécessite beaucoup de stubs (bouchon de test[5])
- Des modules de bas niveau potentiellement réutilisables risquent d'être mal testés
Bottom-up[modifier | modifier le code]
On teste les modules du plus bas niveau puis ceux plus hauts qui les appellent. On obtient donc :
- première étape
- 7
- 8
- 9
- seconde étape
- 4
- 5, 7 et 8
- 9 et 6
- troisième étape
- 2, 4, 5, 7 et 8
- 3, 6 et 9
- quatrième étape
- 1, 2, 3, 4, 5, 6, 7, 8 et 9
Les avantages[modifier | modifier le code]
- Localisation facile des erreurs
- Aucun besoin de stub
- Les modules réutilisables sont testés correctement
- Les tests peuvent se faire en parallèle avec le développement
Les désavantages[modifier | modifier le code]
- Nécessite des Mocks
- Les modules de haut niveau sont testés en dernier
- Aucun squelette de système n'est conceptualisé
Sandwich[modifier | modifier le code]
On combine ici les intégrations Top-down et Bottom-up. Il faut distinguer 3 niveaux :
- Niveau logique (haut)
- Niveau cible (milieu)
- Niveau opérationnel (bas)
On teste en même temps les modules de haut et bas niveau, puis on avance vers le centre, méthode réunissant les avantages des deux précédentes.
- première étape
- 1
- 7 et 8
- 9
- seconde étape
- 1, 2 et 3
- 5, 7 et 8
- 6 et 9
- 4
- troisième étape
- 1, 2, 3, 4, 5 et 6
- 2, 4, 5, 7 et 8
- 3, 6 et 9
- quatrième étape
- 1, 2, 3, 4, 5, 6, 7, 8 et 9
Les avantages[modifier | modifier le code]
- Le niveau haut et bas peuvent être testés en parallèle
- Diminuer les besoins en mock et en stub.
Les désavantages[modifier | modifier le code]
- Plus complexe à planifier
- Le niveau cible peut être difficile à définir
Big-bang[modifier | modifier le code]
Il s’agit d'une intégration non-incrémental. On intègre tous les modules d'un coup juste après les tests unitaires.
Les avantages[modifier | modifier le code]
- Convient aux petits systèmes
- Gain de temps
Les désavantages[modifier | modifier le code]
- besoin de mock et de stub pour chaque module
- ne permet pas le développement en parallèle
- rend la localisation des erreurs difficile
- les erreurs d'interface peuvent facilement passer inaperçues
Outils utilisés[modifier | modifier le code]
Pour les applications utilisant les nouvelles technologies et donc des ateliers de génie logiciel (Eclipse - Visual Studio - JBuilder - JDeveloper ...), les tests d’intégration ont évolué vers de l’intégration continue.
L’intégration continue est la fusion des tests unitaires et des tests d’intégration, car le programmeur détient toute l’application sur son poste et peut donc faire de l’intégration tout au long de son développement.
Notes et références[modifier | modifier le code]
- H.K.N. Leung & L. White, A study of integration testing and software regression at the integration level , p. 293, Software Maintenance, 1990, Proceedings
- Paul C. Jorgensen & Carl Erickson, Object-oriented integration testing, p. 31, Communications of the ACM Sept 1994
- Martyn A Ould & Charles Unwin (ed), Testing in Software Development, BCS (1986), p. 73-74. Accessed 31 Oct 2014
- G. J. Myers, Software reliability: principles and practices, New York: Wiley-Interscience, 1976
- Benoit Baudry, Test d’intégration, p. 12
Bibliographie[modifier | modifier le code]
(en) Martyn A. Ould et Charles Unwin, « Testing in Software Development », Accessed 31 Oct 2014, (lire en ligne)
(en) Paul C. Jorgensen et Carl Erickson, « Object-oriented integration testing », Communications of the ACM, vol. 37 Issue 9, , p. 30-38 (DOI 10.1145/182987.182989)
(en) H.K.N. Leung et L. White, « A study of integration testing and software regression at the integration level », Software Maintenance, 1990, Proceedings, , p. 290 - 301 (DOI 10.1109/ICSM.1990.131377)
Vous êtes ici sur la page personnelle d’un utilisateur de Wikipédia en français.
Cette page ne fait pas partie de l’espace encyclopédique de Wikipédia.
Si vous avez accédé à cette page depuis un autre site que celui de Wikipédia en français, c’est que vous êtes sur un site miroir ou un site qui fait de la réutilisation de contenu. Cette page n’est peut-être pas à jour et l’utilisateur identifié n’a probablement aucune affiliation avec le site sur lequel vous vous trouvez. L’original de cette page se trouve à l'adresse suivante : https://fr.wikipedia.org/wiki/Utilisateur:Seldin/Brouillon.