-
Die
Erfindung betrifft ein Verfahren zur Erstellung von Abläufen zum
Testen einer Software mit den im Oberbegriff des Patentanspruches
1 genannten Merkmalen.
-
Vielfach – insbesondere
in der Automobilbranche – wird
Software heute aus Datenflussmodellen oder aus der Kombination von
Datenflussmodellen und Zustandsdiagrammen entwickelt, d. h. aus einer
graphischen Darstellung, die in Tools wie z. B. "Simulink" und/oder "Stateflow", „ASCET" oder „Matrix
X" erzeugt wird.
Sie ähneln
Schaltplänen
in der Elektrotechnik und bestehen aus einzelnen "Blöcken", deren Ein- und Ausgänge durch
Leitungen ("Signale") verbunden sind.
Anhand der in diesen Modellen definierten Funktionen kann dann der
eigentliche Code, meist in der Programmiersprache C, erzeugt werden,
entweder manuell durch den Programmierer oder auch automatisch durch
einen sogenannten Codegenerator. Im weiteren Verlauf des Software-Entwicklungsprozesses
muss diese Software dann auf dem Zielsystem (z. B. einem Steuergerät) getestet
werden. Diese Tests laufen vielfach automatisiert auf HIL-Testplätzen (Hardware-In-the-Loop)
ab.
-
Die
Erstellung von Testplänen
ist ein essentieller Bestandteil einer professionellen Softwareentwicklung.
Nachteilig ist dabei, dass der genaue Ablauf der Tests meist noch
von einem Tester manuell vorgegeben werden muss, üblicherweise
indem die HIL-Testplätze über einfache
Programme ("Skripte") gesteuert werden.
Solche Skripte bestehen aus einzelnen Testfällen, d. h. Ein- und (Soll-)Ausgangswerten
oder Abfolgen solcher Werte. Der eigentliche Test besteht dann darin,
die vorgegebenen Eingangswerte (bzw. Folgen solcher Werte) zu realisieren,
indem sie über
geeignete Schnittstellen im Zielsystem vorgegeben werden. Die Ausgangswerte
des Zielsystems (bzw. Folgen von Ausgangswerten) werden dann ebenfalls über entsprechende
Schnittstellen ausgelesen und mit den vordefinierten Soll-Ausgangswerten
verglichen. Stimmen die realen und Soll-Ausgangswerte innerhalb
definierter Grenzen überein,
ist der Testfall bestanden. Trifft dies für alle Testfälle zu und
ist die Anzahl der Testfälle
ausreichend, entspricht die Software den Vorgaben des Modells. Der
Aufwand für
die manuelle Erstellung der Testpläne und für deren Abarbeitung kann bis
zu 50% der Kosten und des Zeitaufwandes betragen, die für die Entwicklung
der Software notwendig sind. Außerdem
besteht bei manueller Erstellung der Testpläne aus mehreren Gründen ein
relativ hohes Fehlerrisiko. Zum einen werden oft keine klar definierten
Standards für
die Erstellung der Tests verwendet, so dass der Inhalt der Testpläne stark
von den persönlichen Erfahrungen
und dem Wissen des Erstellers abhängt; zum anderen können auch
Flüchtigkeitsfehler nicht
ausgeschlossen werden.
-
Darüberhinaus
steigt die Softwarequalität
erfahrungsgemäß mit der
Anzahl der ausgeführten sinnvollen,
nicht-redundanten Testfälle.
In der Praxis findet die Anwendung dieses Grundsatzes ihre Grenzen
jedoch recht schnell im dafür
notwendigen Aufwand. Daher ist durch eine automatisierte Testfallerzeugung
aufgrund des dadurch verminderten Aufwands für die Testplanerstellung auch
eine Verbesserung der Softwarequalität zu erreichen.
-
Aus
der
DE 100 55 679
A1 ist ein Verfahren zur modellbasierten Generierung von
Testszenerien vorbekannt, bei dem aus wenigstens einem Teil eines in
Programmform vorliegenden Simulationsmodells automatisch ein Klassifikationsbaum
erzeugt wird, wobei testrelevante Informationen aus dem Simulationsmodell
mit einem Modell-Extrator automatisch extrahiert, als Baumkomponenten
repräsentiert
und zu einem Klassifikationsbaum zusammengesetzt werden. Beim modellbasierten
Testen werden die Testszenerien automatisch aus einer ausführbaren
Spezifikation, beispielsweise in Form eines Matlab/Simulink-Modells,
abgeleitet. Mit Hilfe dieser Testszenarien kann dann sowohl das
Modell im Modelltest selbst, als auch daraus entwickelte Software
im Softwaretest getestet werden.
-
Durch
dieses Verfahren wird der Aufwand zur Erstellung der Testfälle durch
eine teilweise Automatisierung vereinfacht. Nachteilig ist jedoch
die Speicherung von testrelevanten Daten in Baumstrukturen, was
hohe Anforderungen an den zur Verfügung stehenden Speicherplatz
des verwendeten Computersystems bedingt.
-
Aus
der
DE 102 18 212
A1 ist ein Verfahren zum automatisierten Testen von Software
mittels eines Datenverarbeitungsgerätes und einer ausführbaren
Testfallgenerator-Software vorbekannt. Dabei wird mit einem grafischen
Editor das dynamische und das semantische Verhalten der Benutzeroberfläche der
Software spezifiziert. Von der Testfallgenerator-Software werden
anhand des spezifizierten Verhaltens der Benutzeroberfläche Testfälle generiert, welche
unmittelbar anschließend
oder in einem abgesetzten Schritt von einer Software zur automatischen
Testführung
ausgeführt
werden.
-
Das
in der
DE 102 18 212
A1 dargelegte Verfahren beschränkt sich auf die Erzeugung
von Testdaten für
graphische Bedienelemente, deren Verhalten in Form von Zustandsdiagrammen
beschrieben ist. Die Erzeugung von Testfällen für andere Arten von Systemen
oder für
Systeme, die durch Datenflussmodelle beschrieben sind, wird dagegen
nicht beschrieben.
-
Der
Erfindung liegt die Aufgabe zugrunde, ein Verfahren zur Erstellung
von Abläufen
zum Testen einer Software zu schaffen, mit dem der Aufwand zur Erstellung
durchzuführender
Testpläne
und die Rechenzeit zur Überprüfung des
Programms, bei einer verminderten Fehlerquote, reduziert werden.
-
Erfindungsgemäß wird die
Aufgabe durch die Merkmale des Patentanspruches 1 gelöst.
-
Dadurch,
dass zu jedem Modellblock testrelevante Algorithmen in Form eines
Testfallalgorithmus, eines Durchleitungsalgorithmus, eines Rückverfolgungsalgorithmus
und eines Vorwärtsverfolgungsalgorithmus
implementiert werden, wird bei einem Testfall der Software die für einen
Modellblock vorgegebene Teilmenge eines möglichen Wertebereiches der
betreffenden Eingangssignale durch die weiteren Modellblöcke bis
zu deren Ein- und Ausgängen
verfolgt und überprüft, ob eine
sinnvolle Verknüpfung
der einzelnen Blöcke
vorhanden ist.
-
Durch
die Vor- und Rückverfolgung
des eingegebenen Wertebereichs in den vor- und nachgeschalteten Modellblöcken werden
gleichzeitig mögliche
Werte bis zu Systemein- und -ausgängen des zu testenden Systems
weiterverfolgt. Indem Wertebereiche und nicht einzelne Werte verfolgt
werden, steigt die Wahrscheinlichkeit, dass die Rückverfolgung
erfolgreich ist, d. h. für
jeden durchlaufenen Block Eingangs-Wertebereiche gefunden werden, so dass
beliebige Eingangswerte aus diesen Bereichen jeweils einen Ausgangswert
aus dem vorgegebenen Ausgangswertebereich ergeben. Darüberhinaus kann
bei der Rückverfolgung
ein Backtracking (d. h. eine teilweise Wiederholung der Rückverfolgung) aufgrund
unterschiedlicher Anforderungen an dasselbe Signal in vielen Fällen vermieden
werden. Dadurch wird gegenüber
dem im Stand der Technik beschriebenen Verfahren die Rechenzeit
verkürzt.
Außerdem
wird durch die teilweise automatische Generierung der Testpläne die Fehlerquote
beim Testen der Software verringert, indem durch die Verwendung
vorgegebener Algorithmen zur Erzeugung der Testfälle die Einhaltung von Standards
erzwungen wird, die durch diese Algorithmen festgelegt sind. Ein weiterer
Vorteil der erfindungsgemäßen Lösung besteht
darin, dass durch die Implementierung der testrelevanten Algorithmen
für jeden
Modellblock der manuelle Aufwand zur Erstellung von Testplänen reduziert
wird.
-
Weitere
vorteilhafte Ausgestaltungen sind in den Unteransprüchen beschrieben,
sie werden in der Beschreibung zusammen mit ihren Wirkungen erläutert.
-
Anhand
von Zeichnungen wird die Erfindung nachfolgend an Ausführungsbeispielen
näher beschrieben.
Die dazugehörigen
Zeichnungen zeigen:
-
1:
eine schematische Darstellung eines Beispielmodells zum Testen einer
Software und
-
2:
eine schematische Darstellung eines Beispielmodells zum Testen einer
Software mit einem Hystereseprozess.
-
Das
Testen einer aus Datenflussmodellen erstellten Software erfolgt
mittels eines Datenverarbeitungsgeräts und einer ausführbaren
Testfallgenerator-Software. Durch die Testfallgenerator-Software wird
für die
zu überprüfende Software
ein Testplan erzeugt, der aus einzelnen Testfällen besteht. Die automatische
modellbasierte Testfallgenerierung geht davon aus, dass das Verhalten
eines jeden Modellblocks vollständig
bekannt ist. Darauf aufbauend kann bei bekannten Eingangswerten
der Ausgangswert eines Blocks berechnet werden. Bei zustandsabhängigen Blocktypen
ist je nach Blocktyp zusätzlich
noch eine teilweise oder vollständige
Kenntnis des bisherigen Verlaufs der Eingangswerte notwendig, um
die Ausgangswerte zu berechnen. Diese betrifft zum Beispiel Verzögerungsglieder,
Integratoren oder dergleichen.
-
Erfindungsgemäß werden
zum Testen einer Software jedem Modellblock testrelevante Algorithmen
in Form eines Testfallalgorithmus, eines Durchleitungsalgorithmus,
eines Rückverfolgungsalgorithmus
und eines Vorwärtsverfolgungsalgorithmus
implementiert. Bei jedem Testfall wird durch den Testfallalgorithmus
einem Modellblock ein möglicher
Wertebereich für
jedes Eingangssignal zugeordnet, wobei der eingegebene Wertebereich
mittels des Vorwärtsverfolgungsalgorithmus
und des Rückverfolgungsalgorithmus
im zu testenden System durch die einzelnen Blöcke bis zu den Ein- und Ausgängen des
zu testenden Systems verfolgt und deren Ergebnisse überprüft und gespeichert
werden. In der 1 ist schematisch ein Testmodell
zum Testen eines Beispielmodells einer Software dargestellt.
-
Der
Durchleitungsalgorithmus dient dazu, einen bestimmten Eingangswert
ohne wesentliche Einschränkung
von Wertebereich und Genauigkeit zu einem Ausgang des Blocks durchzuleiten.
D. h. der Wert Bart zwar im betrachteten Block verändert werden,
es muss aber eine eineindeutige Zuordnung zwischen dem betrachteten
Ein- und Ausgangswert bestehen.
Der Durchleitungsalgorithmus prüft,
ob dies überhaupt
möglich
ist und legt ggf. die anderen Eingänge des betrachteten Blocks
in geeigneter Weise fest.
-
Der
Rückverfolgungsalgorithmus
dient dazu, Wertebereichseinschränkungen
für die
Ausgänge
eines Blocks in Einschränkungen
für dessen
Eingänge umzusetzen.
Der Algorithmus ordnet jedem Eingang einen bestimmten Wertebereich
zu. Wird jedem Eingang jeweils ein Wert aus diesen Bereichen zugeordnet,
ist sichergestellt, dass der Ausgangswert innerhalb des vorgegebenen
Ausgangswertebereichs liegt. Da bei festem Ausgangswertebereich
im allgemeinen mehrere Möglichkeiten
zur Realisierung dieser Eingangswertebereiche bestehen, kann dieser Algorithmus
auch mehrere Ergebnisse liefern, für die nacheinander versucht
wird, die Wertebereiche über die
an den Eingängen
angeschlossenen Ausgänge anderer
Blöcke
weiterzuverfolgen.
-
Der
Vorwärtsverfolgungsalgorithmus
berechnet für
die gegebenen Eingangswertebereiche eines Blocks für jeden
Ausgang des Blocks einen Wertebereich. Dies geschieht derart, dass
der Ausgangswert auf jeden Fall innerhalb des Ausgangswertebereichs liegt,
wenn die Eingangswerte innerhalb der gegebenen Eingangswertebereiche
liegen. Beinhalten die Eingangswertebereiche jeweils nur einen konkreten Wert,
berechnet dieser Algorithmus als Spezialfall den Ausgangswertebereich
mit ebenfalls nur einem konkreten Wert.
-
Das
in der 1 dargestellte Beispielsmodell erfüllt folgende
Funktionen:
Ist das Eingangssignal „In1" des zu testenden Blocks „RelOp1" gleich einem Wert
von 4.7, wird dem Ausgangssignal „Out1" der Wert 1 zugeordnet und dem Signal „Out2" der Wert des Signals „In1". Ist „In1" dagegen ungleich
dem Wert 4.7, wird dem Signal „Out1" der Wert 0 zugeordnet
und dem Signal „Out2" die Summe aus den
Werten von „In2" und dem „Offset10". Dabei sind alle
hier verwendeten Schalter „Switch" auf einen Schwellenwert
von 0.5 eingestellt, d. h. wenn der mittlere Eingang den Wert 1
hat und somit wahr ist, hat der Schalter die dargestellte obere Stellung,
beim Wert 0, der falsch entspricht, hat der Schalter die jeweils
andere Stellung. Das heißt,
bei einem falschen Wert würde
sich „Switch" in der unteren Stellung
befinden.
-
Zweck
des Testfallgenerators ist es nun, Testfälle zu finden, mit denen die Übereinstimmung der
im Modell dargestellten Funktion mit einer gegebenen Software im
Zielsystem (z. B. Steuergerät),
die dieselbe Funktion erfüllen
soll, überprüft werden kann.
Dazu ist es notwendig, die durch jeden Block im Modell dargestellte
Funktionalität
im Zielsystem möglichst
eindeutig wiederzufinden.
-
Für jeden
Block des Modells werden daher folgende Schritte durchlaufen:
- – Die
Systemausgänge
müssen
von den Ausgängen
des zu testenden Blocks mit genügender
Genauigkeit abhängig
sein. Für
den Test des Summenblocks (3) würde
dies z. B. bedeuten, dass „In1" einen Wert ungleich
4.7 haben muss, damit zumindest ein Systemausgang vom Ausgang des Summenblocks
abhängig
wird. Der Wert von „In2" ist dagegen in diesem
Schritt noch gleichgültig. Diese
Einschränkungen
für die
Systemeingänge werden
berechnet, indem der betrachtete Ausgang bis zu den Systemausgängen weiterverfolgt wird.
Bei jedem dabei passierten Block wird durch einen für diesen
Block spezifischen Durchleitungsalgorithmus berechnet, ob und wie
der Wert möglichst
ohne Verluste der Auflösung
und des Wertebereichs an den Ausgang des passierten Blocks weitergeleitet
werden kann. Beim Schalter geschieht dies im dargestellten Beispiel
durch Anlegen einer „0" an den Steuereingang.
Findet sich keine geeignete Möglichkeit,
wäre die
Testfallgenerierung für
den Summenblock nicht sinnvoll, da sich der Ausgang des Blocks nicht
mit genügender
Genauigkeit überprüfen ließe. Für jeden
der durchlaufenen Blöcke
werden bei diesem Verfahren Einschränkungen für die möglichen Wertebereiche der Blockeingänge erzeugt.
Durch den Rückverfolgungsalgorithmus
werden diese Einschränkungen
bis zu den Systemeingängen
zurückverfolgt.
- – Für jeden
Blocktyp wird durch einen Testfallalgorithmus eine Anzahl von Testfällen vorgegeben. Dies
bedeutet, dass für
jeden Testfall jedem Eingangssignal des betreffenden Blocks ein
Wertebereich zugeordnet wird, aus dem konkrete Werte für den betreffenden
Testfall gewählt
werden können.
Danach werden die gewählten
Wertebereiche für
die Eingangssignale des Blocks mit Hilfe des „Rückverfolgungsalgorithmus" zu den Systemeingängen des
zu testenden Systems zurückverfolgt.
Dabei werden eventuelle Beschränkungen
der Wertebereiche von Signalen berücksichtigt; die im vorherigen
Schritt aufgrund des Durchleitungsalgorithmus gesetzt wurden. Bei
beiden Schritten kann sich ergeben, dass ein Testfall nicht realisierbar
ist. Beim vorherigen Schritt (Durchleitungsalgorithmus) könnte sich
herausstellen, dass sich Tests für
einen Block generell nicht realisieren lassen, da die Blockausgänge nicht
mit genügender
Genauigkeit zu beobachten sind und so später beim Test die Übereinstimmung
der Soll- mit den Ist-Werten nicht beurteilt werden kann; bei der
Rückverfolgung
kann sich für
einzelne Testfälle
herausstellen, dass diese nicht zu den Eingängen des Systems zurückverfolgt
werden können.
Dies kann sowohl an logischer Unmöglichkeit bestimmter Fälle aufgrund der
Signalverknüpfungen
im Modell als auch an der Unzulänglichkeit
des Rückverfolgungsalgorithmus
liegen. Der Rückverfolgungsalgorithmus kann
im allgemeinen nicht alle möglichen
Fälle zur
Rückverfolgung
von Wertebereichen ausprobieren, da die Rechenzeit in der Praxis
begrenzt ist.
- – Ergebnis
der Rückverfolgung
von Testfällen
zu den Systemeingängen
ist jeweils ein Wertebereich pro Eingangssignal für alle Eingangssignale, von
denen der jeweils getestete Block abhängt. Um konkrete Tests durchführen zu
können,
wird aus diesen Wertebereichen jeweils ein konkreter Wert gewählt. Bei
weiteren Eingangssignalen, von denen der zu testende Block nicht
abhängt, können beliebige
Werte gewählt
werden. Über den
Vorwärtsverfolgungsalgorithmus
können
aus den gewählten
Systemeingangswerten dann die tatsächlichen Eingangswerte des
zu testenden Blocks berechnet werden, daraus die Soll-Ausgangswerte
des Blocks und schließlich
auch die Soll-Ausgangswerte des Systems.
-
Passiert
man im Verlauf der Rückverfolgung eine
Verzweigung – im
Beispiel zwischen „In1" und „RelOp1" bzw. „Switch" – müssen Wertebereiche von zwei
Eingängen
gleichzeitig berücksichtigt
werden. Dies geschieht, indem die Schnittmenge beider Wertebereiche
gebildet wird. Gelangt man bei der Rückverfolgung zu einem Systemeingang – im Beispiel „In1" oder „In2" – wird der dorthin zurückverfolgte Wertebereich
gespeichert. Ist dies für
alle Systemeingänge
geschehen, die den ursprünglich
betrachteten Block beeinflussen, ist die Rückverfolgung beendet.
-
Ergibt
sich während
der Rückverfolgung
irgendwann als Wertebereich eine leere Menge, ist die Rückverfolgung
erfolglos beendet; dann muss evtl. in einem der bisher durchlaufenen
Blöcke
eine andere Realisierungsmöglichkeit
für die
Eingangswertebereiche ausprobiert werden. Sind für alle durchlaufenen Blöcke alle
Realisierungsmöglichkeiten
ausgeschöpft
und wurde trotzdem keine Lösung
gefunden, lässt
sich der betreffende Ursprungswert nicht zu den Systemeingängen zurückverfolgen.
-
Die
bisherigen Betrachtungen wurden für zustandsunabhängige Blöcke durchgeführt. Zustandsabhängige Blöcke sind
solche Blöcke,
bei denen die Ausgangswerte auch von den Eingangswerten vorangegangener
Berechnungszyklen abhängen.
Beispiele für
zustandsabhängige
Blöcke
sind Verzögerungsglieder
(„1/z"), Integratoren,
Differenzierglieder, Übertragungsfunktionen,
Hysterese-Blöcke,
Regler, Filter und Blöcke,
die Zustandsmaschinen enthalten (z. B. Stateflow-Diagramme).
-
Im
Unterschied zu zustandsunabhängigen Blöcken kommt
es bei zustandsabhängigen
Blöcken nicht
auf einzelne Werte der Eingangssignale an, sondern auf den Verlauf
dieser Eingangssignale in der Vergangenheit. Für die Testfallgenerierung werden
den einzelnen Signalen daher anstelle von einzelnen Wertebereichen
Folgen solcher Wertebereiche („Sequenzen") zugeordnet.
-
Jedem
Wertebereich wird innerhalb einer Sequenz auch noch ein Zeitbereich
zugeordnet, der angibt, für
wie viele Berechnungszyklen der jeweilige Wertebereich gültig ist. Über die
Zykluszeit (z. B. 10 ms, 20 ms, 100 ms etc.) kann daraus die entspre chende
Zeit in Sekunden berechnet werden. Zeitbereiche können nur
positive ganze Zahlen enthalten.
-
In
der 2 ist ein zustandsabhängiges System am Beispiel einer
Hysterese-Funktion
dargestellt. Ist dabei der Wert des Eingangs „X" größer als der
Wert der Konstanten „X2", erhält der Ausgang „Y" den Wert der Konstanten „Y2". Ansonsten erhält „Y" den Wert von „Y1", falls „X" kleiner als „X1" ist. Liegt „X" zwischen „X1" und „X2", bleibt „Y" unverändert auf
demselben Wert wie beim vorherigen Berechnungszyklus. Entscheidend
ist hier die Verwendung des „1/z"-Blocks, dessen Ausgang
jeweils den Wert von „Y" in der letzten Zeitscheibe
ergibt und das ganze System zustandsabhängig macht.
-
Die
eigentliche Testfallerzeugung für
zustandsabhängige
Blöcke
läuft dann
analog der Testfallerzeugung für
zustandsunabhängige
Blöcke
ab, wobei jeweils Wertebereiche durch Sequenzen zu ersetzen sind.
Bei den drei Teilalgorithmen ergeben sich dadurch einige zusätzliche
Punkte, die zu beachten sind:
- – Im Vergleich
zu zustandsunabhängigen
Blöcken kommt
es bei zustandsabhängigen
Blöcken
zusätzlich
darauf an, mittels des Durchleitungsalgorithmus den zeitlichen Verlauf
des zu verfolgenden Signals auf dem Ausgang möglichst unverändert an
den Ausgang des Blocks weiterzugeben. Eine konstante zeitliche Verschiebung
des Eingangssignals wäre
dabei kein Problem. Beim im dargestellten Beispiel verwendeten „1/z"-Block ist genau
dies der Fall, er bewirkt lediglich eine konstante Verzögerung um
eine Zeitscheibe. Dadurch würden
alle Werte von „Y" hier unverändert – wenn auch
verzögert – weitergeleitet.
- – Beim
Rückverfolgungsalgorithmus
muss zusätzlich
zu den Wertebereichen des Ausgangssignals, die auf Wertebereichseinschränkungen
der Eingangssignale zurückzuführen sind,
außerdem ein
zeitlicher Verlauf dieser Eingangswertebereiche berücksichtigt
werden. Auch hierbei kann es Variationsmöglichkeiten für die Eingangssequenzen
geben, die zu denselben Ausgangssequenzen führen, so dass auch hier mehrere
Möglichkeiten
bzw. deren weitere Rückverfolgung
ausprobiert werden müssen.
- – Auch
bei der Vorwärtsverfolgung
von Sequenzen durch einen Block muss durch den Vorwärtsverfolgungsalgorithmus
sichergestellt sein, dass sich für
jede in den Eingangssequenzen enthaltene Folge von Werten an den
Ausgängen
eine Folge von Werten ergibt, die in der errechneten Ausgangssequenz
enthalten ist.
-
Zur
Reduzierung der Gesamtzahl der Testfälle können die ermittelten Testfälle mit
Hilfe eines Optimierungsalgorithmus zusammengefasst werden, wodurch
ebenfalls die Rechenzeit zur Überprüfung des
Programms verringert wird.