Pourquoi et Quand le Test de Logiciel est Important dans les Systèmes Intégrés ?
trait de séparation
Temps de lecture : 8 min
Dans le monde des systèmes embarqués, ce n’est pas seulement la technologie qui continue de se développer et d’évoluer. Les outils et les méthodes utilisés pour développer cette technologie mûrissent et s’améliorent en parallèle.
Retour d'expérience de Mark Pitchford, spécialiste technique de LDRA Software Technology :
Au début des années 80, j'ai développé un logiciel pour une petite entreprise de métrologie, appliquant les mathématiques de l'ingénierie aux machines à mesurer coordonnées (MMT). J’aimerais penser que j’y étais assez bon. Mais notre cycle de vie de développement considérait essentiellement les logiciels de production comme un bac à sable. Nous commencerions par le code de production, ajouterions des fonctionnalités, effectuer des tests fonctionnels assez rudimentaires et l'expédier.
Dans une si petite entreprise, notre équipe d'ingénierie comprenait naturellement à la fois des spécialistes du logiciel et du matériel. Avec le recul, il est frappant de constater que si le besoin d'un support client étendu était une évidence pour le logiciel que nous avons développé, il n'y avait nulle part la même culture de lutte contre les incendies pour le matériel sur lequel il fonctionnait.
Au début des années 80, j'ai développé un logiciel pour une petite entreprise de métrologie, appliquant les mathématiques de l'ingénierie aux machines à mesurer coordonnées (MMT). J’aimerais penser que j’y étais assez bon. Mais notre cycle de vie de développement considérait essentiellement les logiciels de production comme un bac à sable. Nous commencerions par le code de production, ajouterions des fonctionnalités, effectuer des tests fonctionnels assez rudimentaires et l'expédier.
Dans une si petite entreprise, notre équipe d'ingénierie comprenait naturellement à la fois des spécialistes du logiciel et du matériel. Avec le recul, il est frappant de constater que si le besoin d'un support client étendu était une évidence pour le logiciel que nous avons développé, il n'y avait nulle part la même culture de lutte contre les incendies pour le matériel sur lequel il fonctionnait.
Le développement logiciel est une discipline d'ingénierie
Une partie de la différence entre le support logiciel et matériel est le résultat du processus de développement brut. Mais la simple malléabilité des logiciels et la capacité qui en résulte pour des fonctionnalités toujours plus nombreuses jouent également un rôle majeur. En termes simples, il y a bien plus de façons de se tromper que de bien faire les choses, et cette caractéristique exige qu'elle soit traitée comme une discipline d'ingénierie.
Il n’y a rien de nouveau à ce sujet. Les principales normes de sécurité fonctionnelle de l'aviation, de l'automobile et de l'industrie telles que DO-178, ISO 26262 et IEC 61508 exigent une telle approche depuis des années. Mais avoir une mentalité de discipline d'ingénierie est essentiel si vous voulez profiter des avantages des outils de développement et de test de pointe d'aujourd'hui, qui sont conçus pour servir une telle approche.
Plus récemment, l'importance des tests logiciels a été démontrée par le développement de l'ISO / CEI / IEEE 29119, un ensemble international de normes pour les tests logiciels qui peuvent être utilisés dans tout cycle de vie ou organisation de développement logiciel.
Il n’y a rien de nouveau à ce sujet. Les principales normes de sécurité fonctionnelle de l'aviation, de l'automobile et de l'industrie telles que DO-178, ISO 26262 et IEC 61508 exigent une telle approche depuis des années. Mais avoir une mentalité de discipline d'ingénierie est essentiel si vous voulez profiter des avantages des outils de développement et de test de pointe d'aujourd'hui, qui sont conçus pour servir une telle approche.
Plus récemment, l'importance des tests logiciels a été démontrée par le développement de l'ISO / CEI / IEEE 29119, un ensemble international de normes pour les tests logiciels qui peuvent être utilisés dans tout cycle de vie ou organisation de développement logiciel.
L’importance des exigences
La conception du système électrique commence souvent par une machine à états et une compréhension des différents modes de fonctionnement pour un produit particulier. Les ingénieurs peuvent généralement mapper cette fonctionnalité de machine d'état à la logique très rapidement et facilement. Dans le cas où la machine d'état se complique, elle est souvent traduite en logiciel.
Des exigences de haut niveau sont essentielles pour garantir le bon fonctionnement du système. Ces exigences caractérisent la logique métier et les fonctionnalités prévues et permettent d’évaluer si le système fait ce qu’il est censé faire. Les meilleures pratiques suivent le flux des exigences de haut niveau en passant par l'analyse et la couverture, et naturellement, les outils de traçabilité des exigences sont conçus pour prendre en charge cela.
Des exigences de haut niveau sont essentielles pour garantir le bon fonctionnement du système. Ces exigences caractérisent la logique métier et les fonctionnalités prévues et permettent d’évaluer si le système fait ce qu’il est censé faire. Les meilleures pratiques suivent le flux des exigences de haut niveau en passant par l'analyse et la couverture, et naturellement, les outils de traçabilité des exigences sont conçus pour prendre en charge cela.
Dans le modèle de machine à états, les exigences qui caractérisent chaque état sont des exemples d'exigences de haut niveau. Tracer le chemin d'exécution à travers le code pour s'assurer que chaque exigence est interprétée correctement est un très bon moyen de vérifier la bonne implémentation.
Les normes de sécurité fonctionnelle étendent cela à un concept de traçabilité des exigences. Ils exigent souvent que les utilisateurs utilisent tout leur code à partir d'exigences de haut niveau et expliquent et testent tous les cas découverts avec des tests de bas niveau. Dernièrement, le paradigme du «décalage vers la gauche» en matière de cybersécurité fait écho à ce message, comme l'illustre le modèle en V dans la figure 1.
Figure 1 Comme son nom l'indique, le modèle V incarne un processus de développement de produit qui montre le lien entre les spécifications de test à chaque phase de développement. Source: LDRA
Tester les composants, puis tester le système
Dans toute discipline d'ingénierie, il est important de s'assurer que les composants fonctionnent correctement par eux-mêmes avant d'être intégrés dans un système. Pour appliquer cette réflexion aux logiciels, les ingénieurs doivent définir des exigences de niveau inférieur et s'assurer que chaque fonction et ensemble de fonctions jouent leur rôle. Les ingénieurs doivent également s'assurer qu'ils présentent des interfaces appropriées avec le reste du système.
Les tests unitaires consistent à paramétrer les entrées et les sorties aux niveaux de la fonction et du module, à effectuer un examen pour s'assurer que la connexion entre les entrées et les sorties soit correcte et suive la logique avec une couverture. Les outils de test unitaire peuvent fournir des faisceaux de test éprouvés et une représentation graphique reliant les entrées et sorties individuelles aux chemins d'exécution et permettre de vérifier leur exactitude.
Il est également important de comprendre les interfaces, à la fois au niveau fonctionnel et au niveau des modules. Les outils d'analyse statique peuvent montrer ces interfaces et connecter la logique à différents niveaux.
Les tests unitaires consistent à paramétrer les entrées et les sorties aux niveaux de la fonction et du module, à effectuer un examen pour s'assurer que la connexion entre les entrées et les sorties soit correcte et suive la logique avec une couverture. Les outils de test unitaire peuvent fournir des faisceaux de test éprouvés et une représentation graphique reliant les entrées et sorties individuelles aux chemins d'exécution et permettre de vérifier leur exactitude.
Il est également important de comprendre les interfaces, à la fois au niveau fonctionnel et au niveau des modules. Les outils d'analyse statique peuvent montrer ces interfaces et connecter la logique à différents niveaux.
Trouvez les problèmes le plus tôt possible
Les ingénieurs de n'importe quelle discipline vous diront que plus les problèmes sont découverts tôt, moins il en coûtera pour les résoudre.
L'analyse statique effectue une analyse du code source pour modéliser l'exécution d'un système sans l'exécuter réellement. Disponible dès que le code est écrit, l'analyse statique peut aider les développeurs à maximiser la clarté, la maintenabilité et la testabilité de leur code. Les principales caractéristiques des outils d'analyse statique sont les suivantes:
L'analyse statique effectue une analyse du code source pour modéliser l'exécution d'un système sans l'exécuter réellement. Disponible dès que le code est écrit, l'analyse statique peut aider les développeurs à maximiser la clarté, la maintenabilité et la testabilité de leur code. Les principales caractéristiques des outils d'analyse statique sont les suivantes:
1. Analyse de la complexité du code: comprendre où votre code est inutilement compliqué, afin que les ingénieurs puissent effectuer les activités d'atténuation appropriées.
2. Analyse du flux de programme: dessiner des graphiques de flux de revue de conception de l'exécution du programme pour s'assurer que le programme s'exécute dans le flux attendu.
3. Détection prédictive des erreurs d'exécution: Modélisation de l'exécution du code via autant de chemins exécutables que possible et recherche d'erreurs potentielles telles que les dépassements de limites de tableau et la division par zéros.
4. Adhésion aux normes de codage: Les normes de codage sont souvent choisies pour garantir une concentration sur la cybersécurité, la sécurité fonctionnelle ou, dans le cas des normes MISRA, l'une ou les deux. Les normes de codage aident à garantir que le code adhère aux meilleures pratiques de programmation, ce qui est certainement une bonne idée quelle que soit l'application.
2. Analyse du flux de programme: dessiner des graphiques de flux de revue de conception de l'exécution du programme pour s'assurer que le programme s'exécute dans le flux attendu.
3. Détection prédictive des erreurs d'exécution: Modélisation de l'exécution du code via autant de chemins exécutables que possible et recherche d'erreurs potentielles telles que les dépassements de limites de tableau et la division par zéros.
4. Adhésion aux normes de codage: Les normes de codage sont souvent choisies pour garantir une concentration sur la cybersécurité, la sécurité fonctionnelle ou, dans le cas des normes MISRA, l'une ou les deux. Les normes de codage aident à garantir que le code adhère aux meilleures pratiques de programmation, ce qui est certainement une bonne idée quelle que soit l'application.
Figure 2 Des activités telles que l'analyse statique représentent une surcharge au début du cycle de vie du développement, mais elles rapportent des dividendes à long terme.
Source: LDRA
Développer un code de qualité adéquate
Il n’est pas surprenant que les produits d’ingénierie de meilleure qualité soient plus chers. L'adhésion à tout processus de développement a un coût, et il n'est pas toujours commercialement viable de développer le meilleur possible.
Lorsque la sécurité est importante, les normes de sécurité fonctionnelle exigeront souvent une analyse du coût et de la probabilité de défaillance. Cette évaluation des risques est requise pour chaque système, sous-système et composant afin de s'assurer que des activités d'atténuation proportionnées sont exécutées. Ce même principe est logique, que les systèmes soient critiques pour la sécurité ou pour la sécurité. Si vous testez chaque partie du système avec le même niveau de rigueur, vous surinvestirez dans les parties de votre système où le risque est faible et vous échouerez à atténuer correctement les défaillances là où le risque est plus élevé.
La pratique de la sécurité des logiciels commence par comprendre ce qui se passera si le composant ou le système tombe en panne, puis suit cette défaillance potentielle dans les activités appropriées pour atténuer le risque de le faire. Prenons, par exemple, un système qui contrôle le guidage d’un avion lorsque la défaillance est potentiellement catastrophique. Des activités d'atténuation rigoureuses doivent être effectuées au niveau de la couverture des sous-conditions pour garantir une génération de code correcte.
Comparez cela avec un système de divertissement en vol. En cas de défaillance de ce système, l'avion ne s'écrase pas, de sorte que tester un système de divertissement en vol est moins exigeant qu'un système où il y a un risque de perte de vie immédiate.
La malléabilité des logiciels est à la fois une bénédiction et une malédiction. Il est très facile de faire en sorte qu'un système fasse pratiquement n'importe quoi dans les limites du raisonnable. Mais cette même flexibilité peut également être un talon d’Achille pour s’assurer que les logiciels ne tombent pas en panne.
Même dans le monde commercial, si toutes les pannes logicielles ne sont pas catastrophiques, elles ne sont jamais souhaitables. De nombreux développeurs travaillent dans les secteurs critiques pour la sûreté et la sécurité et n'ont d'autre choix que de se conformer aux normes les plus strictes. Mais les principes promus par ces normes sont là parce qu'il a été prouvé qu'ils améliorent le fonctionnement du produit résultant. Il est donc tout à fait logique d’adopter ces principes de manière proportionnée, quelle que soit la gravité de l’application.
Malgré la pléthore déroutante de normes de sûreté et de sécurité fonctionnelles applicables au développement de logiciels, il y a beaucoup plus de similitudes que de différences entre elles. Tous sont basés sur le fait que le développement logiciel est une discipline d'ingénierie, exigeant que nous établissions des exigences, que nous concevions et développions pour les satisfaire, et que nous testions au plus tôt les exigences.
L'adoption de cet état d'esprit ouvrira la porte à une industrie entière d'outils de soutien, permettant un développement plus efficace de logiciels de meilleure qualité.
Mark Pitchford, spécialiste technique de LDRA Software Technology, a travaillé avec des équipes de développement cherchant à réaliser un développement logiciel conforme dans des environnements critiques pour la sûreté et la sécurité.
Lorsque la sécurité est importante, les normes de sécurité fonctionnelle exigeront souvent une analyse du coût et de la probabilité de défaillance. Cette évaluation des risques est requise pour chaque système, sous-système et composant afin de s'assurer que des activités d'atténuation proportionnées sont exécutées. Ce même principe est logique, que les systèmes soient critiques pour la sécurité ou pour la sécurité. Si vous testez chaque partie du système avec le même niveau de rigueur, vous surinvestirez dans les parties de votre système où le risque est faible et vous échouerez à atténuer correctement les défaillances là où le risque est plus élevé.
La pratique de la sécurité des logiciels commence par comprendre ce qui se passera si le composant ou le système tombe en panne, puis suit cette défaillance potentielle dans les activités appropriées pour atténuer le risque de le faire. Prenons, par exemple, un système qui contrôle le guidage d’un avion lorsque la défaillance est potentiellement catastrophique. Des activités d'atténuation rigoureuses doivent être effectuées au niveau de la couverture des sous-conditions pour garantir une génération de code correcte.
Comparez cela avec un système de divertissement en vol. En cas de défaillance de ce système, l'avion ne s'écrase pas, de sorte que tester un système de divertissement en vol est moins exigeant qu'un système où il y a un risque de perte de vie immédiate.
La malléabilité des logiciels est à la fois une bénédiction et une malédiction. Il est très facile de faire en sorte qu'un système fasse pratiquement n'importe quoi dans les limites du raisonnable. Mais cette même flexibilité peut également être un talon d’Achille pour s’assurer que les logiciels ne tombent pas en panne.
Même dans le monde commercial, si toutes les pannes logicielles ne sont pas catastrophiques, elles ne sont jamais souhaitables. De nombreux développeurs travaillent dans les secteurs critiques pour la sûreté et la sécurité et n'ont d'autre choix que de se conformer aux normes les plus strictes. Mais les principes promus par ces normes sont là parce qu'il a été prouvé qu'ils améliorent le fonctionnement du produit résultant. Il est donc tout à fait logique d’adopter ces principes de manière proportionnée, quelle que soit la gravité de l’application.
Malgré la pléthore déroutante de normes de sûreté et de sécurité fonctionnelles applicables au développement de logiciels, il y a beaucoup plus de similitudes que de différences entre elles. Tous sont basés sur le fait que le développement logiciel est une discipline d'ingénierie, exigeant que nous établissions des exigences, que nous concevions et développions pour les satisfaire, et que nous testions au plus tôt les exigences.
L'adoption de cet état d'esprit ouvrira la porte à une industrie entière d'outils de soutien, permettant un développement plus efficace de logiciels de meilleure qualité.
Mark Pitchford, spécialiste technique de LDRA Software Technology, a travaillé avec des équipes de développement cherchant à réaliser un développement logiciel conforme dans des environnements critiques pour la sûreté et la sécurité.
