Versorgungsprobleme in der EU
Werbung
Datum: 13. Januar 2012 Themendossier Testen mit Open Source Werkzeugen Seite | 1 Testen mit Open Source Werkzeugen Einführung in das Thema Dieses Dossier gibt Software-Entwicklungsunternehmen eine interessante Übersicht über Qualitätssicherungswerkzeuge aus dem Open Source Bereich. In den einleitenden Kapiteln werden die Möglichkeiten von Open Source, die Werkzeugauswahl generell und die Gestaltung eines Testprozesses kurz andiskutiert. Die hier vorgestellten Ergebnisse werden im CSI-Labor (Computer Software Investigation) der Hochschule Osnabrück (http://home.edvsz.fh-osnabrueck.de/skleuker/CSI/index.html) unter Leitung von Prof. Dr. Stephan Kleuker und Projektmitarbeitern erstellt. Wesentliche Arbeiten wurden als Teil des BMBF-Projekts KoverJa (Korrekte verteilte Java-Programme) durchgeführt. Prof. Dr. Stephan Kleuker hat über korrekte Software in Oldenburg promoviert und danach mehrere Jahre als Systemanalytiker sowie Systemberater in der Praxis gearbeitet. Seit 2002 ist er Professor für SoftwareEntwicklung zunächst an der Nordakademie in Elmshorn und der Fachhochschule Wiesbaden, dann seit 2009 an der Hochschule Osnabrück. Die Verknüpfung von praktischen, Forschungs- und Lehrerfahrungen hat er in mehreren Fachbüchern zu den Themengebieten, Software-Engineering, Software-Qualität und Datenbanken festgehalten, die im renommierten Vieweg+Teubner Verlag erschienen sind. Seine Forschungsinteressen liegen in den Themengebieten SW-Qualitätssicherung, Vorgehensmodelle für langfristig erfolgreiche Software-Projekte und aktuelle Java-Technologien für Internet- und mobile Applikationen. Neben der Kooperation in Forschungsprojekten und bei Bachelor- sowie Master-Arbeiten, berät Prof. Dr. Stephan Kleuker Unternehmen mit Projektsachstandsanalysen und individuell konzipierten Optimierungen von Vorgehensmodellen. Seite | 2 Testen mit Open Source Werkzeugen Inhaltsverzeichnis Open Source in Ausbildung und Entwicklung Werkzeugauswahl Testprozess Werkzeuge Seite | 3 Testen mit Open Source Werkzeugen Open Source in Ausbildung und Entwicklung Der wesentliche Unterschied zwischen Open Source Software und anderer Software steht im Namen, so dass der Quellcode für alle Interessierten einsehbar ist. Die weiteren Regeln, wie die Software genutzt werden kann, werden in Lizenzen festgehalten. Die Möglichkeiten gehen von der Variante aus, die Software selbst zu verändern und kommerziell zu vermarkten bis hin zur Notwendigkeit, die neu entstehende Software selbst frei und als Open Source zur Verfügung zu stellen. Das generelle Konzept, Software als freies Werkzeug zu sehen, das allen zur Verfügung steht, und sich nur den kreativen Nutzungs- und Entwicklungsprozess bezahlen zu lassen, muss man für die Entscheidung zur Open Source Nutzung nicht adaptieren (man kann aber ernsthaft darüber nachdenken). Für klassische Unternehmen spielen, wie bei anderer Software, die Lizenzbedingungen und viele weitere Rahmenbedingungen bei der Auswahl eine Rolle. Da es meist für bekanntere Werkzeuge größere Unterstützungsforen und einige Beratungsunternehmen gibt, die die langfristige Nutzbarkeit eines Werkzeugs garantieren, ist Open Source kein KO-Kriterium. Aus Sicht der beruflichen und akademischen Ausbildung stellen Open Source Werkzeuge eine wichtige Möglichkeit dar, neue Qualitätssicherungsansätze zu evaluieren und die Konzepte dahinter zu verstehen, ohne hohe Investitionskosten, oft verknüpft mit langfristig laufenden jährlichen Lizenzkosten, zu benötigen. Werkzeugauswahl Generell ist ein Software-Entwicklungsprozess ohne massive Unterstützung von Werkzeugen als Teil einer Entwicklungsumgebung undenkbar, da sonst sehr viel Zeit in sich wiederholende, monotone Arbeit gesteckt werden muss und Synergien zwischen Projekten kaum nutzbar wären. Die kontinuierliche Verbesserung von Werkzeugen begründet sich zum einen durch die Steigerung der Hardware-Leistung und zum andren durch den Bedarf, Werkzeuge in unternehmensindividuelle Entwicklungsprozesse zu integrieren. Software entwickelnde Unternehmen müssen deshalb zu bestimmten Zeitpunkten klären, ob und wie die gesamte Entwicklungskette verbessert werden kann. Die Werkzeugauswahl im Bereich der Qualitätssicherung unterscheidet sich dabei nicht wesentlich von anderen Bereichen. Zur Auswahl müssen unternehmensindividuelle Kriterienkataloge erstellt werden, die zumindest meistfolgende Punkte umfassen: Anschaffungskosten Fortlaufende Kosten für Lizenzen und Ausbildung Integration in bisher genutzten Entwicklungsprozess Weiterverwendung bisheriger Ergebnisse Seite | 4 Testen mit Open Source Werkzeugen Garantierter Support Bei Qualitätssicherungswerkzeugen, aber auch in anderen Bereichen, muss man neue Innovationen berücksichtigen, so dass ein einfacher Kriterienkatalog bzgl. der geforderten Funktionalität zu restriktiv sein kann. Man muss zunächst die Möglichkeiten analysieren und die Werkzeuge anbieten, die im aktuellen Entwicklungsprozess noch keine Rolle gespielt haben. Diese Innovationsmöglicheit ist in der Abbildung 1 zusammengefasst, welche die von der Ausgangssituation auf der linken Seite nach der Vorauswahl geeigneter Werkzeuge, den Prozess zur Evaluation der Werkzeugmöglichkeiten und die resultierende neue Entwicklungsumgebung auf der rechten Seite veranschaulicht. Abbildung 1: Evaluation innovativer QS-Werkzeuge Im Rahmen des BMBF-geförderten Projekts KoverJa (Korrekte verteilte Java-Programme) werden Werkzeuge für verschiedene QS- und insbesondere Testaufgaben auf ihre Nutzbarkeit und ihre Anwendungsbereiche getestet. Dabei wird die folgende Schablone genutzt. Kriterien zur Analyse von QS-Werkzeugen Name Name des Werkzeugs Homepage Ausgangsseite zur Homepage des Werkzeugs Lizenz Unter welcher Lizenz ist das Werkzeug nutzbar? Untersuchte Version Genaue Angabe der Versionsnummer und der genutzten Dateien Letzter Untersuchungszeitpunkt Wann wurde diese Seite zuletzt besucht? Seite | 5 Testen mit Open Source Werkzeugen Kurzbeschreibung Beschreibung in ein bis vier Sätzen, welche Hauptaufgabe(n) das Werkzeug lösen soll Fazit Ist das Werkzeug für Einsteiger in die Qualitätssicherung nutzbar, lohnt sich der Einstieg in die Einarbeitung für erfahrene Nutzer, gibt es besondere Highlights/Lowlights bei der Nutzung, Dokumentation oder Installation? Wie gut ist das Werkzeug im Vergleich zu Werkzeugen mit vergleichbarer Funktionalität? Einsatzgebiete Wo kann das Werkzeug eingesetzt werden? Gibt es Bereiche, in denen das Werkzeug nicht nutzbar ist? Einsatzumgebungen Kann das Werkzeug ohne andere Werkzeuge benutzt, kann es (zusätzlich) als Plugin in Eclipse oder Netbeans installiert werden? Installation Wie wird installiert, bzw. wo (Link) steht eine Installationsanleitung? Kurze Beurteilung, ob Installation einfach für Programmierer durchführbar, mögliche Kriterien Einfach: Jar-Datei, Installationsprogramm mitgeliefert Aufwändiger: Setzen/Verändern von Systemvariablen, besondere Berücksichtigung von Betriebssystemen Komplex: Abhängigkeit von getrennt zu installierender Software (bei Java kann Java-Installation vorausgesetzt werden) Extrem: Software muss selbst kompiliert werden, es gibt enge Abhängigkeiten von bestimmten Software-Versionen (ok: Java ab Version 5, nicht ok: nur Java 5, nicht Java 6) Dokumentation Macht die Dokumentation für einen Entwickler mit Programmier-, aber wenig bis keiner QSErfahrung einen lesbaren Eindruck, gibt es einen Schnelleinstieg, gibt es die Dokumentation in Deutsch/Englisch, ist sie leicht herunterladbar (z. B. PDF oder/und Teil des Downloads), gibt es besondere Highlights (z. B. Videos). Als gelungen wird eine Dokumentation eingestuft, wenn es einen Kurzeinstieg mit einem prägnanten Beispiel und zusätzlich eine detaillierte Dokumentation gibt. Wartung der Projektseite Machen die Seiten des Werkzeugs den Eindruck, dass sie häufiger gepflegt werden, gibt es eine kontinuierliche Versionsgeschichte, erkennt man, dass neue Features der Umgebung (z. B. Generics und Annotationen in Java) die Entwicklung beeinflussen? Nutzergruppen und Support Gibt es eine detaillierte Fragen- und Antwortseite, gibt es Foren und Nutzergruppen zur Diskussion über das Werkzeug? Gibt es eine E-Mail-Adresse für Anfragen und Kommentare? Intuitive Nutzbarkeit Kann sich ein erfahrener Entwickler anhand der Dokumentation leicht einarbeiten, kann er schnell zu eigenen Beispielen kommen? Werden besondere Fähigkeiten bzw. Kenntnisse gefordert? Gab es besondere Beobachtungen bei der Einarbeitung? Seite | 6 Testen mit Open Source Werkzeugen Automatisierung Kann das Werkzeug ohne einen Nutzer nach einem Start laufen, werden die gewonnenen Ergebnisse lesbar aufbereitet (z. B. HTML-Export), kann der Nutzungsprozess einfach automatisiert werden (z. B. mit Shell-Skripten oder als Ant-Task, Integration in Maven oder Jenkins)? Einführendes Beispiel Möglichst kurzes, einfaches eigenes Beispiel, das die wesentlichen Funktionalitäten dokumentiert. Die Evaluation wird in Rahmen von Kooperationen mit Unternehmen und Forschungsprojekten kontinuierlich aktualisiert und erweitert. Ergebnisse sind unter http://home.edvsz.fh- osnabrueck.de/skleuker/CSI/Werkzeuge/kombiQuWerkzeuge.html einsehbar. Generell ist bei einer Analyse zu beachten, dass ein Werkzeug selten alle zu testenden Varianten unterstützt. Wichtig ist es dann, dass man die testbaren Bereiche eindeutig identifiziert und so die Anzahl manueller Tests wesentlich reduzieren kann. Testprozess Neben den einzelnen Werkzeugen für Teilbereiche spielt auch das Zusammenspiel der Werkzeuge eine Rolle. Dabei soll es möglich sein, dass die Werkzeuge völlig automatisiert (z. B. nachts) ablaufen. Dazu muss ein Steuerungswerkzeug die Ergebnisse der einzelnen Werkzeuge aufbereiten (z. B. Reporte) und es müssen die Ergebnisse zur Steuerung (z. B. Abbruch eines Tests oder Benachrichtigungen an Entwickler) genutzt werden können. Zur Steuerung selbst können einfache Skripte wie Ant (http://ant.apache.org/) oder auch komfortablere Ablaufsteuerungen wie Maven (http://maven.apache.org/), die z. B. auch die Aktualisierung benötigter Bibliotheken berücksichtigen, genutzt werden. Insgesamt ist es sinnvoll, den gesamten Build-Prozess für die Software über ein zentrales Werkzeug, wie z. B. Jenkins (http://jenkins-ci.org/), zu steuern, in das die Qualitätssicherung eingebunden wird. Weiterhin kann es sinnvoll sein, ein Tracking Werkzeug einzusetzen, das kontinuierlich verschiedene Projektmetriken u. a. auch aus dem Qualitätssicherungsbereich (Metriken, Testüberdeckung) visualisiert. Eine solche erweiterbare (http://www.sonarsource.org/) gegeben. Seite | 7 Testen mit Open Source Werkzeugen Möglichkeit ist mit Sonar Werkzeuge Die folgende Werkzeugsammlung stellt die Werkzeuge bzgl. ihrer Funktionalität eingeordnet vor. Obwohl diese Sammlung schon recht mächtig ist, können durch die vielen innovativen Ansätze aber nicht alle Werkzeuge aus dem Open Source Bereich erfasst werden. Für die hier genannten Werkzeuge wurde festgestellt, dass sie zumindest relevante Teilaufgaben sehr gut lösen können. Funktionstest Der Funktionstest (Unit-Test) ist die Grundlage der meisten Entwicklungen und wird meist vom Entwickler selbst durchgeführt. Alle Werkzeuge eigenen sich dabei nicht nur zum Test einzelner Klassen, sie können auch Zusammenhänge testen. Häufiger bauen Testwerkzeuge für Spezialaufgaben auf den Werkzeugen auf. JUnit 4.x (http://www.junit.org/): JUnit wurde zum Testen von Java-Programmen entwickelt. Mit dem Tool lassen sich automatisierte Unit-Tests einzelner Klassen, Methoden oder Testsuiten (Zusammenfassungen mehrerer Tests) durchführen. JUnit liefert bei seinen Tests zwei Ergebnisse: Test fehlerfrei durchlaufen (grün), Test mit Fehler abgebrochen (rot). JUnit ist de Facto in alle Entwicklungsumgebungen integriert und muss zum Erfahrungsschatz eines jeden Java-Entwicklers gehören. TestNG (http://www.testng.org/): TestNG ist ein Frameset zum Erstellen von Unittests. Damit ist es ein direkter Konkurrent zu dem etablierten JUnit und bietet etwas mehr Funktionalität, bei der Erstellung von Massentests basierend z. B. auf Excel-Dateien. Ein wesentlicher Beitrag von TestNG ist es, dass es als Konkurrent die Weiterentwicklung von JUnit vorantreibt. Überdeckungstest Mit Überdeckungstests wird festgestellt, welche Teile des zu testenden Programms durch Tests ausgeführt werden. Es können verschiedene Arten von Überdeckungen unterschieden werden. Generell gilt, dass zunächst das Hauptaugenmerk auf den Tests der typischen Funktionalität liegen sollte und man danach eine möglichst vollständige Überdeckung anstreben kann. CodeCover (http://www.codecover.org/): CodeCover ist ein Überdeckungstool für die Programmiersprachen Java und Cobol. Die Software unterstützt Statement-, Branch- und Schleifenabdeckungen. Das Programm kann auf zwei verschiedene Arten genutzt werden, als Eclipse-PlugIn oder als Standalone-Anwendung für Linux und Windows. Zusätzlich verfügt es über ein CLI-Interface zur Nutzung der Konsole und ein Ant-Interface für die Integration in existierende Build-Prozesse. CodeCover ermöglicht eine volle Integration von JUnit, eine LiveAnzeige für eine manuelle Testfallerkennung, einen Boolean Analyzer und eine Korrelationsmatrix zum Finden und Vergleichen von Testfällen. Eclemma (http://www.eclemma.org/): EclEmma ist ein Eclipse Plugin, das die Zweigüberdeckung (C1) für jede Zeile anzeigt, indem es überprüft, welche Programmteile durchlaufen wurden. Ausgeführt werden können Eclipse/RCP-Applications, JUnit-Tests, JUnit-Plugin-Tests, Seite | 8 Testen mit Open Source Werkzeugen TestNGTests, Equinox OSGi Frameworks sowie lokale Java-Anwendungen. Zum Starten wird einfach eine vorhandene oder neue Run-Konfiguration als „Coverage“ gestartet. Angezeigt wird anschließend, welcher Teil des Codes abgearbeitet wurde und welcher nicht. EclEemma (Eclipse Emma) basiert dabei auf Emma (http://emma.sourceforge.net/) und bindet dessen Funktionalität für einen schnellen und einfachen Zugriff in Eclipse ein. Emma bietet im Wesentlichen die gleiche Funktionalität, kann aber auch von der Kommandozeile aus bzw. in Ant oder Maven integriert genutzt werden. Cobertura (http://cobertura.sourceforge.net/): Cobertura ist ein Code Überdeckungswerkzeug für die C0- und C1-Überdeckung. Es misst die prozentuale Abdeckung von Programmcode und gibt Testern die Möglichkeit, mit der Testabdeckung unzureichend getestete Stellen zu finden. Das Werkzeug ist für Einsteiger relativ einfach nutzbar, wobei die Benutzung über Ant-Tasks oder Kommandozeile nicht so intuitiv ist, wie bei dem Werkzeug CodeCover. Die Besonderheiten von Cobertura sind übersichtliche, ausführliche Berichte, die im Gegensatz zu dem vergleichbaren Werkzeug Emma auch die Anzahl der Durchläufe einer Codezeile anzeigen. Das Layout der Berichte erinnert stark an Javadoc. Eine weitere interessante Eigenschaft, die Cobertura von anderen Werkzeugen abhebt, ist die Möglichkeit, in der ANT-Task eine Prozentzahl für die Überdeckung festzulegen, die nicht unterschritten werden darf. Somit sind Entwickler dazu gezwungen, bei Erweiterungen der Software auch gleich Tests zu schreiben. Diese Eigenschaften machen das Werkzeug auch interessant für fortgeschrittene Benutzer. Coverlipse (http://coverlipse.sourceforge.net/index.php): Einfacher Anweisungsüber- deckungstest, der für gegebene JUnit-Tests in Eclipse überprüft, welche Anweisungen überdeckt werden. Weiterhin ist überprüfbar, ob Zuweisungen im späteren Code genutzt werden. Es wird anscheinend nur sporadisch weiterentwickelt und kann keine anderen Überdeckungen berechnen. Aus diesem Grund sind die anderen auf der Werkzeug-Seite genannten Werkzeuge vorzuziehen. Tests von Oberflächen Generell ist der Ansatz, ähnlich zum Endnutzer, eine Software über die Oberfläche zu nutzen und diese Tests automatisiert wiederholbar zu machen. Dazu können im Wesentlichen zwei Werkzeugarten genutzt wurden. Die erste Art verhält sich wie der Endnutzer und klickt wie dieser auf der Oberfläche und füllt Textfelder aus. Die zweite Art kennt den internen Aufbau und kann so Elemente der Oberfläche direkt aus der Software heraus ansprechen. Während die erste Art sich meist nutzerverwandter verhält und die Testerstellung recht zügig erfolgen kann, sind Tests der zweiten Art unempfindlicher gegenüber kleinen Änderungen der Oberfläche wie z. B. einem neuen Layout. Marathon (http://marathontesting.com/Home.html): Marathon ist ein Tool zum Testen von grafischen Benutzeroberflächen, basierend auf Java Swing. Bei diesem Tool muss der Tester keinen Testcode schreiben, sondern es kann mit Hilfe des Recorders die Nutzerinteraktion auf der grafischen Benutzeroberfläche aufgenommen werden. Während des Aufnahmemodus besteht die Möglichkeit, sogenannte Assertions einzufügen, um zu überprüfen, ob eine Aktion Seite | 9 Testen mit Open Source Werkzeugen auf der Oberfläche korrekt ausgeführt wurde. Marathon speichert das aufgenommene Szenario als JRuby oder Jython Code. Marathon ist ein sehr gutes Programm, für ein schnelles, effektives und automatisiertes Testen kleinerer bis mittlerer GUI-Projekte. Ein sehr großer Vorteil ist der Skript-Recorder, mit dem Nutzerinteraktionen auf der Oberfläche aufgezeichnet werden können. Während der Aufnahmephase können einfach Überprüfungen per Mausklick eingefügt werden, welche Eingaben oder Änderungen am UI verifizieren und auf Korrektheit überprüfen. Es müssen keine Tests von Hand implementiert werden, was einen Vorteil für eher unerfahrene Tester bedeutet. Mit Marathon lassen sich schnelle und gute Testergebnisse erzielen, da die Skripte bequem durch Mausklicks zusammengefügt werden können. Die Entwicklungs- und Testumgebung von Marathon ist sehr strukturiert. Das Layout ist an bekannte Entwicklungsumgebungen angelehnt. Ein weiterer Pluspunkt ist, dass aufgenommene Skripte nachträglich von Hand mit der Programmiersprache JRuby bzw. Jython verändert und ergänzt werden können. Es ist allerdings zu erwarten, dass die Hersteller versuchen werden, Marathon in Folgeversionen zu verkaufen. Da eine Lizenz für ein ausgegebenes Produkt nicht nachträglich geändert werden kann, betrifft dies nicht vor der Lizenzänderung erhaltene Versionen. Google WindowTester Pro (http://code.google.com/intl/en/javadevtools/wbpro/index.html): Mit dem Google WindowTester Pro können auf Swing, SWT oder Eclipse/RCP basierende Benutzeroberflächen von Java Programmen getestet werden. Darüber hinaus gibt es die Möglichkeit einfacher Überdeckungstests. Der WindowTester wird als Plugin in die Eclipse IDE integriert. Die Tests werden auf Basis von JUnit 3 geschrieben. Eine Unterstützung von JUnit 4 ist zurzeit noch nicht gegeben, befindet sich aber laut Hersteller in der Entwicklung. Zur einfachen Erstellung von Tests gibt es einen Recorder. Dabei werden die Eingaben und Klicks auf der Benutzeroberfläche aufgezeichnet und hieraus dann automatisch ein Test generiert. Zusammen mit den Programmen WindowBuilder Pro (GUIEntwicklungswerkzeug) und CodePro AnalytiX (Codeanalyse-Tool) wurde die Software bis September 2010 von der Firma Instantiatons entwickelt und kommerziell vertrieben, dann wurden die Tools von Google aufgekauft und stehen seitdem kostenlos zum Download bereit. Sikuli (http://sikuli.org/): Sikuli ist ein Werkzeug zum automatisierten Zugriff auf grafische Benutzeroberfläche mittels Bildern, die definieren, an welchen Stellen Nutzeraktionen stattfinden sollen. Mit einem Script kann Benutzerverhalten simuliert werden. Sikuli kann zum Automatisieren von Oberflächentests einer Webseite, eines Desktop-Programms oder aber auf mobilen Endgeräten eingesetzt werden. Es stehen für Mac OS X, Windows und Linux Entwicklungsumgebungen zur Verfügung. Außerdem kann Sikuli mit Hilfe der Bibliothek 'sikuli-script.jar' in Java Programmen ausgeführt werden. Die Entwicklung von Sikuli befindet sich noch am Anfang, das Konzept wirkt aber sehr durchdacht und die praktische Nutzbarkeit ist gegeben, so dass die Weiterentwicklung des Werkzeugs genauer verfolgt werden sollte. Selenium (http://seleniumhq.org/): Selenium ist ein skriptbasiertes „Capture and Replay“Testwerkzeug, mit der Möglichkeit zum Exportieren der Testfälle in andere Skript- und Programmiersprachen. Es wird zum funktionsorientierten Testen von Webseiten und Webapplikationen entwickelt (Blackbox-Tests). Mit Hilfe dieses Werkzeugs, kann man u. a. Eingaben und Interaktionen (Links anklicken usw.) aufzeichnen, um diese als automatisiert wieder- Seite | 10 Testen mit Open Source Werkzeugen holbare Tests abzuspeichern. Auf diese Weise aufgezeichnete Tests können anschließend modifiziert und abgespielt werden. Selenium ist im Bereich des Tests von Web-Applikationen sehr weit verbreitet. Einschränkungen gibt es, wenn die Eingabefelder keine eindeutigen ID-Werte erhalten und so nicht (einfach) wieder identifiziert werden können. FEST (http://code.google.com/p/fest/): FEST nutzt als Grundlage TestNG oder JUnit. Es werden die User-Interaktionen auf der Oberfläche simuliert und abgefragt. Zum Testen der Oberflächen werden sogenannte Fixtures angelegt, die eine Schnittstelle zu den nativen JavaSwing-Komponenten zur Verfügung stellen, um diese entsprechend zu testen. Generell muss dabei eine GUI-Komponente, z. B. durch einen in Java vergebenen Namen, eindeutig identifizierbar sein, damit sie bspw. aus einem JUnit-Test heraus angesprochen werden kann. Jubula (http://eclipse.org/jubula/): Jubula ist in die Eclipse-Entwicklungsumgebung integriert, somit gibt es die Möglichkeit, über den Eclipse Marketplace Plug-Ins zu beziehen. Es muss beachtet werden, dass eine zusätzliche Software, der AUT-Manager, parallel zu Jubula gestartet wird und Jubula mit diesem verbunden ist. Die Testfälle werden aus einzelnen, vorgefertigten und konfigurierbaren Bausteinen zusammengesetzt und bilden eine übersichtliche Ablaufstruktur, die zusätzlich, durch Vergabe von optionalen Namen, lesbarer gemacht werden kann. Jubula stellt die Möglichkeit zur Verfügung, die angebotenen Bausteine zu erweitern sowie externe Konsolenbefehle auszuführen, und setzt einige gute Ideen bezüglich der Wartbarkeit von Testfällen um. Nach dem Prinzip des „Keyword-Driven Testing“ werden Tests vollständig aus wiederverwendbaren und konfigurierbaren Blöcken zusammengestellt und sind somit sowohl gut lesbar, als auch einfach zu pflegen. Mock-Erstellung Sollen nur aufwändig verwertbare Ressourcen genutzt werden oder liegt eine Teilsoftware für Tests noch nicht vor, müssen diese möglichst einfach und im Verhalten realistisch nachgebildet werden. Hierfür werden Mocks angeboten, die meist in Form von Frameworks als Bibliotheken vorliegen. Mockito (http://mockito.org/): Mockito ist ein Framework zum Erstellen und Benutzen von simplen Mocks in Softwaretests. Es bietet die Möglichkeit, Verhalten von noch nicht implementierten Klassen und Methoden rudimentär zu simulieren, um so das zu testende System, trotz fehlender Teile, testen zu können. Mockito ist einfach in der Anwendung und kommt für die meisten Aufgaben mit nur wenigen Zeilen Code aus. Diese Eigenschaften machen das Framework sowohl für Einsteiger als auch für Fortgeschrittene interessant. Es legt den Schwerpunkt auf unkomplizierte, intuitive Schnittstellen und überschaubare Funktionsvielfalt, weshalb die Einarbeitungszeit besonders kurz ist und Tests teilweise leserlicher und kürzer ausfallen als bei ähnlichen Frameworks, z. B. JMock und EasyMock. JMock (http://www.jmock.org/): JMock ist eine Bibliothek zur testgetriebenen Softwareentwicklung. Dabei werden sogenannte Mock-Objekte als Dummy-Objekte verwendet. Die MockObjekte werden als Platzhalter für echte Objekte innerhalb von Unit-Tests verwendet. Die Mock-Objekte implementieren dabei die Schnittstellen, über die das zu testende Objekt auf Seite | 11 Testen mit Open Source Werkzeugen seine Umgebung zugreift. Mocks stellen dabei sicher, dass die erwarteten Methoden vollständig, mit den korrekten Parametern und in der richtigen Reihenfolge aufgerufen bzw. durchgeführt werden. EasyMock (http://www.easymock.org/): EasyMock erlaubt es ebenfalls, Methoden zu testen, die auf noch nicht ausprogrammierte Klassen zugreifen. Hierbei muss die zu testende Methode anstatt einer Klasse ein Interface erwarten. Anstatt einer ausprogrammierten Klasse bekommt sie dann einen mit EasyMock zur Laufzeit erstellten Mock zur Nutzung. Da dieser Mock natürlich nicht die volle Programmlogik bietet, welche die ausprogrammierte Klasse später einmal bieten soll, wird innerhalb des TestCases definiert, wie der Mock auf genau diesen einen Fall reagieren soll. Ebenfalls lässt sich mit EasyMock testen, ob der Aufruf der Mockmethode überhaupt stattgefunden hat, so dass hier schon Programmierfehler aufgespürt werden können. Laufzeit Neben der funktionalen Korrektheit spielt auch die Effizienz, d. h. die möglichst schnelle Reaktion der zu testenden Software oft eine sehr wichtige Rolle. Werkzeuge in diesem Bereich messen Laufzeiten und geben teilweise bis auf Ebene einzelner Methoden an, an welcher Stelle wie viel Zeit verbraucht wurde. Netbeans Profiler (http://profiler.netbeans.org/): Der Netbeans Profiler ist ein in Netbeans integrierter, umfangreicher Profiler für Java-Applikationen. Er ist in folgende drei Bereiche unterteilt: Monitor Application (Basic JVM Monitoring), Performance Analysis, Memory Analysis. Außerdem kann optional noch Thread Monitoring aktiviert werden. Die Stärken des Netbeans Profilers sind seine intuitive Nutzung, graphische Aufbereitung und einfache Konfigurierbarkeit. JRat (http://jrat.sourceforge.net/): JRat ist ein einfach zu handhabendes Tool zur Laufzeitanalyse von beliebigen Java-Programmen. Es ist sehr praktisch für einen schnellen und unkomplizierten Einsatz. Eine aufwändige Installation ist nicht nötig. Die Dokumentation ist zwar sehr knapp gehalten, aber völlig ausreichend. Da das Tool im Funktionsumfang relativ eingeschränkt ist, bietet es allerdings kaum Möglichkeiten für flexible Anpassungen. Im Zusammenhang mit der Laufzeit- und Speicherverbrauchsanalyse ist unbedingt das Eclipse Projekt TPTP (Eclipse Test & Performance Tools Platform, http://www.eclipse.org/tptp/) zu beachten, in dem Ansätze zunächst getrennt entwickelter Test-Werkzeuge integriert werden. Da die Teilwerkzeuge unterschiedlich weit in der Entwicklung waren, ergibt sich noch kein homogenes Bild einer Test-Suite. Da die Werkzeuge aber auch getrennt eingesetzt werden können, ist eine genauere Betrachtung sehr sinnvoll. Seite | 12 Testen mit Open Source Werkzeugen Speicherverbrauch Ähnlich zur Laufzeit muss die zu testende Software immer einen maximalen und auch in Standardsituationen nachvollziehbaren Speicherverbrauch garantieren, der mit den genannten Werkzeugen wieder evaluiert werden kann. Netbeans Monitor Application als Teil des NetBeans Profiler Toolkits (s. Werkzeuge zur Laufzeitbetrachtung) HPROF (http://java.sun.com/developer/technicalArticles/Programming/HPROF.html): HPROF ist ein kleines Profiling-Tool, das seit der Version 5.0 fest in Java integriert ist. Das Tool wird zusammen mit dem zu testenden Java-Programm über die Kommandozeile gestartet. Anhand von Optionsparametern können zusätzlich die Bereiche festgelegt werden, auf welche während des Profiling-Vorgangs reagiert werden soll. Wird das Java-Programm beendet, erzeugt HPROF eine Textdatei, in welcher alle wahrgenommenen Ereignisse gespeichert werden. Statistische Quellcode-Analyse Mit Werkzeugen zur Quellcode-Analyse kann der gegebene Programmcode auf verschiedene Eigenschaften, z. B. die korrekte Formatierung, aber auch die Komplexität der Software, untersucht werden. Zur Quellcode-Analyse, insbesondere zum Aufstellen oder Nutzen vorgegebener Regeln, sei auf die folgenden vier Werkzeuge hingewiesen, die sich in ihrer Funktionalität nur teilweise überschneiden. Alle Programme sind als Eclipse-Plug Ins, aber auch ohne Oberfläche nutzbar, was sie in Ant und Maven integrierbar macht. Außer in Lint4J können eigene Regeln programmiert werden. CheckStyle (http://checkstyle.sourceforge.net/index.html) FindBugs (http://findbugs.sourceforge.net/) PMD (http://pmd.sourceforge.net/) Lint4j (http://www.jutils.com/) Zur expliziten Berechnung verschiedener Metriken kann folgendes Werkzeug genutzt werden: Metrics (http://metrics.sourceforge.net/): Metrics ist ein Eclipse Plug In, um in Java-Projekten Projektkennzahlen zu ermitteln. Dazu zählen Klassiker wie die „Lines of Code“ und die zyklomatische Zahl nach McCabe, aber auch Ansätze in Richtung Objektorientierung, wie die „Abstractness“, der Grad wie weit die Software abstrakt und daher wiederverwendbar ist. Die Ausgabe kann direkt in Eclipse angezeigt, aber auch als XMLDatei ausgegeben werden, um sie in andere Dokumente/Anwendungen einzubinden oder einfach nur zu archivieren. Da das Plug In seit Eclipse 3.1 nicht weiter entwickelt wird, ist zu erwarten, dass es ab Eclipse 4.x nicht mehr funktioniert. Seite | 13 Testen mit Open Source Werkzeugen Tests für datenbankbasierte Programme Wird eine Datenbank für die Persistenz genutzt, muss auch ihre korrekte Nutzung überprüft werden. Eine zentrale Herausforderung ist es dabei, die Datenbank immer wieder in den gleichen Ausgangszustand zu versetzen. DbUnit (http://www.dbunit.org/): DbUnit setzt auf JUnit auf und erweitert es um die Fähigkeit, mit relationalen Datenbanken umzugehen. Mit Hilfe von DbUnit können Datenbanken vor dem Ausführen von Tests in einen bekannten Zustand versetzt werden, damit die einzelnen Tests sich nicht gegenseitig beeinflussen. Außerdem bietet DbUnit die Funktionalität, Datensätze aus- und einzulesen sowie miteinander zu vergleichen. Jailer (http://jailer.sourceforge.net/home.htm): Jailer unterstützt den Aufbau von Testdatenbanken für Softwaretests, indem aus Datenbanken mit umfangreichen Datensätzen und komplexen Datenmodellen Teilmengen der Datensätze exportiert werden, ohne die Abhängigkeiten zu verletzen. Außerdem erlaubt Jailer die Visualisierung von Tabellen sowie deren Beziehungen und bietet weitere GUI Unterstützung bei der Analyse und Modellierung von Datenbanken. Unitils (http://www.unitils.org/summary.html): Unitils vereint verschiedene Frameworks aus Bereichen wie Unit-Testing, Mocking und Persistenz zu einem Gesamtpaket von Modulen und vereinheitlicht deren Benutzung. Es bietet damit eine sinnvolle und umfangreiche Kombination von Frameworks, die einen Großteil der üblichen Abläufe bei Unit-Tests von Software abdecken. Es erleichtert den kombinierten Einsatz der verschiedenen Werkzeuge durch ein einheitliches Bedienungs- und Konfigurationskonzept. Im Gegensatz zur gemeinsamen Benutzung von einzelnen Frameworks im selben Projekt, muss sich der Benutzer bei Unitils keine Gedanken über Konflikte zwischen den angebotenen Modulen machen. Diese Eigenschaften machen Unitils sowohl für Einsteiger als auch erfahrene Tester interessant. Tests für JavaServer Faces (JSF) Mit JSF können recht einfach Web-Applikationen entstehen, die eine saubere Trennung zwischen Oberfläche und Anwendung ermöglichen. JSFUnit (http://www.jboss.org/jsfunit/): JSFUnit ist ein Testframework für JSF Applikationen. Es wurde entwickelt, um Integrations- und Unittests von JSF Applikationen mit Hilfe eines Frameworks zu vereinfachen. JSFUnit Tests werden im Container ausgeführt, was ihnen vollen Zugriff auf die Managed Beans, den FacesContext, EL Expressions und den internen JSF Komponentenbaum ermöglicht. Apache JMeter (http://jakarta.apache.org/jmeter/): Apache JMeter ist eine Open-Source Java Applikation. Es lassen sich Lasttests auf verschiedenen Ressourcen durchführen und folgende Protokolle werden unterstützt: - HTTP, HTTPS, SOAP, Datenbank via JDBC, LDAP, JMS, Mail POP3(S) and IMAP(S). JMeter benötigt eine Java Virtual Machine 1.5 oder höher. Es ist eine Stand-Alone Applikation, welche auf einem beliebigen Betriebssystem läuft. Es gibt verschie- Seite | 14 Testen mit Open Source Werkzeugen dene Möglichkeiten JMeter auszuführen: GUI Mode, Non-GUI Mode, Server Mode. Der ServerMode ist z. B. für verteiltes Testen interessant. Weiterhin sei hier auf die für GUIs vorgestellten Testwerkzeuge Silenium und Sikuli hingewiesen. Seite | 15 Testen mit Open Source Werkzeugen Impressum Autor Prof. Dr. Stephan Kleuker Hochschule Osnabrück E-Mail: [email protected] Feedback Uns interessiert Ihre Meinung! Haben Sie Fragen, Anregungen oder Anlass zur Kritik? Bitte senden Sie Ihre Kommentare an: Sven Seiffert Telefon: +49 (0) 341 124 55 60 E-Mail: [email protected] Abmeldung Sie wollen dieses Dokument in Zukunft nicht mehr empfangen? Senden Sie uns einfach eine E-Mail mit einer kurzen Nachricht an: [email protected] Zugangsdaten für www.softwareforen.de Sehr gern richten wir für Sie Zugangsdaten für unseren passwortgeschützten Bereich "Wissen" ein (für unsere Partnerunternehmen; für andere Unternehmen sind Probezugänge möglich). Senden Sie uns einfach eine E-Mail mit einer kurzen Nachricht an [email protected] Seite | 16 Testen mit Open Source Werkzeugen Softwareforen Leipzig GmbH Querstraße 16 | 04103 Leipzig | T +49 (0)341 / 1 24 55 - 0 | F +49 (0)341 / 1 24 55 - 99 | E [email protected] | I www.softwareforen.de Seite | 17 Testen mit Open Source Werkzeugen
