TPT (logiciel)

Un article de Wikipédia, l'encyclopédie libre.
Aller à : navigation, rechercher
Page d'aide sur l'homonymie Pour les articles homonymes, voir TPT.
Time Partition Testing (TPT)
TPT Logo.png

Image illustrative de l'article TPT (logiciel)

Développeur PikeTec GmbH
Version avancée 7
Environnement Microsoft Windows
Langue Anglais
Type Logiciel de test
Licence Propriétaire
Site web Piketec.com

TPT (Time Partition Testing) est un outil de programmation et une méthode pour faciliter les tests logiciels automatisės ou pour la vėrification de Systèmes embarqués. Le logiciel est développé depuis 2000, et est actuellement développé par la société PikeTec GmbH. Les systèmes embarqués sont testés normalement à l'aide de scripts. TPT cependant, permet une modélisation graphique des cas de test. TPT est un outil de test basé sur modèle utilisé pour les tests unitaires, les tests d'intégration, les tests de validation et les tests de régression. TPT permet entre autres de tester des systèmes de régulation et des systèmes à comportement continu (systèmes temps réel qui échangent avec leur environnement des valeurs physiques envoyées ou reçues à des intervalles de temps discrètes). La plupart des systèmes de contrôle appartiennent à cette classe de systèmes.

TPT comprend les tâches suivantes:

  • Modélisation de cas de test,
  • exécution de tests (entièrement automatique) sur différentes plates-formes p. ex. MATLAB/Simulink, ASCET, TargetLink, langage C aussi bien qu'autres standards de communication ( CAN ou LIN),
  • évaluation de tests (entièrement automatique),
  • documentation de tests,
  • gestion de tests,
  • traçabilité des exigences, des cas de test, aussi bien que celles des exécutions et des résultats de test.


Modélisation graphique des cas de test
Description des cas de test à l'aide d'automates hybrides

Tests réactifs[modifier | modifier le code]

À l'aide de TPT, chaque cas de test peut s'adapter au comportement du système durant un test pour par exemple intervenir exactement lorsqu'un état défini est atteint et provoquer d'autres états qui sont pertinents pour le système. Par exemple, pour simuler une panne de capteur lorsque la vitesse de ralenti est dépassée et tester le comportement de l'unité de contrôle du moteur dans une telle situation, il suffit d'avoir la possibilité de réagir à l'événement "dépasser le ralenti" dans la description du cas de test.

La réactivité et la capacité de simuler en temps réel premettent la programmation de systèmes dynamiques à temps discret comme l'exécution de filtres et d'algorithmes de contrôle avec TPT.

Modélisation graphique[modifier | modifier le code]

TPT modélise le flux des cas de test à l'aide d'automates spéciaux ou diagrammes états-transitions. Cette technique de description des cas de test est particulièrement évidente pour les systèmes embarqués puisque les cas de test sont constitués de plusieurs étapes consécutives. De ce fait, les cas de tests sont faciles à lire et à comprendre même s'ils sont très complexes.

Exemple d'une liste d'étapes

Séquences simples (Liste d'étapes)[modifier | modifier le code]

Une suite simple d'étapes successives d'un cas de test peuvent être modéliser par des étapes de test. Dans ces séquences, on peut définir des signaux (set channel), des paramètres (set parameter) ou bien faire une pause durant un cas de test (wait). De plus, une demande des résultats prévus peut être effectuer dans la séquence de test afin d'évaluer le système en cours. Il est aussi possible de placer de sous-automates à l'interieur d'une liste d'étape, qui à leur tour contiennent plusieurs automates et/ou étapes, résultant en une liste d'étape hiérarchique. Les listes d'étapes de test peuvent être combinées avec d'autres méthodes de modélisation.

Exemple d'une définition direct d'un signal

Définition directe de signaux (Direct definitions)[modifier | modifier le code]

À l'aide de cette forme de modélisation, un signal peut être défini comme une fonction de temps, une fonction du signal même à un instant passé ou bien une fonction d'autres signaux. Un signal peut aussi être importer ou bien défini manuellement à l'aide d'un éditeur graphique. Une définition par moyen de formules en notation similaire au syntaxe C est aussi permise.

Fonctions[modifier | modifier le code]

TPT permet de définir des fonctions qui peuvent agir comme clients ou serveurs. les fonctions clientes sont appelées dans le système de test à partir de TPT pendant que les fonctions serveuses sont réalisées en TPT à l'aide de fonction bouchon qui peuvent être appelées à partir du système de test. Ces fonctions peuvent aussi être appelées à partir de TPT.

Cas de test systématiques[modifier | modifier le code]

TPT a été développé spécifiquement pour le test du comportement continue et réactif des systèmes embarqués. Même pour des systèmes très complexes dont le test complet nécessite une grande quantité de cas de test, TPT assure pas son approche systématique une vue d'ensemble qui permet de détecter les faiblesses dans le système en cours avec une quantité optimale de cas de test. L'idée principale ici est la séparation des similitudes et des différences entre les cas de test: la plupart des cas de test sont très similaires dans leur séquence structurale et diffèrent "seulement" dans des petits mais cruciaux details. TPT fait usage de ce fait en modélisant conjointement et partageant les structures communes. Ceci évite d'une part les redondances, d'autre part les vraies différences entre les cas de test sont bien détérminées, c'est-à-dire les aspects spécifiques que chaque cas de test examine sont bien définis. Grâce à cette approche, la comparabilité des cas de test et pasuite la vue d'ensemble est nettement améliorée et le testeur peut se consacrer à l'essentiel, à savoir les caractéristiques distinctives des cas de test. Grâce à la structure hiérarchique des cas de test, un problème complexe peut être décomposé en plusieurs sous-problèmes, ce qui améliore la clarté et ainsi la qualité des tests. Ces techniques de modélisation aide le testeur à trouver les cas pertinents et lui permettent d'éviter les redondances et de garder un aperçu même avec une grande quantité de cas de test.

Exécution de tests[modifier | modifier le code]

Les cas de test en TPT sont indépendants de leur exécution. Les cas de test peuvent être exécutés à l'aide d'une machine virtuelle sur chaque plate-forme et si nécessaire en temps réel. TPT possède des interfaces de programmation (API) pour C et .NET.

Comme exemples d'application on peut citer MATLAB/Simulink, TargetLink ou ASCET, C, CAN, LIN (avec simulation du restbus), composants d'AUTOSAR[1], INCA, LABCAR, Software in the Loop (SiL) et Hardware in the Loop (HiL).

Une mesure de la couverture de code dans les programme en C est possible à l'aide de l'analyseur de code Testwell CTC++.

TPT peut être utilisé comme un générateur de signaux ce qui permet de remplacer comfortablement les générateurs de signaux dans MATLAB/Simulink par exemple. Les résultats sont reproductibles et conduisent à une meilleure qualité de développement.

La mesure synchrone des grandeurs internes dans les unités de contrôle se fait à l'aide de l'interface ASAM-MCD-3. De cette manière, on peut adresser des outils tel que INCA ou CANape. Les résultats sont pasuite disponibles pour l'évaluation des tests[2].

Une interface utilisateur graphique avec des affichages et des composants d'interface graphiques est disponible durant la procédure d'exécution des tests. Ceci permet à l'utilisateur de stimuler et afficher en temps réel les valeurs des signaux parallèlement à l'exécution.

Évaluation programmée[modifier | modifier le code]

Les résultats des tests doivent être évalués. Une déclaration qualitative "vrai", "faux", "incertain" doivent être délivrée dans la documentation des tests. Une déviation du comportement prévu doit aussi être enregistrée. En plus de l'évaluation manuelle et de comparaison avec des données de référence (Test de régression), TPT permet une évaluation automatique des résultats des tests. Une évaluation basée sur des règles est aussi possible. Le comportement temporel et fonctionnel de l'objet de test peut donc être non seulement évalué quantitativement, mais aussi qualitativement. Une inspection visuelle après chaque passe de test n'est plus nécessaire.

L'évaluation des tests est basée sur des données enregistrées. Les évaluations sont effectuées dans un intervalle de temps bien définis, puisque dans la plupart des cas, une évaluation n'est possible que dans des conditions d'entrées bien définies. Par exemple, une condition préalable pour que la lumière soit allumée est que l'interrupteur est activé.

TPT fournit plusieurs interfaces utilisateur graphiques pour l'évaluation de tests:

  • surveillance de limites des signaux (comparaison min/max)
  • comparaison de signaux avec des signaux de référence (Test de régression)
  • vérification de séquences de signaux discrets
  • vérification basée sur le déclenchement de conditions temporelles
  • intégration de scripts MATLAB

Pour des vérifications plus avancées, TPT offre son propre langage de programmation basé sur Python.

Gestion de tests[modifier | modifier le code]

TPT supporte les domaines de gestion de tests suivants:

  • Création de cas de test (modélisation de cas de test)
  • Planification de tests
  • Documentation de tests
  • Indication du progrès au fil des différents versions
  • traçabilité des exigences, cas de test, exécutions et résultats de test.

Domaines d'application[modifier | modifier le code]

TPT est utilisé principalement dans l'industrie automobile. L'idée est née à Daimler AG et Mercedes Benz pour le propre développement de véhicules. Les premières versions de l'outil de test ont été utilisées déjà en 2000. Actuellement TPT est utilisé par une multitude de constructeurs automobiles comme GM, Volkswagen, Audi, Porsche et BMW et autres fournisseurs comme Bosch, Hella, TRW, Continental. Daimler a coordonné le développement de TPT pendant des années et l'a ainsi optimisé pour le secteur de l'automobile.

Traçabilité des exigences[modifier | modifier le code]

Les normes internationales tel que IEC 61508, DO-178, EN 50128 et ISO 26262 exigent la traçabilité des exigences et des tests. Les exigences peuvent être importées en TPT à partir de Telelogic DOORS par exemple. Les cas de test peuvent parsuite être liés aux exigences et les données seront synchronisées. Par la suite, une analyse de couverture et traçabilité des exigences est possible. L'importation d'exigences modifiées marque automatiquement les cas de test liés à ces exigences ce qui facilite leur gestion.

Notes et références[modifier | modifier le code]

  1. Jens Lüdemann: AUTOSAR-Komponententest mit TPT, In: 2. Elektronik automotive congress in Ludwigsburg, Germany, 2010. PDF-Artikel
  2. Jens Lüdemann: Automatic ASAM MCD-3 supported Test, In: Open Technology Forum at the Testing Expo in Stuttgart, Germany, 2009. PDF-Artikel
  • (de) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en allemand intitulé « TPT (Software) » (voir la liste des auteurs).
  • Helmut Götz, Markus Nickolaus, Thomas Roßner et Knut Salomon, Modellierung und Generierung von Tests Grundlagen, Kriterien für Werkzeugeinsatz, Werkzeuge in der Übersicht, 2009, [Lire en ligne]
  • Justyna Zander-Nowicka, Abel Marrero Pérez, Ina Schieferdecker et Zhen Ru Dai, Test Design Patterns for Embedded Systems, 10th International Conference on Quality Engineering in Software Technology, CONQUEST 2007, Potsdam, Allemagne, septembre 2007 [Lire en ligne]
  • Karl J. Åström et Richard M. Murray (2008), Feedback Systems: An Introduction for Scientists and Engineers. Princeton University Press [Lire en ligne]
  • Menno Mennenga, Christian Dziobek, Iyad Bahous, Modell- und Software- Verifikation vereinfacht, 2009, Elektronik automotive, [Lire en ligne]

Liens externes[modifier | modifier le code]