Das Entwicklertestkonzept EnTek

Transkript

1 Das Entwicklertestkonzept EnTek Ausarbeitung Aktuelle Themen der Informatik Prof. Dr. Friedbert Kaspar HFU - Hochschule Furtwangen University Robert-Gerwig-Platz Furtwangen Bernd Häbe Fakultät Computer Networking (CN 7) Matrikel Nr bernd.haebe@fh-furtwangen.de Pflichtveranstaltung CN 8 Sommersemester 2006

2 Inhaltsverzeichnis Vorwort... 3 Einleitung... 4 Testbarkeit von objektorientierten Konzepten Beobachtbarkeit Interfaces, abstrakte und generische Klassen Geerbte und nicht überschriebene Methoden Komplexität nicht in den Methoden selbst, sondern in der Interaktion...7 Nutzen eines Entwicklertestkonzepts... 8 EnTek konkret... 9 Test-Unit... 9 Klassenspezifikation als Teil des Entwicklertests Testbarkeit implementieren Test API Fazit für EnTek Quellen Literatur Internet... 13

3 Vorwort Nachdem sich objektorientierte Ansätze Mitte der 90er Jahre auf breiter Front durchgesetzt haben ist heutzutage die komponentenbasierte Softwareentwicklung in aller Munde. Trotzdem blieb der Test komponentenbasierter Software lange Zeit unbeachtet. Softwaresysteme bestehen aus einer Vielzahl an Softwarekomponenten, welche untereinander in Beziehung stehen. Die Qualität eines Softwaresystems hängt von der Qualität der einzelnen Softwarekomponenten und der Qualität der Beziehungen zwischen ihnen ab. Ein Teil zur Sicherstellung der Produktqualität ist der Test. Bernd Häbe Furtwangen, Dezember 2005

4 Programming is like exploring a dark house. You go from room to room to room. Writing a test is like turning on the light. Then you can avoid the furniture and save your shins. Then you're ready to explore the next room [Kent Beck, URL:TestDrivenDevGroup]

5 Einleitung Um Unit-Tests 1 durchzuführen, werden Frameworks wie zum Beispiel JUnit 2 immer beliebter. Das Wesentliche dieser Frameworks, die Testfallimplementierung, ist keineswegs die schwierigste Aufgabe im Prozess des Testens von objektorientierter Units. So ist z. B. die Testdatenermittlung bei objektorientierten Units wesentlich aufwändiger, da hier auch Objektzustände berücksichtigt werden müssen. Außerdem macht die eingeschränkte Beobachtbarkeit einen Vergleich von Soll- und Istwerten beim Test teils unmöglich. In dieser Ausarbeitung wird das Testkonzept EnTek vorgestellt, das mit seinen Aktivitäten vor der Testfallimplementierung beginnt. Rüppel beschreibt 1997 die Situation beim Testen kleiner objektorientierter Softwareeinheiten wie folgt: Demgegenüber ist das Testen von objektorientierter Software ein wenig beachtetes Gebiet innerhalb der Forschung geblieben: Nicht zuletzt weil man ursprünglich glaubte, daß objektorientierte Software besonders einfach getestet werden können. Weil aber immer mehr Unternehmen vor dem Problem stehen, ihre objektorientierten Komponenten testen zu müssen - ohne dabei auf ein ausreichendes Sortiment von Testverfahren und Testwerkzeugen zugreifen zu können, führte dies dazu, daß schon jetzt eine große Nachfrage bzgl. Methoden und Werkzeugen für den objektorientierten Test besteht. Da der Trend zur Objektorientierung aber anhält und der dynamische Test ein wichtiges Instrument der analytischen Qualitätssicherung in kommerziellen Entwicklungsprojekten ist und auch für absehbare Zeit bleibt, wird derbedarf an Methoden und Werkzeugen in diesem Bereich eher noch zunehmen 3 1 Der Modultest (auch Komponententest oder engl. unit test) ist Teil eines Softwareprozesses (z. B. nach dem Vorgehensmodell des Extreme Programming). Er dient zur Verifikation der Korrektheit von Modulen einer Software, z. B. von einzelnen Klassen. Als Voraussetzung für Refactoring kommt ihm besondere Bedeutung zu. 2 JUnit ist ein Framework zum Testen von Java-Programmen, das besonders für automatisierte Unit-Tests einzelner Units (meist Klassen oder Methoden) geeignet ist. Es basiert auf Konzepten, die ursprünglich unter dem Namen SUnit für Smaltak entwickelt wurden. 3 [Rüppel97, S. 1]

6 Auch heute besitzt dieses Zitat ausreichend Aktualität, um die Situation des Testens objektorientierter Software zu beschreiben. Das Testen objektorientierter Software stellt sich als komplizierter dar als das Testen von prozeduralen Programmen. Das Entwicklertestkonzept EnTek wurde am Fachbereich Wirtschaftsinformatik der Hochschule Furtwangen University in Kooperation mit der Firma Metris GmbH in St. Georgen erstellt. Es unterstützt die Entwickler in Form von Techniken, Vorgehensweisen und Mini-Tools und sucht dabei den Mittelweg zwischen einer guten technischen Fundierung und praktischer Einsetzbarkeit. Testbarkeit von objektorientierten Konzepten Dass eine Test-Unit z. B. Methode oder Klasse fehlerfrei ist, kann man mit Hilfe von Tests nur dann belegen, wenn diese Komponente vollständig, d. h. in allen theoretisch möglichen Szenarien, getestet wurde. Dies ist jedoch bereits bei kleinen Programmen nicht möglich, da der Aufwand nicht zu bewältigen ist. Um aus der großen Menge möglicher Tests die wirkungsvollsten herauszufiltern, wurden unterschiedliche Ansätze, wie Äquivalenzklassen 4 oder Grenzwerte, entwickelt. Bei objektorientierter Software kommen noch die Besonderheiten der Objektorientierung, die das Verhalten der Test-Unit ebenfalls beeinflussen, hinzu. Gemeint sind hier vor allem das Geheimnisprinzip 5 und die Kapselung 6. Dies führt dazu, dass 1. die Testdaten erweitert werden müssen, 2. die Beobachtbarkeit von objektorientierten Units eingeschränkt ist, 3. Interfaces, abstrakte und generische Klassen mit herkömmlichen Verfahren nicht testbar sind, 4. Vererbung zusätzlichen Testaufwand erzeugt und 5. das isolierte Testen von Methoden bei oo-klassen (meist) unangemessen ist. 4 Die Äquivalenzklasse eines Objektes a ist die Klasse der Objekte, die äquivalent zu a sind. 5 Vom Innenleben eines Objektes soll der Verwender (gemeint sind sowohl die Algorithmen, die mit den Objekten arbeiten, als auch der Programmierer, der diese entwickelt) möglichst wenig wissen müssen (Geheimnisprinzip) 6 Als Kapselung bezeichnet man den kontrollierten Zugriff auf Objekte. Objekte können den internen Zustand anderer Objekte nicht in unerwarteter Weise lesen oder ändern.

7 1. Erweiterte Testdaten Herkömmliche Testmethoden/Testansätze sind methodenbezogen und verlangen lediglich die Festlegung der Eingabeparameter und der erwarteten Rückgabewerte. Das Testen objektorientierter Units hingegen benötigt zudem die Festlegung des Objektzustandes und ggfs. die Werte der Klassenattribute. Dies hat nicht nur einen enormen Anstieg der Anzahl möglicher Testdaten zur Folge, es birgt außerdem die Problematik der Verschachtelung. 2. Beobachtbarkeit Steuerbarkeit (Controlability) und Beobachtbarkeit (Observability) werden als die Schlüsselfaktoren für die Testbarkeit objektorientierter Software eingestuft. Diese werden über Zugriffsmodifikatoren geregelt. Ausgehend davon, dass Objekte und Klassen somit den unbefugten Zugriff von außen auf ihre Daten vermeiden, ist das Vergleichen von Sollund Istwerten seitens des Testtreibers erheblich eingeschränkt ein Testen demnach maßgeblich erschwert. 3. Interfaces, abstrakte und generische Klassen Da von diesen Klassen keine Objekte angelegt werden können, muss bei der Testvorbereitung ein weiterer Schritt hinzugefügt werden (z. B. Ableiten einer Klasse von der zu testenden Klasse für Testzwecke). 4. Geerbte und nicht überschriebene Methoden Bei geerbten Methoden, die selbst nicht überschrieben wurden, besteht dennoch die Möglichkeit, dass sie im Kontext der Unterklasse ein anderes Verhalten zeigen. Grund für dieses abweichende Verhalten ist der Aufruf von anderen Methoden, die in der Unterklasse überschrieben wurden. Es ist somit notwendig, neben den überschriebenen Methoden auch die geerbten (nicht überschriebenen) Methoden in der Unterklasse zu testen auch wenn sich deren eigentliche Implementierung nicht geändert hat.

8 5. Komplexität nicht in den Methoden selbst, sondern in der Interaktion Ein Großteil der Funktionalität von objektorientierter Software liegt nicht in einzelnen Methoden, sondern in der Interaktion (Botschaften) zwischen Objekten und Klassen. Das heißt, der Test von objektorientierten Units muss die Interaktion zwischen Methoden beinhalten. EnTek reagiert auf diese zusätzlichen Anforderungen zum einen mit Vorgehensbeschreibungen und zum anderen mit einer eigenen Test API: So wird die eingeschränkte Beobachtbarkeit für Testzwecke umgangen und das Anlegen von Testobjekten in beliebigen Zuständen ermöglicht. Nutzen eines Entwicklertestkonzepts Ein Nutzen bzw. Mehrwert des Entwicklertestkonzepts EnTek ist es, die mit dem Unit-Test zusammenhängenden Aufgaben zu beschreiben, mögliche Hilfsmittel in Form von Anleitungen, Verfahren und Frameworks oder Tools zu evaluieren, zu integrieren und zur Verfügung zu stellen. Abbildung 1 beinhaltet eine Übersicht möglicher Aufgaben des Unit- Tests bei EnTek.

9 Jede Aktivität ist kurz anhand von Stichworten und Beispielen im rechten Teil der Abbildung 1 illustriert. Innerhalb der Testplanung erfolgt neben der Festlegung von Testzielen und -methoden auch die Priorisierung, die eine effiziente Verteilung der Testkapazitäten schon in früheren Phasen der Softwareentwicklung zum Ziel hat. So können Test-Units bzw. Klassen mit hoher Kritikalität identifiziert und der Testaufwand entsprechend verteilt werden. Die Testvorbereitung umfasst u. a. die Erstellung einer Low-Level-Spezifikation, die das Sollverhalten der Test-Units explizit beschreibt. Dieser Aktivität kommt eine hohe Bedeutung zu, da beim Durchführen von funktionalen Tests (Black-Box-Tests) der Test gegen die Spezifikation erfolgt. Eine solche Spezifikation gibt zudem frühe Hinweise darauf, ob die Softwareanforderungen präzise genug sind und verstanden werden. Wird diese Spezifikation in einer formalen Sprache verfasst, bildet sie außerdem einen möglichen Ausgangspunkt für eine automatisierte Ableitung von Testfällen. Zum Erstellen von Testfällen gibt es einerseits Ableitungsregeln für die Testprozeduren und andererseits Verfahren für die Testdatenermittlung, die z. B. Äquivalenzklassen oder Grenzwerte mit einbeziehen, jedoch für den Entwicklertest machbar angepasst sind. Auf einige Besonderheiten objektorientierter Test-Units, wie Test des Zustandsverhaltens oder Test trotz Geheimnisprinzip, geht EnTek detailliert ein. Der Testfallimplementierung gehen innerhalb von EnTek also mehrere zusätzliche Aktivitäten voraus. Zur automatisierten Testfallausführung, -auswertung und -dokumentation nutzt EnTek bewährte Opensource- Frameworks und Tools wie z. B. JUnit, Doclets 7 und ANT 8. 7 Als Doclet bezeichnet man Module, die von Dokumentationswerkzeugen zur Verarbeitung und automatischen Erzeugung von Dokumenten und eventuell auch Code eingesetzt werden. 8 Ant (englisch für Ameise) ist ein in Java geschriebenes Werkzeug zum automatischen Erzeugen von Programmen aus Quelltext

10 EnTek konkret Test-Unit Als Test-Unit werden eng-zusammenhängende Klassen herangezogen, um den Aufwand für die Erstellung von Stubs, der beim isolierten Testen einzelner Klassen oder Methoden auftritt, zu minimieren (siehe Abbildung 2). Je nachdem wohin man das orange Oval verschiebt, entscheidet man sich für eine Kombination aus Test-Unit-Größe und einem Isolationsgrad der Test-Unit. EnTek wählt die Alternative 4. Klassenspezifikation als Teil des Entwicklertests Ein Kernstück von EnTek bildet die Klassenspezifikation. Als Spezifikation auf Test-Unit- Ebene beschreibt sie das Sollverhalten der Test-Unit (z. B. Zustand, Methode) und bildet den Ausgangspunkt zur systematischen Ableitung von Testdaten und Testfällen. Dabei gilt, dass sich ein Objekt nur so ändern darf, wie es explizit spezifiziert ist. Verändert sich der Objektzustand nach einem Methodenaufruf, so muss der Vorzustand in der Vor- und der Nachzustand in der Nachbedingung spezifiziert sein. Ansonsten wird davon ausgegangen, dass kein Zustandsübergang erfolgen darf. Somit ist der Vorzustand Teil der Test-Eingabewerte und der Nachzustand Teil der Test-Ergebniswerte.

11 EnTek empfiehlt nur für Klassen, die für den Klassentest ausgewählt wurden, eine Klassenspezifikation. Die Spezifikation nutzt die JavaDoc-Notation und erweitert diese um testspezifische Tags. Anders als bei der herkömmlichen JavaDoc ist der Inhalt der Tags kein Beschreibungstext, sondern ein nach Java-Syntax kompilierbarer boolescher Ausdruck. Im folgenden Beispiel wird dies anhand der Spezifikation einer Zustandsbeschreibung und einer Vorbedingung vorgestellt. Testbarkeit implementieren Test API Ein anderer Teil von EnTek ist die Test-API, die zur Verbesserung der Beobachtbarkeit für den Vergleich von Soll- zu Ist-Verhalten und zur Erzeugung von Testobjekten in beliebigem Zustand entwickelt wurde. Zum einen ist eine Spezifikation auf Unitebene notwendig, um das Sollverhalten für den späteren Test zu beschreiben, und zum anderen werden Hilfsmethoden benötigt, um für Testzwecke die Beobachtbarkeit der Test-Unit zu ermöglichen. EnTek stellt außerdem eine Klasse TestObjInstantiator zur Verfügung, damit Testobjekte mit beliebigen Testdaten erzeugbar sind. Ein nützlicher Nebeneffekt der beschriebenen JavaDoc-Klassenspezifikation ist die Möglichkeit, daraus mit Hilfe der Doclet-API Dokumentation zu generieren. EnTeks Testable-API wird sowohl bei der Klassenspezifikation als auch beim Implementieren der Tests verwendet. Fazit für EnTek Neben der technischen Fundierung steht bei EnTek vor allem die Machbarkeit für den Entwickler im Vordergrund. Zusammenfassend kann gesagt werden, dass EnTek die genannten Besonderheiten objektorientierter Software beim Entwicklertest wie folgt berücksichtigt: Testdaten Bei der Spezifikation von Testdaten werden objektorientierte Konstrukte wie Objektzustand und Klasseninvarianten detailliert beschrieben und so in die

12 Testfallermittlung mit einbezogen. Beobachtbarkeit EnTek beinhaltet eine Test-API, damit Objektzustände abfragbar/vergleichbar sind. Interaktionen Innerhalb von EnTek ist die Test-Unit keine isolierte (gestubbte) Klasse. Folgende Abbildung illustriert zusammenfassend die Anforderungen an ein Entwicklertestkonzept bzw. dessen positive Auswirkungen auf die Software. Das Verhältnis zwischen Lern- und Zeitaufwand für EnTek muss differenziert betrachtet werden. Die Einführung eines neuen Konzepts bedeutet immer Lernaufwand. Da EnTek gezielt auf bereits vorhandenes Wissen, wie z. B. JavaDoc-Kommentierung, des Entwicklers zurückgreift, ist der Lernaufwand zum großen Teil durch das Verständnis der Testverfahren und des Vorgehens begründet. Dabei ist es notwendig, als Entwickler das bisherige Vorgehen anzupassen und zu erweitern, auf der anderen Seite winkt der Vorteil der erleichterten Fehlersuche. Beim Zeitaufwand hinsichtlich der Durchführung der Testaktivitäten müssen auch die erst später sichtbaren Vorteile, wie eine erleichterte Wartung und Fehlerbehebung, beachtet werden. Zudem verkürzt sich der Zeitaufwand der Testaktivitäten durch Gewohnheit oder Automatisierung.

13 Für einen systematischen Entwicklertest sind besonders die vorgelagerten Testaktivitäten, das Erstellen der Testfälle und Testdaten von Bedeutung. Hierbei spielen nicht nur konventionelle Testverfahren, sondern auch die objektorientierten Besonderheiten eine Rolle. An diesem Punkt stehen sich die technische Notwendigkeit (damit die Testergebnisse aussagefähig sind) und die Limits des Entwicklers (hinsichtlich der Anforderungen aus Testtheorie und zu investierender Zeit) diametral gegenüber. Das Entwicklertestkonzept EnTek beinhaltet ein systematisches Vorgehen zum Ableiten der Testfälle. Gleichzeitig wird jedoch nur ein systematisch ausgewählter Teil dieser Tests implementiert. Als unser Fazit kann formuliert werden: Entwicklertests sind zwar nicht das Allheilmittel schlechthin, stellen aber durchaus eine sinnvolle Qualitätssicherungsmaßnahme begleitend zum Softwareentwicklungs-Prozess dar, da zahlreiche Fehler zu einem frühen Zeitpunkt entdeckt werden und somit gewährleistet ist, dass möglichst wenige Fehler in das Softwareprodukt bzw. den Systemtest gelangen.

14 Quellen Literatur Java Spektrum; 6/2004; Titelthema Testen Internet - Diplomarbeit im Fachbereich Wirtschaftsinformatik der Fachhochschule Furtwangen,