-
Die Erfindung betrifft ein Verfahren zum Computer gestützten, automatisierten Überprüfen von mindestens einer Software-Anforderung und zur Erzeugung von Testdaten. Diese Software-Anforderung weist mindestens eine weitere Software-Anforderung als Subkomponente auf, wobei jede der Softwareanforderungen in mindestens einer Datenbank gespeichert ist und zumindest eine Schnittstellenbeschreibung und eine funktionelle Beschreibung aufweist.
-
Aus der Praxis sind verschiedene Computerprogramme bekannt, die Software-Anforderungen in Textform erfassen und in einer Datenbank ablegen. Diese Datenbank ist dabei verlinkt, um Textpassagen, die sich bereits in der Datenbank befinden, an anderer Stelle zu verwenden. So kann beispielsweise eine Schnittstellenbeschreibung im Rahmen einer Komponente zur Signalaufbereitung beschrieben werden. Wenn die dieser Schnittstelle zugeordneten Signale dann an anderer Stelle benötigt werden, kann die entsprechende Schnittstellenbeschreibung hierzu verlinkt werden. Dies hat den Vorteil, dass eine Änderung der Schnittstellenbeschreibung sich auch auf die anderen, verlinkten Komponenten auswirkt. Nachteilig ist jedoch, dass es dem Entwickler überlassen bleibt, ob er diese Verlinkungstechnik auch nutzt und wie er mit einer sich nachträglich ändernden Beschreibung umgeht. Damit kann der Entwickler, der in der Regel von einem mehrköpfigen Team gebildet wird, unvollständige bzw. inkonsistente Software-Anforderungen erstellen. Computerprogramme, welche mit derartigen, mangelhaften Software-Anforderungen erstellt sind, neigen zu großer Fehleranfälligkeit, wodurch sich der Entwicklungsprozess zeitlich sehr in die Länge streckt. In Ermangelung besserer Systeme sind jedoch Entwickler gezwungen, sich dieser bekannten Komponenten zu bedienen. Diese bilden daher den nächstliegenden Stand der Technik zum Erfindungsgegenstand.
-
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren der eingangs genannten Art zu schaffen, welches qualitativ höherwertige Software-Anforderungen erzeugt und Unvollständigkeiten bzw. Inkonsistenzen möglichst frühzeitig erkennt.
-
Diese Aufgabe wird erfindungsgemäß mit den folgenden Merkmalen gelöst.
-
Bei dem erfindungsgemäßen Verfahren wird mindestens eine Software-Anforderung in einer Datenbank gespeichert. Als Datenbank ist eine Ansammlung von Datenblöcken zu verstehen, die in einer oder mehreren Dateien gespeichert sind und für die eine wahlfreie Zugriffsmöglichkeit eingerichtet ist. Diese Software-Anforderung weist mindestens eine weitere Software-Anforderung als Subkomponente auf, wobei diese Subkomponente grundsätzlich in gleicher Weise wie die Hauptkomponente zu behandeln ist. Jede Software-Anforderung weist zumindest eine Schnittstellenbeschreibung für mindestens ein Eingangs- und/oder Ausgangssignal und mindestens eine funktionelle Beschreibung in formalisierter Form auf. Die Schnittstellenbeschreibung umfasst sämtliche Details, die die jeweilige Schnittstelle und das Signal betreffen, welches über diese Schnittstelle empfangen und/oder gesendet wird. Dies können beispielsweise sein: Datenbreite, Wertebereich, Protokoll, zugeordneter physikalischer Wert, Abtastfrequenz, Portzuordnung, Initialisierungserfordernis und -verfahren, Filtererfordernis und -verfahren, Mittelungserfordernis und -verfahren und Zuverlässigkeitsindikatoren. Diese Aufzählung ist jedoch nur beispielhaft und nicht abschließend zu verstehen. Die funktionelle Beschreibung erfolgt in formalisierter Form, beispielsweise als Flussdiagramm, Zustandsautomat oder Pseudocode. Auch diese Aufzählung ist nur beispielhaft und nicht abschließend zu verstehen. Um Lücken bzw. Fehler in der Software-Anforderung möglichst frühzeitig zu erkennen, erfolgt eine Computer gestützte Prüfung auf Vollständigkeit bzw. Konsistenz. Diese Prüfung umfasst die Schnittstellenbeschreibung und/oder die funktionelle Beschreibung. Bei der Vollständigkeitsprüfung der Schnittstellenbeschreibung kann insbesondere geprüft werden, ob alle erforderlichen Angaben in der Schnittstellenbeschreibung enthalten sind. Diese hängen grundsätzlich von der spezifizierten Art des Signals ab. So werden an rein binäre Signale wesentlich geringere Definitionsanforderungen gestellt als an seriell bzw. parallel übermittelte Daten. Werden Informationen beispielsweise seriell übertragen, so ist die Anwendung des jeweiligen Protokolls von entscheidender Bedeutung. Bei reinen Zustandsinformationen spiegelt das Signal unmittelbar einen äußeren Systemzustand wieder, so dass hier keinerlei Protokollinformationen benötigt werden. Bei der Konsistenzprüfung der Schnittstellenbeschreibung werden gegenseitige Abhängigkeiten berücksichtigt. Wird beispielsweise in der Schnittstellenbeschreibung ein Signal als serieller Datenstrom gekennzeichnet, ohne ein entsprechendes Protokoll zu spezifizieren, kann diese Inkonsistenz erkannt und als Warnung bzw. Fehler ausgegeben werden. Bezüglich Echtzeitanforderungen kommen Informationen wie Samplingrate, Latenzzeit und die geforderte Reaktionszeit auf ein bestimmtes Trigger-Ereignis in Betracht. Es ist auch daran gedacht zu prüfen, ob die angegebenen Echtzeitanforderungen konsistent zueinander sind. Eine Inkonsistenz ergibt sich beispielsweise daraus, dass die Reaktionszeit einer Schnittstellenbeschreibung eines Ausgangssignals kürzer ist als die Summe der damit verbundenen Sampling- und Bearbeitungszeiten. Ebenso könnte eine Inkonsistenz durch Verletzung des Abtasttheorems aufgefunden werden. Dies betrifft sowohl Eingangs- als auch Ausgangssignale. Wenn die Abtast- bzw. Update-Rate kleiner als die halbe Signalperiode ist, ist eine ordnungsgemäße Signalverarbeitung ausgeschlossen. In diesem Fall wird ein entsprechender Fehler bzw. eine Warnung ausgegeben. Bei der Schnittstellenbeschreibung spielt es keine Rolle, ob die Schnittstelle eine externe oder interne Hardware-Schnittstelle oder eine Software-Schnittstelle betrifft. Software-Schnittstellen sind in der Regel Daten, welche in einem entsprechenden Speicher abgelegt sind. Diese können in gleicher Weise wie Hardware-Schnittstellen beschrieben und geprüft werden. Die funktionelle Beschreibung beschreibt den konkreten Programmablauf und lässt sich folglich nicht mit der gleichen Gründlichkeit wie die Schnittstellenbeschreibung prüfen. In eingeschränktem Maß sind jedoch auch hier Prüfungen auf Vollständigkeit und Konsistenz möglich. Da alle genannten Prüfungen Computer gestützt stattfinden, können Dokumentationsfehler in der Software-Anforderung erkannt werden, bevor die erste Programmzeile der entwickelten Software geschrieben ist. Insbesondere ist daran gedacht, der Schnittstellenbeschreibung eine erhöhte Bedeutung zukommen zu lassen. Dies geschieht insbesondere dadurch, dass sämtliche Signal bezogenen Informationen ausschließlich in den Schnittstellenbeschreibungen abgelegt werden. Auf diese Weise wird vermieden, dass sich Signal bezogene Informationen der Vollständigkeits- bzw. Konsistenzprüfung entziehen können. Damit ergibt sich eine zwangsweise Verlinkung der Schnittstellenbeschreibungen. Wenn an irgendeiner Stelle in der Software-Anforderung Informationen zu einem Signal benötigt werden, können diese ausschließlich aus der zugeordneten Schnittstellenbeschreibung kommen. Da diese Schnittstellenbeschreibung aber auf Vollständigkeit und Konsistenz mit hoher Güte geprüft ist, werden Definitionsfehler und -lücken auf diese Weise mit hoher Wahrscheinlichkeit ausgeschlossen. Grundsätzlich zwingt dieses Verfahren den Entwickler dazu, sich frühzeitig zu allen möglichen Details Gedanken zu machen, bevor Inkonsistenzen entstehen können. Auf diese Weise entsteht eine Software mit hoher Qualität und sehr kurzem Entwicklungszyklus, was die Produktivität der Softwareerzeugung insgesamt erheblich verbessert.
-
Vorzugsweise umfasst die Prüfung der Schnittstellenbeschreibung das Überprüfen, ob bestimmte Informationen hinterlegt sind, beispielsweise ob die Schnittstelle zu initialisieren, zu filtern bzw. zu prüfen ist. Oftmals ist eine komplexe Signalaufbereitung erforderlich, was durch spezialisierte Bausteine wie beispielsweise Analog-Digital-Umsetzer, Frequenzzähler oder andere Komponenten erledigt wird. Diese Komponenten benötigen manchmal eine Initialisierung, bevor der erste Wert für das Signal ermittelt werden kann. Für andere Schnittstellen, beispielsweise reine Digitalschnittstellen ist dagegen eine Initialisierung oftmals nicht erforderlich. Je nach Signalqualität kann es auch erforderlich sein, das der Schnittstelle zugeordnete Signal zu filtern, um Störimpulse zu eliminieren oder die Signalgenauigkeit zu erhöhen. Es ist zweckmäßig zu prüfen, ob diesbezüglich entsprechende Angaben in der Schnittstellenbeschreibung enthalten sind, so dass beim Fehlen dieser Angaben eine entsprechende Warnung ausgegeben wird. Außerdem kann es erforderlich sein, ein der Schnittstelle zugeordnetes Signal zu prüfen, um beispielsweise dessen Konsistenz oder Qualität zu bestimmen. Auch das Vorhandensein dieser Information wird zweckmäßigerweise geprüft, um zu verhindern, dass Signale mit schlechter Qualität oder sogar irreguläre Signale der weiteren Prozessverarbeitung zugeführt werden.
-
Für den Fall, dass in der Schnittstellenbeschreibung die Initialisierung, das Filtern oder Prüfen gefordert wird, ist es zweckmäßig, auch das hierfür erforderliche Verfahren in der Schnittstellenbeschreibung zu hinterlegen. Dies erfolgt am zweckmäßigsten durch eine entsprechende funktionelle Beschreibung in formalisierter Form. Das erfindungsgemäße Verfahren prüft in diesem Fall, ob ein entsprechendes Verfahren hinterlegt ist oder entsprechende Parameter, beispielsweise die Zahl der erforderlichen Mittelungen, zur Filterung des Messwertes hinterlegt sind.
-
Oftmals haben Signale nur einen beschränkten Gültigkeitsbereich, wobei bei Über- bzw. Unterschreiten dieses Gültigkeitsbereichs Sonderbehandlungen auszuführen sind. Um diese Sonderbehandlungen konsistent über die gesamte Software-Anforderung zu erstellen, ist es zweckmäßig, den Gültigkeitsbereich des Signals in der Schnittstellenbeschreibung zu hinterlegen. Das erfindungsgemäße Verfahren prüft daher, ob ein entsprechender Gültigkeitsbereich definiert ist. Grundsätzlich ist daran gedacht, neben dem Gültigkeitsbereich auch Zwischenwerte, insbesondere Grenzwerte des Signals in der Schnittstellenbeschreibung zu hinterlegen. Diese Grenzwerte können dann beispielsweise in der funktionellen Beschreibung zum Vergleich mit dem Signal herangezogen werden. Es ist jedoch nicht zweckmäßig, diese Grenzwerte auf Vollständigkeit der Schnittstellenbeschreibung zu prüfen, da eine Prüfung anhand objektiver Kriterien fehlschlagen wird. Für derartige Anwendungsfälle ist es zweckmäßiger, die funktionelle Beschreibung dahingehend zu überprüfen, dass als Vergleichsparameter ausschließlich Parameter aus Schnittstellenbeschreibungen genutzt werden. Auf diese Weise ergibt sich eine konsistente Benutzung der Grenzwerte.
-
In der Regel müssen die Signale, die von Schnittstellen bezogen werden, in entsprechenden Variablen gespeichert werden. Auf diese Variablen kann dann die funktionelle Beschreibung Bezug nehmen, sofern sichergestellt ist, dass durch das Speichern der Signale in der Variablen kein Informationsverlust entsteht. Aus diesem Grund umfasst die Prüfung einen Vergleich der Datenbreite bzw. des Vorzeichens der Schnittstellenbeschreibung mit der zugeordneten Variablen. Kommt dieser Vergleich zu dem Ergebnis, dass beim Speichern des Signals in der Variablen Information verloren geht, weil beispielsweise die Datenbreite zu gering ist oder ein mögliches negatives Vorzeichen verloren ginge, so wird eine entsprechende Warnung erzeugt.
-
Naturgemäß ist die funktionelle Beschreibung wesentlich schwieriger zu prüfen als die Schnittstellenbeschreibung, da die funktionelle Beschreibung den eingesetzten Algorithmus wiedergeben muss. Es ist schwierig, einen Fehler in einem Algorithmus computergestützt aufzufinden. Trotzdem sind gewisse Prüfungen der funktionellen Beschreibung machbar. Beispielsweise kann geprüft werden, ob jeder Zustand der funktionellen Beschreibung aufgrund von definierten Zustandswechselbedingungen erreichbar ist. Ist ein Zustand nicht erreichbar, so liegt offensichtlich ein algorithmischer Fehler vor, der eine entsprechende Warnung zur Folge hat. Dabei kann es durchaus sein, dass ein Zustand nur dann erreichbar ist, wenn ein Signal seinen Gültigkeitsbereich verlässt, um in diesem Zustand dann eine Sonderbehandlungsroutine abzuarbeiten. Ist aber ein Zustand nur aufgrund von einander widersprechenden Signalbedingungen und/oder physikalisch nicht realisierbaren Signalen erreichbar, so liegt offensichtlich ein algorithmischer Fehler in der funktionellen Beschreibung vor, der beim Prüfen durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt.
-
Außerdem ist es vorteilhaft zur prüfen, ob von jedem Zustand der funktionellen Beschreibung ein Folgezustand erreichbar ist. Wenn kein Folgezustand mehr erreichbar wäre, müsste das System für immer in diesem Zustand verbleiben, so dass die Software als „abgestürzt“ zu bezeichnen wäre. Damit liegt für den Fall, dass kein Folgezustand erreichbar ist, ein algorithmischer Fehler in der funktionellen Beschreibung vor, der durch das erfindungsgemäße Verfahren zu einer entsprechenden Warnung führt.
-
Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob jedes definierte Signal der Schnittstellenbeschreibung in der funktionellen Beschreibung verwendet wird. Im gegenteiligen Fall erzeugt das erfindungsgemäße Verfahren eine entsprechende Warnung. Diese Warnung zeigt dem Entwickler an, dass er entweder ein Signal in der funktionellen Beschreibung vergessen hat oder dieses Signal aus der Schnittstellenbeschreibung löschen oder als „reserviert“ markieren sollte. Diese Maßnahme verhindert insbesondere, dass der Entwickler aus Bequemlichkeitsgründen in der Schnittstellenbeschreibung seiner Software-Anforderung einfach grundsätzlich alle möglichen Schnittstellen in der Schnittstellenbeschreibung anführt, die er vielleicht irgendwo benötigen könnte. Damit umgeht der Entwickler aber das Gebot, sich über die erforderlichen Signale zuerst Gedanken zu machen, bevor er die funktionelle Beschreibung erstellt. Das erfindungsgemäße Verfahren quittiert diese Vorgangsweise dann mit einer entsprechenden Anzahl von Warnungen, so dass der Entwickler zwangsweise einen sauberen Schnittstellenansatz definieren muss.
-
Insbesondere bei komplexen Software-Anforderungen kommt es immer wieder vor, dass Ausgangssignale inkonsistent sind, da verschiedene Komponenten der Software-Anforderung unterschiedliche Werte für das Ausgangssignal fordern. Wenn beispielsweise eine Komponente ein bestimmtes Ausgangssignal auf Eins setzt, wenn ein Eingangssignal A aktiv ist und eine weitere Komponente dasselbe Ausgangssignal auf Null setzt, wenn ein Eingangssignal B inaktiv ist, so kann es durchaus vorkommen, dass widersprüchliche Bedingungen für das Ausgangssignal vorliegen, insbesondere wenn das Eingangssignal A aktiv und das Eingangssignal B inaktiv ist. Derartige Fehler sind in der fertigen Software nur sehr schwer zu finden und verursachen daher eine beträchtliche Verlängerung der Entwicklungszeit. Es ist daher zweckmäßig, die Eindeutigkeit der Ausgangssignale bzw. Ausgangssignaländerungen bereits in der funktionellen Beschreibung zu prüfen und Fälle wie den oben genannten mit einer entsprechenden Warnung zu quittieren.
-
In der Informatik sind rekursive Algorithmen bekannt, die einen einfachen, programmtechnischen Ansatz zur Lösung eines komplexen mathematischen Problems bieten. Derartige rekursive Ansätze sind jedoch in der Signalverarbeitung höchst gefährlich, da sie davon ausgehen, dass die entsprechenden Eingangswerte konstant bleiben. Dies ist bei der Signalverarbeitung aber gerade nicht der Fall. Aus diesem Grund ist es zweckmäßig zu prüfen, ob die funktionelle Beschreibung rekursive Signalabfragen enthält. Dies kann man am einfachsten dadurch feststellen, dass geprüft wird, ob eine Zustandsänderungsbedingung in der funktionellen Beschreibung in Abhängigkeit von einem Signal steht, welches von derselben funktionellen Beschreibung erzeugt werden soll. Damit werden rekursive Signalabfragen mit entsprechenden Warnungen durch das erfindungsgemäße Verfahren quittiert. Ein rekursiver Algorithmus ohne Einflussnahme auf Zustände, wie beispielsweise die schnelle Analog-Digital-Wandlung ist davon jedoch nicht betroffen.
-
Um zu verhindern, dass wichtige Werte, wie beispielsweise Vergleichswerte in Zustandsänderungsbedingungen an beliebiger Stelle hinterlegt werden und damit einer Vollständigkeitsprüfung entzogen werden, ist es vorteilhaft, wenn das erfindungsgemäße Verfahren Zustandswechselbedingungen dahingehend überprüft, ob darin Werte genutzt werden, die nicht in der Schnittstellenbeschreibung hinterlegt sind. Damit ist der Entwickler gezwungen, sämtliche Vergleichswerte, die er für seine funktionelle Beschreibung benötigt, in der Schnittstellenbeschreibung zu hinterlegen, wo sie dann in der gesamten Software-Anforderung auf Konsistenz überprüfbar ist.
-
Um auf der anderen Seite zu verhindern, dass der Entwickler prophylaktisch einfach alle möglichen Werte in der Schnittstellenbeschreibung definiert, die er möglicherweise einmal benötigen könnte, ist es zweckmäßig zu prüfen, ob die in der Schnittstellenbeschreibung definierten Werte in der funktionellen Beschreibung verwendet werden. Überflüssige Werte der Schnittstellenbeschreibung erzeugen dann eine entsprechende Warnung. Es kann beispielsweise vorkommen, dass neben einem komplett aufbereiteten Signal zusätzlich eine Signalrohform, beispielsweise das ungefilterte Signal, gespeichert werden soll. Kommt es zu einem unerwarteten Störfall, so kann aus diesem Speicher der zeitliche Verlauf des Rohsignals ausgelesen werden, um Anhaltspunkte für eine Früherkennung des Störfalls zu finden. Diese Information ist für die Weiterentwicklung des Softwareprodukts von erheblicher Bedeutung, insbesondere bei sicherheitsrelevanten Komponenten wie Flugzeug- oder Kraftwerkskomponenten. Um das Rohsignal einem Datenlogger zuführen zu können, muss dieses aber für die Datenlogger-Komponente verfügbar sein. Dies kann am einfachsten dadurch geschehen, dass es in der Schnittstellenbeschreibung aufgeführt wird. Damit wird aber auch klar dokumentiert, dass unterschiedliche Komponenten unterschiedliche Verarbeitungsstadien des Signals erhalten, wodurch Verwechslungen ausgeschlossen werden. Durch das Überprüfen der Verwendung des Rohsignals in der funktionellen Beschreibung ist außerdem sichergestellt, dass der Entwickler nicht grundsätzlich alle möglichen Verarbeitungsstufen in der Schnittstellenbeschreibung öffentlich macht, weil er auf diese Weise mit einer Vielzahl von Warnungen überschüttet würde.
-
Außerdem ist es zweckmäßig, die funktionelle Beschreibung dahingehend zu prüfen, ob ein berechneter Wert genutzt wird, bevor er überschrieben wird. In der Regel ist das Überschreiben eines Wertes vor dessen Auslesen ein algorithmischer Fehler, so dass hier eine entsprechende Warnung erstellt wird.
-
Oftmals ist es erforderlich, in einer Software-Anforderung verschiedene Modi zu definieren, in denen die zu erstellende Software jeweils unterschiedlich abgearbeitet werden soll. Diese Modi können beispielsweise sein: Normaler Betriebsmodus, Unterspannungsmodus, defekter Sensormodus, defekter Aktormodus, ungenügender Speicherplatzmodus usw. Alternativ oder zusätzlich können auch Modi für verschiedene Ausführungsformen der Software-Anforderung, beispielsweise für unterschiedliche Applikationsmodelle definiert werden. So kann eine bestimmte Komponente für ein Kraftfahrzeug unterschiedliche Modi für verschiedene Kraftfahrzeugmodelle aufweisen, so dass die Adaption auf ein bestimmtes Kraftfahrzeugmodell durch einfache Wahl des Modus erfolgen kann. Die unterschiedlichen Modi sind dabei auch kombiniert einsetzbar. So können beispielsweise zwei Modi für die Betriebsspannung, zwei Modi für den Zustand der Sensoren, zwei Modi für den Zustand der Aktoren und vier Modi für die Modelle eingesetzt werden. Dies ergibt dann 32 verschiedene Modi. In Realität können die Modi noch wesentlich komplexer werden, was deren akkumulierte Zahl noch wesentlich in die Höhe treibt. Bei derartigen Software-Anforderungen ist es relativ schwierig, eindeutig festzulegen, ob eine bestimmte funktionelle Beschreibung auch tatsächlich eindeutig den verschiedenen Modi zugeordnet ist. Diese eindeutige Zuordnung ist jedoch unabdingbare Voraussetzung für eine korrekt laufende Software. Aus diesem Grund ist es zweckmäßig zu prüfen, ob für jeden definierten Modus eindeutig festgelegt ist, ob mindestens eine der funktionellen Beschreibungen auszuführen ist. Beim Auftreten von Definitionslücken bezüglich der Moduswahl wird dann eine entsprechende Warnung erzeugt. Bei der Definition von Modi kommt es relativ häufig vor, dass mögliche Moduswechsel übersehen werden. Es kann zwar durchaus vorkommen, dass bestimmte Moduswechsel ausgeschlossen werden können. In der Regel ist jedoch ein nicht definierter Moduswechsel ein Indiz für eine unvollständige Software-Anforderung. Aus diesem Grund ist es zweckmäßig zu prüfen, ob von jedem Modus jeder andere Modus erreichbar ist, oder dessen Erreichbarkeit ausdrücklich verneint ist. Die letztgenannte Möglichkeit erlaubt, eine entsprechende Warnung zu unterdrücken, wenn ein bestimmter Modusübergang nicht vorgesehen ist. In diesem Fall ist jedoch eine ausdrückliche Verneinung erforderlich, so dass der Entwickler sich über den nicht definierten Moduswechsel Gedanken gemacht haben muss. Ein versehentliches Weglassen eines bestimmten Moduswechsels ist hierdurch jedoch ausgeschlossen.
-
Die Erfindung betrifft außerdem ein Verfahren zum Computer gestützten, automatischen Erzeugen von Testdaten für eine Software, die eine Software-Anforderung erfüllen soll. Im Stand der Technik wird hierzu eine Vielzahl von Testdaten zwischen den definierten Grenzen des Gültigkeitsbereichs der einzelnen Signale erzeugt, um die erzeugte Software zu testen. Bei Software-Anforderungen, die nach dem erfindungsgemäßen Verfahren geprüft sind, ist jedoch gewährleistet, dass - die Beachtung von Warnungen vorausgesetzt - sämtliche Schwellwerte zum Vergleich mit Signalen in den Schnittstellenbeschreibungen hinterlegt sind. Damit sind alle Grenzwerte, bei denen sich das Verhalten der Software in irgendeiner Weise ändert, durch Werte eindeutig festgelegt, die in den Schnittstellenbeschreibungen festgelegt sind. Dies wird beim erfindungsgemäßen Verfahren zum automatischen Erzeugen von Testdaten dahingehend ausgenutzt, dass die Schnittstellenbeschreibungen aller Eingangssignale analysiert werden, wobei alle in der Schnittstellenbeschreibung eingetragenen Werte jedes Eingangssignals sortiert werden. Zwischen jeweils benachbarten Werten dieser sortierten Wertereihe ändert sich das grundsätzliche Verhalten der Software nicht. Darum reicht es aus, jeweils einen Testwert zwischen diesen eingetragenen Werten zu erzeugen und diese Werte in unterschiedlichen Permutationen als Testdaten auszugeben. Damit werden wesentlich weniger Testdaten erzeugt, wobei sichergestellt ist, dass jede Abfragebedingung der Signale in den Testdaten realisiert wird. Der Test der Software wird auf diese Weise nicht nur schneller, sondern auch sicherer.
-
Das erfindungsgemäße Verfahren wird vorzugsweise für Software-Anforderungen eingesetzt, welche zur Steuerung und/oder Regelung mindestens eines technischen Prozesses dienen. Dort sind relativ hohe Anforderungen an die Software-Sicherheit zu stellen, so sich das erfindungsgemäße Verfahren. in diesem Bereich besonders vorteilhaft auswirkt.
-
Vorzugsweise läuft die Software auf mindestens einem Controller, welcher neben der zentralen Recheneinheit auch Speicher und Schnittstellen aufweist. In diesem Bereich, der auch als „embeded system“ bezeichnet wird, gelten besonders hohe Anforderungen an die Softwaresicherheit, da ein Eingriff in die Software von außen in der Regel nicht möglich ist.
-
Das erfindungsgemäße Verfahren wird beispielhaft und auszugsweise ohne Anspruch auf Vollständigkeit anhand der folgenden Ausführungsbeispiele unter Bezugnahme auf die Zeichnung näher erläutert. Diese Ausführungen dienen lediglich dazu, das erfindungsgemäße Verfahren zu erläutern und nicht, um den Schutzbereich festzulegen, der durch die Ansprüche definiert ist.
-
Es zeigt:
- 1 ein Verfahren zum Prüfen der Schnittstellenbeschreibung auf Vollständigkeit,
- 2 ein Verfahren zum Prüfen der funktionellen Beschreibung auf Erreichbarkeit aller Zustände und
- 3 ein Verfahren zur Realisierung einer state-Funktion.
-
Die 1 zeigt einen Algorithmus zur Überprüfung der Schnittstellenbeschreibung auf Vollständigkeit. Dabei wird vorausgesetzt, dass dem Entwickler ein Template zur Anlage einer Schnittstellenbeschreibung in einer Datenbank zur Verfügung gestellt wurde, in dem entsprechende Felder zum Ausfüllen enthalten sind. Der Algorithmus gemäß 1 prüft die in der Datenbank abgelegten Schnittstellenbeschreibungen in folgender Weise:
- In Schritt 1 wird eine Zählvariable n auf den Wert 0 initialisiert. Diese Zählvariable n dient zur Referenzierung der Schnittstellenbeschreibungen. Dies bedeutet, dass die erste Schnittstellenbeschreibung mit n = 0, die zweite Schnittstellenbeschreibung mit n = 1 usw. referenziert werden kann. In Schritt 2 wird eine weitere Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m dient zur Referenzierung der einzelnen Datenfelder innerhalb der Schnittstellenbeschreibung, wobei das erste Datenfeld mit dem Index m = 0 referenziert wird.
- In Schritt 3 wird abgefragt, ob in der Datenbank zur Schnittstellenbeschreibung n im Feld m ein Wert eingetragen ist. Außerdem wird in Schritt 3 abgefragt, ob der eingetragene Wert in der Datenbank auch konsistent zu den übrigen Werten der Schnittstellenbeschreibung n ist. Falls mindestens einer der genannten Tests fehlschlägt, verzweigt die Abfrage gemäß Schritt 3 zum Zweig 3F. In diesem Fall wird in Schritt 4 eine entsprechende Warnung erzeugt und ausgegeben. Falls die Tests gemäß Schritt 3 keine Beanstandungen finden, wird der Zweig 3T genutzt, wodurch die Ausgabe der Warnung in Schritt 4 unterdrückt wird.
- In Schritt 5 wird die Zählvariable m inkrementiert, um auf diese Weise das nächste Feld innerhalb der Schnittstellenbeschreibung n zu adressieren.
- Im folgenden Schritt 6 wird abgefragt, ob die Zählvariable m noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 6T verzweigt, so dass der Programmfluss mit Schritt 3 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 6F verzweigt und der folgende Schritt 7 ausgeführt.
- In Schritt 7 wird die Zählvariable n inkrementiert, um auf diese Weise die nächste Schnittstellenbeschreibung zu adressieren.
- Im folgenden Schritt 8 wird abgefragt, ob die Zählvariable n noch innerhalb zulässiger und vordefinierter Grenzwerte liegt. Falls dies der Fall ist, wird zum Zweig 8T verzweigt, so dass der Programmfluss mit dem Schritt 2 fortgesetzt wird. Liegt die Zählvariable m aber innerhalb des zulässigen Bereichs, so wird zum Zweig 8F verzweigt und der folgende Schritt ausgeführt.
-
Nach Durchlaufen dieses Algorithmus sind sämtliche Schnittstellenbeschreibungen auf Vollständigkeit und Konsistenz geprüft. Wie man sieht, ist die Prüfung der Schnittstellenbeschreibung programmtechnisch relativ einfach, wobei trotzdem eine sehr hohe Prüfungsgüte erzielt werden kann. Diese Vereinfachung ist eine Folge der Trennung der gesamten Software-Anforderung in eine funktionelle Beschreibung und eine Schnittstellenbeschreibung.
-
2 zeigt einen Algorithmus zur Überprüfung der funktionellen Beschreibung. Dabei wird vorausgesetzt, dass die funktionelle Beschreibung in Form eines Zustandsautomaten in der oben genannten Datenbank gespeichert ist.
-
In Schritt 10 wird die Funktion state (init) aufgerufen. Diese Funktion versetzt einen virtuellen Zustandsautomaten in jenen Zustand, in den der Zustandsautomat beispielsweise unmittelbar nach einem reset kommt. Dies ist also der Ausgangszustand des Zustandsautomaten. Außerdem werden von dieser Funktion verschiedene Prüfungen durchgeführt, die weiter unten erläutert sind.
-
In Schritt 11 wird eine Zählvariable n auf 0 initialisiert. Dabei wird vorausgesetzt, dass die einzelnen Zustände des Zustandsautomaten in der Datenbank über die Zählvariable n initiiert abgerufen werden können.
-
In Schritt 12 wird geprüft, ob beim Zustand n das checked-flag gesetzt ist. Falls dies nicht der Fall ist, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12F und erzeugt in Schritt 13 eine entsprechende Warnung, welche ausgegeben wird. Falls das checked-flag jedoch gesetzt war, verzweigt die Abfrage gemäß Schritt 12 in den Zweig 12T und unterdrückt die Ausgabe der Warnung durch Umgehung des Schritts 13.
-
In Schritt 14 wird die Zählvariable n inkrementiert, um auf diese Weise den nächsten, folgenden Zustand aufzurufen.
-
In der Abfrage gemäß Schritt 15 wird nun geprüft, ob die Zählvariable n innerhalb zulässiger Grenzen ist oder ob n einen Zustand referenziert, der nicht mehr existiert. Falls die Zählvariable n zulässig ist, verzweigt die Abfrage gemäß Schritt 15 zum Zweig 15T, so dass der Programmfluss zum Schritt 12 verzweigt. Falls jedoch die Zählvariable n ungültig ist, ist die Prüfung abgeschlossen.
-
In 3 ist der Algorithmus für die state-Funktion gemäß Schritt 12 dargestellt. Es versteht sich von selbst, dass der Schritt 10 in gleicher Weise auszubilden ist.
-
In einem Schritt 20 wird eine Zählvariable m auf den Wert 0 initialisiert. Diese Zählvariable m referenziert für den jeweiligen, ausgewählten Zustand eine entsprechende Zustandswechselbedingung, einschließlich einer Referenz auf den jeweiligen Folgezustand. In einem Schritt 21 wird abgefragt, ob ein checked-flag des ausgewählten Zustandes gesetzt ist. In diesem Fall wird der Programmfluss im Zweig 21T fortgesetzt. Falls das checked-flag jedoch nicht gesetzt ist, wird mit dem Zweig 21F fortgesetzt. Dabei ist zu berücksichtigen, dass das checked-flag jedes Zustandes zu Beginn des beschriebenen Algorithmus zurückgesetzt ist. Durch Setzen dieses checked-flags wird angezeigt, dass dieser Zustand bereits geprüft wurde und daher eine weitere Prüfung unterlassen werden kann. Auf diese Weise werden Endlosschleifen vermieden. Außerdem wird auf diese Weise die Effizienz des Algorithmus erheblich gesteigert, da doppelte und mehrfache Prüfungen desselben Zustandes zuverlässig ausgeschlossen werden.
-
Vom Zweig 21F wird der Schritt 22 ausgeführt, in dem das checked-flag gesetzt wird. Damit wird angezeigt, dass der aktuelle Zustand nunmehr der Prüfung unterworfen wurde und eine erneute Prüfung auszuschließen ist.
-
Im folgenden Schritt 23 erfolgen eine oder mehrere Abfragen zum Zustand, die insbesondere die Vollständigkeit und Konsistenz betreffen. Im Falle von Inkonsistenzen oder Unvollständigkeiten wird in den Zweig 28F verzweigt und in Schritt 24 eine entsprechende Warnung ausgegeben. Anderenfalls wird Schritt 24 durch Auswahl des Zweiges 24T unterdrückt.
-
Im folgenden Schritt 25 wird ein Zeiger der Übergangsbedingung mit dem Index m ausgelesen und in Schritt 26 die Funktion state mit dem auf diese Weise ermittelten Zeiger als Parameter aufgerufen. Damit ergibt sich ein rekursiver Aufruf der Funktion state, durch den sichergestellt ist, dass alle möglichen Zustände und Zustandsübergänge berücksichtigt werden.
-
In Schritt 27 wird die Zählvariable m inkrementiert, um die nächste Übergangsbedingung zu prüfen.
-
In Schritt 28 wird abgefragt, ob die Zählvariable m noch innerhalb erlaubter Grenzen liegt. Falls dies der Fall ist, wird in den Zweig 28T verzweigt, so dass dann wieder der Schritt 21 ausgeführt wird. Referenziert die Zählvariable m jedoch einen ungültigen Zustand, so wird in den Zweig 28F verzweigt und die Abfrage gemäß Schritt 29 ausgeführt. In dieser Abfrage gemäß Schritt 29 wird geprüft, ob die Zählvariable m einen Wert > 1 erreicht hat. Falls dies der Fall ist, wird die state-Funktion durch Wahl des Zweiges 29T beendet. Anderenfalls wird der Zweig 29F angewählt und in Schritt 30 die Warnung erzeugt, dass kein Folgezustand erreichbar ist.
-
Der Ablauf dieses Algorithmus ist durch den rekursiven Aufruf der Funktion state relativ komplex, aber anders nur sehr schwer realisierbar. Die Funktion state beginnt dabei mit dem Ausgangszustand gemäß Schritt 10 und prüft diesen nach den vorgegebenen Kriterien. Für den Fall, dass der Zustand bereits geprüft wurde, werden sämtliche Prüfungen, einschließlich der Aufrufe von Folgezuständen unterdrückt. Der rekursive Algorithmus geht zunächst die Zustände in der Reihenfolge der ersten in jedem Zustand genannten Übergangsbedingung durch, bis entweder kein Folgezustand mehr gefunden werden kann oder ein Zustand aufgerufen wird, der bereits geprüft wurde. Anschließend wird die zuletzt gewählte Übergangsbedingung des Zustandsautomaten auf die in der Datenbank nächste angegebene Übergangsbedingung verändert und der Algorithmus in gleicher Weise ausgeführt. Demnach werden die einzelnen Übergangsbedingungen des Initialisierungszustandes in der Regel zuletzt bearbeitet.
