Les tests de régression constituent-ils la suite de tests complète ou un échantillon de tests?

Question

On m'a appris qu'un test de régression était un petit échantillon (assez pour prouver que rien n'avait été cassé avec l'introduction d'un changement ou de nouveaux modules) des tests globaux. Cependant, cet article de Ron Morrison et Grady Booch me fait penser différemment:

  

La stratégie souhaitée consisterait à intégrer chaque unité une à la fois, à effectuer un test de régression approfondi, à corriger les défauts éventuels, puis à passer à l'unité suivante.

Le même document dit aussi:

  

Dès qu'un petit nombre d'unités est ajouté, une version de test est générée et "test de détection de la fumée". dans lequel un petit nombre de tests est exécuté pour s'assurer que le produit intégré fonctionnera comme prévu. L’intention n’est ni de tester en profondeur les nouvelles unités ni de tester complètement la régression de l’ensemble du système.

En décrivant les tests de détection de fumée, les auteurs disent ceci:

  

Il est également important que le test de fumée vérifie rapidement l’ensemble du système, pas seulement le ou les nouveaux composants.

Je n'ai jamais vu " vaste " et " test de régression " utilisés ensemble, ni un test de régression décrit comme "un test de régression complet du système global". Les tests de régression sont supposés être aussi légers et rapides que possible. Et la définition du test de fumée est ce que j’ai appris qu’un test de régression était.

Ai-je mal compris ce qu'on m'a appris? Ai-je appris mal? Ou existe-t-il plusieurs interprétations du "test de régression"?

Answer 1

Les interprétations sont multiples. Si vous ne corrigez qu'un bogue affectant une petite partie de votre système, les tests de régression peuvent inclure uniquement une petite suite de tests permettant d'exercer la classe ou le package en question. Si vous corrigez un bogue ou ajoutez une fonctionnalité ayant une portée plus large, vos tests de régression doivent également avoir une portée plus large.

Le "s'il pouvait éventuellement se casser, testez-le" règle générale s'applique ici. Si une modification de Foo peut affecter Bar , exécutez les régressions pour les deux.

Les tests de régression vérifient simplement si une modification a entraîné l'échec d'un test précédemment réussi. Ils peuvent être exécutés à n’importe quel niveau (unité, intégration, système). Référence .

Answer 2

Les tests de régression ont toujours été considérés comme des tests visant à garantir que les fonctionnalités existantes ne sont pas interrompues par de nouvelles modifications. Cela n’imposera aucune contrainte quant à la taille de la suite de tests.

Answer 3

La régression est généralement utilisée pour faire référence à l’ensemble des tests. C'est la dernière chose que QA fasse avant une publication. Il est utilisé pour montrer que tout ce qui fonctionnait auparavant fonctionne toujours, dans la mesure du possible. D'après mon expérience, il s'agit généralement d'un ensemble de tests couvrant l'ensemble du système, quelle que soit la taille du changement (bien que de petites modifications ne déclenchent pas nécessairement un test de régression).

Answer 4

Là où je travaille, les tests de régression sont normalisés pour chaque application à la fin de chaque publication. Ils sont conçus pour tester toutes les fonctionnalités, mais ils ne sont pas conçus pour détecter les bogues les plus subtils. Ainsi, si votre formulaire comporte différents types de validation, par exemple, une suite de régression pour ce formulaire permettrait de confirmer que chaque type de validation est effectué (niveau de champ et niveau de formulaire) et que des informations correctes peuvent être soumises. . Il n’est pas conçu pour couvrir tous les cas (par exemple, si je laisse le champ A vide? Pourquoi pas le champ B? Il ne fera que tester l’un d’eux et supposer que les autres fonctionnent).

Toutefois, sur le projet en cours sur lequel je travaille, les tests de régression sont beaucoup plus approfondis et nous avons constaté une réduction du nombre de défauts relevés au cours des tests. Les deux ne sont pas nécessairement liés, mais nous le remarquons assez régulièrement.

Answer 5

Selon ma compréhension du terme «test de régression»,

• les tests unitaires sont écrits pour tester les fonctionnalités lors de la création du système
• lorsque des bogues sont découverts, davantage de tests unitaires sont écrits pour reproduire le bogue et vérifier qu'il a été corrigé
• un test de régression exécute l'ensemble des tests prouvant que tout fonctionne toujours, y compris qu'aucun ancien bogue n'a réapparu [c'est-à-dire pour prouver que le code n'a pas "régressé"]]

En pratique, il est préférable de toujours exécuter tous les tests unitaires existants lorsque des modifications sont apportées. la seule fois où je m'ennuierais avec un sous-ensemble de tests, c'est quand la suite complète de tests unitaires prend "trop ??longtemps". pour exécuter [où " trop long " est assez subjectif]

Answer 6

Commencez par ce que vous essayez d'accomplir. Ensuite, faites ce que vous devez faire pour atteindre cet objectif. Et utilisez ensuite le mot à la mode bingo pour attribuer un mot à ce que vous faites réellement. Comme tout le monde :-) La précision n'est pas si importante.

Answer 7

  

... le test de régression était un petit échantillon (juste assez pour prouver que vous n'aviez pas rompu avec l'introduction d'un changement ou de nouveaux modules) - échantillon des tests globaux

Si un petit échantillon de tests suffit à prouver le fonctionnement du système, pourquoi les autres tests existent-ils? Et si vous pensez savoir que votre modification ne concerne qu'un sous-ensemble de fonctionnalités, pourquoi devez-vous tester quoi que ce soit après avoir effectué la modification? Les humains sont faillibles, personne ne sait vraiment si changer quelque chose casse autre chose. IMO, si vos tests sont automatisés, ré-exécutez-les tous. Et si elles ne sont pas automatisées, automatisez-les. En attendant, relancez tout ce qui est automatisé.

Answer 8

En général, un sous-ensemble des tests de fonctionnalité de la nouvelle fonctionnalité introduite dans la version X d'un produit devient la base des tests de régression pour les versions X + 1, X + 2, etc. Au fil du temps, vous pouvez réduire le temps passé par les tests de fonctionnalité / tests de régression de fonctionnalités stables qui n'ont pas subi de régression. Si une fonctionnalité subit de nombreuses régressions, il peut être intéressant de mettre davantage l'accent sur la fonctionnalité.

Je pense que l'article faisant référence à un "test de régression étendu" signifie l'exécution d'un ensemble complet de tests de régression (simples, individuellement).