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


Quelle est la différence entre les tests unitaires, fonctionnels, d'acceptation et d'intégration (et tous les autres types de tests que j'ai omis de mentionner)?


712
2018-02-04 23:59


origine


Réponses:


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, ceux-ci sont légèrement laineux et d'autres peuvent être en désaccord.

Tests unitaires

Teste la plus petite unité de fonctionnalité, typiquement une méthode / fonction (par exemple donné une classe avec un état particulier, l'appel de la méthode x sur la classe devrait provoquer y). Les tests unitaires doivent être focalisés sur une caractéristique particulière (par exemple, appeler la méthode pop lorsque la pile est vide doit lancer une InvalidOperationException). Tout ce qu'il touche doit être fait en mémoire; cela signifie que le code de test et le code testé ne doit pas:

  • Appelez des collaborateurs (non triviaux)
  • Accéder au réseau
  • Hit une base de données
  • Utilisez le système de fichiers
  • Faire tourner un fil
  • etc.

Tout type de dépendance lente / difficile à comprendre / initialiser / manipuler doit être stubbed / mocked / whatevered en utilisant les techniques appropriées afin que vous puissiez vous concentrer sur ce que fait l'unité de code, pas 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 composants 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 en isolation, les unités de code peuvent exploser une fois combinées, ce qui nous amène à ...

Tests d'intégration

Les tests d'intégration s'appuient sur des tests unitaires en combinant les unités de code et en testant que la combinaison résultante fonctionne correctement. Cela peut être soit l'intérieur d'un système, soit la combinaison de plusieurs systèmes pour faire quelque chose d'utile. En outre, une autre chose qui différencie les tests d'intégration des tests unitaires est l'environnement. 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érents changements d'environnement fonctionneront correctement.

Si vous avez construit un code de sérialisation et que l'unité a testé ses entrailles sans toucher au 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 files d'attente. Peut-être que vos permissions de fichiers sont incorrectes et que vous avez testé les entrailles en utilisant des flux mémoire. La seule façon de savoir avec certitude est de le tester «pour de vrai» en utilisant un environnement qui est le plus proche de la production.

Le principal avantage est qu'ils trouveront des bugs que les tests unitaires ne peuvent pas faire tels que des bugs de câblage (par exemple une instance de classe A reçoit une instance nulle de B) et des bogues d'environnement (ça marche bien sur mon machine à un processeur, mais mon la machine à 4 cœurs du 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.

De plus, 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 je le 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 avec la spécification. Les tests fonctionnels ne se préoccupent pas de résultats intermédiaires ou d'effets secondaires, mais simplement du résultat (ils ne se soucient pas qu'après avoir fait x, l'objet y ait l'état z). Ils sont écrits pour tester une partie de la spécification comme, "appeler 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 satisfait à 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 que le logiciel, dans son ensemble, est complet. L'inconvénient est que vous avez déplacé un autre niveau dans la pyramide des tests. Les tests d'acceptation touchent des montagnes de codes, il peut donc être difficile de retrouver une panne.

En outre, dans le développement de logiciels agiles, les tests d'acceptation des utilisateurs impliquent la création de tests pour refléter les histoires 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 histoires peuvent être considérées comme complètes. 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 la langue utilisée 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 est que certains tests regardent les choses du point de vue du programmeur, alors que d'autres utilisent un focus client / utilisateur final.


1254
2018-02-05 01:32



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

Je suis récemment tombé sur le système de nommage de Google pour leurs tests, et je l'aime plutôt - ils contournent les arguments en utilisant simplement Small, Medium et Large. Pour décider de la catégorie dans laquelle s'inscrit un test, ils examinent quelques facteurs: combien de temps faut-il pour exécuter, accède-t-il 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 Small, Medium et Large 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 ex. programmeur vs client / utilisateur final, est vraiment important.


75
2018-02-05 16:39



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

Le billet de Martin Fowler parle de stratégies pour tester le code (en particulier dans une architecture de micro-services) mais la plupart s'applique à n'importe quelle application.

Je vais citer un extrait de sa diapositive sommaire:

  • Tests unitaires - Exercez les plus petits éléments du logiciel testable dans 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 pour détecter les défauts d'interface.
  • Tests de composants - limiter la portée du logiciel exercé à une partie du système testé, en manipulant le système via   interfaces de code interne et en utilisant des doubles de test pour isoler le code   sous test d'autres composants.
  • Contrats contractuels - vérifie les interactions à la frontière d'un service externe en affirmant qu'il répond au contrat attendu par un consommateur   un service.
  • 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, à partir de   de bout en bout.

55
2018-02-21 22:08



Tests unitaires - Comme son nom l'indique, cette méthode teste au niveau de l'objet. Les composants logiciels individuels sont testés pour toute erreur. 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 il est destiné à.

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

Test d'acceptation - C'est le 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 réalisé par les membres de l'équipe de développement, connu sous le nom de test d'acceptation interne (test alpha), l'autre réalisé par le client ou l'utilisateur final (test bêta).

 Tests 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) Bottom-Up


25
2018-06-25 22:12



C'est très simple.

  1. Test unitaire: C'est le test réalisé par les développeurs qui ont des connaissances en codage. Ce test est effectué lors de la phase de codage et fait partie des tests en boîte blanche. Quand un logiciel vient pour le développement, il est développé dans le morceau de code ou les tranches de code connues comme une unité. Et les tests individuels de ces unités appelées tests unitaires effectués par les développeurs pour trouver des erreurs humaines comme manque de couverture de déclaration, etc.

  2. Test fonctionnel: Ce test est effectué lors de la phase de test (QA) et fait partie des tests en boîte noire. L'exécution réelle des cas de test précédemment écrits. Ce test est en fait effectué par des testeurs, ils trouvent le résultat réel de toute fonctionnalité sur le site et comparent ce résultat au résultat attendu. Si ils ont trouvé une disparité, c'est un bug.

  3. Test d'acceptation: savoir comme UAT. Et cela est fait par le testeur ainsi que les développeurs, l'équipe de gestion, l'auteur, les auteurs et tous ceux qui sont impliqués dans ce projet. Pour s'assurer que le projet est enfin prêt à être livré avec des bugs gratuits.

  4. Tests d'intégration: Les unités de code (expliquées au point 1) sont intégrées les unes aux autres pour compléter le projet. Ces unités de codes peuvent être écrites dans une technologie de codage différente ou bien elles peuvent être de version différente, ce test est fait par les développeurs pour s'assurer que toutes les unités du code sont compatibles avec les autres et qu'il n'y a aucun problème d'intégration.


15
2018-05-07 13:24



Quelques idées (relativement) récentes contre les moqueries excessives et les tests unitaires purs:


5
2018-03-10 02:18



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 seront réalisés par le développeur.

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

test fonctionnel vérifier les fonctionnalités individuelles d'une application est un test fonctionnel

tests d'acceptation ce test est effectué par l'utilisateur final ou le client, que l'application de construction soit conforme aux exigences du client, et que la spécification du client soit connue comme test de réception


4
2018-04-26 12:33



Je vais vous expliquer ceci avec un exemple pratique et non théorique:

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

Lorsqu'une interface graphique est développée et que l'application est assignée à un testeur, il vérifie les besoins de l'entreprise avec un client et exécute les différents scénarios. C'est ce qu'on appelle les tests fonctionnels. Ici, nous cartographions les exigences du client avec les flux d'applications.

Test d'intégration: disons que notre application a deux modules: RH et Finance. 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 sont également disponibles maintenant, donc dans cette phase, vous testerez les points de communication entre les deux et vérifierez qu'ils fonctionnent comme requis dans les exigences.

Le test de régression est une autre phase importante, effectuée après tout nouveau développement ou correction de bogue. Son but est de vérifier les fonctions de travail antérieures.


4
2018-02-12 10:53