Testwerkzeuge
Transcription
Testwerkzeuge
Seminar in Software Engineering und Software-Qualitätsmanagement Thema: Messen und Prüfen von Software Testwerkzeuge Markus Dommann [email protected] Prof. Dr. Martin Glinz Betreuer: Christian Seybold 13.11.2001 Zusammenfassung Diese Seminararbeit befasst sich mit Testwerkzeugen. Es soll aufgezeigt werden warum Tests überhaupt automatisiert werden sollten. Des weiteren wird eine Übersicht gegeben, was für Testwerkzeuge überhaupt vorhanden sind und in welchen Phasen des Testens sie Anwendung finden. Einige am Markt erhältliche Testwerkzeuge werden mit ihren Fähigkeiten kurz vorgestellt. INHALTSVERZEICHNIS 1 Inhaltsverzeichnis 1 Einführung 2 Welche Testwerkzeuge für welche Aufgaben? 2.1 Werkzeuge für Reviews und Inspektionen . . 2.2 Werkzeuge zur Planung von Tests . . . . . . . 2.3 Testdesign und -entwicklung . . . . . . . . . . 2.4 Testausführung und -auswertung . . . . . . . 2.5 Support-Werkzeuge beim Software-Testen . . 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2 2 3 3 4 3 Warum überhaupt Tests automatisieren 4 4 Unit-Testing 4.1 Ein Beispiel für Unit-Testing: JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Arbeitsweise von JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 6 5 GUI-Testing 5.1 Mögliche Probleme beim GUI-Testen . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Ein Beispiel für Capture/Replay: WinRunner . . . . . . . . . . . . . . . . . . . . . 8 9 9 6 Weitere Testwerkzeuge 6.1 JTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2 McCabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 10 12 7 Fazit 13 1 EINFÜHRUNG 1 2 Einführung Testen ist ein Gebiet der Software-Entwicklung, das häufig vernachlässigt wird. Es zeigt sich jedoch, dass durch Testen von Software viele Unannehmlichkeiten verhindert und die Kosten der Softwareentwicklung gesenkt werden können. Eine grosse Anzahl an Werkzeugen kann bei der Planung, Ausführung und Auswertung von Tests eine grosse Hilfe sein. Der nachfolgende Text soll einen kurzen Einblick in die Welt der Testwerkzeuge vermitteln. 2 Welche Testwerkzeuge für welche Aufgaben? Je nach Testtätigkeit gibt es verschiedene Werkzeuge, welche die Arbeit unterstützen können. Edward Kit [1] gliedert die Werkzeuge nach folgenden Tätigkeiten: • Reviews und Inspektionen • Planung von Tests • Testdesign und -entwicklung • Testausführung und -auswertung • Supportwerkzeuge beim Testen von Software 2.1 Werkzeuge für Reviews und Inspektionen Bei Reviews und Inspektionen können Werkzeuge auf unterschiedliche Weise die Arbeit unterstützen: Durch Komplexitätsanalyse können sie Aufschluss darüber geben, welche Bereiche des Programms bei Inspektionen und Tests spezieller Aufmerksamkeit bedürfen. Bereiche mit hoher Komplexität können durch die Anzahl Entscheidungen in einem Programm oder anderen Metriken ausfindig gemacht werden. Bei der Planung von Tests kann die Komplexitätsanalyse Hinweise darauf geben, wieviel Testen nötig ist. Werkzeuge helfen uns unbekannten Code besser zu verstehen. Sie können Abhängigkeiten verstehen helfen, die Programmlogik verfolgen, graphische Repräsentationen des Programms anzeigen und toten Code identifizieren. Bei der Vorbereitung für eine Code-Inspizierung können solche Werkzeuge die Arbeit erleichtern. Werkzeuge zur Syntax- und Semantikanalyse führen intensive Fehlerprüfung am Code durch um Fehler zu finden, die ein Compiler übersehen würde. Diese Werkzeuge sind sprachabhängig. Sie parsen Code, unterhalten eine Fehlerliste und bieten weitere Informationen. Der Parser kann sowohl semantische Fehler finden, als auch Rückschlüsse darauf ziehen was syntaktisch inkorrekt ist. 2.2 Werkzeuge zur Planung von Tests Der Zweck der Planung von Tests ist es, Umfang, Methode, Ressourcen (inklusive Werkzeuge) und Zeitplanung des Testens festzulegen. Die wahrscheinlich grösste Hilfe in diesem Bereich kommt von Standards. Der IEEE/ANSIStandard für Softwaretest-Dokumentation 1 beschreibt den Zweck, Umfang und den Inhalt eines Testplans. Diese Standards werden von vielen Firmen benutzt indem sie Vorlagen für TestDokumentation erstellen, die auf diesem Standard beruhen. Werkzeuge, die bei der Vorbereitung von Reviews und Inspektionen helfen, sind auch bei der Planung von Tests von Nutzen. So helfen z.B. Werkzeuge zur Komplexitätsanalyse Bereiche zu identifizieren, welche die Planung zusätzlicher Tests durch Risikoanalyse beeinflussen. Des weiteren werden Werkzeuge zur Personal- und Zeitplanung verwendet. 1 IEEE 829-1998 2 WELCHE TESTWERKZEUGE FÜR WELCHE AUFGABEN? 2.3 3 Testdesign und -entwicklung Das Testdesign – das Anwendens des Testplans auf die konkrete Software und das Erkennen und Priorisieren von Testfällen – wird kaum von Werkzeugen unterstützt. Hingegen können bei der Testentwicklung – dem Umsetzen des Testdesigns in konkrete Testfälle – Werkzeuge benutzt werden, die auch bei der Testausführung und -auswertung Anwendung finden (siehe Abschnitt 2.4). So z.B. bieten Capture/Replay-Werkzeuge Unterstützung bei der Entwicklung von Testfällen. Ausserdem kommen Werkzeuge zum Generieren von Testdaten zum Einsatz. Diese automatisieren das Erzeugen von Testdaten nach benutzerdefinierten Vorgaben. Sie können z.B. alle Permutationen einer spezifischen Eingabe generieren. 2.4 Testausführung und -auswertung Testausführung und -auswertung beinhalten das Auswählen von Testfällen, das Aufsetzen der Umgebung, das Ausführen der Tests, das Aufzeichnen der Ausgaben, das Analysieren möglicher Fehler und das Messen des Fortschritts. Mit Capture/Replay Werkzeugen automatisieren Tester die Ausführung von Tests. Capture/Replay Werkzeuge zeichnen Benutzeroperationen (Eingaben per Tastatur und Maus) und Ausgaben auf. Das Werkzeug kann dann die zuvor aufgezeichneten Tests wann immer nötig wiederholen und die Resultate validieren, indem sie mit den aufgezeichneten und vom Tester validierten Ergebnisse verglichen werden. Capture/Replay-Werkzeuge können in native und nicht eindringende (non-intrusive) Werkzeuge unterteilt werden. Bei nativen (auch intrusive) Werkzeugen befinden sich das Werkzeug und die zu testende Software im gleichen System. Die Performance des Systems wird durch das Werkzeug in gewissem Rahmen beeinträchtigt. Die non-intrusive Form von Capture/Replay benötigt ein zusätzliches Hardware-System als Testwerkzeug. Üblicherweise hat das Host-System, welches die zu testende Software enthält, eine spezielle Hardware-Verbindung zum Capture/Replay-Werkzeug. Diese Verbindung erlaubt dem Capture/Replay System seine Funktion für das Host-System transparent durchzuführen. Die häufigste Form von Capture/Replay ist native, weil sich der Aufwand von non-intrusive Hardware Lösungen nur in speziellen Situationen rechtfertigt (z.B. Real-Time-Systeme). Werkzeuge zur Coverage Analyse können die Qualität von Tests quantitativ messen. Mit ihrer Hilfe kann herausgefunden werden, ob die Software gründlich getestet wird. Sie sagen uns welche Teile des Produkts durch Tests ausgeführt wurde. Es gibt verschiedene Arten von Coverage. Darunter Statement-, Decision-, Condition-, Decision/ Condition-, Multiple Condition- und Path-Coverage. Im Minimum sollte sichergestellt werden, dass jedes Statement des Programms und jede Entscheidung für alle möglichen Ergebnisse mindestens einmal ausgeführt wurde. Bound Checkers, Memory Testers, Runtime-Error Detectors oder Leak Detectors können unter anderem entdecken, ob Speicherprobleme bestehen, Arraygrenzen überschritten werden, Speicher alloziiert aber nicht freigegeben oder uninitialisierter Speicher gelesen und benutzt wird. Solche Werkzeuge sind meist sprach- und plattformabhängig. Es gibt aber auch non-intrusive, einfach benutzbare Werkzeuge dieses Typs. Werkzeuge zum Verwalten von Testfällen erlauben auf einfache Weise den Überblick über die erstellten Testfälle zu halten. Mit ihnen können Tests verwaltet und gestartet werden. Sie bieten eine nahtlose Einbettung von Werkzeugen für Capture/Replay und Coverage Analyse. Ausserdem können mit ihrer Hilfe die Erstellung von Testberichten und -dokumentation automatisiert werden. Simulatoren treten an die Stelle von Soft- und Hardware die mit dem zu testenden System interagiert. Manchmal sind sie die einzige praktikable Möglichkeit, die für Tests zur Verfügung steht. Z.B. wenn Software mit unkontrollierbarer oder nicht verfügbarer Hardware zusammenarbeiten muss. Ausserdem erlauben Simulatoren die Performance des Systems zu untersuchen. 3 WARUM ÜBERHAUPT TESTS AUTOMATISIEREN 2.5 4 Support-Werkzeuge beim Software-Testen Support-Werkzeuge unterstützen den Test-Prozess in allen Phasen. Dazu gehören Problem Management Werkzeuge, die bei der Verwaltung von Fehlern und Erweiterungen während dem Lebenszyklus Unterstützung bieten. Sie ermöglichen es schnell und einfach Fehler-Rapporte zu übermitteln oder zu ergänzen, Berichte zu erstellen, Benutzer automatisch über Änderungen zu informieren und bieten einen Zugang zu benutzerdefinierten Abfragen. Ein für alle zugängliches Beispiel eines solchen Werkzeugs ist Bugzilla 2 . Bugzilla wird für die Verwaltung von Fehlern und Erweiterungen des Open-Source Software-Projekts Mozilla verwendet. Durch eine HTML-Benutzerschnittstelle können Entwickler und interessierte Anwender Fehler melden (Siehe Abbildung refbugzilla). Entwickler können die Datenbank nach nützlichen Informationen durchsuchen und bei Bedarf mit den Benutzern (Testern) in Verbindung treten. Abbildung 1: Ein Fehler-Eintrag in Bugzilla Configuration Management (CM) Werkzeuge sind der Schlüssel zur Verwaltung, Steuerung und Koordination von Veränderungen von Dokumenten. Sie unterstützen die Versionskontrolle und das Build-Management. 3 Warum überhaupt Tests automatisieren Wenn man von der Automatisierung von Tests spricht, sollte man sich auch die Frage stellen, welche Gründe dafür sprechen, nicht alle Tests von Hand auszuführen, sondern sie wenn möglich zu automatisieren. Boris Beizer [2] sagt dazu: The argument to use is simple: Manual Testing ” doesn’t work.“ Natürlich lässt sich auch genauer aufzeigen, warum manuelles Testen nicht funktioniert: • Testen von Hand ist unzuverlässig. Menschen sind von Natur aus nicht für repetitive Aufgaben geeignet. Um zuverlässige Aussagen machen zu können, müssen die Tests vergleichbar sein. Das ist nur mit automatisierten Tests gegeben, da hier gewährleistet werden kann, dass die Testfälle immer gleich ablaufen. 2 http://bugzilla.mozilla.org 4 UNIT-TESTING 5 • Manuelles Testen verleitet zu falscher Sicherheit. Manuelles Testen ist schwierig, langweilig und ermüdend. Nach manuellem Testen ist man erschöpft und hat das Gefühl viel geleistet zu haben. Wenn wir so hart gearbeitet haben, müssen wir einfach gut getestet ” haben.“ Beim Testen zählen jedoch nur gefundene Fehler und nicht der Erschöpfungsgrad der Tester. • Die geforderte Zuverlässigkeit verlangt automatisiertes Testen. Benutzer fordern hohe Zuverlässigkeit. Alle Methoden zur Schätzung der Zuverlässigkeit von Software basieren auf voll automatisierten Testverfahren. Und – wie wir alle wissen – kann selbst mit automatisiertem Testen die vom Benutzer verlangte Zuverlässigkeit nicht einfach überprüft werden. • Wie oft wird ein Test wiederholt? Der Versuch manuelles Testen zu rechtfertigen basiert oft auf einer Unterschätzung, wie oft ein Test wiederholt wird. Was oft vernachlässigt wird sind Fehler im Testdesign. Tester sind nicht mehr vor Fehlern gefeit als Programmierer. Wenn wir einen guten Test haben – das heisst er findet viele Fehler – dann wird er für gewöhnlich duzende von Malen ausgeführt. Schon mindestens dreimal um den Test zu debuggen, dann weitere dreimal um zu bestätigen, dass der gefundene Fehler wiederholbar ist. Und wieder dreimal um den Fehler dem Programmierer zu demonstrieren. Dann will ihn der Programmierer noch ausführen und nachdem der Fehler behoben ist, wird man den Test auch noch ein paar Mal ausgeführen. • Software muss gepflegt werden. Der heutige Software Entwicklungsprozess befasst sich vor allem mit der Pflege und nicht mit dem Erstellen und Testen von Software. Für die meisten Produkte umfasst der Aufwand der Pflege um die 80%. Dazu gehört sowohl das Beheben von Fehlern als auch das Erweitern der Software um neue Funktionen. Dazu werden umfassende Regressionstests benötigt. Wird Regressionstesten manuell betrieben, so findet es normalerweise überhaupt nicht statt. • Was sind die tatsächlichen Kosten von manuellem Testen? Die tatsächlichen Kosten von manuellem Testen sind praktisch nicht ermittelbar. Denn die dazu benötigte Infrastruktur ist erst vorhanden, nachdem automatisierte Tests vorhanden sind. Aber wenn die Kosten von manuellem Testen auf Grund der benötigten Arbeitsressourcen ehrlich bestimmt werden, sind die Ergebnisse schockierend. 4 Unit-Testing Werkzeuge für Unit-Testing unterstützen das Testen von Klassen oder Komponenten. Wir wollen uns als Beispiel eines solchen Werkzeugs JUnit ansehen. 4.1 Ein Beispiel für Unit-Testing: JUnit JUnit ist ein Framework für Unit-Testing das von Kent Beck und Erich Gamma entwickelt wurde. Das Werkzeug ist in der Programmiersprache der jeweiligen Entwicklungsumgebung geschrieben. Im Falle von JUnit ist das Java. Da der Code von JUnit frei zugänglich ist, gibt es inzwischen Implementationen für fast jede Programmiersprache (xUnit) 3 . Wir betrachten hier nur JUnit. Implementationen für andere Sprachen als Java sind zwar speziell auf die Besonderheiten der jeweiligen Programmiersprache angepasst, bieten aber in etwa die gleichen Funktionen an. JUnit ist als Testumgebung von Extreme Programming (XP) [5] berühmt geworden. In dieser Entwicklungsmethode wird der Testcode geschrieben bevor überhaupt der zu testende Code dazu geschrieben wird. Der Test wird also gleichzeitig mit der Software entwickelt. Der Programmierer muss sich also zuerst überlegen was seine Klasse tun soll. Mit den Tests legt er den Rahmen dazu fest. Wird dann die eigentliche Software dazu geschrieben hat man eine klare Kontrolle darüber, 3 http://www.junit.org 4 UNIT-TESTING 6 ob die Bedingungen die man vorher in der Form eines Tests festgelegt hat erfüllt sind oder nicht. Schlägt der Test fehl sind entweder die Erwartungen an die Klasse falsch oder die Umsetzung weist Fehler auf. Durch die gleichzeitige Entwicklung von Tests und Software wird sichergestellt, dass jeder Teil des Programms durch Tests geschützt ist. Ändert man die Software zu einem späteren Zeitpunkt und die Tests scheitern, so weiss man, dass Annahmen, die man früher gemacht hat nicht mehr zutreffen und ein Fehler sehr wahrscheinlich ist. Regressions-Probleme werden so schnell erkannt. Nach der XP-Arbeitsweise werden Tests und Code gleichzeitig und auch von den gleichen Leuten erstellt. JUnit setzt auf der gleichen Entwicklungsumgebung, auf der auch die Software entwickelt wird auf. Dies hat auch den Vorteil, dass die Entwickler mit der Sprache des Testwerkzeugs schon vertraut sind – es ist dieselbe, die sie täglich benutzen. Wird JUnit in der XP-Weise genutzt, so geht das Schreiben von Tests in die normale Arbeitsweise über. Mit der Übung verringert sich auch der Aufwand für die Erstellung der Testfälle. Ausserdem erhält der Programmierer direktes Feedback, ob seine Annahmen über Eingabedaten korrekt sind. Dies kann die Effektivität der normalen Programmiertätigkeit steigern. 4.2 Arbeitsweise von JUnit Betrachten wir ein einfaches Beispiel einer Klasse. Wir wollen einen Test für die Klasse StatModel schreiben. public class StatModel extends Observable { private Vector list = new Vector(); public int sum() { int sum = 0; for (Enumeration e = this.list.elements(); e.hasMoreElements();) { sum = sum + ((Integer)e.nextElement()).intValue(); } return sum; } // ... } Dazu erstellen wir eine weitere Klasse StatModelTest, die unseren Testfall aufnehmen kann. import junit.framework.*; public class StatModelTest extends TestCase { public StatModelTest(String name) { super(name); } public void testSum() { StatModel m = new StatModel(); m.addValue(3); m.addValue(4); m.addValue(5); assertEquals(3, m.size()); assertEquals(12, m.sum()); } 4 UNIT-TESTING 7 public static void main(String args[]) { TestCase test = new StatModelTest("testSum"); test.run(); } } Die main()-Methode dieses Programms erstellt eine Instanz unseres Testfalls und ruft ihn auf. In der Methode testSum erzeugen wir eine Instanz der zu testenden Klasse. Wir übergeben Werte an die addValue-Methode und überprüfen danach mit assertEquals, ob die Instanz auch den erwarteten Zustand hat. In unserem Fall überprüfen wir, ob die übergebenen Werte wirklich zur Liste hinzugefügt wurden und ob die Berechnung der Summe zum richtigen Ergebnis führt. Wichtig ist, dass die Tests keinerlei Seiteneffekte haben dürfen. D.h. es muss egal sein in welcher Reihenfolge die Tests ausgeführt werden. Deshalb wird vor jedem Test setup() und nach jedem Test tearDown() aufgerufen. Wir können die Initialisierung, welche meist für alle Testfälle gleich aussieht, in diese Methoden packen. So wird verhindert, dass der Initialisierungscode in allen Testfällen wiederholt wird. Die einzelnen Tests können zu einer Test-Suite zusammengefasst werden: public class StatModelTest extends TestCase { private StatModel m; public StatModelTest(String name) { super(name) } protected void setUp() { m = new StatModel(); m.addValue(3); m.addValue(4); m.addValue(5); } // Tests public static Test suite() { TestSuite suite = new TestSuite(); suite.addTest(new StatModelTest("testSum")); suite.addTest(new StatModelTest("testMean")); return suite; } } Um nicht jeden Testfall einzeln zur Suite hinzufügen zu müssen kann man auch Reflection benutzen: public static Test suite() { TestSuite suite = new TestSuite(StatModelTest.class); return suite; } Alle Methoden der Form public void test*() können so auf einmal zur Test-Suite hinzugefügt werden. 5 GUI-TESTING 8 Abbildung 2 zeigt die graphische Benutzerschnittstelle, den sogenannten Test-Runner. Mit ihm können Tests – wenn gewünscht selektiv – ausgeführt werden. Der Erfolg/Misserfolg von Tests wird mit einem Fortschrittsbalken klar dargestellt. Die von den Testfällen ausgelösten Fehlermeldungen werden dem Tester angezeigt, was diesem die Suche nach dem Grund für das Scheitern des Tests erleichtert. Abbildung 2: Die graphische Benutzerschnittstelle von JUnit Neben der hier gezeigten graphischen Benutzerschnittstelle existieren noch weitere. Der Aufruf der verschiedenen Schnittstellen unterscheidet sich lediglich im zu verwendenden Start-Befehl. Die Testfälle müssen dazu nicht neu kompiliert werden. Mit • java junit.textui.TestRunner StatModelTest, • java junit.awtui.TestRunner StatModelTest bzw. • java junit.swingui.TestRunner StatModelTest wird unser Beispiel-Test mit Text-, AWT- bzw. Swing-basierter Schnittstelle aufgerufen. JUnit und seine Pendants werden sehr oft benutzt – auch von Unternehmen, die kein XP einsetzen. Die freie Verfügbarkeit mag da eine Rolle spielen. Vor allem aber ist dieses Werkzeug einfach in der Handhabung und liefert gute Ergebnisse. Allerdings können die mit JUnit erzielten Ergebnisse nur so gut sein wie die erstellten Testfälle. Sind die Tests nicht gut geschrieben, können auch keine guten Resultate erwartet werden. 5 GUI-Testing Für das Testen von GUI’s (Graphical User Interfaces) kommen Capture/Replay-Werkzeuge zum Einsatz. Alle erhältlichen Werkzeuge dieses Typs funktionieren ähnlich: • Capture Modus: Das Capture/Replay-Werkzeug (CR-Werkzeug) erfasst alle manuellen Benutzer-Interaktionen auf dem Test-Objekt. Alle CR-Werkzeuge arbeiten objektorinetiert, d.h. sie erkennen jedes ausgewählte GUI-Element (z.B. Button, Radio-Box, Toolbar etc.) und erfassen alle Objektcharakteristiken (z.B. Name, Farbe, Label, Wert) und nicht nur die X/Y-Koordinaten der Mausklicks. 5 GUI-TESTING 9 • Programmierung: Die erfassten Testschritte werden vom CR-Werkzeug in einem Testskript festgehalten. Mit all den Funktionen einer Sprache des Testskripts (Fallunterscheidungen, Schleifen, Subroutinen) können komplexe Testabläufe implementiert werden. • Checkpoints: Um zu festzustellen, ob das getestete Programm korrekt funktioniert oder ob Fehler aufgetreten sind, kann der Tester während dem Capture Modus oder beim Bearbeiten des Skripts zusätzliche Checkpoints ins Testscript einfügen. So können Layout-relevante Eigenschaften von Objekten (Farbe, Position, Grösse) zusammen mit der funktionalen Eigenschaften des getesteten Programms (Wert einer Maske, Inhalt einer Message-Box, etc.) überprüft werden. • Replay Modus : Einmal aufgezeichnet, können Tests wieder abgespielt werden und sind prinzipiell zu jeder Zeit wiederholbar. Die Objektorientierung der CR-Werkzeuge erlaubt es, GUI-Elemente selbst dann wiederzuerkennen, wenn das GUI unterdessen verändert wurde. Wenn sich das Testobjekt während dem Test anders verhält oder wenn Checkpoints verletzt werden, so schlägt der Test fehl. Das CR-Werkzeug registriert dies als ein Fehler im Testobjekt. 5.1 Mögliche Probleme beim GUI-Testen Die Hersteller von CR-Werkzeugen bewerben ihre Produkte als eine schnelle und einfache Methode um GUI-Tests zu automatisieren. Aber es gibt einige Schwierigkeiten welche die Effektivität von CR-Werkzeugen beeinflussen können [6]: • CR-Werkzeuge sollen GUI-Objekte mit Verfahren der Objektorientierung erkennen und das auch wenn sich das Layout des GUI verändert hat. Aber wenn ein Testwerkzeug GUI-Objekte von einem C++-Entwicklungssystem erkennen kann, heisst das nicht, dass es auch andere GUI-Objekte anderer Entwicklungssysteme erkennt. Eventuell müssen zusätzliche Schnittstellen nachgerüstet werden. • Da CR-Werkzeuge GUI-Elemente an ihrer ID oder durch eine Kombination von AttributWerten erkennen, sind sie sensibel auf Änderungen dieser Werte. Gewisse Entwicklungswerkzeuge ändern die ID von GUI-Elementen ohne Einfluss des Entwicklers. In diesem Fall muss das CR-Werkzeug bei jedem Test manuell über die geänderten GUI Elemente unterrichtet werden. Ein ähnliches Problem tritt auf, wenn Objekte wegen funktionalen Änderungen in der neuen Version wegfallen oder verändert werden. • Wenn ein CR-Werkzeug einen Test aufzeichnet wie drücke den Speichern-Button und warte ” bis gespeichert in einem Meldefenster erscheint“ heisst das nicht ohne weiteres, dass die Daten tatsächlich gespeichert wurden. • Testfälle sind abhängig vom bisherigen Verlauf der getesteten Software und dem aktuellen Zustand. Bei der Automatisation von GUI-Tests geschieht dies bei praktisch jedem Testfall. 5.2 Ein Beispiel für Capture/Replay: WinRunner WinRunner der Firma Mercury Interactive [7] soll hier als Beispiel eines Capture/Replay-Werkzeugs vorgestellt werden. WinRunner unterstützt zahlreiche Umgebungen. Von Internetbrowsern, JavaApplikationen, ActiveX, WAP, Oracle, SAP, über Terminal-Emulatoren bis zu Visual Basic, C/C++, PowerBuilder und Delphi ist fast alles vertreten. Für nicht-Windows Betriebssysteme gibt es das Produkt xRunner für X-Window basierte Systeme. Über eine graphische Benutzerschnittstelle kann die Aufzeichnung gestartet werden. Die Entstehung des Skripts der Aufzeichnung kann in einem Fenster mitverfolgt werden (Abbildung 3). WinRunner benutzt dazu eine eigene Skriptsprache. Während der Test aufgezeichnet wird kann das Skript bereits editiert werden, um komplexere Tests zu erstellen. 6 WEITERE TESTWERKZEUGE 10 Abbildung 3: Die graphische Benutzerschnittstelle von WinRunner Während der Aufzeichnung können Checkpoints eingefügt werden, an denen die erwarteten mit den tatsächlichen Ergebnissen verglichen werden. Es gibt verschiedene Typen von Checkpoints: Text, GUI, Bitmap und Database. Mit einem Bitmap-Checkpoint kann verifiziert werden, dass ein Bild (z.B. das Firmenlogo) an einer bestimmten Stelle erscheint. Zusätzlich zum Erstellen und Abspielen von Tests kann WinRunner Datenbank-Werte verifizieren, um zu überprüfen, dass eine Datentransaktion tatsächlich stattgefunden hat. WinRunner zeigt die Resultate dieser Überprüfung automatisch an und markiert veränderte, gelöschte und eingefügte Datensätze farblich. Um Tests mit unterschiedlichen Eingabedaten auszuführen, bietet WinRunner einen DataDriver Wizard. Damit kann ein aufgezeichneter Prozess in einen datengesteuerten Test umgewandelt werden. Die dazu benötigten Daten können entweder direkt in ein Spreadsheet eingegeben oder von einer externen Applikation wie z.B. einer Datenbank eingelesen werden. Auch das Einfügen von Funktionen in das Testskript findet über einen Wizard statt. Aus verschiedenen Gruppen von Funktionen kann die geeignete ausgewählt werden. Mit einem weiteren Wizard können Schnittstellen zu unbekannten, non-standard Objekten erstellt werden. Durch eine weitere Benutzerschnittstelle kann die Ausführung von Tests gesteuert werden. Die zu testende Applikation wird durch Winrunner automatisch gesteuert. Nach dem Ausführen der Tests werden die Ergebnisse übersichtlich dargestellt und farblich unterschiedlich gekennzeichnet (Abbildung 5). 6 Weitere Testwerkzeuge Es folgt die Vorstellung einiger weiterer Testwerkzeuge. 6.1 JTest JTest der Firma ParaSoft [9] ist wie JUnit ein Werkzeug für Unit-Testing unter Java. Allerdings ist JTest ein kommerzielles Produkt und bietet einiges mehr als JUnit. 6 WEITERE TESTWERKZEUGE Abbildung 4: WinRunner kann auch Veränderungen in der Datenbank verifizieren Abbildung 5: Ausführen und verifizieren von Tests mit WinRunner 11 6 WEITERE TESTWERKZEUGE 12 JTest automatisiert das Erstellen von Black-Box-Tests indem es Information über die Spezifikation ausliest, welche mittels der Sprache DbC 4 in die Klasse eingebaut wird. Das Erstellen von White-Box-Tests wird automatisiert indem der Quellcode gelesen und daraus automatisch Testfälle generiert werden. Ausserdem hilft JTest dabei Standards beim Codieren durchzusetzen. Ausserdem wird ein Framework bereitgestellt um benutzerdefinierte Testfälle erstellen zu können. Verschiedene Metriken über das Projekt können erzeugt und über die Zeit verfolgt werden. JUnit unterstützt neben Windows noch die Betriebssysteme Solaris und Linux. 6.2 McCabe McCabe IQ2 von McCabe & Associates [10] beinhaltet eine ganze Reihe von Werkzeugen. • McCabe QA ist ein Werkzeug um die Qualität von Software zu messen. Gemessen werden verschiedene Metriken der Komplexität. Die Ergebnisse dieser Messung können dazu benutzt werden, Risiken und Aufwand abzuschätzen und um die Ressourcen dorthin auszurichten, wo sie die grösste Wirkung erzielen können. Das Werkzeug bietet eine graphische Darstellung der Architektur der Anwendung um die Interpretation der ermittelten Daten besser interpretieren zu können (Abbildung 6). Abbildung 6: McCabe QA’s graphische Darstellung der Architektur Die berechneten Metriken werden archiviert und können über die Zeit angezeigt werden, sodass Veränderungen sichtbar werden. Es können Berichte generiert werden, welche helfen, aus den gefundenen Daten die Qualität der Software und deren Veränderung richtig einzuschätzen. • McCabe Test ist ein Werkzeug um den Testprozess zu überwachen. Es erlaubt Ressourcen für das Testen von Software im Voraus zu planen. Graphische Anzeigen von Testpfaden der benötigten Tests zeigen bildlich die komplexesten Bereiche der zu testenden Software auf. • McCabe Coverage Server speichert die gesammelten Daten der übrigen Werkzeuge der McCabe IQ2 Suite zentral ab und macht sie verfügbar. Die übrigen Werkzeuge können den 4 Design by Contract 7 FAZIT 13 Server zu Datenverwaltung benutzen, anstatt dass jedes Werkzeug die Daten für sich selbst verwaltet. • McCabe Reengineer ist ein Werkzeug zum Auffinden von risikoreichem, fehleranfälligem Code der die Basis fürs Reengineering bildet. Es kann helfen, die Architektur besser zu verstehen, risikohaften Code ausfindig zu machen, Neuentwicklung zu fokussieren und Ressourcen präzise zu planen. • McCabe TRUEchange bietet Funktionen zur Organisation, Kontrolle und Verfolgen des Software-Entwicklungsprozesses. Es beinhaltet Configuration Management, Kontrolle von Versionen und Veränderungen. • McCabe TRUEtrack dient dazu, den Entwicklungsprozess der Software zu verfolgen. Es besitzt die Fähigkeit, Problem – welche die gleiche Ursache haben – zu erkennen und diese miteinander zu verbinden um doppelte Lösungen zu vermeiden. Es hilft dabei, das angesammelte Wissen über den Entwicklungsprozess zu kommunizieren. • McCabe TestCompress ist ein Werkzeug, das die Handhabung grosser Mengen von Testdaten vereinfacht und hilft so den Aufwand für das Erstellen von Tests zu verkleinern. 7 Fazit Während dem Suchen nach Quellmaterial für diese Arbeit vielen mir auch einige Erfahrungsberichte in die Hände [11]. Darunter gab es keine die das Testen absolut verteufelten, aber viele, welche davor warten, Wunder davon zu erwarten. In der Praxis scheint es häufig so zu sein, dass Test-Werkzeuge dann angeschafft werden, wenn das Projekt bereits in der Schieflage ist. Dann ist es jedoch bereits zu spät. Werkzeuge – können sie noch so mächtig sein – müssen von den Testern zuerst akzeptiert und dann richtig angewandt werden. Das braucht Zeit und Schulung. Allerdings – davon zeugt, dass ich keine Texte der Art Test-Werkzeuge sind überflüssig“ ” gefunden haben – können Test-Werkzeuge wertvolle Dienste leisten. Für Interessierte sei Bret Pettichord’s Software Testing Hotlist [12] empfohlen. Diese übersichtlich gegliederte Übersicht über Material zum Thema Testen bietet einen guten Ausgangspunkt für Recherchen zu diesem Thema. Literatur [1] Edward Kit, Software Testing in the Real World - Improving the Process, Addision-Wesley (1995) [2] Boris Beizer, Black-Box Testing - Techniques for Functional Testing of Software and Systems, John Wiley & Sons (1995) [3] Brian Marick, When Should a Test be automated?, http://www.testing.com/writings/automate.pdf (1998) [4] Bruno Schäffer, Skrip zu Objektorientierte Softwareentwicklung - Testen, 2000 [5] Kent Beck, Extreme Programming Explained - Embrace Change, Addision-Wesley (2000) [6] Tilo Linz, Matthias Daigl, How to Automate Testing of Graphical User Interface, http://www.imbus.de/forschung/pie24306/gui/aquis-full paper-1.3.html [7] Homepage Mercury Interactive, http://www.merc-int.com [8] Horwath, Green, Lawler, SilkTest and WinRunner Feature Description, http://www.automationexpertise.com/Files/SilkWrFeatures.pdf (2000) LITERATUR 14 [9] Homepage ParaSoft, http://www.parasoft.com [10] Homepage McCabe and Associates, http://www.mccabe.com [11] Elfriede Dustin, Lessons in Test Automation, http://www.stickyminds.com/sitewide.asp?ObjectId=1802&ObjectType=ART&Function=edetail [12] Bret Pettichord, Software Testing Hotlist, http://www.io.com/~wazmo/qa/