Couverture ElectroniqueS n°127

Même dans les systèmes embarqués, les logiciels doivent être testés suffisamment en avance pour assurer le lancement du produit sur le marché. Le volume des ressources de cibles embarquées étant limité, la mémoire et le processeur peuvent facilement atteindre leurs limites. Avec un peu de créativité, il est néanmoins possible de mesurer et de prouver la couverture de test. T ous les acteurs s'accordent sur le fait que les exigences pour les systèmes embarqués augmentent de plus en plus. Surtout, en ce qui concerne l'Internet des objets connectés (IoT), les systèmes embarqués y prennent une place importante, voire critique. Selon une étude de juin 2018 de la société de conseil IDC, le marché des technologies de l'IoT va croître au rythme de 13% par an, pour atteindre un chiffre d'affaires global de 1,2 milliard de dollars d'ici 2020. Les systèmes embarqués devenant une part de plus en plus importante de l'activité de beaucoup d'entreprises, la sécurité de ces systèmes deviendra, elle aussi, une priorité, comme elle l'est déjà aujourd'hui dans le développement de ces systèmes dans d'autres domaines. Figure 1.-Diagramme de la couverture des instructions La couverture des instructions indique combien d'instructions ont été exécutées. Dans cet exemple, six des sept instructions ont été exécutées, la couverture des instructions atteignant donc 85%. Que ce soit pour les équipements médicaux, l'aéronautique, l'automobile ou l'industrie ferroviaire, des normes strictes régissent le test et la certification des systèmes embarqués, pour que ces derniers soient mis sur le marché. En dehors de ces branches traditionnellement très axées sur la sécurité, il existe manifestement un énorme retard à combler. Selon un sondage de Gartner réalisé au printemps 2018, près de 20% des entreprises interrogées ont été victimes d'une attaque informatique via un objet connecté. L'une des raisons avancées par Gartner est la lente évolution des normes de sécurité appliquées à l'IoT ; on manque encore de «Security-by-Design». Afin de développer des systèmes embarqués sûrs, les tests sont un levier fondamental. Ce n'est pas sans raison que les normes de développement de logiciels critiques pour la sécurité des biens et des personnes incluent des exigences très précises en termes de méthodes et de couverture des tests. En règle générale, les normes, telles que la DO-178C en aéronautique ou l'ISO 26262 dans l'industrie automobile, requièrent la couverture des instructions et des chemins ( Statement Coverage et Path Coverage ). La technique de couverture de condition/décision modi-fiée ( Modified Condition/Decision Coverage ou MC/DC) est également souvent requise. KLAUS LAMBERTZ (VERIFYSOFT TECHNOLOGY) Avant d'être l'un des fondateurs et le CEO de Verifysoft Technology en 2003, Klaus Lambertz a occupé différents postes commerciaux et de direction au sein de fournisseurs spécialisés dans le logiciel (responsable des grands comptes chez Testlight de 2001 à 2003 et responsable de bureau chez Parasoft de 1999 à 2001). La couverture MC/DC a le niveau de test le plus élevé Fondamentalement, plus les exigences de sécurité d'un logiciel sont élevées, plus la couverture de test requise doit être élevée. Cependant, tous les niveaux de couverture de code n'ont pas forcément de sens dans chaque scénario et peuvent fournir aussi des informations différentes. Par exemple, la couverture des fonctions ( Function Coverage ) ignore complètement le fonctionnement interne du logiciel, son utilité est donc relativement faible. La couverture des instructions, elle, recherche quelles instructions sont exécutées lors des tests. Elle permet donc d'identifier le code mort et les instructions pour lesquelles il n'y a pas encore de test. En ce qui concerne la couverture des points de test ( Condition Coverage ), elle vérifie si toutes les conditions ont été exécutées et vérifiées au moins une fois. Cette méthode est donc plus complète que la couverture des instructions et est une couverture minimale atteignable exigeant un minimum de tests à un coût raisonnable. Enfin, la couverture de type MC/DC est le niveau de couverture de test le plus élevé requis par les normes. L'évaluation de toutes les combinaisons possibles des conditions demandant un travail phéno-ménal, la technique cherche à minimiser l´effort de test et va observer chaque condition atomique d'une condition complexe. Pour chacune de ces conditions atomiques, la méthode MC/DC va tester une paire d'entrées, qui fait changer le résultat final de la condition complexe sans que les autres conditions atomiques ne changent. Pour analyser la couverture du code, on a recours à des Code Coverage Analysers , qui vont compléter le code avec des compteurs en fonction des niveaux de test souhaités, avant de les transférer au compilateur. Ce processus s'appelle «instrumenter le code». Il existe des outils d'une grande simplicité pour le faire, comme, par exemple, le testeur de couverture GNU Gcov. En utilisant l'option «-ftest-cove-rage», le code peut être instrumenté pour déterminer combien de fois chaque ligne de code a été exécutée; l'option «-fprofile-arcs»orchestre les branches. Cet outil est parfaitement adapté pour faire ses premières expériences dans le domaine de la couverture de code, ou alors pour de petits projets. Outre le manque de niveaux de couverture de test avancés, nécessaires pour des besoins plus importants, l'inconvénient de cet outil réside dans le traitement et l'interprétation des informations obtenues. Ici, les outils commerciaux sont clairement supérieurs. Figure 2.-Rapport de couverture de code par Testwell CTC++ Au cours de la fonction «lights», cinq des six instructions ont été exécutées. La couverture des instructions (Test Effectiveness Ratio ou TER) est donc de 83%. La couverture structurelle, ici, une couverture condition/décision modifiée (MC/DC), est de 75%. L'instrumentation étend le code Les solutions professionnelles fonctionnent sur le même principe de base que Gcov, en permettant d'instrumenter le code. Les compteurs sont, de manière générale, stockés sous forme de tableaux globaux. Quand et où ces compteurs seront modifiés dépendra du niveau de couverture configuré. L'exemple suivant d'une boucle «while» en C montre quelle est la conséquence de l'instrumentation : while (! b 0) { r a % b; a b; b r; } result a; Suite à l'instrumentation, réalisée dans ce cas par l'outil de couverture de code Testwell CTC++, on obtient la structure suivante : while (((! b 0) ? (ctc_t++, 1) : (ctc_f++, 0))) { r a % b; a b; b r; } result a; Comme on le constate, l'instrumentation fait grossir le code. Comme les tableaux requis se trouvent dans la mémoire des données, il faut donc plus de mémoire dans la Ram, mais aussi dans la Rom. L'instrumentation va également influencer les temps d'exécution. Dans des applications sur serveur ou ordinateur de bureau, il est possible de négliger ces effets, mais dans les systèmes embarqués, il n'est souvent pas possible de le faire, les ressources étant définies au plus juste pour des raisons de coût. Il convient alors de veiller à utiliser un analyseur de couverture de code avec un impact d'instrumentation faible, car sinon les compteurs dépassent rapidement les limites de la mémoire disponible. Cela est particulièrement vrai lorsque des niveaux de couverture de test très exigeants, comme la méthode MC/DC, sont requis. Si l'outil de couverture de code a tout de même un impact trop élevé sur la Ram, il est possible de ne faire qu'une instrumentation partielle, au cours de laquelle de petits bouts du programme sont testés les uns après les autres. Les tests sont alors exécutés successivement, et les données récoltées sont fusionnées. Il est alors possible de vérifier la couverture du code pour l'ensemble du programme. La couverture de code devient incontournable Une autre approche adaptée aux petites cibles consiste à limiter la taille des compteurs. En temps normal, les outils de couverture de code utilisent des compteurs de 32 bits, mais il est théoriquement possible de réduire ceux-ci à 16 bits ou même 8 bits. Il faudra, dans ce cas, faire attention aux risques de dépassement de capacité. Dans le cas de compteurs réduits, il faut donc accorder une attention toute particulière à l'interprétation des données. Dans les cas les plus extrêmes, il est même possible de réduire le compteur à 1 bit unique-ment, quand il n'est pas intéressant de savoir combien de fois une partie du programme est traversée. Le niveau de couverture de test influe par ailleurs sur la quantité de Ram requise. La surcharge de la Rom n'est, par contre, presque pas influençable. Une fois l'acquisition des données réalisée par l'instrumentation, on a recours à une petite bibliothèque, notamment pour assurer la transmission des valeurs des compteurs à l'hôte. De plus, l'instrumentation ne charge pas uniquement la mémoire, mais aussi le processeur cible. Il est donc possible qu'un timing ne soit plus respecté, en particulier quand le processeur est déjà proche de 100 % de sa charge, et des erreurs peuvent alors apparaître. La communication par les différents bus en est particulièrement affectée. C'est au testeur d'être très attentif à ce genre de comportements et de bien vérifier les résultats obtenus. Les outils de couver-ture de code professionnels sont néan-moins capables de ne pas influencer outre mesure les besoins supplémentaires en mémoire et en puissance de calcul. Figure 4.-Instrumentation du code Comme l'instrumentation fait grossir le code, les besoins en ressources augmentent drastiquement. Les tableaux requis se trouvant dans la mémoire des données, il faut donc plus de mémoire dans la Ram, mais aussi dans la Rom. Les tests et la mesure de la couverture de test voient leur importance grandir dans le développement pour les systèmes embarqués. Parce que la qualité du logiciel devient de plus en plus importante et, même si tous les standards et normes n'exigeront pas 100 % de couverture de type MC/DC pour tous les types de logiciels, que ce n'est qu'une question de temps avant que les commissions de standardisation et les associations d'industriels ne rehaussent les exigences pour les logiciels n'ayant pas encore d'exigences de sécurité. De meilleurs tests sont également dans l'intérêt du fabricant: des produits défectueux occasionnent en effet d'importants coûts, sans compter la réputation écornée de la société. Le «Banana Principle», celui du logiciel qui mûrit chez le client, bien connu dans les applications de bureau, ne sera certainement pas acceptable dans le développement pour plateformes embarquées. n

Les cibles les plus petites ont elles aussi droit à leur couverture de test

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure

Les cibles les plus petites ont elles aussi droit à leur couverture de test

Dans la même rubrique

Couverture ElectroniqueS n°127

IBM grave les premières puces en 2 nm en abandonnant les FinFET

Zeta, le protocole LPWAN made in China, arrive en Europe

Harting invente le connecteur électronique sur mesure