TPT (logiciel)

À 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 permettent la programmation de systèmes dynamiques à temps discret comme l'exécution de filtres et d'algorithmes de contrôle avec TPT.

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)

Une suite simple d'étapes successives d'un cas de test peuvent être modélisées 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 effectuée dans la séquence de test afin d'évaluer le système en cours. Il est aussi possible de placer des sous-automates à l’intérieur d'une liste d'étapes, qui à leur tour contiennent plusieurs automates et/ou étapes, résultant en une liste d'étapes hiérarchiques. Les listes d'étapes de test peuvent être combinées avec d'autres méthodes de modélisation. Il est aussi possible de définir des mesures parallèles.

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

TPT a été développé spécifiquement pour le test du comportement continu 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 par 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 détails. 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éterminé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 par la suite 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.

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, composants d'AUTOSAR[2], INCA, LABCAR, Software in the Loop (SiL) et Hardware in the Loop (HiL).

Une mesure de la couverture de code dans les programmes 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 aisément 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[3].

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.

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.

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.

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.

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 par suite ê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.

• (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]

• Piketec GmbH