what is regression testing
Qu'est-ce que le test de régression?
Le test de régression est un type de test effectué pour vérifier qu'une modification de code dans le logiciel n'affecte pas la fonctionnalité existante du produit. Cela permet de s'assurer que le produit fonctionne correctement avec les nouvelles fonctionnalités, les corrections de bogues ou tout changement dans la fonctionnalité existante. Les cas de test précédemment exécutés sont réexécutés afin de vérifier l'impact du changement.
=> Cliquez ici pour une série complète de didacticiels sur le plan de test
Le test de régression est un type de test logiciel dans lequel les cas de test sont réexécutés afin de vérifier si la fonctionnalité précédente de l'application fonctionne correctement et que les nouvelles modifications n'ont pas introduit de nouveaux bogues.
Ce test peut être effectué sur une nouvelle version lorsqu'il y a un changement significatif dans la fonctionnalité d'origine, même dans une seule correction de bogue.
La régression consiste à tester de nouveau les parties inchangées de l'application.
Ce que vous apprendrez:
- Tutoriels couverts dans cette série
- Aperçu du test de régression
- Quand effectuer ce test?
- Les tests de régression peuvent-ils être effectués manuellement?
- Outils de test de régression automatisés
- Pourquoi le test de régression?
- Types de tests de régression
- Quelle régression est nécessaire?
- Que faisons-nous dans le contrôle de régression?
- Techniques de test de régression
- Comment sélectionner une suite de tests de régression?
- Comment effectuer des tests de régression?
- Régression en Agile
- Avantages
- Désavantages
- Régression de l'application GUI
- Différence entre la régression et le nouveau test
- Modèle de plan de test de régression (TOC)
- Conclusion
- lecture recommandée
Tutoriels couverts dans cette série
Tutoriel n ° 1: Qu'est-ce que le test de régression (Ce tutoriel)
Tutoriel n ° 2: Outils de test de régression
Tutoriel n ° 3: Retester les tests de régression Vs
Tutoriel n ° 4: Tests de régression automatisés dans Agile
Aperçu du test de régression
Le test de régression est comme une méthode de vérification. Les cas de test sont généralement automatisés car les cas de test doivent s'exécuter encore et encore et exécuter les mêmes cas de test encore et encore manuellement prend du temps et est également fastidieux.
Par exemple, Considérez un produit X, dans lequel l'une des fonctionnalités est de déclencher des e-mails de confirmation, d'acceptation et d'envoi lorsque vous cliquez sur les boutons Confirmer, Accepter et Expédier.
Un problème se produit dans l'e-mail de confirmation et afin de résoudre le même problème, certaines modifications de code sont effectuées. Dans ce cas, non seulement les e-mails de confirmation doivent être testés, mais les e-mails d'acceptation et d'envoi doivent également être testés pour s'assurer que la modification du code ne les a pas affectés.
Le test de régression ne dépend d'aucun langage de programmation tel que Java, C ++, C #, etc. C'est une méthode de test qui est utilisée pour tester le produit pour les modifications ou pour les mises à jour en cours. Il vérifie que toute modification d'un produit n'affecte pas les modules existants du produit.
Vérifier que les bogues sont corrigés et que les fonctionnalités nouvellement ajoutées n'ont créé aucun problème dans la version de travail précédente du logiciel.
Les testeurs effectuent des tests fonctionnels lorsqu'une nouvelle version est disponible pour vérification. Le but de ce test est de vérifier les modifications apportées à la fonctionnalité existante et la fonctionnalité nouvellement ajoutée.
Lorsque ce test est terminé, le testeur doit vérifier si la fonctionnalité existante fonctionne comme prévu et si les nouvelles modifications n'ont introduit aucun défaut dans la fonctionnalité qui fonctionnait avant cette modification.
Le test de régression doit faire partie du cycle de publication et doit être pris en compte dans l'estimation du test.
Quand effectuer ce test?
Les tests de régression sont généralement effectués après vérification des modifications ou des nouvelles fonctionnalités. Mais ce n'est pas toujours le cas. Pour la publication qui prend des mois, des tests de régression doivent être intégrés au cycle de test quotidien. Pour les versions hebdomadaires, des tests de régression peuvent être effectués une fois les tests fonctionnels terminés.
Le contrôle de régression est une variante du retest (qui consiste simplement à répéter un test). Lors d'un nouveau test, la raison peut être n'importe quoi. Disons que vous testiez une fonctionnalité particulière et que c'était la fin de la journée - vous ne pouviez pas terminer le test et vous deviez arrêter le processus sans décider si le test réussissait / échouait.
Le lendemain, lorsque vous revenez, vous effectuez à nouveau le test - cela signifie que vous répétez un test que vous avez effectué auparavant. Le simple fait de répéter un test est un nouveau test.
Le test de régression est essentiellement une sorte de retest. Ce n'est que pour l'occasion spéciale que quelque chose dans l'application / le code a changé. Cela peut être le code, la conception ou quoi que ce soit qui dicte le cadre général du système.
Un nouveau test qui est effectué dans cette situation pour s'assurer que ledit changement n'a pas eu d'impact sur tout ce qui fonctionnait déjà auparavant est appelé test de régression. Les raisons les plus courantes pour lesquelles cela pourrait être effectué sont parce que de nouvelles versions du code ont été créées (augmentation de la portée / exigence) ou des bogues ont été corrigés.
Les tests de régression peuvent-ils être effectués manuellement?
J'enseignais juste un de ces jours dans ma classe, et une question m'est venue: 'La régression peut-elle être effectuée manuellement?'
J'ai répondu à la question et nous avons continué dans la classe. Tout semblait correct, mais d'une manière ou d'une autre, cette question m'a harcelé pendant un certain temps plus tard.
Sur les nombreux lots, cette question revient plusieurs fois de différentes manières. Certains d'entre eux sont:
- Pour effectuer l'exécution du test, avons-nous besoin d'un outil?
- Comment les tests de régression sont-ils effectués?
- Même après une série complète de tests - les nouveaux arrivants ont du mal à discerner ce qu'est exactement le test de régression?
Et bien sûr, la question initiale:
- Ce test peut-il être effectué manuellement?
Pour commencer, Exécution des tests est un simple acte d'utiliser vos cas de test et d'effectuer ces étapes sur l'AUT, de fournir les données de test et de comparer le résultat obtenu sur l'AUT avec le résultat attendu mentionné dans vos cas de test.
En fonction du résultat de la comparaison, nous définissons le statut de réussite / échec du scénario de test. L'exécution des tests est aussi simple que cela, il n'y a pas d'outils spéciaux nécessaires pour ce processus.
Outils de test de régression automatisés
Le test de régression automatisé est la zone de test où nous pouvons automatiser la plupart des efforts de test. Nous exécutons tous les cas de test précédemment exécutés sur une nouvelle version.
Cela signifie que nous avons un ensemble de cas de test disponible et que l'exécution de ces cas de test manuellement prend du temps. Nous connaissons les résultats attendus, donc l'automatisation de ces cas de test est un gain de temps et constitue une méthode de test de régression efficace. L'étendue de l'automatisation dépend du nombre de cas de test qui resteront applicables au fil du temps.
Si les cas de test varient de temps en temps, la portée de l'application augmente et l'automatisation de la procédure de régression sera une perte de temps.
La plupart des outils de test de régression sont de type enregistrement et lecture. Vous enregistrerez les cas de test en naviguant dans l'AUT (application en cours de test) et vérifierez si les résultats attendus arrivent ou non.
Outils
- Sélénium
- Catalogue Studio
- AdventNet QEngine
- Testeur de régression
- vTest
- l'eau
- actiWate
- Testeur fonctionnel rationnel
- SilkTest
- TimeShiftX
La plupart d'entre eux sont des outils de test fonctionnels et de régression.
Lecture recommandée => Consultez ici la liste des principaux outils de régression
L'ajout et la mise à jour de cas de test de régression dans une suite de tests d'automatisation est une tâche fastidieuse. Lors de la sélection d'un outil d'automatisation pour les tests de régression, vous devez vérifier si l'outil vous permet d'ajouter ou de mettre à jour facilement les cas de test.
réalité virtuelle compatible avec xbox one
Dans la plupart des cas, nous devons fréquemment mettre à jour les cas de test de régression automatisés en raison de changements fréquents dans le système.
VOIR LA VIDÉO
Pour une explication plus détaillée de la définition avec un exemple, veuillez vérifier ce qui suitVidéo du test de régression:
Pourquoi le test de régression?
La régression est lancée lorsqu'un programmeur corrige un bogue ou ajoute un nouveau code pour une nouvelle fonctionnalité au système.
Il peut y avoir de nombreuses dépendances dans les fonctionnalités nouvellement ajoutées et existantes.
C'est une mesure de qualité pour vérifier si le nouveau code est conforme à l'ancien code afin que le code non modifié ne soit pas affecté. La plupart du temps, l'équipe de test a la tâche de vérifier les changements de dernière minute dans le système.
Dans une telle situation, il est nécessaire de tester uniquement la zone d'application concernée pour terminer le processus de test à temps en couvrant tous les principaux aspects du système.
Ce test est très important lorsqu'il y a un changement / amélioration continu ajouté dans l'application. La nouvelle fonctionnalité ne doit pas affecter négativement le code testé existant.
La régression est nécessaire pour trouver les bogues qui se sont produits en raison d'une modification du code. Si ce test n'est pas effectué, le produit peut rencontrer des problèmes critiques dans l'environnement réel et cela peut en effet entraîner des problèmes pour le client.
Lors du test d'un site Web en ligne, un testeur signale un problème selon lequel le prix du produit n'est pas affiché correctement, c'est-à-dire qu'il affiche un prix inférieur au prix réel du produit, et il doit être corrigé rapidement.
Une fois que le développeur a résolu le problème, il doit être retesté et des tests de régression sont également nécessaires, car la vérification du prix sur la page signalée aurait été corrigée, mais il se peut qu'il affiche un prix incorrect sur la page de résumé où le total est affiché. avec les autres frais ou le courrier envoyé au client a toujours le prix incorrect.
Désormais, dans ce cas, le client devra supporter la perte si ce test n'est pas effectué car le site calcule le coût total avec le prix incorrect et le même prix revient à un client par email. Une fois que le client accepte, le produit est vendu en ligne à un prix inférieur, ce sera une perte pour le client.
Donc, ces tests jouent un grand rôle et sont également très nécessaires et importants.
Types de tests de régression
Voici les différents types de régression:
- Régression des unités
- Régression partielle
- Régression complète
# 1) Régression d'unité
La régression d'unité est effectuée pendant la Test unitaire la phase et le code sont testés isolément, c'est-à-dire que toutes les dépendances de l'unité à tester sont bloquées afin que l'unité puisse être testée individuellement sans aucune divergence.
# 2) Régression partielle
La régression partielle est effectuée pour vérifier que le code fonctionne correctement même lorsque les modifications ont été effectuées dans le code et que l'unité est intégrée au code inchangé ou déjà existant.
# 3) Régression complète
La régression complète est effectuée lorsqu'un changement dans le code est effectué sur un certain nombre de modules et également si l'impact du changement d'un changement dans un autre module est incertain. Le produit dans son ensemble est régressé pour vérifier les modifications dues au code modifié.
Quelle régression est nécessaire?
Cela dépend de la portée des fonctionnalités nouvellement ajoutées.
Si la portée d'un correctif ou d'une fonctionnalité est trop grande, la zone d'application affectée est également assez grande et les tests doivent être effectués de manière approfondie, y compris tous les cas de test d'application. Mais cela peut être décidé efficacement lorsque le testeur reçoit des informations d'un développeur sur la portée, la nature et la quantité de changement.
Comme il s'agit de tests répétitifs, les cas de test peuvent être automatisés afin qu'un ensemble de cas de test seul puisse être facilement exécuté sur une nouvelle version.
Les cas de test de régression doivent être sélectionnés très soigneusement afin que la fonctionnalité maximale soit couverte dans un ensemble minimum de cas de test. Ces ensembles de cas de test nécessitent des améliorations continues pour les fonctionnalités nouvellement ajoutées.
Cela devient très difficile lorsque la portée de l'application est très vaste et qu'il y a des incréments ou des correctifs continus dans le système. Dans de tels cas, des tests sélectifs doivent être exécutés afin d'économiser du temps et des coûts de test. Ces cas de test sélectifs sont choisis en fonction des améliorations apportées au système et des parties où cela peut le plus affecter.
Que faisons-nous dans le contrôle de régression?
- Relancez les tests précédemment effectués
- Comparez les résultats actuels avec les résultats des tests précédemment exécutés
Il s'agit d'un processus continu exécuté à différentes étapes tout au long du cycle de vie des tests logiciels.
Une bonne pratique consiste à effectuer un test de régression après Test de santé mentale ou de fumée et à la fin des tests fonctionnels pour une version courte.
Afin de mener des tests efficaces, la régression Plan de test devrait être créé. Ce plan doit décrire la stratégie de test de régression et les critères de sortie. Les tests de performances font également partie de ce test pour s'assurer que les performances du système ne sont pas affectées en raison des modifications apportées aux composants du système.
Les meilleures pratiques : Exécutez des cas de test automatisés tous les jours le soir afin que les effets secondaires de la régression puissent être corrigés dans la construction du lendemain. De cette façon, il réduit le risque de libération en couvrant presque tous les défauts de régression à un stade précoce plutôt que de trouver et de corriger ceux à la fin du cycle de publication.
Techniques de test de régression
Ci-dessous sont les différentes techniques.
- Tout retester
- Sélection du test de régression
- Hiérarchisation des cas de test
- Hybride
# 1) Tout retester
Comme son nom l'indique, tous les cas de test de la suite de tests sont réexécutés pour s'assurer qu'aucun bogue ne s'est produit à cause d'un changement de code. Il s'agit d'une méthode coûteuse car elle nécessite plus de temps et de ressources par rapport aux autres techniques.
# 2) Sélection du test de régression
Dans cette méthode, les cas de test sont sélectionnés dans la suite de tests pour être réexécutés. La suite entière n'est pas réexécutée. La sélection des cas de test se fait sur la base du changement de code dans le module.
Les cas de test sont divisés en deux catégories, l'une est les cas de test réutilisables et l'autre est les cas de test obsolètes. Les cas de test réutilisables peuvent être utilisés dans les futurs cycles de régression, tandis que les cas obsolètes ne sont pas utilisés dans les prochains cycles de régression.
# 3) Priorisation des cas de test
Les cas de test avec une priorité élevée sont exécutés en premier que ceux avec une priorité moyenne et faible. La priorité du cas de test dépend de sa criticité et de son impact sur le produit ainsi que de la fonctionnalité du produit qui est le plus souvent utilisé.
# 4) Hybride
La technique hybride est une combinaison de sélection de test de régression et de priorisation de cas de test. Plutôt que de sélectionner toute la suite de tests, sélectionnez uniquement les cas de test qui sont réexécutés en fonction de leur priorité.
Comment sélectionner une suite de tests de régression?
La plupart des bogues trouvés dans l'environnement de production se produisent à cause des changements effectués ou des bogues corrigés à la onzième heure, c'est-à-dire les changements effectués à un stade ultérieur. La correction de bogue à la dernière étape peut créer d'autres problèmes / bogues dans le produit. C'est pourquoi la vérification de régression est très importante avant de lancer un produit.
Vous trouverez ci-dessous une liste de cas de test pouvant être utilisés lors de l'exécution de ce test:
- Fonctionnalités fréquemment utilisées.
- Cas de test qui couvrent le module où les modifications ont été effectuées.
- Cas de test complexes.
- Cas de test d'intégration qui incluent tous les composants principaux.
- Scénarios de test pour la fonctionnalité ou la caractéristique principale du produit.
- Les cas de test de priorité 1 et de priorité 2 doivent être inclus.
- Des cas de test qui échouent fréquemment ou des défauts de test récents ont été trouvés dans le même.
Comment effectuer des tests de régression?
Maintenant que nous avons établi ce que signifie la régression, il est évident qu'elle teste aussi - répétition simplement dans une situation spécifique pour une raison spécifique. Par conséquent, nous pouvons en déduire que la même méthode s'applique pour les tests en premier lieu peut également être appliquée à cela.
Par conséquent, si les tests peuvent être effectués manuellement, les tests de régression peuvent l'être également. L'utilisation d'un outil n'est pas nécessaire. Cependant, au fil du temps, les applications s'accumulent avec de plus en plus de fonctionnalités qui ne cessent d'augmenter la portée de la régression. Pour profiter au maximum du temps, ce test est le plus souvent automatisé .
Vous trouverez ci-dessous les différentes étapes impliquées dans l'exécution de ce test
- Préparez une suite de tests pour la régression en tenant compte des points mentionnés dans «Comment sélectionner la suite de tests de régression»?
- Automatisez tous les cas de test de la suite de tests.
- Mettez à jour la suite de régression chaque fois que cela est nécessaire, comme si un nouveau défaut qui n'est pas couvert dans le cas de test est trouvé, et un cas de test pour le même devrait être mis à jour dans la suite de tests afin que le test ne soit pas manqué pour la même fois la prochaine fois . La suite de tests de régression doit être gérée correctement en mettant continuellement à jour les cas de test.
- Exécutez les cas de test de régression chaque fois qu'il y a un changement dans le code, le bogue est corrigé, une nouvelle fonctionnalité est ajoutée, une amélioration de la fonctionnalité existante est effectuée, etc.
- Créez un rapport d'exécution de test qui inclut l'état de réussite / échec des cas de test exécutés.
Par exemple:
Laissez-moi vous expliquer cela avec un exemple. Veuillez examiner la situation ci-dessous:
Statistiques de la version 1 | |
---|---|
Nombre de testeurs | 3 |
Nom de l'application | XYZ |
Numéro de version / version | 1 |
Nombre d'exigences (portée) | dix |
Nombre de cas de test / tests | 100 |
Nombre de jours nécessaires pour se développer | 5 |
Nombre de jours nécessaires pour tester | 5 |
Statistiques de la version 2 | |
---|---|
Nombre de testeurs | 3 |
Nom de l'application | XYZ |
Numéro de version / version | deux |
Nombre d'exigences (portée) | 10+ 5 nouvelles exigences |
Nombre de cas de test / tests | 100+ 50 nouveaux |
Nombre de jours nécessaires pour se développer | 2,5 (puisque cette moitié de la quantité de travail qu'avant) |
Nombre de jours nécessaires pour tester | 5 (pour les 100 TC existants) + 2,5 (pour les nouvelles exigences) |
Statistiques de la version 3 | |
---|---|
Nombre de testeurs | 3 |
Nom de l'application | XYZ |
Numéro de version / version | 3 |
Nombre d'exigences (portée) | 10+ 5 + 5 nouvelles exigences |
Nombre de cas de test / tests | 100+ 50+ 50 nouveaux |
Nombre de jours nécessaires pour se développer | 2,5 (puisque cette moitié de la quantité de travail qu'avant) |
Nombre de jours nécessaires pour tester | 7,5 (pour les 150 TC existants) + 2,5 (pour les nouvelles exigences) |
Voici les observations que nous pouvons faire à partir de la situation ci-dessus:
- Au fur et à mesure que les versions se développent, la fonctionnalité augmente.
- Le temps de développement n'augmente pas nécessairement avec les versions, mais le temps de test augmente
- Aucune entreprise / sa direction ne sera prête à investir plus de temps dans les tests et moins pour le développement
- Nous ne pouvons même pas réduire le temps de test en augmentant la taille de l'équipe de test car plus de personnes signifie plus d'argent et de nouvelles personnes signifie également beaucoup de formation et peut-être aussi un compromis de qualité car les nouvelles personnes pourraient ne pas être à la hauteur des connaissances requises. niveaux immédiatement.
- L'autre alternative est clairement de réduire la quantité de régression. Mais cela pourrait être risqué pour le produit logiciel.
Pour toutes ces raisons, les tests de régression sont un bon candidat pour les tests d'automatisation, mais cela ne doit pas être fait uniquement de cette manière.
Étapes de base pour effectuer des tests de régression
À chaque fois que le logiciel subit un changement et qu'une nouvelle version / release apparaît, voici les étapes que vous pouvez suivre pour effectuer ce type de test:
- Comprendre quels types de changements ont été apportés au logiciel
- Analyser et déterminer quels modules / parties du logiciel pourraient être impactés - les équipes de développement et BA peuvent jouer un rôle déterminant dans la fourniture de ces informations
- Jetez un œil à vos cas de test et déterminez si vous devrez effectuer une régression complète, partielle ou unitaire. Identifiez ceux qui conviendront à votre situation
- Planifiez le temps et testez!
Régression en Agile
Agile est une approche adaptative qui suit une méthode itérative et incrémentale. Le produit est développé en courtes itérations appelées sprint qui durent 2 à 4 semaines. En agile, il y a un certain nombre d'itérations, ce test joue donc un rôle important car la nouvelle fonctionnalité ou le changement de code est effectué dans les itérations.
La suite de tests de régression doit être préparée dès la phase initiale et mise à jour à chaque sprint.
Dans Agile, le contrôle de régression est couvert sous deux catégories:
- Régression de niveau de sprint
- Régression de bout en bout
# 1) Régression du niveau de sprint
La régression de niveau de sprint est effectuée principalement pour la nouvelle fonctionnalité ou l'amélioration effectuée dans le dernier sprint. Les cas de test de la suite de tests sont sélectionnés en fonction de la fonctionnalité nouvellement ajoutée ou de l'amélioration effectuée.
# 2) Régression de bout en bout
La régression de bout en bout inclut tous les cas de test qui doivent être réexécutés pour tester le produit complet de bout en bout en couvrant toutes les fonctionnalités de base du produit.
Comme Agile a des sprints courts et que cela continue, il est très nécessaire d'automatiser la suite de tests, les cas de test sont à nouveau exécutés et cela aussi doit être terminé dans un court laps de temps. L'automatisation des cas de test réduit le temps d'exécution et le glissement des défauts.
Avantages
Voici les différents avantages du test de régression
- Cela améliore la qualité du produit.
- Il garantit que toute correction de bogue ou amélioration effectuée n'affectera pas la fonctionnalité existante du produit.
- Des outils d'automatisation peuvent être utilisés pour ces tests.
- Cela garantit que les problèmes déjà résolus ne se reproduiront plus.
Désavantages
Bien qu'il y ait plusieurs avantages, il y a aussi quelques inconvénients. Elles sont:
- Cela doit également être fait pour un petit changement dans le code, car même un petit changement dans le code peut créer des problèmes dans la fonctionnalité existante.
- Si dans le cas où l'automatisation n'est pas utilisée dans le projet pour ces tests, il sera une tâche longue et fastidieuse d'exécuter les cas de test encore et encore.
Régression de l'application GUI
Il est difficile d'effectuer un test de régression GUI (interface utilisateur graphique) lorsque la structure GUI est modifié. Les cas de test écrits sur l'ancienne interface graphique deviennent obsolètes ou doivent être modifiés.
La réutilisation des cas de test de régression signifie que les cas de test GUI sont modifiés en fonction de la nouvelle GUI. Mais cette tâche devient fastidieuse si vous disposez d'un grand nombre de cas de test GUI.
Différence entre la régression et le nouveau test
Un nouveau test est effectué pour les cas de test qui échouent pendant l'exécution et le bogue soulevé pour le même a été corrigé tandis que le contrôle de régression n'est pas limité à la correction de bogue car il couvre également d'autres cas de test pour s'assurer que le correctif de bogue n'a pas impacté toute autre fonctionnalité du produit.
Modèle de plan de test de régression (TOC)
1. Historique du document
2. Références
3. Plan de test de régression
3.1. introduction
3.2. But
3.3. Stratégie de test
3.4. Fonctionnalité à tester
3.5. Besoin en ressources
3.5.1. Exigence matérielle
3.5.2. Exigence logicielle
3.6. Calendrier des tests
3.7. Changer de requête
3.8. Critères d'entrée / sortie
3.8.1. Critères d'entrée pour ce test
3.8.2. Critères de sortie pour ce test
3.9. Hypothèse / Contraintes
3.10. Cas de test
3.11. Risque / hypothèses
3.12. Outils
4. Approbation / Acceptation
Jetons un coup d'œil à chacun d'eux en détail.
# 1) Historique des documents
L'historique du document se compose d'un enregistrement du premier brouillon et de tous ceux mis à jour dans le format ci-dessous.
Version | Date | Auteur | Commenter |
---|---|---|---|
1 | JJ / MM / AA | abc | Approuvé |
deux | JJ / MM / AA | abc | Mis à jour pour la fonctionnalité ajoutée |
# 2) Références
La colonne Références garde une trace de tous les documents de référence utilisés ou requis pour le projet lors de la création d'un plan de test.
Ne pas | Document | Lieu |
---|---|---|
1 | Document SRS | Drive partagé |
# 3) Plan de test de régression
3.1. introduction
Ce document décrit le changement / la mise à jour / l'amélioration du produit à tester et l'approche utilisée pour ces tests. Tous les changements de code, améliorations, mises à jour, fonctionnalités ajoutées sont décrits pour être testés. Les cas de test utilisés pour les tests unitaires et les tests d'intégration peuvent être utilisés pour créer une suite de tests pour la régression.
3.2. But
Le but du plan de test de régression est de décrire ce qui exactement et comment les tests seraient effectués pour obtenir les résultats. Un contrôle de régression est effectué pour s'assurer qu'aucune autre fonctionnalité du produit n'est entravée en raison du changement de code.
3.3. Stratégie de test
La stratégie de test décrit l'approche qui sera utilisée pour effectuer ces tests et qui comprend la technique qui sera utilisée, quels seront les critères d'achèvement, qui effectuera quelle activité, qui écrira les scripts de test, quel outil de régression sera utilisé , des mesures pour couvrir les risques tels que la pénurie de ressources, les retards de production, etc.
3.4. Caractéristiques à tester
Les caractéristiques / composants du produit à tester sont répertoriés ici. Dans la régression, tous les cas de test sont réexécutés ou ceux qui affectent la fonctionnalité existante sont choisis en fonction de la correction / mise à jour ou de l'amélioration effectuée.
3.5. Besoin en ressources
3.5.1. Exigence matérielle:
Les exigences matérielles sont identifiées ici comme les ordinateurs, les ordinateurs portables, les modems, les livres Mac, les smartphones, etc.
3.5.2. Exigence logicielle:
Les exigences logicielles sont identifiées comme le système d'exploitation et les navigateurs requis.
3.6. Calendrier des tests
Le programme de test définit le temps estimé pour effectuer les activités de test.
Par exemple Combien de ressources effectueront une activité de test et cela aussi dans combien de temps?
3.7. Changer de requête
Les détails CR sont mentionnés pour lesquels la régression serait effectuée.
S. Non | Description CR | Suite de tests de régression |
---|---|---|
1 | ||
deux |
3.8. Critères d'entrée / sortie
3.8.1. Critères d'entrée pour ce test:
Les critères d'entrée du produit pour démarrer le contrôle de régression sont définis.
Par exemple:
- Les changements de codage / l'amélioration / l'ajout d'une nouvelle fonctionnalité doivent être terminés.
- Le plan de test de régression doit être approuvé.
3.8.2. Critères de sortie pour ce test:
Ici, les critères de sortie pour la régression sont définis.
Par exemple:
- Les tests de régression doivent être terminés.
- Tout nouveau bogue critique détecté lors de ce test doit être fermé.
- Le rapport de test doit être prêt.
3.9. Cas de test
Les cas de test de régression sont définis ici.
3.10. Risque / hypothèses
Tous les risques et hypothèses sont identifiés et un plan d'urgence est préparé pour le même.
3.11. Outils
Les outils à utiliser dans le projet sont identifiés. Tel que:
- Outil d'automatisation
- Outil de rapport de bogue
# 4) Approbation / Acceptation
Les noms et la désignation des personnes sont énumérés ici:
Nom | Approuvé / Rejeté | Signature | Date |
---|---|---|---|
Conclusion
Le test de régression est l'un des aspects importants car il permet de fournir un produit de qualité en s'assurant que toute modification du code, qu'elle soit petite ou grande, n'affecte pas la fonctionnalité existante ou ancienne.
De nombreux outils d'automatisation sont disponibles pour automatiser les cas de test de régression, cependant, un outil doit être sélectionné conformément aux exigences du projet. Un outil doit avoir la capacité de mettre à jour la suite de tests car la suite de tests de régression doit être mise à jour fréquemment.
Sur ce, nous clôturons ce sujet et espérons qu'il y aura une bien meilleure clarté sur le sujet à partir de maintenant.
Veuillez nous faire part de vos questions et commentaires relatifs à la régression. Comment avez-vous abordé vos tâches de test de régression?
=> Visitez ici pour une série complète de didacticiels sur le plan de test
lecture recommandée
- Meilleurs outils de test de logiciels 2021 [Outils d'automatisation des tests QA]
- Top 10 des outils de test de régression les plus populaires en 2021
- Qu'est-ce que le test de fiabilité: définition, méthode et outils
- 11 meilleurs outils d'automatisation pour tester les applications Android (outils de test des applications Android)
- Tests de régression automatisés: défis, processus et étapes
- Téléchargement du livre électronique sur les tests
- Différence entre un nouveau test et un test de régression avec l'exemple
- Top 10 des meilleurs outils de test SAP (SAP Automation Tools)