BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

Transkript

1 CO-MAT-TECH October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand at the Department of Information Technology and Automation, Slovak University of Technology, Faculty of Materials Science and Technology, Paulinska 16, Trnava, Slovakia, 1 Einführung Eine der wichtigsten Aufgaben des Testens ist zu prüfen, ob das zu testende Softwaresystem die in ihrer Spezifikation definierten Anwenderanforderungen erfüllt. Einzelne Anforderungen sind durch implementierte Aktionen des Softwaresystems realisiert. Die Reihenfolge, in der diese Aktionen ausgeführt werden, kann immer unterschiedlich sein. Dabei kann jede Aktion den Zustand des zu testenden Softwaresystems ändern. Diese Tatsache spielt vor allem bei dem Testen der objektorientierten Software eine sehr wichtige Rolle. Der globale Zustand ergibt sich hier von Werten einzelner Attribute aller Klassen des Softwaresystems. Deshalb wird jede Aktion, die den Wert mindestens eines Attributes ändert, gleichzeitig auch den Zustand des ganzen Softwaresystems beeinflussen. Bezüglich der Variabilität der Reihenfolge der ausgeführten Aktionen ist es sehr wahrscheinlich, dass jede Aktion in mehreren unterschiedlichen Zuständen des Softwaresystems ausgeführt werden kann. Aus der Sicht des Softwaretestens ist dieser Fakt sehr wichtig. Ein einmaliges Testen jeder Anwenderanforderung, bzw. der Aktion die diese Anforderung realisiert, nur in einem Zustand der zu testenden Software ist nicht ausreichend. Jede Aktion muss in allen Ausgangzuständen getestet werden, in denen man sie auch bei einem realen Einsatz der zu testenden Software ausführen kann. Gleichzeitig gilt, dass jeder Ausgangzustand durch mehrere Wege erreichbar ist. Diese Wege sind durch die Reihenfolge der ausgeführten Aktionen bestimmt. Ich werde solche Wege als Pfade bezeichnen. Deshalb muss jede Aktion in jedem relevanten Ausgangzustand getestet werden und gleichzeitig muss jeder Ausgangszustand durch alle möglichen Pfade erreicht werden. Nur dann wird die zu testende Software ausreichend bezüglich ihres Zustands getestet.

2 Aufgrund dieser Tatsachen ist es möglich, die Anzahl der Testszenarios festzulegen, die für das Testen einer Anwenderanforderung notwendig sind. Die Menge S = {s 1,, s m } ist eine Menge von möglichen Ausgangzuständen, in denen man eine Anwenderanforderung ausüben kann. Die Menge P i = {p i1,, p in } ist eine Menge mit möglichen Pfaden, durch die ein Zustand s i S erreichbar ist. Dann ist die Anzahl der notwendigen Testszenarien für das Testen einer Anwenderanforderung: n = wobei: n... Anzahl von notwendigen Testszenarien m... Anzahl von möglichen Ausgangszuständen, in denen die m i= 1 p i [1.1] Anwenderanforderung durchführbar ist p i... Anzahl von Pfaden, durch die man einen Ausgangszustand s i S erreichen kann. Für das Testen jeder Anwenderanforderung muss eine Menge von Testszenarien TS = {ts 1,, ts n } verwendet werden. Jedes Testszenario ts j TS stellt dabei eine Kombination eines Elementes aus der Menge S und eines Elementes aus der Menge P i dar. In diesem Beitrag wird eine Lösung für das Erreichen von Ausgangszuständen während des Testens präsentiert. Diese Lösung geht bei dem Identifizieren der Ausgangszustände und den Pfaden zu ihnen von der Spezifikation der zu testenden Software aus, die mit Hilfe der UML [10] hergestellt wurde. Für diesen Zweck wird eine Kombination von Sequenzdiagrammen und Zustandsdiagrammen genutzt. Dabei gehe ich davon aus, dass die Sequenzdiagramme die beste Grundlage für das Generieren von Testszenarien aus einer UML Spezifikation darstellen. Diese Überzeugung basiert sowohl auf der Empfehlung der Autoren der UML [7, 8], als auch auf existierenden Projekten in diesem Bereich [2, 5]. 2 Entwurf der Lösung Die Menge SD = {sd 1,, sd n } ist eine Menge von Sequenzdiagrammen, durch die das Verhalten der zu testenden Software modelliert ist. Jedes Sequenzdiagramm sd i SD beschreibt dabei das Verhalten beim Durchführen genau einer Anwenderanforderung. In jedem Diagram sd i SD ist eine Menge O = {o 1,, o n } mit Objekten dargestellt, die an dem Ablauf dieses Verhaltens beteiligt sind. Aus der Sicht des Generierens von Testszenarien aufgrund eines Sequenzdiagramms sd i SD ist der globale Zustand des zu testenden Softwaresystems von Zuständen aller Objekte aus der Menge O abhängig. Der Zustand von Objekten, die in dem Diagram sd i SD nicht dargestellt sind und dadurch keinen Einfluss auf den Ablauf des modellierten Verhaltens haben ist hierbei irrelevant. Aus diesem Grund werde ich unter dem Ausgangszustand des zu testenden Softwaresystems, in dem sich die im Sequenzdiagram sd i modellierte Aktion testen lässt, eine Kombination von Zuständen aller in diesem Diagram dargestellter Objekte verstehen. Deshalb ist es wichtig für jedes Objekt o i O eine Menge mit möglichen Zuständen zu finden, in denen dieses Objekt seine Rolle in dem Sequenzdiagram sd i einnehmen kann. Diese Menge nenne ich eine Menge

3 von möglichen Einleitungszuständen des Objektes o i bezüglich seines Auftretens im Sequenzdiagramm sd i und wird als V i = {v i1,, v in } bezeichnet. Die Menge V i enthält mindestens ein Element. In der Praxis kann aber diese Menge mehrere Elemente enthalten. Damit man bei Verwendung der in diesem Beitrag präsentierten Lösung alle möglichen Einleitungszustände eines Objektes bezüglich seines Auftretens im einem Sequenzdiagramm und alle Pfade zu jedem dieser Zustände identifizieren kann, muss das zu testende Softwaresystem folgende Bedingungen der Testbarkeit erfüllen: 1. Die zu testende Funktionalität ist in der UML-Spezifikation durch eine Menge von Sequenzdiagrammen modelliert. In jedem Sequenzdiagramm sd i ist eine Menge von Objekten O = {o 1,, o n } dargestellt, die an der Durchführung der modellierten Funktionalität beteiligt sind. Zu jedem Objekt o i O ist eine geordnete Menge von Eingangsbotschaften U = {u 1,, u n } definiert, die das Objekt o i bei dieser Durchführung empfängt. Als Reaktion auf den Empfang einer Eingangsbotschaft u k U sendet das Objekt o i eine geordnete Menge von Ausgangsbotschaften Y k = {y k1,, y kn }. Empfänger einer Ausgangsbotschaft y ki kann entweder das Objekt o i, oder ein anderes Objekt sein. Die Menge Y k kann auch leer sein. 2. Jedem Objekt o i O, das im Sequenzdiagramm sd i dargestellt ist, muss eine Klasse zugeordnet sein. Jede Klasse muss durch genau ein Zustandsdiagramm beschrieben sein. In dem Zustandsdiagramm ist eine Menge S = {s 1,, s m } mit Zuständen enthalten, in denen sich das Objekt o i befinden kann. Außerdem existiert eine Menge T mit den gültigen Übergängen. Jeder Übergang t m T ist dabei durch die Variable t m (s i, s j, u k, Y k ) definiert, wobei die Eingangsbotschaft u k die Rolle des den Übergang t m auslösenden Ereignisses einnimmt. Die Menge Y k = {y k1,, y kn } enthält eine Reihe von Ausgangsbotschaften. Ein Übergang t m zwischen zwei Zuständen s i und s j stellt eine Reaktion des Objektes o i auf ein bestimmtes Ereignis dar. Das Auftreten eines Ereignisses wird dem Objekt o i durch die Eingangsbotschaft u k signalisiert. Neben dem Zustandsübergang t m kann ein Ereignis auch eine Folge von Aktionen auslösen. Diese Folge von Aktionen wird durch die Menge Y k der Ausgangsbotschaften repräsentiert. Jede Ausgangsbotschaft y ki aus der Menge Y k wird entweder an das Objekt o i oder an ein anderes Objekt gesendet. Zustandsübergänge mit s i = s j sind zulässig. Wenn die oben genannten Bedingungen erfüllt sind, kann man den Einleitungszustand des Objektes o i O und zusätzlich einen Pfad zu diesem Zustand identifizieren. Für diesen Zweck wird das Verhalten des Objektes im Sequenz- und im Zustandsdiagramm verglichen. Das geschieht durch Vergleich von Sequenzen der Eingangs- und Ausgangsbotschaften des Objektes o i im Sequenzdiagramm sd i auf einer Seite und im Zustandsdiagramm der Klasse des Objektes o i auf der anderen Seite. Dabei muss gelten, dass man einen Zustand s i genau dann als Einleitungszustand des Objektes o i bezeichnen kann, wenn das Objekt o i im Zustand s i auf die Botschaft u k U reagieren kann. Die Botschaft u k ist dabei eine Eingangsbotschaft des Objektes o i im Sequenzdiagramm sd i. Außerdem muss als Reaktion auf den Empfang der Botschaft u k zusammen mit einem Zustandsübergang auch eine Reihe von Aktionen generiert

4 werden. Diese Aktionen repräsentieren die Menge Yk = {yk1,, ykn} von Ausgangsbotschaften, die das Objekt oi nach dem Empfang von uk im Sequenzdiagramm sdi entsendet. So entsteht eine Menge Vi = {vi1,, vin}. Die Menge Vi stellt eine Menge von möglichen Einleitungszuständen des Objektes oi bezüglich seines Auftretens im Sequenzdiagramm sdi dar. In dem Bild 1a ist das Sequenzdiagram sd1 abgebildet. In diesem Diagram ist eine Menge von Objekten O = {o1, o2, o3, o4} dargestellt. Für das Identifizieren des Einleitungszustandes des Objektes o1 bezüglich seines Auftretens im Sequenzdiagramm sd1 muss man das Zustandsdiagram dieses Objektes benutzten. In dem Bild 1b ist ein Ausschnitt aus diesem Zustandsdiagram abgebildet. In dem Sequenzdiagram sd1 empfängt das Objekt o1 eine Eingangsbotschaft u1. Als Reaktion auf den Empfang werden zwei Botschaften generiert. Die Botschaft u2 wird an das Objekt o2 und die Botschaft u3 an das Objekt o3 entsendet. Aus der Sicht des Objektes o1 stellen die Botschaften o2.u2 und o3.u3 eine Menge von Ausgangsbotschaften dar. Wie sich aus dem Bild 1b ergibt, kann das Objekt o1 auf den Empfang der Botschaft u1 genau dann reagieren, wenn es sich entweder im Zustand s1 oder im Zustand s2 befindet. Diese zwei Zustände sind deshalb Kandidaten für den gesuchten Einleitungszustand. Wenn sich das Objekt o1 im Zustand s2 befindet, wird nach dem Empfang der Botschaft u1 ein Übergang vom Zustand s2 in den Zustand s3 realisiert und gleichzeitig wird die Botschaft u2 an das Objekt o2 entsendet. Damit ist die Menge von Ausgangszuständen wie sie im Sequenzdiagramm sd1 dargestellt sind nicht komplett. Die Ausgangsbotschaft o3.u3 fehlt. Wenn sich allerdings das Objekt o1 im Zustand s1 befindet, wird nach dem Empfang der Botschaft u1 ein Übergang in den Zustand s2 realisiert und gleichzeitig wird die Botschaft u2 an das Objekt o2 und die Botschaft u3 an das Objekt o3 entsendet. Damit stimmt im Zustand s1 sowohl die Menge der Eingangsbotschaften, als auch die Menge der Ausgangsbotschaft wie sie in dem Sequenzdiagram sd1 für das Auftreten des Objektes o1 modelliert sind. Deshalb muss sich das Objekt o1 vor dem Testen des in Sequenzdiagram sd1 definierten Verhaltens immer in seinem Zustand s1 befinden.

5 Nach dem Identifizieren von Einleitungszustand des Objektes o i O muss das Objekt unmittelbar vor dem Testen in diesen Zustand eingeleitet werden. Das passiert durch eine Sequenz von Eingangsbotschaften, die an das Objekt o i entsendet werden. Diese Sequenz verursacht eine Reihe von Zustandsübergängen, die das Objekt o i von seinem Initialzustand s 0 zu dem Einleitungszustand v ij bringen. Diese Reihe von Zustandsübergängen heißt Pfad. Die Sequenz von Eingangsbotschaften, die den Ablauf des Pfades verursachen, wird von dem Zustandsdiagramm des Objektes o i abgelesen. Jede Eingangsbotschaft wird dem Objekt durch den Aufruf einer der Methoden seiner Klasse geliefert. 3 Auswahl von möglichen Einleitungszuständen und Pfaden In der Praxis kann es zu einer Situation kommen, in der ein Objekt o i in mehreren seiner Zustände eine Rolle bei dem Ausführen des in Sequenzdiagram sd i definierten Verhaltens einnehmen kann. In diesem Fall enthält die Menge V i = {v i1,, v in } der möglichen Einleitungszustände des Objektes o i bezüglich seines Auftretens im Sequenzdiagramm sd i mehr als ein Element. Ähnlich kann zu jedem Zustand v ij V i mehr als ein Pfad aus dem Initialzustand s 0 des Objektes o i führen. Jeder Pfad p i = { t 1 (s 0, s 1, u k, Y k ), t 2 (s 1, s j, u m, Y m ),..., t w (s i-1, s i, u i, Y i )} bietet dabei eine Grundlage für die sogenannte vortestierende Sequenz, die das Objekt o i in einen Einleitungszustand bringt. Die Anzahl solcher Sequenzen, durch die man alle möglichen Einleitungszustände des Objektes o i erreichen kann, ist: o = m w k k = 1 [3.1] wobei: o... Anzahl der Sequenzen m... Anzahl von Einleitungszuständen des Objektes o i w k... Anzahl von Pfaden zu dem Einleitungszustand v ik des Objektes o i Ich gehe davon aus, dass der Zustand des zu testenden Softwaresystems durch eine Kombination von Zuständen aller beteiligten Objekte bestimmt wird, die sich in dem grundlegenden Sequenzdiagram befinden. Wenn für jedes Paar von einem Ausgangszustand und einem Pfad zu ihm, ein Testszenario ts j TS generiert wird, ist die Anzahl von notwendigen Testszenarien, durch die das in dem Sequenzdiagram modellierte Verhalten getestet werden muss: t = n k = 1 o k [3.2] wobei: t... Anzahl von notwendigen Testszenarien n... Anzahl von im Sequenzdiagram dargestellten Objekten o k Anzahl von Sequenzen, durch die man ein Objekt o k in alle seine Einleitungszustände bringen kann [3.1]

6 Im Bild 2a ist das Zustandsdiagramm des Objektes o2 dargestellt. Dieses Objekt ist an dem Ablauf des Verhaltens beteiligt, das in dem Sequenzdiagram sd1 (Bild 1a) modelliert wird. Vor der Analyse des Zustandsdiagramms wird dieses in eine Baumstruktur [4] umgewandelt (Bild 2b), in der alle Übergänge zwischen zwei benachbarten Zuständen dargestellt ist. Für diese Struktur ist wichtig, von welchen Zuständen ein konkreter Zustand erreichbar ist und zu welchen Zuständen ein Übergang von diesem Zustand führen kann. Damit ist die Analyse von direkten Pfaden vom Zustand si zum Zustand sj ohne zyklische und sich wiederholende Pfade möglich. Aus diesem Diagramm hat sich ergeben, dass sowohl der Zustand s3 als auch der Zustand s4 als Einleitungszustand des Objektes o2 bezüglich seines Auftretens im Sequenzdiagramm sd1 (Bild 1a) bezeichnet werden kann. In diesen beiden Zuständen reagiert das Objekt o2 auf den Empfang der Eingangsbotschaft u2 mit einem Zustandsübergang, wobei die Menge der Ausgangsbotschaften leer ist, wie es im Sequenzdiagramm sd1 definiert ist. In der Baumstruktur (Bild 1b) kann man vier Pfade aus dem Initialzustand des Objektes o2 zu seinem Zustand s3 identifizieren: p1 = {t1 (s0, s1, u 0,θ ), t 2 (s1, s3, u1,θ )} p2 = {t1 (s0, s1, u0,θ ), t2 (s1, s3, u1,θ ), t3 (s3, s3, u2,θ )} p3 = {t1 (s0, s1, u0,θ ), t2 (s1, s3, u4,θ )} p4 = {t1 (s0, s1, u0,θ ), t2 (s1, s2, u3,θ ), t3 (s2, s3, u1,θ )} Ähnlich gibt es drei Pfade aus dem Initialzustand des Objektes o2 zu seinem Zustand s4: p1 = {t1 (s0, s1, u0,θ ), t2 (s1, s2, u3,θ ), t3 (s2, s4, u3,θ )} p2 = {t1 (s0, s1, u0,θ ), t2 (s1, s3, u1,θ ), t3 (s3, s4, u4,θ )} p3 = {t1 (s0, s1, u0,θ ), t2 (s1, s3, u1,θ ), t3 (s3, s5, u3,θ ), t3 (s5, s4, u4,θ )}

7 Es ist nicht immer rentabel, alle existierte Ausgangszustände und Pfade zu ihnen bei dem Generieren von den Testszenarien zu verwenden. Im nächsten Kapitel werden deshalb Testkriterien definiert, die sich mit der Auswahl von konkreten Zuständen und konkreten Pfaden zu ihnen beschäftigen. 4 Testkriterien Bei dem Verwenden aller Testszenarien, wie es in der Formel 1.1. definiert ist, wird eine Anwenderanforderung in allen möglichen Ausgangszuständen des zu testenden Softwaresystems getestet. Zusätzlich werden alle Ausgangszustände durch alle möglichen Pfade erreicht. In der Praxis ist allerdings solch ein komplexes Testen nicht immer nötig. Bezüglich der Projektkosten ist es manchmal während des Projektes ausreichend, wenn die Software nur in manchen Ausgangszuständen, bzw. beim Verwenden nur weniger Pfade, getestet wird. Für diesen Zweck habe ich Testkriterien entworfen, die genau auf Ausgangszuständen und Pfaden zu ihnen basieren. Jedes Kriterium definiert eine eigene Art von Überdeckung. Einzelne Überdeckungen beschreiben Einleitungszustände eines Objektes bezüglich seines Auftretens in einem Sequenzdiagramm sd i, in denen das Objekt getestet werden muss. Das Sequenzdiagramm sd i dient dabei als Grundlage für das Generieren von Testszenarien. Außer Einleitungszuständen werden auch alle Pfade zu ihnen definiert, durch die man während des Testens einzelne Einleitungszustände erreichen muss. Es handelt sich um folgende Testkriterien: 1S1P (One State - One Path). Bei diesem Testkriterium wird jedes Objekt o i O in genau einen Einleitungszustand v ij V i eingeleitet. Es wird genau der Zustand ausgewählt, der von dem Initialzustand s 0 mit der niedrigsten Zahl von Übergängen erreichbar ist. Das Objekt o i wird in den Zustand v ij nur durch den kürzesten Pfad eingeleitet. 1SAP (One State - All Pathes). Bei diesem Testkriterium wird jedes Objekt o i O auch in genau einen Einleitungszustand v ij V i eingeleitet. Gibt es vom Initialzustand s 0 zu dem Einleitungszustand v ij mehrere Pfade, wird für jeden Pfad ein neues zusätzliches Testszenario generiert. AS1P (All States - One Path). Bei diesem Testkriterium wird jedes Objekt o i O in jeden Einleitungszustand v ij V i eingeleitet. Für jeden Zustand v ij wird ein Testszenario generiert. Das Objekt o i wird nur den kürzesten Pfad in den Zustand v ij eingeleitet. ASAP (All States - All Pathes). Bei diesem Testkriterium wird jedes Objekt o i O in jeden Einleitungszustand v ij V i eingeleitet. Gibt es vom Initialzustand s 0 zu dem Einleitungszustand v ij mehrere Pfade, wird für Pfad ein neues Testszenario generiert. Damit die größtmögliche Kombination von Einleitungszuständen und Pfaden zu ihnen erreicht. Die Verwendung von jedem dieser Testkriterien ermöglicht das Generieren von Testmengen mit unterschiedlicher Anzahl von Testszenarien. Jede Testmenge erreicht während des Testens auch eine andere Überdeckung der zu testenden Funktionalität. So kann man das Generieren von Testszenarien bezüglich der gewünschten Überdeckung steuern.

8 5 Schlusswort Dieser Beitrag hat gezeigt, wie man einen korrekten Ausgangszustand der objektorientierten Software vor ihrem Testen erreichen kann. Als Grundlage wurde eine UML Spezifikation des zu testenden Softwaresystems benutzt. Die präsentierte Methode verwendet für das Identifizieren und das Erreichen von Ausgangszuständen Sequenzdiagramme. Diese Art von UML Diagrammen ist dafür am besten geeignet. Das beweisen sowohl die Empfehlungen der Autoren der UML, als auch die existierenden Projekte in diesem Bereich. Als ein zusätzliches Diagramm wurde dabei das Zustandsdiagramm verwendet. Zusätzlich zu dem Verfahren wurden hierbei auch Testkriterien definiert, die man zum Steuern des Generierens von Testszenarien bezüglich der Projektkosten benutzen kann. Durch Verwendung dieser Testkriterien können sowohl kleinere Testmengen von Testszenarien generiert werden, die vor allem in der Anfangsphase des Softwareprojektes ausreichend sind, als auch große Testmengen, die das zu testende Softwaresystem in allen relevanten Ausgangszuständen testet, die zusätzlich durch alle möglichen Pfade erreicht wurden. Das komplexe Testen wird vor allem vor der Softwareübergabe an den Kunden gefordert. Referenzen [1] Andrews, A.; Franc, R. B.; Ghosh, S.; Craig, G.: Test Adequacy Criteria for UML Design Models, Journal of Software Testing, Verification and Reliability, 13(2)/2003, S [2] Basanieri, F.; Bertolino, A.: APractical Approach to UML-based Derivation of Integration Tests. 4th International Software Quality Week Europe, 2000, paper 3T. [3] Beizer, B.: Software Testing Techniques. Van Nostrand Reinhold, [4] Binder, R. V.: Testing Object-Oriented Systems Models, Patterns, and Tools. AddisonWesley, [5] Briand, L.; Labiche, Y.: A UML-based approach to system testing, 4th International Conference on the UML. 2001, S [6] Fraikin, F.; Leonhardt, T.: SeDiTeC Testing Based On Sequence Diagrams, The 17 th IEEE International Conference on Automated Software Engineering. 2002, S [7] Jacobson, I.; Christerson, M.; Jonsson, P.; Övergaard, G.: Object-Oriented Software Engineering, Addison-Wesley, 1994 [8] Jacobson, I.; Booch, G.; Rumbaugh, J.: The Unified Software Development Process, Addison-Wesley, 1998 [9] Offutt, J.; Abdurazik, A.: Generating tests from UML specifications, 2nd International Conference on the UML. 1999, S [10] The Object Management Group: OMG Unified Modelling Language Specification, Version 1.3. OMG, [11] Zhu, H.; Hall, P.; May, J.: Software Unit Test Coverage and Adequacy. ACM Computing Surveys, 29(4)/1999, S