Test de régression fonctionnelle avec SOAtest dans le cadre d'un processus d'intégration continue

L'intégration continue fusionne toutes les copies de travail des développeurs dans une ligne principale partagée. Ce processus rend le développement logiciel plus accessible, plus rapide et moins risqué pour les développeurs. Lisez cet article pour comprendre comment configurer SOAtest pour exécuter des tests de régression fonctionnelle dans le cadre de CI.

Qu'est-ce qu'un test de régression fonctionnelle ?

Une régression est définie comme « une tendance ou un glissement vers un état inférieur ou imparfait », ce que nous cherchons tous à éviter lors du développement de logiciels. Les tests de régression permettent de détecter les défauts qui s'infiltrent dans nos logiciels à mesure que nous ajoutons de nouvelles fonctionnalités, corrigeons des bugs ou apportons d'autres modifications à l'application.

Le test de régression est une méthode courante que la plupart des processus de développement de logiciels utilisent pour revérifier la fonctionnalité du logiciel après y avoir apporté des modifications. Ces tests déterminent si les nouvelles modifications affectent les fonctionnalités actuelles du logiciel. Bien sûr, de nouveaux tests sont nécessaires pour de nouvelles fonctionnalités. Les tests de régression permettent de s'assurer que ce qui est déjà testé reste fonctionnel.

Les tests de régression jouent un rôle essentiel dans l'intégration continue (CI) dans le développement de logiciels en garantissant que le code nouvellement intégré ne casse pas les fonctionnalités existantes ou n'introduit pas de régressions. Ces tests fournissent la rétroaction rapide essentielle dans CI en détectant les défauts dans le code nouvellement intégré afin qu'ils puissent être rapidement identifiés et résolus avant qu'ils n'affectent la stabilité du logiciel.

Test de régression fonctionnelle vs test fonctionnel

Les tests de régression Inclut les tests fonctionnels. En pratique, la plupart des tests fonctionnels se transforment progressivement en tests de régression. La principale différence réside dans le calendrier et l'objectif de ces tests.

Test fonctionel Ce test est généralement effectué pendant le développement, lors du développement, de l'implémentation et du test de nouvelles fonctionnalités. Il se concentre sur des fonctions, des fonctionnalités ou des cas d'utilisation spécifiques du logiciel afin de vérifier leur comportement attendu. Il peut impliquer diverses techniques de test, telles que les tests unitaires, les tests d'API, les tests d'interface utilisateur, etc.

Les tests de régression, en revanche, sont effectués pendant le développement dans le cadre du pipeline CI et/ou après des étapes de développement importantes, comme à la fin d'un sprint ou d'un cycle de publication. Les tests de régression sont automatisés autant que possible afin qu'ils puissent être reproductibles et efficaces, et ils incluent à la fois des tests fonctionnels et non fonctionnels. Plus à ce sujet ci-dessous.

Outils de test de régression fonctionnelle

Les tests de régression bénéficient considérablement de l'automatisation et, par conséquent, les outils conçus pour prendre en charge la pratique prennent également en charge l'automatisation de tous les types de tests. Ces outils permettent d'automatiser l'exécution des scénarios de test qui vérifient la fonctionnalité du logiciel, rassemblent et analysent les résultats et signalent tout problème de régression. Voici quelques classes d'outils d'automatisation logicielle couramment utilisées pour les tests de régression fonctionnelle.

• Test de l'interface utilisateur. Ces outils automatisent la test des interfaces utilisateur basé sur un paradigme d'enregistrement et de lecture. Les testeurs enregistrent les cas d'utilisation ou les flux de travail des utilisateurs et les outils reproduisent les mêmes actions dans l'interface utilisateur. Selenium, par exemple, est un outil d'automatisation open source populaire largement utilisé pour les tests d'applications Web. Il prend en charge plusieurs langages de programmation et fournit un cadre pour automatiser les interactions du navigateur.
• Tests d'API. Automatisation des tests au niveau de l'API nécessite des cas de test et des harnais pour les exécuter qui interagissent directement avec les API d'application sous-jacentes. Les tests à ce niveau présentent des avantages par rapport aux tests manuels et automatisés de l'interface utilisateur, car ils sont plus résistants aux modifications de l'interface utilisateur et testent la logique métier plus directement.
• Tests unitaires. Tests unitaires se fait au niveau du composant logiciel le plus bas, qui est généralement une méthode en C++ ou Java ou une fonction en C. Les tests unitaires fonctionnent en testant individuellement les fonctions de code et/ou les procédures dans un fichier source pour la sûreté, la sécurité et la robustesse. Au fur et à mesure que les tests unitaires sont exécutés, les valeurs de sortie des fonctions sont collectées et inspectées pour s'assurer qu'elles sont correctes, et les rapports peuvent être stockés à des fins d'audit ou de conformité. De nombreuses équipes de développement mesurent également la couverture du code pour exposer le code qui n'a pas été testé. Le fait de savoir que chaque unité de code a été testée et qu'elle est saine élimine les risques et contribue à garantir la livraison d'une application de qualité.
• Gestion des données de test. Des données de test appropriées doivent être fournies aux applications testées pendant le processus de test afin que les cas de test puissent valider la fonctionnalité de l'application, y compris les chemins d'accès utilisateur communs ou critiques et les cas particuliers. Lorsque des données de test réalistes sont utilisées, cela aide également à reproduire les conditions d'erreur et les défauts. Gestion des données de test (TDM) fournit un moyen de créer et de gérer des ensembles de données sûrs et appropriés que votre entreprise peut utiliser dans plusieurs équipes pour valider les fonctionnalités et les performances d'une application.
• Rapports et analyses. Après l'exécution des tests de régression, les résultats sont analysés pour fournir à la fois statut et résultats exploitables qui peuvent être consultés sur le Web, sur le bureau ou dans des rapports HTML statiques. Idéalement, les analyses sont présentées dans des tableaux de bord faciles à utiliser et personnalisables, composés de widgets très flexibles qui affichent clairement les risques au sein de votre base de code et fournissent une vue complète de l'état et de la qualité du projet.

Ces types d'outils mentionnés sont un sous-ensemble des nombreux outils différents qui peuvent être nécessaires pour valider complètement une application. Il est essentiel que ces outils fonctionnent ensemble de manière transparente afin de faciliter le pipeline CI/CD.

Atteignez la vélocité tout en protégeant votre application contre les régressions

CI est une pratique bien comprise et bien adoptée et une première étape nécessaire pour améliorer de manière significative la vitesse de livraison des applications. Il permet aux développeurs de pousser leurs modifications directement dans une branche principale du code source. Un seul développeur peut potentiellement apporter de nombreuses modifications à la branche principale au cours d'une même journée. Pour s'assurer que la branche principale est vierge, compilable et de qualité production, il est essentiel d'avoir des cas de test appropriés pour chaque modification, car elle sert de copie dorée du code source de l'application.

Voyons comment configurer Parasoft SOAtest pour exécuter des tests fonctionnels et des tests de régression dans le cadre d'un processus d'intégration continue. Nous allons passer en revue les étapes pour configurer Parasoft SOAtest avec Jenkins, une plate-forme d'automatisation populaire utilisant l'application de démonstration open source Parabank et la déployer à l'aide de Docker pour simplifier les choses.

Comment cela fonctionnera-t-il ?

Le diagramme ci-dessous montre le flux de travail décrit dans cet article. Suivez les étapes de gauche à droite.

1. Un développeur ou un testeur vérifiera ses cas de test dans un référentiel de contrôle de code source. Dans cet exemple, nous utiliserons GitHub.
2. Jenkins va extraire le référentiel de GitHub, qui contient le projet SOAtest appelé «Parabanque" qui contient nos cas de tests fonctionnels. Jenkins extraira également une image Docker appelée parasoft/parabanque depuis DockerHub. Cette image contient non seulement Parabank, mais également le serveur d'application et les dépendances nécessaires pour exécuter l'application.
3. Jenkins va créer une image Parabank (appelée « conteneur ») et configurer l'application testée (AUT) selon les spécificités de l'environnement de test.
4. Jenkins déclenchera ensuite Parasoft SOAtest pour exécuter des tests fonctionnels extraits de GitHub afin que nous puissions valider notre application Parabank et implémenter les corrections de bogues nécessaires.

Certes, ce n'est pas tout à fait dans l'esprit d'une véritable intégration continue puisque nous partons d'une image Docker pré-construite. Mais cela nous évite d'avoir à construire Parabank avec Maven et à installer et configurer Tomcat/Java.

Le diagramme ci-dessous montre un diagramme de CI plus réaliste et plus réel. Dès qu'un développeur vérifie le code source dans GitHub, nous voulons exécuter les tests de régression nécessaires et tout nouveau cas de test fonctionnel pour vérifier que l'application est toujours en bon état même après les modifications du développeur.

Un changement de code source dans GitHub déclenche automatiquement une construction dans Jenkins, et Jenkins lance une étape de construction Maven, qui exécute toute analyse de code statique et JUnit teste et construit notre application. Si tous les tests unitaires réussissent, l'application packagée, parabank.war, est déployée sur un serveur d'applications (dans ce cas, Tomcat) dans le cadre de l'étape de déploiement. SOAtest lance ensuite l'étape de test et exécute des tests de régression et des tests fonctionnels.

Ce n'est qu'après la réussite des tests unitaires et des cas de test de la boîte noire lors de l'exécution de SOAtest que les modifications initiales du développeur sont considérées comme bonnes.

Passons en revue les prérequis et les étapes pour configurer le processus dans le premier diagramme.

Configurer SOAtest & Jenkins

Pré-requis :

• Une machine capable d'exécuter Docker. Ce didacticiel utilise Windows, donc certaines des commandes de cet article peuvent avoir une syntaxe différente. Cette machine doit être connectée à Internet.
• Créez un fichier localsettings.properties quelque part sur votre machine. Copiez le contenu de ce exemple de fichier dans ça. Si vous avez une licence verrouillée par nœud, ajoutez-la à la ligne 5. Si vous utilisez un serveur de licences, définissez la ligne 6 sur true et ajoutez le nom d'hôte de votre serveur de licences à la ligne 3. Nous aurons besoin du chemin d'accès à ce fichier plus tard.
• Jenkins 2.387.1 ou plus récent installé sur la même machine.
• Parasoft SOAtest 2022.1 ou plus récent installé et sur le PATH pour invoquer soatestcli depuis n'importe quel répertoire.
• Docker installé et sur le PATH de la même machine.
• Git installé.

Étapes

1. Connectez-vous à Jenkins dans votre navigateur Web. Jenkins est généralement déployé sur une URL telle que http:// :8080/jenkins.

2. Nous allons commencer par installer quelques plugins Jenkins. Sélectionnez Gérer Jenkins sur la gauche, puis Gérer les plugins dans le nouveau menu qui apparaît.

3. Sous l'onglet Disponible, sélectionnez et installez le plug-in Parasoft Findings.
4. Sélectionnez Installer sans redémarrage, puis, sur la page Installation, cochez la case Redémarrer Jenkins lorsque l'installation est terminée et qu'aucune tâche n'est en cours d'exécution.
5. Revenez au menu principal de Jenkins à partir de l'étape 1. Sur la gauche, sélectionnez Nouvel élément.

6. Indiquez le nom Parabank Deploy and Test et sélectionnez Freestyle project, puis OK.

7. Dans le menu de configuration qui apparaît, faites défiler jusqu'à Gestion du code source et sélectionnez Git. Ajoutez cette URL au champ URL du référentiel : https://github.com/sdebrosse/soatest-automation-example.git. Tous les autres champs peuvent conserver leurs valeurs par défaut.

8. Faites défiler vers le bas de la page et sous Générer, ajoutez une étape de génération de la commande par lots Exécuter Windows. Si vous utilisez Linux, sélectionnez plutôt Exécuter le shell.

9. Copiez le contenu du script ici et collez-le dans le nouveau champ d'étape de construction. Vous devez modifier les valeurs des deux variables en haut du script pour refléter le chemin d'accès à votre propre fichier localsettings.properties et l'endroit où vous souhaitez créer un espace de travail temporaire. SOAtest créera cet espace de travail pendant le processus de test. Les commentaires dans le script expliquent ce qui se passe sur chaque ligne.

10. C'est ça. Maintenant, nous sommes prêts à exécuter notre travail Jenkins ! Assurez-vous d'abord de fermer toutes les instances ouvertes de SOAtest. Sélectionnez ensuite Enregistrer en bas du menu de configuration et cliquez sur Construire maintenant à gauche.

11. Vous pouvez cliquer sur la tâche en cours d'exécution à gauche, puis afficher la sortie de la console en direct.

12. Les journaux afficheront le statut SUCCESS à la fin de votre travail si tout a fonctionné correctement. Cela signifie que vous avez réussi à extraire un projet de test SOAtest de GitHub, déployé un conteneur Docker avec Parabank et exécuté des tests sur cette application Parabank. À la fin du processus, nous avons automatiquement tué le conteneur Parabank et supprimé notre temp_workspace pour nettoyer l'environnement de construction. Mais vous avez peut-être remarqué en consultant les journaux que nous avons eu des échecs de test. Oui, quelques-uns de nos tests contre Parabank ont ​​échoué.

Si nous voulons que notre build Jenkins échoue en raison d'échecs de test SOAtest, nous ajoutons l'indicateur -fail lorsque nous invoquons soatestcli. Comme ça:

soatestcli.exe -fail -data %TEMP_WORKSPACE_PATH% -resource /Parabank -config "builtin://Demo Configuration" -localsettings %LOCALSETTINGS_PATH%

Si vous ouvrez le test dans l'interface utilisateur SOAtest Desktop, vous découvrirez que cet échec de test est principalement un problème de données de test et de configuration de l'environnement de test. Le service de traitement des prêts a refusé un prêt qu'il aurait dû approuver.

Synthèse

La mise en œuvre de l'intégration continue dans votre processus de développement logiciel augmente considérablement la vitesse de livraison des applications. Des solutions automatisées comme SOAtest offrent une stratégie de test de régression évolutive et efficace avec la possibilité d'exécuter des cas de test qui vérifient la fonctionnalité du logiciel, rassemblent et analysent les résultats et signalent tout problème de régression. Cette combinaison aide les équipes à atteindre une plus grande vitesse de publication, à améliorer la productivité des tests et à garantir une couverture de test élevée.