Découvrez GoogleTest certifié TÜV avec Agentic AI pour les tests C/C++ !
Plus de détails »
Blog Parasoft
Les changements de code peuvent avoir beaucoup d'impact sur votre logiciel. Les tests de régression aident les ingénieurs logiciels à tester les changements de code. Ici, nous découvrons comment le moteur d'analyse de Parasoft peut vous aider à mieux comprendre l'impact des modifications apportées à votre logiciel.
Aller à la section
Les équipes de développement effectuent des tests de régression sur les systèmes embarqués afin de vérifier que les modifications de code (correction d'un bug ou ajout de nouvelles fonctionnalités) dans une application logicielle n'entraînent pas l'introduction d'un autre bug ou la rupture des fonctionnalités existantes du système.
Pour de nombreux systèmes embarqués, sinon pour la plupart, les équipes effectuent des tests de régression à la fin du cycle de vie pour déterminer la stabilité de chaque version du logiciel. Il s'agit d'un processus itératif qui se poursuit jusqu'à ce que le projet atteigne la fin du développement ou la fin de la maintenance.
Dans d'autres flux de travail, les tests de régression sont une activité qui est la réalité quotidienne des développeurs. En fait, on peut affirmer que dans les processus itératifs et Agiles, la plupart des tests sont des tests de régression. Avant d'aller plus loin, regardons ce que sont les tests de régression et pourquoi ils occupent une place si importante dans les pratiques de développement logiciel.
Une régression est 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 lorsque nous ajoutons de nouvelles fonctionnalités, corrigeons des bugs et modifions les cas de test eux-mêmes.
Dans le cadre de la plupart des processus de développement logiciel, les développeurs effectuent des tests de régression après avoir apporté des modifications au logiciel. Ces tests déterminent si les nouvelles modifications ont eu un impact sur le fonctionnement actuel du logiciel.
Les tests de régression sont nécessaires, bien sûr, mais ils indiquent seulement que les modifications récentes du code n'ont pas provoqué l'échec des tests. Rien ne garantit que les changements fonctionnent eux-mêmes. De plus, la nature des changements qui motivent la nécessité de faire des tests de régression peut aller au-delà de l'application actuelle et inclure des changements dans le matériel, le système d'exploitation et l'environnement d'exploitation.
Étant donné que les systèmes embarqués ont tendance à avoir des contraintes critiques en matière de sûreté et de sécurité, les équipes de développement testent le système ou le sous-système à la recherche de régressions. Le test se produit sans doute à la fin de chaque cycle de vie itératif du système ou du sous-système. Cela signifie que tous les cas de test unitaires qui ont été définis pour un système logiciel ou une version de sous-système précédente, ainsi que les nouveaux cas de test unitaires qui ont été ajoutés pour vérifier la nouvelle fonctionnalité, doivent être exécutés afin d'exposer les régressions dans le logiciel.
Si un cas de test unitaire précédent a réussi et échoue maintenant, une régression potentielle peut avoir été identifiée. Une nouvelle fonctionnalité pourrait provoquer l'échec. Si tel est le cas, alors le scénario de test devra peut-être être mis à jour en tenant compte des changements des valeurs d'entrée et de sortie.
Il est également crucial de comprendre que les tests de régression ne se limitent pas aux tests unitaires. Les tests de régression des systèmes embarqués incluent aussi l'exécution de tests d'intégration, de tests système, de tests de performance, de tests de charge, etc. En réalité, les développeurs doivent exécuter tous les tests préalablement créés afin de garantir :
Les deux sont essentiels car chaque nouveau système logiciel ou nouvelle version de sous-système est construit ou développé sur sa version précédente. Si vous n'avez pas de base solide, tout peut s'effondrer.
Parasoft C/C++test peut générer automatiquement des cas de test. Leur combinaison avec des cas de test créés manuellement permet de constituer un ensemble complet : une suite de tests. Les développeurs et les testeurs exécutent cette suite de tests pour identifier les défauts de l’application.
Le test Parasoft C / C ++ capture les résultats du test et identifie les échecs à analyser et à corriger. Après ce cycle initial, les équipes peuvent réutiliser les cas de test existants ou la suite de tests pour les tests de régression.
Chaque nouveau test unitaire, une fois validé, devient un futur test de régression. Les tests de régression sont des tests cumulés au fil du temps.
Il est probablement évident que les mises à jour et les modifications du logiciel doivent être testées. En ce sens, les tests de régression sont une étape évidente dans le processus de développement. Dans le développement de logiciels modernes avec des processus Agile et une intégration et un déploiement continus, les tests de régression deviennent une étape critique dans chaque cycle.
Au fur et à mesure que le logiciel se développe, la suite de tests de régression évolue également. Au fur et à mesure que la suite se développe, le temps d'exécution et de débogage augmente et souvent le goulot d'étranglement dans le pipeline. Il est difficile d'avoir un développement Agile et un pipeline DevOps rationalisé sans tests de régression ciblés et rationalisés.
Travailler sur des systèmes embarqués ajoute une autre dimension aux tests, car il est souvent préférable ou nécessaire d'effectuer des tests sur le matériel cible. Les tests de régression peuvent être plus difficiles en raison de la complexité du lancement et de l'observation des tests sur des cibles intégrées. Ajoutez à cela l'accès limité au matériel cible dont disposent les équipes logicielles en raison du coût élevé de ces systèmes cibles.
Ainsi, la mise en place d'une solution d'automatisation des tests réutilisable et configurable, capable de passer de manière transparente et continue de l'exécution sur un système hôte et/ou virtuel à la vérification et à la validation sur le système cible, permet de réaliser des économies importantes en ressources, en temps et en coûts.
Les équipes de développement peuvent utiliser Parasoft pour exécuter des tests unitaires sur la plateforme hôte, le simulateur de processeur cible ou le système embarqué. Optimisé pour minimiser l'impact sur l'empreinte binaire et les cycles de traitement, le framework de test Parasoft C/C++test est fourni sous forme de code source. Les équipes peuvent ainsi l'adapter aux spécificités de chaque plateforme. Cette personnalisation est essentielle pour les systèmes critiques en matière de sécurité et de sûreté, car la collecte des résultats de test et des données de couverture de code du système cible est requise par les normes de processus telles que DO-178B /C, ISO 26262 , IEC 62304 , etc.
Une vue de haut niveau du déploiement, de l'exécution et de l'observation des tests d'hôte à cible dans le test Parasoft C / C ++.
De plus, Parasoft C/C++test propose des intégrations dédiées avec les environnements de développement intégrés (IDE) et les débogueurs embarqués, simplifiant et automatisant ainsi l'exécution des cas de test. Parmi les IDE compatibles figurent Eclipse, VS Code, Green Hills Multi, Wind River Workbench, IAR EW, ARM MDK, ARM DS-5, TI CCS, Visual Studio et bien d'autres. Consultez l'ensemble des spécifications techniques de Parasoft C/C++test.
Au cœur des tests de régression se trouve l'héritage des cas de test de la version logicielle précédente. Ces tests consistent à réutiliser ces cas de test existants afin d'identifier toute dégradation de la qualité du code entre chaque mise à jour logicielle et chaque nouvelle version. Par conséquent, les bonnes pratiques consistent à automatiser la gestion de ce vaste ensemble de cas de test de régression.
Pour garantir une suite de tests solide pour chaque test de régression entrepris, les équipes doivent effectuer les tâches suivantes.
Parce qu'il peut y avoir des milliers de cas de test, les équipes d'assurance qualité voudront automatiser la gestion des tests de régression. Les organisations voudront adopter une solution qui identifie automatiquement les cas de test qui doivent être mis à jour en raison de modifications logicielles. Les tests de base des modifications pour les solutions de test Java, C# et VB.Net sont expliqués ci-dessous. Des solutions telles que Parasoft accélèrent les modifications de la logique de cas de test existante, y compris le remplacement et la gestion des variations des valeurs de test d'entrée et de sortie.
Pour le code nouvellement ajouté, de nouveaux cas de test devront être créés. Parasoft permet la génération automatisée de cas de test unitaire. De plus, une interface graphique permet d'accélérer la création manuelle de cas de test. Pour le code supprimé, n'oubliez pas de supprimer tous les tests non pertinents correspondants.
Le principal défi des tests de régression est de déterminer les parties d'une application à tester. Il n'est pas rare d'exécuter tous les tests de régression par défaut en cas de doute sur l'impact des récentes modifications de code. C'est une approche du « tout ou rien ». Cependant, pour les grands projets logiciels, cela représente une tâche colossale et nuit à la productivité de l'équipe. Cette incapacité à cibler les tests compromet de nombreux avantages des processus itératifs et continus, potentiellement exacerbés dans les logiciels embarqués où les cibles de test constituent une ressource limitée.
Il est nécessaire d'identifier les tests à réexécuter et de concentrer les efforts de test (tests unitaires, tests fonctionnels automatisés et tests manuels) sur la validation des fonctionnalités et du code associé impactés par les modifications les plus récentes. Grâce à la combinaison des moteurs d'analyse de couverture propriétaires de Parasoft ( C/C++test pour C et C++, Jtest pour Java et dotTEST pour C#) et du moteur d'intelligence des processus (PIE) intégré à Parasoft DTP , les développeurs et les testeurs peuvent comprendre les modifications apportées au code entre les versions et, grâce à cette efficacité accrue, concrétiser les promesses de l'agilité. Cette forme d'exécution intelligente des tests est appelée analyse d'impact des tests, parfois désignée sous le terme de tests basés sur les modifications.
L'analyse d'impact des tests utilise les données collectées pendant les exécutions de tests et les modifications de code entre les versions pour déterminer quels fichiers ont été modifiés et quels tests spécifiques ont touché ces fichiers. Le moteur d'analyse de Parasoft peut analyser le delta entre deux builds et identifier le sous-ensemble de tests de régression à exécuter. Il comprend également les dépendances sur les unités modifiées pour déterminer quel effet d'entraînement les modifications apportées aux autres unités.
Parasoft Jtest et dotTest fournissent des informations sur l'impact des modifications logicielles et proposent des recommandations sur les endroits où ajouter des tests et où exécuter davantage de tests de régression. Voir l'exemple de rapport de test basé sur les modifications ci-dessous.
Un exemple de rapport de test basé sur le changement de Parasoft DTP. Il montre les zones du code qui sont testées et non testées.
La rationalisation des tests de régression avec l'analyse d'impact des tests réduit considérablement la charge globale des tests. Il permet aux développeurs et aux testeurs de se concentrer uniquement sur le code et les tests impactés. Les resultats?
Les tests de régression ne sont plus un fardeau mais une étape clé dans l'amélioration de la qualité et de la sécurité des produits. Il génère des métriques pour aider à mesurer la qualité, la sécurité et les progrès globaux.
Grâce à la prise en charge d'outils de pointe et aux tests basés sur des cibles, il est également possible de démarrer les tests de régression dès que les développeurs créent du code. Chaque nouveau test unitaire devient un test de régression au fil du temps et les développeurs peuvent immédiatement tirer parti des tests basés sur le changement.
Faire des tests de régression tôt (en les déplaçant vers la gauche de la chronologie de développement) signifie une détection plus précoce des défauts. Le déplacement vers la gauche permet d'économiser du temps et de l'argent immédiatement. Cela est encore plus rentable plus tard dans le cycle de vie du logiciel.
Ne sous-estimez pas ce gain. Cela peut réduire considérablement les coûts en aval. La détection précoce des défauts dans le SDLC réduit le coût de leur résolution et réduit l'impact sur les activités en aval. Consultez le diagramme ci-dessous.
Les tests de régression sont une activité essentielle dans les tests de logiciels embarqués. Chaque fonctionnalité, correction de bogue ou modification de configuration nouvellement ajoutée nécessite des tests pour confirmer ce qui fonctionne déjà et continue de fonctionner. Cependant, à mesure qu'un projet se développe et que la complexité du logiciel augmente, le nombre de tests de régression augmente également.
Finalement, l'automatisation des tests devient nécessaire pour aider à gérer le fardeau des tests. Les nouvelles technologies telles que l'exécution intelligente des tests facilitent les tests de régression. Cela pousse les développeurs et les testeurs à se concentrer sur des tests qui testent spécifiquement le code modifié et impacté.
La combinaison d'améliorations de processus comme Agile, CI/CD et DevOps avec l'automatisation des tests logiciels permet de commencer les tests de régression presque dès que le code est écrit. Il déplace efficacement les tests vers la gauche et détecte les bogues plus tôt lorsqu'ils sont moins chers et plus faciles à corriger.
