L'actualité PCB - Découverte de défauts logiciels lors de la conception de PCB

Cet article explique comment éviter ces erreurs cachées mais courantes et décrit plusieurs techniques pour aider les ingénieurs à détecter les erreurs cachées dans le logiciel de réplication de PCB. La plupart des projets de développement logiciel reposent sur une combinaison de vérification de code, de tests structurels et de tests fonctionnels pour identifier les défauts logiciels. Bien que ces techniques traditionnelles soient si importantes qu'elles peuvent détecter la plupart des problèmes logiciels, elles ne peuvent pas détecter de nombreuses erreurs courantes dans les systèmes complexes d'aujourd'hui.

Les tests structurels ou les tests de boîte blanche peuvent être efficaces pour détecter les erreurs de logique, de flux de contrôle, de calcul et de données dans le Code. Ce test nécessite un aperçu complet du fonctionnement interne du logiciel (d'où le terme « boîte blanche» ou « boîte en verre») pour comprendre les détails de la structure du logiciel. Il examine chaque expression conditionnelle, opération mathématique, entrée et sortie. Comme les détails à tester sont nombreux, les tests structurels examinent une unité logicielle à la fois, généralement une fonction ou une classe. L'examen du Code utilise également les mêmes techniques sophistiquées que la détection des défauts de mise en œuvre et des problèmes potentiels. Comme pour les tests de la boîte blanche, chaque unité du logiciel est généralement examinée, car un processus d'examen efficace nécessite un examen centralisé et détaillé. Contrairement à la censure et aux tests de boîte blanche, les tests fonctionnels ou les tests de boîte noire supposent une ignorance de la mise en œuvre du logiciel. Il teste la sortie pilotée par une entrée contrôlée. Les tests fonctionnels consistent en des processus de test écrits par un testeur ou un développeur qui spécifient la sortie attendue du programme correspondant à un ensemble spécifique d'entrées de programme. Une fois le test exécuté, le testeur compare la sortie réelle à la sortie attendue pour déterminer le problème. Les tests de boîte noire peuvent être efficaces pour détecter les besoins non satisfaits, les problèmes d'interface, les problèmes de performance et les erreurs dans les fonctions les plus couramment utilisées dans un programme. Bien que la plupart des erreurs cachées dans des programmes logiciels spécifiques puissent être découvertes en combinaison avec ces techniques, elles ont également des limites. La révision du Code et les tests de la boîte blanche ne ciblent qu'une petite partie du Code à la fois, tout en ignorant le reste du système. Les tests de boîte noire traitent généralement le système dans son ensemble, ignorant les détails de mise en œuvre. Certains problèmes importants ne peuvent être découverts qu'en prêtant attention aux détails de leur interaction dans l'ensemble du système; Les méthodes traditionnelles ne permettent pas d'identifier ces problèmes de manière fiable. Un examen global du système logiciel doit être effectué pour déterminer la cause spécifique d'un problème particulier. Comme il n'est généralement pas possible d'analyser en profondeur chaque détail d'un programme et son interaction avec toutes les autres parties du Code, l'analyse doit porter sur des aspects spécifiques du programme qui sont connus pour causer des problèmes. Cet article explorera trois domaines de problèmes potentiels: * Stack overflow * conditions de concurrence * Deadlock les lecteurs peuvent lire la deuxième partie de cet article en ligne, qui explorera les questions suivantes: * problèmes de synchronisation * conditions de rentrée tous les problèmes ci - dessus sont courants dans les systèmes utilisant des techniques de conception en temps réel multitâches. Le processeur de dépassement de pile utilise la pile pour stocker des variables temporaires, passer des paramètres à la fonction appelée, enregistrer l'état du thread, etc. si le système n'utilise pas de mémoire virtuelle (En d'autres termes, il ne peut pas transférer des pages de mémoire sur le disque pour libérer de l'espace mémoire à D'autres fins), la pile sera fixée à la taille du produit à la sortie de l'usine. Si, pour une raison quelconque, la pile est hors de portée de l'allocation du programmeur, le Programme devient incertain. Cette instabilité peut entraîner de graves défaillances du système. Il est donc essentiel de s'assurer que le système est capable d'allouer suffisamment de piles dans le pire des cas. La seule façon de s'assurer qu'un débordement de pile ne se produit jamais est d'analyser le Code, de déterminer la quantité maximale d'utilisation de pile du programme dans diverses conditions possibles, puis de vérifier si suffisamment de piles sont allouées. Il est peu probable que ce test déclenche une combinaison particulière d'entrées instantanées et entraîne le pire scénario pour le système. Le concept d'analyse de la profondeur de la pile est relativement simple: 1. Créez un arbre d'appel pour chaque thread indépendant. 2. Déterminez l'utilisation de la pile pour chaque fonction dans l'arbre d'appel. Chaque arbre d'appel est examiné pour déterminer quel chemin d'appel de la racine de l'arbre à la "feuille" externe nécessite le plus de piles. 4. Ajoutez l'utilisation maximale de la pile pour chaque arbre d'appel de thread indépendant. 5. Déterminez l'utilisation maximale de la pile pour chaque routine de service d'interruption (ISR) dans chaque priorité d'interruption et calculez le total. Toutefois, si l'ISR lui - même n'a pas de pile et utilise une pile qui interrompt les Threads, le nombre maximal de piles utilisées par l'ISR doit être ajouté à la pile de chaque thread. Pour chaque priorité, ajoutez le nombre de piles utilisées pour sauvegarder l'état du processeur au moment de l'interruption. Si vous utilisez RTOS, ajoutez le nombre maximal de piles nécessaires à l'utilisation interne de RTOS lui - même (contrairement aux appels système causés par le Code de l'application inclus à l'étape 2). Tout d'abord, une arborescence d'appels construite uniquement à partir du code source d'un langage de haut niveau peut être incomplète. La plupart des compilateurs utilisent des bibliothèques d'exécution pour optimiser les tâches de calcul courantes telles que la multiplication et la Division d'entiers de grande valeur, les opérations en virgule flottante, etc. ces appels ne sont visibles que dans le langage assembleur généré par le compilateur. L'exécution des fonctions de bibliothèque elle - même peut utiliser beaucoup d'espace de pile, et elles doivent être incluses dans l'analyse. Si vous utilisez le langage C + +, tous les types de fonctions (méthodes) suivants doivent également être inclus dans l'arbre d'appel: Corps de structure, destructeurs, opérateurs de surcharge, structures de réplication et fonctions de transformation. Tous les pointeurs de fonction doivent également être analysés et les fonctions qu'ils appellent sont incluses dans l'analyse.