Le dilemme ISO 26262 : « Function coverage » ou « call coverage »
trait de séparation
Temps de lecture : 5 minutes
La norme ISO 26262 recommande fortement deux types de tests de couverture logiciel : La couverture des fonctions (functions coverage) et la couverture des appels des fonctions (call coverage). Mais quelle est la relation entre les deux ?
Il existe une gamme toujours plus large de systèmes électriques et/ou électroniques automobiles (E/E/PE), tels que les systèmes d'aide à la conduite adaptatifs, les systèmes de freinage ABS, les systèmes de gestion de la direction et les airbags. Le standard ISO 26262, « Véhicules routiers – sécurité fonctionnelle », est une norme internationale rédigée en réponse à cette demande croissante. Il spécifie des processus de développement de sécurité fonctionnelle exigeants, de la spécification des exigences à la conception, la mise en œuvre, l'intégration, la vérification, la validation et la configuration.
L'ISO 26262 rend obligatoire la mesure de la couverture structurelle à la fois au niveau de l'unité logicielle et au niveau architectural. La couverture structurelle fournit un mécanisme pour garantir l'exhaustivité des tests et pour identifier tout code excédentaire par rapport aux exigences.
Couverture fonctionnelle vs Couverture des fonctions
Tout d'abord, il est utile de dissiper un malentendu qui est monnaie courant lorsqu’on effectue une recherche rapide sur son navigateur préféré.
La couverture fonctionnelle est une mesure de la quantité de fonctionnalité de conception qui a été exercée. Il s'agit d'un régime de tests de haut niveau en boîte noire, conçu pour démontrer que chaque fonctionnalité du logiciel fonctionne comme il se doit. Il s'agit d'effectuer des tests définis dans un plan de test, chacun démontrant qu'un aspect du logiciel tel que défini dans la spécification est correctement mis en œuvre. Plus il y a de tests complétés, plus la couverture fonctionnelle est élevée.
Malgré la similitude phonétique, la couverture des fonctions sert un objectif différent. Il concerne la couverture structurelle du code. La couverture des fonctions d'un programme est un pourcentage du nombre de fonctions (sous-programmes) appelées, en proportion de leur nombre, qu'elles remplissent ou non l'objectif visé.
Dans ce blog, nous nous intéressons à la couverture des fonctions plutôt qu'à la couverture fonctionnelle.
La couverture fonctionnelle est une mesure de la quantité de fonctionnalité de conception qui a été exercée. Il s'agit d'un régime de tests de haut niveau en boîte noire, conçu pour démontrer que chaque fonctionnalité du logiciel fonctionne comme il se doit. Il s'agit d'effectuer des tests définis dans un plan de test, chacun démontrant qu'un aspect du logiciel tel que défini dans la spécification est correctement mis en œuvre. Plus il y a de tests complétés, plus la couverture fonctionnelle est élevée.
Malgré la similitude phonétique, la couverture des fonctions sert un objectif différent. Il concerne la couverture structurelle du code. La couverture des fonctions d'un programme est un pourcentage du nombre de fonctions (sous-programmes) appelées, en proportion de leur nombre, qu'elles remplissent ou non l'objectif visé.
Dans ce blog, nous nous intéressons à la couverture des fonctions plutôt qu'à la couverture fonctionnelle.
Couverture des fonctions vs Couverture des appels des fonctions
Comme la couverture des fonctions, la couverture des appels des fonctions est une métrique concernée par la couverture structurelle du code.
Pour rappel, la couverture des fonctions est une mesure du nombre de fonctions (sous-programmes) qui ont été appelées pendant l'exécution d'un programme, sous forme de pourcentage du nombre de fonctions qui existent dans ce programme.
La couverture des appels des fonctions est une mesure du nombre d'appels aux fonctions (sous-programmes) qui ont été exercés pendant l'exécution d'un programme, sous forme de pourcentage du nombre d'appels qui existent dans ce programme.
Une couverture des fonctions à 100 % n'implique pas une couverture des appels des fonctions à 100 %. L'inverse n'est pas nécessairement vrai non plus. De plus, il n'est pas possible de déduire un pourcentage de couverture de fonction à partir d'une métrique de couverture d'appel des fonctions seule.
Fonctions redondantes
Une interprétation littérale de la couverture des appels des fonctions ne tient pas compte des fonctions redondantes. Par définition, celles-ci ne s'appellent pas du tout ! Mais les fonctions redondantes sont importantes. Non seulement elles ont un impact sur la maintenance du code, mais elles sont également susceptibles de résulter d'une erreur de programmation. Il est donc sage de considérer une métrique à côté de la couverture des appels des fonctions qui les identifiera – une approche peut-être une couverture de type Branch/Decision Coverage ou Modified Condition/Decision Coverage (MC/DC).
Pour rappel, la couverture des fonctions est une mesure du nombre de fonctions (sous-programmes) qui ont été appelées pendant l'exécution d'un programme, sous forme de pourcentage du nombre de fonctions qui existent dans ce programme.
La couverture des appels des fonctions est une mesure du nombre d'appels aux fonctions (sous-programmes) qui ont été exercés pendant l'exécution d'un programme, sous forme de pourcentage du nombre d'appels qui existent dans ce programme.
Une couverture des fonctions à 100 % n'implique pas une couverture des appels des fonctions à 100 %. L'inverse n'est pas nécessairement vrai non plus. De plus, il n'est pas possible de déduire un pourcentage de couverture de fonction à partir d'une métrique de couverture d'appel des fonctions seule.
Fonctions redondantes
Une interprétation littérale de la couverture des appels des fonctions ne tient pas compte des fonctions redondantes. Par définition, celles-ci ne s'appellent pas du tout ! Mais les fonctions redondantes sont importantes. Non seulement elles ont un impact sur la maintenance du code, mais elles sont également susceptibles de résulter d'une erreur de programmation. Il est donc sage de considérer une métrique à côté de la couverture des appels des fonctions qui les identifiera – une approche peut-être une couverture de type Branch/Decision Coverage ou Modified Condition/Decision Coverage (MC/DC).
Pertinence avec la norme ISO 26262
Pour évaluer l'exhaustivité des cas de test et fournir la preuve que les objectifs de test pour les tests d'intégration sont atteints de manière adéquate, l'ISO 26262 exige que la couverture structurelle soit évaluée par les méthodes répertoriées dans le Tableau 12.
ISO 26262:6 §10.4.5 recommande l'utilisation à la fois de la couverture des fonctions et de la couverture des appels des fonctions pour les applications moins critiques (ASIL A & B), et les recommande fortement lorsque la criticité est plus élevée (ASIL C & D).
ISO 26262:6 §10.4.5 recommande l'utilisation à la fois de la couverture des fonctions et de la couverture des appels des fonctions pour les applications moins critiques (ASIL A & B), et les recommande fortement lorsque la criticité est plus élevée (ASIL C & D).
ISO 26262:6 Tableau 12 ISO 26262:6 Tableau 12 recommande l'utilisation à la fois de la couverture des fonctions et de la couverture des appels des fonctions
Atteindre les objectifs de la norme ISO 26262:6 Tableau 12
La norme ISO 26262 ne nécessite l'utilisation d'aucun outil. Cependant, un outil de test certifié comme la suite d'outils LDRA ® rend le processus de développement beaucoup plus efficace et moins sujet aux erreurs pour toutes les applications, sauf les plus triviales. L'automatisation de la mesure de la couverture structurelle lors des tests basés sur les exigences au niveau de l'intégration logicielle permet d'identifier le code non testable, les fonctionnalités involontaires, le code mort ou le code désactivé. Les rapports de couverture des fonctions et de couverture des appels des fonctions fournissent des artefacts probants pour ce travail.
Rapports de couverture des fonctions et des appels des fonctions Les rapports de couverture des fonctions et des appels fournissent des artefacts probants
Prenant la couverture des fonctions comme exemple, supposons qu'un système de freinage type ABS comporte quatre sous-composants principaux (capteurs de vitesse, soupapes, ECU et HCU). L'obtention d'une couverture fonctionnelle de 100 % pour les capteurs montrerait que chaque fonction (sous-programme) a été exercée pour ce composant. Répéter ce processus pour tous les autres composants permettrait d'obtenir une couverture fonctionnelle de 100 % pour le système ABS dans son ensemble.
La représentation graphique de la couverture dans la suite d'outils LDRA aide les utilisateurs à identifier les parties du système qui n'ont pas été testées et à concevoir de nouveaux tests afin d'accéder à ces parties du code.
Conclusion
Selon la criticité de l'application, la norme ISO 26262:6 Tableau 12 recommande ou recommande fortement l'utilisation à la fois de la couverture des fonctions et de la couverture des appels des fonctions. Les deux sont des mesures de couverture de code et ne doivent pas être confondus avec la couverture fonctionnelle, qui est une mesure du degré auquel les fonctionnalités logicielles ont été testées et éprouvées.
La réalisation de chacun de ces objectifs peut être réalisée grâce à des tests « ascendants », montrant que chaque sous-composant a été testé de manière adéquate pour finalement atteindre la couverture du système dans son ensemble.
