Testwerkzeuge

Transcription

Testwerkzeuge

Seminar in Software Engineering und Software-Qualitätsmanagement
Thema: Messen und Prü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 überhaupt automatisiert werden sollten. Des weiteren wird eine Übersicht gegeben,
was für Testwerkzeuge überhaupt vorhanden sind und in welchen Phasen des Testens sie
Anwendung finden. Einige am Markt erhältliche Testwerkzeuge werden mit ihren Fähigkeiten
kurz vorgestellt.
INHALTSVERZEICHNIS
1
Inhaltsverzeichnis
1 Einführung
2 Welche Testwerkzeuge für welche Aufgaben?
2.1 Werkzeuge für Reviews und Inspektionen . .
2.2 Werkzeuge zur Planung von Tests . . . . . . .
2.3 Testdesign und -entwicklung . . . . . . . . . .
2.4 Testausführung und -auswertung . . . . . . .
2.5 Support-Werkzeuge beim Software-Testen . .
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
3
3
4
3 Warum überhaupt Tests automatisieren
4
4 Unit-Testing
4.1 Ein Beispiel für Unit-Testing: JUnit . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Arbeitsweise von JUnit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
6
5 GUI-Testing
5.1 Mögliche Probleme beim GUI-Testen . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Ein Beispiel für Capture/Replay: WinRunner . . . . . . . . . . . . . . . . . . . . .
8
9
9
6 Weitere Testwerkzeuge
6.1 JTest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 McCabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
10
12
7 Fazit
13
1
EINFÜHRUNG
1
2
Einführung
Testen ist ein Gebiet der Software-Entwicklung, das häufig vernachlässigt wird. Es zeigt sich
jedoch, dass durch Testen von Software viele Unannehmlichkeiten verhindert und die Kosten der
Softwareentwicklung gesenkt werden können. Eine grosse Anzahl an Werkzeugen kann bei der
Planung, Ausfü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 für welche Aufgaben?
Je nach Testtätigkeit gibt es verschiedene Werkzeuge, welche die Arbeit unterstützen können.
Edward Kit [1] gliedert die Werkzeuge nach folgenden Tätigkeiten:
• Reviews und Inspektionen
• Planung von Tests
• Testdesign und -entwicklung
• Testausführung und -auswertung
• Supportwerkzeuge beim Testen von Software
2.1
Werkzeuge für Reviews und Inspektionen
Bei Reviews und Inspektionen können Werkzeuge auf unterschiedliche Weise die Arbeit unterstützen:
Durch Komplexitätsanalyse können sie Aufschluss darüber geben, welche Bereiche des Programms bei Inspektionen und Tests spezieller Aufmerksamkeit bedürfen. Bereiche mit hoher Komplexität können durch die Anzahl Entscheidungen in einem Programm oder anderen Metriken ausfindig gemacht werden. Bei der Planung von Tests kann die Komplexitätsanalyse Hinweise darauf
geben, wieviel Testen nötig ist.
Werkzeuge helfen uns unbekannten Code besser zu verstehen. Sie können Abhängigkeiten verstehen helfen, die Programmlogik verfolgen, graphische Repräsentationen des Programms
anzeigen und toten Code identifizieren. Bei der Vorbereitung für eine Code-Inspizierung können
solche Werkzeuge die Arbeit erleichtern.
Werkzeuge zur Syntax- und Semantikanalyse führen intensive Fehlerprüfung am Code
durch um Fehler zu finden, die ein Compiler übersehen würde. Diese Werkzeuge sind sprachabhängig.
Sie parsen Code, unterhalten eine Fehlerliste und bieten weitere Informationen. Der Parser kann
sowohl semantische Fehler finden, als auch Rückschlü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 grösste Hilfe in diesem Bereich kommt von Standards. Der IEEE/ANSIStandard für Softwaretest-Dokumentation 1 beschreibt den Zweck, Umfang und den Inhalt eines Testplans. Diese Standards werden von vielen Firmen benutzt indem sie Vorlagen fü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 Komplexitätsanalyse Bereiche zu
identifizieren, welche die Planung zusätzlicher Tests durch Risikoanalyse beeinflussen. Des weiteren
werden Werkzeuge zur Personal- und Zeitplanung verwendet.
1 IEEE
829-1998
2
WELCHE TESTWERKZEUGE FÜ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 Testfällen – wird kaum von Werkzeugen unterstützt. Hingegen können bei
der Testentwicklung – dem Umsetzen des Testdesigns in konkrete Testfälle – Werkzeuge benutzt
werden, die auch bei der Testausführung und -auswertung Anwendung finden (siehe Abschnitt 2.4).
So z.B. bieten Capture/Replay-Werkzeuge Unterstützung bei der Entwicklung von Testfällen.
Ausserdem kommen Werkzeuge zum Generieren von Testdaten zum Einsatz. Diese automatisieren das Erzeugen von Testdaten nach benutzerdefinierten Vorgaben. Sie können z.B. alle
Permutationen einer spezifischen Eingabe generieren.
2.4
Testausführung und -auswertung
Testausführung und -auswertung beinhalten das Auswählen von Testfällen, das Aufsetzen der
Umgebung, das Ausführen der Tests, das Aufzeichnen der Ausgaben, das Analysieren möglicher
Fehler und das Messen des Fortschritts.
Mit Capture/Replay Werkzeugen automatisieren Tester die Ausfü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 nötig wiederholen und die Resultate validieren, indem sie mit den aufgezeichneten und vom Tester validierten
Ergebnisse verglichen werden.
Capture/Replay-Werkzeuge kö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 beeinträchtigt.
Die non-intrusive Form von Capture/Replay benötigt ein zusätzliches Hardware-System als
Testwerkzeug. Üblicherweise hat das Host-System, welches die zu testende Software enthält, eine
spezielle Hardware-Verbindung zum Capture/Replay-Werkzeug. Diese Verbindung erlaubt dem
Capture/Replay System seine Funktion für das Host-System transparent durchzuführen.
Die häufigste Form von Capture/Replay ist native, weil sich der Aufwand von non-intrusive
Hardware Lösungen nur in speziellen Situationen rechtfertigt (z.B. Real-Time-Systeme).
Werkzeuge zur Coverage Analyse können die Qualität von Tests quantitativ messen. Mit
ihrer Hilfe kann herausgefunden werden, ob die Software gründlich getestet wird. Sie sagen uns
welche Teile des Produkts durch Tests ausgefü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 für alle möglichen Ergebnisse mindestens einmal ausgeführt wurde.
Bound Checkers, Memory Testers, Runtime-Error Detectors oder Leak Detectors
können unter anderem entdecken, ob Speicherprobleme bestehen, Arraygrenzen überschritten werden, Speicher alloziiert aber nicht freigegeben oder uninitialisierter Speicher gelesen und benutzt
wird. Solche Werkzeuge sind meist sprach- und plattformabhängig. Es gibt aber auch non-intrusive,
einfach benutzbare Werkzeuge dieses Typs.
Werkzeuge zum Verwalten von Testfällen erlauben auf einfache Weise den Überblick über
die erstellten Testfälle zu halten. Mit ihnen können Tests verwaltet und gestartet werden. Sie bieten
eine nahtlose Einbettung von Werkzeugen für Capture/Replay und Coverage Analyse. Ausserdem
kö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 Möglichkeit, die für Tests zur Verfügung
steht. Z.B. wenn Software mit unkontrollierbarer oder nicht verfügbarer Hardware zusammenarbeiten muss. Ausserdem erlauben Simulatoren die Performance des Systems zu untersuchen.
3
WARUM ÜBERHAUPT TESTS AUTOMATISIEREN
2.5
4
Support-Werkzeuge beim Software-Testen
Support-Werkzeuge unterstützen den Test-Prozess in allen Phasen. Dazu gehören Problem Management Werkzeuge, die bei der Verwaltung von Fehlern und Erweiterungen während dem
Lebenszyklus Unterstützung bieten. Sie ermöglichen es schnell und einfach Fehler-Rapporte zu
übermitteln oder zu ergänzen, Berichte zu erstellen, Benutzer automatisch über Änderungen zu
informieren und bieten einen Zugang zu benutzerdefinierten Abfragen.
Ein für alle zugängliches Beispiel eines solchen Werkzeugs ist Bugzilla 2 . Bugzilla wird für
die Verwaltung von Fehlern und Erweiterungen des Open-Source Software-Projekts Mozilla verwendet. Durch eine HTML-Benutzerschnittstelle können Entwickler und interessierte Anwender
Fehler melden (Siehe Abbildung refbugzilla). Entwickler können die Datenbank nach nü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 Schlüssel zur Verwaltung, Steuerung und Koordination von Veränderungen von Dokumenten. Sie unterstützen die Versionskontrolle und das Build-Management.
3
Warum überhaupt Tests automatisieren
Wenn man von der Automatisierung von Tests spricht, sollte man sich auch die Frage stellen,
welche Gründe dafür sprechen, nicht alle Tests von Hand auszuführen, sondern sie wenn möglich
zu automatisieren. Boris Beizer [2] sagt dazu: The argument to use is simple: Manual Testing
”
doesn’t work.“
Natürlich lässt sich auch genauer aufzeigen, warum manuelles Testen nicht funktioniert:
• Testen von Hand ist unzuverlässig. Menschen sind von Natur aus nicht für repetitive
Aufgaben geeignet. Um zuverlässige Aussagen machen zu können, müssen die Tests vergleichbar sein. Das ist nur mit automatisierten Tests gegeben, da hier gewährleistet werden
kann, dass die Testfä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 ermüdend. Nach manuellem Testen ist man erschöpft und hat das Gefühl
viel geleistet zu haben. Wenn wir so hart gearbeitet haben, müssen wir einfach gut getestet
”
haben.“ Beim Testen zählen jedoch nur gefundene Fehler und nicht der Erschöpfungsgrad
der Tester.
• Die geforderte Zuverlässigkeit verlangt automatisiertes Testen. Benutzer fordern
hohe Zuverlässigkeit. Alle Methoden zur Schätzung der Zuverlässigkeit von Software basieren auf voll automatisierten Testverfahren. Und – wie wir alle wissen – kann selbst mit
automatisiertem Testen die vom Benutzer verlangte Zuverlässigkeit nicht einfach überprüft
werden.
• Wie oft wird ein Test wiederholt? Der Versuch manuelles Testen zu rechtfertigen basiert oft auf einer Unterschätzung, wie oft ein Test wiederholt wird. Was oft vernachlä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
für gewöhnlich duzende von Malen ausgeführt. Schon mindestens dreimal um den Test zu
debuggen, dann weitere dreimal um zu bestätigen, dass der gefundene Fehler wiederholbar
ist. Und wieder dreimal um den Fehler dem Programmierer zu demonstrieren. Dann will ihn
der Programmierer noch ausführen und nachdem der Fehler behoben ist, wird man den Test
auch noch ein paar Mal ausgefü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. Für die
meisten Produkte umfasst der Aufwand der Pflege um die 80%. Dazu gehört sowohl das
Beheben von Fehlern als auch das Erweitern der Software um neue Funktionen. Dazu werden
umfassende Regressionstests benötigt. Wird Regressionstesten manuell betrieben, so findet
es normalerweise überhaupt nicht statt.
• Was sind die tatsächlichen Kosten von manuellem Testen? Die tatsächlichen Kosten
von manuellem Testen sind praktisch nicht ermittelbar. Denn die dazu benötigte Infrastruktur ist erst vorhanden, nachdem automatisierte Tests vorhanden sind. Aber wenn die Kosten
von manuellem Testen auf Grund der benötigten Arbeitsressourcen ehrlich bestimmt werden,
sind die Ergebnisse schockierend.
4
Unit-Testing
Werkzeuge für Unit-Testing unterstützen das Testen von Klassen oder Komponenten. Wir wollen
uns als Beispiel eines solchen Werkzeugs JUnit ansehen.
4.1
Ein Beispiel für Unit-Testing: JUnit
JUnit ist ein Framework fü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 zugänglich ist, gibt es inzwischen
Implementationen für fast jede Programmiersprache (xUnit) 3 . Wir betrachten hier nur JUnit.
Implementationen fü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] berühmt geworden. In dieser
Entwicklungsmethode wird der Testcode geschrieben bevor überhaupt der zu testende Code dazu
geschrieben wird. Der Test wird also gleichzeitig mit der Software entwickelt. Der Programmierer
muss sich also zuerst ü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 darüber,
3 http://www.junit.org
4
UNIT-TESTING
6
ob die Bedingungen die man vorher in der Form eines Tests festgelegt hat erfüllt sind oder nicht.
Schlä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 geschützt ist. Ändert man die Software zu einem späteren Zeitpunkt
und die Tests scheitern, so weiss man, dass Annahmen, die man frü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 täglich benutzen.
Wird JUnit in der XP-Weise genutzt, so geht das Schreiben von Tests in die normale Arbeitsweise über. Mit der Übung verringert sich auch der Aufwand für die Erstellung der Testfälle.
Ausserdem erhält der Programmierer direktes Feedback, ob seine Annahmen über Eingabedaten
korrekt sind. Dies kann die Effektivität der normalen Programmiertätigkeit steigern.
4.2
Arbeitsweise von JUnit
Betrachten wir ein einfaches Beispiel einer Klasse. Wir wollen einen Test fü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 übergeben Werte
an die addValue-Methode und überprüfen danach mit assertEquals, ob die Instanz auch den
erwarteten Zustand hat. In unserem Fall überprüfen wir, ob die übergebenen Werte wirklich zur
Liste hinzugefügt wurden und ob die Berechnung der Summe zum richtigen Ergebnis führt.
Wichtig ist, dass die Tests keinerlei Seiteneffekte haben dürfen. D.h. es muss egal sein in welcher
Reihenfolge die Tests ausgeführt werden. Deshalb wird vor jedem Test setup() und nach jedem
Test tearDown() aufgerufen. Wir können die Initialisierung, welche meist für alle Testfälle gleich
aussieht, in diese Methoden packen. So wird verhindert, dass der Initialisierungscode in allen
Testfällen wiederholt wird.
Die einzelnen Tests kö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 hinzufügen zu mü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*() können so auf einmal zur Test-Suite hinzugefügt werden.
5
GUI-TESTING
8
Abbildung 2 zeigt die graphische Benutzerschnittstelle, den sogenannten Test-Runner. Mit ihm
können Tests – wenn gewünscht selektiv – ausgeführt werden. Der Erfolg/Misserfolg von Tests wird
mit einem Fortschrittsbalken klar dargestellt. Die von den Testfällen ausgelösten Fehlermeldungen
werden dem Tester angezeigt, was diesem die Suche nach dem Grund fü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
Testfälle mü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 Verfügbarkeit mag da eine Rolle spielen. Vor allem aber ist dieses Werkzeug
einfach in der Handhabung und liefert gute Ergebnisse. Allerdings können die mit JUnit erzielten
Ergebnisse nur so gut sein wie die erstellten Testfälle. Sind die Tests nicht gut geschrieben, können
auch keine guten Resultate erwartet werden.
5
GUI-Testing
Für das Testen von GUI’s (Graphical User Interfaces) kommen Capture/Replay-Werkzeuge zum
Einsatz. Alle erhältlichen Werkzeuge dieses Typs funktionieren ä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 ausgewä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) können komplexe Testabläufe implementiert werden.
• Checkpoints: Um zu festzustellen, ob das getestete Programm korrekt funktioniert oder ob
Fehler aufgetreten sind, kann der Tester während dem Capture Modus oder beim Bearbeiten des Skripts zusätzliche Checkpoints ins Testscript einfügen. So können Layout-relevante
Eigenschaften von Objekten (Farbe, Position, Grösse) zusammen mit der funktionalen Eigenschaften des getesteten Programms (Wert einer Maske, Inhalt einer Message-Box, etc.)
überprüft werden.
• Replay Modus : Einmal aufgezeichnet, kö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 verändert wurde.
Wenn sich das Testobjekt während dem Test anders verhält oder wenn Checkpoints verletzt werden, so schlägt der Test fehl. Das CR-Werkzeug registriert dies als ein Fehler im
Testobjekt.
5.1
Mö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 Effektivität von
CR-Werkzeugen beeinflussen können [6]:
• CR-Werkzeuge sollen GUI-Objekte mit Verfahren der Objektorientierung erkennen und das
auch wenn sich das Layout des GUI verä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 müssen zusätzliche Schnittstellen nachgerüstet werden.
• Da CR-Werkzeuge GUI-Elemente an ihrer ID oder durch eine Kombination von AttributWerten erkennen, sind sie sensibel auf Änderungen dieser Werte. Gewisse Entwicklungswerkzeuge ändern die ID von GUI-Elementen ohne Einfluss des Entwicklers. In diesem Fall muss
das CR-Werkzeug bei jedem Test manuell über die geänderten GUI Elemente unterrichtet
werden. Ein ähnliches Problem tritt auf, wenn Objekte wegen funktionalen Änderungen in
der neuen Version wegfallen oder verändert werden.
• Wenn ein CR-Werkzeug einen Test aufzeichnet wie drücke den Speichern-Button und warte
”
bis gespeichert in einem Meldefenster erscheint“ heisst das nicht ohne weiteres, dass die Daten
tatsächlich gespeichert wurden.
• Testfälle sind abhä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 für Capture/Replay: WinRunner
WinRunner der Firma Mercury Interactive [7] soll hier als Beispiel eines Capture/Replay-Werkzeugs
vorgestellt werden. WinRunner unterstützt zahlreiche Umgebungen. Von Internetbrowsern, JavaApplikationen, ActiveX, WAP, Oracle, SAP, über Terminal-Emulatoren bis zu Visual Basic, C/C++,
PowerBuilder und Delphi ist fast alles vertreten. Für nicht-Windows Betriebssysteme gibt es das
Produkt xRunner für X-Window basierte Systeme.
Ü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. Wä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
Während der Aufzeichnung können Checkpoints eingefügt werden, an denen die erwarteten mit
den tatsä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.
Zusätzlich zum Erstellen und Abspielen von Tests kann WinRunner Datenbank-Werte verifizieren, um zu überprüfen, dass eine Datentransaktion tatsächlich stattgefunden hat. WinRunner
zeigt die Resultate dieser Überprüfung automatisch an und markiert veränderte, gelöschte und
eingefügte Datensätze farblich.
Um Tests mit unterschiedlichen Eingabedaten auszuführen, bietet WinRunner einen DataDriver Wizard. Damit kann ein aufgezeichneter Prozess in einen datengesteuerten Test umgewandelt
werden. Die dazu benötigten Daten können entweder direkt in ein Spreadsheet eingegeben oder
von einer externen Applikation wie z.B. einer Datenbank eingelesen werden.
Auch das Einfügen von Funktionen in das Testskript findet über einen Wizard statt. Aus
verschiedenen Gruppen von Funktionen kann die geeignete ausgewählt werden. Mit einem weiteren
Wizard können Schnittstellen zu unbekannten, non-standard Objekten erstellt werden. Durch eine
weitere Benutzerschnittstelle kann die Ausführung von Tests gesteuert werden. Die zu testende
Applikation wird durch Winrunner automatisch gesteuert.
Nach dem Ausführen der Tests werden die Ergebnisse ü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 für Unit-Testing unter Java. Allerdings
ist JTest ein kommerzielles Produkt und bietet einiges mehr als JUnit.
6
Abbildung 4: WinRunner kann auch Veränderungen in der Datenbank verifizieren
Abbildung 5: Ausführen und verifizieren von Tests mit WinRunner
11
6
12
JTest automatisiert das Erstellen von Black-Box-Tests indem es Information ü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
Testfälle generiert werden. Ausserdem hilft JTest dabei Standards beim Codieren durchzusetzen.
Ausserdem wird ein Framework bereitgestellt um benutzerdefinierte Testfälle erstellen zu können.
Verschiedene Metriken über das Projekt können erzeugt und über die Zeit verfolgt werden.
JUnit unterstü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 Qualität von Software zu messen. Gemessen werden
verschiedene Metriken der Komplexität. Die Ergebnisse dieser Messung können dazu benutzt
werden, Risiken und Aufwand abzuschätzen und um die Ressourcen dorthin auszurichten,
wo sie die grösste Wirkung erzielen können. Das Werkzeug bietet eine graphische Darstellung der Architektur der Anwendung um die Interpretation der ermittelten Daten besser
interpretieren zu können (Abbildung 6).
Abbildung 6: McCabe QA’s graphische Darstellung der Architektur
Die berechneten Metriken werden archiviert und können über die Zeit angezeigt werden,
sodass Veränderungen sichtbar werden. Es können Berichte generiert werden, welche helfen, aus den gefundenen Daten die Qualität der Software und deren Veränderung richtig
einzuschätzen.
• McCabe Test ist ein Werkzeug um den Testprozess zu überwachen. Es erlaubt Ressourcen
für das Testen von Software im Voraus zu planen. Graphische Anzeigen von Testpfaden der
benötigten Tests zeigen bildlich die komplexesten Bereiche der zu testenden Software auf.
• McCabe Coverage Server speichert die gesammelten Daten der übrigen Werkzeuge der
McCabe IQ2 Suite zentral ab und macht sie verfügbar. Die übrigen Werkzeuge können den
4 Design
by Contract
7
FAZIT
13
Server zu Datenverwaltung benutzen, anstatt dass jedes Werkzeug die Daten für sich selbst
verwaltet.
• McCabe Reengineer ist ein Werkzeug zum Auffinden von risikoreichem, fehleranfälligem
Code der die Basis fürs Reengineering bildet. Es kann helfen, die Architektur besser zu verstehen, risikohaften Code ausfindig zu machen, Neuentwicklung zu fokussieren und Ressourcen
präzise zu planen.
• McCabe TRUEchange bietet Funktionen zur Organisation, Kontrolle und Verfolgen des
Software-Entwicklungsprozesses. Es beinhaltet Configuration Management, Kontrolle von
Versionen und Veränderungen.
• McCabe TRUEtrack dient dazu, den Entwicklungsprozess der Software zu verfolgen. Es
besitzt die Fähigkeit, Problem – welche die gleiche Ursache haben – zu erkennen und diese
miteinander zu verbinden um doppelte Lösungen zu vermeiden. Es hilft dabei, das angesammelte Wissen über den Entwicklungsprozess zu kommunizieren.
• McCabe TestCompress ist ein Werkzeug, das die Handhabung grosser Mengen von Testdaten vereinfacht und hilft so den Aufwand für das Erstellen von Tests zu verkleinern.
7
Fazit
Während dem Suchen nach Quellmaterial für diese Arbeit vielen mir auch einige Erfahrungsberichte in die Hä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 häufig so zu sein, dass
Test-Werkzeuge dann angeschafft werden, wenn das Projekt bereits in der Schieflage ist. Dann ist
es jedoch bereits zu spät. Werkzeuge – können sie noch so mächtig sein – mü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 überflüssig“
”
gefunden haben – können Test-Werkzeuge wertvolle Dienste leisten.
Für Interessierte sei Bret Pettichord’s Software Testing Hotlist [12] empfohlen. Diese übersichtlich gegliederte Übersicht über Material zum Thema Testen bietet einen guten Ausgangspunkt fü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 Schä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/

Testwerkzeuge

Transcription

Documents pareils

¨Ubungen zur Vorlesung CPU-Design SS 2010 ¨Ubungsblatt 1

Eintauchen in die Welt und die Techniken der Brücke

PDF-Datei - IT-Administrator

Aufgabenblatt 1

Als fester Bestandteil des Integrationsprozesses sind folgende

können Sie den vollständigen Artikel als PDF

65-teiliges Werkzeugset - A8E070eUR Nach der

kostenlose Werbemöglichkeiten - IPM