Seminar in Software Engineering und Software-Qualit¨atsmanagement Thema: Messen und Pr¨ufen von Software
Testwerkzeuge
Markus Dommann
markus.dommann@access.unizh.ch
Prof. Dr. Martin Glinz Betreuer: Christian Seybold
13.11.2001
Zusammenfassung
Diese Seminararbeit befasst sich mit Testwerkzeugen. Es soll aufgezeigt werden warum Tests ¨uberhaupt automatisiert werden sollten. Des weiteren wird eine ¨Ubersicht gegeben, was f¨ur Testwerkzeuge ¨uberhaupt vorhanden sind und in welchen Phasen des Testens sie Anwendung finden. Einige am Markt erh¨altliche Testwerkzeuge werden mit ihren F¨ahigkeiten kurz vorgestellt.
INHALTSVERZEICHNIS 1
Inhaltsverzeichnis
1 Einf¨uhrung 2
2 Welche Testwerkzeuge f¨ur welche Aufgaben? 2
2.1 Werkzeuge f¨ur Reviews und Inspektionen . . . 2
2.2 Werkzeuge zur Planung von Tests . . . 2
2.3 Testdesign und -entwicklung . . . 3
2.4 Testausf¨uhrung und -auswertung . . . 3
2.5 Support-Werkzeuge beim Software-Testen . . . 4
3 Warum ¨uberhaupt Tests automatisieren 4 4 Unit-Testing 5 4.1 Ein Beispiel f¨ur Unit-Testing: JUnit . . . 5
4.2 Arbeitsweise von JUnit . . . 6
5 GUI-Testing 8 5.1 M¨ogliche Probleme beim GUI-Testen . . . 9
5.2 Ein Beispiel f¨ur Capture/Replay: WinRunner . . . 9
6 Weitere Testwerkzeuge 10 6.1 JTest . . . 10
6.2 McCabe . . . 12
7 Fazit 13
1 EINF ¨UHRUNG 2
1 Einf¨ uhrung
Testen ist ein Gebiet der Software-Entwicklung, das h¨aufig vernachl¨assigt wird. Es zeigt sich jedoch, dass durch Testen von Software viele Unannehmlichkeiten verhindert und die Kosten der Softwareentwicklung gesenkt werden k¨onnen. Eine grosse Anzahl an Werkzeugen kann bei der Planung, Ausf¨uhrung 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¨ ur welche Aufgaben?
Je nach Testt¨atigkeit gibt es verschiedene Werkzeuge, welche die Arbeit unterst¨utzen k¨onnen.
Edward Kit [1] gliedert die Werkzeuge nach folgenden T¨atigkeiten:
• Reviews und Inspektionen
• Planung von Tests
• Testdesign und -entwicklung
• Testausf¨uhrung und -auswertung
• Supportwerkzeuge beim Testen von Software
2.1 Werkzeuge f¨ ur Reviews und Inspektionen
Bei Reviews und Inspektionen k¨onnen Werkzeuge auf unterschiedliche Weise die Arbeit unterst¨utzen:
DurchKomplexit¨atsanalysek¨onnen sie Aufschluss dar¨uber geben, welche Bereiche des Pro- gramms bei Inspektionen und Tests spezieller Aufmerksamkeit bed¨urfen. Bereiche mit hoher Kom- plexit¨at k¨onnen durch die Anzahl Entscheidungen in einem Programm oder anderen Metriken aus- findig gemacht werden. Bei der Planung von Tests kann die Komplexit¨atsanalyse Hinweise darauf geben, wieviel Testen n¨otig ist.
Werkzeuge helfen uns unbekannten Code besser zu verstehen. Sie k¨onnen Abh¨angigkei- ten verstehen helfen, die Programmlogik verfolgen, graphische Repr¨asentationen des Programms anzeigen und toten Code identifizieren. Bei der Vorbereitung f¨ur eine Code-Inspizierung k¨onnen solche Werkzeuge die Arbeit erleichtern.
Werkzeuge zur Syntax- und Semantikanalyse f¨uhren intensive Fehlerpr¨ufung am Code durch um Fehler zu finden, die ein Compiler ¨ubersehen w¨urde. Diese Werkzeuge sind sprachabh¨angig.
Sie parsen Code, unterhalten eine Fehlerliste und bieten weitere Informationen. Der Parser kann sowohl semantische Fehler finden, als auch R¨uckschl¨usse 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¨osste Hilfe in diesem Bereich kommt vonStandards. Der IEEE/ANSI- Standard f¨ur Softwaretest-Dokumentation 1 beschreibt den Zweck, Umfang und den Inhalt ei- nes Testplans. Diese Standards werden von vielen Firmen benutzt indem sie Vorlagen f¨ur Test- Dokumentation 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 zurKomplexit¨atsanalyseBereiche zu identifizieren, welche die Planung zus¨atzlicher Tests durch Risikoanalyse beeinflussen. Des weiteren werden Werkzeuge zurPersonal- und Zeitplanungverwendet.
1IEEE 829-1998
2 WELCHE TESTWERKZEUGE F ¨UR WELCHE AUFGABEN? 3
2.3 Testdesign und -entwicklung
Das Testdesign – das Anwendens des Testplans auf die konkrete Software und das Erkennen und Priorisieren von Testf¨allen – wird kaum von Werkzeugen unterst¨utzt. Hingegen k¨onnen bei der Testentwicklung – dem Umsetzen des Testdesigns in konkrete Testf¨alle – Werkzeuge benutzt werden, die auch bei der Testausf¨uhrung und -auswertung Anwendung finden (siehe Abschnitt 2.4).
So z.B. bieten Capture/Replay-Werkzeuge Unterst¨utzung bei der Entwicklung von Testf¨allen.
Ausserdem kommen Werkzeuge zum Generieren von Testdaten zum Einsatz. Diese automa- tisieren das Erzeugen von Testdaten nach benutzerdefinierten Vorgaben. Sie k¨onnen z.B. alle Permutationen einer spezifischen Eingabe generieren.
2.4 Testausf¨ uhrung und -auswertung
Testausf¨uhrung und -auswertung beinhalten das Ausw¨ahlen von Testf¨allen, das Aufsetzen der Umgebung, das Ausf¨uhren der Tests, das Aufzeichnen der Ausgaben, das Analysieren m¨oglicher Fehler und das Messen des Fortschritts.
Mit Capture/Replay Werkzeugen automatisieren Tester die Ausf¨uhrung von Tests. Cap- ture/Replay Werkzeuge zeichnen Benutzeroperationen (Eingaben per Tastatur und Maus) und Ausgaben auf. Das Werkzeug kann dann die zuvor aufgezeichneten Tests wann immer n¨otig wieder- holen und die Resultate validieren, indem sie mit den aufgezeichneten und vom Tester validierten Ergebnisse verglichen werden.
Capture/Replay-Werkzeuge k¨onnen in native und nicht eindringende (non-intrusive) Werkzeu- ge 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¨achtigt.
Die non-intrusive Form von Capture/Replay ben¨otigt ein zus¨atzliches Hardware-System als Testwerkzeug. ¨Ublicherweise hat das Host-System, welches die zu testende Software enth¨alt, eine spezielle Hardware-Verbindung zum Capture/Replay-Werkzeug. Diese Verbindung erlaubt dem Capture/Replay System seine Funktion f¨ur das Host-System transparent durchzuf¨uhren.
Die h¨aufigste Form von Capture/Replay ist native, weil sich der Aufwand von non-intrusive Hardware L¨osungen nur in speziellen Situationen rechtfertigt (z.B. Real-Time-Systeme).
Werkzeuge zur Coverage Analyse k¨onnen die Qualit¨at von Tests quantitativ messen. Mit ihrer Hilfe kann herausgefunden werden, ob die Software gr¨undlich getestet wird. Sie sagen uns welche Teile des Produkts durch Tests ausgef¨uhrt wurde.
Es gibt verschiedene Arten von Coverage. Darunter Statement-, Decision-, Condition-, Decisi- on/ Condition-, Multiple Condition- und Path-Coverage. Im Minimum sollte sichergestellt werden, dass jedes Statement des Programms und jede Entscheidung f¨ur alle m¨oglichen Ergebnisse min- destens einmal ausgef¨uhrt wurde.
Bound Checkers, Memory Testers, Runtime-Error Detectors oderLeak Detectors k¨onnen unter anderem entdecken, ob Speicherprobleme bestehen, Arraygrenzen ¨uberschritten wer- den, Speicher alloziiert aber nicht freigegeben oder uninitialisierter Speicher gelesen und benutzt wird. Solche Werkzeuge sind meist sprach- und plattformabh¨angig. Es gibt aber auch non-intrusive, einfach benutzbare Werkzeuge dieses Typs.
Werkzeuge zumVerwalten von Testf¨allen erlauben auf einfache Weise den ¨Uberblick ¨uber die erstellten Testf¨alle zu halten. Mit ihnen k¨onnen Tests verwaltet und gestartet werden. Sie bieten eine nahtlose Einbettung von Werkzeugen f¨ur Capture/Replay und Coverage Analyse. Ausserdem k¨onnen mit ihrer Hilfe die Erstellung von Testberichten und -dokumentation automatisiert werden.
Simulatorentreten an die Stelle von Soft- und Hardware die mit dem zu testenden System interagiert. Manchmal sind sie die einzige praktikable M¨oglichkeit, die f¨ur Tests zur Verf¨ugung steht. Z.B. wenn Software mit unkontrollierbarer oder nicht verf¨ugbarer Hardware zusammenar- beiten muss. Ausserdem erlauben Simulatoren die Performance des Systems zu untersuchen.
3 WARUM ¨UBERHAUPT TESTS AUTOMATISIEREN 4
2.5 Support-Werkzeuge beim Software-Testen
Support-Werkzeuge unterst¨utzen den Test-Prozess in allen Phasen. Dazu geh¨orenProblem Ma- nagement Werkzeuge, die bei der Verwaltung von Fehlern und Erweiterungen w¨ahrend dem Lebenszyklus Unterst¨utzung bieten. Sie erm¨oglichen es schnell und einfach Fehler-Rapporte zu
¨ubermitteln oder zu erg¨anzen, Berichte zu erstellen, Benutzer automatisch ¨uber ¨Anderungen zu informieren und bieten einen Zugang zu benutzerdefinierten Abfragen.
Ein f¨ur alle zug¨angliches Beispiel eines solchen Werkzeugs ist Bugzilla 2. Bugzilla wird f¨ur die Verwaltung von Fehlern und Erweiterungen des Open-Source Software-Projekts Mozilla ver- wendet. Durch eine HTML-Benutzerschnittstelle k¨onnen Entwickler und interessierte Anwender Fehler melden (Siehe Abbildung refbugzilla). Entwickler k¨onnen die Datenbank nach n¨utzlichen Informationen durchsuchen und bei Bedarf mit den Benutzern (Testern) in Verbindung treten.
Abbildung 1: Ein Fehler-Eintrag in Bugzilla
Configuration Management (CM) Werkzeugesind der Schl¨ussel zur Verwaltung, Steue- rung und Koordination von Ver¨anderungen von Dokumenten. Sie unterst¨utzen die Versionskon- trolle und das Build-Management.
3 Warum ¨ uberhaupt Tests automatisieren
Wenn man von der Automatisierung von Tests spricht, sollte man sich auch die Frage stellen, welche Gr¨unde daf¨ur sprechen, nicht alle Tests von Hand auszuf¨uhren, sondern sie wenn m¨oglich zu automatisieren. Boris Beizer [2] sagt dazu:
”The argument to use is simple: Manual Testing doesn’t work.“
Nat¨urlich l¨asst sich auch genauer aufzeigen, warum manuelles Testen nicht funktioniert:
• Testen von Hand ist unzuverl¨assig.Menschen sind von Natur aus nicht f¨ur repetitive Aufgaben geeignet. Um zuverl¨assige Aussagen machen zu k¨onnen, m¨ussen die Tests ver- gleichbar sein. Das ist nur mit automatisierten Tests gegeben, da hier gew¨ahrleistet werden kann, dass die Testf¨alle immer gleich ablaufen.
2http://bugzilla.mozilla.org
4 UNIT-TESTING 5
• Manuelles Testen verleitet zu falscher Sicherheit. Manuelles Testen ist schwierig, langweilig und erm¨udend. Nach manuellem Testen ist man ersch¨opft und hat das Gef¨uhl viel geleistet zu haben.
”Wenn wir so hart gearbeitet haben, m¨ussen wir einfach gut getestet haben.“ Beim Testen z¨ahlen jedoch nur gefundene Fehler und nicht der Ersch¨opfungsgrad der Tester.
• Die geforderte Zuverl¨assigkeit verlangt automatisiertes Testen. Benutzer fordern hohe Zuverl¨assigkeit. Alle Methoden zur Sch¨atzung der Zuverl¨assigkeit von Software ba- sieren auf voll automatisierten Testverfahren. Und – wie wir alle wissen – kann selbst mit automatisiertem Testen die vom Benutzer verlangte Zuverl¨assigkeit nicht einfach ¨uberpr¨uft werden.
• Wie oft wird ein Test wiederholt? Der Versuch manuelles Testen zu rechtfertigen ba- siert oft auf einer Untersch¨atzung, wie oft ein Test wiederholt wird. Was oft vernachl¨assigt wird sind Fehler im Testdesign. Tester sind nicht mehr vor Fehlern gefeit als Programmie- rer. Wenn wir einen guten Test haben – das heisst er findet viele Fehler – dann wird er f¨ur gew¨ohnlich duzende von Malen ausgef¨uhrt. Schon mindestens dreimal um den Test zu debuggen, dann weitere dreimal um zu best¨atigen, dass der gefundene Fehler wiederholbar ist. Und wieder dreimal um den Fehler dem Programmierer zu demonstrieren. Dann will ihn der Programmierer noch ausf¨uhren und nachdem der Fehler behoben ist, wird man den Test auch noch ein paar Mal ausgef¨uhren.
• 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¨ur die meisten Produkte umfasst der Aufwand der Pflege um die 80%. Dazu geh¨ort sowohl das Beheben von Fehlern als auch das Erweitern der Software um neue Funktionen. Dazu werden umfassende Regressionstests ben¨otigt. Wird Regressionstesten manuell betrieben, so findet es normalerweise ¨uberhaupt nicht statt.
• Was sind die tats¨achlichen Kosten von manuellem Testen?Die tats¨achlichen Kosten von manuellem Testen sind praktisch nicht ermittelbar. Denn die dazu ben¨otigte Infrastruk- tur ist erst vorhanden, nachdem automatisierte Tests vorhanden sind. Aber wenn die Kosten von manuellem Testen auf Grund der ben¨otigten Arbeitsressourcen ehrlich bestimmt werden, sind die Ergebnisse schockierend.
4 Unit-Testing
Werkzeuge f¨ur Unit-Testing unterst¨utzen das Testen von Klassen oder Komponenten. Wir wollen uns als Beispiel eines solchen Werkzeugs JUnit ansehen.
4.1 Ein Beispiel f¨ ur Unit-Testing: JUnit
JUnit ist ein Framework f¨ur 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¨anglich ist, gibt es inzwischen Implementationen f¨ur fast jede Programmiersprache (xUnit) 3. Wir betrachten hier nur JUnit.
Implementationen f¨ur 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¨uhmt geworden. In dieser Entwicklungsmethode wird der Testcode geschrieben bevor ¨uberhaupt der zu testende Code dazu geschrieben wird. Der Test wird also gleichzeitig mit der Software entwickelt. Der Programmierer muss sich also zuerst ¨uberlegen 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¨uber,
3http://www.junit.org
4 UNIT-TESTING 6
ob die Bedingungen die man vorher in der Form eines Tests festgelegt hat erf¨ullt sind oder nicht.
Schl¨agt 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¨utzt ist. ¨Andert man die Software zu einem sp¨ateren Zeitpunkt und die Tests scheitern, so weiss man, dass Annahmen, die man fr¨uher 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 Testwerk- zeugs schon vertraut sind – es ist dieselbe, die sie t¨aglich benutzen.
Wird JUnit in der XP-Weise genutzt, so geht das Schreiben von Tests in die normale Ar- beitsweise ¨uber. Mit der ¨Ubung verringert sich auch der Aufwand f¨ur die Erstellung der Testf¨alle.
Ausserdem erh¨alt der Programmierer direktes Feedback, ob seine Annahmen ¨uber Eingabedaten korrekt sind. Dies kann die Effektivit¨at der normalen Programmiert¨atigkeit steigern.
4.2 Arbeitsweise von JUnit
Betrachten wir ein einfaches Beispiel einer Klasse. Wir wollen einen Test f¨ur die KlasseStatModel 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();
} }
Diemain()-Methode dieses Programms erstellt eine Instanz unseres Testfalls und ruft ihn auf.
In der MethodetestSumerzeugen wir eine Instanz der zu testenden Klasse. Wir ¨ubergeben Werte an die addValue-Methode und ¨uberpr¨ufen danach mit assertEquals, ob die Instanz auch den erwarteten Zustand hat. In unserem Fall ¨uberpr¨ufen wir, ob die ¨ubergebenen Werte wirklich zur Liste hinzugef¨ugt wurden und ob die Berechnung der Summe zum richtigen Ergebnis f¨uhrt.
Wichtig ist, dass die Tests keinerlei Seiteneffekte haben d¨urfen. D.h. es muss egal sein in welcher Reihenfolge die Tests ausgef¨uhrt werden. Deshalb wird vor jedem Test setup()und nach jedem TesttearDown()aufgerufen. Wir k¨onnen die Initialisierung, welche meist f¨ur alle Testf¨alle gleich aussieht, in diese Methoden packen. So wird verhindert, dass der Initialisierungscode in allen Testf¨allen wiederholt wird.
Die einzelnen Tests k¨onnen 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¨ugen zu m¨ussen 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¨onnen so auf einmal zur Test-Suite hinzu- gef¨ugt werden.
5 GUI-TESTING 8
Abbildung 2 zeigt die graphische Benutzerschnittstelle, den sogenannten Test-Runner. Mit ihm k¨onnen Tests – wenn gew¨unscht selektiv – ausgef¨uhrt werden. Der Erfolg/Misserfolg von Tests wird mit einem Fortschrittsbalken klar dargestellt. Die von den Testf¨allen ausgel¨osten Fehlermeldungen werden dem Tester angezeigt, was diesem die Suche nach dem Grund f¨ur 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¨alle m¨ussen dazu nicht neu kompiliert werden.
Mit
• java junit.textui.TestRunner StatModelTest,
• java junit.awtui.TestRunner StatModelTestbzw.
• 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¨ugbarkeit mag da eine Rolle spielen. Vor allem aber ist dieses Werkzeug einfach in der Handhabung und liefert gute Ergebnisse. Allerdings k¨onnen die mit JUnit erzielten Ergebnisse nur so gut sein wie die erstellten Testf¨alle. Sind die Tests nicht gut geschrieben, k¨onnen auch keine guten Resultate erwartet werden.
5 GUI-Testing
F¨ur das Testen von GUI’s (Graphical User Interfaces) kommen Capture/Replay-Werkzeuge zum Einsatz. Alle erh¨altlichen Werkzeuge dieses Typs funktionieren ¨ahnlich:
• 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¨ahlte 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 Test- skript festgehalten. Mit all den Funktionen einer Sprache des Testskripts (Fallunterscheidun- gen, Schleifen, Subroutinen) k¨onnen komplexe Testabl¨aufe implementiert werden.
• Checkpoints: Um zu festzustellen, ob das getestete Programm korrekt funktioniert oder ob Fehler aufgetreten sind, kann der Tester w¨ahrend dem Capture Modus oder beim Bearbei- ten des Skripts zus¨atzliche Checkpoints ins Testscript einf¨ugen. So k¨onnen Layout-relevante Eigenschaften von Objekten (Farbe, Position, Gr¨osse) zusammen mit der funktionalen Ei- genschaften des getesteten Programms (Wert einer Maske, Inhalt einer Message-Box, etc.) uberpr¨¨ uft werden.
• Replay Modus : Einmal aufgezeichnet, k¨onnen 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¨andert wurde.
Wenn sich das Testobjekt w¨ahrend dem Test anders verh¨alt oder wenn Checkpoints ver- letzt werden, so schl¨agt der Test fehl. Das CR-Werkzeug registriert dies als ein Fehler im Testobjekt.
5.1 M¨ ogliche 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¨at von CR-Werkzeugen beeinflussen k¨onnen [6]:
• CR-Werkzeuge sollen GUI-Objekte mit Verfahren der Objektorientierung erkennen und das auch wenn sich das Layout des GUI ver¨andert 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¨ussen zus¨atzliche Schnitt- stellen nachger¨ustet werden.
• Da CR-Werkzeuge GUI-Elemente an ihrer ID oder durch eine Kombination von Attribut- Werten erkennen, sind sie sensibel auf ¨Anderungen dieser Werte. Gewisse Entwicklungswerk- zeuge ¨andern die ID von GUI-Elementen ohne Einfluss des Entwicklers. In diesem Fall muss das CR-Werkzeug bei jedem Test manuell ¨uber die ge¨anderten GUI Elemente unterrichtet werden. Ein ¨ahnliches Problem tritt auf, wenn Objekte wegen funktionalen ¨Anderungen in der neuen Version wegfallen oder ver¨andert werden.
• Wenn ein CR-Werkzeug einen Test aufzeichnet wie
”dr¨ucke den Speichern-Button und warte bis gespeichert in einem Meldefenster erscheint“ heisst das nicht ohne weiteres, dass die Daten tats¨achlich gespeichert wurden.
• Testf¨alle sind abh¨angig 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¨ ur Capture/Replay: WinRunner
WinRunner der Firma Mercury Interactive [7] soll hier als Beispiel eines Capture/Replay-Werkzeugs vorgestellt werden. WinRunner unterst¨utzt zahlreiche Umgebungen. Von Internetbrowsern, Java- Applikationen, ActiveX, WAP, Oracle, SAP, ¨uber Terminal-Emulatoren bis zu Visual Basic, C/C++, PowerBuilder und Delphi ist fast alles vertreten. F¨ur nicht-Windows Betriebssysteme gibt es das Produkt xRunner f¨ur X-Window basierte Systeme.
Uber eine graphische Benutzerschnittstelle kann die Aufzeichnung gestartet werden. Die Ent-¨ stehung des Skripts der Aufzeichnung kann in einem Fenster mitverfolgt werden (Abbildung 3).
WinRunner benutzt dazu eine eigene Skriptsprache. W¨ahrend 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¨ahrend der Aufzeichnung k¨onnen Checkpoints eingef¨ugt werden, an denen die erwarteten mit den tats¨achlichen 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¨atzlich zum Erstellen und Abspielen von Tests kann WinRunner Datenbank-Werte verifi- zieren, um zu ¨uberpr¨ufen, dass eine Datentransaktion tats¨achlich stattgefunden hat. WinRunner zeigt die Resultate dieser ¨Uberpr¨ufung automatisch an und markiert ver¨anderte, gel¨oschte und eingef¨ugte Datens¨atze farblich.
Um Tests mit unterschiedlichen Eingabedaten auszuf¨uhren, bietet WinRunner einen DataDri- ver Wizard. Damit kann ein aufgezeichneter Prozess in einen datengesteuerten Test umgewandelt werden. Die dazu ben¨otigten Daten k¨onnen entweder direkt in ein Spreadsheet eingegeben oder von einer externen Applikation wie z.B. einer Datenbank eingelesen werden.
Auch das Einf¨ugen von Funktionen in das Testskript findet ¨uber einen Wizard statt. Aus verschiedenen Gruppen von Funktionen kann die geeignete ausgew¨ahlt werden. Mit einem weiteren Wizard k¨onnen Schnittstellen zu unbekannten, non-standard Objekten erstellt werden. Durch eine weitere Benutzerschnittstelle kann die Ausf¨uhrung von Tests gesteuert werden. Die zu testende Applikation wird durch Winrunner automatisch gesteuert.
Nach dem Ausf¨uhren der Tests werden die Ergebnisse ¨ubersichtlich 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¨ur Unit-Testing unter Java. Allerdings ist JTest ein kommerzielles Produkt und bietet einiges mehr als JUnit.
6 WEITERE TESTWERKZEUGE 11
Abbildung 4: WinRunner kann auch Ver¨anderungen in der Datenbank verifizieren
Abbildung 5: Ausf¨uhren und verifizieren von Tests mit WinRunner
6 WEITERE TESTWERKZEUGE 12
JTest automatisiert das Erstellen von Black-Box-Tests indem es Information ¨uber die Spezi- fikation 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¨alle generiert werden. Ausserdem hilft JTest dabei Standards beim Codieren durchzusetzen.
Ausserdem wird ein Framework bereitgestellt um benutzerdefinierte Testf¨alle erstellen zu k¨onnen.
Verschiedene Metriken ¨uber das Projekt k¨onnen erzeugt und ¨uber die Zeit verfolgt werden.
JUnit unterst¨utzt neben Windows noch die Betriebssysteme Solaris und Linux.
6.2 McCabe
McCabe IQ2 von McCabe & Associates [10] beinhaltet eine ganze Reihe von Werkzeugen.
• McCabe QAist ein Werkzeug um die Qualit¨at von Software zu messen. Gemessen werden verschiedene Metriken der Komplexit¨at. Die Ergebnisse dieser Messung k¨onnen dazu benutzt werden, Risiken und Aufwand abzusch¨atzen und um die Ressourcen dorthin auszurichten, wo sie die gr¨osste Wirkung erzielen k¨onnen. Das Werkzeug bietet eine graphische Darstel- lung der Architektur der Anwendung um die Interpretation der ermittelten Daten besser interpretieren zu k¨onnen (Abbildung 6).
Abbildung 6: McCabe QA’s graphische Darstellung der Architektur
Die berechneten Metriken werden archiviert und k¨onnen ¨uber die Zeit angezeigt werden, sodass Ver¨anderungen sichtbar werden. Es k¨onnen Berichte generiert werden, welche hel- fen, aus den gefundenen Daten die Qualit¨at der Software und deren Ver¨anderung richtig einzusch¨atzen.
• McCabe Testist ein Werkzeug um den Testprozess zu ¨uberwachen. Es erlaubt Ressourcen f¨ur das Testen von Software im Voraus zu planen. Graphische Anzeigen von Testpfaden der ben¨otigten Tests zeigen bildlich die komplexesten Bereiche der zu testenden Software auf.
• McCabe Coverage Server speichert die gesammelten Daten der ¨ubrigen Werkzeuge der McCabe IQ2 Suite zentral ab und macht sie verf¨ugbar. Die ¨ubrigen Werkzeuge k¨onnen den
4Design by Contract
7 FAZIT 13
Server zu Datenverwaltung benutzen, anstatt dass jedes Werkzeug die Daten f¨ur sich selbst verwaltet.
• McCabe Reengineer ist ein Werkzeug zum Auffinden von risikoreichem, fehleranf¨alligem Code der die Basis f¨urs Reengineering bildet. Es kann helfen, die Architektur besser zu verste- hen, risikohaften Code ausfindig zu machen, Neuentwicklung zu fokussieren und Ressourcen pr¨azise zu planen.
• McCabe TRUEchange bietet Funktionen zur Organisation, Kontrolle und Verfolgen des Software-Entwicklungsprozesses. Es beinhaltet Configuration Management, Kontrolle von Versionen und Ver¨anderungen.
• McCabe TRUEtrackdient dazu, den Entwicklungsprozess der Software zu verfolgen. Es besitzt die F¨ahigkeit, Problem – welche die gleiche Ursache haben – zu erkennen und diese miteinander zu verbinden um doppelte L¨osungen zu vermeiden. Es hilft dabei, das angesam- melte Wissen ¨uber den Entwicklungsprozess zu kommunizieren.
• McCabe TestCompressist ein Werkzeug, das die Handhabung grosser Mengen von Test- daten vereinfacht und hilft so den Aufwand f¨ur das Erstellen von Tests zu verkleinern.
7 Fazit
W¨ahrend dem Suchen nach Quellmaterial f¨ur diese Arbeit vielen mir auch einige Erfahrungsbe- richte in die H¨ande [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¨aufig so zu sein, dass Test-Werkzeuge dann angeschafft werden, wenn das Projekt bereits in der Schieflage ist. Dann ist es jedoch bereits zu sp¨at. Werkzeuge – k¨onnen sie noch so m¨achtig sein – m¨ussen 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 ¨uberfl¨ussig“
gefunden haben – k¨onnen Test-Werkzeuge wertvolle Dienste leisten.
F¨ur Interessierte sei Bret Pettichord’s Software Testing Hotlist [12] empfohlen. Diese ¨ubersicht- lich gegliederte ¨Ubersicht ¨uber Material zum Thema Testen bietet einen guten Ausgangspunkt f¨ur 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¨affer,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/
