Techniques ou catégories de tests de logiciels [fermé]


16

Quels types de tests logiciels connaissez-vous? J'ai entendu parler du développement piloté par les tests, des tests unitaires, etc., mais je ne comprends pas leur importance et leur différence. Par exemple, pourquoi utilisons-nous des tests de régression ou des tests d'acceptation. Quel avantage offrent-ils?


8
Quelle partie de cela était confuse ou incomplète? en.wikipedia.org/wiki/Software_testing
S.Lott

2
Vous pouvez ignorer les tests de régression si vous ne vous souciez pas si vous cassez les fonctionnalités existantes et vous pouvez ignorer le test d'acceptation si vous ne vous souciez pas de savoir si les personnes qui utilisent réellement le logiciel ou qui le paient pensent qu'il fait ce qu'elles s'attendent à ce qu'il fasse. . Les programmeurs professionnels se soucient de ces deux choses.
HLGEM

Je vote pour rouvrir cette question car c'est la seule que j'ai pu trouver donnant un bon aperçu des différents types de catégories de tests. Peut-être que quelqu'un a une bonne idée de la façon de reformuler la question pour l'adapter mieux à ce site?
Doc Brown

Réponses:


38

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.


5
+1 ... et malheureusement, il y a encore des tests manuels même après tout cela.
Steven Evers

2
et Stres Test - toutes les sessions possibles testant le même masque en même temps et en continu à travers un scénario de test, quelque part inclus dans le cadre de l'UAT, btw +1
mKorbel

1
Vous ne manquez pas les tests de couverture / couverture de succursale? En outre, fonctionnant sous une sorte de système d'observation de la mémoire, comme malloc "Electric Fence" ou Valgrind?
Bruce Ediger

1
@Bruce Ediger: la couverture est une statistique pour les tests en boîte blanche, pas une méthode de test elle-même et les outils que vous décrivez sont pour les tests de performance.
Steven Evers

Je dois différer sur les "outils ... sont pour les tests de performance". Dans certains langages (C ou C ++), l'exécution de nombreux tests unitaires dans valgrind trouvera des bogues qu'aucun des autres types de tests répertoriés ci-dessus ne trouvera. Valgrind est certainement un outil de débogage, mais l'exécution de tests dans un programme valgrinded est très nécessaire.
Bruce Ediger

4

Des tests de régression sont effectués pour s'assurer que les nouvelles modifications apportées à un système ne cassent aucune fonctionnalité existante qui n'était pas censée avoir été affectée par les modifications.

Le test d'acceptation est généralement effectué par le client / client / utilisateurs professionnels, il est souvent plus élevé que les autres formes de test et il est effectué de sorte que les personnes qui ont demandé les modifications en soient satisfaites et vous permettront de promouvoir les modifications dans votre Système de production.


1
Et ce qui est le plus important pour qu'ils conviennent qu'ils ont obtenu ce qu'ils voulaient et qu'ils peuvent vous payer maintenant.
Mchl
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.