Close
Banner PikeTec Sitemap

Glossar der Testbegriffe.

Abnahmetest, Acceptance Test

Beim Abnahmetest wird die Übereinstimmung des entwickelten Systems mit den Kundenanforderungen geprüft. Der Kunde entscheidet dabei, ob er das System akzeptiert oder nicht. Der Abnahmetest erfolgt unter normalen Betriebsbedingungen.

Anforderungsabdeckung

Die Anforderungsabdeckung zeigt an wie viele Anforderungen im Verhältnis zu vorhandenen Anforderungen abgedeckt sind. Die Anforderungsabdeckung ist ein Testendekriterium.

Anforderungsbasierter Test

Beim anforderungsbasierten Test werden die Anforderungen an ein zu testendes System (SUT) analysiert und daraus Testfälle abgeleitet. Der Tester analysiert die Anforderungen und überlegt sich, wie jede einzelne Anforderung an das System geprüft werden kann.

Häufig werden anforderungsbasierte Testfälle mit Anforderungen verknüpft. Ziel der Verknüpfung ist es, nachzuverfolgen welche Anforderungen durch Testfälle abgedeckt werden bzw. sicherzustellen, dass jede Anforderung durch mindestens einen Testfall abgedeckt ist. Eine Anforderung gilt dann als erfüllt, wenn alle ihr zugewiesenen Testfälle erfolgreich waren. 

In TPT können Anforderungen importiert und mit Testfällen verlinkt werden. So ist sofort ersichtlich, welche Anforderungen geprüft werden und für welche Anforderungen noch Testfälle erstellt werden müssen.

Anweisungsüberdeckung, Statement Coverage

Die Anweisungsüberdeckung stellt ein Testkriterium dar, bei dem die Anzahl der bei einem Test durchlaufenen Programmanweisungen im Vergleich zur Gesamtzahl enthaltener Anweisungen (in Prozent) betrachtet wird.

Anweisungsüberdeckung  =  Anzahl besuchter (ausgeführter) Anweisungen/Gesamtzahl von Anweisungen

Äquivalenzklassentest

Äquivalenzklassentest basiert auf der Idee, dass viele ähnliche Eingaben des Testobjekts gleiches Verhalten bewirken, während viele andere Eingangswerte dieses Verhalten nicht auslösen. Diese Gruppe ähnlicher Eingangswerte werden quasi in eine Schublade gelegt, die dann Äquivalenzklasse genannt wird. Es wird angenommen, dass man nur einen oder wenige repräsentative Werte (Repräsentanten) einer Äquivalenzklasse für den Test auswählen muss und trotzdem eine gute funktionale Abdeckung erlangt. Diese Repräsentanten einer Äquivalenzklasse könnten neben einem Zufallswert auch Werte an den Grenzen der Äquivalenzklasse sein, da hier besonders kritische Verhaltensänderungen am zu testenden System zu erwarten sind. In diesem Fall spricht man von Grenzwerttests.

Bei einem automatischen Lichtsystem wären bspw. „hell“, „ dunkel“ und „zu hell“ Äquivalenzklassen für die Beleuchtungsstärke, die ganzzahlige Werte zwischen Null und 100 annehmen kann. Während im Beispiel „dunkel“ von Null bis 50 wäre und „hell“ von 50 (exklusive) bis 100 wäre, ist „zu hell“ für unzulässige Werte größer 100 definiert. Das System verhält sich immer gleich und schaltet das Licht aus, wenn die Beleuchtungsstärke „hell“ ist und schaltet immer ein, wenn es „dunkel“ ist. Werte größer 100 können nicht auftreten, sind also verboten. Ein Äquivalenzklassentest würde also beispielsweise die Werte 17, 89 und 101 testen. Die Repräsentanten sind hier zufällig gewählt. Für den Grenzwerttest würden bspw. 0, 50, 51, 100, und 101 hinzukommen.

Beim Äquivalenzklassentest wird für jede Äquivalenzklasse ein Testfall erstellt und so die Testmenge eingeschränkt. Dies ist weniger aufwendig als jeden Wert in einem Wertebereich zu prüfen, was häufig unmöglich ist.

Die Sicherheitsnorm ISO26262 empfiehlt für ASIL-B, ASIL-C und ASIL-D dringend die Äquivalenzklassenmethode anzuwenden, da damit leicht und systematisch eine begrenzte Anzahl guter Eingangswerte für das Testobjekt gefunden werden können.

In TPT können Äquivalenzklassen gebildet werden, die dann symbolisch in der Testmodellierung verwendet werden können.  Abdeckungsprüfungen für Äquivalenzklassen sowie die automatische Testfallgenerierung basierend auf Äquivalenzklassen sind möglich.

ASAM XIL API

Die ASAM XiL API beschreibt die Kommunikation zwischen Testautomatisierungswerkzeugen und Prüfständen in MiL, SiL und HiL. Das X in XiL bedeutet, dass es für alle „in-the-loop“ Umgebungen geeignet ist.  Mehr Infos unter https://www.asam.net/standards/detail/xil/

TPT unterstützt die ASAM XiL API.

ASIL

ISO 26262 unterscheidet – risikobasiert – vier „Automotive Safety Integrity Level (ASIL)“ auf einer Skala von A bis D, wobei D die höchste Sicherheitsstufe klassifiziert. Die Anforderungen an die Entwicklung, den Betrieb eines Fahrzeugs steigen mit jeder ASIL-Stufe. Die ASIL-Einstufung eines konkreten Systems erfolgt nach einer Gefährdungs- und Risikoanalyse.

Zu den geforderten Maßnahmen gehört in der Entwicklung neben Anforderungen an Software-Entwicklung und -Test auch ein Nachweis über die „Confidence in the use of software tools“.

Sicherheitsstandards mit TPT.

Automatisierte Fahrzeugtests

Ein automatisierter Fahrzeugtest bezeichnet die Ausführung und Bewertung von vordefinierten Testfällen direkt im Fahrzeug mittels einem Testing Tool wie TPT. Abhängig von den Anforderungen des Fahrzeugtests, kann entweder der TPT Autotester oder das TPT Dashboard, das PikeTec eigens dafür entwickelt hat, verwendet werden.

Back-to-Back Test

Das ISTQB definiert Back-to-Back-Tests als den Vergleich von zwei oder mehr Varianten eines Testobjekts. Die Varianten werden mit den gleichen Testfällen ausgeführt und die Ergebnisse miteinander verglichen.  

Beim Back-to-Back-Testing [Link auf Neue Unterseite Back-toBack-Testing] gilt ein Testfall als erfolgreich bestanden, wenn die Ergebnisse der verschiedenen Versionen gleich sind. 

Ein Anwendungsbeispiel ist der MiL-SiL-Vergleich, bei dem gegebenfalls auch Toleranzen zugelassen werden um numerische Fehler auszublenden. 

Generell soll der Back-to-Back-Test sicherzustellen, dass bei einem Wechsel der Testphase, dh. von MiL zu SiL, von SiL zu PiL, von Pil zu HiL, die Testergebnisse nur unwesentlich abweichen. Die ISO26262 fordert ausdrücklich den Vergleich der Ergebnisse zwischen den Testphasen. Back-to-Back-Tests werden auch angewandt, um zu sicherzustellen, dass mehrere Softwarekomponenten mit denselben Anforderungen, identische Ergebnisse liefern.

Mit TPT sind vollautomatische Back-to-Back Tests sehr einfach konfigurierbar. Meist unterschieden sich die Testergebnisse marginal, sodass ein Toleranzband um die Referenzsignale die Robustheit deutlich erhöht. Zeit- und Wertetoleranzen sind in TPT einfach einstellbar.

Bedingungsüberdeckung, Condition Coverage

Die Bedingungsüberdeckung stellt ein Testkriterium dar, bei dem die Anzahl der jeweils auf True und False gesetzten elementaren Bedingungen des Testobjektes im Verhältnis zur doppelten Ge­samtanzahl von Elementarbedingungen (in Prozent) betrachtet wird.

Die Condition Coverage berücksichtigt bei einer boolschen Auswertung zur Verzweigung jede einzelne Komponente, die zum boolschen Ergebnis geführt hat.
Bemerkung: Eine vollständige Bedingungsüberdeckung (100%) kann eintreten, ohne dass eine vollstän­dige Zweigüberdeckung vorliegt, d.h. die Zweige werden nicht zwangsläufig alle durchlaufen.

Ein Beispiel aus der Programmiersprache C: Sei if (A && B) {case1} else {case2} eine Funktion, so sind A und B die Elementarbedingungen. Die Bedingungsüberdeckung von 100% ist erfüllt, wenn so­wohl A als auch B jeweils mit True und False belegt waren. Die beiden Testfälle ‘A=True, B=False’ sowie ‘A=False, B=True’ liefern also 100% Bedingungsüberdeckung; der Zweig case1 wird jedoch nie erreicht.

Black-Box-Test

Black-Box-Testing ist ein dynamisches Testverfahren um die Funktionalität von Software hinsichtlich ihrer Spezifikation zu überprüfen. Beim Black-Box-Test ist die interne Struktur des Testobjektes unbekannt oder wird bewusst nicht betrachtet. Allein die Spezifikation wird beim Test berücksichtigt.

Zu der Klasse der Black-Box-Tests gehören die Funktionstests, Zufallstests, statische Tests usw. Im engeren Sinne wird der Begriff Black-Box-Test häufig auch als Synonym für Funktionstests verwendet. 

Testmodellierung with TPT.

Siehe auch: https://de.wikipedia.org/wiki/Black-Box-Test

Branch Coverage

Code Coverage

Die Code Coverage findet beim White-Box-Testen Anwendung und ist ein Maß dafür, inwieweit programmierter Code ausgeführt wurde. Werden mehrere Testfälle ausgeführt, wird die Code Coverage in Prozent gemessen und gibt an wieviel Prozent des Codes bereits ausgeführt wurde und wieviel nicht. Die Code Coverage gibt Aufschluss darüber, wie weit ein Test in die Tiefe des Codes vorgedrungen ist, und ob der Code ausführbar war. Wenn bspw. Code nicht ausgeführt wurde, kann man auch keine Aussage darüber machen, ob er das richtige Ergebnis liefern würde. Insofern wird die Code Coverage als Kriterium herangezogen, ob genügend getestet wurde und ist ein sogenanntes Testendekriterium.

Um Code Coverage messen zu können, muss der Code instrumentiert werden. Dies bedeutet, dass Zähler in den Code eingebaut werden, welche die Anzahl der Ausführungen an dessen Verzweigungsstellen aufzeichnen. Es gibt verschiedene Abdeckungsmaße wie bspw:

Mittels Code Coverage-Untersuchungen sollen jene Codeteile gefunden werden, die während des Tests nicht ausgeführt werden. Die Code Coverage kann damit Schwachstellen im Code und in den Tests aufzeigen, nämlich:

  • nicht getesteter Code, der aber getestet werden sollte
  • toter, nicht erreichbarer oder überflüssiger Code, der entfernt werden sollte
  • Code, der nur unter sehr großem Aufwand erreicht und getestet werden kann

Confidence in the use of software tools

Wird im Automotive-Bereich bei der Entwicklung eines sicherheitsrelevanten Systems ein Software-Tool eingesetzt, so ist nach ISO 26262 Part 8 ab ASIL A ein Nachweis erforderlich, dass dieses Werkzeug „vertrauenswürdig“ ist (Qualifizierung).

Eine Qualifizierung erfolgt in zwei Schritten. Zunächst ist eine Analyse und Klassifizierung des Tools vorzunehmen. Hier wird der Tool Impact (TI), eine Tool Error Detection (TD), ermittelt und daraus der Tool Confidence Level (TCL) abgeleitet.

Danach werden – wenn notwendig – die erforderlichen Maßnahmen abgeleitet und durchgeführt.

Coverage-Analyse

Coverage-Analysen dienen der Bewertung, ob genügend getestet wurde, oder noch weitere Testfälle notwendig sind. Die Coverage-Analyse zeigt diejenigen Stellen, für welche keine oder zu wenig Tests vorhanden sind. Dabei kommen verschiedene Abdeckungen (Coverage) zum Einsatz, bspw:

  • Anforderungsabdeckung
  • Strukturelle Abdeckung des Codes
  • Abdeckung jedes Sicherheitsmechanismus
  • Abdeckung jeder Parameterkonfiguration

Debugging

Aktivität, die sich aus Fehlerlokalisation, -analyse und -behebung zusammensetzt. Debugging ist vom Testen, das vor allem dem Aufdecken von Fehlern dient, zu unterscheiden.

Dynamisches Testen

Beim dynamischen Testen wird die zu testende Software ausgeführt und mit konkreten Eingabedaten gefüttert, um konkrete Ausgangsdaten zu erhalten. Die Testergebnisse werden mit den erwarteten Ergebnissen verglichen um herauszufinden, ob sich das Programm wie spezifiziert verhält.

Dynamische Testverfahren werden in strukturelle und funktionale Tests untergliedert. Dabei spielen sogenannte Black-Box-Tests und White-Box-Tests eine Rolle.

In Abgrenzung zum dynamischen Testverfahren, wird bei sogenannten statischen Testverfahren der Softwarecode nicht ausgeführt.

Echtzeitsystem

Als Echtzeitsystem wird ein System bezeichnet, das innerhalb einer endlichen und vorhersagbaren Zeitspanne reagieren muss. Echtzeitsysteme haben demzufolge nicht nur logisch-algorithmische Anforderungen, sondern müssen diese auch in einer bestimmten Zeit erfüllen. Die Echtzeitfähigkeit bedeutet dabei nicht zwangsläufig die Schnelligkeit eines Systems, sondern vielmehr die zeitliche Determiniertheit und die Einhaltung zeitlicher Grenzen.

Das Testwerkzeug TPT ist in der Testausführung mit der TPT-VM echtzeitfähig. Das bedeutet, dass TPT auf Echtzeitplattformen vorhersagbar die Zeitbeschränkungen einhält.

Electronic Control Unit (ECU), Steuergerät

ECU steht für Electronic Control Unit und bezeichnet Steuergeräte. ECUs sind Eingebettete Systeme, die Sensorsignale und Eingabedaten lesen und die Ausgabewerte aus diesen Daten ausrechnen. Die Ausgabewerte sind entweder direkte Ansteuerungen von Aktuatoren oder Signale an andere Steuergeräte, die beispielsweise über einen CAN-Bus kommuniziert werden. Beispiele für ECUs sind Motorsteuerung, Getriebesteuerung, Lichtsteuergerät, ESP Steuergerät, ABS Steuergerät, oder Fensterhebersteuerung.

Entscheidungsüberdeckung, Decision Coverage

Die Decision Coverage berücksichtigt lediglich ob eine Verzweigung in der Software genommen wurde, lässt das Wie aber unbeachtet.

Das heißt, hat eine verzweigte Bedingung mehrere Komponenten, wird nur das Ergebnis der Auswertung berücksichtigt, nicht aber wie es zu diesem Ergebnis kam.

Decision Coverage = Anzahl besuchter Zweige/Gesamtzahl von Zweigen

Fahrerassistenzsystem, Advanced Driver Assistance System (ADAS)

Fahrerassistenzssysteme sind elektronische Einrichtungen, die mit dem Fahrer interagieren, um ihn beim Fahren zu unterstützen. Sie dienen der Verbesserung der Sicherheit und des Fahrkomforts.
Fahrerassistenzsysteme erfassen den aktuellen Fahrzustand des Fahrzeugs, aber auch das Umfeld des Fahrzeugs, also die Straße, Verkehrszeichen, andere Verkehrsteilnehmer und Hindernisse. Für die Umfelderfassung werden verschiedenste Sensoren eingesetzt wie Ultraschallsensor (Parksensorik), Kamerasensor, Radar- und Lidarsensor.

Fahrerassistenzysteme warnen den Fahrer, greifen potentiell aber auch in das Fahrgeschehen ein und sind aus diesem Grund sicherheitsrelevant nach ISO26262; häufig werden sie mit der höchsten Sicherheitsstufe ASIL-D klassifiziert.

Beispiele für heutige Fahrerassistenzsystme sind: Abstandregeltempomat, Notbremsassistent, Totwinkelassistent, Stauassistent, Verkehrszeichenerkennung, Nachtsichtassistent, Spurhalteassistent, Spurwechselassistent und Parkassistent.
Die Zukunft der Fahrerassistenzsysteme ist das autonome Fahren.

Fehler, Failure

Ein Fehler ist die Abweichung zwischen dem beobachteten, gemessenen Wert und dem erwarteten Wert.

Bemerkung: Der Begriff Fehler wird in der deutschen Sprache in der Regel auch als Begriff für error, fault etc. verwendet und hat in diesen Fällen eine andere Bedeutung.

Fehlerinjektionstest

Fehlerinjektionstests provozieren äußere Fehler am zu testenden System (SUT) um Untersuchungen anzustellen, inwieweit sich das System robust gegenüber Fehlern und Fehlertoleranzalgorithmen verhält. Diese Tests decken Systemzustände ab, die im Normalbetrieb einer Software nicht erreicht werden.

Festkommaarithmetik

Festkommaarithmetik kommt zum Einsatz, weil einige Prozessoren keine Gleitkommaarithmetik unterstützen, oder weil Festkommaarithmetik schneller ist. Festkommaarithmetik bedeutet dabei, dass eine Zahl immer die gleiche Anzahl von Stellen hat.

Bei Berechnungen mit physikalischen Größen, müssen diese meist skaliert werden, um eine höchstmögliche Genauigkeit zu erzielen und um die Berechnungen ohne Überläufe der Daten durchführen zu können. Der Datentyp des Ergebnisses muss zur Darstellung der Zahl passen.

Funktionales Testen, Funktionstest

Das funktionale Testen oder auch Funktionstest genannt prüft, ob sich die Funktion des zu testenden Systems (SUT) entsprechend der Spezifikation verhält. Dieses Black-Box-Testverfahren prüft, ob das System bei der Ausführung das macht, was es machen soll.

Beim Funktionstest handelt es sich um eine Klasse von Testmethoden zur Testfallermittlung, bei der die Testfälle aus der Spezifikation des Testobjektes ab­geleitet werden, d.h., Interna des Testobjekts werden bei der Testfallermittlung nicht beachtet.

Funktionentest, Unit-Test

Testphase, in der eine Funktion isoliert getestet wird. Eine Funktion ist hierbei die kleinste testbare Softwarekomponente.

In der Programmiersprache C sind es beispielsweise die Exportfunktionen einer C-Quelle.

Grenzwerttests

Grenzwerttests sind eine Untergruppe der Äquivalenzklassentests. Grenzwerte sind dabei solche kleinsten oder größten Werte einer Äquivalenzklasse oder eines Datentyps, die gerade noch innerhalb des Bereiches, auf der Grenze oder gerade außerhalb eines Bereiches liegen.

Diese Herangehensweise basiert auf der Erfahrung, dass Fehler häufig an Grenzen von Wertebereichen auftreten.

Hardware-in-the-Loop (HiL)

Hardware-in-the-Loop (HiL) Testing bedeutet für den Test eingebetteter Systeme, dass das fertige (Entwicklungs-)Steuergerät elektrisch mit einer Simulationsumgebung verbunden ist. Die Software ist also auf dem Steuergerät und quasi bereit ins Fahrzeug eingebaut zu werden. Statt im Fahrzeug angeschlossen zu sein, wird das Fahrzeug und seine Umgebung in Echtzeit simuliert, dem Steuergerät wird also vorgegaukelt, es würde sich in seiner eigentlichen Umgebung befinden.

Diese Simulationsumgebung, auch HiL genannt, hat mehrere Vorteile. Zum einen muss das Fahrzeug für den Test der Steuerung noch nicht verfügbar sein und es sind im Labor auch Tests möglich die den Fahrer und Fahrzeug potentiell gefährden könnten. Dies könnten zum Beispiel Fehlersimulationen, auch elektrische sein, oder auch Busfehler oder gefährliche Fahrsituationen, die das Fahrzeug mechanisch zerstören würden.

Die Umgebung des Steuergeräts, also die Regelstrecke wird am HiL in der Regel simuliert. In manchen Fällen ist die Simulation aufwendig und kann besser durch Verwendung realer Bauteile abgebildet werden. So finden sich bspw. häufig reale Drosselkappen für den Test von Motorsteuergeräten in einer Schublade, der sogenannten Lastschublade am HiL, weil deren Simulation ungenau und aufwendig ist.

In allen Fällen laufen HiLs in Echtzeit.

HiL-Tests können automatisiert werden, was bei Fahrzeugtests nur mit sehr großem Aufwand möglich ist. Allerdings stellt die Simulation immer eine Vereinfachung der realen Welt dar und kann reale Fahrzeugtests nicht ersetzen.

In der Automobilindustrie unterscheidet man verschiedene Integrationsstufen beim HiL-Testen. Es werden sogenannte Komponenten-HiLs für einzelne Steuergeräte oder Verbünde einiger weniger Steuergeräte verwendet, aber auch Integrations– oder Fahrzeug-HiLs sind üblich, bei denen Fahrzeuggerüste mit ihren Kabeln und Steuergeräten aufgebaut werden um das Zusammenspiel aller Steuergeräte zu erproben.

Für die Testautomatisierung mit TPT existieren diverse Anbindungen an HiL-Systeme verschiedener Hersteller wie bspw. dSPACE, ETAS oder Vector. Beim ASAM gibt es auch einen Standard, die sogenannte XiL-API um HiLs verschiedenster Hersteller fernzusteuern. Auch TPT unterstützt die ASAM XiL-API.

https://de.wikipedia.org/wiki/Hardware_in_the_Loop

Integrationstest, integration testing, Subsystemtest

Testphase, in der das Zusammenspiel von Modulen, Subsystemen sowie ggf. Hardware/Software (bei eingebetteten Systemen) geprüft wird.

ISO 26262

Die ISO 26262 ist die Norm für die funktionale Sicherheit elektrischer und elektronischer Systeme in Straßenfahrzeugen. Die ISO 26262 unterscheidet „Automotive Safety Integrity Levels (ASIL)“, die ein Maß für die Sicherheitsrelevanz einer Fehlfunktion darstellen. Es gibt insgesamt 4 Stufen auf einer Skala von A bis D unterteilt, wobei D die höchste Sicherheitsstufe klassifiziert. Die ASIL-Einstufung erfolgt nach einer Gefährdungs- und Risikoanalyse.

Klasse, Eigenschaft

Spezifische Charakteristik einer Teilmenge des Eingabedatenraums zu einem Testobjekt nach einer bestimmten Klassifikation.
“Rot” ist beispielsweise eine Klasse zur Klassifikation “Farbe”.

Klassifikation

Aufteilung des Eingabedatenraums (bzw. Teilen davon) eines Testobjekts nach testrelevanten Gesichtspunkten in Klassen.

Klassifikationsbaum-Methode

Testmethode zur systematischen Testfallermittlung. Mit der Klassifikationsbaum-Methode wird der Eingabedatenraum eines Testobjekts unter verschiedenen, vom Tester als relevant erkannten Gesichtspunkten betrachtet. Die entstehenden Klassifikationen bestehen aus jeweils disjunkten und vollständigen Klassen. Diese können wiederum durch weitere Klassifikationen verfeinert werden. Die Zerlegung wird als Baum notiert und als Kopf einer Kombinationstabelle verwendet, in der Testfälle markiert werden.

Die Klassifikationsbaum-Methode gehört zu den Funktionstests.

Model-in-the-Loop (MiL)

Model-in-the-Loop-Testing (MiL) auch Modelltest genannt, meint das frühe Testen von Modulen oder auch Modulintegrationen in einer modellbasierten Entwicklungsumgebung wie bspw. MATLAB Simulink von Mathworks, TargetLink von dSPACE oder ASCET von ETAS. Dabei kommuniziert das zu testende System (SUT) über sogenannte Signale mit der Umwelt.

Im Grunde wird ein Modell des zu testenden Systems (SUT) simuliert und getestet. Das „in-the-Loop“ zielt auf den geschlossenen zu testenden Regelkreis ab, wobei MiL auch für offene Regelkreise verwendet wird. Model-in-the-Loop Testing gibt es mit oder ohne dynamisches Modell der Regelstrecke in Abhängigkeit vom zu testenden System (SUT). In Fällen, in denen das System keine Umgebungssimulation benötigt, werden alle Eingangssignale von der Testumgebung synthetisch erzeugt.

Model-in-the-Loop ist die erste Teststufe in der modellbasierten Entwicklung. Neben dem anforderungsbasierten Test für Modelle spielen auch Abdeckungskriterien wie Branch Coverage, Decision Coverage, Condition Coverage und MC/DC ähnlich zum Softwaretest eine große Rolle als Testendekriterium.

Im Unterschied zu klassischer Software, bei der Programmcode in-the-loop getestet wird (sog. Software-in-the-Loop (SiL) Test), werden im MiL-Test vielmehr die Blockdiagramme der Software getestet.

In vielen Fällen ist die auf MiL folgende Teststufe Software-in-the-Loop (SiL), da häufig aus den Modellen direkt mittels automatischer Codegenerierung Software erzeugt wird, die wiederum getestet werden muss. Typische Codegeneratoren für Simulink-Modelle sind Simulink Coder und Embedded Coder von Mathworks oder TargetLink von dSPACE. Für MiL-Testing spielt später der Vergleich (Back-to-Back Test oder Regressionstest) eine große Rolle, da die Testergebnisse des Modelltests (MiL) mit den Ergebnissen des Softwaretests (SiL) gleich oder zumindest sehr ähnlich sein sollten. Unterschiede ergeben sich bspw. durch Fix-Point Skalierung oder Verwendung anderer Datentypen.

TPT bietet MiL-Testing mit automatischer Testumgebungserstellung für Simulink, TargetLink und ASCET an. Funktionale Testfälle werden in TPT meist manuell erstellt, wobei mit TASMO Abdeckungstestfälle automatisch generiert werden können. Reaktive Testfälle des geschlossenen Regelkreises sind möglich. Weitere Informationen siehe:

https://de.wikipedia.org/wiki/Model_in_the_Loop

Modified Condition / Decision Coverage (MC/DC)

MC/DC Coverage ähnelt der Condition Coverage.

Bei der MC/DC Coverage wird jede einzelne atomare Entscheidung unabhängig jeweils einmal positiv und einmal negativ getestet ohne dabei den Wahrheitswert der anderen atomaren Entscheidungen zu verändern.

Sicherheitsnormen wie ISO 26262 verweisen auf die MC/DC coverage als „highly recommended“ für ASIL-D aber auch für ASIL A und B und C wird MC/DC empfohlen.

Modul

Software ist häufig aus Bausteinen, sogenannten Modulen aufgebaut, die für sich genommen eine bestimmte Funktionalität darstellen. In der Softwarearchitektur wird festgelegt wie die einzelnen Module zusammen eine Gesamtfunktionalität abbilden.

Modultest

Testphase, in der die Funktionalität eines Moduls (exportierte Funktionen und deren Zusammenspiel) getestet wird.

Pfadüberdeckung, Path Coverage

Testkriterium, bei dem die Anzahl der bei einem Test durchlau­fenen Programmpfade im Vergleich zur Gesamtzahl möglicher Pfade (in Prozent) betrachtet wird.
Eine Pfadüberdeckung von 100% ist in der Regel nicht erreichbar, da die Zahl der möglichen Pfade bei Auftreten von Schleifen meist sehr groß ist. Aus diesem Grunde gibt es speziellere Pfadüberdeckungskrite­rien, die auf Begrenzungen für die Zahl der Schleifendurchläufe basieren.
Anmerkung: Die vollständige Pfadüberdeckung (100%) schließt die vollständige Zweigüberdeckung ein und führt ihr gegenüber zu einer höheren Überdeckung des Testobjekts.

Processor-in-the-Loop (PiL)

Processor-in-the-Loop (PiL) bezeichnet Test und Validierung von eingebetteter Software auf dem Prozessor, der auch im Steuergerät später verwendet wird. Die Algorithmen und Funktionen werden normalerweise auf einem PC innerhalb einer Entwicklungsumgebung entweder direkt in C, C++ oder modellbasiert bspw. mit Simulink, TargetLink oder ASCET entwickelt. Der entstehende C-Code muss mit einem speziellen „Target“-Compiler für den Prozessor kompiliert werden, der später auch im Steuergerät im Fahrzeug verwendet wird. Um zu testen, ob der kompilierte Code auch auf dem Zielprozessor funktioniert, werden PiL-Tests durchgeführt. Die Regelalgorithmen werden für den PiL-Test meist auf einem sogenannten Evaluierungsboard ausgeführt. Manchmal werden PiL-Tests auch auf dem realen Steuergerät ausgeführt. Beide Varianten nutzen den real in der Steuerung verwendeten Prozessor und nicht wie beim SiL-Test den PC. Die Verwendung des Ziel-Prozessors hat den Vorteil, dass Compilerfehler aufgedeckt werden können.

„In-the-loop“ bedeutet bei PiL-Tests, dass der Regler in die reale Hardware eingebettet ist und die Umgebung der zu testenden Software simuliert wird. Umgebungsmodelle wie bei MiL, SiL und HiL sind beim PiL-Test eher unüblich, da die Einbettung solcher Modelle auf dem Zielprozessor aufwendig oder unmöglich sind. Wenn Umgebungsmodelle mit dem Prozessor zusammenkommen spricht man meist von Hardware-in-the-Loop-Test (HiL).

TPT ermöglicht PiL-Testing über sogenannte Debugger. Dabei steuert TPT den Debugger wie Lauterbach TRACE32 oder PLS UDE fern um den kompilierten Code direkt auf dem Prozessor auszuführen zu steuern.

Regressionstest

Wiederholung eines Tests nach Änderungen des Testobjektes. Dabei kann aus Effizienzgründen versucht werden, nur solche Teile erneut zu testen, die von der Änderung be­troffen sind.

ISTQB definiert Regressionstests als das erneute Testen eines bereits getesteten Programms oder einer Teilfunktionalität nach deren Änderung. Ziel ist der Nachweis, dass durch die vorgenommenen Änderungen keine Fehlerzustände eingeführt oder (zuvor verdeckte) Fehlerzustände freigelegt wurden. 

Schnittstellentest

Software besteht meist aus einzelnen Modulen, die miteinander kommunizieren, oder hat Schnittstellen zu Benutzern oder zur Umgebung. Diese Schnittstellen, über die Software ihre Eingabedaten erhält oder Ausgabedaten bereitstellt, wird beim Schnittstellentest auf Vollständigkeit und Korrektheit geprüft. Dabei spielen Datenformate sowie deren Wertebereiche und Grenzwerte eine große Rolle und sollten geprüft werden.

Software-in-the-Loop (SiL)

Software-in-the-Loop-Testing meint das Testen eingebetteter Software, von Algorithmen oder ganzer Regelkreise auf dem PC, also ohne Steuergerätehardware. Der Programmcode für das eingebettete System wird für die Ausführung auf dem PC kompiliert und anschließend auf dem PC getestet. Der Terminus „in-the-Loop“ bedeutet, dass Teile der Umgebung der Software, also die Regelstrecke oder auch Hardware, simuliert werden. Die Simulation eines geschlossenen Regelkreises ist nicht zwingend erforderlich, da einige zu testende Systeme (SUT), insbesondere beim Modultest, keine geschlossenen Regelkreise benötigen.

Im Falle des Modul– oder Unittests erfolgt der Software-in-the-Loop-Test bei handkodierter Software in der ersten Teststufe. Bei der sogenannten modellbasierten Entwicklung wird der Software-in-the-Loop-Test erst an zweiter Stelle, also nach dem Model-in-the-Loop-Test durchgeführt.

Der Software-in-the-Loop-Test wird für Modul-, Unit– und für Integrationstests verwendet. Beim Softwareintegrationstest kommen komplexere SiL- und Co-Simulationsumgebungen sowie Hardwarevirtualisierungen zum Einsatz.

Die Code Coverage mit ihren Abdeckungskriterien (bspw. Decision Coverage, Condition Coverage und MC/DC) spielen als Testendekriterium beim Software-in-the-Loop-Test eine große Rolle für die Entscheidung wann genug getestet wurde. Für die  Code Coverage kann in TPT das Testfallgenerierungsverfahren TASMO verwendet werden, das automatisch die für eine maximale Code Coverage notwendige Testfälle generiert. Anders als die für die Code Coverage relevanten strukturellen Testfälle, werden funktionale Testfälle meist manuell erstellt bzw. modelliert.

Für den Software-in-the-Loop-Test muss vorab der Programmcode kompiliert werden. Dabei kommen oftmals gängige Softwarecompiler wie bspw. Microsoft Visual Studio oder MinGW zum Einsatz. Falls in der Software spezielle Funktionen verwendet werden, die weder vom Compiler noch vom PC-Prozessor unterstützt werden, müssen diese Funktionen „gestubbed“ werden, d.h. durch Dummyfunktionen ersetzt werden.

TPT bietet für den Software-in-the-Loop-Test mehrere problemgerechte Lösungen:

  • MATLAB/Simulink SiL: Im Falle der automatisierten Codegenerierung aus Simulinkmodellen mittels Simulink Coder, Embedded Coder oder TargetLink, wird das Simulinkmodell von TPT automatisch in den sogenannten SiL-Modus versetzt und zu Testzwecken in Simulink simuliert.

  • ASCET SiL: SiL-Tests von mit ASCET erstellen Implementierungsmodellen wird von TPT unterstützt

  • Für handgeschriebenen C/C++ Code bietet TPT die automatische Erstellung der Testumgebung  (C-Platform) oder eine Co-Simulationsumgebung (FUSION) an. Beide Testumgebungen sind im Standardumfang von TPT enthalten.

  • AUTOSAR Software kann entweder direkt ähnlich C-Code oder mit der FUSION getestet werden
  • Weitere SiL-Umgebungen wie bspw. VeOS von dSPACE (über die ASAM XiL API), Silver von QTronic oder RTLab werden von TPT unterstützt.

Sollwert, Predicted Result

Erwartetes Ergebnis eines Testlaufs. Dabei handelt es sich um das erwartete Verhalten eines Testobjekts. Ein Sollwert kann bspw. für einen Ausgabeparameter definiert werden. Zu Ermittlung des Sollwertes werden häufig Testorakel verwendet.
In TPT werden Sollwerte weitgehend in Auswerteregeln (Assesslets) definiert. Die Auswerteregeln werden automatisch auf die Testdaten angewendet.

Statisches Testverfahren

Unter statischem Testverfahren versteht man das Testen ohne den Code/das Programm auszuführen. D.h. der unkompilierte Programmcode wird reviewed oder statischen Analysen unterzogen.

Strukturtest

Beim Strukturtest werden die Testfälle aus der Struktur des Testobjektes abgeleitet, um bspw. kontrollflussorientierte Tests (z.B. Zweigüberdeckungstest) oder datenflussorientierte Tests durchzuführen. Der Strukturtest ist damit auch ein White-Box-Test.

Stub

Ein Stub ist ein Platzhalter für nicht getestete/nicht vorhandene Module. Es wird beim sogenannten Top-down-Test verwendet. Stubs realisieren dabei die Funktionalität des ersetzten Moduls nicht vollständig, sondern haben ein vereinfachtes I/O-Verhalten.

SUT

Abkürzung für “system under test”; siehe Testobjekt

Systemtest

Im Systemtest wird das gesamte betrachtete System getestet.

Testdokumentation

Zur Testdokumentation gehören der Testplan, die Testspezifikation, die Dokumentation der Testdurchführung und die Dokumentation der Testauswertung. Die Testdokumentation dient der Nachverfolgbarkeit und ist verpflichtend bei der Entwicklung sicherheitsrelevanter eingebetteter Systeme.

Testdurchführung

Die Testausführung beschränkt sich nicht auf das bloße Ausführen von Testfällen, sondern umfasst auch als vorbereitende Aktivitäten die Erzeugung des Teststandes und die Bereitstellung der Testdaten. An­schließend wird der Teststand ausgeführt. Die Ergebnisse werden pro­tokolliert. Der Vergleich der Ergebnisse mit den Sollwerten erfolgt erst im Zuge der Testauswertung.

Testen

Beim Testen werden die Funktionen eines Programmcodes oder einer ausführbaren Software in einer definierten Umgebung geprüft. Der zu testende Programmcode bzw. die Software werden als Testobjekte bezeichnet. Die erzielten Ergebnisse werden beim Testen bewertet. Jede (stichprobenartige) Ausführung des Testobjekts unter spezifizierten Bedingungen zum Zwecke des Überprüfens der beobachteten Ergebnisse des Testobjekts im Hinblick auf gewisse ge­wünschte Eigenschaften (Sollwert, Testorakel) wird als Test bezeichnet.

Das Testen dient der Steigerung der Qualität und soll das Vertrauen in die zu testende Funktion festigen. Testen ist immer ein stichprobenartiges Vorgehen. Damit kann Testen zwar Fehler aufdecken, nicht aber deren Abwesenheit beweisen. Teststrategien werden verwendet um mit möglichst geringem Aufwand eine gute Testabdeckung zu erzielen.

Im Englischen wird der Begriff „testing“ teilweise auch als “prüfen” verstanden und schließt demnach auch die statischen Prüfverfahren mit ein.
https://de.wikipedia.org/wiki/Softwaretest

Testendekriterium

Ein vollständiger Test ist sehr aufwändig. Aus diesem Grund muss in der Teststrategie festgelegt werden, wann ein System ausreichend getestet ist. Das Testendekriterium beschreibt den Zeitpunkt oder Zustand eines Testfalls, um als erfolgreich abgeschlossen zu gelten. Im Allgemeinen werden Testkriterien zur Beschreibung des Testendekriteriums eingesetzt.

Testendekriterien beschreiben wann ein Test beendet wird. Dabei kommen verschiedenste Kriterien zum Einsatz, bspw.:

  • Bewertete Restrisiken
  • Überdeckungskriterien (Zweigüberdeckung, Pfadüberdeckung etc.)
  • Testdauer
  • Testbudget
  • Qualitätsmaße wie bspw. Anzahl offener Fehler oder wie viele Fehler innerhalb einer Zeitspanne neu entdeckt wurden

Testfall

In einem Testfall werden bestimmte Eingabesituation festgelegt. Das heißt, es werden konkrete Eingabewerte aus dem Eingabedatenraum des Testobjekts gesetzt. Der Tester wählt dabei die konkreten Eingabewerte aus der Eingabedatenraummenge so aus, dass sie Repräsentanten der Menge darstellen, um Fehler der gesamten Menge aufzudecken.

Anmerkung: Das Institute of Electrical and Electronics Engineers (IEEE) definiert “Testfall” abweichend: Dort um­fasst der Testfall zusätzlich das Testdatum und den Sollwert.

Testfallermittlung

Testaktivität, bei der Testfälle definiert werden, mit denen die Prüfung der Testobjekte durchgeführt werden soll. Die Testfallermittlung ist die wichtigste Testaktivität, da sie die Qualität des Tests entscheidend beeinflusst.

Testkriterium

Beobachtbare und im Allgemeinen auch messbare, objektive Bewertungskriterien für die Qualität eines Tests. Beispiele für Testkriterien sind Kriterien zur Testbarkeit eines Testobjektes aber auch die Testdauer bzw. das Testbudget.

Testlauf

Der Testlauf meint die Ausführung eines Testobjektes. Durch die Ausführung werden Testdaten erzeugt. Diese können aufgezeichnet und anschließend ausgewertet werden.

Testmanagement

Unter Testmanagement versteht man das Koordinieren aller Tätigkeiten im gesamten Testprozess. Zu den Testaktivitäten gehören:

Testmethode, Testverfahren

Man unterscheidet statische Testverfahren, bei denen der Programmcode nicht ausgeführt wird, von dynamischen Testverfahren, bei denen der Programmcode ausgeführt wird. Die gewählte Testmethode beeinflusst damit die Testfallerstellung.

Testobjekt, zu testendes System (SUT)

Ein Testobjekt ist eine zu testende Einheit, die sich durch eine bestimmte Funk­tionalität von ihrer Umgebung abgrenzt. Aufgrund des strukturierten Vorgehens bei der Entwicklung soft­warebasierter Systeme, bei dem unterschiedliche Funktionen in separaten Strukturen realisiert werden, handelt es sich bei Testobjekten deshalb häufig – je nach Testphase – um eine einzelne Funktion (unit), eine Funktionengruppe, ein Modul, ein Subsystem oder das Gesamtsystem. Der Begriff „system under test“ wird synonym zu Testobjekt verwendet.

Testorakel

Um zu entscheiden, ob sich das Testobjekt korrekt verhält oder nicht, muss vorab definiert werden, was als korrektes und inkorrektes Verhalten gilt. Hierzu werden besondere Informationsquellen wie Handbücher, ein existierendes System, oder auch eine reale Person mit Spezialwissen benötigt. Die Informationsquelle wird als Testorakel bezeichnet.

Testorganisation

Die Testorganisation umfasst alle Aktivitäten, die mit der Verwal­tung der Testobjekte und der zugehörigen Daten verbunden sind. Dazu gehört insbesondere die Speiche­rung von Testfällen, Testdaten, Sollwerten, Istwerten und technischen Parametern. Die Testorga­nisation dient dazu, Tests jederzeit reproduzierbar zu machen.

Testphase

Jeder Softwareentwicklungsphase ist eine Testphase zugeordnet, in der die entsprechenden Testmethoden angewandt werden. Entsprechend den Entwicklungsphasen kommen also Funktionentest, Modultest, Integrationstest, Systemtest und Abnahmetest in Anwendung.

Testplan

Testdokument, welches die Testendekriterien, die Teststrategie, die Testmethoden, die Ressourcen, die Verantwortlichkeiten, den Aufwand und die Terminplanung der in­tendierten Tests beschreibt. Darüber hinaus werden die Testobjekte festgelegt.

Testprozess

Der Testprozess besteht aus der Gesamtheit aller Testphasen mit ihrer Einord­nung in den Software Life Cycle.

Testrahmen, Test Frame

Für den Test eines Testobjekts notwendige Umgebung. Ist es notwendig, Auf­rufer des Testobjekts zu simulieren, so muss ein Testtreiber generiert werden, der diese Aufgabe über­nimmt. Die möglicherweise notwendige Simulation von Komponenten, die vom Testobjekt aufgerufenen werden, wird mittels Stellvertretern (stubs) realisiert.

Testspezifikation

Testdokument, das die konkrete Teststrategie und Detailangaben zur Testmethode umfasst. Konkret muss erläutert werden, wie die Testendekriterien erreicht werden sollen. Weiterhin umfasst die Testspezifikation die Beschreibung der Testvorbereitung, die Testfälle, die Akzeptanz- und Rückweisungskriterien und den Leitfaden für den Regressionstest. Im engeren Sinne wird der Begriff Testspezifikation auch als synonym für Testfallspezifikation verwendet.

Teststand, Test Rig

Für den Testlauf notwendige Einheit, bestehend aus Testrahmen und Testobjekt.

Teststrategie

Die Teststrategie ist das Resultat aus der Auswahl und Festlegung des Zusammenspiels von einzelnen Testmethoden (z.B. Äquivalenzklassentest und Zweigüberdeckung). Die Entscheidung wie Teilkomponenten in das Gesamtsystem integriert werden (top-down, bottom-up etc.), kann die Teststrategie beeinflussen.

Testtreiber

I/O-Schnittstelle zwischen Testobjekt und Tester, der das Testobjekt isoliert steuern kann.

Tool Confidence Level (TCL)

Im Rahmen einer Tool-Qualifizierung wird aufgrund der Abschätzung für den Tool Impact und die Tool error Detection wird das Konfidenzniveau, „Tool Confidence Level“ ermittelt.

Wurde ein Tool Confidence Level TCL1 ermittelt, sind keine weiteren Qualifizierungsmaßnahmen erforderlich. Wurde TCL2 oder TCL3 ermittelt, ist eine Tool-Qualifizierung durchzuführen.

Tool error detection (TD)

Tool Error Detection ist nach ISO 26262 Part 8 die Wahrscheinlichkeit einen Werkzeugfehler in einem definierten Anwendungsprozess zu erkennen bzw. zu vermeiden

TD1=hohe Wahrscheinlichkeit
TD2=mittlere Wahrscheinlichkeit
TD3=geringe Entdeckungswahrscheinlichkeit

Tool Impact (TI)

Mit der Analyse des Tool Impact (TI) wird gemäß ISO 26262 Part 8 untersucht, ob ein Software-Werkzeug einen direkten oder indirekten Einfluss auf die zu entwickelnde Software hat. Der Tool Impact kann die Werte 1 oder 2 annehmen. TI=2 bedeutet, dass ein Software-Werkzeug eine Auswirkung auf die Tool-Anwendung hat, bei TI=1 ist keine Auswirkung gegeben.

Beispielsweise kann ein Tool wie TPT selbst keinen fehlerhaften Code erzeugen. Dennoch könnte eine Fehlfunktion von TPT dazu führen, dass die Verletzung einer Sicherheitsanforderung nicht erkannt wird.
Somit muss für TPT wie für jedes Test-Tool – ein Tool-Impact als gegeben angenommen werden (TI 2).

Tool-Qualifizierung

Bei gegebenem Tool Confidence Level (TCL) > 1 muss für ein Software-Werkzeug eine Tool-Qualifizierung durchgeführt werden. Nach ISO 26262 Part 8 hierzu vier Methoden zur Auswahl:

  • „Increased Confidence from Use“,
  • „Evaluation of the Development Process“,
  • „Validation of the Software Tool“ und
  • „Development in Compliance with a Safety Standard“

Welche der alternativen Maßnahmen für eine Qualifizierung in Betracht kommen, wird durch die ASIL-Einstufung des zu entwickelnden Produkts bestimmt. 1c „Validation of the Software Tool“ ist z.B. für ASIL C und D dringend empfohlen. Die Inputs, Anforderungen und Outputs („work products“) für die jeweilige Methode sind in der Norm im Detail beschrieben.

Top-down-Test

Vorgehensweise beim Integrationstest. Begonnen wird mit den Modulen auf der höch­sten Entwurfsebene, die weiteren Module werden in die Hierarchie der Modulaufrufe eingefügt. Die Top-down-Vorgehensweise bedingt den Einsatz von Stubs.

TPT Autotester

Der Autotester ist ein von PikeTec entwickeltes TPT Feature, mit dem die vom Fahrer und vom Fahrzeug abgegebenen Testsignale automatisch beobachtet und bewertet werden können. Es gilt zu beachten, dass, sobald ein Testfall als aktiver Testfall festgelegt wurde, andere Fälle während der Fahrprüfung automatisch und parallel ausgeführt, untersucht und bewertet werden können. Aufgrund dieser “Drive-by”-Tests kann mit dem TPT Autotester erhebliche Testzeit eingespart werden.

TPT Dashboard

Das TPT Dashboard ist ein Feature von TPT, das für automatisierte Fahrzeugtests verwendet wird. Hierbei kann der Testfall über eine GUI gleichzeitig mit Fahrer und Fahrzeug kommunizieren. Konkret wird die Kommunikation ermöglicht durch Schaltflächen, Text und akustische Mitteilungen über die Testdurchführung. Innerhalb der automatisierten Fahrversuche unterscheiden wir das TPT Dashboard vom TPT Autotester.

Validierung

Mit der Validierung wird geprüft, ob die Software ihren Zweck erfüllt, also den Kundenanforderungen gerecht wird.

Verifikation, Verifizierung

Mit der Verifikation wird geprüft, ob die Software ihren Anforderungen genügt.

Verlinkung von Anforderungen und Testfällen, Traceability

Um die Abdeckung von Anforderungen bewerten zu können, und um eine Nachverfolgbarkeit von Artefakten im Entwicklungsprozess zu gewährleiten kann man Anforderungen mit Testfällen verlinken (verknüpfen). Jede Anforderung kann dabei von mehreren Testfällen getestet werden und jeder Testfall kann mehrere Anforderungen abdecken. Die Nachverfolgbarkeit von Anforderungen wird bspw. auch von der ISO26262 gefordert.

In TPT können Anforderungen direkt mit Testfällen als auch mit Assesslets, die Sollbestimmungen beinhalten, verknüpft werden.

White-Box-Test

White-Box-Testing ist ein dynamisches Testverfahren. White-Box-Tests nutzen die vorhandenen Informationen über die interne Struktur des Testobjektes für kontroll- oder datenflussorientierte Tests aus. Testfälle werden bei dieser Methode anhand von Untersuchungen des Codes der Software entwickelt.

Beim White-Box-Testverfahren wird der Code und dessen Kontrollfluss berücksichtigt. Die Abdeckung des Kontrollflusses wird gemessen. Beispiele für Grade der Abdeckung sind bspw. Statement Coverage & Branch Coverage, Decision/Condition Coverage oder Modified Condition/Decision Coverage. Diese Maßzahlen sind Beispiele für die Messgrößen für die Vollständigkeit des White-Box Tests.

TPT unterstützt Coverage Messungen für Modelle und Code mit bspw. der Simulink Coverage Toolbox und CTC++, wobei die Coverage-Ergebnisse im TPT-Report dargestellt werden.

https://de.wikipedia.org/wiki/White-Box-Test

Zweigüberdeckung, Branch Coverage

Testkriterium, bei dem die Anzahl der bei einem Test durchlaufenen Programmzweige im Verhältnis zur Gesamtzahl enthaltener Zweige betrachtet wird. Ziel ist es herauszufinden, ob bei jeder Verzweigung im Programmablauf jede Option mindestens einmal durchlaufen wurde.

Zweigüberdeckungstest

Testfallermittlung auf der Basis der Programmstruktur (Strukturtest) mit dem Ziel, möglichst viele Zweige des Testobjektes mindestens einmal auszuführen, d.h. eine hohe Zweigüberdeckung zu erreichen. Im Allgemeinen wird als Testendekriterium eine bestimmte Zweigüberdeckung gefordert (z.B. 80% Zweigüberdeckung).
Die Zweigüberdeckung enthält die Anweisungsüberdeckung und führt ihr gegenüber – sofern Verzwei­gungen auftreten – zu einer höheren Überdeckung des Testobjekts.

XIL API

siehe ASAM XiL API