Beginnt man die Suche nach Testtools für J2EE-Anwendungen, wird man im Internet geradezu überhäuft mit hunderten von Werkzeugen. Für (fast) alle Arten von Tests findet sich etwas, oftmals auch im Open Source-Bereich. Damit nicht selbst jedes Tool unter die Lupe genommen werden muss, wird in diesem Artikel eine Vorstellung der interessantesten Testwerkzeuge präsentiert. Um einen Überblick zu liefern, wann sich der Einsatz von welchem Testwerkzeug lohnt, wird eine Einteilung nach den verschiedenen Testarten vorgenommen. Am Beispiel des Funktionaltests lässt sich schnell erkennen, dass dieser auf allen Stufen des Integrationsverlaufs von J2EE-Anwendungen in verschiedenen Ausprägungen anzutreffen ist. Was könnte also als weiteres Kriterium zur Kategorisierung dienlich sein?

Eine nochmalige Unterteilung gelingt entlang des Integrationsverlaufs durch die Rollen der J2EE -pezifikation, was nicht bedeuten soll, dass deshalb auch eine tatsächliche Arbeitsteilung zwischen realen Entwicklern stattfinden muss (so findet sich der Entwickler von J2EE-Komponenten oftmals auch in der Rolle des Deployers wieder). Nach genauer Betrachtung fehlt für das Testen jedoch noch die Abpictureung des Kunden bzw. eines Domänen-Experten, der den Akzeptanztest durchführt. Mit den verschiedenen Testarten und den J2EE-Rollen lässt sich die in Tabelle 1 abgepictureete Einteilung von Testaktivitäten vornehmen.
  Je Kategorie werden brauchbare Werkzeuge mit einer kleinen Beschreibung vorgestellt. Um einen schnellen Überblick zu erhalten, liefert die Tabelle 2 am Ende des Artikels eine feinere Einordnung pro Tool. Damit wird der Tatsache Rechnung getragen, dass ein Tool nicht immer exakt in eine Kategorie passt.

Strukturierter Test (White Box)

Mit der Kenntnis des Codes bzw. der Implementierung der Funktionalität können sogenannte White Box-Tests durchgeführt werden. Ob und wie diese Art des Testens bei J2EE-Anwendungen oder allgemein im objektorientierten Umfeld Verwendung finden sollte, soll hier nicht diskutiert werden. Entsprechende Werkzeuge sind kaum am Markt vertreten. In diesem Testbereich kann auf JUnit zurückgegriffen werden - in Kombination mit einem Werkzeug zur Code Coverage Analyse. Die zu erstellenden Tests stellen (trotz des Namens des Frameworks) keine Unit-Tests dar. In einem sich wiederholenden Prozess kann mit einem Coverage-Werkzeug analysiert werden, welcher Code auf welche Weise von den Tests durchlaufen wird. Ein entsprechendes Ergebnis ist Ansatzpunkt für weitere Tests, die gezielt die bisher nicht durchlaufenen Codezeilen zur Ausführung bringen sollen. Für Code Coverage können folgende Werkzeuge eingesetzt werden.

Clover: Ein kleines Tool mit großer Wirkung - über Ant leicht in ein Projekt zu integrieren, können spezielle Tasks ausgeführt werden, die den Coverage-Prozess anstoßen. Clover arbeitet auf der Stufe von Statement und Branch Coverage. Die Coverage-Ergebnisse können entweder über ein Swing GUI betrachtet oder in XML, HTML oder PDF ausgegeben werden. Info: www.thecortex.net/clover

JCover: Wie Clover kann mit JCover Statement und Branch Coverage durchgeführt werden. Allerdings bringt JCover die Features mit, die man bei der Verwendung von Clover vermisst. Das Werkzeug ermöglicht den Vergleich von Coverage-Ergebnissen, ermittelt Testredundanz und bietet Client- und Server-seitiges Coverage. JCover kann sowohl als eigenständiges Werkzeug benutzt als auch in einen automatisierten Build-Prozess integriert werden.
Info: www.codework.com/JCover/product.html

Hansel und Gretel: Bei diesen beiden Werkzeugen wird ein anderer Coverage Ansatz verfolgt - Residual Test Coverage. Während beim gängigen Code Coverage analysiert wird, welcher Code mittels Tests ausgeführt wurde, liegt hier die Vorgehensweise in der Analyse von nicht ausgeführtem Code. Gretel verfolgt diesen Ansatz allgemein für Java-Programme, d.h. nachdem der Programmcode von Gretel instrumentiert und das Programm ausgeführt wurde, zeigt Gretel den nicht ausgeführten Code auf. Hansel stellt eine JUnit kompatible Erweiterung dieses Ansatzes dar.
Info Gretel: www.cs.uoregon.edu/research/perpetual/dasada/Software/Gretel/
Info Hansel: hansel.sourceforge.net/

Funktionaler Test (Black Box)

Das Gewährleisten von Funktions- und Anforderungskonformität muss auf jeder Entwicklungsstufe innerhalb eines Projektes durchgeführt werden, d.h. von der einzelnen Komponente beginnend über integrierte Teilsysteme bis hin zur Abnahme. Prominentester Vertreter dieser Kategorie ist das JUnit-Framework (www.junit.org/). Es bietet die Möglichkeit, Testtreiber in Form von Klassen zu erstellen, die mittels mitgelieferter Testrunner-Objekte ausgeführt werden. Theoretisch betrachtet, liefert das JUnit Framework alles, was man zum Funktionaltest, welcher Art auch immer, benötigt. Im Hinblick auf die vielseitigen Funktionalitäten von J2EE-Applikationen bestehen neben dem standardgemäßen Testen von Java-Funktionalität zusätzlich grundlegende Anforderungen, um ein J2EE-Testumfeld zu schaffen. Beispielsweise können EJBs als Business-Komponenten in ihrer Funktionalität nur innerhalb eines Application Servers getestet werden. Um dies zu bewerkstelligen, müssen die Tests ebenso innerhalb dieser Umgebung ausgeführt werden können.

JUnitEE: Das Testframework JUnitEE basiert auf JUnit und ermöglicht das Ausführen der Unit-Tests innerhalb des Application Servers. Die Tests werden als Web-Archive der Gesamtapplikation mitgegeben. Somit ist ein Testen im Produktivsystem auf Abruf möglich. Die Tests werden über ein Servlet gesteuert und die Ergebnisse im HTML-Format ausgegeben. Mit JUnitEE als Framework hat man alle Hilfsmittel zur Verfügung, um das Umfeld der zu testenden Komponenten entsprechend zu konfigurieren, z.B. durch Setzen von JNDI Properties. Info: www.junitee.org/ HttpUnit: HttpUnit bietet die Möglichkeit, Webseiten automatisiert aufzurufen. Mittels einer zentralen Klasse WebConversation wird ein Browser simuliert, der es ermöglicht, den Inhalt einer angeforderten Webseite zu erhalten. Handelt es sich beim Inhalt um XML, kann dynamisch ein DOM-Tree erzeugt werden. Liegt HTML vor, stehen zusätzlich Navigationsmöglichkeiten zur Verfügung. Typische HTML-Elemente werden durch Klassen repräsentiert, wie z. B. WebTable und können bezüglich ihres Inhalts evaluiert werden. Ein ausgezeichnetes Werkzeug zum Überprüfen der Funktionalität der Webanwendung außerhalb des Servers. Info: www.httpunit.org/

HtmlUnit: Ähnlich wie HttpUnit kann auch HtmlUnit Webseiten automatisiert aufrufen und deren Inhalt prüfen. HtmlUnit unterscheidet sich jedoch dadurch, dass der Benutzer nicht mit Request oder Response Objekten arbeitet, sondern seitenorientiert. Für das gezielte Testen des statischen Inhalts von Webseiten, auch im Zusammenspiel mit JavaScript, bietet sich HtmlUnit besonders an, da hierfür noch speziellere Klassen als bei HttpUnit zur Verfügung stehen. Info: htmlunit.sourceforge.net/

Cactus: Cactus ist ein Framework, welches das Testen von Server-Seitigem Java-Code, z.B. Servlets, Filter und EJBs, ermöglicht. Dazu erweitert es das JUnit Framework um Client- und Server-seitige Klassen. Die Testfälle werden von der Client-Seite aus durch einen JUnit-Testrunner und über ein Redirector Proxy-Objekt gesteuert. Die Testfälle werden auf der Server-Seite in der JVM des Containers ausgeführt. Cactus wird wie JUnit bereits von einigen kommerziellen Werkzeugen unterstützt. Als interessant könnte sich eine Idee, die auf der Cactus-Homepage veröffentlicht wurde, erweisen - das Verbinden von Cactus mit JUnitEE. Genauere Informationen waren bei Reaktionsschluss noch nicht vorhanden. Info: jakarta.apache.org/cactus/

TagUnit: Das Testen von Servlets und JavaServer Pages gestaltet sich trotz Tools wie Cactus, JunitEE und HttpUnit als schwierig, wenn Custom Taglibs verwendet werden. Es macht wenig Sinn, Custom Tags durch den Aufruf ihrer Methoden zu testen, da sie als Komponente in einem speziellen Umfeld verwendet werden. TagUnit ermöglicht es, Taglibs in diesem Umfeld zu testen. Es werden Assertions zur Verfügung gestellt, die den Inhalt und die Seiteneffekte (Attribute, Cookies, etc.) prüfen, die durch ein Custom Tag erzeugt werden. Info: www.tagunit.org/

Bugkilla: Bugkilla ist eine Sammlung von Werkzeugen zur Unterstützung des funktionalen Testens von J2EE Web Anwendungen. Das Hauptziel ist die Automatisierung der Spezifikation und Ausführung von Akzeptanztests in ein und demselben Werkzeug. Dabei gilt es, sowohl die Webschicht als auch die Geschäftslogikschicht zu testen. Integriert in die IDE Eclipse kann man mit dem Ansatz, den Bugkilla verfolgt, eine ganz andere Sichtweise auf das Testen bekommen (mehr zu Bugkilla erfahren Sie in einem weiteren Beitrag dieses Titelthemas).
Info: bugkilla.sourceforge.net/

Solex: Das Eclipse-Plugin Solex präsentiert sich in seiner Arbeitsweise ähnlich dem Bugkilla-Projekt. Request und Response von HTTP-Nachrichten werden mittels einer Proxy-Komponente aufgezeichnet und können als XML-Files gespeichert werden, um später wieder abgespielt zu werden. Die aufgenommenen HTTP Requests und Responses stehen als Informationsträger mit ihrem gesamten Inhalt zur Verfügung. Allerdings bestehen hier keinerlei Ambitionen zum Test der Geschäftslogikschicht. Info: solex.sourceforge.net/

Canoo Web Test Distribution: Die Web Test Distribution von Canoo bietet, wie HttpUnit, die Möglichkeit, durch Webseiten zu surfen und Inhalte zu prüfen. Ein Benutzerszenario muss allerdings nicht von Hand programmiert werden, sondern wird mittels XML spezifiziert. Der Domänen-Experte hat mit diesem Tool eine brauchbare Möglichkeit, mit der sich Akzeptanztests spezifizieren lassen, ohne Java programmieren zu müssen.
Info: webtest.canoo.com/webtest/manual/WebTestHome.html

Bean Test: In jedem J2EE-Projekt, das mit einer Geschäftslogik in Form von EJB-Komponenten arbeitet, muss außer der Funktionalität ebenso die Skalierbarkeit getestet werden. Hier steht mit Bean Test ein Werkzeug zur Verfügung, mit dem sich beide Testziele gleichzeitig verfolgen lassen. Optimiert für die Großen wie z.B. Bea Weblogic, IBM Websphere und Oracle9iAS, können gezielt Performance- und Funktionaltests durchgeführt werden, die automatisch durch Bean Test generiert werden. Speziell im Bereich EJB-Testing stellt Bean Test gewiss eines der führenden Testwerkzeuge dar. Infos: www.empirix.com/empirix/

DBUnit: Datenbanken sind ein wichtiges Teilsystem einer J2EE-Applikation. Daher ist es erforderlich, die Auswirkungen der einzelnen Komponenten auf den Zustand der Datenbank zu evaluieren. DbUnit wird in Kombination mit JUnit verwendet und übernimmt sowohl das Datenbank-spezifische Testfixture, als auch die Evaluation des Datenbankzustandes nach der Ausführung der zu testenden Operationen. Ausgangsdaten und Testorakel können einfach per XML-Datei spezifiziert werden. Info: dbunit.sourceforge.net/

Mock-Generatoren: Unit Tests evaluieren einzelne Softwarekomponenten in Isolation auf ihre korrekte Funktionsweise. Soll eine Softwarekomponente getestet werden, die mit anderen Komponenten interagiert, müssen Attrappen für diese erstellt werden, sogenannte Mock-Objekte. Diese simulieren die für den Testzweck zu ersetzenden Klassen in einer einfachen Weise. Easy Mock, Mock Creator und Mock Maker sind Generatoren, die die Erstellung von Mock-Objekten weitgehend vereinfachen und automatisieren. Info: www.easymock.org/, www.abstrakt.de/mockcreator.html, www.mockmaker.org/

StrutsTestCase: Eine Erweiterung von JUnit, die einen MockObjects-Ansatz mit einem Cactus-Ansatz verbindet, um das ActionServlet von Struts (Struts 1.1b3) auszuführen. Dadurch wird es möglich, den Struts-Code wahlweise außerhalb oder innerhalb des Containers auszuführen. Auch Mappings, FormBeans und Forward-Deklarationen können getestet werden. Info: strutstestcase.sourceforge.net/

Performanz- und Lasttest

Performanz stellt wahrscheinlich eines der Hauptkriterien dar, die über den Erfolg eines J2EE-Projekts entscheiden. Um so wichtiger ist es, im gesamten System den Überblick zu behalten, wie sich die einzelnen Komponenten bzw. Subsysteme im Betrieb bezüglich ihrer Performance verhalten. Da die meisten Ressourcen innerhalb des Application Servers verbraucht werden, bieten z.B. WebSphere oder WebLogic Analysemöglichkeiten des Performanzverhaltens über entsprechende Module. In der Open Source-Landschaft können Server wie JBoss und JOnAs zwar nicht auf so professioneller Ebene mithalten, jedoch lässt sich beispielsweise über die JMX-Konsole des JBoss das Verhalten der Applikation gut mitverfolgen. Erweiterungen in diesem Bereich sind bei beiden Application Servern angekündigt.

JMeter: JMeter vom Apache-Jakarta-Projekt ist ein Werkzeug zum Ausführen von Lasttest in Client/Server-Anwendungen. Mittels eines zu erstellenden Testplans wird spezifiziert, welche Teile der Anwendung durchlaufen werden sollen, um konkrete Ergebnisse über das Anwortzeitverhalten zu bekommen. Diese werden in der leicht zu bedienenden Oberfläche von JMeter präsentiert. Durch Logik-Komponenten, Listener, Sampler, Timer und Konfigurationselemente lassen sich bis ins Detail angepasste Testpläne erstellen. JMeter kann auch als Proxy-Komponente zum Auszeichnen einer Abfolge von Testschritten eingesetzt werden, die als Basis von Testplänen eingesetzt werden kann. Ein besonderes Feature ist, dass mittels Sampler gesendete Requests sich nicht nur auf HTTP und HTTPS beschränken, sondern ebenso für FTP, SOAP und JDBC erzeugt werden können.
Info: jakarta.apache.org/jmeter/

The Grinder: Als Nebenprodukt eines Buches wurde The Grinder entwickelt, ein Java-Lasttest-Framework. Das Tool ermöglicht es, über Testskripte Aktivitäten in verschiedenen Prozessen über mehrere Rechner verteilt gezielt auf die Anwendung zu steuern. The Grinder bringt bestehende Module zum Belasten von Anwendungen über HTTP und zum automatischen Aufzeichnen von HTTP Requests mit sich. Eine Besonderheit ist seit der Version 3 (noch im Beta-Stadium), dass die Testskripte in Jython (www.jython.org/) erstellt werden, der Java-Implementierung von Python. Info: grinder.sourceforge.net/

JUnitPerf: Wie der Name bereits zu erkennen gibt, handelt es sich bei JUnitPerf um einen Aufsatz zu JUnit. Hierbei wird Performance und Lastmessung an den bestehenen JUnit-Tests durchgeführt. Ohne diese zu modifizieren, kann ausserhalb des TestCases eine bestimmte Dauer, in der ein Test ausgeführt werden soll, spezifiziert werden. Wird diese überschritten, gilt der Test als fehlgeschlagen. Durch die Angabe von Benutzeranzahl, Dauer und Wiederholungen kann JUnitPerf das Laufzeitverhalten der Tests unter Last überprüfen. Der Einsatz von JUnit mit JUnitPerf ermöglicht bereits im frühen Stadium, Skalierbarkeit im Kleinen zu kontrollieren.
Info: www.clarkware.com/software/JUnitPerf.html

EJP: Der Extensible Java Profiler (EJP) ist ein klassisches Profiling-Werkzeug zum Performance-Test. Mit dem EJP kann schnell Code aufgespürt werden, der besonders viel CPU braucht. Mit anspruchsvoller grafischer Oberfläche ausgestattet, präsentiert sich das Open Source-Tool sehr professionell. Über Filter ist möglich, jeweils für den Test bestimmte Information von weniger wichtigen zu trennen und präsentieren zu lassen. Klassische Profiling Features wie z.B. Verfolgen von Methodenaufrufen und graphische Darstellung in Baumstruktur sind natürlich vorhanden. Durch die User Interfaces für Filter und die XML-Konfiguration lässt sich EJP benutzerspezifisch erweitern.
Info: ejp.sourceforge.net/

SimpleProfiler: Der SimpleProfiler basiert auf dem Java Virtual Machine Profiler Interface (JVMPI) und versteht sich als Speicher-Profiler. Durch einfaches Hinzufügen an die Virtuelle Maschine können Speicherstatistiken erstellt werden. Dieses kleine Werkzeug ermöglicht auf einfache Art und Weise, das Speicherverhalten während des Ausführens einer Anwendung zu analysieren und Informationen über Ausführungszeiten von Methoden zu erhalten. Der SimpleProfiler befindet sich erst im Alpha-Stadium und ist in seiner Umsetzung noch sehr einfach gehalten.
Info: sourceforge.net/projects/simpleprofiler

jProf: Ein weiterer Profiler aus der freien Welt. Wie SimpleProfiler setzt auch jProf auf dem JVMPI auf. In der Swing-GUI kann man gezielt während der Ausführung der zu testenden Anwendung den Speicher, die Garbage Collection oder die laufenden Threads betrachten. Ergebnisse werden als HTML ausgegeben. Sehr veranschaulichend sind die verschiedenen Charts, die anhand der Ergebnisse erzeugt werden können, so z.B. der Anteil einzelner Methodenaufrufe an der CPU-Nutzung. Info: starship.python.net/crew/garyp/jProf.html

EclipseProfiler: Just another plug-in? Was hier als kleines Modul zur Erweiterung von Eclipse daherkommt, bringt eine ganze Sammlung von Funktionalität im Bereich Java Profiling mit. In Eclipse integriert, ermittelt der EclipseProfiler Ausführungszeiten von Aufrufen, erstellt Ausführungsgraphen, blendet dabei den Speicher ein und ermöglicht das gezielte Verfolgen einzelner Threads und deren Ausführung. Interessant ist die Remote-Profiling Konfiguration, die es beispielsweise innerhalb von Tomcat oder JBoss ermöglicht, Informationen über Speicherbedarf und Ladezeiten zu erhalten. Info: eclipsecolorer.sourceforge.net/ P6Spy: P6Spy betrachtet speziell einen Performance-kritischen Bestandteil von Enterprise Anwendungen - den Datenbanktraffic, der mittels JDBC-Statements erzeugt wird. Der P6Spy besteht aus zwei Modulen, P6Log und P6Outage. Mit dem P6Log können alle Operationen, die mittels JDBC auf der Datenbank ausgeführt werden, verfolgt und geloggt werden. Um lange laufende JDBC Statements herauszufiltern, kann man mit dem P6Outage diese speziell erfassen lassen. Der P6Spy lässt sich ohne Veränderungen am Code in bestehende Projekte integrieren. Pluspunkt - für JBoss, ATG, Orion, JOnAS, iPlanet, WebLogic, WebSphere, Resin and Tomcat sind Anleitungen zur Installation verfügbar. Info: www.p6spy.com/

JStress: Kleines Tool - große Wirkung. Das Werkzeug geht mit der Intention an den Start, sich nicht auf bestimmte Systemarchitekturen zu beschränken. Mittels verschiedener, verteilten Agenten, die zentral gesteuert werden, können Tests ausgeführt werden. Zwar befindet sich JStress noch im Beta-Stadium, kann aber, so einfach es auf den ersten Blick erscheinen mag, sehr wirksam Last für J2EE Anwendungen erzeugen.
Info: jstress.sourceforge.net/index.php

LoadRunner: Die Firma Mecury Interactive ermöglicht mit ihrem LoadRunner das Systemverhalten und die Systemleistung vorherbestimmen zu können. Herausragend ist die Toolunterstützung für alle bekannten Anbieter in den einzelnen Enterprise-Bereichen. Die LoadRunner Suite besteht aus verschiedenen Echtzeit-Monitoren für Applikationsserver, Datenbankserver, Webserver und Netzwerk, die präzise Performance-Messungen während der Lasttests durchführen. Über den LoadRunner Controller werden die Tests gesteuert. Zur Ermittelung von Problemstellen in der Netzwerkstruktur können Tests außerhalb von Firewalls ausgeführt werden. Alle Performancedaten des Systems werden gesammelt in einem Repository zu späteren Analyse und Auswertung abgelegt. Info: www-svca.mercuryinteractive.com/products/loadrunner/

PerfectLoad: Um eine J2EE-Anwendung mal richtig zu belasten, kann man ihr mit PerfectLoad ordentlich einheizen, z.B. mit mehreren tausend Usern, die konkurrierend HTTP-Requests abschicken. Anhand der Anforderungen kann PerfectLoad ermitteln, ob eine Anwendung diesen standhält. Ebenso können durch Profiling Möglichkeiten in jedem Entwicklungsstadium Performance- und Lastprobleme aufgedeckt werden. Sogar bei der Entscheidung, ob eine Anwendung zur Verbesserung entweder mehr Hardware benötigt oder die Software mehr Veränderungen, hilft dieses Werkzeug. Info: www.solnet.co.nz/solutions/perfectload.html

JProbe und PerformaSure: Aus der Softwareschmiede Sitraka (heute zu Quest Software gehörend) kommen sowohl mit JProbe als auch mit PerformaSure zwei Werkzeuge, die kaum Wünsche im Bereich Profiling und Performace-Testen übrig lassen. JProbe stellt eine Sammlung von Werkzeugen zur Fehlerbehebung und Aufdeckung von Performancelöchern zur Verfügung. Mit Threadanalyzer, Memory Debugger, Coverage und Profiler wird eine Diagnose der Anwendung und des Umfelds erstellt. Dabei lässt sich jedes auftretende Probleme genau nachverfolgen. Während sich JProbe als Werkzeug im allgemeinen Java-Umfeld positioniert, setzt PerformaSure die entsprechenden Ansprüche in Bezug auf das J2EE-Umfeld um. Einsetzbar als Monitor, kann das gesamte Umfeld einer J2EE Applikation unter Performance-Gesichtspunkten betrachtet werden. Werden beispielsweise bestimmte Transaktionen als Flaschenhals ausfindig gemacht, erlaubt PerformaSure durch Visualisierung der einzelnen Transaktionsschritte das genaue Beobachten der beteiligten Komponenten und deren Verhalten. Ein Satz für beide Tools: Testversion anfordern - anschauen lohnt sich! Info: www.sitraka.com/home/home.shtml

OptimizeIt: Mit der OptimizeIt Suite und der Erweiterung OptimizeIt ServerTrace von Borland kommen zwei interessante Werkzeuge zum Performance-Testen. Bestehend aus Profiler, Coverage Analyzer und Thread Debugger setzt die OptimizeIt Suite das Testen auf Code-Ebene an und hilft, gezielt Ursachen für Performance-Verluste aufzufinden. OptimizeIt ServerTrace stellt eine Erweiterung für die J2EE-Entwicklung dar und ermöglicht, die Performance auch während des Testens zu überwachen und zu steuern. Dabei werden Lösungen zum Optimieren angeboten. Wie bereits bei den Vorgängern geschrieben - anschauen lohnt sich. Vor allem die Kombination, die OptimizeIt Suite integriert im JBuilder einzusetzen. Info: www.borland.com/optimizeit/

Weiteres rund ums Testen und QS

Hyades: Am 2. April 2003 hat Hyades 0.0.1, der erste veröffentlichte Build, das Licht der Welt erblickt. Wir gehen davon aus, dass über Hyades noch viel zu berichten sein wird. Das Hyades Projekt hat sich zum Ziel gesetzt, eine Open Source-Plattform für Automatisierte Software Qualität (ASQ) auf der Basis des Eclipse-Projekts bereitzustellen. Auch einige Referenzimplementierungen für Tracing- Monitoring- und Testwerkzeuge sollen dem Basisframework beigelegt werden. Als Toolanbieter kann man auf Unterstützung für die Erstellung von Werkzeugen für Aufzeichnung, Funktionaltests, Lasttests, Testmanagement, Testanalyse und Monitoring hoffen. Ein einheitliches Datenmodell für Testfallspezifikationen, Testprotokolle und Traces (erste UML-Modelle sind schon sichtbar) auf der Basis eines OMG Test Profil Modells und ein gemeinsam nutzbares User-Interface wird die Entwicklungskosten für ASQ-Werkzeuge deutlich senken. Bisher sind IBM, Parasoft, Rational, Scapa Technologies und Telelogic dem Projekt beigetreten. Info: www.eclipse.org/hyades/

CruiseControl: Treat the daily build as the heartbeat of the project. If there's no heartbeat, the project is dead [1] Beim Extreme Programming findet sich eine dem Daily Build entsprechende Idee namens Continuous Integration. Grundvoraussetzung ist die vollständige Automatisierung des Buildprozesses, was insbesondere die folgenden Punkte beinhaltet:

• Interaktion mit der Versionsverwaltung um die neueste Version zu erhalten.
• Aufruf aller notwendigen Compile-, Link- und Package-Vorgänge mit einem Kommando
• Aufruf aller notwendigen Testläufe mit einem Kommando
• Benachrichtigung aller beteiligten Personen über die Resultate des letzten Builds.

CruiseControl ist ein Java-basiertes Open Source-Framework, das aus zwei Kernteilen besteht, der Build Loop und der Build Results JSP. Bei der Build Loop handelt es sich um einen Hintergrundprozess, der periodisch prüft, ob Änderungen im zentralen Quellcode durchgeführt wurden. Falls ja, werden die oben genannten Punkte abgearbeitet. Die Build Loop wird über eine XML-Datei konfiguriert oder wahlweise auch über ein JMX-basiertes Web-Interface verwaltet. Neben der bereits erwähnten Mailbenachrichtigung wird zusätzlich nach jedem Build eine Log-Datei erzeugt, die von der Build Results JSP zur Darstellung einer Ergebnis-Historie verwendet wird. CruiseControl bringt eine deutliche Qualitätsverbesserung für Java-basierte Softwareprojekte. Durch die ständige Integration werden mögliche Integrationsfehler früh entdeckt. Durch kontinuierliches erfolgreiches Bauen eines Projekts kann außerdem die Moral eines Entwicklungsteams nachhaltig gestärkt werden. Der Einführungsaufwand für CruiseControl ist für Java-Projekte, die bereits auf Ant und CVS basieren, ausgesprochen gering und wird von den zuvor genannten Vorteilen mehr als aufgewogen. Das Zusammenwerfen einzelner Codeteile kurz vor einem Release mit anschließendem Fehler-Urknall, die sogenannte Big Bang Integration, sollte damit endgültig der Vergangenheit angehören. Info: cruisecontrol.sourceforge.net/

Metrics: Das Metrics-Plugin von Team in a Box ist für die Eclipse-Plattform geschrieben. Es ermöglicht die Messung verschiedener Metriken, wie z.B. die Anzahl der Parameter einer Methode, die Komplexität einer Klasse und die Zyklomatische Zahl. Die einzelnen Metriken ermöglichen es, die Qualität des Quellcodes zu messen. Anhand von Vergleichswerten kann entschieden werden, welche Stellen im Code einem Refactoring unterzogen werden sollten. Info: www.teaminabox.co.uk/downloads/metrics/

Panorama for Java: Ähnlich dem Metrics-Plugin für Eclipse bietet Panorama for Java eine Analyse des Quellcodes in verschiedenen Variationen an. Darüber hinaus können Beziehungen zwischen Codeteilen unterschiedlich visualisiert und Coverage Analysen durchgeführt werden. Info: www.softwareautomation.com/

JUnitDoclet: Um es mit den Worten der JUnitDoclet-Entwickler zu beschreiben, dieses Werkzeug vermindert die Schritte bis zum Unit-Test. JUnitDoclet ermöglicht es, sogenannte Skeletons von TestCases zu generieren. Ebenso können TestSuites erzeugt werden, die alle generierten Tests ausführen. Info: www.junitdoclet.org/

NetBeans JUnit Modul: Das JUnit Modul für die NetBeans Plattform kann anhand der zu testenden Klassen Skelette für JUnit Testfälle generieren. Dabei wird für jede, von außen zugängliche Methode, eine leere Testmethode generiert. Pakete können rekursiv bearbeitet werden. Info: junit.netbeans.org/
  Wer auf die kombinierte Lösung gehofft hat, die sich allen Problemen im Bereich Testen stellt, wird vielleicht enttäuscht sein oder noch immer Unsicherheit verspüren, wo denn nun und mit welchem Werkzeug das Testen zu beginnen sei. Um zumindest dem Gefühl Sicherheit zu verschaffen, auch ohne sofortiges Integrieren von Testwerkzeugen etwas zur Qualitätssteigerung zu tun, kann grundlegend der Einsatz eines Bug Tracking Tools wie z. B. BugZilla (bugzilla.mozilla.org), das Arbeiten mit einem Versionsmanagement à la CVS (www.cvshome.org/) und ein einheitlicher Build Prozess, beispielsweise durch Ant (ant.apache.org)gesteuert, eine sinnvolle Maßnahme darstellen. Wenn man dann noch ein funktionales Testbett, z.B. profan mit JUnit, automatisiert mit CruiseControl auslösen kann, hat man bereits eine gewisse Bettschwere erreicht.
Sabine Winkler ist bei der Firma Orientation in Objects GmbH in Mannheim als Entwickler, Berater und Trainer im Bereich Java und XML beschäftigt. Im Bereich J2EE liegen ihre Hauptinteressen bei Servlets, JSPs, JSTL und EJB-Clustering. Ulf Krum ist freiberuflicher Trainer und Berater und bei OIO Seminarverantwortlicher für Test-Seminare.

Links und Literatur

• DevLynx Search - Software Technologies: www.swtech.com/
• GREEN EGGS REPORT for comp.software.testing: www.ar.com/ger/comp/software/testing/content.html
• Open source functional test tools: opensourcetesting.org/functional.htm
• Software Testing & Quality Assurance: www.qalinks.com/Tools/Automated_Testing/
• Web Test-Tools: www.softwareqatest.com/qatweb1.html