Que sont les tests unitaires, les tests d'intégration, les tests de fumée et les tests de régression?

Que sont les tests unitaires, les tests d'intégration, les tests de fumée et les tests de régression? Quelles sont les différences entre eux et quels outils puis-je utiliser pour chacun d'eux?

Par exemple, j'utilise JUnit et NUnit pour les tests unitaires et les tests d'intégration . Existe-t-il des outils pour les deux derniers, des tests de fumée ou des tests de régression ?

• Test unitaire : Spécifiez et testez un point du contrat de méthode unique d'une classe. Cela devrait avoir une portée très étroite et bien définie. Les dépendances complexes et les interactions avec le monde extérieur sont tronquées ou moquées .

• Test d'intégration : testez le bon fonctionnement de plusieurs sous-systèmes. Il y a tout un spectre, du test d'intégration entre deux classes au test d'intégration avec l'environnement de production.

• Test de fumée (aka sanity check) : Un test d'intégration simple où nous vérifions simplement que lorsque le système sous test est invoqué, il revient normalement et ne saute pas.

  • Le test de fumée est à la fois une analogie avec l'électronique, où le premier test a lieu lors de la mise sous tension d'un circuit (s'il fume, c'est mauvais!) ...
  • ... et, apparemment , avec la plomberie , où un système de tuyaux est littéralement rempli de fumée, puis vérifié visuellement. Si quelque chose fume, le système fuit.

• Test de régression : test écrit lorsqu'un bogue a été corrigé. Il garantit que ce bogue spécifique ne se reproduira plus. Le nom complet est "test de non-régression". Il peut également s'agir d'un test effectué avant de modifier une application pour vous assurer que l'application fournit le même résultat.

À cela, j'ajouterai:

• Test d'acceptation : test qu'une fonctionnalité ou un cas d'utilisation est correctement implémenté. Il est similaire à un test d'intégration, mais en mettant l'accent sur le cas d'utilisation à fournir plutôt que sur les composants impliqués.

• Test système : teste un système comme une boîte noire. Les dépendances sur d'autres systèmes sont souvent moquées ou tronquées pendant le test (sinon ce serait plus un test d'intégration).

• Contrôle pré-vol : tests qui sont répétés dans un environnement de production, pour atténuer le syndrome «s'appuie sur ma machine». Souvent, cela est réalisé en faisant un test d'acceptation ou de fumée dans un environnement de production.

• Test unitaire : un test automatique pour tester le fonctionnement interne d'une classe. Il doit s'agir d'un test autonome qui n'est pas lié à d'autres ressources.
• Test d'intégration : un test automatique qui se fait sur un environnement, donc similaire aux tests unitaires mais avec des ressources externes (db, accès disque)
• Test de régression : après avoir implémenté de nouvelles fonctionnalités ou corrigé des bogues, vous testez à nouveau des scénarios qui fonctionnaient dans le passé. Ici, vous couvrez la possibilité dans laquelle vos nouvelles fonctionnalités cassent les fonctionnalités existantes.
• Test de fumée : premiers tests sur lesquels les testeurs peuvent conclure s'ils continueront le test.

Tout le monde aura des définitions légèrement différentes et il y a souvent des zones grises. Toutefois:

• Test unitaire: est-ce que ce petit morceau (aussi isolé que possible) fonctionne?
• Test d'intégration: ces deux (ou plus) composants fonctionnent-ils ensemble?
• Test de fumée: l'ensemble de ce système (aussi proche que possible d'un système de production) se relie-t-il assez bien? (c'est-à-dire sommes-nous raisonnablement convaincus que cela ne créera pas de trou noir?)
• Test de régression: avons-nous réintroduit par inadvertance des bogues que nous avions précédemment corrigés?

Une nouvelle catégorie de test dont je viens de prendre connaissance est le test des canaris . Un test canari est un test automatisé et non destructif qui est exécuté régulièrement dans un environnement réel , de sorte que s'il échoue, quelque chose de vraiment grave s'est produit.

Des exemples pourraient être:

• Les données qui ne devraient être disponibles qu'en développement / testy sont-elles apparues en direct ?
• Un processus d'arrière-plan n'a-t-il pas pu s'exécuter?
• Un utilisateur peut-il se connecter?

Répondez à l'un des meilleurs sites Web pour les techniques de test de logiciels:

Types de tests logiciels - liste complète cliquez ici

C'est une description assez longue, et je ne vais pas la coller ici: mais elle peut être utile pour quelqu'un qui veut connaître toutes les techniques de test.

Test unitaire: vérification du composant particulier (c.-à-d. Classe) créé ou modifié des fonctions comme prévu Ce test peut être manuel ou automatisé, mais il ne dépasse pas la limite du composant.

Test d'intégration: vérifier que l'interaction de composants particuliers fonctionne comme prévu. Les tests d'intégration peuvent être effectués au niveau de l'unité ou au niveau du système. Ces tests peuvent être manuels ou automatisés.

Test de régression: vérification que de nouveaux défauts ne sont pas introduits dans le code existant. Ces tests peuvent être manuels ou automatisés.

En fonction de votre SDLC ( cascade , RUP , agile , etc.), des tests particuliers peuvent être effectués en «phases» ou peuvent tous être effectués, plus ou moins, en même temps. Par exemple, les tests unitaires peuvent être limités aux développeurs qui remettent ensuite le code aux testeurs pour les tests d'intégration et de régression. Cependant, une autre approche pourrait avoir des développeurs effectuant des tests unitaires et un certain niveau de tests d'intégration et de régression (en utilisant une approche TDD avec une intégration continue et des tests unitaires et de régression automatisés).

L'ensemble d'outils dépendra largement de la base de code, mais il existe de nombreux outils open source pour les tests unitaires (JUnit). HP (Mercury) QTP ou Borland's Silk Test sont tous deux des outils pour les tests automatisés d'intégration et de régression.

Test unitaire : le test d'un module individuel ou d'un composant indépendant dans une application est connu pour être un test unitaire. Le test unitaire sera effectué 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. Ces tests ont également été effectués par des développeurs.

Test de fumée Dans un test de fumée, ils vérifient l'application d'une manière peu profonde et large. Lors des tests de détection de fumée, ils vérifient la fonctionnalité principale de l'application. S'il y a un problème de bloqueur dans l'application, il le signalera à l'équipe de développement, et l'équipe de développement le corrigera et rectifiera le défaut, puis le rendra à l'équipe de test. Maintenant, l'équipe de test vérifiera tous les modules pour vérifier que les modifications apportées dans un module auront un impact sur l'autre module ou non. Dans les tests de fumée, les cas de test sont scriptés.

Test de régression exécutant les mêmes cas de test à plusieurs reprises pour s'assurer que le module inchangé ne cause aucun défaut. Les tests de régression sont soumis aux tests fonctionnels

LES TESTS DE RÉGRESSION-

"Un test de régression réexécute les tests précédents sur le logiciel modifié pour s'assurer que les modifications apportées au logiciel actuel n'affectent pas la fonctionnalité du logiciel existant."

Je voulais juste ajouter et donner un peu plus de contexte sur la raison pour laquelle nous avons ces niveaux de test, ce qu'ils signifient vraiment avec des exemples

Mike Cohn dans son livre «Réussir avec Agile» a proposé la «Pyramide de test» comme un moyen d'aborder les tests automatisés dans les projets. Il existe différentes interprétations de ce modèle. Le modèle explique quel type de tests automatisés doivent être créés, à quelle vitesse ils peuvent donner un retour sur l'application testée et qui écrit ces tests. Il existe essentiellement 3 niveaux de tests automatisés nécessaires pour tout projet et ils sont les suivants.

Tests unitaires - Ils testent le plus petit composant de votre application logicielle. Cela pourrait littéralement être une fonction dans un code qui calcule une valeur basée sur certaines entrées. Cette fonction fait partie de plusieurs autres fonctions de la base de code matériel / logiciel qui compose l'application.

Par exemple - Prenons une application de calculatrice basée sur le Web. Les plus petits composants de cette application qui doivent être testés à l'unité pourraient être une fonction qui effectue l'addition, une autre qui effectue la soustraction et ainsi de suite. Toutes ces petites fonctions réunies constituent l'application calculatrice.

Historiquement, le développeur écrit ces tests car ils sont généralement écrits dans le même langage de programmation que l'application logicielle. Des cadres de tests unitaires tels que JUnit et NUnit (pour java), MSTest (pour C # et .NET) et Jasmine / Mocha (pour JavaScript) sont utilisés à cet effet.

Le plus grand avantage des tests unitaires est qu'ils s'exécutent très rapidement sous l'interface utilisateur et nous pouvons obtenir des commentaires rapides sur l'application. Cela devrait représenter plus de 50% de vos tests automatisés.

API / Tests d'intégration - Ils testent ensemble divers composants du système logiciel. Les composants pourraient inclure des bases de données de test, des API (Application Programming Interface), des outils et services tiers avec l'application.

Par exemple - Dans notre exemple de calculatrice ci-dessus, l'application Web peut utiliser une base de données pour stocker des valeurs, utiliser des API pour effectuer des validations côté serveur et elle peut utiliser un outil / service tiers pour publier des résultats sur le cloud pour les rendre disponibles sur différents plates-formes.

Historiquement, un développeur ou un QA technique rédigerait ces tests à l'aide de divers outils tels que Postman, SoapUI, JMeter et d'autres outils comme Testim.

Ceux-ci s'exécutent beaucoup plus rapidement que les tests d'interface utilisateur car ils s'exécutent toujours sous le capot, mais peuvent consommer un peu plus de temps que les tests unitaires car ils doivent vérifier la communication entre les différents composants indépendants du système et s'assurer qu'ils ont une intégration transparente. Cela devrait représenter plus de 30% des tests automatisés.

Tests d'interface utilisateur - Enfin, nous avons des tests qui valident l'interface utilisateur de l'application. Ces tests sont généralement écrits pour tester les flux de bout en bout dans l'application.

Par exemple - Dans l'application calculatrice, un flux de bout en bout pourrait être d'ouvrir le navigateur -> Entrer l'URL de l'application calculatrice -> Se connecter avec un nom d'utilisateur / mot de passe -> Ouvrir l'application calculatrice -> Effectuer certaines opérations sur la calculatrice -> vérification de ces résultats depuis l'interface utilisateur -> Déconnexion de l'application. Cela pourrait être un flux de bout en bout qui serait un bon candidat pour l'automatisation de l'interface utilisateur.

Historiquement, les AQ techniques ou les testeurs manuels écrivent des tests d'interface utilisateur. Ils utilisent des frameworks open source comme Selenium ou des plateformes de test d'interface utilisateur comme Testim pour créer, exécuter et maintenir les tests. Ces tests donnent plus de commentaires visuels car vous pouvez voir comment les tests sont en cours d'exécution, la différence entre les résultats attendus et réels à travers des captures d'écran, des journaux, des rapports de test.

La plus grande limitation des tests d'interface utilisateur est qu'ils sont relativement lents par rapport aux tests au niveau de l'unité et de l'API. Il ne devrait donc représenter que 10 à 20% de l'ensemble des tests automatisés.

Les deux types de tests suivants peuvent varier en fonction de votre projet, mais l'idée est-

Tests de fumée

Cela peut être une combinaison des 3 niveaux de test ci-dessus. L'idée est de l'exécuter à chaque archivage de code et de s'assurer que les fonctionnalités critiques du système fonctionnent toujours comme prévu; après la fusion des nouveaux changements de code. Ils doivent généralement fonctionner avec 5 à 10 minutes pour obtenir un retour d'informations plus rapide sur les échecs.

Tests de régression

Ils sont généralement exécutés au moins une fois par jour et couvrent diverses fonctionnalités du système. Ils s'assurent que l'application fonctionne toujours comme prévu. Ils sont plus détaillés que les tests de fumée et couvrent plus de scénarios de l'application, y compris les non critiques.

Les tests unitaires visent la plus petite partie possible de l'implémentation. En Java, cela signifie que vous testez une seule classe. Si la classe dépend d'autres classes, celles-ci sont truquées.

Lorsque votre test appelle plusieurs classes, il s'agit d'un test d'intégration .

Les suites de tests complètes peuvent prendre un certain temps à s'exécuter. Par conséquent, après un changement, de nombreuses équipes exécutent des tests rapides et complets pour détecter les ruptures importantes. Par exemple, vous avez divisé les URI en ressources essentielles. Ce sont les tests de fumée .

Les tests de régression s'exécutent sur chaque build et vous permettent de refactoriser efficacement en capturant ce que vous cassez. Tout type de test peut être un test de régression, mais je trouve que les tests unitaires sont les plus utiles pour trouver la source du défaut.

• Test d'intégration: le test d'intégration est l'intégration d'un autre élément
• Test de fumée: le test de fumée est également appelé test de version de build. Le test de fumée est le processus de test initial exercé pour vérifier si le logiciel testé est prêt / stable pour d'autres tests.
• Tests de régression: les tests de régression sont des tests répétés . Si un nouveau logiciel est effectué dans un autre module ou non.
• Test unitaire: Il s'agit d'un test en boîte blanche. Seuls les développeurs y participent

Test unitaire: il est toujours effectué par le développeur après son développement pour découvrir le problème de son côté test avant de préparer toute exigence pour l'assurance qualité.

Test d'intégration: cela signifie que le testeur doit vérifier la vérification module à sous-module lorsque certaines données / fonctions sont dirigées vers un module vers un autre module. Ou dans votre système si vous utilisez un outil tiers qui utilise vos données système pour les intégrer.

Test de fumée: testeur effectué pour vérifier le système pour des tests de haut niveau et essayer de découvrir le bogue show stopper avant que les modifications ou le code ne soient mis en ligne.

Test de régression: le testeur a effectué une régression pour vérifier la fonctionnalité existante en raison des changements mis en œuvre dans le système pour une nouvelle amélioration ou des changements dans le système.

Tests unitaires

Les tests unitaires sont généralement effectués par les développeurs, tandis que les testeurs évoluent en partie dans ce type de test où les tests sont effectués unité par unité. En Java, des cas de test JUnit peuvent également être possibles pour tester si le code écrit est parfaitement conçu ou non.

Test d'intégration:

Ce type de test est possible après le test unitaire lorsque tous / certains composants sont intégrés. Ce type de test garantira que lorsque les composants sont intégrés, affectent-ils les capacités de travail ou les fonctionnalités des uns et des autres?

Test de fumée

Ce type de test est effectué au dernier lorsque le système est intégré avec succès et prêt à fonctionner sur le serveur de production.

Ce type de test garantit que toutes les fonctionnalités importantes du début à la fin fonctionnent correctement et que le système est prêt à être déployé sur le serveur de production.

Les tests de régression

Ce type de test est important pour tester que les défauts involontaires / indésirables ne sont pas présents dans le système lorsque le développeur a résolu certains problèmes. Ces tests permettent également de s'assurer que tous les bogues ont été résolus avec succès et, pour cette raison, aucun autre problème ne s'est produit.

Les tests de détection de fumée et d'intégrité sont tous deux effectués après une version logicielle pour déterminer s'il faut commencer les tests. Sanity peut ou non être exécuté après un test de fumée. Ils peuvent être exécutés séparément ou en même temps - la santé mentale étant immédiatement après la fumée.

Parce que les tests d'intégrité sont plus approfondis et prennent plus de temps, dans la plupart des cas, cela vaut la peine d'être automatisé.

Le test de fumée ne prend généralement pas plus de 5 à 30 minutes pour être exécuté. Il est plus général: il vérifie un petit nombre de fonctionnalités de base de l'ensemble du système, afin de vérifier que la stabilité du logiciel est suffisamment bonne pour des tests supplémentaires et qu'il n'y a pas de problèmes, bloquant l'exécution des cas de test prévus.

Les tests de santé mentale sont plus détaillés que la fumée et peuvent prendre de 15 minutes à une journée entière, selon l'échelle de la nouvelle construction. Il s'agit d'un type de test d'acceptation plus spécialisé, effectué après une progression ou un nouveau test. Il vérifie les fonctionnalités de base de certaines nouvelles fonctionnalités et / ou corrections de bugs ainsi que certaines fonctionnalités étroitement liées à celles-ci, afin de vérifier qu'elles fonctionnent selon la logique opérationnelle requise, avant que les tests de régression puissent être exécutés à plus grande échelle.

Il y a déjà de bonnes réponses, mais je voudrais les affiner davantage:

Le test unitaire est la seule forme de test en boîte blanche ici. Les autres sont des tests en boîte noire. Le test de la boîte blanche signifie que vous connaissez l'entrée; vous connaissez le fonctionnement interne du mécanisme et pouvez l'inspecter et vous connaissez la sortie. Avec les tests de boîte noire, vous ne savez que ce qu'est l'entrée et ce que devrait être la sortie.

Il est donc clair que les tests unitaires sont les seuls tests en boîte blanche ici.

• Les tests unitaires testent des morceaux de code spécifiques. Habituellement, les méthodes.
• Les tests d'intégration testent si votre nouveau logiciel peut s'intégrer à tout le reste.
• Les tests de régression. Ces tests sont effectués pour s'assurer que vous n'avez rien cassé. Tout ce qui fonctionnait auparavant devrait toujours fonctionner.
• Le test de fumée est un test rapide pour vous assurer que tout va bien avant de vous lancer dans des tests plus rigoureux.

Les tests de fumée ont déjà été expliqués ici et sont simples. Les tests de régression font l'objet de tests d'intégration.

Les tests automatisés peuvent être divisés en deux seulement.

Tests unitaires et tests d'intégration (c'est tout ce qui compte)

J'appellerais l'expression «test long» (LT) pour tous les tests comme les tests d'intégration, les tests fonctionnels, les tests de régression, les tests d'interface utilisateur, etc. Et les tests unitaires comme «test court».

Un exemple LT pourrait être le chargement automatique d'une page Web, la connexion au compte et l'achat d'un livre. Si le test réussit, il est plus susceptible de s'exécuter sur le site en direct de la même manière (d'où la référence «meilleur sommeil»). Long = distance entre la page Web (début) et la base de données (fin).

Et c'est un excellent article sur les avantages des tests d'intégration (test long) par rapport aux tests unitaires .

Test de régression - est un type de test de logiciel où nous essayons de couvrir ou vérifier autour du bug fix . La fonctionnalité autour du correctif de bogue ne doit pas être changée ou altérée en raison du correctif fourni. Les problèmes détectés dans ce processus sont appelés problèmes de régression .

Test de fumée: est une sorte de test effectué pour décider d'accepter la version / le logiciel pour d'autres tests d'assurance qualité.