Les tests de régression sont des techniques de test en boîte noire. Il est utilisé pour authentifier qu'un changement de code dans le logiciel n'a pas d'impact sur les fonctionnalités existantes du produit. Les tests de régression visent à garantir que le produit fonctionne correctement avec les nouvelles fonctionnalités, les corrections de bogues ou toute modification apportée à la fonctionnalité existante.
Les tests de régression sont un type de tests de logiciels . Les cas de test sont réexécutés pour vérifier que les fonctionnalités précédentes de l'application fonctionnent correctement et que les nouvelles modifications n'ont produit aucun bug.
Des tests de régression peuvent être effectués sur une nouvelle version lorsqu'il y a un changement significatif dans la fonctionnalité d'origine. Cela garantit que le code fonctionne toujours même lorsque des modifications se produisent. La régression signifie re-tester les parties de l'application qui sont inchangées.
Les tests de régression sont également connus sous le nom de méthode de vérification. Les cas de test sont souvent automatisés. Les cas de test doivent être exécutés plusieurs fois et exécuter le même scénario de test encore et encore manuellement prend du temps et est également fastidieux.
Exemple de test de régression
Ici, nous allons prendre un cas pour définir efficacement les tests de régression :
Considérons un produit Y, dans lequel l'une des fonctionnalités est de déclencher des e-mails de confirmation, d'acceptation et d'envoi. Il doit également être testé pour garantir que la modification du code ne les a pas affectés. Les tests de régression ne dépendent d'aucun langage de programmation comme Java , C++ , C# , etc. Cette méthode est utilisée pour tester le produit pour les modifications ou les mises à jour effectuées. Il garantit que toute modification apportée à un produit n’affecte pas le module existant du produit. Vérifiez que les bogues corrigés et les fonctionnalités nouvellement ajoutées n'ont créé aucun problème dans la version de travail précédente du logiciel.
Quand pouvons-nous effectuer des tests de régression ?
Nous effectuons des tests de régression chaque fois que le code de production est modifié.
Nous pouvons effectuer des tests de régression dans le scénario suivant, à savoir :
1. Lorsqu'une nouvelle fonctionnalité est ajoutée à l'application.
Exemple:
Un site Web dispose d'une fonctionnalité de connexion qui permet aux utilisateurs de se connecter uniquement par e-mail. Fournissant désormais une nouvelle fonctionnalité pour se connecter à l'aide de Facebook.
2. Lorsqu'il y a une exigence de changement.
Exemple:
N'oubliez pas le mot de passe supprimé de la page de connexion qui était applicable précédemment.
3. Lorsque le défaut est réparé
Exemple:
Supposons que le bouton de connexion ne fonctionne pas dans une page de connexion et qu'un testeur signale un bug indiquant que le bouton de connexion est cassé. Une fois le bug corrigé par les développeurs, le testeur le teste pour s'assurer que le bouton de connexion fonctionne conformément au résultat attendu. Simultanément, le testeur teste d’autres fonctionnalités liées au bouton de connexion.
4. Lorsqu'il y a un correctif de problème de performances
Exemple:
Le chargement d'une page d'accueil prend 5 secondes, réduisant le temps de chargement à 2 secondes.
texte d'habillage CSS
5. Quand il y a un changement d’environnement
Exemple:
Lorsque nous mettons à jour la base de données de MySql vers Oracle.
Comment effectuer des tests de régression ?
Le besoin de tests de régression survient lorsque la maintenance logicielle comprend des améliorations, des corrections d'erreurs, l'optimisation et la suppression de fonctionnalités existantes. Ces modifications peuvent affecter la fonctionnalité du système. Des tests de régression deviennent nécessaires dans ce cas.
Les tests de régression peuvent être effectués à l'aide des techniques suivantes :
1. Re-testez tout :
Re-Test est l'une des approches pour effectuer des tests de régression. Dans cette approche, toutes les combinaisons de cas de test doivent être réexécutées. Ici, nous pouvons définir un nouveau test comme lorsqu'un test échoue et nous déterminons que la cause de l'échec est une erreur logicielle. Le défaut est signalé, on peut s'attendre à une nouvelle version du logiciel dans laquelle le défaut est corrigé. Dans ce cas, nous devrons réexécuter le test pour confirmer que le défaut est résolu. C’est ce qu’on appelle un nouveau test. Certains appelleront cela des tests de confirmation.
Le nouveau test est très coûteux, car il nécessite énormément de temps et de ressources.
2. Test de régression Sélection :
- Dans cette technique, une combinaison de cas de test sélectionnée sera exécutée plutôt qu'une combinaison de cas de test entière.
- Les cas de test sélectionnés sont divisés en deux cas
- Cas de tests réutilisables.
- Cas de test obsolètes.
- Les cas de test réutilisables peuvent être utilisés dans le cycle de régression suivant.
- Les cas de test obsolètes ne peuvent pas être utilisés dans le cycle de régression suivant.
3. Priorisation des cas de tests :
Hiérarchisez le scénario de test en fonction de l'impact commercial, des fonctionnalités critiques et fréquemment utilisées. La sélection de cas de test réduira la suite de tests de régression.
Quels sont les outils de tests de régression ?
Les tests de régression sont une partie essentielle du processus d'assurance qualité ; lors de l'exécution de la régression, nous pouvons être confrontés aux défis ci-dessous :
lettre d'îlot java
Les tests de régression prennent beaucoup de temps. Les tests de régression impliquent à nouveau des tests existants, les testeurs ne sont donc pas enthousiastes à l'idée de réexécuter le test.
Les tests de régression sont également complexes lorsqu'il est nécessaire de mettre à jour un produit ; les listes de tests augmentent également.
Les tests de régression garantissent que les fonctionnalités du produit existant sont toujours en état de fonctionnement. La communication sur les tests de régression avec un responsable non technique peut être une tâche difficile. L'exécutif souhaite voir le produit évoluer et investir beaucoup de temps dans les tests de régression pour garantir que les fonctionnalités existantes fonctionnent peut être difficile.
Processus de test de régression
Le processus de test de régression peut être effectué sur l'ensemble du construit et le sorties .
Tests de régression à travers les builds
Chaque fois que le bug est corrigé, nous testons à nouveau le bug, et s'il existe un module dépendant, nous effectuons un test de régression.
Par exemple , Comment effectuons-nous les tests de régression si nous avons des versions différentes comme Construire 1, Construire 2 et Construire 3 , qui a différents scénarios.
Construire1
- Tout d’abord, le client répondra aux besoins de l’entreprise.
- Ensuite, l’équipe de développement commence à développer les fonctionnalités.
- Après cela, l'équipe de test commencera à rédiger les cas de test ; par exemple, ils rédigent 900 cas de test pour la version n°1 du produit.
- Et puis, ils commenceront à mettre en œuvre les cas de test.
- Une fois le produit lancé, le client effectue une série de tests d’acceptation.
- Et finalement, le produit est déplacé vers le serveur de production.
Construire2
- Désormais, le client demande l’ajout de 3 à 4 (nouvelles) fonctionnalités supplémentaires et fournit également les exigences relatives aux nouvelles fonctionnalités.
- L'équipe de développement commence à développer de nouvelles fonctionnalités.
- Après cela, l'équipe de test commencera à rédiger le scénario de test pour les nouvelles fonctionnalités et rédigera environ 150 nouveaux scénarios de test. Par conséquent, le nombre total de scénarios de test écrits est de 1 050 pour les deux versions.
- L'équipe de test commence désormais à tester les nouvelles fonctionnalités à l'aide de 150 nouveaux cas de test.
- Une fois cela fait, ils commenceront à tester les anciennes fonctionnalités à l’aide de 900 cas de test pour vérifier que l’ajout de la nouvelle fonctionnalité a endommagé ou non les anciennes fonctionnalités.
- Ici, tester les anciennes fonctionnalités est appelé Les tests de régression .
- Une fois que toutes les fonctionnalités (nouvelles et anciennes) ont été testées, le produit est remis au client, qui effectue ensuite les tests d'acceptation.
- Une fois les tests d'acceptation effectués, le produit est déplacé vers le serveur de production.
Construire3
- Après la deuxième version, le client souhaite supprimer l'une des fonctionnalités telles que les ventes.
- Il supprimera ensuite tous les cas de tests appartenant au module de vente (environ 120 cas de tests).
- Ensuite, testez l'autre fonctionnalité pour vérifier que si toutes les autres fonctionnalités fonctionnent correctement après la suppression des cas de test du module de vente, et ce processus est effectué dans le cadre des tests de régression.
Note:
- Tester les fonctionnalités stables pour s’assurer qu’elles sont cassées en raison des modifications. Ici, les changements impliquent que le la modification, l'ajout, la correction de bugs ou la suppression .
- La réexécution des mêmes cas de test dans les différentes versions ou versions vise à garantir que les changements (modification, ajout, correction de bugs ou suppression) n'introduisent pas de bugs dans les fonctionnalités stables.
Tests de régression sur toute la version
Le processus de test de régression démarre chaque fois qu'il y a une nouvelle version pour le même projet, car la nouvelle fonctionnalité peut affecter les anciens éléments des versions précédentes.
Pour comprendre le processus de test de régression, nous suivrons les étapes ci-dessous :
Étape 1
Il n'y a pas de test de régression dans Version n°1 car aucune modification n'est effectuée dans la version n°1 car la version est elle-même nouvelle.
Étape 2
Le concept des tests de régression commence à partir de Version n°2 quand le client en donne nouvelles exigences .
Étape 3
Après avoir d'abord obtenu les nouvelles exigences (modification des fonctionnalités), ils (les développeurs et les ingénieurs de test) comprendront les besoins avant de passer à l'étape suivante. analyse d'impact .
Étape 4
Après avoir compris les nouvelles exigences, nous effectuerons une série de analyse d'impact pour éviter le risque majeur, mais ici la question se pose de savoir qui fera l'analyse d'impact ?
Étape 5
L'analyse d'impact est réalisée par le client en fonction de leur Connaissance des affaires , le développeur en fonction de leur connaissances en codage , et surtout, cela est fait par le ingénieur d'essais parce qu'ils ont le connaissance des produits .
Remarque : Si une seule personne le fait, il se peut qu'elle ne couvre pas toutes les zones d'impact. Nous incluons donc toutes les personnes afin de pouvoir couvrir une zone d'impact maximale, et l'analyse d'impact doit être effectuée dès les premiers stades des versions.
Étape 6
Une fois que nous en avons fini avec le zone d'impact , alors le développeur préparera le zone d'impact (document) , et le client préparera également le document sur la zone d'impact afin que nous puissions atteindre le couverture maximale de l’analyse d’impact .
Étape 7
Après avoir terminé l'analyse d'impact, le développeur, le client et l'ingénieur de test enverront le Rapports# des documents sur la zone d'impact au Responsable des Tests . Et pendant ce temps, l’ingénieur de test et le développeur travaillent sur le nouveau scénario de test.
Étape 8
Une fois que le responsable du test aura reçu le numéro de rapport, il/elle consolider les rapports et stockés dans le référentiel d'exigences de scénario de test pour la version n°1.
Remarque : Référentiel de cas de test : ici, nous enregistrerons tous les cas de test des versions.
Étape 9
Après cela, le responsable du test demandera l'aide de RTM et sélectionnera les éléments nécessaires. cas de test de régression du référentiel de cas de test , et ces fichiers seront placés dans le Suite de tests de régression .
Note:
- Le responsable du test stockera le scénario de test de régression dans la suite de tests de régression pour éviter toute confusion supplémentaire.
Étape 10
Après cela, lorsque l'ingénieur de test aura fini de travailler sur les nouveaux cas de test, le responsable du test attribuer le scénario de test de régression à l'ingénieur d'essai.
Étape 11
Lorsque tous les cas de tests de régression et les nouvelles fonctionnalités sont stable et réussi , puis vérifiez le zone d'impact à l'aide du cas de test jusqu'à ce qu'il soit durable pour les anciennes fonctionnalités ainsi que les nouvelles fonctionnalités, puis il sera remis au client.
Types de tests de régression
Les différents types de tests de régression sont les suivants :
- Tests de régression unitaire [URT]
- Tests de régression régionaux [RRT]
- Tests de régression complets ou complets [FRT]
1) Tests de régression unitaire [URT]
En cela, nous allons tester uniquement l'unité modifiée, pas la zone d'impact, car cela peut affecter les composants du même module.
Exemple 1
Dans l'application ci-dessous et dans la première version, le développeur développe le Recherche bouton qui accepte 1-15 caractères . Ensuite, l'ingénieur de test teste le bouton Rechercher à l'aide du technique de conception de cas de test .
Désormais, le client apporte quelques modifications à l'exigence et demande également que le Bouton Rechercher peut accepter le 1-35 caractères . L'ingénieur de test testera uniquement le bouton Rechercher pour vérifier qu'il prend entre 1 et 35 caractères et ne vérifiera aucune autre fonctionnalité de la première version.
Exemple2
Ici nous avons Construire B001 , un défaut est identifié et le rapport est remis au développeur. Le développeur corrigera le bug et enverra quelques nouvelles fonctionnalités développées dans le second. Construire B002 . Après cela, l’ingénieur de test ne testera qu’une fois le défaut corrigé.
- L'ingénieur de test identifiera qu'en cliquant sur le Soumettre Le bouton va à la page blanche.
- Et c'est un défaut, et il est envoyé au développeur pour qu'il le corrige.
- Lorsque la nouvelle version est accompagnée des corrections de bogues, l'ingénieur de test testera uniquement le bouton Soumettre.
- Et ici, nous n'allons pas vérifier les autres fonctionnalités de la première build et passer à tester les nouvelles fonctionnalités envoyées dans la deuxième build.
- Nous sommes sûrs que la réparation du Soumettre Le bouton n'affectera pas les autres fonctionnalités, nous testons donc uniquement le bug corrigé.
Par conséquent, nous pouvons dire qu'en testant uniquement la fonctionnalité modifiée, on l'appelle la Tests de régression unitaire .
2) Tests de régression régionaux [RRT]
En cela, nous allons tester la modification ainsi que la ou les zones d'impact, appelées les Tests de régression régionaux . Ici, nous testons la zone d'impact car s'il existe des modules fiables, cela affectera également les autres modules.
Par exemple:
Dans l'image ci-dessous, nous pouvons voir que nous avons quatre modules différents, tels que Module A, module B, module C et module D , qui sont fournis par les développeurs pour les tests lors de la première build. Désormais, l'ingénieur de test identifiera les bugs dans ModuleD . Le rapport de bug est envoyé aux développeurs, et l'équipe de développement corrige ces défauts et envoie la deuxième version.
Dans la deuxième version, les défauts précédents sont corrigés. L'ingénieur de test comprend désormais que la correction du bug dans le module D a eu un impact sur certaines fonctionnalités du module. Module A et Module C . Ainsi, l'ingénieur de test teste d'abord le module D où le bug a été corrigé, puis vérifie les zones d'impact dans Module A et Module C . Par conséquent, ce test est connu sous le nom de Tests de régression régionaux.
Lors de l'exécution des tests de régression régionale, nous pouvons être confrontés au problème ci-dessous :
se connecter à une base de données java
Problème:
Dans la première version, le client envoie des modifications aux exigences et souhaite également ajouter de nouvelles fonctionnalités dans le produit. Les besoins sont envoyés aux deux équipes, c'est-à-dire celles de développement et de tests.
Après avoir obtenu les exigences, l'équipe de développement commence à effectuer les modifications et développe également les nouvelles fonctionnalités en fonction des besoins.
Désormais, le responsable du test envoie un courrier aux clients et leur demande que toutes les zones d'impact seront affectées une fois les modifications nécessaires effectuées. Ainsi, le client aura une idée des fonctionnalités qui doivent être testées à nouveau. Et il enverra également un mail à l'équipe de développement pour savoir quels domaines de l'application seront affectés suite aux modifications et ajouts de nouvelles fonctionnalités.
De la même manière, le client envoie un mail à l’équipe de test pour obtenir une liste des zones d’impact. Par conséquent, le responsable du test collectera également la liste d'impact auprès du client, de l'équipe de développement et de l'équipe de test.
Ce Liste des impacts est envoyé à tous les ingénieurs de test qui consultent la liste et vérifient si leurs fonctionnalités sont modifiées et si oui, alors ils le font tests de régression régionaux . Les zones d'impact et les zones modifiées sont toutes testées par les ingénieurs respectifs. Chaque ingénieur de test teste uniquement les fonctionnalités qui auraient pu être affectées par la modification.
Le problème avec cette approche ci-dessus est que le responsable du test peut ne pas avoir une idée complète des zones d'impact car l'équipe de développement et le client n'ont peut-être pas autant de temps pour revenir sur ses e-mails.
Solution
Pour résoudre le problème ci-dessus, nous suivrons le processus ci-dessous :
Lorsqu'une nouvelle version est accompagnée des dernières fonctionnalités et corrections de bugs, l'équipe de test organisera une réunion au cours de laquelle elle discutera si ses fonctionnalités sont affectées par la modification ci-dessus. Par conséquent, ils feront un tour de Analyse d'impact et générer le Liste des impacts . Dans cette liste particulière, l'ingénieur de test essaie de délimiter les zones d'impact probables maximales, ce qui diminue également le risque d'obtenir des défauts.
Lorsqu'une nouvelle version arrive, l'équipe de test suivra la procédure ci-dessous :
- Ils effectueront des tests de fumée pour vérifier les fonctionnalités de base d'une application.
- Ensuite, ils testeront de nouvelles fonctionnalités.
- Après cela, ils vérifieront les fonctionnalités modifiées.
- Une fois qu'ils auront fini de vérifier les fonctionnalités modifiées, l'ingénieur de test testera à nouveau les bogues.
- Ensuite, ils vérifieront la zone d’impact en effectuant des tests de régression régionaux.
Inconvénient de l'utilisation des tests de régression unitaires et régionaux
Voici quelques-uns des inconvénients liés à l’utilisation des tests de régression unitaires et régionaux :
- Nous pouvons manquer certaines zones d'impact.
- Il est possible que nous identifiions la mauvaise zone d’impact.
Remarque : On peut dire que le travail majeur que nous effectuons sur les tests de régression régionaux nous amènera à obtenir plus de défauts. Mais si nous faisons le même travail sur les tests de régression complets, nous obtiendrons moins de défauts. Par conséquent, nous pouvons déterminer ici que l’amélioration de l’effort de test ne nous aidera pas à obtenir davantage de défauts.
3) Tests de régression complète [FRT]
Lors de la deuxième et de la troisième version du produit, le client demande l'ajout de 3 à 4 nouvelles fonctionnalités, et certains défauts doivent également être corrigés par rapport à la version précédente. Ensuite, l'équipe de test effectuera l'analyse d'impact et identifiera que la modification ci-dessus nous amènera à tester l'ensemble du produit.
On peut donc dire que tester le fonctionnalités modifiées et toutes les (anciennes) fonctionnalités restantes s'appelle le Tests de régression complets .
Quand effectuons-nous des tests de régression complète ?
Nous effectuerons le FRT lorsque nous aurons les conditions suivantes :
- Lorsque la modification se produit dans le fichier source du produit. Par exemple , JVM est le fichier racine de l'application JAVA, et si un changement doit se produire dans JVM, alors l'ensemble du programme JAVA sera testé.
- Lorsque nous devons effectuer un nombre n de changements.
Note:
Les tests de régression régionaux sont l'approche idéale des tests de régression, mais le problème est que nous pouvons manquer de nombreux défauts lors de l'exécution des tests de régression régionale.
Et ici, nous allons résoudre ce problème à l’aide de l’approche suivante :
- Lorsque la demande de test est soumise, l'ingénieur de test testera les 10 à 14 premiers cycles et effectuera le RRT .
- Puis pour le 15ème cycle, on fait FRT. Et encore une fois, pour le prochain cycle 10-15, nous faisons Tests de régression régionaux , et pour le 31ème cycle, on fait le test de régression complet , et nous continuerons ainsi.
- Mais pour les dix derniers cycles de la sortie, nous jouerons uniquement tests de régression complets .
Par conséquent, si nous suivons l’approche ci-dessus, nous pouvons obtenir davantage de défauts.
L'inconvénient de faire des tests de régression manuellement à plusieurs reprises :
- La productivité va diminuer.
- C'est un travail difficile à faire.
- Il n'y a pas de cohérence dans l'exécution des tests.
- Et le temps d’exécution des tests est également augmenté.
Par conséquent, nous opterons pour l’automatisation pour résoudre ces problèmes ; lorsque nous aurons le numéro n du cycle de test de régression, nous opterons pour le processus de test de régression automatisé .
Processus de test de régression automatisé
Généralement, nous optons pour l'automatisation chaque fois qu'il y a plusieurs versions ou plusieurs cycles de régression ou qu'il y a une tâche répétitive.
Le processus de test de régression automatisé peut être effectué selon les étapes suivantes :
Note 1:
Le processus de test de l'application à l'aide de certains outils est appelé test d'automatisation.
Supposons que si nous prenons un exemple d'un Module de connexion , puis comment nous pouvons effectuer les tests de régression.
Ici, la connexion peut se faire de deux manières, qui sont les suivantes :
Manuellement: En cela, nous effectuerons une régression seulement une et deux fois.
Automatisation: En cela, nous effectuerons l'automatisation plusieurs fois car nous devons écrire les scripts de test et effectuer l'exécution.
Remarque 2 : En temps réel, si nous avons rencontré des problèmes tels que :
| Problèmes | Manipuler par |
|---|---|
| Nouvelles fonctionnalités | Ingénieur de tests manuels |
| Fonctionnalités de test de régression | Ingénieur tests d'automatisation |
| Restant (110 fonctionnalité + Release#1) | Ingénieur de tests manuels |
Étape 1
Lorsque la nouvelle version démarre, nous n'optons pas pour l'automatisation car il n'y a pas de concept de test de régression et de cas de test de régression tel que nous l'avons compris dans le processus ci-dessus.
Étape 2
Lorsque la nouvelle version et l'amélioration démarrent, nous avons deux équipes, à savoir l'équipe manuelle et l'équipe d'automatisation.
Étape 3
MySQL change le type de colonne
L'équipe manuelle passera en revue les exigences, identifiera également la zone d'impact et remettra le suite de tests d'exigences à l'équipe d'automatisation.
Étape 4
Maintenant, l'équipe manuelle commence à travailler sur les nouvelles fonctionnalités, et l'équipe d'automatisation commencera à développer le script de test et commencera également à automatiser le scénario de test, ce qui signifie que les cas de test de régression seront convertis en script de test.
Étape 5
Avant de commencer à automatiser le scénario de test (l'équipe d'automatisation), ils analyseront également quels cas peuvent être automatisés ou non.
Étape 6
Sur la base de l'analyse, ils démarreront l'automatisation, c'est-à-dire convertiront tous les cas de test de régression en script de test.
Étape 7
Au cours de ce processus, ils bénéficieront de l'aide du Cas de régression parce qu'ils n'ont pas une connaissance des produits aussi bien que outil et le application .
Étape 8
Une fois le script de test prêt, ils lanceront l'exécution de ces scripts sur la nouvelle application [ancienne fonctionnalité]. Depuis, le script de test est écrit à l’aide de la fonctionnalité de régression ou de l’ancienne fonctionnalité.
Étape 9
Une fois l'exécution terminée, nous obtenons un statut différent comme Réussite/échec .
Étape 10
Si le statut est en échec, ce qui signifie qu'il doit être reconfirmé manuellement, et si le bug existe, il sera signalé au développeur concerné. Lorsque le développeur corrige ce bogue, le bogue doit être retesté avec la zone d'impact par l'ingénieur de test manuel, et le script doit également être réexécuté par l'ingénieur de test d'automatisation.
Étape 11
Ce processus se poursuit jusqu'à ce que toutes les nouvelles fonctionnalités et la fonctionnalité de régression soient adoptées.
Avantages de faire des tests de régression par les tests d'automatisation :
- Le script de test peut être réutilisé dans plusieurs versions.
- Même si le nombre de cas de test de régression augmente par version, nous n'avons pas besoin d'augmenter les ressources d'automatisation puisque certains cas de régression sont déjà automatisés à partir de la version précédente.
- C'est un processus permettant de gagner du temps car l'exécution est toujours plus rapide que la méthode manuelle.
Comment sélectionner les cas de test pour les tests de régression ?
Cela a été découvert lors d’une inspection de l’industrie. Les nombreux défauts signalés par le client étaient dus à des corrections de bugs de dernière minute. Créer des effets secondaires et donc sélectionner le scénario de test pour les tests de régression est un art, pas une tâche facile.
Le test de régression peut être effectué par :
java double en chaîne
- Un cas de test qui présente des défauts fréquents
- Des fonctionnalités plus visibles pour les utilisateurs.
- Les cas de test vérifient les fonctionnalités principales du produit.
- Tous les cas de tests d'intégration
- Tous les cas de tests complexes
- Cas de test de valeur limite
- Un échantillon de cas de tests réussis
- Échec des cas de test
Outils de tests de régression
Si le logiciel subit des modifications fréquentes, les coûts des tests de régression augmentent également. Dans ces cas, l’exécution manuelle des scénarios de test augmente le temps d’exécution des tests ainsi que les coûts. Dans ce cas, les tests d’automatisation sont le meilleur choix. La durée de l'automatisation dépend du nombre de cas de tests qui restent réutilisables pour des cycles de régression successifs.
Voici les outils essentiels utilisés pour les tests de régression :
Sélénium
Selenium est un outil open source. Cet outil est utilisé pour tester automatiquement une application Web. Pour les tests de régression basés sur un navigateur, le sélénium est utilisé. Sélénium utilisé pour le test de régression au niveau de l'interface utilisateur pour les applications Web.
Studio Ranorex
Automatisation des tests de régression tout-en-un pour les applications de bureau, Web et mobiles avec le pilote Web Selenium intégré. Ranorex Studio comprend un IDE complet ainsi que des outils pour l'automatisation sans code.
Professionnel des tests rapides (QTP)
QTP est un outil de test automatisé utilisé pour les tests de régression et fonctionnels. Il s'agit d'un outil basé sur des données et basé sur des mots clés. Il utilisait le langage VBScript pour l’automatisation. Si nous ouvrons l'outil QTP, nous voyons les trois boutons qui sont Enregistrez, jouez et arrêtez . Ces boutons permettent d'enregistrer chaque clic et chaque action effectuée sur le système informatique. Il enregistre les actions et les lit.
Testeur fonctionnel rationnel (RTF)
Rational Functional Tester est un outil Java utilisé pour automatiser les cas de test des applications logicielles. RTF utilisé pour automatiser les cas de tests de régression et s'intègre également au testeur fonctionnel rationnel.
Pour plus d'informations sur les outils de tests de régression et d'automatisation, consultez le lien ci-dessous :
https://www.javatpoint.com/automation-testing-tool
Tests de régression et gestion de la configuration
La gestion de la configuration dans les tests de régression devient impérative dans les environnements agiles, où un code est continuellement modifié. Pour garantir un test de régression valide, nous devons suivre les étapes :
- Les modifications ne sont pas autorisées dans le code pendant la phase de test de régression.
- Un scénario de test de régression ne doit pas être affecté par les modifications du développeur.
- La base de données utilisée pour les tests de régression doit être isolée ; les modifications ne sont pas autorisées dans la base de données.
Différences entre les nouveaux tests et les tests de régression
Re-tester les tests signifie tester à nouveau la fonctionnalité ou le bogue pour garantir que le code est corrigé. S’il n’est pas défini, les défauts n’ont pas besoin d’être rouverts. S’il est corrigé, le défaut est fermé.
Le re-test est un type de test effectué pour vérifier que les cas de test qui ont échoué lors de l'exécution finale ont réussi une fois les défauts réparés.
Les tests de régression signifie tester l'application logicielle lorsqu'elle subit une modification de code pour garantir que le nouveau code n'a pas affecté d'autres parties du logiciel.
Les tests de régression sont un type de test exécuté pour vérifier si un code n'a pas modifié la fonctionnalité existante de l'application.
Les différences entre les tests de re-test et les tests de régression sont les suivantes :
| Re-tester | Les tests de régression |
|---|---|
| Des tests supplémentaires sont effectués pour garantir que les cas de test qui ont échoué lors de l'exécution finale réussissent une fois les défauts corrigés. | Des tests de régression sont effectués pour confirmer si le changement de code n'a pas affecté les fonctionnalités existantes. |
| Le nouveau test fonctionne sur les corrections de défauts. | Le but des tests de régression est de garantir que les modifications du code n’affectent pas négativement les fonctionnalités existantes. |
| La vérification des défauts fait partie du nouveau test. | Les tests de régression n'incluent pas la vérification des défauts |
| La priorité du nouveau test est supérieure à celle du test de régression, elle est donc effectuée avant le test de régression. | En fonction du type de projet et de la disponibilité des ressources, les tests de régression peuvent être parallèles aux nouveaux tests. |
| Le re-test est un test planifié. | Les tests de régression sont des tests génériques. |
| Nous ne pouvons pas automatiser les cas de test pour les nouveaux tests. | Nous pouvons automatiser les tests de régression ; les tests manuels peuvent être coûteux et prendre du temps. |
| Les nouveaux tests concernent les cas de test ayant échoué. | Les tests de régression concernent les cas de test réussis. |
| En effectuant un nouveau test, assurez-vous que le défaut d'origine est corrigé. | Les tests de régression vérifient les effets secondaires inattendus. |
| Le nouveau test exécute les défauts avec les mêmes données et le même environnement avec une entrée différente avec une nouvelle version. | Les tests de régression surviennent lorsqu'une modification se produit ou que des changements deviennent obligatoires dans un projet existant. |
| Un nouveau test ne peut pas être effectué avant de commencer les tests. | Les tests de régression peuvent obtenir des cas de test à partir de la spécification fonctionnelle, des didacticiels et manuels utilisateur, ainsi que des rapports de défauts concernant le problème corrigé. |
Avantages des tests de régression
Les avantages des tests de régression sont :
- Les tests de régression augmentent la qualité du produit.
- Cela garantit que toute correction de bug ou toute modification n’affectera pas les fonctionnalités existantes du produit.
- Les outils d'automatisation peuvent être utilisés pour les tests de régression.
- Cela garantit que les problèmes résolus ne se reproduiront plus.
Inconvénients des tests de régression
Les tests de régression présentent plusieurs avantages, mais ils présentent également des inconvénients.
- Les tests de régression doivent être effectués pour de petites modifications dans le code, car même une légère modification dans le code peut créer des problèmes dans les fonctionnalités existantes.
- Si l’automatisation n’est pas utilisée dans le projet pour les tests, il sera long et fastidieux d’exécuter le test encore et encore.
Conclusion
Les tests de régression sont l’un des aspects essentiels car ils contribuent à fournir un produit de qualité qui permet aux organisations d’économiser du temps et de l’argent. Cela permet de fournir un produit de qualité en s'assurant que toute modification du code n'affecte pas les fonctionnalités existantes.
Pour automatiser les cas de tests de régression, plusieurs outils d'automatisation sont disponibles. Un outil doit avoir la capacité de mettre à jour le suite de tests car la combinaison de test de régression doit être mise à jour fréquemment.