Découvrez comment la plate-forme de qualité continue de Parasoft aide à contrôler et à gérer les environnements de test pour fournir des logiciels de haute qualité en toute confiance. Inscrivez-vous pour la démo >>

BLOG

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

Test de régression des systèmes embarqués Temps de lecture : 7 minutes

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.

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

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.

Optimisation des tests unitaires et de régression pour les systèmes embarqués

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 de version logicielle fiable.

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.

Donc, mettre en place une solution d'automatisation de test 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 verification 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 62304, Et 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.

Comment décider quoi tester de régression?

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 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 fait baisser la productivité de l'équipe. Cette incapacité à cibler les tests entrave une grande partie des 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 affecté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 builds, et avec cette efficacité améliorée, réaliser la promesse d'Agile. Cette forme d'exécution de test intelligente est appelée analyse d'impact de test (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.

Les tests Parasoft C / C ++, Jtest et dotTest fournissent un aperçu de l'impact des modifications logicielles et proposent des recommandations pour savoir où ajouter des tests et où exécuter plus de tests de régression. Consultez 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 permet d'économiser des coûts en aval importants. La détection des défauts plus tôt dans le SDLC réduit le coût de réparation 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 démarrer 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é
Écrit par

Ricardo Camacho

Responsable marketing produit technique pour les solutions de test embarquées de Parasoft. Ricardo possède une expertise dans le SDLC et l'automatisation des tests d'applications embarquées en temps réel, critiques pour la sûreté et la sécurité, et la conformité des logiciels aux normes de l'industrie.

Recevez les dernières nouvelles et ressources sur les tests de logiciels dans votre boîte de réception.