Améliorer les tests de logiciels avec des graphiques de décisions de flux de contrôle
Découvrez comment les CFDGs améliorent les tests logiciels en clarifiant les chemins de décision.
― 7 min lire
Table des matières
- C'est quoi les critères de couverture ?
- Comprendre le flux de contrôle
- Le souci avec les CFGs traditionnels
- Introduction aux Control-Flow Decision Graphs (CFDGs)
- Comment fonctionnent les CFDGs
- Les avantages des CFDGs
- Automatiser le processus
- Critères de couverture principaux expliqués
- Couverture des instructions (SC)
- Couverture des décisions (DC)
- Couverture des conditions (CC)
- Couverture des décisions/conditions (D/CC)
- Couverture des conditions multiples (MCC)
- Couverture modifiée des conditions/décisions (MC/DC)
- Conclusion
- Source originale
Dans le développement logiciel, s'assurer que les programmes fonctionnent correctement est super important, surtout pour les systèmes utilisés dans des domaines sensibles comme l'aviation et l'automobile. Un moyen de vérifier si le logiciel a été bien testé, c'est à travers des Critères de couverture, qui aident les développeurs à voir s'ils ont testé toutes les parties de leur code. Cet article va expliquer comment utiliser un modèle appelé Control-Flow Decision Graph (CFDG) pour améliorer la façon dont on définit et mesure ces critères de couverture.
C'est quoi les critères de couverture ?
Les critères de couverture sont des directives qui définissent ce qui doit être testé dans un programme. Ils aident à s'assurer que toutes les parties d'un code sont vérifiées pendant les tests. Les critères courants incluent vérifier si chaque ligne de code a été exécutée au moins une fois ou si tous les résultats possibles d'une décision dans le code ont été testés. L'importance de ces critères est énorme, car ils donnent un moyen d'évaluer si un programme est robuste et fiable.
Comprendre le flux de contrôle
Quand un programme s'exécute, il suit un certain chemin ou flux de contrôle. Ce flux est souvent représenté sous forme de diagramme appelé Control-Flow Graph (CFG). Dans un CFG, chaque point où une décision est prise ou une opération se produit est représenté comme un nœud, et les chemins possibles que le programme peut prendre sont représentés comme des arêtes reliant ces nœuds.
Cependant, les CFGs classiques peuvent compliquer la visualisation de l'impact des décisions sur le flux du programme. Cette limitation est particulièrement problématique lorsqu'on essaie de comprendre comment différents tests affectent la couverture du code.
Le souci avec les CFGs traditionnels
Bien que les CFGs soient utiles, ils ne représentent pas explicitement les décisions dans le code. Les décisions sont cruciales car elles déterminent comment le programme se comporte sous différentes conditions. Par exemple, si un programme a une instruction "if", cela peut conduire à des résultats différents selon que la condition est vraie ou fausse. Les CFGs traditionnels ne clarifient pas comment ces décisions influencent le flux du programme, ce qui peut mener à des malentendus et des lacunes dans les tests.
Introduction aux Control-Flow Decision Graphs (CFDGs)
Pour pallier les limites des CFGs, un nouveau modèle appelé Control-Flow Decision Graphs (CFDGs) a été proposé. Les CFDGs s'appuient sur les CFGs en ajoutant le concept de décisions directement dans le graphe. Chaque décision dans le programme est clairement marquée, ce qui facilite la visualisation de l'impact des conditions sur le flux du programme.
L'approche CFDG permet une meilleure analyse et compréhension des critères de couverture. En utilisant ce modèle, les développeurs peuvent avoir une vision plus claire de comment leurs tests couvrent les chemins de décision du code.
Comment fonctionnent les CFDGs
Les CFDGs représentent les décisions comme des sous-graphes au sein du flux de contrôle global. Chaque décision influence la façon dont le programme se divise à partir d'un certain point. Lorsqu'une décision est prise dans le code, le CFDG montre clairement les chemins potentiels qui peuvent être empruntés en fonction des résultats de cette décision.
Pour créer un CFDG à partir d'un CFG, des algorithmes spécifiques parcourent les nœuds du CFG et identifient des segments du graphe qui correspondent à des décisions. Ce processus permet de voir comment différents chemins peuvent mener à divers résultats en fonction des décisions prises dans le programme.
Les avantages des CFDGs
Clarté : En montrant explicitement les décisions, les CFDGs rendent la compréhension du comportement du programme plus facile pour les développeurs. Ils peuvent voir directement comment les décisions impactent le flux et le contrôle dans l'application.
Meilleur testing : Avec une représentation plus claire des points de décision, les développeurs peuvent concevoir des cas de test plus efficaces. Ils peuvent s'assurer que tous les résultats possibles de chaque décision sont testés, ce qui améliore la couverture globale.
Meilleure conformité : Beaucoup de secteurs ont des régulations strictes concernant les tests logiciels, surtout dans des domaines critiques pour la sécurité. Les CFDGs peuvent aider à répondre à ces exigences en s'assurant que tous les critères nécessaires sont clairement définis et respectés.
Automatisation : Le processus de génération des CFDGs peut être automatisé avec des outils. Cette automatisation peut faire gagner du temps et réduire les erreurs humaines dans le processus de test.
Automatiser le processus
Il existe plusieurs outils qui peuvent créer des CFDGs à partir de CFGs existants produits par des compilateurs courants comme GCC et Clang. Ces outils prennent les CFGs et les annotent automatiquement avec des informations sur les décisions. Cela permet aux développeurs de visualiser les critères de couverture directement liés aux décisions dans le code.
Cette automatisation facilite énormément le travail des équipes de développement logiciel qui veulent utiliser les CFDGs dans leur processus de test. Au lieu de déterminer manuellement comment les décisions sont représentées dans un CFG, les développeurs peuvent utiliser ces outils pour obtenir des représentations visuelles claires du flux de leur code.
Critères de couverture principaux expliqués
Maintenant, regardons quelques critères de couverture communs qui peuvent être analysés avec les CFDGs.
Couverture des instructions (SC)
La couverture des instructions assure que chaque ligne de code dans un programme a été exécutée au moins une fois. C'est la forme de couverture la plus simple et cela sert de vérification de base pour confirmer qu'aucune partie du code n'a été ignorée pendant les tests.
Couverture des décisions (DC)
La couverture des décisions va un peu plus loin en s'assurant que non seulement chaque ligne a été exécutée mais aussi que chaque décision a été évaluée pour tous les résultats possibles au moins une fois. Cela garantit que les différents chemins à travers le programme sont adéquatement testés.
Couverture des conditions (CC)
La couverture des conditions nécessite que chaque condition au sein des décisions soit évaluée à la fois à vrai et à faux au moins une fois. C'est un critère de test plus approfondi, car cela assure que les conditions individuelles fonctionnent correctement.
Couverture des décisions/conditions (D/CC)
Ce critère combine la couverture des décisions et des conditions. Il confirme que toutes les instructions et tous les résultats des décisions et conditions ont été testés, assurant ainsi un haut niveau de rigueur dans les tests.
Couverture des conditions multiples (MCC)
La couverture des conditions multiples exige que toutes les combinaisons de conditions au sein d'une décision soient testées. Cela signifie que les tests doivent couvrir toutes les façons possibles dont les conditions peuvent interagir, ce qui peut considérablement augmenter le nombre de tests nécessaires.
Couverture modifiée des conditions/décisions (MC/DC)
MC/DC est l'un des critères de test les plus rigoureux. Il affirme que chaque résultat possible d'une décision doit être testé, s'assurant que chaque condition dans une décision influence indépendamment les résultats de cette décision. C'est crucial dans des secteurs comme l'aviation et l'automobile, où la sécurité est primordiale.
Conclusion
L'introduction des Control-Flow Decision Graphs offre une manière plus claire et plus efficace de comprendre et de mesurer la couverture du code dans les tests logiciels. En représentant clairement les décisions dans le flux d'un programme, les CFDGs aident les développeurs à créer de meilleurs tests et à s'assurer que leur code respecte les normes de sécurité et de qualité nécessaires.
Alors que la demande pour des logiciels de haute qualité continue de croître, surtout dans les secteurs sensibles à la sécurité, l'utilisation de modèles comme les CFDGs va devenir de plus en plus importante pour garantir que les logiciels sont non seulement fonctionnels mais aussi fiables.
Titre: Annotating Control-Flow Graphs for Formalized Test Coverage Criteria
Résumé: Control flow coverage criteria are an important part of the process of qualifying embedded software for safety-critical systems. Criteria such as modified condition/decision coverage (MC/DC) as defined by DO-178B are used by regulators to judge the adequacy of testing and by QA engineers to design tests when full path coverage is impossible. Despite their importance, these coverage criteria are often misunderstood. One problem is that their definitions are typically written in natural language specification documents, making them imprecise. Other works have proposed formal definitions using binary predicate logic, but these definitions are difficult to apply to the analysis of real programs. Control-Flow Graphs (CFGs) are the most common model for analyzing program logic in compilers, and seem to be a good fit for defining and analyzing coverage criteria. However, CFGs discard the explicit concept of a decision, making their use for this task seem impossible. In this paper, we show how to annotate a CFG with decision information inferred from the graph itself. We call this annotated model a Control-Flow Decision Graph (CFDG) and we use it to formally define several common coverage criteria. We have implemented our algorithms in a tool which we show can be applied to automatically annotate CFGs output from popular compilers.
Auteurs: Sean Kauffman, Carlos Moreno, Sebastian Fischmeister
Dernière mise à jour: 2024-07-04 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2407.04144
Source PDF: https://arxiv.org/pdf/2407.04144
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.