Discussion :

[amine04]

Test d'acceptation, test fonctionnel, test unitaire, test d'intégration, test de validation, test en boite blanche, test en boite noire, test de régression, test de performance.

Je me suis vraiment perdu entre ces termes
quelqu'un peut me donner des petites déf et surtout la relation entre ces différents types de test??

Merci de votre aide.

[el_slapper]

Test d'acceptation, test fonctionnel, test unitaire, test d'intégration, test de validation, test en boite blanche, test en boite noire, test de régression, test de performance.
(.../...).

Tout ce que tu veux savoir sur les tests est dans ce blog indispensable.

Bon, évidemment, il faut quelques jours pour tout lire, alors je vais résumer à la hache :

_Test d'acceptation : Test réalisé par une structure extérieure au projet. Avec un résultat binaire : "accepté/pas accepté".
_Test fonctionnel : Test qui cherche à savoir si l'application se comporte comme prévu. On ne descend pas au niveau technique. Genre, on va taper un débit de 10€ dans l'appli, et on vérifie qu'on retrouve ses petits partout.
_Test unitaire : test d'un bloc unitaire de code. Généralement avec une forte dose de technique. Généralement réalisé par le développeur(mais pas toujours). Par exemple, on va invoquer à la main le module qui fait les débits avec 10€ en paramètre, et on vérifie qu'il fait bien ce qu'il faut en base.
_Test d'intégration : vient après le test unitaire. On assemble(intègre) les blocs de code, et on vérifie que tout marche bien ensemble(pro-tip : c'est souvent là que ça se passe le plus mal, prévoir du temps et des corrections en pagaille). Suivant les maisons, c'est fait par les devs, ou les testeurs, c'est très technique, ou très fonctionnel, très boite blanche, ou très boite noire.
_Test de validation : celui-là est vraiment spécifique à chaque boite. ça veut tout dire, et donc rien dire. Demander sur place la définition.
_Test en boite blanche : le code est grand ouvert, et on va taper dedans pour regarder si il marche comme on voulait(les notions de tests en boite blanche, grise, ou noire, sont transversales aux autres. On peut faire du test unitaire en boite noire, et du test d'intégration en boite blanche, si on est retors).
_Test en boite noire : on est à la place de l'utilisateur lambda, et on a rien de technique pour tester, on se contente d'appuyer sur les boutons mis à disposition.
_Test en boite grise : on a accès à quelques trucs techniques, mais pas trop. Du genre, on peut lancer des scripts à la main, mais pas les modifier.
_Test de non-régression : à chaque nouvelle version, il y a risque de régression, c'est-à-dire de fonctionnalité qui marchait et ne marche plus. Les tests de non-régression, généralement les premiers qu'on automatise, ont pour objet de vérifier que ce qui marchait avant marche toujours.
_Tests de performance : on charge la mule, et on vérifie qu'elle ne crève pas la gueule ouverte. Par exemple, on peut simuler des milliers de connexions en même temps à la base de donnée, à l'appli, ou donner à manger à un batch quotidien une volumétrie de l'année pour voir. Et surtout, pour mesurer. C'est le plus difficile, et c'est aussi le mieux payé. C'est une spécialité en soi.

[amine04]

Tout ce que tu veux savoir sur les tests est dans ce blog indispensable.

Bon, évidemment, il faut quelques jours pour tout lire, alors je vais résumer à la hache :

_Test d'acceptation : Test réalisé par une structure extérieure au projet. Avec un résultat binaire : "accepté/pas accepté".
_Test fonctionnel : Test qui cherche à savoir si l'application se comporte comme prévu. On ne descend pas au niveau technique. Genre, on va taper un débit de 10€ dans l'appli, et on vérifie qu'on retrouve ses petits partout.
_Test unitaire : test d'un bloc unitaire de code. Généralement avec une forte dose de technique. Généralement réalisé par le développeur(mais pas toujours). Par exemple, on va invoquer à la main le module qui fait les débits avec 10€ en paramètre, et on vérifie qu'il fait bien ce qu'il faut en base.
_Test d'intégration : vient après le test unitaire. On assemble(intègre) les blocs de code, et on vérifie que tout marche bien ensemble(pro-tip : c'est souvent là que ça se passe le plus mal, prévoir du temps et des corrections en pagaille). Suivant les maisons, c'est fait par les devs, ou les testeurs, c'est très technique, ou très fonctionnel, très boite blanche, ou très boite noire.
_Test de validation : celui-là est vraiment spécifique à chaque boite. ça veut tout dire, et donc rien dire. Demander sur place la définition.
_Test en boite blanche : le code est grand ouvert, et on va taper dedans pour regarder si il marche comme on voulait(les notions de tests en boite blanche, grise, ou noire, sont transversales aux autres. On peut faire du test unitaire en boite noire, et du test d'intégration en boite blanche, si on est retors).
_Test en boite noire : on est à la place de l'utilisateur lambda, et on a rien de technique pour tester, on se contente d'appuyer sur les boutons mis à disposition.
_Test en boite grise : on a accès à quelques trucs techniques, mais pas trop. Du genre, on peut lancer des scripts à la main, mais pas les modifier.
_Test de non-régression : à chaque nouvelle version, il y a risque de régression, c'est-à-dire de fonctionnalité qui marchait et ne marche plus. Les tests de non-régression, généralement les premiers qu'on automatise, ont pour objet de vérifier que ce qui marchait avant marche toujours.
_Tests de performance : on charge la mule, et on vérifie qu'elle ne crève pas la gueule ouverte. Par exemple, on peut simuler des milliers de connexions en même temps à la base de donnée, à l'appli, ou donner à manger à un batch quotidien une volumétrie de l'année pour voir. Et surtout, pour mesurer. C'est le plus difficile, et c'est aussi le mieux payé. C'est une spécialité en soi.

Merci beaucoup de ton aide, c'est très expressif
reste à savoir qu'elle est la relation entre ces types, par ce que j'ai lu sur un article que les tests d'acception désignent une étape du projet et qu'ils incluent les tests unitaires, d'intégration et de validation. c'est donc une relation d'inclusion.
Autre chose, pour un ingénieur recette fonctionnels, il est censé savoir quel type de test?

Merciii

[el_slapper]

Merci beaucoup de ton aide, c'est très expressif
reste à savoir qu'elle est la relation entre ces types, par ce que j'ai lu sur un article que les tests d'acception désignent une étape du projet et qu'ils incluent les tests unitaires, d'intégration et de validation. c'est donc une relation d'inclusion.
Autre chose, pour un ingénieur recette fonctionnels, il est censé savoir quel type de test?

Merciii

ton article, il est douteux. Enfin, il peut arriver que l'acceptance comporte des tests unitaires, mais je ne l'ai jamais vu. Généralement, c'est juste du test fonctionnel en boite noire + du test de performances. Mais oui, la relation entre tous ces types varie de boite en boite, donc je ne peut pas vraiment te répondre.