Tests en temps réel

Les tests en temps réel sont le processus de test des systèmes informatiques en temps réel .

Les tests de logiciels sont effectués pour détecter et aider à corriger les bugs (erreurs) dans les logiciels informatiques. Les tests consistent à s'assurer non seulement que le logiciel est exempt d'erreurs, mais qu'il fournit les fonctionnalités requises à l'utilisateur. Les méthodes de test statiques et conventionnelles peuvent détecter les bugs, mais ces techniques peuvent ne pas garantir des résultats corrects dans les systèmes logiciels en temps réel.
Les systèmes logiciels en temps réel ont des contraintes de temps strictes et ont un comportement déterministe. Ces systèmes doivent planifier leurs tâches de manière à ce que les contraintes de temps qui leur sont imposées soient respectées. La méthode d'analyse statique conventionnelle n'est pas adéquate pour gérer ces contraintes de temps, c'est pourquoi des tests en temps réel supplémentaires sont importants.

La conception de cas de test pour les tests en temps réel peut être proposée en quatre étapes

• Tests de tâches

Dans la toute première étape, chaque tâche est testée individuellement avec des tests statiques conventionnels. Ces tests sont effectués uniquement pour découvrir les erreurs de logique ou de syntaxe du programme. L'ordre des événements n'a pas d'importance car les tests de tâches ne traitent pas des contraintes de temps et des propriétés temporelles des événements.

• Tests comportementaux

En utilisant des modèles de système conçus à l'aide d'outils de test automatisés, il est possible de simuler le comportement du système en temps réel et l'impact des événements externes simultanés sur son comportement.

• Tests intertâches

Une fois les tests effectués sur la tâche individuelle, la tâche est censée être exempte d'erreurs dans le domaine du codage et du comportement. Les contraintes liées au temps sont testées avec des tests intertâches. Pour révéler les erreurs de communication, les tâches asynchrones sont testées avec des débits de données variables et des charges utiles différentes.

• Tests système

Lors de ces tests, les logiciels et le matériel sont intégrés et une gamme complète de tests système est effectuée pour détecter les erreurs, le cas échéant, lors de l'interface entre le logiciel et le matériel .

Les tests des systèmes en temps réel devenant de plus en plus importants, certains outils sont conçus pour ces tests.

Les diagrammes de séquences de messages constituent une norme internationalement reconnue pour la capture des exigences. MSC fournit un langage graphique 2D souvent nécessaire pour collecter les exigences via certains scénarios d'interaction.

Le langage de spécification et de description est une norme utilisée pour la conception et l'analyse. SDL prend en charge la spécification de systèmes logiciels complexes et a été largement appliqué dans un large éventail de domaines allant des télécommunications à l'automatisation ,en passant par le développement général de logiciels.

La notation de test et de contrôle de test est le seul langage de test standardisé au niveau international. TTCN3 offre une applicabilité plus large, par rapport aux versions antérieures de TTCN, qui étaient principalement axées sur les protocoles OSI uniquement.

Ces trois normes sont utilisées ensemble pour tester les applications en temps réel. Il est nécessaire que les exigences soient satisfaites avec ces modèles et les cas de test générés doivent capturer les informations fonctionnelles et en temps réel nécessaires pour tester les systèmes. De plus, les changements dans les exigences de conception et les nouvelles informations sur les propriétés en temps réel des systèmes doivent être intégrés dans les modèles afin que leur impact puisse être déterminé.

Pour capturer avec précision les propriétés en temps réel d'un système de test donné et pour garantir que les exigences et les modèles sont utilisés pour générer des informations de synchronisation réalistes et applicables, il est essentiel que le langage lui-même (TTCN-3) dispose d'un modèle de temps bien compris et sémantiquement solide.

TTCN-3 est le seul langage de test standardisé à l'échelle internationale actuellement disponible. Avant TTCN3, ses versions antérieures avaient des fonctionnalités limitées et une portée limitée par rapport au protocole OSI. Mais TTCN3 est une version avancée et a une applicabilité plus large.
Les caractéristiques de TTCN3 sont les suivantes :

• possibilité de spécifier des tests simultanés dynamiques
• opérations de communication basées sur des messages et des procédures
• la possibilité de spécifier des modèles de données et de signatures avec de puissants mécanismes de correspondance
• paramétrisation du type et de la valeur
• l'attribution et le traitement des verdicts de test
• Mécanismes de paramétrisation des suites de tests et de sélection des cas de test

La raison pour laquelle TTCN3 est utilisé pour les tests en temps réel est à cause de ses temporisateurs. Ces temporisateurs sont définis dans des suites de tests de fonctions . Il n'existe aucun temporisateur global utilisé dans TTCN3. Ces temporisateurs peuvent être démarrés, arrêtés et vérifiés à l'aide de fonctions simples telles que timer.start, timer.stop et timer.read.

Snapshot Semantics est une technique de TTCN3 (également de TTCN2), qui traite du message transmis lors de la communication entre systèmes ou implémentations testées. Lorsqu'une série de réponses est reçue par le système testé, un instantané est pris et elles sont évaluées dans l'ordre de leur arrivée. Ainsi, à chaque fois qu'un ensemble d'attributs est traité, un instantané est pris et seuls les événements présents dans l'instantané sont évalués.

Mais cette technique n'est pas efficace car certains événements et leurs informations d'attribut peuvent être perdus lors de la prise de l'instantané. Certains événements peuvent être enregistrés dans la file d'attente de traitement, mais pas dans l'instantané. De tels événements ne peuvent jamais être traités. De plus, si l'équipement d'exécution du test n'est pas suffisamment rapide, il ne peut pas communiquer correctement avec le système testé. Ainsi, des erreurs peuvent être générées lors de l'évaluation de ce test.

• Tests rt : https://git.kernel.org/pub/scm/utils/rt-tests/rt-tests.git/
• Cycletest par SUSE : https://documentation.suse.com/sle-rt/15-SP1/html/SLE-RT-all/art-slert-hwtest.html