Methodische Grundlagen der Testautomatisierung
Aus Winfwiki
| Name des Autors / der Autoren: | Yvonne Gadaschewski, Nicolas Druzba |
| Titel der Arbeit: | "Methodische Grundlagen der Testautomatisierung" |
| Hochschule und Studienort: | FOM Essen |
| Abgegeben am: | 14.01.2010 |
| Betreuer: | Prof. Dr. Uwe Kern |
Inhaltsverzeichnis |
1 Einleitung
Das Testen von Software ist eine unabdingbare Tätigkeit um die Qualität von Software zu steigern, bzw. eine gewisse Qualität zu garantieren.
Da Programme immer größer werden und auch mit anderen Programmen kommunizieren, wird es immer schwieriger eine Software mit einer vernünftigen Testfallabdeckung zu testen. Durch diese Tatsache nimmt die Automatisierung von Softwaretest eine immer größere Rolle im Bereich der Softwaretests ein.
Diese Fallstudie befasst sich mit den Grundlagen von Tests bzw. Grundlagen der Testautomatisierung, denn viele Grundlagen sind für beide Arten von Test gleich, jedoch kommen bei der Testautomatisierung einige Kriterien dazu. Diese Kriterien bilden zum Beispiel den Grundstein der Entscheidung, ob man automatisierte Tests innerhalb eines Projektes bzw. innerhalb einer Firma einsetzt.
2 Grundlagen von Softwaretests
2.1 Begriffsdefinitionen
2.1.1 Fehler
Ein Fehler ist ein nicht anforderungskonformes Verhalten der Software, also eine Abweichung des Ist-Verhaltens vom Soll-Verhalten[1].
Das Soll-Verhalten muss also sehr detailliert in Anforderungsdokumenten bzw. Spezifikationen beschrieben werden, um einen Fehler als solchen zu identifizieren[1].
Im Gegensatz zu physikalischen Systemen, bei denen Fehler durch Verschleiß oder Alterung auftreten können, sind Fehler in der Software bereits durch die Entwicklung vorhanden (ausgenommen sind Fehler die durch Umwelteinflüsse wie zum Beispiel Magnetismus)[1].
Sie treten aber erst bei der Ausführung der Software auf[1].
Fehler sind nicht immer gleich schwer und so kann man Fehler gewichten.
Manfred Rätzmann stellt als Beispiel folgende Vierer-Skala vor :
- Priorität 1: Fehler, die eine Benutzung der Software, laut der definierten Anforderungen, nicht zulassen.
- Priorität 2: Fehler, die eine Benutzung der Software, laut der definierten Anforderungen, nur durch „Workarounds“, also durch Umwegen möglich macht.
- Priorität 3: Fehler, die die Benutzung der Software, durch Umwege nur in sehr geringem Maße beeinflussen.
- Priorität 4: Fehler, die die Anwendung nur optisch, jedoch nicht in seiner Funktion und Bedienbarkeit beeinflussen.[2]
- Priorität 1: Fehler, die eine Benutzung der Software, laut der definierten Anforderungen, nicht zulassen.
Man kann zum Beispiel noch eine Prioritätsstufe zwischen 1 und 2 einfügen, in der es darum geht, ob die Benutzung einer Hauptfunktion oder einer Nebenfunktion unmöglich ist.
Es ist möglich, dass ein Fehler durch andere Fehler verdeckt wird und somit erst entdeckt wird, wenn die anderen Fehler behoben worden sind[1].
2.1.2 Test
Um einen Defekt in einer Software zu beheben, muss dieser zuerst lokalisiert werden. Durch den Test wird nur ein Fehlerzustand festgestellt[3].
Die genaue Lokalisierung im Quellcode und die Behebung des Fehlers ist Aufgabe des Entwicklers[3]. Umso besser ein Fehlerzustand beschrieben wird, umso leichter wird es für den Entwickler den Fehler zu lokalisieren[3].
Tests stellen im Allgemeinen nur eine stichprobenhafte Ausführung von Testobjekten dar, da die Anzahl der Testfälle bei einer 100% Testfallabdeckung, je nach Komplexität der Software, nahezu unmöglich ist[3].
Die Auswahl der Testfälle sollten deshalb nach bestimmten Kriterien ausgewählt werden, wie die Wahrscheinlichkeit einen neuen Fehler aufzudecken oder das Risiko, welches eine Fehlerwirkung nach sich zieht[3].
Die Ziele von Tests sind Fehlerwirkungen zu ermitteln, die Qualität von Software zu bestimmen, die Akzeptanz der Software gegenüber zu steigern und die Analyse des Programms und der Dokumente um Fehlerwirkungen vorzubeugen[3].
Neben der Durchführung von Tests ist auch die Planung, Vorbereitung wie zum Beispiel das Bereitstellen von Testdaten, als auch die Auswertung der Test von großer Bedeutung[3].
2.1.3 Qualität
Tests dienen durch die Feststellung und das anschließende Beheben von Fehlern zur Steigerung der Softwarequalität[4]. Besonders die spätere Benutzung der Software steht im Vordergrund bei der Auswahl der Testfälle[4].
Zusätzlich zum Fehlerfreiheitsgrad einer Software gehören auch die Funktionalität, die Zuverlässigkeit und Benutzbarkeit, die Effizienz, Änderbarkeit und die Übertragbarkeit zu den Kriterien der Softwarequalität[4].
Welches Qualitätsniveau eine Software in den einzelnen Bereichen haben soll, sollte vor der Erstellung und der Tests als Qualitätsanforderung festgelegt werden[4].
Die Wirtschaftlichkeit spielt dort ebenfalls eine gewichtige Rolle, da der Aufwand mit steigender Anforderung an die Qualität ebenfalls steigt[4].
Eine absolut fehlerfreie Software zu entwickeln ist nahezu unmöglich, welches im Abschnitt Aufwand näher erläutert wird[4].
2.1.4 Aufwand
Um eine fehlerfreie Software zu entwickeln müsste das Programm in allen möglichen Situationen, mit allen möglichen Eingaben unter Berücksichtigung aller möglichen Randbedingungen getestet werden[5]. Die Anzahl von Testfällen, welche sich durch die mögliche Anzahl kombinatorischer Möglichkeiten ergibt, verhindert das vollständige Testen von Software in der Praxis[5].
Beispiel: Eine Anwendung hat 4 Verzweigungen. Diese Verzweigungen liegen in einer Schleife. Die maximale Anzahl von Durchläufen dieser Schleife werden hier auf 20 festgelegt, um eine Begrenzung zu haben[6].
Bei dieser vorgegebenen Beschränkung von maximal 20 Iterationen der Schleife und der Annahme, dass alle Verzweigungen unabhängig voneinander sind erhält man eine Anzahl 100 Billionen unterschiedlicher Abläufe[6].
Werden die Testfälle manuell ausgeführt und man legt eine Durchschnittsdauer von 5 Minuten je Testfall zu Grunde, würde man insgesamt ca. eine Milliarde Jahre für den Test brauchen[6].
2.2 Psychologie des Testens
Bei Menschen können Fehler passieren wir sind halt keine Maschinen. Wie es so lautet doch "Errare humanum est"[7].
Zugegeben werden diese Fehler aber eher selten und wenn dann sehr ungern[7].
Bei dem Testen von Software geht es darum, die Fehler gegenüber der angeforderten Spezifikation bzw. Beauftragung des Kunden herauszufinden[7]. Die so gefunden Fehler müssen dann an die verantwortlichen Entwickler weitergeleitet werden zwecks Behebung der selbigen[7].
Die Entwicklung von Software wird häufig als konstruktiv und eine Überprüfung der Dokumente und zusätzlich der Software als destruktiv angesehen[7]. Dadurch ergeben sich oft von den beteiligten Personen unterschiedliche Sichtweisen zu der Einstellung ihrer beruflichen Tätigkeit[7].
Bei der Prüfung stößt man dann auf Fragen wie, ob die Tests eines Programms auch durch seinen Entwickler erfolgen können, dazu gibt es aber keine richtige Beantwortung[7]. Oder wenn der Tester der Autor ist, dann muss seine Arbeit kritisch geprüft werden[7].
Schwierig ist dabei das nicht jeder es schafft einen Abstand zu seinem selbst erstellten Produkt herzustellen, da gelangen wir wieder an dem Punkt, wer gibt schon gerne seine eigenen Fehler zu?[7]
Wenn Entwickler sein eigenes geschriebenes Programm testet, kann es vorkommen, dass er hier zu positiv an die Sache rangeht[7]. Es besteht die Gefahr das die wichtigen und auch sinnvollen Testfälle vergessen werden oder das er sich vom Grundsatz her nur für die Programmierung und nicht für das Testen interessiert, so dass nur ein oberflächlicher Test erfolgt[7].
Sollte als Beispiel ein elementarer Designfehler in das Programm eingebaut sein, weil eventuell die Aufgabenstellung falsch interpretiert wurde, dann kann auch der Entwickler dies in seinem Test nicht finden[7]. Da er durch die falsche Interpretation den dazu gehörigen Testfall um diesen Fehler zu finden, nicht ermittelbar ist da von seiner Sichtweise kein Fehler vorhanden ist[7].
Hier könnte man dann dazu übergehen das Programm von einem zusätzlichen unabhängigen Entwickler mitzutesten lassen[7].
Natürlich sind die Kenntnisse die über das eigen entwickelte Programm bestehen ohne Frage auch ein Vorteil[7]. Man muss nicht eingearbeitet werden und somit kann Zeit gespart werden[7].
Es muss dazu eine Abwägung von Seiten der Verantwortlichen erfolgen, wie als Beispiel das Management ob der Zeitfaktor eine große Rolle spielt und dadurch die Tests durch die eigenen Entwickler laufen sollen oder diese von unabhängigen Testern ausgeführt werden[7]. Diese Entscheidung muss von Fall zu Fall auf das jeweilige Testobjekt gesichtet werden und den damit verbundenen Risiken[7].
Von Vorteil ist es wenn die Tests durch unabhängige Testteams ausgeführt werden[7].
Es spielt hier die Unvoreingenommenheit gegenüber dem Testobjekt eine große Rolle. Zwar muss auch der Tester sich das Wissen über das jeweilige Testobjekt aneignen, dafür bringt er aber ein spezifisches Wissen über die Durchführung von Tests mit, die ein Entwickler entweder nicht hat oder sich auch aneignen muss[7].
Der Tester hat die Aufgabe die gefundenen Fehler und Abweichungen an den Autor und den entsprechenden Leitenden mitzuteilen[7]. Hier muss auf die Kommunikation zwischen Testerteam und Entwickler geachtet werden, da es durch diese Kommunikation auch zu Probleme kommen könnte[7]. Fehlern von anderen Personen nachzuweisen ist nicht leicht zu händeln[7]. Dabei ist es wichtig das nachgewiesene Fehler und Testumgebung müssen genauestens dokumentiert werden, damit die Ursachen für das Fehlverhalten nachvollzogen werden können[7]. Nicht selten kommt es dazu das diese Fehlverhalten dann von Seiten des Entwicklerteams nicht reproduziert werden können[7]. Auch eine Abstimmung bzw. Beschreibung ist zu erstellen wann ein Fehler oder eine Abweichung im Programm vorliegt[7]. Sollte das nicht aus der detaillierten Beschreibung bzw. Anforderung des Programms herauskristallisiert werden, dann ist hierzu der jeweilige Verantwortliche sprich eventuell Management und der Kunde zu einer Entscheidung zu bringen[7]. Denn es kann nicht von Seiten Testern und Entwicklern diskutiert werden ob es sich hier um einen Fehler handelt oder eine zusätzliche Funktion[7]. Daher sollten Entwickler über die Grundlagen des Testes informiert sein und Tester ein Grundwissen der Softwareentwicklung besitzen, so das hier auch ein gegenseitiges Verständnis der jeweiligen Arbeit des Anderen erfolgen kann[7]. Aber nicht nur auf der Stufe der Entwickler und der Tester kann dies Missverständnis herrschen, auch wenn es einen Testmanager und eine Projektmanager gibt, können auf Ebene des Managements Probleme entstehen[7].
2.3 Modelle der Softwareentwicklung
2.3.1 Wasserfallmodell
Das Wasserfallmodell legt fest, dass eine Software Stufe für Stufe entwickelt wird[8].
Es gibt Rückkopplungsschleifen zwischen den Stufen, welche aber auf angrenzende Stufen begrenzt sind[8].
Das Wasserfallmodell besitzt folgende Merkmale[8]:
- eins Jede Aktivität ist in der richtigen Reihenfolge vollständig durchzuführen
- zwei Der Ablauf der Entwicklung ist sequentiell. Jede Stufe muss beendet sein, bevor die nächste starten kann.
- drei Das Modell ist einfach und verständlich.
- vier Das Modell ist benötigt nur wenig Managementaufwand.
- fünf Eine Benutzerbeteiligung ist nur in der Definitionsphase vorgesehen.
2.3.2 V-Modell
Das V-Modell ist eine Erweiterung des Wasserfall-Modells[8]. Es wurden die Verifikation und Validation der Teilprodukte integriert[8].
Bei der Verifikation handelt es sich um die Überprüfung, ob eine Software mit seiner Spezifikation übereinstimmt[8]. -> Wird eine korrekte Software entwickelt?[8]
Bei der Validation handelt es sich um die Prüfung, ob sich die Software für ihren Einsatzzweck eignet[8]. -> Wird die richtige Software entwickelt?[8]
2.4 Methoden von Softwaretests
Bei Testverfahren erfolgt eine Unterscheidung in funktions- und strukturbasierte Tests[9].
Bei Black-Box-Tests handelt es sich um funktionsbasierte Tests, während mit White-Box-Tests strukturbasierte Tests durchgeführt werden[9].
Daneben existieren die Gray-Box-Tests die immer mehr an Bedeutung gewinnen, da hier nicht eine Unterscheidung getroffen wird sondern je nach Bedarf entschieden wird ob ein funktions- oder ein strukturbasierter Test erfolgt[9].
 |  |
2.4.1 Blackbox
Unter Black-Box-Tests versteht man zwei verschiedene Definitionen[11].
Tests zur der Prüfung der Schnittstellendefinitionen in jeglicher Situation werden Black-Box-Tests genannt, hier ist dann nur eine definierte Schnittstelle des Programms oder des Programmteils bekannt[11]. Aber auch Tests die von Seiten des Auftragsgebers bei der Produktabnahme erfolgen, werden Black-Box-Tests genannt[11]. Hier wird überprüft ob das Endprodukt allen definierten Anforderungen entspricht[11]. Eine Erstellung von Testfällen erfolgt hier anhand der jeweiligen Aufgabenbeschreibungen[11].
2.4.2 Whitebox
Die Erstellung der Testfälle von White-Box-Tests erfolgt basierend auf dem Wissen des sogenannten Innenlebens des jeweiligen zu testender Software[12]. Man kann auch hier von entwicklerspezifischen Tests sprechen, hier wird gesichert das jede Funktion der Software einmal vollständig durchlaufen und auf ihr korrektes Verhalten geprüft wurde[12]. Die Entwicklung der Testfälle, der Risikobetrachtung und der Methodik erfolgt aus der Kenntnis der internen Abläufe und Strukturen[12].
2.4.3 Graybox
Hier wird sich analog zum Black-Box-Test mit dem korrekten Ablauf und der Zuverlässigkeit der Eingabe und Ausgabe des Programms bzw. des Moduls befasst[13]. Testfälle, die Risikobetrachtung und die Methoden werden aus der Kenntnis der internen Abläufe und Strukturen heraus entwickelt[13].
Bei einer komponentenbasierten IT Struktur gewinnt der Gray-Box-Test immer mehr an Bedeutung, da hierbei die Software als ein Zusammenspiel von mehren Komponenten betrachtet wird[13].
3 Teststufen
3.1 Modultest
Der Modultest ist die erste Teststufe die nach der vorangegangenen Programmierphase der Softwarebausteine erfolgt[14].
Unabhängig von der eingesetzten Programmiersprache werde die Softwareeinheiten unterschiedlich bezeichnet, als Module, Units oder Klassen (bei objektorientierter Programmierung)[14]. Die dazugehörigen Tests werden entsprechend Modultest, Unit Test oder Klassentest genannt[14]. Dabei wird von Komponenten oder Softwarebausteinen gesprochen[14]. Der Test des Softwarebausteins wird dann als Komponententest bezeichnet[14].
Es erfolgt eine Betrachtung der einzelnen Bausteine losgelöst von den anderen Bausteinen, damit erreicht man, dass bei Fehlern, direkt die betroffene Komponente erkannt werden kann[14]. Zwar kann die testenden Komponente auch aus mehren Bausteinen bestehen, aber es ist entscheidend das bei diesem Test nicht die Zusammenarbeit mit den Nachbarkomponenten geprüft wird, das ist Teil des Integrationstest, sondern eine Prüfung der internen Aspekte der Komponente geprüft werden[14].
3.2 Systemtest
Es erfolgt eine Betrachtung des Systems als "Ganzes"[15]. Die Testfälle können hier am einfachsten entwickelt werden wenn man sich die Software als Inhalt einer Box vorstellt[15]. Es geht darum die Funktionalitäten des Systems zu betrachten, die in Richtung Vollständigkeit, Performance, Sicherheit, Integration in die bestehende Infrastruktur etc. abzielen[15]. Daher sollten die Testfälle vor allem auf die Beantwortung der Frage "Wurde an allen geforderten Stufen gedacht" abzielen[15]. Denn sollte eine geforderte Komponente in der Software fehlen, kann das System schwer als Ganzes betrachtet werden[15]. Dieses Tests werden oft durch eigene Testteams ausgeführt[15].
Es sollen dadurch folgende Fragen beantwortet werden[15]:
- eins Funktionale Vollständigkeit des Systems oder Ausbaustufe
- zwei Ablaufverhalten bei unterschiedlichen Betriebssystemen oder unterschiedlichen Hardware Konfigurationen
- drei Installierbarkeit und Konfigurierbarkeit auf unterschiedlichen Systemen
- vier Kapazitätsbeschränkungen (max. Dateigröße, Anzahl, Datensätze, max. Anzahl gleichzeitiger Benutzer)
- fünf Reaktion auf Probleme in der Programmumgebung (Systemabsturz, Netzwerk nicht verfügbar, Platte voll, Drucker nicht bereit)
- sechs Schutz vor feindlichen Zugriff auf Daten und Programme
3.3 Integrationstest
Mit einem Integrationstest wird geprüft ob die Zusammenarbeit der Programmeinheiten funktioniert[16].
Die einzelnen Programmeinheiten die vorher einzeln getestet wurden, werden hier zu größeren Einheiten zusammengefügt[16]. Dieses Zusammenspiel der Module wird dann in den Integrationstest ausgeführt[16]. Man befasst sich nicht mehr mit den Details der Implementierung sondern mit den Anforderungen und Designentscheidungen, die für die Zusammenarbeit entscheidend sind[16].
Teilweise je nach Größe der Organisation werden diese Tests direkt durch das Entwicklungsteam oder durch ein separates Testteam durchgeführt[16].
Bei diesen Tests werden folgende Punkte geprüft[16]:
- eins Funktionsfähigkeit der Transaktionen über mehre Module
- zwei Zusammenspiel der Menü, Toolbar, Funktionstasten und den aufgerufenen Programmeinheiten
- drei Zusammenspiel von Verarbeitungs- und Darstellungsmethoden
- vier Reaktion der Programmteile auf Systemereignisse (Events)
3.4 Performancetest
Diese Tests prüfen das Verhalten des Programms nach dem Zusammenbau aller Module, ob das Programm mit den maximalen vorgesehenen oder voraussehbaren Belastungen zu recht kommt[17]. Das bedeutet die Prüfung ob das Programm zuverlässig bei einer maximalen Nutzung und auch mit einer angemessenen Geschwindigkeit arbeitet[17]. Die Tests gehen dabei oft über die maximale Belastbarkeit darüber hinaus, bis eventuell das komplette Programme oder ein Modul die Verarbeitung einstellt[17].
Bei einer Auffälligkeit oder einem reinem Versagen wird entsprechend nach einer Optimierung oder einer Anpassung zur rechtzeitigen Entlastung bei einer Überlastung des Programms gesucht[17].
Einen Performancetest durchzuführen ist sehr wichtig, da es teileweise zu Problemen bei der Auslieferung von Software kommt die dann zwar alle Funktionen enthalten aber auf Grund von schlechter Performance bei einer maximalen Auslastung nicht die geforderte Stabilität erbringen[17].
3.5 Abnahmetest
Es besteht hier die Unterscheidung zu den anderen Tests, dass bei einem Abnahmetest es nicht darum geht weitere Fehler zu finden, sondern zu zeigen, dass alle definierten Anforderungen an das Programm erfüllt worden sind[18].
Eine Prüfung des Programms kann nach der Freigabe der Entwickler erfolgen, durchgeführt durch den Auftraggeber oder durch den Auftraggeber benannte Personen[19].
Geprüft wird auch hier gegen die Produktdefinition des Programmes[20].
Es erfolgt die Konzentration auf einen Test des Programmes unter realen Betriebsbedingungen[20].
Geprüft wird auf[20]:
- eins Prüfung ob alle Kriterien der vorherigen Produktdefinitionen erfüllt wurden
- zwei Testfälle aus dem Systemtest
- drei Prüfung der Verarbeitung von angeforderten Geschäftsvorgängen wie als Beispiel Verarbeitung von Zeitdaten oder Abrechnungen
- vier Prüfung des durchlaufenden Betriebes des Programms angelehnt an einer längeren Zeitspanne.
4 Testautomatisierung
4.1 Grundansatz
4.1.1 Fachliche Sicht
Aus der fachlichen Sicht gelten bei automatisierten Tests die gleichen Anforderungen wie bei manuellen Testfällen.
Es muss bei den automatisierten Tests ebenfalls am Ende eine Dokumentation über die durchgeführten Testfälle erzeugt werden. Diese Dokumentation muss genauso nachvollziehbar sein wie bei den entsprechenden manuellen Tests, so dass eine einfache Auswertung der Testfälle möglich ist.
Zuerst sollten manuelle Testfälle von fachlichen Spezialisten geschrieben werden, welche sich mit den Anforderungen der Software auskennen. Diese Testfälle werden in der frühen Phase der Entwicklung manuell durchgeführt, da am Anfang die Fehlerhäufigkeit größer ist und dadurch sehr häufige Veränderungen in der Software nötig werden. Das Anpassen von automatisierten Testfällen stellt einen erheblich größeren Aufwand dar, als das von manuellen. Sollten die Anfangsfehler beseitigt sein, erstellt ein Spezialist, meistens ein Entwickler auf Grundlage der manuellen Testfälle die automatisierten. Bei einem auftretenden Fehler kann der Testfall dann auch manuell, z.B. vom Entwickler, nachgetestet werden, um eine mögliche Fehlerursache zu finden.
4.1.2 Technische Sicht
Automatisierte Tests stellen eine hohe Anforderung an das zu testende System und dessen Daten, da sich im Gegensatz zu einem Menschen, ein Testwerkzeug nicht automatisch auf eine Veränderung der Testumgebung oder der Testparameter einstellen kann.
Die Eingabeparameter und das erwartete Verhalten, sowie das erwartete Ergebnis eines Testfalls, müssen also exakt vorher bekannt sein, damit das Testwerkzeug Vergleichsparameter hat auf das es reagieren kann. Die Reaktion des Testwerkzeugs wird ebenfalls vorher festgelegt.
Testdaten müssen aus diesem Grund nach dem Test, ohne großen Aufwand, wieder in den Ursprungszustand zurückgesetzt werden können, da sonst das Ergebnis beim nächsten Testdurchlauf verfälscht werden kann, zum Beispiel bei zu prüfenden Mengen.
Beispiel:
Ein Artikel soll vom Lager bestellt werden. Dieser Artikel muss für den bestimmten Testfall eine Verfügbarkeit im Lager haben. Wenn keine Verfügbarkeit für diesen Artikel vorliegt, kann ein manueller Tester sehr schnell einen vergleichbaren Artikel verwenden und des Testfall fortführen. Ein automatisierter Testfall hingegen würde mit einem Fehler abbrechen.
Ein weiterer Aufwand stellt das Bereitstellen einer eigenen Testumgebung für automatisierte Tests dar.
Oftmals hat eine Software Schnittstellen zu Drittsystemen, mit denen die Software kommuniziert. Diese Drittsysteme müssen ebenfalls als Testsystem in der Testumgebung abgebildet werden. Würde die Software mit Drittsystemen aus dem manuellen Testbereich oder der Praxis kommunizieren ist die Gefahr zu groß, das Datenveränderungen in diesen Systemen zum Scheitern der Tests führen.
4.2 Anwendungsgebiete
In allen Bereichen, in der Softwaretests manuell durchgeführt werden, können theoretisch auch automatisierte Test eingesetzt werden.
Jedoch spielt es eine große Rolle, ob mit vielen Veränderungen in der Software oder den Testdaten zu rechnen ist und wie häufig in Testfall durchgeführt werden muss. Bei starken Veränderungen oder geringer Anzahl von Durchläufen wird der Einsatz der Testautomatisierung aber unökonomisch.
Ein weiter Punkt ist die Kompatibilität des Testwerkzeugs zur zu testenden Software bzw. zum System. Da es aber immer mehr Testwerkzeuge auf dem Markt gibt, findet man fast für jeden Bereich ein passendes, ohne selbst eins entwickeln zu müssen.
4.3 Testwerkzeuge
4.3.1 Allgemein
Es existieren die verschiedensten Arten von Testwerkzeugen, die zur Unterstützung von Tests oder zur Testautomatisierung eingesetzt werden können. Die verschiedenen Testwerkzeuge lassen sich in Gruppen einordnen, die je nach Testaktivität in den einzelnen Phasen der Tests unterstützen können. Normalerweise werden in Projekten nicht alle Arten von Testwerkzeugen eingesetzt. Eine vorhergehende Analyse der Testwerkzeuge ist jedoch vor ihrer Auswahl unbedingt notwendig, da sonst nicht bestimmt werden kann, ob ein Werkzeug sinnvoll innerhalb eines Projektes eingesetzt werden kann.
4.3.2 Typen
4.3.2.1 Werkzeuge für Management und Steuerung von Tests
Es werden Mechanismen zur Erfassung, Katalogisierung und Verwaltung der Testfälle und deren Priorisierung angeboten[21].
Dabei kann eine Überwachung des Status von Testfällen erfolgen[21]. Dazu unterstützen auch einige Werkzeuge das Projektmanagement, in Richtung als Beispiel Ressourcen- und Zeitplanung[21]. So kann dem Testmanager bei der Planung geholfen werden und er kann den Überblick über die verschiedenen Testfälle behalten[21].
Fortschrittliche Werkzeuge können auch anforderungsbasiertes Testen unterstützen[21].
Es können Systemanforderungen erfasst werden oder sogar importiert werden um mit den Tests verknüpft werden die die jeweilige Anforderung prüfen[21].
Auch Prüfungen der Konsistenz können ausgeführt werden, als Beispiel wurde für jede Anforderung auch ein Testfall geplant[21].
Bei den sogenannten Requirements Management Werkzeugen können alle Informationen zu den Anforderungen gespeichert und verwaltet werden[21].
Bei den Requirements Management Tools kann ein Austausch mit Testmanagementwerkzeugen erfolgen[21]. So ist es möglich eine Verknüpfung der Anforderungen, der Fälle und der Ergebnisse vorzunehmen und damit eine Prüfung aller Anforderung auszuführen.
Ein Werkzeug für die Verwaltung von Fehlermeldungen ist sehr wichtig[21].
Dazu werden Fehlermanagementwerkzeuge genutzt die eine Erfassung, Verwaltung, Verteilung und rechnerische Auswertungen der Meldungen ermöglichen[21].
Bei Werkzeugen zu Konfigurationsmanagement handelt es sich im engeren Sinne nicht so sehr um Testwerkzeuge[21]. Dieses Werkzeug ermöglicht die Verwaltung der unterschiedlichen Versionen und Konfigurationen der Software, zusätzlich dazu auch die Dokumentationen und Testdokumente können ebenfalls verwaltet werden[21]. Hier kann dann schneller eine Suche erfolgen welche Ergebnisse aus welchem Test an welchem Objekt der Software und der Version erbracht wurden[21].
Eine Integration von den Werkzeugen untereinander und mit anderen gewinnt immer mehr an Beachtung[21]. Es können Anforderungen importiert werden, der Status kann ermittelt und nachvollzogen werden[21]. Resultate zu Test können automatisch übermittelt und archiviert werden[21]. Durch die Kopplung von Testwerkzeug und Fehlerwerkzeug, können Pläne für die Nachtests erzeugt werden[21]. So ist es möglich das alles von Status zu den Anforderungen, bis zu den Tests und den Ergebnissen ohne Verlust der Daten nachvollzogen werden kann[21].
4.3.2.2 Werkzeuge für Testspezifikation
Damit eine Reproduktion des Tests ausgeführt werden kann müssen die Bedingungen Vor und Nach dem Test sowie auch die Testdaten festgelegt werden[22].
- eins Datenbankbasiertes Testdatengeneratoren[22]
- eins Codebasierte Testdatenbankgeneratoren[22]
- eins Schnittstellenbasierte Testdatengeneratoren[22]
- eins Spezifikationsbasierte Testdatengeneratoren[22]
Die Spezifikation der Tests ist anspruchsvoll und daher wird hier umfassendes Know-How über das zu testenden Objekts vorausgesetzt[22]. Der Testdatengenerator kann Regeln anwenden um die Test auch systematisch zu erzeugen, hier erfolgt aber keine Beurteilung ob die generierten Testfälle richtig oder falsch sind[22]. Dies muss dann weiterhin der Testersteller erarbeiten, sowie die Sollreaktionen müssen ebenfalls manuell ergänzt werden[22].
4.3.2.3 Werkzeuge für statische Tests
Diese Werkzeuge unterstützen dabei schon in der relativ frühen Phase der Entwicklung Fehler zu entdecken[23]. Dadurch können Zeit und auch Kosten gespart werden da diese Fehler dann sofort behoben werden können und somit auch keine weiteren Folgefehler entstehen[23].
Bei den Werkzeugen zur Review-Unterstützung kann eine Hilfestellung zur Auswertung der Ergebnisse geben. Alles was in Reviews entsteht an Planungen oder Dokumentationen kann hier verwaltet werden[23].
Dadurch können die Reviews und deren Aufwände geplant werden, sowie aber auch Schwächen in der Entwicklung erkannt und behoben werden[23].
Bei den Programmcodes werden die Maßzahlen von den statischen Analysatoren geliefert[23]. Damit können große und damit anfällig für Fehler identifiziert werden[23].
Auch für die frühe Erkennung von Unstimmigkeiten und Fehlern im Quellecode, werden diese Analysatoren eingesetzt[23].
4.3.2.4 Werkzeuge für dynamische Tests
Diese Werkzeuge tragen dazu bei eine Entlastung der mechanischen Arbeit zu erbringen da es sich hier oft um Werkzeuge zur automatisierten Durchführung von Tests handelt[24].
Das zu testende Objekt wird mit den Eingabedaten versorgt, die Reaktionen werden aufgezeichnet und der Ablauf des Tests dokumentiert[24].
Hier teilen sich oft Testobjekt und Werkzeug dieselbe Hardware[24]. Es könnte aber da durch zu Beeinflussung des Testobjekts kommen hinsichtlich Laufzeitverhalten[24].
Die Werkzeuge werden an die Testschnittstelle angeschlossen, dadurch unterscheiden sie sich nach der Teststufe für die sie eingesetzt werden[24].
Der Einsatz von Debugger ermöglicht als ein Analysewerkzeug des Entwicklers das nachvollziehen von Ausfällen und Fehlern, beim Test können mit ihnen Situationen herbeigeführt werden die meist nur mit großem Aufwand darzustellen sind[24].
Für die Tests bei der Komponentenebene könne sie als Schnittstelle dienen[24].
Die Testtreiber kommen zum Einsatz wo die zu testenden Objekte über die Programmierschnittstellen angesprochen werden und keine Benutzerschnittstelle zur Verfügung steht und dadurch manuelle Test nicht auszuführen sind[24]. Die Testtreiber werden genutzt in den Komponenten- bzw. Integrationstests und zusätzlich auch für besondere Aufgaben im Rahmen eines Systemtests[24].
Sollte bei einem Systemtest mit dem System nicht ausführbar sein kann auch ein Simulator zum Einsatz kommen[24]. Durch diese wird die Umgebung so realistisch wie möglich abgebildet[24].
Wenn die Benutzeroberfläche als Test dient können auch Testroboter eingesetzt werden[24]. Diese Art von Werkzeugen nennt man “Capture-and-Replay-Tools” bzw. “Capture-and-Playback-Tools”[24]. Diese Roboter arbeiten wie eine Art Aufnahme- bzw. Abspielgerät, bei dem „Capture-and-Replay-Tools“ werden alle manuellen Schritte aufgezeichnet[24]. Diese Schritte werden dann als Testskript gespeichert. Dies ermöglicht eine automatische Abspielung des Tests[24]. Vor einer Nachbearbeitung sind diese Skripte nicht gewahrt da auch hier Fehler auftreten können[24].
Der Einsatz von Komparatoren ermöglicht die Unterscheidung zwischen dem Ergebnis des Tests und dem definiertem Ergebnis[24].
Es können auch so genannte dynamische Analysen durch Werkzeuge erfolgen, dabei wird eine Information erzeugt die Auskunft als Beispiel über belegte und freie Speicher gibt[24].
4.3.2.5 Werkzeuge für nicht funktionale Tests
Für die Last- und Performancetests gibt es auch Werkzeuge, bei dem Lasttest kann eine synthetische Last generiert werden wie Abfrage der Datenbank oder Transaktionen[25]. Bei dem Performancetest führen die Werkzeuge Messungen durch und erstellen Protokolle zu den Antwortzeiten des zu testenden Programms, unabhängig von der entstandenen Last[25]. Hier ist es wichtig sich mit Performancetest auszukennen[25].
Auch für die Kontrolle der Zugriffe- und der Datensicherheit gibt es Werkzeuge, diese prüfen ob Sicherheitslücken bestehen wodurch das System angreifbar wird[25].
Der Einsatz von Virenscanner sowie einer Firewall können auch hier eingeordnet werden, da auch alle Zugriffe durch Fremdeinwirkung protokolliert werden[25].
4.4 Testplanung
Um eine Software wirkungsvoll zu testen braucht es eine gute Planung[26].
Die Testplanung umfasst alle Aktivitäten, welche zum Testen einer Software nötig sind. Alle diese Aktivitäten, wie die Prozesse, Methoden, Techniken, Werkzeuge, Ausrüstung sowie die beteiligten Menschen müssen effizient organisiert werden[20].
Es muss Zeitpläne mit Meilensteinen geben, die den Sollstatus des Testverlaufs wiedergeben[20]. Weitergehend muss der Testplan immer aktualisiert, also bei Veränderungen immer auf dem neusten Stand gehalten werden[20]. Nur durch eine effiziente Planung und deren Durchführung ist ein erfolgreicher Testverlauf möglich[20].
4.5 Testdurchführung
Zum Zeitpunkt des Starts der Testdurchführung sollte das eingesetzte Testteam mit dem Testdesign, der Entwicklung der Testfälle und dem Aufbau des Testsystems fertig sein[28].
Die erstellten Testfälle werden dann laut Teststufe und Testplan getestet bzw. der automatisierte Test gestartet[28]. Nach der Beendigung der Durchführung folgt nun die Analyse der Testergebnisse[28].
4.6 Testdokumentation
Eine gute Testdokumentation, d.h. eine Dokumentation, welche die durchgeführten Testfälle mit ihren Testschritten nachvollziehbar und leicht zu analysieren macht, ist eine Grundvoraussetzung für einen sinnvollen automatisierten Test. Nur so
bekommen automatisierte Tests überhaupt eine Aussagekraft.
Wenn mehrere Testwerkzeuge im Einsatz sind ist es von Vorteil, wenn die Ergebnisse in gleicher Weise, bzw. gleicher Form, dokumentiert werden und diese in einem Werkzeug zur Testanalyse zusammengeführt werden können. Dies erhöht die Übersichtlichkeit über die durchgeführten Testfällen und ihren Ergebnissen beträchtlich und macht es demjenigen, der die entsprechenden Testmanagementaufgaben hat erheblich leichter, seine Planung der zukünftigen Testaktivitäten durchzuführen. Außerdem kann viel schneller ein Status über den Stand der Software erstellt und somit schneller auf Probleme reagiert werden. Dies ist von großer Bedeutung, da in einer Entwicklung immer bestimmte Terminvorgaben vorliegen, die einzuhalten sind.
4.7 Ökonomische Aspekte
Ökonomische Aspekte sind in der heutigen Zeit die wichtigsten Punkte, anhand derer festgelegt wird, ob eine Testautomatisierung überhaupt eingesetzt wird oder nicht.
4.7.1 Qualität
Ein korrekt erstellter automatisierter Testfall, liefert besonders bei Wiederholungen, ein konstant genaues Ergebnis, im Gegensatz zu manuell durchgeführten Tests, da der Fehlerfaktor Mensch nicht mehr zum tragen kommt. Ein weiterer Pluspunkt im Bezug auf Qualität ist seine schnelle Durchführung. Man bekommt im selben Zeitraum, bei geringerem menschlichen Einsatz, mehr Testfälle durchgeführt und damit einen größeren Testabdeckungsgrad. Dies steigert die Qualität der Software.
4.7.2 Zeitaufwand
Die Automatisierung von Testfällen nimmt in der Regel eine Menge Zeit in Anspruch. Daher lohnt es sich nicht einen Testfall zu automatisieren, wenn dieser Testfall nur sehr selten ausgeführt wird. Obwohl er erheblich schneller in seinem automatisierten Durchlauf ist, als wenn ein Tester in manuell ausführt, ist der Zeitaufwand der Erstellung dafür zu groß. Umso häufiger also ein Testfall wiederholt werden muss, desto lohnenswerter wird seine Automatisierung. Eine Testautomatisierung in einer frühen Entwicklungsphase ist ebenfalls nicht ratsam, da noch häufige Veränderungen der Software einen sehr großen Zeitaufwand in der Anpassung der automatisierten Testfälle verursachen. Es muss also darauf geachtet werden, dass durch eine Testautomatisierung ein zeitlicher Nutzen entsteht und somit der zeitliche Gesamtaufwand des Testens reduziert wird.
4.7.3 Kosten
Beim Thema Kosten gibt es verschiedene Aspekte. Ein Aspekt ist der oben genannte Zeitaufwand. Wenn der Zeitaufwand in der Erstellung eines automatisierten Testfalls und dessen Durchführung (Einplanung des Testfalls; Starten des Tests; Zurücksetzung des Systems vor erneutem Durchlauf) geringer ist als der Aufwand den ein manueller Tester verursacht, bringt dies eine Kostenersparnis im Bereich Manpower.
Da automatisierte Test qualitativ besser sind und mehr Testfälle in einem gleichen Zeitraum durchgeführt werden können, steigt die Qualität der Software, wie unter dem Punkt Qualität beschrieben wurde. Dadurch ist die Wahrscheinlichkeit von Regressansprüchen bzw. der Aufwand für Nachbesserungen geringer, was wiederum eine Kostenersparnis darstellt.
Dagegen müssen natürlich der Aufwand für die richtige Auswahl eines Testwerkzeuges, die Anschaffungskosten bzw. Lizenzkosten, der Aufwand für die Implementierung des Testwerkzeuges, der Schulungsaufwand im Bezug auf ein Testwerkzeug und der Einsatz eines zusätzlichen Testsystems gerechnet werden.
5 Fazit
Die meisten Grundlagen der Testautomatisierung sind identisch mit den Grundlagen für manuelle Tests.
Es kommen jedoch technische Aspekte hinzu. Ein geeignetes Testsystem muss aufgebaut werden und einige technische Funktionen sind zu beachten, wie z.B. das Zurücksetzen der Testdaten. Wichtig bei der Testautomatisierung ist auch der Zeitpunkt zudem eine Automatisierung der Testfälle in einem Projekt stattfindet, um keinen zusätzlichen Anpassungsaufwand von Testfällen zu erzeugen.
Unsrer Meinung nach wird man deswegen nicht auf manuelle Tests verzichten können, um im Gegenzug alle Tests zu automatisieren, jedoch ist bei vielen größeren Projekten eine zusätzliche Testautomatisierung zwingend notwendig, will man das Projekt in einem angemessenen Zeitraum und angemessener Qualität erfolgreich beenden.
Hinzu kommen immer kürzere Terminvorstellungen von Auftraggebern, für die eine kürzere Fertigstellungszeit bei gleicher oder besserer Qualität ein wichtiges Vergabekriterium ist.
6 Anhang
6.1 Fußnoten
- ↑ 1,0 1,1 1,2 1,3 1,4 Vgl. [SpLi07] S.7f
- ↑ Vgl. [Rätz04] S.19
- ↑ 3,0 3,1 3,2 3,3 3,4 3,5 3,6 Vgl. [SpLi07] S.8ff
- ↑ 4,0 4,1 4,2 4,3 4,4 4,5 Vgl. [SpLi07] S.11ff
- ↑ 5,0 5,1 Vgl. [SpLi07] S.13ff
- ↑ 6,0 6,1 6,2 6,3 Vgl. [Myer01] S.8f
- ↑ 7,00 7,01 7,02 7,03 7,04 7,05 7,06 7,07 7,08 7,09 7,10 7,11 7,12 7,13 7,14 7,15 7,16 7,17 7,18 7,19 7,20 7,21 7,22 7,23 7,24 7,25 7,26 7,27 7,28 7,29 Vgl. [SpLi07] S.33ff
- ↑ 8,00 8,01 8,02 8,03 8,04 8,05 8,06 8,07 8,08 8,09 8,10 Vgl. [Balz98] S.99f
- ↑ 9,0 9,1 9,2 Vgl. [Rätz07] S.55
- ↑ 10,0 10,1 Vgl. [Ligg09] S.8f
- ↑ 11,0 11,1 11,2 11,3 11,4 11,5 Vgl. [Rätz07] S.55
- ↑ 12,0 12,1 12,2 Vgl. [Rätz07] S.56
- ↑ 13,0 13,1 13,2 Vgl. [Rätz07] S.56
- ↑ 14,0 14,1 14,2 14,3 14,4 14,5 14,6 Vgl. [SpLi07] S.42f
- ↑ 15,0 15,1 15,2 15,3 15,4 15,5 15,6 Vgl. [Rätz07] S.69/S.123
- ↑ 16,0 16,1 16,2 16,3 16,4 16,5 Vgl. [Rätz07] S.68
- ↑ 17,0 17,1 17,2 17,3 17,4 Vgl. [Rätz07] S.134
- ↑ Vgl. [Rätz07] S.57
- ↑ Vgl. [Rätz07] S.70
- ↑ 20,0 20,1 20,2 20,3 20,4 20,5 20,6 Vgl. [Balz98] S.542
- ↑ 21,00 21,01 21,02 21,03 21,04 21,05 21,06 21,07 21,08 21,09 21,10 21,11 21,12 21,13 21,14 21,15 21,16 21,17 21,18 Vgl. [SpLi07] S.203ff
- ↑ 22,0 22,1 22,2 22,3 22,4 22,5 22,6 22,7 Vgl. [SpLi07] S.203ff
- ↑ 23,0 23,1 23,2 23,3 23,4 23,5 23,6 Vgl. [SpLi07] S.203ff
- ↑ 24,00 24,01 24,02 24,03 24,04 24,05 24,06 24,07 24,08 24,09 24,10 24,11 24,12 24,13 24,14 24,15 24,16 24,17 Vgl. [SpLi07] S.203ff
- ↑ 25,0 25,1 25,2 25,3 25,4 Vgl. [SpLi07] S.203ff
- ↑ Vgl. [Dust00] S.222
- ↑ Vgl. [Dust00] S.224
- ↑ 28,0 28,1 28,2 Vgl. [Dust00] S.405f
6.2 Literatur- und Quellenverzeichnis
| [SpLi07] | Spillner, Andres; Linz, Tilo: Basiswissen Softwaretest (2007) | |||||
| [Rätz04] | Rätzmann, Manfred: Software-Testing & Internationalisierung (2.Aufl. 2004) | |||||
| [Ligg09] | Liggesmeyer, Peter: Software-Qualität Testen, Analysieren, Verifizieren von Software (2.Aufl. 2009) | |||||
| [Myer01] | Myers, Glenford J.: Methodisches Testen von Programmen (7.Aufl. 2001) | |||||
| [Balz98] | Balzert, Helmut: Lehrbuch der Software-Technik (1998) | |||||
| [Dust00] | Dustin, Elfriede: Software automatisch testen (2000) |
6.3 Abbildungsverzeichnis
| 1 | Steuerfluß eines kleinen Programms |
| 2 | Das Wasserfallmodell |
| 3 | Das V-Modell |
| 4 | Prinzip des funktionsorientierten Tests |
| 5 | Prinzip des strukturorientierten Tests |
| 6 | Testverfahren im Überblick |
| 7 | Ursprung in Inhalt des Testplans |
