Experience Embedded

Professionelle Schulungen, Beratung und Projektunterstützung

Automatisierte Assessments und Traceability für den Modelltest

Autor: Dr. Hartmut Pohlheim, Model Engineering Solutions

Beitrag - Embedded Software Engineering Kongress 2015

 

 

Es wird eine Methode vorgestellt, die es ermöglicht, Anforderungen auf allen Testsequenzen zu testen und automatisiert auszuwerten. Somit werden der Testaufwand und die Fehleranfälligkeit reduziert. Weiterhin wird eine Methode vorgestellt, die das geforderte Requirement-Tracing in der Praxis unterstützt. Die Kombination beider Methoden in einem effizienten Test-Tool führt zu einer signifikanten Steigerung der Testabdeckung und der Verlässlichkeit der Testergebnisse.

Immer komplexer werdende Software in Verbindung mit hohen Qualitätsansprüchen macht effizientes Testen unverzichtbar. Speziell durch die ISO 26262 ist es in der modellbasierten Entwicklung unerlässlich, effiziente Techniken zum Testen zu entwickeln. Die durch die Norm geforderte Testabdeckung in Verbindung mit Requirement-Tracing und der Empfehlung zu anforderungsbasiertem Testen führen dazu, dass bisherige Testmethoden überdacht werden müssen [1].

In diesem Zusammenhang stellen wir eine Methode zur automatischen Prüfung anforderungsbasierter Modelltests vor, mit der nicht nur eine höhere Testabdeckung gewährleistet werden kann, sondern darüber hinaus ein verlässliches Tracing durch ein speziell zu diesem Zweck entwickeltes Framework möglich ist.

Die Kombination der automatisierten Assessments und des automatisierten Requirement-Tracings sind in einem Test-Tool für Simulink®-, Embedded Coder®- und TargetLink®-Modelle integriert, mit dem die Forderungen der ISO 26262 mit erheblich geringerem Aufwand erfüllt werden können [2].

Integrierter Ansatz für den anforderungsbasierten Test

Wie der Name verdeutlicht, bilden die Anforderungen die Grundlage des anforderungsbasierten Testens. Ausgehend vom Lastenheft der Software beginnt der Tester damit, alle Stimulationen der Anforderungen abzuleiten, die zum Test der Software notwendig sind. Diese dienen als Input des zu testenden Modells. Nach einer Anzahl erfolgter Simulationen, auch Testsequenzen genannt, stehen die aufgezeichneten Output-Signale zur Verfügung. Mit diesen Signalen kann nun die Testbewertung bezüglich der Einhaltung geltender Anforderungen erfolgen. Mit der Erhebung der Execution-Coverage kann zusätzlich geprüft werden, ob die angewandte Menge an Stimulationen für eine Bewertung ausreichend ist (Abb. 1, siehe PDF).

Klassischerweise erfolgte eine Software-Bewertung durch visuelle Begutachtung der Ausgangssignale. Dadurch müssen die Stimulationen oft sehr einfach gehalten werden, um die aufwendige manuelle Bewertung zu vereinfachen oder gar erst zu ermöglichen.

Dieser Beitrag präsentiert einen weiterentwickelten Ansatz zur verbesserten und vor allem automatisierten Bewertung anforderungsbasierter Testfälle. Insbesondere bricht er mit der strengen Verbindung von Testfällen und Anforderungen. Die automatische Bewertung erfolgt durch ein entsprechend entwickeltes Framework zur formellen Prüfung von Anforderungen. Dieser Ansatz zeichnet sich dadurch aus, dass eine einmalig in einem Assessment formulierte Prüfung wiederverwendbar ist und auf allen erdenklichen Systemantworten angewendet werden kann. Dies unterstreicht zum einen den allgemeingültigen Charakter von Anforderungen und hilft zum anderen Fehler aufzudecken, die zuvor nicht antizipiert worden sind.

Diese Methode beruht generell auf drei charakteristischen Elementen: der Anforderung, der Testspezifikation und den Assessments. Um deren starke Abhängigkeiten untereinander stets zu überblicken, ist es im Sinne des in der ISO 26262 geforderten Tracings unablässig, diese jederzeit nachzuverfolgen. Hierfür wurde das Framework „Requirements, Coverage, and Traceability“ (RCT) entwickelt, welches auf komfortable Weise die Anforderungsverfolgung unterstützt.

Die Kombination beider Ansätze in einem Test-Tool ermöglicht somit einen integrierten Ansatz für einen modern gestalteten und effektiven Testprozess (Abb. 2, siehe PDF).

Automatische Testevaluierung mit Assessments

Ein Grundprinzip der Assessments ist deren Wiederverwendbarkeit. Ein Assessment kann als eine Funktion verstanden werden, welches die aufgezeichneten In- und Output-Signale sowie die lokalen Signale und Parameter untersucht (Abb. 3, siehe PDF).

Hiermit prüft das Assessment die Invarianz des Systemverhaltens und stellt das Ergebnis für jede Sequenz einzeln bereit. Dabei sind drei Ergebniswerte möglich: Passed (das Verhalten entspricht der geltenden Anforderung), Failed (im Verlauf der Testsequenz wurde eine Verletzung der Anforderung detektiert) und NotTriggered (die Testsequenz hat nicht zu einer Stimulation dieser Anforderung geführt).

Im Gegensatz zu einer direkten Prüfung von n Testsequenzen mit genau n erwarteten Ergebnissen (Abb. 4, links, siehe PDF), liefert die Matrixevaluierung mit Hilfe von Assessments eine deutlich höhere Testabdeckung durch m*n Evaluierungen, da hier ein Satz von m Anforderungen, durch m Assessments geprüft wird und diese Prüfung auf allen n Testsequenzen erfolgt (Abb. 4, rechts, siehe PDF). Die Matrixevaluierung ermöglicht zudem die Aggregation der Ergebnisse auf Ebene der Testsequenzen und Assessments. Dies führt unmittelbar zu einer höheren Verlässlichkeit der Prüfergebnisse.

Um diese Reihe von Aufgaben erfüllen zu können, besteht ein Assessment aus einem beschreibenden Anteil und einem evaluierenden Ausführungsteil. Der erste Teil umfasst u.a. die Traceability-Informationen und einem Beschreibungstext. Im zweiten Teil finden als Post-Processing der Testsequenz der Signalzugriff und deren Bewertung statt (Abb. 5, siehe PDF).

Um einen schnellen Einstieg zu ermöglichen steht ein Template-Generator zur Verfügung. Anforderungen und benötigte Signale können ausgewählt werden und mit wenigen Eingaben wird automatisch ein passendes Template für die Assessments bereitgestellt.

Selbst zu befüllen sind im Beschreibungsteil der Name und die Description des Assessments (Abb. 6, siehe PDF). Für die Evaluierung muss unter Triggered die Bedingung formuliert werden, unter der die Anforderung gültig ist. Mit den bereitgestellten Hilfsfunktionen kann daraus die Prüfung implementiert werden, wie im gezeigten Beispiel eine klassische „Wenn-Dann“-Beziehung. Zulässige Reaktionszeiten des Systems können ebenfalls berücksichtigt werden (Abb. 7, siehe PDF).

Nachdem alle Testsequenzen zu der Evaluierung einer Anforderung beigetragen haben, können deren Ergebnisse aggregiert werden. Die Darstellung des Gesamtergebnisses mit zugehörigen Metriken unseres Beispiels ist in Abb. 8 (siehe PDF) gegeben. Hierbei genügt eine einzige Verletzung der Anforderung um als Endresultat ein Failed zu erhalten.

Anforderungsverfolgung und Darstellung der Ergebnisdaten

Charakteristisch für den vorgestellten Modelltest ist, dass Testsequenzen wie Assessments stets Bezug auf Anforderungen nehmen. Hieraus entsteht eine Vielzahl an Verknüpfungen (Abb. 9, siehe PDF), deren Nachverfolgung in der Praxis oft eine große Herausforderung für den Tester darstellt.

Um diesen Prozess zu unterstützen, haben wir das RCT-Framework entwickelt. Es folgt automatisiert den Verknüpfungen und ermöglicht somit die klare Nachverfolgung von Anforderungen. Als zentrale Elemente dienen hier die IDs der Anforderungen. Der Tester muss lediglich auf diese Bezug nehmen – sowohl innerhalb der Testspezifikationen, als auch der Assessments. Dieses Framework stellt hierfür die entsprechenden Möglichkeiten bereit (Abb. 10, siehe PDF). Eine Methode zur Testspezifikation (MTCD), die den hier vorgestellten Prozess unterstützt ist in [3] vorgestellt.
Sind alle Bezüge hinterlegt, wird eine Berichtsübersicht bereitgestellt, die nicht nur alle geltenden Anforderungen zusammenfasst, sondern auch detaillierte Informationen über die jeweiligen Testsequenzen und Assessments liefert – sowie Angaben zu deren Bearbeitungsfortschritt macht (Abb. 11, siehe PDF).

Das RCT-Dashboard enthält außerdem wichtige Angaben über den Erfüllungsgrad der Anforderungen und deren Abdeckung mit Testsequenzen und Assessment, was eine Aussage zur funktionalen Güte des getesteten Software-Moduls ermöglicht. Metriken zur Bewertung der Testqualität werden ebenfalls bereitgestellt. Darunter zählen u.a. der Fortschrittsgrad des Reviews von Testsequenzen und Assessments sowie die Werte für Modell- bzw. Code-Coverage (Abb. 12, siehe PDF).

Umgang mit Anforderungsänderungen

Der Report des RCT-Frameworks dient zum einen als wichtiges Dokumentationselement. Zum anderen ist es ein effektives Arbeitsinstrument, in dem der Tester seinen Arbeitsaufwand ablesen kann, insbesondere bei Änderung des Anforderungsdokuments.

Durch das RCT-Framework kann auf einfache Weise das neue Anforderungsdokument in das bestehende Projekt geladen werden. Die Differenzanalyse von RCT identifiziert die geänderten Anforderungen und setzt den Bearbeitungstand der mit ihnen verknüpften Elemente zurück. Hierdurch sinken in der Praxis zunächst die Kennzahlen des Testprojekts. Des Weiteren wird die Teilmenge an betroffenen Testsequenzen und Assessments angezeigt, sodass eine gezielte und somit zeitsparende Revision dieser Elemente möglich ist – stets mit dem Ziel, die ursprünglichen Kennzahlen wieder zu erreichen bzw. zu übertreffen (Abb. 13, siehe PDF).

Zusammenfassung

Der vorliegende Betrag zeigt, wie es methodisch möglich ist, zu einer höheren Testabdeckung zu gelangen. Die Anwendung des hierfür entwickelten Frameworks zur automatischen Anforderungsprüfung mittels Assessments unterstützt den Anwender dadurch in der Praxis im hohen Maße. In Zukunft werden Testsequenzen mehr und mehr die Aufgabe übernehmen, dass zu testende System ausreichend zu stimulieren, um die hohen geforderten Coverage-Werte zu erzielen. Die Prüfung und Sicherstellung der Anforderungserfüllung erfolgt effizient durch die Assessments.

Zudem wurde gezeigt, dass auch das in der Norm geforderte Tracing tool-basiert und effizient unterstützt werden kann. Die Anwendung des entsprechenden Frameworks ermöglicht bereits im laufenden Testprozess nicht nur eine Bewertung der funktionalen Güte, sondern Aussagen über die Qualität des Tests als solches.

Die Kombination beider Ansätze zeigt, wie schon heute ein moderner anwendungsbasierter Modelltest gestaltet sein kann.

 Literatur

[1]

ISO, ISO 26262: Road vehicles -- Functional safety, International Standard ISO/FDIS 26262, 2011.

[2]

Model Engineering Solutions GmbH, 2015. [Online]. Available: http://www.model-engineers.com/de/mtest.html.

[3]

Schmidt, Tobias, et al. Efficient Testing Framework for Simulink Models with MTCD and Automated Test Assessments in the Context of ISO 26262. SAE International Journal of Passenger Cars-Electronic and Electrical Systems 7.2014-01-0306 (2014): 166-177.

 

 

Beitrag als PDF downloaden

 


Test, Qualität & Debug - unsere Trainings & Coachings

Wollen Sie sich auf den aktuellen Stand der Technik bringen?

Dann informieren Sie sich hier zu Schulungen/ Seminaren/ Trainings/ Workshops und individuellen Coachings von MircoConsult zum Thema Test, Qualität & Debug.

 

Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie hier.


Test, Qualität & Debug - Fachwissen

Wertvolles Fachwissen zum Thema Test, Qualität & Debug steht hier für Sie zum kostenfreien Download bereit.

Zu den Fachinformationen

 
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.