DE19723252C2 - Verfahren zum automatischen Testen komplexer Systeme - Google Patents

Description

Die Erfindung betrifft ein Verfahren gemäß dem Oberbegriff des Patentanspruchs 1.

Bei den heute existierenden Telekommunikationsanlagen handelt es sich um sehr große und extrem komplexe technische Systeme mit komplexen Funktionen. Aufgrund der wachsenden Komplexität dieser Systeme wird es zunehmend schwieriger und aufwendiger, die geforderten Anforderungen bezüglich Zuverlässigkeit und Funktionalität zu erfüllen. Durch die stetige Weiterentwick­ lung der zugrunde liegenden Protokollspezifikationen durch nationale und internationale Normierungsgremien sind Telekom­ munikationsanlagen daher einer stetigen Modifizierung unter­ worfen.

Darüberhinaus ist den Kundenanforderungen nach immer mehr Leistungsmerkmalen gerecht zu werden. Daher ist auch von die­ ser Seite ebenfalls eine stetige Modifizierung der Software unumgänglich. Für die Entwicklung der Software bedeutet dies ein kontinuierliches Erweitern der bestehenden Telekommunika­ tionsanlagen um neue Anteile, wobei die schon existierenden Funktionen in keinerlei Weise beeinträchtigt werden dürfen.

Aus diesem Grunde werden hohe Anforderungen an die Qualität der Entwurfsverfahren und an die Zuverlässigkeit solcher Sy­ steme gestellt. Wichtigstes Hilfsmittel zur Sicherung der ge­ wünschten Funktionalität ist heute weiterhin die Validierung des Systems durch Testen. Hierbei wird die Reaktion des ent­ wickelten Systems, insbesondere von Systemkomponenten auf Eingabe gewisser Testsequenzen mit den erwarteten Reaktionen verglichen. Eine Diskrepanz weist auf ein Fehlverhalten hin, dessen Ursache lokalisiert und behoben wird. Die Auswahl der Testsequenzen und die Vorgabe des erwarteten Verhaltens bzw. die Auswertung der Testergebnisse werden vom Entwickler über­ wiegend manuell durchgeführt.

Die Problematik dieser Entwurfs- und Teststrategie ist, daß im Grunde nur relativ wenige Szenarien aus einer sehr großen Menge möglicher Szenarien getestet werden. Damit ist es aber sehr wahrscheinlich, daß eine Konstellation, die einen Fehler beinhaltet, unerkannt bleibt. Die Erfahrung zeigt, daß insbe­ sondere in vom Normalablauf abweichenden Abläufen oder in Fehler- und Exception-Behandlungen sehr viele Abläufe möglich sind, die nur schwer überschaubar und testbar sind.

Beim gegenwärtigen Stand der Technik besteht weiterhin das Problem, daß aufgrund unzulänglicher Testverfahren der einzu­ bringenden Software nach wie vor Fehler im Code sowie logi­ sche Fehler auftreten. Wenn diese Softwarekomponenten unter praktischen Gegebenheiten zum Ablauf gelangen, kann dies unter Umständen dazu führen, daß extrem seltene Konstellati­ onen mit der umgebenden Software auftreten, die dann zu einem gravierenden Fehlverhalten führen.

Aus der DE 195 29 342 A1 ist ein Verfahren zur Ermittlung des Überdeckungsgrades beim Test eines endlichen Automaten be­ kannt. Hierbei findet eine Beschränkung auf eine relative kleine Anzahl von Testfällen statt, worunter die Effizienz des Tests leidet.

Der Erfindung liegt die Aufgabe zugrunde, neue in ein komple­ xes System einzubringende Programme auf korrekte Codierung sowie Funktionalität hin effizient zu testen.

Die Erfindung wird ausgehend von dem im Oberbegriff von Pa­ tentanspruch 1 angegebenen Merkmalen durch die im Kennzeichen beanspruchten Merkmale gelöst.

Vorteilhaft an der Erfindung ist insbesondere das Verwenden eines Testprogramms, mit dessen Hilfe alle im Rahmen vorde­ finierter Regeln möglichen Szenarien ermittelt werden. Damit ist der Vorteil verbunden, daß auch extrem seltene, vom Entwickler nicht vorhersehbare Kombinationen von Zuständen und Anreizen getestet und auf mögliches Fehlverhalten im Sy­ stem hin überprüft werden können. Damit ist insbesondere der Vorteil verbunden, daß neu in eine Kommunikationsanlage ein­ zubringende Systemkomponenten bezüglich logischen Fehlern ausführlichen Tests unterzogen werden, wodurch eine fehler­ freie Arbeitsweise sichergestellt ist. Weiterhin ist damit ist der Vorteil verbunden, daß bestimmte beispielsweise nicht sinnvolle Zustandskombinationen ausgeschlossen werden. Außer­ dem läßt sich damit die gewaltige Vielfalt an Testszenarien auf eine vernünftig handhabbare Menge an Daten reduzieren. Damit wird eine Kombination aller Anreize mit allen zugelas­ senen Zuständen durchgeführt.

Vorteilhafte Weiterbildungen der Erfindung sind in den Unter­ ansprüchen angegeben.

Gemäß Anspruch 2 ist vorgesehen, daß das zu testende System ein Softwareprogramm ist. Damit ist der Vorteil verbunden, daß auch Programme nach der Methode der Finite States Mach­ ines als Systeme behandelbar sind und somit unter Verwendung dieser Methode effizient getestet werden können.

Gemäß Anspruch 3 ist vorgesehen, daß der Code des Software­ programmes beim Testvorgang mitbenutzt wird. Damit ist der Vorteil verbunden, daß beim Testlauf reale Bedingungen gege­ ben sind.

Gemäß Anspruch 4 ist vorgesehen, daß vom zu testenden Pro­ gramm als Testergebnis Ausgangszustände und Folgeaktionen zurückgegeben werden. Damit ist der Vorteil verbunden, daß aufgrund der derart erhaltenen Daten unmittelbar Rückschlüsse auf die Korrektheit des Codes gezogen werden können.

Gemäß Anspruch 5 ist vorgesehen, daß die erhaltenen Tester­ gebnisse in wenigstens einer Tabelle abgelegt und per Daten­ bank ausgewertet werden. Damit ist der Vorteil verbunden, daß viele Testergebnisse gleichzeitig ausgewertet werden, wodurch sich eine enorme Zeitersparnis ergibt.

Die Erfindung wird im folgenden anhand eines Ausführungsbei­ spiels näher erläutert.

Es zeigen:

Fig. 1 ein Blockschaltbild, in dem das Zusammenwirken aller Programmkomponenten aufgezeigt ist,

Fig. 2 eine Tabelle T₁, in der die jeweiligen Zustände und Events aufgelistet sind,

Fig. 3 eine weitere Tabelle T₂, in der die Testergebnisse aller Tests in ihrer Gesamtheit festgelegt sind.

In Fig. 1 ist die Erfindung anhand eines Blockdiagrammes aufgezeigt. Demgemäß ist ein Testprogramm TEST vorgesehen, das in Wirkverbindung mit dem zu testenden Programm PROG steht. Das zu testende Programm PROG wird von seiner Struktur her aus einzelnen, logisch abgeschlossenen Subsystemen gebildet, die durch einzelne Prozeduren oder einen Komplex von Prozeduren beschrieben werden. Die Prozeduren können ineinander ge­ schachtelt sein. Gemäß vorliegendem Ausführungsbeispiel sind dies die in Fig. 1 aufgezeigten Prozeduren P₁...P_k.

Die Prozeduren können einzeln sowie in ihrem Zusammenwirken untereinander getestet werden. Ersteres ist gemäß Fig. 1 durch die Prozeduren P₁, P_k angedeutet, die lediglich im einzelnen getestet werden. Aufgrund der Schachtelung der Pro­ zeduren können jedoch in einer Prozedur mehrere weitere Prozeduren aufgerufen werden. Dies ist in Fig. 1 durch den gestrichelt dargestellten Pfeil dargestellt. In gleicher Weise ist das Zusammenwirken der Prozedur P₂ mit der Prozedur P₃ zu verstehen, die ebenso ein logisches Subsystem bilden sollen.

Das Testprogramm TEST übergibt dem Programm PROG zur Durch­ führung des Testvorganges vordefinierte Parameter. Dazu ge­ hören insbesondere Zustandswerte und Anreize, auf die später noch detaillierter eingegangen wird. Diese Parameter werden damit dem Code der zu testenden Prozedur zur Verfügung ge­ stellt und im folgenden mit dem Ablauf der Prozedur abgear­ beitet. Das Ergebnis wird wieder dem Testprogramm TEST über­ geben. Vom Testprogramm TEST werden nun die erhaltenen Werte in noch näher zu beschreibende Tabellen T₁, T₂ gemäß Fig. 2, 3 eingearbeitet, die als Basis für die in einer Datenbank DB abschließend zu erfolgende Auswertungen dienen.

Erfindungsgemäß wird das Programm PROG als System im Sinne der Theorie der "Finite State Machines" beschrieben. Dies be­ deutet, daß jedes technische System - und somit auch jedes Programm, als ein solches aufgefaßt werden kann - durch Defi­ nition seiner Zustände sowie von Anreizen, die auf diese Zu­ stände einwirken - beschreibbar ist. Die Anreize werden auch als Events bezeichnet. Aufgrund dieser Events erfolgen nun Zustandsübergänge von einem (Anfangs/Eingangs) Zustand in einen weiteren (End/Ausgangs) Zustand.

Die das zu testende Programm beschreibenden Zustände sind da­ bei aus einer Mehrzahl von Zustandsvariablen ausgebildet. Sie können demgemäß als Vektoren oder Tupel aufgefaßt werden. Den Zustandsvariablen können nun eine weitere Mehrzahl von Zu­ standswerten zugewiesen sein.

Zu Beginn des eigentlichen Testvorgangs wird nun ein Abbild des zu testenden Programmes PROG im Testprogramm TEST er­ stellt. Gemäß der Theorie der Finite State Machines erfolgt dies, indem alle möglichen Zustände, die das Programm PROG einnehmen kann, definiert werden. Insbesondere muß hier eine Beschreibung der Schnittstelle zum Testprogramm TEST defi­ niert werden. Dies erfolgt, indem die die Zustände beschreib­ enden Zustandsvariablen mit der Menge der Zustandswerte defi­ niert werden. Zustandsvariablen und Zustandswerte werden in einer Tabelle T₁ abgelegt. Die entsprechenden Verhältnisse sind in Fig. 2 aufgezeigt.

Im weiteren wird nun dem Testprogramm TEST die Ausschlußregel für alle nicht erlaubten Zustandskombinationen der eingege­ benen Zustandswerte eingegeben. Demgemäß wird im Sinne einer Ausschlußregel definiert, welche der Zustandskombinationen zugelassen werden, und welche nicht. Die entsprechenden Er­ gebnisse sind tabellarisch ebenfalls in Fig. 2 aufgezeigt. In Spalte 1 der Tabelle T₁ sind somit alle Zustandsvariablen abgelegt, die im Programm PROG eingenommen werden können. In Spalte 2 werden die Zustandswerte abgelegt, die die Zustands­ variablen einnehmen können, und in Spalte 3 alle die Zu­ standskombinationen, die gemäß der Ausschlußregel zugelassen werden. Spalte 3 wird direkt aus Spalte 2 unter Benutzung der Ausschlußregel vom Testprogramm TEST berechnet.

Beispielhaft sei nun angenommen, daß das zu testende Programm PROG lediglich durch die 2 Zustandsvariablen A, B vollständig beschrieben wird. Diese sollen die Zustandswerte (a₁, a₂) so­ wie (b₁, b₂, b₃, b₄) einnehmen. Die Zustandsvariablen A, B sind in Spalte 1 der Tabelle T₁ aufgezeigt, während in Spalte 2 die zugehörigen Zustandswerte abgelegt sind. Vom Testpro­ gramm TEST werden nun alle möglichen Zustandskombinationen in ihrer Gesamtheit berechnet und unter Anwendung der defi­ nierten Ausschlußregel lediglich die zugelassenen Zustands­ kombinationen in Spalte 3 eingetragen.

Beispielhaft sollen die Zustandskombinationen (a₁, b₁), (a₁, b₂), (a₁, b₄), (a₂, b₁) und (a₂, b₄) in Spalte 3 gemäß der Ausschlußregel als zugelassene Zustandskombinationen einge­ tragen werden, während die Zustandskombinationen (a₁, b₃), (a₂, b₂) sowie (a₂, b₃) vom Testprogramm TEST zwar errechnet werden, gemäß Ausschlußregel jedoch nicht erlaubt sein sollen. Welche Zustandskombinationen als erlaubt anzusehen sind und welche nicht, hängt von der Funktion des zu testenden Pro­ grammes ab. Sinnvollerweise können nur Zustände akzeptiert werden, die als verträglich mit der Funktionalität anzusehen sind. Diese sollen nun als Basis für die weiteren Testvor­ gänge dienen.

Im weiteren sind nun ebenfalls alle Events oder Anreize zu definieren, die auf die Zustände oder erlaubten Zustandskom­ binationen des Programmes PROG einwirken und Zustandsüber­ gänge in weitere Zustände bewirken. Beispielhaft sollen dies die Anreize E₁, E₂ sein. Damit ist eine vollständige Beschrei­ bung der Schnittstellen des zu testenden Programmes PROG er­ reicht, die im Testprogramm TEST abgelegt ist. Die entsprech­ enden Verhältnisse sind in Fig. 3 aufgezeigt. Die Anreize E₁, E₂ werden in Spalte 2 der dort aufgezeigten Tabelle T₂ eingetragen, während in Spalte 1 die zugelassenen Zustands­ kombinationen gemäß Spalte 3 von Tabelle T₁ abgelegt sind.

Im folgenden wird nun der eigentliche Testvorgang durchge­ führt. Hierbei werden nun alle Anreize gemäß Spalte 2 mit den zugelassenen Zustandskombinationen gemäß Spalte 1 kombiniert. Dies bedeutet, daß der Anreiz E₁ mit den Zustandskombinationen (a₁, b₁), (a₁, b₂), (a₁, b₄), (a₂, b₁) sowie (a₂, b₄) kombiniert wird. In gleicher Weise wird mit dem Anreiz E₂ verfahren, der ebenfalls mit diesen Zustandskombinationen zu kombinieren ist.

Das Ergebnis dieser Kombinationen wird als Eingangsgröße, die eingangs als vordefinierte Parameter bezeichnet wurden, für das zu testende Programm PROG genommen. Hier wird mit den derart definierten Eingangsgrößen das Programm PROG bzw. die betreffende Prozedur zum Ablauf gebracht. Als Ergebnis wird vom zu testenden Programm PROG bzw. der betreffenden Prozedur ein bestimmter Ausgangszustand dem Testprogramm TEST zusammen mit einer Folgeaktion F₁..F_n übergeben. Dabei ist unter einer Folgeaktion die Aktion zu verstehen, die sich an den erreich­ ten Ausgangszustand unmittelbar anschließt. Die Folgeaktion ist im Code des zu testenden Programmes PROG enthalten und weist die "Dimension" eines Anreizes auf. Die Folgeaktionen können mehrfach auftreten. Dies bedeutet, daß im Anschluß an einen Ausgangszustand mehrere Folgeaktionen durchführbar sind. Der besseren Verständlichkeit halber sind in Spalte 4 von Fig. 3 lediglich eine einzige Folgeaktion pro Zeile auf­ gezeigt.

Die Ergebnisse werden vom Testprogramm TEST in Spalte 3 und 4 der Tabelle T₂ abgelegt. Gemäß vorliegendem Ausführungsbei­ spiel soll der Eingangszustandswert (a₁, b₁) mit dem Anreiz E₁ kombiniert werden und als Eingangsgröße dem zu testenden Programm PROG zur Verfügung gestellt werden. Als Ausgangszu­ standswert wird vom Testprogramm TEST der Zustand (a₂, b₁) in Spalte 3 und die Folgeaktion F₁ in Spalte 4 eingetragen. Als Testergebnis wird somit eine komplette Tabelle T₂ erstellt.

Um die derart erhaltenen Testergebnisse detaillierter auswer­ ten zu können, wird die Tabelle T₂ in eine Datenbank DB gela­ den. Dort werden nun eine ausführliche Analyse der erhaltenen Testergebnisse vorgenommen. Die Analyse läuft entweder auto­ matisiert oder wahlweise durch Vorgabe gezielter Auswerte­ strategien ab.

Beispielsweise werden die in der Spalte 3 von Tabelle T₂ er­ haltenen Ausgangszustände auf ihre Korrektheit gemäß Spalte 3 von Tabelle T₁ hin überprüft. Werden Zustandskombinationen ermittelt, die gemäß der Spalte 3 von Tabelle T₁ nicht zuge­ lassen sind, so werden die betreffenden Zustände in der Ta­ belle T₂ markiert. Dies gibt einen Hinweis darauf, daß die Codierung des Programmes PROG an dieser Stelle fehlerhaft ist. Die derart gestaltete Analyse läuft automatisiert ab.

Im weiteren wird ebenfalls automatisiert überprüft, ob aus­ gehend von irgendeinem Zustand durch eine beliebige Anzahl von Anreizen jeder zugelassene Zustand erreichbar ist. Ist dies der Fall, kann von einer korrekten Codierung ausgegangen werden, andernfalls erfolgt auch hier eine Markierung der be­ treffenden Datensätze in der Tabelle T₂.

Letztendlich können vom Bediener je nach Teststrategie alle denkbaren Fehlerszenarien vorgebenen werden. Dies ist unter Benutzung der in der Datenbank DB vorgesehenen Befehle mög­ lich. Anhand der erhaltenen Ergebnisse können dann Rück­ schlüsse auf die Korrektheit des Codes gezogen werden. Nach Maßgabe der Ergebnisse kann dann erneut ein Testlauf gestar­ tet werden, wobei der während des zuvor erfolgten Testlaufes als fehlerhaft ermittelte Code in entsprechender Weise korri­ giert worden ist.

Claims (5)

1. Verfahren zum automatischen Testen von komplexen Systemen, die über eine Mehrzahl von Zuständen sowie auf diese ein­ wirkende Anreize (E₁...E_m) und über Folgeaktionen (F₁...F_n) beschreibbar sind, mittels eines Testprogrammes (TEST), dadurch gekennzeichnet,
daß in einem ersten Testlauf alle zugelassenen Zustandskombi­ nationen des zu testenden Systems vom Testprogramm (TEST) ermittelt werden, wobei ein Abbild des zu testenden Systems anhand aller im System möglichen Zustände und/oder Anreize nach Maßgabe der Theorie der Finite State Machines verwendet wird, und vorgegebene Kriterien für sinnvolle Zustands/An­ reizkombinationen ausgewertet werden, und
daß in einem zweiten Testlauf die derart ermittelten zugelas­ senen sinnvollen Zustands/Anreizkombinationen auf das zu testende System angewendet und dessen Reaktionen gespeichert und automatisch ausgewertet werden.

2. Verfahren nach Anspruch 1, dadurch gekennzeichnet, daß das zu testende System ein Softwareprogramm (PROG) ist.

3. Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, daß der Code des Softwareprogrammes (PROG) beim Testvorgang mitbenutzt wird.

4. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, daß vom zu testenden Programm (PROG) als Testergebnis Aus­ gangszustände und Folgeaktionen (F₁...F_n) zurückgegeben wer­ den.

5. Verfahren nach einem der vorstehenden Ansprüche, dadurch gekennzeichnet, daß die erhaltenen Testergebnisse in wenigstens einer Tabelle (T₂) abgelegt und per Datenbank (DB) ausgewertet werden.