Test unitaire de logiciels embarqués

Question

Quelles sont les meilleures pratiques que vous avez utilisées dans les tests unitaires de logiciels embarqués qui sont propres aux systèmes embarqués ?

Answer 1

Les logiciels embarqués ont peut-être beaucoup évolué au cours des dix dernières années, mais nous faisions généralement ce qui suit :

• pour les algorithmes qui ne dépendaient pas du matériel cible, nous avions simplement des tests unitaires qui étaient construits et testés sur une plateforme non intégrée.
• pour les choses qui nécessitaient le matériel, les tests unitaires étaient compilés de manière conditionnelle dans le code pour utiliser le matériel disponible. Dans notre cas, il s'agissait d'un port série sur la cible qui transmettait les résultats à une autre machine, plus performante, où l'exactitude des tests était vérifiée.
• En fonction du matériel, il est parfois possible de simuler un périphérique "virtuel" sur une plate-forme non intégrée. Cela consiste généralement à avoir un autre fil d'exécution (ou une fonction de signal) qui modifie la mémoire utilisée par le programme. Utile pour les E/S mappées en mémoire mais pas pour les IRQ et autres.
• En général, vous ne pouviez tester qu'un petit sous-ensemble du code complet à la fois (en raison des contraintes de mémoire).
• pour les tests de choses sensibles au temps, nous ne l'avons pas fait. C'est aussi simple que cela. Le matériel que nous utilisions (8051 et 68302) n'était pas toujours fonctionnel s'il fonctionnait trop lentement. Ce genre de débogage devait être effectué au départ avec un CRO (oscilloscope) et (lorsque nous avons eu un peu plus d'argent) un ICE (émulateur en circuit).

Espérons que la situation s'est améliorée depuis la dernière fois que je l'ai fait. Je ne souhaiterais pas cette douleur à mon pire ennemi.

Answer 2

Il y a beaucoup à gagner à effectuer des tests unitaires dans un environnement PC (en compilant votre code avec un compilateur C PC et en exécutant votre code dans un cadre de tests unitaires PC), à plusieurs conditions :

1. Cela ne s'applique pas au test de votre code de bas niveau, y compris le code de démarrage, les tests de RAM, les pilotes matériels. Vous devrez utiliser des tests unitaires plus directs pour ceux-ci.
2. Le compilateur de votre système embarqué doit être digne de confiance, afin que vous ne soyez pas à la recherche de bogues créés par le compilateur.
3. Votre code doit avoir une architecture en couches, avec une abstraction matérielle. Vous devrez peut-être écrire des simulateurs de pilotes matériels pour le cadre de test unitaire de votre PC.
4. Vous devez toujours utiliser le stdint.h tels que uint16_t plutôt que de simples unsigned int etc.

Nous avons suivi ces règles et constaté qu'après avoir testé le code de la couche d'application dans un cadre de test unitaire PC, nous pouvons être sûrs qu'il fonctionne bien.

Avantages des tests unitaires sur la plate-forme PC :

1. Vous n'êtes pas confronté au problème du manque d'espace ROM sur votre plate-forme embarquée en raison de l'ajout d'un cadre de test unitaire.
2. Le cycle compilation-liaison-exécution est généralement plus rapide et plus simple sur la plate-forme PC (et évite l'étape "écriture/téléchargement" qui peut prendre plusieurs minutes).
3. Vous disposez de plus d'options pour visualiser la progression (certaines applications embarquées ont des périphériques d'E/S limités), stocker les données d'entrée/sortie pour analyse, exécuter des tests plus longs.
4. Vous pouvez utiliser des cadres de tests unitaires facilement disponibles sur PC qui ne sont pas disponibles/adaptés pour une plateforme embarquée.

Answer 3

Les systèmes embarqués sont un vaste sujet, mais en général, considérons-les comme un produit à usage spécifique qui combine à la fois le matériel et le logiciel. Mon expérience en matière de systèmes embarqués vient des téléphones mobiles, qui ne sont qu'un petit sous-ensemble de tous les systèmes embarqués. Je vais essayer de garder les points suivants un peu plus abstraits :

• Abstraire les dépendances matérielles chaque fois que possible. De cette façon, vous pouvez exécuter vos tests unitaires sur du "matériel" simulé et également tester divers cas rares/exceptionnels qui seraient plus difficiles à tester sur la cible. Pour éviter les coûts d'abstraction, vous pouvez utiliser, par exemple, la compilation conditionnelle.

• Faites dépendre le moins possible le matériel.

• Les tests unitaires exécutés sur un émulateur ou dans un environnement de compilation croisée ne garantissent toujours pas que le code fonctionne sur le matériel cible. Vous devez également tester sur la cible. Testez sur la cible le plus tôt possible.

Answer 4

Vous pourriez vouloir vérifier Développement piloté par les tests pour le C embarqué par James W. Grenning. La publication du livre est prévue en août 2010, mais le livre bêta est disponible dès maintenant sur La librairie pragmatique .

Answer 5

Je fais part de mon inexpérience, mais c'est une question à laquelle j'ai également réfléchi ces derniers temps. Il me semble que la meilleure approche serait soit

A) Écrivez autant de code d'application indépendant du matériel que possible dans un environnement PC, avant de l'écrire sur la cible, et écrivez vos tests unitaires en même temps (le fait de le faire d'abord sur le PC devrait vous obliger à séparer les éléments indépendants du matériel). De cette façon, vous pouvez utiliser les testeurs unitaires de votre choix, puis tester les éléments dépendants du matériel à l'ancienne - avec des RS-232 et/ou des oscilloscopes et des broches d'E/S signalant des données dépendantes du temps, en fonction de la vitesse d'exécution.

B) Tout écrire sur le matériel cible, mais avoir un make target pour compiler conditionnellement un build de test unitaire qui exécutera les tests unitaires et produira les résultats (ou des données qui peuvent être analysées pour les résultats) via RS-232 ou d'autres moyens. Si vous ne disposez pas de beaucoup de mémoire, cela peut être délicat.

Edition 7/3/2009 Je viens d'avoir une autre idée sur la façon de tester unitairement des choses dépendantes du matériel. Si les événements matériels se produisent trop rapidement pour être enregistrés avec la RS-232, mais que vous ne voulez pas passer manuellement en revue des tonnes de données d'oscilloscope pour vérifier si les drapeaux des broches d'E/S montent et descendent comme prévu, vous pouvez utiliser une carte PC avec EOD intégrée (comme la gamme de cartes d'acquisition de données de National Instruments) pour évaluer automatiquement le timing de ces signaux. Il vous suffirait alors d'écrire le logiciel sur votre PC pour contrôler la carte d'acquisition de données afin de la synchroniser avec le test unitaire en cours.