Analyse de couverture de code pour les projets C ++ embarqués [fermé]

Question

J'ai récemment commencé à travailler sur un très grand projet C ++ qui, après avoir terminé 90% de la mise en œuvre, a déterminé qu'ils devaient démontrer une couverture de 100% des branches au cours des tests. Le projet est hébergé sur une plate-forme intégrée (Green Hills Integrity). Je recherche des suggestions et des expériences d'autres personnes sur StackOverflow qui ont utilisé des produits de couverture de code dans des environnements similaires. Les commentaires positifs et négatifs sur ces types d’outils m'intéressent.

Answer 1

Couverture de 100% des succursales? C'est tout à fait l'exigence, d'autant plus que certaines branches (par défaut dans les instructions case des machines à états, par exemple) ne devraient pas pouvoir être exécutées. Je suppose qu'il y a quelques exceptions, et s'il n'y en a pas, vous aurez peut-être besoin de comprendre ce que les tests de couverture peuvent et ne peuvent pas accomplir avant de commencer - sinon vous finirez par vous arracher les cheveux, ou pire - donner des données incorrectes.

La plupart des tests de couverture des systèmes intégrés sont en réalité effectués sur des PC. Le code est porté, certains aspects du microcontrôleur sont émulés dans le logiciel et Bullseye ou une autre couverture de code similaire. l'utilitaire est exécuté. La raison en est que trop de microcontrôleurs et de compilateurs / débogueurs / environnements de test permettent de développer des outils de couverture de code pour chacun d’entre eux.

Lorsque des outils de couverture de code existent pour une plate-forme intégrée spécifique, ils ne sont pas aussi puissants, configurables, faciles à utiliser et sans bogues que ceux développés pour la plate-forme PC. Les processeurs ne disposent pas souvent de la fonction de trace (sans matériel d'émulation haut de gamme) nécessaire pour couvrir correctement le code sans insérer de code de débogage supplémentaire dans votre micrologiciel, ce qui entraîne des conséquences et des effets secondaires difficiles à contrôler, notamment en ce qui concerne les problèmes de synchronisation. systèmes temps réel.

Transférer du code n’est pas très difficile tant que vous pouvez résumer le code spécifique au matériel (et puisque vous utilisez correctement le C ++, cela devrait être facile, non? ;-D). Le problème le plus important que vous rencontrerez concerne les types, qui bien que mieux spécifiés en C ++ qu’ils ne l’étaient en C posent néanmoins quelques problèmes. Assurez-vous que vous utilisez une configuration types.h ou similaire pour indiquer spécifiquement au compilateur le type exact de chaque type utilisé et la manière dont il doit être interprété.

Après cela, vous pouvez aller en ville pour tester la logique de base sur le PC. Vous pouvez même tester les pilotes de matériel de bas niveau si vous souhaitez développer l’émulation logicielle requise à cet effet, même si les problèmes de minutage peuvent poser quelques problèmes.

Des outils de test logiciel tels que MxVDev effectuent une grande partie de l'émulation du microcontrôleur et vous aident à résoudre les problèmes de minutage. mais vous aurez toujours un peu de travail, même avec une telle aide.

Si vous devez le faire sur le système lui-même, vous devrez acheter un émulateur pour le processeur avec une capacité de couverture - une proposition peu coûteuse (de nombreux émulateurs coûtent plus de 30 000 USD pour l'ensemble complet des outils et du matériel d'émulation). , mais c’est l’un des nombreux outils utilisés dans des environnements très fiables tels que les industries de l’automobile et de l’aérospatiale.

-Adam

Avertissement: je travaille pour la société qui produit MxVDev.

Answer 2

Nous avons utilisé Cantata et vectorcast dans le passé pour les tests unitaires et la couverture de code. Nous utilisons également les outils Greenhills et ces deux outils fonctionnent avec les outils de développement Greenhills. Nous effectuons la plupart de nos tests sur le simulateur PPC et nous ne faisons que procéder à des tests qui reposent sur du matériel sur le matériel cible via un module JTAG. Canatata et Vector casting sont très similaires. Catata est légèrement plus facile à utiliser et offre un peu plus de fonctionnalités, mais les petits suppléments font une grande différence dans l'expérience utilisateur.

En règle générale, si vous souhaitez atteindre un niveau élevé de couverture de branche, vous devez concevoir votre code de manière à ce qu'il puisse être testé. Plus vous testez, plus vous en apprendrez sur l'écriture de code testable.

Nous avons également essayé les tests sur PC, alors que les tests intégrés nous posaient des problèmes d’endianess mais c’est seulement un problème au niveau matériel.

De plus, ces outils sont certifiés selon la norme RTCA / DO-178B.

Answer 3

Comme avec Adam, nous portons notre code intégré sur un harnais basé sur un PC et effectuons l'essentiel de la couverture et du profilage. J'ai utilisé AutomatedQA AQTime et Compuwares DevPartner, deux bons produits,

Si vous deviez utiliser ob-board de couverture, vous auriez besoin d'un profileur de couverture créant une version instrumentée de la source. Il existe à la fois des outils commerciaux et à code source ouvert pour le faire, mais IMO ajoute beaucoup de travail pour un gain minime.

La couverture à 100% est ambitieuse, car vous aurez besoin de beaucoup d'injection de fautes pour entrer dans tous vos gestionnaires d'erreur et de gestion des exceptions. OMI, cela serait aussi plus facile à faire avec un harnais qu’à bord.

Il est également utile de signaler à quiconque a demandé une couverture de code à 100% que une couverture de code à 100% n'équivaut en aucune manière à une couverture de test à 100% . Considérons par exemple la fonction suivante;

int div(int a, int b)
{
return (a/b);
}

La couverture de code à 100% ne nécessite que l’appel de cette fonction une fois, la couverture de test à 100% nécessitant bien plus d’appels. Ma propre stratégie de test consiste à développer des cas de test automatisés pour me donner un niveau acceptable de couverture de test et à utiliser un outil de couverture de code uniquement pour vous aider à rechercher des zones non testées. Dans une certaine mesure, cela dépend de votre budget de test. Pour moi, une couverture de code à 100% est très chère pour ce qu'elle livre.

Answer 4

Voir Couverture de test SD C ++ . Il s’agit d’une famille d’outils de couverture de tests (de branches) pour une variété de dialectes C ++ (ANSI, GNU, MS ...) qui fonctionne bien même dans le matériel de systèmes embarqués, du fait de son faible encombrement et de sa moyen d’exporter les données de couverture de test collectées. L’affichage de la couverture de l’interface graphique, qui ne dépend pas de votre matériel intégré, produira également un résumé complet du rapport de couverture.

[Je suis l'un des principaux fournisseurs de ces outils.]