Webinaire en vedette : MISRA C++ 2023 : tout ce que vous devez savoir | Voir le séminaire

Test de régression des systèmes embarqués

Portrait de Ricardo Camacho, directeur de la conformité de la sûreté et de la sécurité
8 juin 2023
7 min lire

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.

Equipes de développement effectuer des tests de régression pour vérifier que les changements de code (corriger un bogue ou ajouter une nouvelle fonctionnalité) dans une application logicielle n'entraînent pas l'introduction d'un autre bogue ou la rupture d'une fonctionnalité du système existant.

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.

Qu'est-ce que le test de régression?

Une régression est « une tendance ou un changement vers un état inférieur ou moins que parfait », ce que nous essayons tous d'éviter lorsque nous développons des logiciels. Les tests de régression aident à trouver les défauts qui se glissent dans notre logiciel lorsque nous ajoutons de nouvelles fonctionnalités, corrigeons des bogues et apportons des modifications aux 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.

Pourquoi les tests de régression dans les systèmes embarqués sont-ils importants?

É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 n'impliquent pas seulement des cas de test unitaires. Les tests de régression des systèmes embarqués comprennent également l'exécution de cas de test d'intégration, de cas de test système, de cas de test de performance, de cas de test de résistance, etc. En fait, les développeurs doivent exécuter tous les cas de test créés précédemment pour garantir:

  • Aucune régression n'existe.
  • Construction d'une nouvelle version logicielle de haute qualité.

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. En les combinant avec des cas de test créés manuellement, on obtient un ensemble collectif: une suite de tests. Les développeurs et les testeurs exécutent la 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.

Une infographie montrant comment les nouveaux tests unitaires deviennent des tests de régression après validation et les tests de régression sont les tests accumulés au fil du temps.
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.

Test de régression dans le développement Agile

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.

Test de régression pour les périphériques embarqué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.

Mettre donc en place une solution d'automatisation des tests réutilisable et configurable qui peut passer de manière transparente et continue de l'exécution sur un hôte et/ou un système virtuel — et pour la vérification et validation sur le système cible - permet des économies significatives en termes de ressources, de temps et de coûts.

Les équipes de développement peuvent utiliser Parasoft pour exécuter des tests unitaires sur la plate-forme hôte, le simulateur de processeur cible ou la cible intégrée. Optimisé pour prendre un minimum de frais supplémentaires pour l'empreinte binaire ou les cycles de processus, le harnais de test de Parasoft C/C++test se présente sous la forme d'un code source. Cela signifie que les équipes peuvent personnaliser les modifications spécifiques à la plate-forme requises. Cela est nécessaire car les résultats des tests et la collecte de données de couverture de code à partir du système cible sont essentiels pour les systèmes critiques pour la sûreté et la sécurité et requis par les normes de processus telles que DO-178B / C, ISO 26262, IEC 62304et plus encore.

Infographie montrant 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 ++.
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, le test Parasoft C / C ++ offre des intégrations dédiées avec des IDE et des débogueurs intégrés qui rendent le processus d'exécution des cas de test fluide et automatisé. Les environnements IDE pris en charge incluent Eclipse, VS Code, Green Hills Multi, Wind River Workbench, IAR EW, ARM MDK, ARM DS-5, TI CCS, Visual Studio et bien d'autres. Voir tous les tests Parasoft C / C ++ Spécifications techniques.

Meilleures pratiques et techniques de test de régression

Au cœur des tests de régression se trouve l’héritage des cas de test de la version précédente du logiciel testé. Les tests de régression consistent à réutiliser des cas de test existants pour identifier une rechute dans la qualité du code entre chaque mise à jour logicielle et nouvelle version. Les meilleures pratiques consistent donc à application de l'automatisation pour gérer la vaste collection de cas de tests 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.

  • Identifiez les cas de test qui doivent être mis à jour.
  • Mettre à jour les scénarios de test pour tester les modifications de code.
  • Créez de nouveaux cas de test pour tester le nouveau code.
  • Supprimez les cas de test non pertinents.

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.

Comment décider quoi tester de régression?

Le principal défi des tests de régression consiste à déterminer quelles parties d'une application tester. Il n'est pas rare d'exécuter par défaut tous les tests de régression en cas de doute sur les impacts des modifications récentes du code. C'est cette approche « tout ou rien ». Cependant, pour les grands projets logiciels, cela devient une entreprise énorme et réduit la productivité de l'équipe. Cette incapacité à se concentrer sur les tests entrave de nombreux avantages des processus itératifs et continus - potentiellement exacerbés dans les logiciels embarqués où les cibles de test sont une ressource limitée.

Ce qu'il faut, c'est un moyen d'identifier les tests qui doivent être réexécutés 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é qui sont impactés par les modifications les plus récentes. En utilisant une combinaison des moteurs d'analyse de couverture propriétaires de Parasoft (Test C / C ++ pour C & C ++, Jtest pour Java, et pointTEST pour C #) et le Process Intelligence Engine (PIE) dans PAO Parasoft, les développeurs et les testeurs peuvent comprendre les changements dans la base de code entre les versions et, grâce à cette efficacité améliorée, réaliser la promesse d'Agile. Cette forme d'exécution intelligente des tests est appelée analyse d'impact des tests, parfois appelée test basé sur le changement.

Comprendre l'impact des changements de code sur les tests avec l'analyse d'impact des tests

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.

Capture d'écran du rapport de test basé sur le changement de Parasoft DTP montrant les zones du code qui ont été testées et non testées.
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.

Test de régression plus tôt et plus souvent

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?

  • Plus de tests pour augmenter la couverture du code.
  • Plus de cycles pour converger vers un meilleur produit.
  • Ou une combinaison des deux.

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.

Graphique animé. Jones, câpres. Mesure logicielle appliquée: analyse globale de la productivité et de la qualité. Affiche les défauts trouvés décalés vers la gauche.

Résumé

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.

Comment rationaliser les tests unitaires pour les systèmes embarqués et critiques pour la sécurité