Quelle est la différence entre les tests unitaires, fonctionnels, d'acceptation et d'intégration?

Question

Quelle est la différence entre les tests unitaires, fonctionnels, d'acceptation et d'intégration (et tous les autres types de tests que je n'ai pas mentionnés)?

Mark Simpson · Accepted Answer

Selon l'endroit où vous regardez, vous obtiendrez des réponses légèrement différentes. J'ai beaucoup lu sur le sujet, et voici ma distillation; encore une fois, ils sont légèrement laineux et d’autres peuvent ne pas être d’accord.

Tests unitaires

Teste la plus petite unité de fonctionnalité, généralement une méthode/fonction (par exemple, pour une classe ayant un état particulier, l'appel de la méthode x sur la classe devrait provoquer l'apparition de y). Les tests unitaires doivent être axés sur une fonctionnalité particulière (par exemple, l’appel de la méthode pop lorsque la pile est vide doit renvoyer un InvalidOperationException). Tout ce qu'il touche doit être fait en mémoire; cela signifie que le code de test et le code sous test ne devrait pas:

Faites appel à des collaborateurs (non triviaux)
Accéder au réseau
Frapper une base de données
Utiliser le système de fichiers
Faites tourner un fil
etc.

Tout type de dépendance qui est lent/difficile à comprendre/initialiser/manipuler doit être écrasé/moqué/peu importe en utilisant les techniques appropriées afin que vous puissiez vous concentrer sur ce que fait l'unité de code et non sur ce que font ses dépendances.

En bref, les tests unitaires sont aussi simples que possible, faciles à déboguer, fiables (en raison de facteurs externes réduits), rapides à exécuter et aident à prouver que les plus petits blocs constitutifs de votre programme fonctionnent comme prévu avant d'être assemblés. La mise en garde est que, bien que vous puissiez prouver qu'ils fonctionnent parfaitement de manière isolée, les unités de code peuvent exploser lorsqu'elles sont combinées, ce qui nous amène à ...

Tests d'intégration

Les tests d'intégration reposent sur des tests unitaires en combinant les unités de code et en vérifiant que la combinaison obtenue fonctionne correctement. Cela peut être soit les entrailles d'un système, soit la combinaison de plusieurs systèmes pour faire quelque chose d'utile. En outre, l'environnement est une autre chose qui différencie les tests d'intégration des tests unitaires. Les tests d'intégration peuvent et vont utiliser des threads, accéder à la base de données ou faire tout ce qui est nécessaire pour s'assurer que tout le code et les différentes modifications de l'environnement fonctionneront correctement.

Si vous avez construit un code de sérialisation et que l'unité a testé ses inerties sans toucher le disque, comment savez-vous que cela fonctionnera lorsque vous chargez et enregistrez sur le disque? Peut-être avez-vous oublié de vider et d'éliminer les flux de fichiers. Peut-être que vos autorisations sur les fichiers sont incorrectes et que vous avez testé les entrailles en utilisant des flux de mémoire. La seule façon de le savoir est de le tester "réellement" en utilisant un environnement proche de la production.

L’avantage principal est qu’ils trouveront des bogues que les tests unitaires ne peuvent pas réaliser, tels que des bogues de câblage (par exemple, une instance de classe A reçoit de manière inattendue une instance nulle de B) et des bogues d’environnement La machine à 4 cœurs de votre collègue ne peut pas passer les tests). Le principal inconvénient est que les tests d'intégration touchent plus de code, sont moins fiables, les échecs sont plus difficiles à diagnostiquer et les tests sont plus difficiles à maintenir.

En outre, les tests d'intégration ne prouvent pas nécessairement qu'une fonctionnalité complète fonctionne. L'utilisateur peut ne pas se soucier des détails internes de mes programmes, mais c'est ce que je fais!

Tests fonctionnels

Les tests fonctionnels vérifient l'exactitude d'une caractéristique particulière en comparant les résultats d'une entrée donnée à la spécification. Les tests fonctionnels ne concernent pas les résultats intermédiaires ni les effets secondaires, mais seulement le résultat (ils ne se soucient pas qu'après avoir fait x, l'objet y a l'état z). Ils sont écrits pour tester une partie de la spécification telle que "l'appel de la fonction Square (x) avec l'argument de 2 renvoie 4".

Tests d'acceptation

Les tests d'acceptation semblent être divisés en deux types:

Les tests d'acceptation standard impliquent d'effectuer des tests sur le système complet (par exemple, en utilisant votre page Web via un navigateur Web) pour voir si la fonctionnalité de l'application est conforme à la spécification. Par exemple. "cliquer sur une icône de zoom devrait agrandir la vue du document de 25%." Il n'y a pas de véritable continuum de résultats, juste un résultat positif ou négatif.

L’avantage est que les tests sont décrits en anglais et qu’ils garantissent que le logiciel, dans son ensemble, est complet. L'inconvénient est que vous avez gravi un autre niveau dans la pyramide de test. Les tests d'acceptation touchent des montagnes de code. Il peut donc être difficile de détecter une défaillance.

De plus, dans le développement logiciel agile, les tests d'acceptation utilisateur impliquent la création de tests afin de refléter les user stories créées par/pour le client du logiciel pendant le développement. Si les tests réussissent, cela signifie que le logiciel doit répondre aux exigences du client et que les articles peuvent être considérés comme complets. Une suite de tests d'acceptation est essentiellement une spécification exécutable écrite dans un langage spécifique à un domaine qui décrit les tests dans le langage utilisé par les utilisateurs du système.

Conclusion

Ils sont tous complémentaires. Parfois, il est avantageux de se concentrer sur un type ou de les éviter complètement. La principale différence pour moi réside dans le fait que certains tests considèrent les choses du point de vue du programmeur, alors que d'autres utilisent un focus client/utilisateur final.

testerab · Answer

L'important est que vous sachiez ce que ces termes signifient pour vos collègues. Différents groupes auront par exemple des définitions légèrement différentes de ce qu’ils veulent dire quand ils disent tests "complets de bout en bout".

Je suis récemment tombé sur le système de nommage de Google pour leurs tests, et je l'aime bien. Ils contournent les arguments en utilisant simplement Small, Medium et Large. Pour déterminer dans quelle catégorie un test appartient, ils examinent quelques facteurs: combien de temps faut-il exécuter, at-il accès au réseau, à la base de données, au système de fichiers, aux systèmes externes, etc.

http://googletesting.blogspot.com/2010/12/test-sizes.html

J'imagine que la différence entre Petit, Moyen et Grand pour votre lieu de travail actuel peut varier de celle de Google.

Cependant, il ne s'agit pas seulement de la portée, mais de l'objectif. Le point de Mark sur les différentes perspectives pour les tests, par exemple programmeur vs client/utilisateur final, est vraiment important.

Maxim · Answer

http://martinfowler.com/articles/microservice-testing/

Le billet de blog de Martin Fowler parle de stratégies de test de code (en particulier dans une architecture de micro-services), mais la plus grande partie s’applique à toutes les applications.

Je cite un extrait de son résumé:

Tests unitaires - utilisez les plus petits logiciels testables de l'application pour déterminer s'ils se comportent comme prévu.

Tests d'intégration - vérifiez les chemins de communication et les interactions entre les composants afin de détecter les défauts d'interface.

Tests des composants - limitez la portée du logiciel utilisé à une partie du système testé, manipulez le système via des interfaces de code internes et utilisez des doubles de tests pour isoler le code testé des autres composants.

Tests de contrat - vérifiez les interactions aux limites d'un service externe, en affirmant qu'il respecte le contrat attendu par un service consommateur.

Tests de bout en bout - vérifiez qu'un système répond aux exigences externes et atteint ses objectifs, en testant l'ensemble du système, de bout en bout.

Shah · Answer

Tests unitaires - Comme son nom l'indique, cette méthode teste au niveau de l'objet. Les composants logiciels individuels sont testés pour toutes les erreurs. La connaissance du programme est nécessaire pour ce test et les codes de test sont créés pour vérifier si le logiciel se comporte comme prévu.

Test fonctionel - est réalisée sans aucune connaissance du fonctionnement interne du système. Le testeur essaiera d’utiliser le système en se conformant simplement aux exigences, en fournissant différentes entrées et en testant les sorties générées. Ce test est également appelé test en boîte fermée ou en boîte noire.

Test d'acceptation - Il s’agit du dernier test effectué avant la remise du logiciel au client. Il est effectué pour s'assurer que le logiciel développé répond à toutes les exigences du client. Il existe deux types de tests d'acceptation: l'un effectué par les membres de l'équipe de développement, appelé test d'acceptation interne (test Alpha) et l'autre, effectué par le client ou l'utilisateur final (test bêta).

Test d'intégration - Les modules individuels déjà soumis à des tests unitaires sont intégrés les uns aux autres. Généralement les deux approches sont suivies:

1) de haut en bas
2) De bas en haut

Rakesh Kumar · Answer

C'est très simple.

Tests unitaires: il s'agit des tests réellement effectués par les développeurs possédant des connaissances en matière de codage. Ce test est effectué lors de la phase de codage et fait partie des tests de la boîte blanche. Lorsqu'un logiciel doit être développé, il est développé sous forme de code ou de tranches de code appelé unité. Et les tests individuels de ces unités, appelés tests unitaires effectués par les développeurs, ont pour but de détecter des erreurs humaines telles que l'absence de couverture de relevé, etc.
Test fonctionnel: Ce test est effectué à la phase de test (QA) et fait partie du test de la boîte noire. L'exécution réelle des cas de test précédemment écrits. Ces tests sont en réalité effectués par des testeurs. Ils trouvent le résultat réel de toute fonctionnalité du site et le comparent au résultat attendu. S'ils trouvent une disparité, c'est un bug.
Test d'acceptation: connu sous le nom d'UAT. Et cela a été fait par le testeur ainsi que par les développeurs, l’équipe de gestion, l’auteur, les rédacteurs et tous ceux qui participent à ce projet. Pour que le projet soit enfin prêt à être livré sans bugs.
Test d'intégration: Les unités de code (expliquées au point 1) sont intégrées les unes aux autres pour mener à bien le projet. Ces unités de codes peuvent être écrites dans différentes technologies de codage ou peuvent avoir des versions différentes. Les développeurs effectuent ce test pour s'assurer que toutes les unités du code sont compatibles les unes avec les autres et qu'il n'y a aucun problème d'intégration.

cdunn2001 · Answer

Quelques idées (relativement) récentes contre la moquerie excessive et les tests unitaires purs:

malini · Answer

test unitaire: le test d'un module individuel ou d'un composant indépendant dans une application est connu pour être un test unitaire; les tests unitaires sont effectués par le développeur.

test d'intégration: combinaison de tous les modules et test de l'application pour vérifier la communication et le flux de données entre les modules, fonctionne correctement ou non, test réalisé également par les développeurs.

test fonctionnel vérifier la fonctionnalité individuelle d'une application signifie être un test fonctionnel

test d'acceptation cet essai est effectué par l'utilisateur final ou le client, que l'application de construction soit conforme aux exigences du client ou à la spécification du client, il s'agit d'un test d'acceptation.

fahad shaikh · Answer

Je vais vous expliquer cela avec un exemple pratique et aucune théorie:

Un développeur écrit le code. Aucune interface graphique n'est encore implémentée. Les tests effectués à ce niveau permettent de vérifier que les fonctions fonctionnent correctement et que les types de données sont corrects. Cette phase de test s'appelle le test unitaire.

Lorsqu'une interface graphique est développée et que l'application est attribuée à un testeur, celui-ci vérifie les exigences de l'entreprise avec un client et exécute les différents scénarios. Ceci s'appelle le test fonctionnel. Nous mappons ici les exigences du client avec les flux d’application.

Tests d'intégration: supposons que notre application comporte deux modules: les ressources humaines et les finances. Le module RH a été livré et testé précédemment. Maintenant, Finance est développé et est disponible pour tester. Les fonctionnalités interdépendantes étant également disponibles à présent, vous allez donc tester les points de communication entre les deux et vérifier leur fonctionnement conformément aux exigences.

Les tests de régression constituent une autre phase importante, qui est effectuée après tout nouveau développement ou correction de bogue. Son but est de vérifier les fonctions précédemment opérationnelles.