Les grandes catégories à mon avis seraient:
Test de boîte noire . Vous ne voyez pas le code et testez simplement à l'aveugle dans une certaine mesure car ce qui se trouve dans l'application ou le système vous est caché. Ainsi, dans ce cas, les gens ne connaissent pas tous les cas d'erreur et doivent deviner avec diverses conditions aux limites qui peuvent ou non être évidentes pour trouver tous les cas.
Test de boîte blanche . Vous obtenez voir le code et pouvez vérifier quelles voies de code sont utilisées afin que la couverture de code puisse être utilisée comme métrique pour garantir que toute la logique est utilisée dans le système. L'idée ici est de savoir à quoi ressemble le code pour aider à guider les tests afin qu'il ne soit pas aussi mystérieux que les tests de boîte noire.
Les tests en boîte grise sont un hybride des deux précédents.
Les cas limites ont tendance à être quelque chose que l'on peut voir dans les tests en boîte blanche car il y a diverses conditions à voir dans le code que l'on écrit pour tester les tests, par exemple si vous aviez un programme qui demande un nombre et que quelqu'un entre X comment cela est géré devrait être vu quelque part dans le code.
Les classifications générales des tests seraient les suivantes:
Tests unitaires . Ce sont généralement les plus petits tests qui testent quelque chose d'assez spécifique, par exemple cette méthode gère-t-elle ce cas limite? Notez que l' injection de dépendances peut être utilisée ici pour les cas impliquant des objets fictifs afin de réduire les dépendances pour les tests.
Tests d'intégration . Il s'agit de tests dans lesquels deux composants sont connectés et des tests sont exécutés pour s'assurer que les composants fonctionnent bien ensemble. Notez que bien que les tests unitaires puissent fonctionner indépendamment, c'est là que le test de la façon dont les choses se réunissent est effectué car il peut y avoir une mauvaise communication entre les couches qui rend ces tests utiles pour attraper divers pièges. Le terme tests de bout en bout est utilisé pour les tests d'intégration où une chaîne complète de composants est testée "d'un point de terminaison de l'application à un autre" (quoi que cela signifie).
Tests de régression . Il s'agirait de tests effectués dans le passé qui sont effectués à nouveau pour s'assurer que ce qui a été corrigé reste fixe et que les bogues ne sont pas réintroduits dans le code.
Tests d'utilisabilité . Il s'agirait de tests effectués pour voir dans quelle mesure les utilisateurs finaux peuvent travailler avec le logiciel pour effectuer diverses tâches. Où quelque chose pourrait-il être automatisé pour accélérer quelque chose ou ajuster l'interface utilisateur pour que quelque chose soit plus facile à utiliser.
Tests d'acceptation des utilisateurs . Il s'agirait de tests effectués par les utilisateurs finaux afin qu'ils puissent voir de première main comment quelque chose fonctionne et convenir que le logiciel répond au besoin commercial qui l'a demandé en premier lieu.
Les tests fonctionnels sont toutes sortes de tests basés sur les spécifications fonctionnelles du logiciel testé. Ce sont toujours des tests de boîte noire.
Des tests de performance. Il s'agirait de tests effectués pour s'assurer qu'un système peut gérer une certaine quantité de charge sans devenir trop lent. Par exemple, tester une nouvelle batterie de serveurs Web pourrait gérer 100 utilisateurs frappant un site en même temps serait un exemple de test de performance. Celles-ci peuvent également être appelées "tests de charge" ou "tests de stress" car généralement l'idée ici est de pousser le système à sa limite ou de vérifier que le système peut gérer une projection d'un autre département. La raison de ces tests est qu'il existe souvent de nombreux paramètres de configuration à optimiser qui peuvent prendre plus d'un peu de travail pour découvrir les goulots d'étranglement et résoudre les problèmes avec cela. Le goulot d'étranglement ici pourrait être la mémoire, les E / S, le processeur ou la bande passante du réseau, ce qui fait que le système n'est pas aussi réactif que prévu.
Le développement piloté par les tests est une méthodologie qui ne fait pas référence à un type spécifique de test, mais plutôt que les tests sont écrits avant le code afin que les tests soient ce qui motive le développement plutôt que le comportement , le domaine ou la fonctionnalité étant d'autres exemples en termes de processus.
L'intégration continue consiste à exécuter régulièrement des tests tels que les tests unitaires, d'intégration et de régression, de sorte que si un changement échoue à un test, il soit détecté le plus tôt possible.