Les tests de couverture s’appliquent aux codes source et objet

Le 26/04/2011 à 11:24  

La société AdaCore lance GnatCoverage, un outil de test de couverture pour les logiciels critiques. Il offre la particularité de pouvoir être exécuté aussi bien sur le code source (langage Ada ou C) que sur le code objet (le code compilé qui tourne sur la cible matérielle). Et comme ce nouvel outil est qualifié vis-à-vis de la norme DO-178B, il simplifie radicalement les procédures de certification.

Dans le monde des logiciels critiques, la notion de couverture consiste à vérifier que les cas de tests définis au début du projet permettent de couvrir l’intégralité du code qui a été développé. Ceci afin d’éviter que des lignes de code inutiles n’entraînent des défaillances inexpliquées du système. Dans le cadre de la norme DO-178B, les organismes de certification imposent différentes vérifications de couverture en fonction du niveau de criticité de chaque application. Ainsi, pour du code de niveau C, qui est le degré de criticité le plus bas, on demande uniquement de tester la couverture sur le code objet (le code compilé qui tourne sur la cible). A l’inverse, le niveau B exige des tests de couverture sur le code source (le code Ada ou C). Quant au niveau A, il requiert à la fois des tests de couverture du code source et des tests MC/DC (Modified Condition/Decision Coverage).
Le projet Couverture
« Il existait déjà des outils pour vérifier la couverture des tests, mais il s’agissait soit de logiciels libres pas adaptés aux contraintes de la DO-178B, soit d’outils propriétaires pas adaptés au langage Ada 2005, explique Cyrille Comar, directeur d’AdaCore. Nous voulions proposer un logiciel Open Source capable de s’intégrer dans un contexte de certification, c’est pourquoi nous avons lancé le projet Couverture (en partenariat avec OpenWide, Telecom PT et l’université Paris 6). Ce projet financé par le pôle de compétitivité mondial System@tic vient de s’achever, et nous sommes fiers d’annoncer la sortie de Gnatcoverage. »
L’objectif de ce vaste projet (160 hommes/mois sur 2 ans, un budget de 2,23 millions d’euros) était de mettre au point une technique d’analyse unique capable de couvrir tous les besoins, à savoir la couverture du code source, la couverture du code objet et la méthode MC/DC. Grâce à des études mathématiques très poussées, les ingénieurs d’AdaCore ont déterminé pour chaque type de fonctions ou d’algorithmes laquelle des deux méthodes (couverture ou MC/DC) était la plus adaptée. L’outil développé est donc capable de passer d’une méthode à l’autre en fonction des cas pour offrir une pertinence maximale. Pour Quentin Ochem, chef de projet chez AdaCore, les intérêts sont multiples. « D’abord, explique-t-il, l’outil est capable de mettre en évidence les zones du code qui ne satisfont pas les exigences de la norme, ce qui facilite le travail de débogage. Ensuite, il a la particularité de s’exécuter sur le code source “non instrumenté” (d’ordinaire, on devait modifier le code source pour exécuter les tests de couverture, et dans certains cas ce code instrumenté pouvait induire des erreurs). De plus, l’outil est capable de mettre en évidence les zones du code qui ne satisfont pas les exigences de la norme. Et surtout, Gnatcoverage est le seul outil de test qualifié vis-à-vis de la DO-178B niveau A, le niveau le plus critique. Du coup, les développeurs n’ont plus besoin d’expliquer en détails leur méthode de test. Le rapport délivré par Gnatcoverage suffit. »
Un émulateur pour accélérer les tests
Si ce nouvel outil est capable de tester indifféremment du code source ou du code objet, les tests de couverture sur le code objet restent néanmoins fastidieux. On sait que plus les problèmes sont détectés tard dans le cycle de développement, plus ils coûtent cher. Et comme les tests sur le code objet imposent d’avoir la cible à disposition, ils constituent une étape critique. La cible est en général peu accessible (elle coûte souvent cher et il n’est donc pas toujours possible que chaque développeur en ait une à disposition). Parfois même, elle n’est pas disponible, ce qui entraîne des retards. Enfin, reste le problème de la lenteur (faire tourner des jeux de tests sur la cible est toujours plus long que sur une machine de développement). «  C’est pour toutes ces raisons que nous avons mis au point un second outil baptisé Gnatemulator, poursuit Cyrille Comar. Comme son nom le suggère, il s’agit d’un émulateur qui simule l’exécution d’un processeur PowerPC (architecture très répandue en aéronautique) sur un PC standard à architecture x86. La traduction PowerPC vers x86 s’effectue à la volée. Du coup, les tests sont exécutés beaucoup plus rapidement, et ils peuvent démarrer beaucoup plus tôt. On peut donc faire des tests plus souvent, et cela s’intègre parfaitement dans le cadre des nouvelles méthodes de développement de type Agile ou Lean. »
Frédéric Parisot

 

 

La lecture de cet article est payante.
Pour le lire abonnez-vous ou connectez vous.

Dans la même rubrique

Copy link
Powered by Social Snap