Qu'est-ce qu'un test d'intégration?


110

Mes amis et moi avons eu du mal à classer exactement ce qu'est un test d'intégration.

En rentrant chez moi, je viens de me rendre compte que chaque fois que j’essaie de donner un exemple concret de test d’intégration, c’est un test d’acceptation, c’est-à-dire. Quelque chose qu'un homme d'affaires dirait à haute voix et spécifie ce que le système devrait fournir.

J'ai consulté la documentation de Ruby on Rails pour connaître leur classification de ces types d'essais, et elle est maintenant complètement rejetée.

Pouvez-vous me donner une brève description académique d'un test d'intégration avec un exemple du monde réel?


76
BTW, lorsque vous avez une phrase nominale ("moi et quelques amis"), vous devez faire attention à la première personne du singulier que vous utilisez. Voici le test. Déposez les amis et voyez si cela fonctionne toujours. "Je me suis battu" vs "Je me suis battu". Ce test vous dit que c’est "moi et mes amis ...". Et pour être poli, nous en énumérons d’autres d’abord. "Mes amis et moi". Le test est important.
S.Lott

58
Je pense que S.Lott vient de vous faire passer un test d’intégration grammaire> société.
Jordanie

Réponses:


78

Pour le moment, j'aime bien cette déclaration: "Ce n'est pas important ce que vous appelez, mais ce qu'il fait" faite par Gojko Adzic dans cet article .

Vous devez vraiment spécifier aux personnes qui parlent les tests ce que vous avez l’intention de tester.

Beaucoup de gens ont des points de vue différents selon leur rôle.

Pour les testeurs, TMap est une méthodologie de test généralement acceptée aux Pays-Bas . TMap fait la distinction suivante.

  • Test de l'unité
  • test d'intégration unitaire
  • test du système
  • test d'intégration système
  • test d'acceptation (tous types / niveaux)
  • test d'acceptation fonctionnelle
  • test d'acceptation utilisateur
  • test d'acceptation de production

Ils ont des types plus spécifiques de tests qui peuvent être effectués dans les tests mentionnés ci-dessus. Regardez ce mot doc pour un aperçu.

Wikipedia a également un bon aperçu .

Le livre du programmeur pragmatique dit:

  • un test unitaire est un test qui exerce un module
  • les tests d'intégration montrent que les principales parties d'un système fonctionnent bien ensemble

En examinant ces différentes sources et en intégrant certaines de mes propres expériences et opinions, je commencerais par distinguer trois catégories.

  • qui fait les tests en général
  • ce qui est testé
  • quel est le but du test

    • Test unitaire : teste la logique dans les classes par les programmeurs pour montrer la correction au niveau du code. Ils doivent être rapides et ne pas dépendre d'autres parties du système que vous n'avez pas l'intention de tester.
    • Test d'acceptation fonctionnelle : teste un scénario de cas d'utilisation sur un ensemble de données limité (spécialement créé) effectué par le service de test pour montrer que chaque scénario spécifié fonctionne comme prévu.
    • Test d'acceptation des utilisateurs : teste des scénarios de cas d'utilisation sur la production, tels que des données effectuées par des représentants des utilisateurs pour les amener à accepter formellement l'application.
    • Test d'intégration : testez les chemins de communication entre les différentes parties du module, réalisés par le service de test ou les développeurs, pour montrer que tous les modules fonctionnent correctement ensemble.

Ma liste ci-dessus n’est qu’un début et une suggestion, mais j’ai vraiment l’impression que: «L’appel que vous appelez n’est pas important, mais son rôle»

J'espère que cela t'aides.

26-10-2016 Edit: Récemment, une très belle introduction a été placée sur les tests unitaires YouTube et les tests d'intégration - Les réflexions de MPJ - FunFunFunction # 55


3
+1 Pour le "peu importe comment vous l'appelez". Malheureusement, il n’existe pas de définition universelle de tout type de test. Même le bon vieux test unitaire est un peu variable. Tester le DOM pour une application Web est-il considéré comme un test unitaire? Certains disent oui, certains disent non.
Laurent Bourgault-Roy

2
Le lien vers le mot doc n'est pas disponible.
Paul Rougieux

6
"Ce n'est pas important ce que vous appelez ça" s'applique à toute l'informatique, et en fait à presque tous les domaines. Je trouve que beaucoup des arguments enflammés dans lesquels les gens se débattent peuvent être résumés en "nous nous disputons au sujet de la définition d'une phrase arbitraire".
Gardenhead

Je suis d'accord sur les définitions: j'ai été à un endroit où "Test unitaire" indique que le programmeur a essayé le système avec au moins un échantillon d'entrée ... manuellement ... et a visuellement vérifié le résultat s'il "semblait correct" . Aucun contrat quant à ce qui était attendu, aucun intrant contrôlé, etc.
Newtopian

Le lien vers Gojko renvoie un 404. Vous pouvez accéder à une archive ici: web.archive.org/web/20150104002755/http://gojko.net/2011/01/12/…
Eduardo Copat

32

test d'intégration, il s'avère être un test d'acceptation

Évidemment.

Ces deux sont presque la même chose. Mais la définition du test présente des dimensions légèrement différentes.

Intégration == le système dans son ensemble.

Acceptation == le système dans son ensemble.

La seule différence - et c'est subtile - est la définition des cas de test.

Intégration == cas de test pour tester la profondeur et le degré d'intégration. Est-ce que cela fonctionne pour tous les cas extrêmes et les cas d'angle? Les cas de test tendent à être techniques, écrits par des concepteurs et des codeurs.

Acceptance == cas de test pour n'exercer que 80% de l'ensemble des fonctionnalités axées sur l'utilisateur final. Pas tous les cas bord et coins. Les cas de test ont tendance à être non techniques, rédigés par les utilisateurs finaux.


7
La seule chose que je voudrais ajouter à cela, c'est que les tests d'intégration peuvent également tester seulement une partie du système, mais plus d'un élément à la fois. Chaque fois que vous recherchez des bogues causés par deux ou plusieurs parties du système travaillant à l'unisson (intégrées ensemble), vous effectuez des tests d'intégration. L’intégration s’étend de deux composants réels et de tout le reste, jusqu’à l’ensemble de la suite d’applications pouvant aller jusqu’à vérifier l’intégration avec d’autres applications (par exemple, «Comment MS Office fonctionne-t-il avec Internet Explorer?»).
Ethel Evans

1
@Ethel Evans: Bon point. Le test restera flou entre intégration et acceptation, même si seule une partie du système est impliquée. Les tests sont effectués à un niveau suffisamment élevé pour que l'acceptation et l'intégration se sentent similaires.
S.Lott

3
Les tests d'intégration ne testent certainement pas (et ne devraient probablement pas) tester «le système dans son ensemble». Partout où deux composants ou plus sont testés ensemble, en particulier lors de tests sur des composants externes (base de données, réseau, etc.), vous effectuez des tests d'intégration. En raison des coûts élevés des tests sur "tout le système", vous voulez éviter cela autant que possible. Essayez
Schneider du

1
@ Schneider le dit bien, les tests d'intégration ne devraient pas tester "le système dans son ensemble". Ces tests seraient considérés comme des "tests de bout en bout" ou des "tests de système", en fonction de la portée que vous envisagez dans votre projet. Les tests de bout en bout peuvent couvrir un flux de données "dans son ensemble" qui s'exécute sur plusieurs systèmes, et le système ne teste qu'un "système dans son ensemble".
RoyB

Voici comment je les définit pour éviter la confusion entourant l'utilisation généralisée du test "Intégration". Tests unitaires -> teste la plus petite unité de travail, une méthode d'une classe, qui n'appelle pas de code en dehors de cette méthode (mocking dépendances si nécessaire) Tests d'intégration -> teste une portée plus grande des tests unitaires où ils peuvent et devrait tester les couches d'une application fonctionnant ensemble, mais PAS l'ensemble de l'application déployée quelque part.) Tests fonctionnels / test de réception -> tests testant une version déployée de l'application
Kevin M

16

Personnellement, j’aime penser à un test d’intégration comme à un test de fonctionnalité lorsque chaque composant du système est réel , sans objets fictifs.

Un vrai référentiel, une vraie base de données, une vraie interface utilisateur. Vous testez des fonctionnalités spécifiques lorsque le système est entièrement assemblé et qu'il est supposé l'être une fois déployé.


4
Je suis d'accord sauf qu'il n'est pas nécessaire que le système soit "complètement assemblé". Vous pouvez (et devriez) faire des tests d'intégration avec des sous-ensembles du système complet, car cela est généralement moins cher et plus simple.
Schneider

L'intégration entre 2 unités / composants peut également être "testée en intégration", le reste étant encore fictif. Par conséquent, de nombreux frameworks de test d'intégration permettent de se moquer :)
RoyB

1
J'ai des tests dans une application Spring Boot qui teste le frontal (contrat API) dans un conteneur Spring, mais simule le calque référentiel / données. Donc, il utilise des référentiels / données fictifs, mais fusionne la couche contrôleur et effectue le marshalling jackson, etc. Test d'intégration.
Kevin M

8

Dans mon (je l'avoue) peu d'expérience, j'ai compris que le mot intégration peut réellement créer des malentendus: en réalité, il est difficile de trouver quelque chose de complètement isolé dans un système, certains éléments nécessiteront certainement une certaine intégration.

Ainsi, je me suis habitué à faire les distinctions suivantes:

  • J'utilise des tests unitaires pour identifier, documenter et mettre en évidence tous les comportements que la classe que je teste est responsable d'accomplir.
  • Je fais des tests d'intégration chaque fois que j'ai dans mon système un composant (éventuellement plus d'un) en conversation avec un autre système " externe ". (continue ci-dessous ...)
  • J'implémente un test d'acceptation pour définir, documenter et souligner un certain flux de travail attendu par le système.

Dans la définition du test d'intégration, par externe, j'entendais les systèmes situés en dehors de ma plage de développement : je ne peux pas changer immédiatement leur comportement, pour quelque raison que ce soit. Il peut s'agir d'une bibliothèque, d'un composant du système qui ne peut pas être modifié (c'est-à-dire partagé avec d'autres projets de l'entreprise), d'un dbms, etc. Pour ces tests, je dois configurer quelque chose de très similaire à l'environnement réel du système. fonctionnera dans: un système externe doit être initialisé et réglé à un certain état; des données réalistes doivent être enregistrées dans la base de données; etc.

Au lieu de cela, lorsque je fais des tests d'acceptation, je simule des choses: je travaille sur quelque chose de différent, je travaille sur les spécifications du système, pas sur sa capacité à collaborer avec des entités externes.

C'est vraiment une vision plus étroite par rapport à ce que KeesDijk a décrit plus tôt, mais je suppose que les projets sur lesquels j'ai travaillé jusqu'à présent étaient suffisamment petits pour me permettre ce niveau de simplification.


6

Un test d'intégration vérifie que les composants d'un système complexe (logiciels, avions, centrales, etc.) fonctionnent ensemble comme prévu.

Imaginons qu'il s'agisse d'un avion (avec un logiciel, c'est plus abstrait et difficile à faire la différence). Les tests d'intégration comprennent, vérifiant:

  • interaction correcte entre certains composants. Exemple: en appuyant sur le bouton de démarrage, le moteur démarre et l'hélice atteint la vitesse de rotation attendue (l'avion reste toujours au sol)
  • interaction correcte avec les composants externes. Exemple: vérifier que la radio intégrée peut communiquer avec une radio fixe (avion encore au sol)
  • interaction correcte entre tous les composants impliqués, de sorte que le système dans son ensemble fonctionne comme prévu. Exemple: une équipe de pilotes d'essais et d'ingénieurs démarre l'avion et vole avec lui (ils portent tous des parachutes ...).

Le test d'intégration répond à un problème technique , à savoir que le système fonctionne malgré sa subdivision en composants. Dans le logiciel, les composants peuvent être des cas d’utilisation, des modules, des fonctions, des interfaces, des bibliothèques, etc.

Le test d'acceptation vérifie que le produit est adapté à l'usage auquel il est destiné. Ils sont en principe effectués par le client. En prenant l'analogie de l'aéronef, ils vérifient notamment que:

  • Les scénarios d’entreprise envisagés donnent les résultats escomptés dans une situation presque réelle. Exemple: répétez un embarquement avec des passagers d’essai pour vérifier que le personnel peut contrôler l’embarquement comme prévu avec les procédures opérationnelles. Certains scénarios peuvent être si simples qu’ils ressemblent à des tests unitaires, mais ils sont réalisés par l’utilisateur (par exemple, essayez les prises électriques avec les équipements de l’entreprise).
  • le système fonctionne dans une situation commerciale presque réelle. Exemple: effectuez un vol d’essai vide entre deux destinations réelles, avec des pilotes nouvellement formés de la compagnie aérienne pour vérifier que la consommation de carburant est conforme aux promesses.

Le test d'acceptation aborde davantage un problème de responsabilité . Dans une relation client / fournisseur, il peut s'agir d'une responsabilité contractuelle (respect de toutes les exigences). Mais dans tous les cas, il incombe également à l’organisme utilisateur de s’assurer que ses fonctions peuvent être exécutées avec le système et d’éviter avec prudence tout problème imprévu (par exemple, cette société de chemins de fer qui a découvert lors des essais de réception qu’elle avait dû raccourcir certaines les nouveaux wagons étaient 5 cm trop grand - pas de blague!).

Conclusions: Les tests d'intégration et d'acceptation se chevauchent. Ils ont tous deux l'intention de montrer que le système dans son ensemble fonctionne. Cependant, le "tout" peut être plus grand pour le client (car le système peut lui-même faire partie d'un système organisationnel plus grand) et plus technique pour l'intégrateur de système:

entrez la description de l'image ici


1

Les tests d'intégration ne sont rien d'autre que la vérification de la connexion et de l'exactitude du flux de données entre deux modules ou plus.

Par exemple: lorsque nous composons un courrier (un module) et l'envoyons à un ID utilisateur valide (deuxième module), le test d'intégration consiste à vérifier si le courrier envoyé est présent dans les éléments envoyés.


3
Bienvenue aux programmeurs. Qu'est-ce que votre réponse ajoute qui n'a pas déjà été fourni par les réponses existantes? Programmers.SE n'est pas comme les forums traditionnels. Il met l'accent sur des questions / réponses de haute qualité au lieu de beaucoup de discussions. Veuillez consulter la page de la tournée pour plus d'informations sur le fonctionnement du site.

0

Une définition pratique d'un test d'intégration est la suivante: Tout test nécessitant une interaction avec quelque chose hors processus.

Par exemple:

  • Le système de fichiers
  • Le réseau
  • Une base de données
  • Une API externe

Il existe un type de contrat entre votre processus et le monde externe, et le vérifier au minimum devrait être l'objectif d'un test d'intégration. c'est-à-dire qu'il ne devrait pas simplement vérifier le contrat. Si c'est le cas, vous vous dirigez vers l'espace système / de bout en bout.

Les tests unitaires sont capables de tester toute la logique au sein de votre processus, et ils peuvent le faire facilement, précisément en raison de l'absence de dépendances sur le "monde extérieur" lent / fragile / complexe.

Bien qu'il existe des tests d'intégration que cette définition ne couvre pas (d'où la raison pour laquelle je l'ai appelée une définition pratique ), je pense qu'ils sont beaucoup moins communs / utiles.

NB: à proprement parler, oui, cette définition couvrirait également les tests de système / de bout en bout. Dans ma philosophie, il s’agit d’une forme de test d’intégration «extrême», ce qui explique pourquoi leurs noms soulignent un autre aspect. Dans l’autre sens, un test unitaire peut être considéré comme un test d’intégration à zéro composant, c’est-à-dire que tous les tests peuvent être considérés comme se situant quelque part sur le spectre d’intégration, intégrant entre les composants 0-n :-)


Lorsque vous avez deux unités, vous testez chacune avec un test unitaire. Lorsque ces deux unités s'intègrent, vous testez l'intégration à l'aide d'un test d'intégration. Ils ne doivent pas nécessairement être "hors processus", et ce type de test est extrêmement courant.
Bryan Oakley

Vous avez tout à fait raison: il n'est pas nécessaire que le processus soit un processus d'intégration pour être un test d'intégration. C'est pourquoi j'ai essayé de préciser que ma réponse était davantage une "règle de base" (mais peut-être un échec). Je ne suis pas d'accord pour dire que les tests d'intégration entre unités sont "extrêmement communs". Les tests d'intégration hors processus sont beaucoup plus fréquents dans mon expérience et sont souvent très précieux. C'est pourquoi ma réponse met l'accent sur cet aspect des tests d'intégration.
Schneider
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.