TPT (Software)

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von Time Partition Testing)
Zur Navigation springen Zur Suche springen
Time Partition Testing (TPT)

Basisdaten

Entwickler PikeTec GmbH
Aktuelle Version 19[1]
(März 2023)
Betriebssystem Windows
Kategorie Softwaretest
Lizenz proprietär
deutschsprachig nein
TPT

TPT (Time Partition Testing) ist eine Methode und ein Software-Werkzeug der Firma PikeTec für den automatisierten Softwaretest oder die Softwareverifikation eingebetteter Systeme. Meist werden eingebettete Systeme mit Hilfe von Testskripten getestet – bei TPT werden Testfälle grafisch modelliert. TPT ist ein modellbasiertes Testwerkzeug für den Modultest, Integrationstest, Systemtest und Regressionstest. TPT unterstützt unter anderem auch Tests von Regelungssystemen und Systemen mit kontinuierlichem Verhalten (Echtzeitsysteme, die mit ihrer Umgebung physikalische Werte bzw. Signale austauschen, die in einem Zeitraster zeitdiskret empfangen oder versandt werden). Die meisten Steuerungs- und Regelungssysteme gehören zu dieser Systemklasse.

TPT umfasst die folgenden Aufgabenbereiche:

  • manuelle oder automatische Testfallmodellierung,
  • Testdurchführung (vollautomatisch) auf verschiedenen Plattformen mit z. B. Matlab/Simulink, ASCET, TargetLink, C-Code oder unter Nutzung von Kommunikationsstandards wie CAN
  • Testauswertung (vollautomatisch)
  • Testdokumentation (vollautomatisch)
  • Test Management
  • Nachverfolgbarkeit von Anforderungen und Testfällen, Testdurchführungen und Testresultaten
Grafische Testfallmodellierung
Testbeschreibung mit Hybriden Automaten

Mit TPT kann jeder Testfall während des Testablaufs gezielt auf das Systemverhalten reagieren, um beispielsweise genau bei Eintreten eines bestimmten Zustands eingreifen und weitere, testrelevante Systemzustände provozieren zu können. Soll beispielsweise für eine Motorsteuerung bei Überschreiten der Leerlaufdrehzahl ein Sensorausfall simuliert werden, um das Verhalten der Motorsteuerung bei dieser Situation zu testen, muss in der Beschreibung des Testfalls auf das Ereignis „Leerlaufdrehzahl überschritten“ reagiert werden können.

Die Reaktivität zusammen mit der Echtzeitfähigkeit der Testausführung erlaubt die Programmierung von zeitdiskreten dynamischen Systemen wie beispielsweise die Implementierung von Filterfunktionen und Regelalgorithmen mit TPT.

Grafische Testfallmodellierung

[Bearbeiten | Quelltext bearbeiten]

Der Ablauf von Testfällen wird bei TPT grafisch mit Hilfe spezieller Zustandsautomaten oder Zustandsübergangsdiagramme modelliert. Diese Beschreibungstechnik für Testfälle ist für das Einsatzfeld eingebetteter Systeme besonders naheliegend, weil Testfälle immer aus einzelnen, zeitlich aufeinander folgenden Schritten bestehen. Die Testfälle sind dadurch intuitiv lesbar, auch wenn sie sehr komplex sind.

Test Step List Beispiel

Einfache Sequenzen (Test-Step-Listen)

[Bearbeiten | Quelltext bearbeiten]

Einfache Abfolgen von Testschritten, die nicht parallel abgearbeitet werden sollen wie beispielsweise Signal setzen (set channel), Signalrampe (ramp channel), Parameter setzen (set parameter), Warten (wait) können mit Testschritten einfach modelliert werden. In die Sequenzen können Abfragen für das erwartete Testergebnis zur Testbewertung als Testorakel eingefügt werden. Wenn Automatenzustände, die wiederum Automaten oder Sequenzen enthalten, eingefügt werden, entstehen hierarchische StepListen. Die Testsequenzen können auch mit anderen Modellierungsmethoden kombiniert und parallelisiert werden.

Direct Definition Beispiel

Direkte Signaldefinition (Direct Definitions)

[Bearbeiten | Quelltext bearbeiten]

In den „Test-Step-Listen“ sind sogenannte „Direct Definitions“ möglich. Signale werden in dieser Modellierungsform als Funktionen der Zeit, der Vergangenheit und anderer Signale definiert. Die Definition von Formeln in „C-Ähnlicher“ Notation ist neben dem Import von Messdaten oder einem manuellen Signaleditor möglich.

Es ist möglich, Funktionen zu definieren, die als Client oder Server agieren. Clientfunktionen werden aus TPT im zu testenden System aufgerufen, wobei Serverfunktionen in TPT implementiert als sogenannte Stub-funktionen aus dem zu testenden System aufgerufen werden können. TPT kann die Serverfunktionen auch selbst aufrufen.

Systematische Testfälle

[Bearbeiten | Quelltext bearbeiten]

TPT wurde speziell für den Test des kontinuierlichen und reaktiven Verhaltens eingebetteter Systeme entwickelt. Selbst für sehr komplexe Systeme, deren gründlicher Test eine große Menge an Testfällen erfordert, gewährleistet TPT durch sein systematisches Vorgehen bei der Testfallermittlung den Überblick und ermöglicht es so, Schwachstellen im zu testenden System mit einer optimalen Menge von Testfällen aufzudecken. Die zugrunde liegende Idee der Systematik von TPT ist die Separierung von Gemeinsamkeiten und Unterschieden zwischen den Testfällen: Die meisten Testfälle sind einander in ihrem strukturellen Ablauf sehr ähnlich und unterscheiden sich „nur“ in wenigen, aber entscheidenden Details. TPT macht sich diese Tatsache zunutze, indem gemeinsame Strukturen auch gemeinsam modelliert und genutzt werden. Dadurch werden zum einen Redundanzen vermieden. Zum anderen wird sehr klar herausgestellt, worin sich die Testfälle tatsächlich unterscheiden – das heißt, welche spezifischen Aspekte sie jeweils testen. Durch diesen Ansatz wird die Vergleichbarkeit der Testfälle und damit die Übersicht deutlich verbessert und das Hauptaugenmerk des Testers auf das Wesentliche – die differenzierenden Merkmale der Testfälle – gelenkt. Durch die hierarchische Struktur der Testfälle lassen sich komplexe Testprobleme in Teilprobleme zerlegen, was die Übersichtlichkeit und dadurch die Qualität des Tests ebenfalls verbessert. Mit diesen Modellierungstechniken wird der Tester dabei unterstützt, die tatsächlich relevanten Fälle zu finden, Redundanzen zu vermeiden und selbst bei einer großen Menge an Testfällen den Überblick zu bewahren.

Interaktion mit dem Test über den Dashboard

Automatische Testfallgenerierung

[Bearbeiten | Quelltext bearbeiten]

TPT beinhaltet verschiedene Möglichkeiten zur automatischen Testfallgenerierung:

  • Testfälle zur Abdeckung von Äquivalenzklassen
  • Testfälle zur Abdeckung von Simulink-Modellen oder C-Code mittels statischer Analysen und suchbasierter Verfahren (TASMO)[2]
  • Sequenzbildung von Varianten von Zuständen im Testmodell
  • Testfälle aus Aufzeichnungen von Interaktionen mit dem SUT über eine grafische Benutzerschnittstelle (Dashboard)

Testausführung

[Bearbeiten | Quelltext bearbeiten]

TPT-Testfälle sind unabhängig von ihrer Ausführung. Die Testfälle sind mittels einer sogenannten Virtuellen Maschine (TPT-VM) quasi auf jeder Plattform automatisch und wenn nötig in Echtzeit ausführbar. Für die TPT-VM gibt es Programmierschnittstellen (API) für C und das .Net-Framework. Die Ausführung kann manuell, im Batchmodus oder auf einem Jenkins Server erfolgen.

Beispiele für die Anwendung sind Model in the Loop (MiL) mit Matlab/Simulink, TargetLink oder ASCET, C-Programmen, CAN, CANape, CANoe, AUTOSAR-Komponenten[3], INCA, LABCAR, Software in the Loop (SiL), CarMaker und Hardware in the Loop (HiL).

Für eine Analyse und Messung der Testüberdeckung steht beispielsweise für C-Programme eine Ankopplung an den Code Coverage Analyser Testwell ctc++ oder gcov bereit.

TPT kann als Signalgenerator auch zum „Ausprobieren“ der Implementierung während der Entwicklungsphase benutzt werden. Durch die Möglichkeit, beliebige Signale zu generieren, kann TPT auch als Signalgenerator benutzt werden. In Matlab/Simulink können damit Schalter und Signalgeneratoren komfortabel ersetzt werden. Die Ergebnisse sind wiederholbar und führen zu einer verbesserten Qualität der Entwicklung.

Das testsynchrone Messen steuergeräteinterner Messgrößen am Prüfstand oder im Fahrzeug erfolgt über Werkzeuge wie INCA oder CANape. Die Messergebnisse stehen zur Testfallbewertung oder zur Testlaufzeit zur Verfügung[4].

Bei der Testdurchführung steht eine konfigurierbare grafische Benutzeroberfläche mit Anzeigen und Steuerelementen zur Verfügung. Damit können in Echtzeit parallel zur Testausführung Werte vom Benutzer stimuliert oder angezeigt werden. Diese Interaktion kann auch aufgezeichnet werden um so Tests als Schrittliste aufzunehmen.

Programmierte Testauswertung

[Bearbeiten | Quelltext bearbeiten]

Testergebnisse müssen bewertet werden. Qualitative Aussagen wie „wahr“, „falsch“ oder „ungewiss“ müssen in der Testdokumentation ausgegeben werden. Abweichungen vom Soll-Verhalten sollen protokolliert werden. Neben der manuellen Auswertung und dem Vergleich mit Referenzdaten (Regressionstest) können mit TPT Testergebnisse automatisch ausgewertet werden. Regelbasierte Auswertungen sind möglich. Zeitliches und funktionales Verhalten des Testobjekts kann somit nicht nur strikt quantitativ, sondern auch qualitativ einfach beurteilt werden. Eine visuelle Inspektion nach jedem Testdurchlauf entfällt.

Die Testauswertung, auch Testassessment genannt, basiert auf aufgezeichneten Testdaten. Auswertungen werden in wohl definierten Zeitintervallen durchgeführt, da in vielen Fällen eine Auswertung der Ergebnisse nur unter bestimmten Eintrittsbedingungen erfolgen kann. Beispielsweise ist eine Vorbedingung dafür, dass ein Licht leuchtet, dass das Licht eingeschaltet ist.

Für gängige und einfache Testauswertungen stehen graphische Benutzeroberflächen zur Verfügung:

  • Überwachung von Signalgrenzen (Min/Max-Vergleich)
  • Fehlertoleranter Vergleich von Signalen mit Referenzsignalen (Regressionstest)
  • Untersuchung von diskreten Signalsequenzen
  • Regelbasierte Untersuchungen nach zeitlichen Triggerbedingungen
  • Einbindung von Matlab-Skripten

Für weiterreichende Untersuchungen steht eine eigene Programmiersprache auf Python-Basis zur Verfügung. Diese Programmiersprache stellt eine umfangreiche Bibliothek zum Rechnen mit Signalen bereit. Bspw. sind Filteroperationen, Monotonieuntersuchungen, zeitliche Abfragen, Untersuchungen, ob eine Bedingung immer oder niemals auftritt, oder die Definition zeitlicher Intervalle möglich. Eine Auswertung anderweitig erhaltener Messergebnisse ist gleichfalls möglich. Die Messdaten modellinterner TargetLink- oder Simulink-Signale sowie Daten anderer Messgeräte sind automatisch in der Testauswertung nutzbar.

TPT unterstützt folgende Bereiche des Testmanagements:

  • Testfallerstellung (Testfallmodellierung)
  • Testplanung
  • Testdokumentation
  • Fortschrittsanzeige über verschiedene Releases
  • Nachverfolgbarkeit von Anforderungen, Testfällen, Testdurchführungen und Testresultaten

TPT wird vorrangig in der Automobilindustrie eingesetzt. Die ursprüngliche Idee ist bei der Daimler AG und Mercedes-Benz für die eigene Fahrzeugentwicklung entstanden.[5] Mit den ersten Versionen des Testwerkzeugs wurde dort schon im Jahr 2000 gearbeitet. Inzwischen arbeiten auch andere Automobilfirmen wie GM, Volkswagen, Audi, Porsche und BMW sowie Zulieferer wie Bosch, Hella, TRW und Continental mit dem Testwerkzeug.[6] Daimler hat die Weiterentwicklung von TPT jahrelang selbst koordiniert und TPT dabei für den Automobilsoftwarebereich optimiert.

Nachverfolgbarkeit von Anforderungen

[Bearbeiten | Quelltext bearbeiten]

Internationalen Standards für sichere Systeme wie IEC 61508, DO-178B, EN 50128 und ISO 26262 fordern Nachverfolgbarkeit von Anforderungen und Tests. Mit TPT können Requirements beispielsweise aus dem Werkzeug DOORS importiert werden, Testfälle mit den Anforderungen verlinkt werden und die Daten miteinander synchronisiert werden. Abdeckungs- und Nachverfolgbarkeitsanalysen sind möglich. Beim Import geänderter Anforderungen werden betroffene Testfälle markiert und können somit gezielt an neue Spezifikationen angepasst werden.

  • Eckard Lehmann: Time Partition Testing. Systematischer Test des kontinuierlichen Verhaltens von eingebetteten Systemen. Technische Universität Berlin, Fakultät IV – Elektrotechnik und Informatik, 2004, doi:10.14279/depositonce-743 (Dissertation).
  • Menno Mennenga, Christian Dziobek, Iyad Bahous: Modell- und Softwareverifikation vereinfacht. In: Elektronik Automotive. Heft 4, 2009 (piketec.com [PDF; 314 kB]).

Einzelnachweise

[Bearbeiten | Quelltext bearbeiten]
  1. siehe Herstellerseite: http://piketec.com/
  2. Benjamin Wilmes: Hybrides Testverfahren für Simulink/TargetLink-Modelle, Dissertation, TU-Berlin, Germany, 2015. [1]
  3. Jens Lüdemann: AUTOSAR-Komponententest mit TPT, In: 2. Elektronik automotive congress in Ludwigsburg, Germany, 2010. PDF-Artikel
  4. Jens Lüdemann: Automatic ASAM MCD-3 supported Test, In: Open Technology Forum at the Testing Expo in Stuttgart, Germany, 2009. PDF-Artikel
  5. Modellbasierte Entwicklung eingebetteter Fahrzeugsoftware bei DaimlerChrysler In: Informatik – Forschung und Entwicklung Volume 20, Numbers 1–2 (2005), 3–10; Springer Berlin / Heidelberg. Springerlink.com, 9. Juli 2001, abgerufen am 8. August 2013.
  6. Hauser Automotive Website (Memento vom 24. November 2015 im Internet Archive). Abgerufen am 16. März 2015.