ESE Fachwissen
Testen von Model-to-Code-Tools mit 3 Methoden
Autor: Martin Wildmoser, Validas AG
Beitrag - Embedded Software Engineering Kongress 2016
Fehler in Model-to-Code Tools können systematische Fehler in die damit entwickelte Software injizieren. Die Sicherheitsnorm ISO 26262 fordert daher, dass das Vertrauen in solche Werkzeuge über Maßnahmen wie z.B. einer Tool-Validierung gerechtfertigt wird. Die Validas AG setzt zur Tool-Validierung vorwiegend 3 Testentwurfsmethoden ein: Equivalence Classes, Error Guessing und Random Testing. Über diese drei Methoden wurden eine Vielzahl von Fehlern in Codegeneratoren für Simulink (SL), Stateflow (SF) und Embedded MATLAB (EM) und C-Compilern entdeckt. Über eine systematische Auswertung der gefundenen Fehler vergleichen wir die drei genannten Testentwurfsmethoden untereinander bezüglich Effektivität und Effizienz. Die dabei gewonnen Kennzahlen resultieren aus realen Tools und Projekten und liefern damit einen Beitrag zur fundierten Einschätzung der drei Testentwurfsmethoden bei Anwendung auf Model-to-Code Tools.
Modellbasierte Softwareentwicklung erfordert den Einsatz von Model-to-Code (M2C) Tools, die Modelle zu Binärcode transformieren. M2C-Tools (s. Bild 1, PDF) bestehen i.d.R. aus einer Kette von Tools, z.B. C-Code Generator und C-Compiler.
Das Modell kann auf dem PC simuliert werden (Model-In-The-Loop, MIL), was in der Regel sehr viel schneller und kostengünstiger ist, als den generierten Binärcode auf einem Target Prozessor auszuführen (Processor-In-The-Loop, PIL). An ein M2C-Tool stellt sich dabei typischerweise folgende operationelle Hauptanforderung:
„Das M2C-Tool soll aus einem Modell verhaltensäquivalenten Code generieren.“
Die Zielsetzung für das M2C-Tool ist es Code zu generieren, der unter Ausführung auf dem Target möglichst präzise das Simulationsverhalten am PC nachbildet, d.h. es gilt eine M2C-Verhaltensäquivalenz. Relative M2C-Abweichungen, die eine festgelegte Toleranz überschreiten, z.B. 10-5, werden dabei per Definition als Instanz eines M2C-Fehlers angesehen. Dabei spielt keine Rolle, ob tatsächlich ein „Tool-Bug“ vorliegt, oder ob die Abweichung andere Ursachen hat, z.B. niedrigere Rechengenauigkeit bei PIL.
Bei einer Tool-Validierung eines M2C-Tools geht es darum, die geforderte M2C-Verhaltensäquivalenz durch eine Validierungssuite nachzuweisen bzw. die gefährlichen Modellierungssituationen, die M2C-Fehler auslösen, aufzudecken. Die Validierungssuite besteht dabei aus einer für den Praxiseinsatz des M2C-Tools repräsentativen Menge von Testmodellen. Diese Testmodelle werden für Back-To-Back Tests („MIL vs PIL“) herangezogen, d.h. man führt das Modell und den daraus generierten Code für die gleichen Eingabewerte (Stimuli) aus und vergleicht die jeweiligen Ausgabewerte. Alle dabei beobachteten Abweichungen oberhalb der Toleranz werden analysiert, einem bereits bekanntem oder neuem M2C-Fehler (Finding) zugeordnet und bezüglich möglicher Gegenmaßnahmen, z.B. Modellierungsrichtlinien, diskutiert. Einfache Beispiele für M2C-Fehler werden bereits in einem anderen Artikel [3] beschrieben. Dieser Artikel setzt den Fokus auf Testentwurfsmethoden für Testmodelle. Testentwurfsmethoden für Software werden bereits seit vielen Jahren untersucht, allerdings stellen Survey Papers ([3], [4], [5]) fest, dass die Ergebnisse teils widersprüchlich und schwer vergleichbar sind. Die Methoden „Equivalence Classes“ und „Error Guessing“ werden von der ISO 26262 empfohlen. Auch wenn M2C-Tools selbst auch Software sind, gibt es doch einige gravierende Unterschiede zwischen Embedded Software und M2C-Tools. Ein Unterschied liegt beispielsweise in der Eingabedomäne. Während die Funktionen einer Embedded Software i.d.R. einfache Zahlen als Ein- und Ausgabe haben, haben wir es bei M2C-Tools mit Modellen zu tun, d.h. einem multi-dimensionalen, stark strukturierten und komplexen Raum von möglichen Eingaben. Nach Kenntnis des Autors gibt es bisher wenig publizierte Erfahrungen darüber, wie die genannten Testentwurfsmethoden überhaupt auf diese Testsituation angewendet werden können, oder darüber welche Methoden sich dafür besonders eignen. In diesem Artikel wollen wir einen kleinen Beitrag hierzu leisten.
Equivalence Classes
Bei der Testentwurfsmethode „Equivalence Classes“ (EC) leiten wir aus der Hauptanforderung systematisch Klassen von Modellen ab von denen wir annehmen, dass sich das M2C-Tool ähnlich verhalten wird. Idealerweise haben alle Modelle einer Klasse die Fähigkeit eine bestimmte Art von Fehler im M2C-Tool aufzudecken bzw. eine bestimmte spezifische Teilanforderung zu prüfen. Diese Teilanforderungen identifizieren wir über eine systematische Strukturierung der vorliegenden Modellierungssprachen anhand der unterstützten grafischen oder textuellen Elemente und deren Properties.
Die Elemente bei SL sind die Blöcke, z.B. Sum-Block oder Gain-Block. Die Properties sind die Details, die sich bei den Blöcken jeweils einstellen lassen, z.B. OutDatatype oder Gain-Faktor. In analoger Weise lassen sich auch SF und EM über Elemente und deren Properties strukturieren.
Nach der Einteilung des Eingaberaums in Elemente und Properties lassen sich über folgende Kombinatorik 2 verschiedene Arten von Tests definieren:
a) Intra-Element-Tests: Testmodelle, die sich jeweils auf ein Modellierungselement konzentrieren. Das Ziel ist dabei möglichst alle äquivalenten Kombinationen von Properties abzudecken.
b) Inter-Element-Tests: Testmodelle, die sich auf bestimmte Kombinationen von Elementen konzentrieren. Das Ziel ist dabei möglichst alle äquivalenten Kombinationsmöglichkeiten von jeweils 2 oder mehr Elementen abzudecken.
Error Guessing
Bei der Testentwurfsmethode „Error Guessing“ (EG) lassen wir uns von unserer Erfahrung für mögliche schwierige Situationen für das M2C-Tool leiten. Wir analysieren Listen von bekannten Fehlern (Known Bugs) oder befragen Anwendungsexperten, um eine Liste von sogenannten „typischen Fehlersituationen“ aufzustellen. Für jede identifizierte Fehlersituation entwickeln wir jeweils Testmodelle, die das M2C-Tool mit der entsprechenden Situation herausfordern.
Random Testing
Bei der Testentwurfsmethode „Random Testing“ (RT) entwickeln wir einen Zufallsgenerator für Modelle. Bei Simulink und Stateflow ist dazu zunächst ein zufälliger Graph zu generieren, der die Verschaltung der Elemente definiert. In einem weiteren Schritt werden die Knoten des Graphs über zufällig ausgewählte (passende) Elemente besetzt. In einem dritten Schritt werden die Properties der Elemente zufällig variiert. Bei den Stateflow Actions und Embedded MATLAB Functions wird die Grammatik der jeweiligen Sprache herangezogen und durch Expansion der Regeln zufällige Terme generiert.
Entwicklung der Validierungssuite
Die drei Testentwurfsmethoden wurden bereits in den Jahren 2006-2011 für eine TargetLink Validierungssuite [1] angewendet. In analoger Weise wurden die Methoden in den Jahren 2012 bis 2015 zur Entwicklung einer Validierungssuite für Embedded Coder basierte M2C-Tools für SL-, SF- und EM-Modelle angewendet. Für jede Modellierungssprache wurde jeweils ein Testfeld EC mit „Equivalence Classes“, ein Testfeld RT mit „Random Testing“ und ein Testfeld EG mit „Error Guessing“ entwickelt. Bei jedem Testfeld waren jeweils 2-3 Personen als Entwickler tätig und weitere 1-2 Personen für die Qualitätssicherung. Die Testmodelle in jedem Testfeld sind jeweils in Testkategorien gruppiert, wobei jede Testkategorie i.d.R. von 1 Person entwickelt wurde und ein spezifisches und einheitliches Design von Testmodellen aufweist, z.B. Konzentration auf ein bestimmtes Element oder eine Element-Kombination bei EC, auf eine Fehlersituation bei EG oder auf eine Modellgröße bei RT.
Ergebnisse der Validierungssuite
Die Validierungssuite wurde auf mehrere in realen Entwicklungsprojekten verwendete M2C-Tools angewendet, die sich insbesondere über die verwendeten Target-Compiler sowie die dazugehörigen PIL-Architekturen (Power PC, Tricore, ARM Cortex R4) unterschieden. Die folgende Tabelle (s. Tabelle 1, PDF) stellt die gefundenen Fehler und andere Kennzahlen für eines dieser M2C-Tools dar. Die Zahlen für die anderen validierten M2C-Tools sind jeweils ähnlich groß und verteilt. Die Tabelle zeigt absolute Kennzahlen zur Größe der Testfelder, dem Aufwand für die Entwicklung und Anwendung der Testmodelle in Zeiteinheiten (ZE), der Produktivität in Anzahl Outports pro ZE, der Effektivität in Anzahl der M2C-Fehler (#Findings) und der Effizienz in Anzahl M2C-Fehler pro ZE. Die Größe eines Testfelds bemessen wir dabei in der Anzahl der Outports der darin enthaltenen Testmodelle. Jeder Outport modelliert eine bestimmte Funktion und stellt das M2C-Tool vor die Aufgabe daraus verhaltensäquivalenten Code zu generieren. Ein direkter Vergleich der Effektivität der Testentwurfsmethoden ist auf Basis dieser Darstellung jedoch nicht fair, da deutliche Unterschiede in der Größe der Testfelder bestehen. Die Größe der RT Testfelder ließe sich zwar relativ einfach erhöhen, allerdings ist bei den so erzeugten Testmodellen der Aufwand für die Analyse der M2C-Abweichungen besonders hoch und damit der limitierende Faktor. Bei RT wurde zudem beobachtet, dass eine kleine Teilmenge von M2C-Fehlern häufig auftritt, d.h. sich in vielen M2C-Abweichungen manifestiert. Jede M2C-Abweichung muss einzeln analysiert werden, bevor man sie einem bestimmten M2C-Fehler zuordnen kann.
Vergleichsmethode
Um die 3 Testentwurfsmethoden bezüglich ihrer Effektivität fair zu vergleichen führen wir für SL, SF und EM jeweils eine statistische Analyse durch. Dazu entnehmen wir aus jedem der 3 Testfelder (k Î{1, 2, 3}) jeweils 30 Samples Sk,i mit iÎ{1,…,30}. Jedes Sample Sk,i besteht aus 50 zufallsbasiert ausgewählten Outports aus dem Testfeld k. Die Auswahl erfolgt ohne Zurücklegen und so, dass jede Testkategorie innerhalb des Testfelds die gleiche Chance hat bei jeder Einzelauswahl zum Zuge zu kommen (unabhängig von der Größe der Testkategorie). Mit Fk,i bezeichnen wir die Vereinigungsmenge aller M2C-Fehler (Ticket IDs), die durch die Outports aus Sk,i gefunden werden.
Wir modellieren die Effektivität der Testentwurfsmethode k bei Anwendung über einen sehr langen Zeitraum und Erstellung einer sehr großen Population von Testmodellen über die Zufallsvariable Xk. Für diese Zufallsvariable liegen uns folgende Stichprobenwerte vor:
xk,i = |Fk,i| (Anzahl der M2C-Fehler, die durch Sample Sk,i entdeckt werden)
Um neben der reinen Fehleranzahl auch ein Maß für die Fehlervariation über die Samples hinweg zu bekommen, führen wir weiter folgende abhängige Zufallsvariable Y ein, mit folgenden Stichprobenwerten:
yk,i = |Fk,i - Uj<iFk,j| (Anzahl neuer M2C-Fehler, die durch das Sample Sk,i entdeckt werden.)
Um Herauszufinden, ob sich die 3 Testentwurfsmethoden bezüglich der Erwartungswerte µx1, µx2 und µx3 unterscheiden, wenden wir eine Kruskal-Wallis Varianzanalyse [6] (MATLAB Funktion kruskalvallis) zum Test folgender Nullhypothese an:
Ho: µx1 = µx2 = µx3 (gleiche Anzahl gefundener Fehler pro Sample erwartet)
Der Stichprobenumfang von 30 Samples wurde unter Vorgabe eines Konfidenzniveaus von 1 - a= 95% und einer Teststärke von 1 - b= 90% geplant.
Vergleichsergebnisse
In allen drei Fällen (s. Tabelle 2, PDF) trat ein signifikantes Ergebnis auf (p < a = 0,05), das auf einen systematischen Unterschied zwischen den drei Testentwurfsmethoden hindeutet. Bei SL wurden beispielsweise pro Sample im Durchschnitt 4.6 Fehler durch Equivalence Classes gefunden (davon ca. 0.7 neu), 3.3 durch Error Guessing (davon ca. 0.5 neu) und nur 2.4 durch Random Testing (davon ca. 0.3 neu). Bei SF und EM treten analoge Unterschiede auf, wobei RT deutlich weniger Treffer lieferte.
Zusammenfassung und Schlussfolgerung
Wir haben in einem realen Industrieprojekt zum Testen von M2C-Tools beobachtet, dass unabhängig von der Modellierungsart (SL, SF, EM) durch Equivalence Classes im Schnitt mit 3.4 - 4.6 die meisten M2C-Fehler pro Sample gefunden wurden. Error Guessing kommt mit 2.3 - 3.3 auf Platz 2 und Random Testing mit 0.1 – 2.4 auf Platz 3. Alle drei Methoden fanden zum Teil Fehler, die durch die anderen Testentwurfsmethoden nicht gefunden wurden. Meine Empfehlung für das Testen von M2C-Tools lautet daher, eine Kombination von mehreren Testentwurfsmethoden einzusetzen.
Literatur- und Quellenverzeichnis
[1] Schneider S., Lovric T., Mai P.; The Validation Suite Approach to Safety Qualification of Tools; SAE World Congress 2009, Detroit, MI, USA; SAE Tech Paper 2009-01-0746
[2] Wildmoser M., Jeschull R.; Testen mit der Röntgenbrille – Model-to-Code Fehler durch dynamische Modellanalyse erkennen; Tagungsband Embedded Software Engineering Kongress 2014; ISBN 978-3-8343-2409-2
[3] Juristo N., Moreno A.; Reviewing 25 years of Testing Technique Experiments; Journal Empirical Software Engineering Vol 9. Issues 1-2, March 2004, pages 7-44.
[4] Sheikh U. Farroq, SMK Quadri; Empirical Evaluation of Software Testing Techniques – Need, Issues and Mitigation; Software Engineering: An international Journal (SEIJ), Vol. 3 Nr. 1, 2013
[5] Tyagi M., Malhotra S.; A Review of Empirical Evaluation of Software Testing Techniques with Subjects; International Journal of Advanced Research in Computer Engineering & Technology (IJARCET); Vol. Issue 2; 2014
[6] Kruskal W. H., Wallis, W. A.; Use of ranks in one-criterion variance analysis, in: Journal of the American Statistical Association, Vol. 47, 1952, S. 583-621
Danksagung
Wir danken dem BMBF für die Förderung dieser Arbeit im Rahmen des Forschungsprojekts SPEDiT (01IS15058H).
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.
Fachwissen zu weiteren Themen unseren Portfolios finden Sie hier.